AI Semantic Interoperability / RDF / OWL / SHACL Playbook

面向对象: AI Architect / AI PM / AI BA / Data Product Manager / Knowledge Governance Lead / EvalOps Lead / 金融零售 AI 平台负责人。 核心问题: 当 RAG、GraphRAG、AI agents、工具调用、事件流、指标语义层和审计追踪都在消费同一批业务概念时, 如何用 RDF / OWL / SHACL 设计可互操作、可验证、可追溯的 AI semantic contract。 学习目标: 能为 KYC、AML、信贷、客服、财富、监管响应等场景建立 graph facts、ontology semantics、constraint validation、schema boundary、eval contract 和 portfolio evidence。 前提假设: 读者已经具备成熟 PM / BA / CBAP 能力, 本手册不讲需求入门或语义网基础教程, 重点训练 AI 架构、知识治理、语义互操作和金融零售落地表达。

---

Source Anchors

以下来源作为语义互操作和金融语义建模的官方锚点, 不构成法律、合规、模型验证或供应商选型意见。访问日期按 2026-06-29 记录。

Standards-to-artifacts:

---

1. One-Sentence Positioning / 一句话定位

AI semantic interoperability 的目标不是把企业所有数据都改造成 RDF, 而是让 AI 系统在跨文档、跨图谱、跨 API、跨事件、跨指标和跨评估时使用同一套可治理语义契约。

business meaning
-> stable identifiers
-> RDF graph facts
-> OWL ontology semantics
-> SHACL constraint validation
-> RAG / GraphRAG / tool / event / eval contracts
-> auditable AI behavior

一句话:

Semantic interoperability for AI = 用可交换事实、明确语义和可执行约束, 降低 AI 幻觉、概念混淆、字段错配、指标歧义和审计不可追踪。

金融零售 AI 中最常见的失控点不是模型不会说话, 而是模型把语义边界弄错:

• "customer" 在 CRM、core banking、KYC、merchant acquiring、wealth 里不是同一个对象。
• "approval" 可能是信贷审批、合规批准、经理授权、系统状态或 AI recommendation accepted。
• "high risk" 在 AML、credit、customer vulnerability、cyber fraud、wealth suitability 中语义不同。
• "active account" 在运营指标、监管报送、产品资格和收费规则中口径不同。
• "evidence" 可能是原始交易、政策条款、case note、screening hit、customer document 或 evaluator rationale。

因此, AI Architect / PM / BA 需要交付的不是一个更长 prompt, 而是一个 semantic control plane:

---

2. 为什么 AI 需要 Semantic Interoperability

传统系统集成主要关心 payload 能不能传、字段能不能解析、接口能不能调用。AI 系统还要解决更难的问题: 语义是否一致、证据是否支撑、上下文是否正确、约束是否可验证、输出是否可审计。

2.1 AI 放大语义缺陷的方式

2.2 AI 语义互操作的五个目标

2.3 语义互操作不是单一技术选型

---

3. 核心框架: Semantic Contract Stack

Semantic Contract Stack 用来把标准、领域语言、系统接口和 AI 行为连接成可运行的治理链路。

一句话能力表达:

我能把金融零售 AI 的业务概念、事实图谱、本体语义、约束验证、接口 schema 和评估门禁设计成一套可运行的 semantic contract, 而不是把语义交给模型临场猜测。

---

4. RDF / OWL / SHACL 分工

RDF、OWL、SHACL 经常被混在一起讨论。架构表达中要先划清三者的职责:

RDF answers: what facts and relationships are asserted?
OWL answers: what do those concepts and relationships mean?
SHACL answers: does this graph satisfy the agreed constraints?

4.1 RDF: Graph Facts

RDF 适合表达可交换的事实和关系, 尤其当 AI 需要跨系统追踪 source、evidence、claim、version、permission 和 graph path 时。

RDF 最小落地不一定是部署 triple store。可以先做 RDF-inspired mapping:

4.2 OWL: Ontology Semantics

OWL 适合表达概念、类、关系和可推理语义。它不是普通数据字典, 而是告诉系统 "这些东西在业务上意味着什么"。

OWL 的实际使用要按风险分层:

4.3 SHACL: Constraint Validation

SHACL 适合把语义契约变成可执行验证。它检查的是 RDF data graph 是否满足 shapes graph 中定义的条件。

SHACL 在 AI lifecycle 中可以放在多个门:

---

5. JSON Schema 与 SHACL 的边界

JSON Schema 和 SHACL 都能做 validation, 但它们解决的问题不同。架构评审中要避免把接口结构检查误当成语义正确。

5.1 决策边界

5.2 推荐组合模式

JSON Schema:
  validates message shape, types, required fields, enums, arrays, nested objects

Semantic mapper:
  maps JSON payload fields to canonical concepts and graph objects

SHACL:
  validates graph constraints, relationships, evidence, authority, version, permissions

5.3 示例: AI Tool Input Contract

{
  "$id": "https://example.bank/schemas/tools/create-kyc-remediation-task.json",
  "type": "object",
  "required": ["case_id", "customer_party_id", "task_type", "reason_code", "evidence_claim_id"],
  "properties": {
    "case_id": { "type": "string", "pattern": "^KYC-[0-9]{8}$" },
    "customer_party_id": { "type": "string" },
    "task_type": { "type": "string", "enum": ["request_document", "escalate_review"] },
    "reason_code": { "type": "string", "enum": ["missing_ubo_document", "expired_identity_document", "jurisdiction_exception"] },
    "evidence_claim_id": { "type": "string" }
  },
  "additionalProperties": false
}

JSON Schema 能确认 payload 结构正确, 但不能单独回答:

• customer_party_id 是否属于 case_id 对应的 KYC case。
• 当前用户是否有权为该客户创建 remediation task。
• reason_code 是否由当前有效政策支持。
• evidence_claim_id 是否有 source authority 和 evidence span。
• 该 task 是否越过人工审批边界。

这些应由 semantic mapper、SHACL validation、policy engine 和 audit trace 共同完成。

5.4 示例: SHACL-style Constraint Intent

ex:KYCRemediationTaskShape
  a sh:NodeShape ;
  sh:targetClass ai:KYCRemediationTask ;
  sh:property [
    sh:path ai:belongsToCase ;
    sh:class ai:KYCCase ;
    sh:minCount 1 ;
    sh:maxCount 1 ;
    sh:severity sh:Violation ;
  ] ;
  sh:property [
    sh:path ai:supportedBy ;
    sh:class ai:PolicyClaim ;
    sh:minCount 1 ;
    sh:severity sh:Violation ;
  ] ;
  sh:property [
    sh:path ai:requestedBy ;
    sh:class ai:AuthorizedActor ;
    sh:minCount 1 ;
    sh:severity sh:Violation ;
  ] .

作品集表达:

JSON Schema 保证 AI 工具调用的消息形状正确; SHACL 保证消息背后的业务对象、证据、权限和语义关系正确。高风险金融零售 AI 需要两者组合, 不能只靠 API schema。

---

6. RAG / GraphRAG / Tool / Event / Eval 的语义契约

AI 语义互操作的价值在于让多个 AI 消费面使用同一套 concept identity、source authority、graph facts、constraints 和 audit trace。

6.1 RAG Semantic Contract

RAG 的关键不是 "top-k 更准", 而是 "top-k 中的每条证据是否语义可用"。

6.2 GraphRAG Semantic Contract

6.3 Tool Semantic Contract

6.4 Event Semantic Contract

AI agents 不应只消费 "消息", 而应消费带语义的 domain events。

6.5 Eval Semantic Contract

Eval 不是只给答案打分, 而是验证 AI 是否遵守语义契约。

---

7. 金融零售案例

7.1 KYC / CDD Policy Assistant

高级表达:

KYC assistant 的核心不是把政策 PDF 放进向量库, 而是把客户身份、控制关系、文件要求、政策条款和证据引用建立成可验证语义契约, 防止 AI 把相似术语混成同一个合规义务。

7.2 AML Investigation Graph / GraphRAG

高级表达:

AML GraphRAG 的价值不是展示更复杂的图, 而是让每条风险路径有可解释关系类型、证据来源、时间有效性和人工复核边界。

7.3 Credit Origination Assistant

高级表达:

信贷 AI 的语义互操作要服务于 decision support, 不是 decision automation。它要把政策、申请事实、reason code 和人工决策边界连接起来, 并且让越界行为可测试。

7.4 Customer Servicing / Complaint AI

高级表达:

客服 AI 的风险不是回答不够流畅, 而是把解释、承诺、升级和监管表述混在一起。语义契约要让这些 speech acts 可区分、可限制、可审计。

7.5 AI Value Office / Metrics Semantic Layer

高级表达:

AI Value Office 的指标层必须是语义契约, 不是 dashboard 拼接。否则 AI 会把 adoption、usage、business value 和 risk reduction 混成一套看似合理但不可审计的故事。

---

8. Semantic Governance Operating Model

语义互操作需要治理角色, 不能只靠平台团队维护 ontology 文件。

8.1 RACI

8.2 Semantic Change Control

8.3 Semantic Drift Signals

---

9. Templates / Portfolio Artifacts

下面模板使用具体示例值, 目的是形成作品集证据和架构评审材料, 不是空白表单。

9.1 Semantic Contract Card

# Semantic Contract Card: KYC Beneficial Owner Requirement

## Identity
- Contract ID: semcon:kyc-beneficial-owner-requirement-v1
- Bounded context: KYC / Customer Due Diligence
- Risk tier: High
- Accountable owner: Head of KYC Policy
- Responsible steward: KYC Knowledge Governance Lead
- Architecture owner: AI Knowledge Platform Architect

## Business Meaning
- Approved concept URI: concept:kyc.beneficial_owner
- Approved definition: A natural person who owns, controls, or benefits from a legal entity customer under the active KYC policy threshold and jurisdiction rules.
- Not the same as: authorized signer, relationship manager, primary contact, credit guarantor.
- Source authority: src:kyc-policy-v6-1, src:regulatory-kyc-guidance-us-2026.

## RDF Facts
- Named graph: graph:kyc-prod-2026-06-15
- Core triples:
  - clause:kyc-v6-1-3-4 ai:defines concept:kyc.beneficial_owner
  - claim:kyc-bo-doc-014 ai:supportedBy evidence:kyc-v6-1-p12-r3
  - claim:kyc-bo-doc-014 ai:appliesTo concept:customer.legal_entity

## Ontology Semantics
- Class: ai:BeneficialOwner
- Superclass: ai:ControllingPerson
- Related classes: ai:LegalEntityCustomer, ai:DocumentRequirement, ai:EnhancedDueDiligenceRequirement
- Disjoint classes: ai:AuthorizedSignerOnly, ai:RelationshipManager

## SHACL Constraints
- High-risk KYC claims require source authority A0 or A1.
- Claims require at least one evidence span with source version and effective period.
- Claims must include jurisdiction and customer segment.
- Any claim using retired source status fails release gate.

## AI Consumption
- RAG: allowed for policy explanation with claim-level citation.
- GraphRAG: allowed for ownership/control path explanation when evidence path is present.
- Tool: allowed to create remediation task only after SHACL validation and user entitlement check.
- Eval: included in KYC-BO-001 through KYC-BO-018 regression cases.

## Audit
- Required trace: user role, query, business date, graph version, ontology version, shapes version, source version, retrieved evidence, answer claims.
- Release gate: unsupported high-risk claim count must be 0.

9.2 Ontology Slice

9.3 SHACL Constraint Checklist

9.4 Semantic Drift Log

9.5 Portfolio Evidence Pack

---

10. Architecture Review Questions

10.1 Semantic Scope

• 这个 AI capability 属于哪个 bounded context, 是否存在一词多义风险?
• 哪些概念必须使用 stable URI, 哪些只需要普通 metadata?
• 哪些外部 ontology, 如 FIBO, 适合作为 reference, 哪些必须由内部上下文定义?
• 哪些概念不能跨上下文复用, 必须建立 anti-corruption mapping?

10.2 RDF / Graph Facts

• 哪些事实需要表达成 graph facts, 而不是只存在于文档 chunk 或 JSON payload?
• 每个 claim 是否能追到 source、version、evidence span、permission 和 business date?
• named graph 如何表达 source snapshot、environment、jurisdiction、ontology version 和 constraint version?
• 历史 graph 是否保留到足以支持 audit replay?

10.3 OWL / Ontology Semantics

• 哪些 class 和 property 是 AI 风险关键, 需要显式建模?
• 是否定义了 domain/range、disjointness、subclass 和 restriction?
• 推理结果是 production answer 的依据, 还是 investigation lead?
• ontology 变更会影响哪些 RAG metadata、GraphRAG path、tool contract 和 eval cases?

10.4 SHACL / Validation

• 哪些 constraints 是 release blockers, 哪些只是 warning?
• validation 发生在 ingestion、retrieval、tool execution、event processing 还是 eval 阶段?
• SHACL validation report 是否进入 release evidence 和 audit trace?
• constraint failure 的 owner、SLA、exception process 是否明确?

10.5 JSON Schema Boundary

• JSON Schema 验证的是 payload shape 还是业务语义?
• API payload 字段如何映射到 canonical concept URI?
• 字段名相同但语义不同的情况如何处理?
• Tool call 是否在 JSON Schema 通过后还经过 semantic precondition 和 permission check?

10.6 AI Consumption

• RAG retrieved context 是否通过 authority、version、permission 和 semantic constraints?
• GraphRAG path 是否区分 confirmed fact、weak signal、investigation lead 和 recommendation?
• Event-driven agents 是否只消费 approved domain events?
• Eval 是否覆盖 context confusion、field mismatch、metric ambiguity、unsupported claim 和 audit replay?

---

11. 30-Day Lab: 做一个 Semantic Interoperability Portfolio Case

目标: 30 天内完成一个面向金融零售 AI 的 semantic interoperability 作品集包。推荐选择 KYC Policy Assistant、AML Investigation GraphRAG、Credit Memo Assistant 或 AI Value Office Metrics Assistant。

验收标准:

---

12. 面试表达

12.1 30 秒版本

AI semantic interoperability 是把业务概念、事实、证据、接口和评估统一成可治理语义契约。RDF 负责把事实和关系表达成可交换 graph facts, OWL 负责定义概念和关系的业务语义, SHACL 负责验证这些 graph 是否满足约束。JSON Schema 仍然重要, 但它主要管 API 或 tool payload 的结构; 高风险金融零售 AI 还需要 SHACL 和 ontology 来管证据、权限、版本、上下文和审计。

12.2 2 分钟版本

我会把语义互操作拆成四层。

第一层是 concept identity。金融零售里 "customer"、"risk"、"approval"、"case" 这类词在 AML、信贷、客服、财富里含义不同, 所以要先有 bounded context、concept URI、definition、owner、synonym 和 blocked confusion terms。

第二层是 graph facts。用 RDF-style mapping 把 claim、evidence、source、policy clause、graph path、version、permission 表达出来, 尤其用 named graph 管 source snapshot、effective date、jurisdiction 和 audit replay。

第三层是 ontology semantics。用 OWL-style class、property、domain/range、disjointness 和 restriction 定义业务含义。例如 BeneficialOwner 不是 AuthorizedSignerOnly, AML red flag 不是 credit approval reason。这样 AI 不靠相似文本猜语义。

第四层是 constraint validation。用 SHACL-style shapes 在 ingestion、retrieval、tool execution、event processing 和 eval gate 前做检查。比如 high-risk KYC claim 必须有 A0/A1 source、effective period、jurisdiction、evidence span 和 permission group。缺任何一个都不能进入生产回答。

JSON Schema 我会用于 tool input 和 event payload 的形状验证, 但不会让它替代语义验证。生产级 AI agent 必须先通过 JSON Schema, 再通过 semantic mapper、SHACL、permission 和 policy gate。

12.3 Enterprise Architect 版本

在企业架构视角, semantic interoperability 是 AI control plane 的一部分。它连接业务架构的 bounded context、数据架构的 canonical concepts、应用架构的 API/event/tool contracts、知识架构的 RAG/GraphRAG、治理架构的 eval/release/audit。

我会用 RDF 表达可交换事实和 lineage, 用 OWL 定义核心领域语义和推理边界, 用 SHACL 把语义质量转成可执行门禁, 用 JSON Schema 管接口 payload, 用 FIBO 做金融行业概念参考。落地不是一次性建设全企业 ontology, 而是选择高风险 AI use case 的 ontology slice, 先让 KYC、AML、credit、customer servicing 或 AI metrics 的关键语义可治理、可验证、可审计。

判断标准是: 如果一个 AI capability 无法说明它使用哪些 concept URI、哪些 graph facts、哪些 ontology semantics、哪些 SHACL constraints、哪些 source versions、哪些 eval hard negatives 和哪些 audit trace, 它就不应该进入高风险生产流程。

12.4 高阶追问速答

---

13. 一页总结

AI semantic interoperability 的核心, 是把 "AI 理解业务" 从 prompt 期望升级为可治理工程契约。

作品集表达可以浓缩成一句话:

I design AI semantic contracts with RDF-style facts, OWL-style meaning and SHACL-style validation, so financial retail AI systems can exchange knowledge without confusing concepts, mismatching fields, inventing metrics or losing audit traceability.