AI Semantic Interoperability：RDF / OWL / SHACL
Semantic interoperability 是让 AI 在跨文档、跨数据、跨系统、跨团队时仍能保持概念一致。RDF 适合表达事实和关系，OWL 适合表达本体和可推理语义，SHACL 适合验证图数据是否符合约束，JSON Schema 适合约束 API payload 和模型结构化输出。它们的价值不是“更学术”，而是把自然语言的不稳定性转成可验证的语义契约。
AI Semantic Interoperability / RDF / OWL / SHACL 解读
配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是
docs/AI_SEMANTIC_INTEROPERABILITY_RDF_OWL_SHACL_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| W3C RDF | https://www.w3.org/RDF/ | 参考图式事实表达和资源关系建模 |
| W3C OWL | https://www.w3.org/OWL/ | 参考本体语义、类、属性、推理和概念约束 |
| W3C SHACL | https://www.w3.org/TR/shacl/ | 参考 RDF graph 约束验证, 用于 semantic quality gates |
| JSON Schema | https://json-schema.org/ | 参考 JSON payload 和结构化输出约束 |
| FIBO | https://spec.edmcouncil.org/fibo/ | 参考金融行业本体和语义建模实践 |
核心导读
Semantic interoperability 是让 AI 在跨文档、跨数据、跨系统、跨团队时仍能保持概念一致。RDF 适合表达事实和关系，OWL 适合表达本体和可推理语义，SHACL 适合验证图数据是否符合约束，JSON Schema 适合约束 API payload 和模型结构化输出。它们的价值不是“更学术”，而是把自然语言的不稳定性转成可验证的语义契约。
对金融零售 AI，语义互操作决定了系统能否正确区分客户、账户、合同、交易、费用、争议、授权、风险和证据之间的关系。
问题定义
AI 系统常见语义断裂：
- RAG 检索到的文档使用不同术语，模型无法判断是否同一概念。
- 多系统字段映射靠人工经验，AI 输出与下游系统 schema 不一致。
- 结构化输出只做 JSON 格式校验，不验证业务语义。
- 知识图有节点和边，但没有约束，错误关系会被模型当作事实。
- 本体建设与产品交付脱节，无法进入 runtime、eval 和 control。
语义互操作要解决三个层次：
| 层次 | 问题 | 机制 |
|---|---|---|
| Syntactic | 格式是否正确 | JSON Schema、API schema |
| Structural | 字段和关系是否完整 | SHACL shapes、schema validation |
| Semantic | 概念含义是否一致 | ontology、RDF graph、concept registry |
核心原理与方法
四种技术的分工：
| 技术 | 适用问题 | AI 中的用法 |
|---|---|---|
| RDF | 表达资源、事实和关系 | evidence graph、knowledge graph、provenance |
| OWL | 表达类别、属性、层级和语义规则 | ontology slice、concept reasoning、domain vocabulary |
| SHACL | 验证图是否符合形状和约束 | semantic quality gate、data onboarding validation |
| JSON Schema | 验证结构化 JSON payload | tool input/output、model response schema |
方法上应采用 semantic slice：
- 选择一个高价值场景，例如 lending policy assistant。
- 抽取核心概念和关系，例如 applicant、credit product、eligibility rule、decision reason。
- 定义最小 ontology slice，而非全企业本体。
- 用 SHACL 定义必须存在、禁止存在、取值范围和关系约束。
- 用 JSON Schema 约束模型输出和工具接口。
- 把 semantic validation 接入数据 onboarding、RAG ingestion、eval 和 release gate。
系统与架构模型
可落地的语义架构：
Enterprise Concept Registry
-> Ontology Slice
-> RDF Knowledge / Evidence Graph
-> SHACL Validation Gates
-> JSON Schema Tool and Output Contracts
-> Semantic Eval and Runtime Monitoring
关键组件：
| 组件 | 职责 |
|---|---|
| Concept Registry | 概念定义、上下文、owner、版本、同义词和禁用含义 |
| Ontology Slice | 选择 use case 所需的类、属性、关系和约束 |
| RDF Graph | 存储事实、关系、来源、证据和 provenance |
| SHACL Shapes | 验证图对象是否满足业务约束 |
| Schema Registry | 管理工具输入、输出和模型结构化响应 |
| Semantic Gateway | 在 ingestion、retrieval、tool call 和 output 阶段执行语义检查 |
示例：lending explanation output 不只要求 JSON 格式正确，还要语义正确：
| 校验层 | 规则 |
|---|---|
| JSON Schema | 必须包含 decision_id、reason_codes、source_ids、disclosure_text |
| SHACL | reason_code 必须属于该产品和地区允许集合 |
| Ontology | affordability、credit history、identity verification 不能被混作同一原因 |
| Runtime Policy | 不允许生成未在决策系统中存在的拒绝理由 |
关键机制与取舍
| 取舍 | 判断原则 |
|---|---|
| RDF/OWL 严谨性 vs 工程复杂度 | 高风险概念用本体和图约束，低风险内容用轻量 schema |
| Full ontology vs Slice | 从 use case slice 开始，逐步沉淀复用概念 |
| Reasoning vs Validation | 金融核心流程优先 validation，不依赖隐式推理替代控制 |
| Natural language flexibility vs Structured output | 用户表达可自然语言，系统边界和工具交互必须结构化 |
| Central semantic team vs Domain ownership | 语义平台统一机制，概念定义由业务服务域 owner 负责 |
一个实用原则：凡是进入工具调用、客户承诺、监管证据、财务影响或客户权益的 AI 输出，都不能只停留在自然语言，必须有 schema 和语义约束。
证据与控制
语义控制应覆盖 ingestion、generation 和 action：
| 控制点 | 控制活动 | 证据 |
|---|---|---|
| Knowledge onboarding | 文档和图谱对象通过 SHACL 校验 | validation report、rejected records |
| Retrieval | 检索结果必须匹配 context 和 concept type | retrieval trace、concept filter log |
| Structured output | 模型输出通过 JSON Schema 和 semantic checks | schema validation log |
| Tool call | 工具参数符合业务概念和权限约束 | tool input validation、audit trace |
| Evidence graph | 关键输出连接 source、activity、agent 和 time | RDF provenance query |
Semantic quality dashboard 可跟踪：
- 概念未映射率。
- SHACL 校验失败类型。
- 模型结构化输出失败率。
- 跨上下文概念误用次数。
- 高风险概念的人工 override rate。
- 语义变更导致的 eval 回归。
AI 产品与金融零售场景
以贷款政策 AI 为例：
| 概念 | 语义约束 |
|---|---|
| Applicant | 必须与申请、身份验证和 consent 关系明确 |
| Product | 必须有地区、版本、有效期和适用客户段 |
| Eligibility Rule | 必须有 source、owner、生效日期和例外条件 |
| Decision Reason | 必须来自决策系统或批准的原因集合 |
| Disclosure | 必须与地区和产品监管要求匹配 |
系统设计：
Policy Documents
-> Semantic Ingestion
-> Ontology Slice + SHACL Validation
-> Context-Aware Retrieval
-> Structured Explanation Generation
-> Schema + Semantic Validation
-> Evidence Trace
真实取舍：完整本体能提升一致性，但建设成本高。更务实的方法是围绕高风险输出先建立最小语义切片，例如拒绝原因、费用解释、争议状态、客户授权，再逐步扩展。
反模式
- 只做向量检索，不维护概念和关系。
- 把 JSON Schema 当成语义验证，忽略业务含义和上下文。
- 构建大而全本体，无法服务具体产品和评测。
- 语义模型没有 owner 和版本，变更后无法做影响分析。
- SHACL 只用于数据治理平台，不进入 AI ingestion 和 release gate。
- 让模型在自然语言中自由转换金融概念，再把结果写入核心系统。
最终心智模型
RDF 让事实可连接，OWL 让概念有语义，SHACL 让关系可验证，JSON Schema 让系统交互可约束。AI 语义互操作的目标不是追求语义技术本身，而是让模型输出、知识、工具和证据在业务含义上保持一致，并能在关键场景中被验证和追责。
SOTA 状态标注 (2026-07-01)
本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。