AI 扩展计划 / Playbooks

AI Knowledge Governance / Ontology Playbook

这些来源作为知识治理、AI 风险管理和语义建模的官方锚点, 不构成法律、合规、审计或采购意见。

984 行AI_KNOWLEDGE_GOVERNANCE_ONTOLOGY_PLAYBOOK.md

AI Knowledge Governance / Ontology Playbook

面向对象: AI PM / AI Architect / Data Product Manager / AI Governance / 金融零售知识产品负责人。核心问题: 如何把企业政策、SOP、产品规则、调查证据和业务术语治理成可检索、可推理、可评估、可审计的 AI knowledge product。学习目标: 能为 KYC、AML、信贷、客服、监管响应等场景设计知识权威层级、ontology/taxonomy、RAG/GraphRAG 架构、质量 SLO、发布门禁和作品集证据。前提假设: 读者已具备成熟 BA/PM 能力, 本手册不讲需求入门, 只讲 AI 知识治理和产品架构决策。

Source Anchors

这些来源作为知识治理、AI 风险管理和语义建模的官方锚点, 不构成法律、合规、审计或采购意见。

Anchor	Link	在本手册中的用法
NIST AI RMF	https://www.nist.gov/itl/ai-risk-management-framework	用 Govern / Map / Measure / Manage 组织 AI knowledge product 的风险识别、度量、控制和持续治理
NIST AI 600-1 GenAI Profile	https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence	用于 GenAI 特有风险: hallucination、data leakage、prompt injection、synthetic content、evaluation、misuse
ISO/IEC 42001	https://www.iso.org/standard/42001	用 AI management system 视角设计责任、流程、变更、监控、持续改进和管理评审
W3C RDF 1.1 Concepts	https://www.w3.org/TR/rdf11-concepts/	用 triple、IRI、literal、RDF graph、named graph 思考可交换的知识表达和证据图谱
W3C OWL 2 Overview	https://www.w3.org/TR/owl2-overview/	用 ontology、class、property、restriction、reasoning 思考严格语义、约束和一致性检查
W3C SKOS Primer	https://www.w3.org/TR/skos-primer/	用 concept scheme、prefLabel、altLabel、broader、narrower、related 管理业务词表、分类和同义词
W3C DCAT 3	https://www.w3.org/TR/vocab-dcat-3/	用 catalog、dataset、distribution、data service、access rights、versioning 描述知识资产目录、版本和分发方式

1. 定位: 从文档库到 AI Knowledge Product

企业 AI 项目失败时, 团队常把问题归因于模型能力, 但金融零售场景里更常见的根因是知识没有产品化:

权威来源不清, 政策、FAQ、培训材料、分行口径互相冲突。
文档有版本, 但检索结果没有 effective date、expiry date、approval status。
向量库能搜到相似文本, 但无法证明引用是否支撑回答中的关键断言。
业务词表、产品代码、风险类型、地区规则没有统一语义, 导致召回和评估切片失真。
知识 owner、steward、reviewer、incident responder 不清, 上线后没人维护。
评测集只测“答案像不像”, 不测权限、版本、证据链、冲突处理和拒答。

本手册的核心观点:

AI knowledge is production-ready only when it is authoritative, modeled, permissioned, versioned, measurable, traceable and owned.

AI PM / AI Architect 在这里要交付的不是“一个知识库”, 而是一套可运行的知识产品能力:

能力	低成熟度表达	高成熟度表达
Source	上传 PDF 到向量库	Source authority hierarchy + owner + effective period + approval workflow
Semantics	用文件夹分类	Taxonomy / ontology / entity-relation-claim model
Retrieval	top-k 相似度	Hybrid retrieval + metadata filter + rerank + permission + version tests
Graph	看到 GraphRAG 就上图谱	用多跳关系、冲突解释、证据路径和实体解析证明图谱必要性
Quality	人工试几个问题	Knowledge quality SLO + golden set + release gate + incident trend
Governance	合规上线前看一次	RACI + change control + audit lineage + quarterly capability review
Portfolio	展示聊天 UI	展示 knowledge source registry、ontology ADR、eval report、release memo、incident playbook

2. Advanced Framework: KGov-7

KGov-7 是本手册的主框架, 适合用来做 AI knowledge governance 方案、架构评审和作品集目录。

层	核心问题	关键决策	核心产物
1. Knowledge Domain	哪个业务知识域值得产品化	先做 KYC、AML、信贷、客服还是监管响应	Knowledge Product Canvas
2. Authority	冲突发生时信谁	source authority hierarchy、owner、approval status	Source Registry + Authority Matrix
3. Semantics	知识如何被机器理解	taxonomy、ontology、property graph、RDF graph 的边界	Ontology ADR + Concept Scheme
4. Ingestion	文档如何进入可用状态	OCR、chunking、metadata、PII、permission、version	Ingestion Control Checklist
5. Retrieval / Reasoning	如何找到、组合和解释证据	RAG、GraphRAG、hybrid search、rules、reasoner	AI Pattern ADR + Retrieval Eval Matrix
6. Evaluation	如何证明可上线	SLO、golden set、claim-level citation、权限测试	Eval Report + Release Gate Memo
7. Operations	上线后如何维护	stewardship、change control、incident、review cadence	RACI + Runbook + Quarterly Review

一句话能力表达:

我能把一个金融零售知识域从 source inventory 建模到 ontology、RAG/GraphRAG、eval gate、release control 和 incident operations, 并沉淀成可审计作品集。

3. Knowledge Product Lifecycle

知识产品生命周期不是文档管理流程, 而是 AI 消费视角下的端到端治理链路。

阶段	决策问题	必备控制	退出标准	作品集证据
Domain selection	这个知识域是否适合 AI 产品化	价值、风险、用户、流程插入点、no-AI alternative	有明确 owner、用户角色、业务指标和风险边界	Opportunity Canvas
Source inventory	哪些来源进入范围	source-of-truth、authoritative copy、draft exclusion、retention	每个 source 有 owner、class、权限、版本字段	Knowledge Source Registry
Authority design	来源冲突如何处理	authority rank、conflict rule、approval status、effective date	冲突测试有预期行为	Authority Matrix
Semantic modeling	如何统一概念、实体和关系	taxonomy、ontology、entity resolution、claim model	核心概念、关系和断言类型可被评审	Ontology / Taxonomy ADR
Ingestion hardening	文档如何转成可靠知识	OCR QA、table preservation、chunk ID、lineage、PII tagging	ingestion gate 通过, 不合格来源不入生产 index	Ingestion Report
Retrieval architecture	用 RAG 还是 GraphRAG	query types、multi-hop need、metadata filter、permissions	retrieval eval 达到 gate 阈值	Retrieval Eval Matrix
Answer governance	模型如何输出可信答案	claim extraction、citation support、refusal、conflict disclosure	高风险 critical claim 有证据支持	Answer Quality Report
Release	是否允许 pilot / production	SLO、incident plan、RACI、rollback、audit replay	release gate 明确 go / limited / no-go	Release Gate Memo
Operations	知识如何持续有效	freshness monitor、change log、steward review、incident workflow	月度质量趋势和变更复盘稳定	Quarterly Review Pack
Retirement	何时下线或替换知识	expiry、deprecation、archival、index purge	过期知识不再被检索、引用或缓存	Retirement Log

关键原则:

向量库不是 source of truth, 只能是消费层索引。
文档可用不等于 AI 可用, 还要可定位、可验证、可授权、可过期、可回放。
ontology 不是画给专家看的图, 而是检索、推理、权限、评估和审计的共同语言。
每个上线版本都要能回答: 当时用了哪些来源、哪些版本、哪些权限、哪些 prompt、哪些模型、哪些评测结果。

4. Source Authority Hierarchy

金融零售 AI 知识系统必须先定义 source authority hierarchy。否则当政策、SOP、FAQ、培训材料和历史工单冲突时, 模型会把“相似”误当“正确”。

4.1 Authority Levels

Level	来源类型	示例	AI 使用边界	冲突处理
A0 External binding authority	监管规则、正式监管函、法院/仲裁约束性材料	AML 法规、KYC 监管指引、消费者保护监管要求	作为最高外部约束和解释边界, 需要合规确认	与内部政策冲突时升级 Risk/Compliance
A1 Internal approved policy	经批准的企业政策、制度、产品条款	KYC Policy v6.1、Credit Risk Policy、Fee Policy	可作为高风险回答的 primary evidence	覆盖 SOP、FAQ、培训材料
A2 Approved procedure / SOP	正式发布的操作手册、流程、控制清单	Branch KYC SOP、Customer Service Refund SOP	用于操作步骤、例外流程、人工升级	不得推翻 A1 政策
A3 System of record	业务系统事实记录	Core banking ledger、CRM master、case management	用于客户、账户、交易、case 状态事实	与文档冲突时按事实类型决定
A4 Product / training knowledge	培训材料、产品说明、内部 FAQ	New credit card training deck、agent FAQ	用于解释、话术和低风险引导	不可作为高风险政策依据
A5 Operational notes	工单、会议纪要、分行经验、analyst notes	Case note、implementation memo	用于背景、案例和候选知识	需要 steward 审核后才能提升权威
A6 External reference	行业报告、供应商文档、公开网页	Vendor guide、industry article	用于背景学习或 vendor 功能说明	不得替代内部政策和合规解释

4.2 Conflict Rules

冲突类型	例子	系统预期行为	人工责任
新旧版本冲突	KYC Policy v5.4 与 v6.1 同时命中	根据 query business date 和 effective period 选择版本, 并引用版本号	Knowledge Owner 维护 effective / expiry
政策 vs SOP	SOP 步骤没有覆盖新政策限制	回答政策约束, 标记 SOP 可能过期, 升级流程 owner	Process Owner 更新 SOP
总部 vs 地区	总部政策和州/国家地区规则不同	根据 jurisdiction filter 返回适用规则, 不跨地区引用	Compliance 维护 jurisdiction mapping
FAQ vs 条款	FAQ 简化说明与产品条款不一致	高风险问题引用条款, FAQ 只作辅助解释	Product Owner 修正 FAQ
系统事实 vs 文档说明	客户状态已变更, SOP 仍描述旧状态	对事实类问题以 system of record 为准, 对规则类问题以政策为准	Data Owner 保障事实同步
调查证据冲突	AML case 中交易证据与 analyst note 不一致	展示冲突证据路径, 不做最终判断	AML Analyst 复核

5. Taxonomy vs Ontology vs Knowledge Graph

5.1 决策边界

资产	解决的问题	不适合解决的问题	金融零售例子	作品集表达
Taxonomy	分类、标签、导航、权限过滤、统计切片	复杂关系推理和一致性检查	风险类型、客户类型、产品线、文档类型	Taxonomy tree + tag governance
Controlled vocabulary	同义词、缩写、业务别名、搜索召回	复杂业务规则	UBO / beneficial owner / 最终受益人	SKOS concept scheme
Ontology	概念、实体、关系、约束、业务语义一致性	快速一次性 FAQ demo	Customer、Account、BeneficialOwner、Case、PolicyClause 关系	Ontology ADR + class/property catalog
Knowledge graph	实体和关系实例化, 支持路径、邻居、社区、证据解释	纯文档问答、低风险 FAQ	AML entity network、merchant risk network	Graph schema + evidence path examples
RDF graph	标准化语义交换、named graph、IRI、跨系统互操作	团队只会 property graph 且无互操作需求	policy clause、claim、evidence span、source metadata	RDF mapping profile
Property graph	工程落地快, 适合查询路径和运营图谱	需要标准语义推理和跨机构交换	Neo4j AML investigation graph	Cypher query + graph screen
OWL ontology	严格语义、class/property 约束、reasoning、一致性	规则频繁变化且团队无 ontology 运维能力	高风险客户定义、控制义务、产品资格约束	OWL profile decision memo

5.2 选择路径

场景	推荐路径	判断理由
客服 SOP 助手	Taxonomy + SKOS vocabulary + RAG	核心是术语召回、版本过滤、引用和拒答, 不需要复杂图推理
信贷政策助手	Taxonomy + lightweight ontology + RAG + rules	需要客户类型、产品、地区、阈值、例外关系, 但最终决策仍由规则和人工
AML 调查图谱	Ontology + knowledge graph + GraphRAG	需要客户、账户、设备、商户、交易、名单、case 之间的多跳关系和证据路径
KYC 政策助手	SKOS + policy clause ontology + RAG	需要同义词、文档版本、条款引用、地区适用性和冲突提示
监管响应知识库	DCAT catalog + ontology + evidence lineage	需要材料目录、来源、版本、责任人、审计证据和复用

5.3 反模式

反模式	为什么危险	更好的做法
把文件夹目录当 taxonomy	目录反映存放习惯, 不一定反映业务概念	建立业务概念 scheme, 文档只作为资源挂载
把所有边都放进图谱	图变成杂乱事实堆, 查询和审计困难	只建与决策、检索、证据和风险相关的关系
用 embedding 代替同义词治理	相似度无法表达权威术语、禁用词和地区语义	用 SKOS 管理 prefLabel / altLabel / hiddenLabel
用 LLM 生成 ontology 后直接上线	概念边界未经过 domain owner 验证	LLM 草拟, steward 评审, eval 验证
用 GraphRAG 掩盖文档治理问题	图谱无法修复过期、无权、冲突来源	先做 source authority 和 metadata gate

6. RDF / OWL / SKOS / DCAT Mapping

标准不是为了“显得先进”, 而是让知识资产可交换、可审计、可治理。落地时可以采用完整 RDF/OWL, 也可以先用这些标准作为 conceptual mapping, 再映射到关系库、搜索索引或 property graph。

标准	核心能力	在 AI 知识治理中的映射	最小落地方式
RDF 1.1	用 subject-predicate-object 表达 graph data model	将 `PolicyClause -> appliesTo -> CustomerSegment`、`Claim -> supportedBy -> EvidenceSpan` 表达为可追踪关系	为实体、文档、条款、断言、证据分配稳定 URI/ID
RDF named graph	支持多个图和来源上下文	用 named graph 表示不同 source、版本、jurisdiction、approval status	每批 ingestion 生成 graph_id / source_version_id
OWL 2	表达 class、property、restriction 和语义约束	定义 `HighRiskCustomer`、`BeneficialOwner`、`KYCRequirement`、`requiresDocument` 等概念及约束	先维护 class/property catalog 和禁止冲突规则
SKOS	管理 concept scheme、标签、同义词、层级和相关概念	管理业务词表: KYC、CDD、EDD、UBO、merchant risk、complaint type	每个概念有 prefLabel、altLabel、definition、owner
DCAT 3	描述 catalog、dataset、distribution、data service、access rights、versioning	建立 knowledge source catalog, 描述文档集、数据集、API、索引、权限、版本	Source Registry 字段对齐 DCAT metadata

6.1 Standards-to-Artifact Mapping

作品集资产	可借鉴标准	必备字段
Knowledge Source Registry	DCAT	title、identifier、publisher、owner、access rights、release date、modified date、version、status、distribution
Concept Scheme	SKOS	concept_id、prefLabel、altLabel、hiddenLabel、definition、broader、narrower、related、owner
Ontology Catalog	OWL	class、property、domain、range、cardinality、constraint、disjointness、example
Evidence Graph	RDF	subject、predicate、object、source_id、graph_id、valid_time、asserted_by
Claim Contract	RDF + application ontology	claim_id、claim_type、normalized_predicate、evidence_span、support_status、permission_group
Source Version Chain	DCAT + provenance metadata	previous_version、current_version、replaces、effective_date、expiry_date、change_note

6.2 Practical URI / ID Strategy

对象	示例 ID	设计要求
Knowledge source	`src:kyc-policy-v6-1`	稳定、可版本化、可映射到文档管理系统
Policy clause	`clause:kyc-v6-1-3-4-non-resident-entity`	精确到可引用粒度, 支持 citation
Concept	`concept:beneficial-owner`	不随语言变化, label 可多语言
Entity instance	`customer:internal-12345`	不在日志和作品集中暴露真实 PII
Claim	`claim:kyc-doc-required-2026-014`	可绑定证据、版本、权限、审核状态
Graph version	`graph:kyc-prod-2026-06-15`	支持 audit replay 和 rollback

7. Entity / Relation / Claim Model

RAG 只处理“文本片段”会遇到三个限制:

无法稳定区分文档、条款、事实、解释和建议。
无法表达“这个断言由哪个证据支持, 在什么时间、地区、角色下有效”。
无法把用户反馈、事故和评测回流到具体知识单元。

因此高级知识治理要把 claim 作为一等对象。

7.1 Core Entities

Entity	说明	关键字段	金融零售例子
Source	权威来源资产	source_id、authority_level、owner、approval_status、version	KYC Policy v6.1
Document	具体文档或页面	doc_id、source_id、format、language、distribution	PDF、HTML、SharePoint page
Section / Clause	可引用条款	clause_id、heading、page、paragraph、effective_date	`3.4 Non-resident Entity`
Concept	业务概念	concept_id、prefLabel、altLabel、definition	Beneficial owner、EDD、MSB
Entity Instance	业务实体实例	entity_id、entity_type、source_system、permission_group	customer、merchant、account、case
Relation	实体之间的关系	subject、predicate、object、valid_time、source	customer owns account
Claim	可验证断言	claim_id、claim_type、statement、support_status、validity	“非居民企业需额外提交税务居住证明”
Evidence Span	支撑 claim 的证据片段	evidence_id、doc_id、clause_id、offset/page/table_row	第 12 页第 3 段
Decision / Recommendation	AI 或人工建议	decision_id、basis_claims、human_review_status	AML case escalation recommendation
Control	治理或业务控制	control_id、control_type、owner、test_method	Permission filter, citation validator

7.2 Relation Catalog

Relation	Domain -> Range	用途	示例
`defines`	Source / Clause -> Concept	术语定义和引用	KYC Policy defines BeneficialOwner
`appliesTo`	Clause / Claim -> Segment / Jurisdiction / Product	适用性过滤	Clause appliesTo NonResidentEntity
`requires`	Policy / Procedure -> Document / Action / Control	缺件、流程和控制	EDD requires SourceOfFundsDocument
`overrides`	Source / Clause -> Source / Clause	权威冲突处理	Policy v6.1 overrides v5.4
`supportedBy`	Claim -> Evidence Span	claim-level citation	Claim supportedBy clause 3.4
`contradicts`	Claim -> Claim	冲突提示和 steward review	FAQ claim contradicts policy claim
`derivedFrom`	Claim / Entity -> Source / Record	lineage	Risk score derivedFrom transaction pattern
`visibleTo`	Source / Evidence / Claim -> Role / Entitlement	权限控制	Investigation note visibleTo AMLAnalyst
`validDuring`	Claim / Relation -> Time Period	版本和生效期	Claim validDuring 2026-01-01 to 2026-12-31
`reviewedBy`	Claim / Source -> Steward / SME	知识审核	KYC steward reviewed claim

7.3 Claim Types

Claim type	用途	需要的证据强度	示例
Policy claim	政策义务、限制、资格、阈值	A0 / A1 primary evidence	“高风险客户必须执行 EDD”
Procedure claim	操作步骤、人工升级、系统路径	A2 primary evidence	“缺少 UBO 文件时创建 remediation task”
Fact claim	客户、账户、交易、case 状态	A3 system-of-record evidence	“Case C-2026-008 已分配给 analyst team A”
Interpretation claim	对证据的解释或风险叙述	多来源证据 + human review	“该商户行为符合 structuring typology”
Recommendation claim	建议动作	policy + facts + HITL status	“建议升级 EDD review”
Refusal claim	不回答或升级人工的理由	policy / permission / missing evidence	“当前角色无权查看调查细节”

7.4 Claim Contract

字段	填写要求	示例
claim_id	全局唯一, 可回放	`claim:kyc-nre-tax-doc-2026-001`
claim_type	policy / procedure / fact / interpretation / recommendation / refusal	`policy`
statement	面向用户的自然语言断言	非居民企业开户需提供税务居住证明或等效文件。
normalized_predicate	机器可评估谓词	`requiresDocument(NonResidentEntity, TaxResidencyEvidence)`
source_authority	最高支撑来源等级	`A1`
evidence_ids	支撑证据片段	`evidence:kyc-v6-1-p12-para3`
effective_period	生效期间	`2026-01-01/2026-12-31`
jurisdiction	适用地区	`US`
permission_group	可见角色	`kyc-analyst, compliance-reviewer`
support_status	supported / partially_supported / contradicted / unsupported	`supported`
reviewer	业务或知识 steward	`KYC Policy Steward`
last_reviewed_at	最近审核日期	`2026-06-15`

8. Knowledge Ownership / Stewardship

AI 知识治理需要明确 owner, 但 owner 不是一个人包办所有责任。高成熟组织会把 business ownership、knowledge stewardship、data ownership、architecture ownership、risk oversight 拆开。

8.1 Roles

Role	核心责任	典型交付物
AI Product Owner	价值、范围、路线图、用户采纳、release decision	Product roadmap、release memo、adoption dashboard
Knowledge Product Owner	知识域价值、权威来源、内容优先级、业务冲突决策	Knowledge Product Canvas、authority matrix
Knowledge Steward	术语、条款、claim、版本、审核和修复	Concept scheme、claim review queue、change log
Domain SME	专业正确性和边界场景复核	Golden set review、expert adjudication
Data Owner	系统事实、数据质量、retention、lineage	Data contract、quality SLO dashboard
AI Architect	架构、集成、权限、索引、可观测、回滚	C4、data flow、ADR、control design
EvalOps Owner	golden set、eval runner、release gate、质量趋势	Eval report、regression suite
Risk / Compliance	风险分类、控制要求、审计证据、人类监督	Risk register、control attestation
Security / Privacy	IAM、PII、日志、供应商、访问审计	Permission model、privacy review
Operations Lead	日常流程运行、用户反馈、培训、incident intake	Runbook、feedback dashboard

8.2 RACI for Knowledge Change

Activity	Product	Knowledge Owner	Steward	SME	Architect	EvalOps	Risk	Security
新来源纳入	A	R	R	C	C	C	C	C
权威等级确认	C	A/R	R	C	I	I	C	I
taxonomy / ontology 变更	C	A	R	R	C	C	I	I
ingestion 发布	I	C	R	C	A/R	R	C	C
权限标签变更	I	C	R	I	R	C	C	A/R
golden set 更新	C	C	R	R	I	A/R	C	I
release gate 决策	A/R	C	C	C	R	R	C	C
事故定级和遏制	A	C	R	C	R	R	A/R	C

9. Version / Freshness / Permissions

9.1 Version Model

对象	版本字段	控制要求
Source	source_version、approval_status、published_at	只有 approved 版本进入 production retrieval
Clause	clause_version、effective_date、expiry_date	回答必须按 business date 选择有效条款
Concept	concept_version、definition_change_type	概念定义变化触发 retrieval 和 eval 回归
Ontology	ontology_version、breaking_change	class/property 破坏性变更需要 architecture gate
Index	index_version、embedding_model、chunking_strategy	可回放每次回答使用的 index
Prompt	prompt_version、policy_instructions	prompt 变更触发 regression eval
Model	model_id、provider_version、deployment	模型变更记录在 release memo
Eval set	eval_set_version、scenario_coverage	release gate 使用固定版本

9.2 Freshness Controls

知识类型	Freshness SLO	Breach action
KYC / AML policy	已发布变更 24 小时内进入 approved index	高风险查询显示 stale warning, 超过阈值停用相关 route
Credit policy	当日发布当日回归测试	未通过 regression 不允许用于生产建议
Customer service SOP	48 小时内更新 searchable SOP	允许低风险 FAQ 继续, 涉及费用/承诺升级人工
System facts	P95 同步延迟小于 30 分钟	超过阈值不生成事实性断言
Regulator response evidence	每次材料变更后生成 lineage snapshot	未生成 snapshot 不纳入审计包

9.3 Permission Model

权限不能只控制文档下载, 还要控制 retrieval、prompt context、citation、logs、eval、feedback 和 cache。

层	必控点	失败后果
Source access	用户是否可访问原文	引用链接泄露
Retrieval entitlement	chunk 是否能被召回	无权知识进入 context
Context packing	最终 prompt 是否含无权内容	模型输出泄露
Citation rendering	用户是否可打开引用	答案安全但证据泄露
Logs and traces	prompt、context、output 是否脱敏	日志成为影子数据库
Eval samples	生产样本是否可用于评测	PII / restricted info 外泄
Cache	不同角色是否隔离缓存	低权限用户读取高权限答案
Feedback	用户纠错是否保留敏感信息	反馈池污染和合规风险

权限测试必须纳入 release gate:

测试	设计方式	通过标准
same query, different role	分别用 branch staff、KYC analyst、compliance reviewer 查询	返回内容和引用符合角色权限
denied citation test	低权限用户问高权限问题	拒答或升级, 不返回证据标题、摘要或链接
cache isolation test	高权限查询后低权限重复查询	低权限结果不复用高权限 context
audit replay test	回放历史答案	能还原 user role、source version、index、prompt、model

10. RAG and GraphRAG Fit

RAG 和 GraphRAG 是知识消费模式, 不是治理替代品。架构决策应从 query pattern、证据结构、风险等级和可解释性要求出发。

10.1 Pattern Decision Matrix

需求	Prefer	Avoid	决策理由
单文档政策解释、引用和拒答	RAG + metadata filter + citation validator	GraphRAG-first	主要挑战是权威、版本和引用, 不是多跳关系
多文档冲突和适用性判断	RAG + ontology metadata + conflict detector	纯向量 top-k	需要 jurisdiction、effective date、authority rank
多实体调查路径	GraphRAG + evidence retrieval + HITL	long-context 文档塞入	需要解释客户、账户、设备、交易、名单、case 的关系
SOP 步骤导航	RAG + workflow state + rules	LLM 自由编排流程	流程步骤需要确定性控制和人工升级
信贷政策资格判断	RAG + rules engine + human review	让 LLM 直接做 credit decision	高风险决策必须由可审计规则、模型和人工控制
监管材料检索	DCAT catalog + RAG + lineage	只做聊天问答	审计需要材料目录、版本、责任人和证据链

10.2 GraphRAG Justification Checklist

只有当至少满足下列多个条件时, GraphRAG 才是强选项:

条件	具体判断
多跳必要	单个答案需要跨 customer、account、merchant、device、transaction、case 等多类实体
关系是证据	关系路径本身是风险解释或调查依据
entity resolution 是核心	同一客户、商户、设备、地址、UBO 的合并影响结论
需要社区或模式摘要	AML typology、merchant ring、fraud network 需要群体结构
文档检索无法表达路径	chunk 召回能给材料, 但无法解释关系链
审计要求路径可回放	analyst 要看到为什么某条路径支持风险 narrative

10.3 RAG / GraphRAG Hybrid Architecture

Knowledge sources
  -> Source registry / authority / permissions
  -> Ingestion pipeline
      -> Document store + chunk index
      -> Concept scheme / ontology registry
      -> Entity resolution + relationship extraction
      -> Knowledge graph
  -> Retrieval orchestration
      -> query classification
      -> metadata filter
      -> vector / lexical retrieval
      -> graph neighborhood / path retrieval
      -> rerank and context packing
  -> Answer governance
      -> claim extraction
      -> citation support
      -> conflict / stale / permission checks
      -> human review route
  -> EvalOps and audit
      -> golden set
      -> quality SLO
      -> lineage replay
      -> incident learning

11. Policy / SOP / Document Ingestion Controls

高质量 ingestion 不是“把 PDF 切 chunk”。它要把 source authority、结构、语义、权限、版本、证据定位和评估需求一起带入索引。

11.1 Pre-Ingestion Gate

Check	通过标准	阻断条件
Source approval	source 已被 owner 标记为 approved / production-eligible	草稿、过期、来源不明
Authority level	A0-A6 等级明确	冲突时无法决定信谁
Owner and steward	owner、steward、review cadence 明确	上线后无人维护
Effective period	effective / expiry / jurisdiction 明确	版本无法过滤
Permission class	role、entitlement、PII class 明确	无法做 retrieval permission
Format quality	OCR、表格、页码、标题结构可解析	表格错位、扫描质量差
Retention	retention 和 deletion rule 明确	过期知识无法清理
Usage boundary	可用于 RAG / eval / training / analytics 的边界明确	知识用途扩散

11.2 Ingestion Pipeline Controls

Step	控制点	输出
Parsing	保留标题层级、页码、表格行列、脚注、附件	structured document tree
Normalization	统一日期、产品代码、地区、部门、术语	normalized metadata
Chunking	section-aware chunk, parent-child, table-preserving	chunk_id + parent_id
Metadata enrichment	authority、permission、version、jurisdiction、doc_type	retrieval filter fields
Concept tagging	SKOS concept、synonym、product、risk type	concept tags
Entity extraction	customer、merchant、policy、control、case 等实体	entity candidates
Claim extraction	从条款中抽取 policy / procedure claim	claim registry
Validation	sample QA、hard negative、permission tests	ingestion QA report
Index publish	生成 index_version 和 lineage snapshot	production index manifest

11.3 Ingestion Acceptance Metrics

Metric	Target	说明
OCR critical table accuracy	>= 99% sampled pass	费率、阈值、文件清单、风险矩阵不能错行
Section anchor coverage	>= 98%	引用必须能定位到 section/page/paragraph/table row
Required metadata completeness	100% for production sources	authority、owner、version、permission、effective date
Duplicate / near-duplicate review	100% high-similarity reviewed	防止旧政策和新政策同时有效
Permission tagging pass	100% critical source sampled pass	高风险来源不可缺权限标签
Claim extraction review	>= 95% supported for critical claims	关键政策断言必须可证据化

12. Knowledge Quality SLOs

AI knowledge quality SLO 要覆盖 source、semantics、retrieval、answer、operations。单看 answer accuracy 不够。

SLO	定义	建议目标	Breach action
Source freshness	生产 index 中知识与 approved source 的延迟	P95 小于 24-48 小时, 按场景调整	stale warning、route downgrade、owner alert
Authority correctness	高风险回答引用最高适用权威来源	critical sample 100%	release no-go, 修复 authority matrix
Retrieval recall	gold evidence 是否进入候选	recall@10 >= 90% for core scenarios	调整 metadata、hybrid search、synonym
Context precision	最终 context 中相关且有权且有效的证据比例	>= 85%, critical permission 100%	优化 rerank、filter、context packing
Citation support	关键断言被引用证据支持	critical claim 100%, ordinary claim >= 95%	加 citation validator 和 claim review
Version correctness	query business date 选择正确版本	100% sampled pass	停止受影响 source route
Permission correctness	检索、context、citation、cache 均按权限	100%	立即 incident, 关闭 route
Conflict detection	已知冲突能被识别并提示	>= 95% risk set pass	增加 conflict rules 和 steward review
Refusal quality	无答案、无权限、低证据问题正确拒答	>= 95%	更新 refusal policy 和 query classifier
Audit replay	历史答案可重放 source/index/prompt/model	100% release sample	补 lineage 或禁止生产

SLO 的作品集表达不应只展示数字, 还要展示:

样本来源和覆盖范围。
失败分级和业务影响。
release decision 如何被指标驱动。
失败如何进入 backlog、golden set 和 incident runbook。

13. Evidence Lineage

Evidence lineage 要能从最终答案追溯到:

User question
  -> user role / entitlement / business date
  -> query rewrite / classifier
  -> retrieval filters
  -> candidate chunks / graph paths
  -> selected context
  -> answer claims
  -> citations / evidence spans
  -> source versions
  -> owner review / release gate

13.1 Minimum Audit Record

字段	说明
interaction_id	单次问答或 workflow 的唯一 ID
user_role	不记录不必要个人身份, 但记录权限角色
business_date	适用政策日期
query_text_hash	敏感场景使用 hash 或脱敏文本
query_intent	policy question、procedure question、fact lookup、investigation narrative
retrieval_filters	authority、jurisdiction、permission、effective date
candidate_ids	初召回证据 ID
selected_context_ids	进入 prompt 的证据 ID
graph_path_ids	GraphRAG 使用的实体和关系路径
answer_claim_ids	输出中的关键断言
citation_ids	每个 claim 对应证据
model_prompt_index_versions	model、prompt、index、ontology、eval set 版本
safety_decision	answered、refused、escalated、limited answer
human_review_status	not_required、pending、approved、rejected

13.2 Claim-Level Citation Rule

断言类别	Citation 要求	示例
金额、阈值、日期	必须 evidence-span citation	手续费、贷款期限、EDD 阈值
资格条件	必须政策条款 citation	信贷申请资格、开户资格
操作步骤	必须 SOP section citation	客服退款流程
风险解释	必须多证据 citation + human review	AML suspicious pattern narrative
一般解释	paragraph-level citation	产品概念和流程说明
拒答	citation 可选, 但必须记录 refusal reason	无权限、无证据、冲突未解决

14. Release Gates

14.1 Gate Overview

Gate	核心问题	Go 条件	No-Go 条件
G0 Domain Gate	知识域是否值得做	有明确业务结果、owner、用户、风险边界	只有技术 demo, 无业务 owner
G1 Authority Gate	来源是否权威可用	source registry、authority matrix、conflict rules 完成	草稿/过期/无 owner 来源进入范围
G2 Semantic Gate	语义是否足够	taxonomy / ontology / claim model 覆盖核心 query	术语冲突、关系不清、claim 无证据
G3 Ingestion Gate	文档是否可被 AI 消费	metadata、permission、version、chunk QA 通过	表格错位、权限缺失、版本缺失
G4 Retrieval Gate	系统能否找到正确证据	recall、context precision、hard-negative 测试达标	gold evidence 找不到或旧政策排前
G5 Answer Gate	输出是否可引用可拒答	citation support、faithfulness、refusal、conflict 测试达标	unsupported critical claim
G6 Risk Gate	生产风险是否可控	RACI、runbook、audit replay、rollback 完成	权限泄漏、无 incident owner
G7 Pilot / Release Gate	是否进入试点或生产	limited user group、monitoring、feedback loop	无质量 dashboard 或无人工升级路径
G8 Scale Gate	是否扩大范围	质量趋势稳定, ROI 和 adoption 证明有效	incident 趋势恶化或知识维护不可持续

14.2 Release Gate Memo Template

Section	填写要求	示例表达
Use case	业务场景、用户、风险等级	KYC policy assistant for KYC analyst, regulated internal decision support
Knowledge scope	包含和排除的来源	包含 approved KYC policies and SOP, 排除 draft training decks
Authority decision	最高权威和冲突规则	A1 policy overrides FAQ; jurisdiction-specific rules override global SOP
Semantic scope	taxonomy / ontology / graph 范围	SKOS terms for KYC docs; clause ontology for applicability
Eval summary	样本、指标、失败	240-query golden set; permission tests 100% pass; 7 low-risk synonym failures fixed
Risk controls	权限、引用、拒答、HITL	high-risk claims require claim-level citation; conflict escalates to compliance
Operational readiness	owner、runbook、monitoring	knowledge steward weekly review; stale source alert daily
Decision	go / limited go / no-go	limited go for 25 analysts, no customer-facing use
Conditions	上线条件和复核时间	monthly gate review; no auto decisioning

15. Incident Patterns

Pattern	触发信号	可能根因	Immediate containment	Corrective action
Stale policy answer	引用过期政策或旧 SOP	effective date 缺失, index 未刷新	停用 affected source route, 显示 stale warning	修复 version metadata, 加 freshness SLO alert
Unsupported claim	答案中关键断言无证据	prompt 过强, context 不足, model hallucination	禁用相关 answer template, 升级人工	加 claim validator, failure 入 golden set
Wrong citation	引用存在但不支持断言	citation 粒度太粗, rerank 错误	回退到 paragraph-level 或拒答	claim-level citation eval
Permission leakage	无权用户看到高权限内容	retrieval filter、cache、citation entitlement 缺陷	关闭 route, 保存审计日志, 通知 Security/Risk	修复 entitlement, 增加角色回归测试
Conflict not detected	FAQ 与政策冲突但系统直接回答	authority matrix 不完整	受影响主题改为人工确认	增加 `contradicts` 关系和 conflict rules
Ontology drift	新产品/政策概念未入词表	steward cadence 不足	用 fallback RAG 回答并提示范围限制	每月 concept review, change impact eval
Graph relation error	AML 路径连接错误实体	entity resolution false positive	隐藏 graph explanation, analyst review	调整 matching threshold, 加人工确认
Table extraction error	阈值、费率、文件清单错位	OCR/table parser 失败	停用受影响表格引用	table QA gate, 保留结构化表格
Prompt injection via document	文档中的指令影响模型	未隔离 evidence 与 instruction	禁用 source, 安全复核	content sanitization, instruction hierarchy
Eval blind spot	生产失败未被 gate 捕获	golden set 覆盖不足	事故样本进入 regression set	更新 scenario taxonomy 和 release criteria

16. Architecture / Product Mapping

Component	Product decision	Architecture decision	Governance evidence
Knowledge Source Registry	哪些知识进入产品范围	registry schema、DCAT mapping、owner workflow	source inventory、authority matrix
Taxonomy / Concept Service	用户和系统如何统一术语	SKOS store、synonym API、concept versioning	concept scheme、change log
Ontology Registry	哪些实体、关系和约束被正式采用	OWL / property graph schema / application ontology	ontology ADR、class/property catalog
Ingestion Pipeline	来源如何变成可消费知识	parsers、chunking、metadata enrichment、QA gates	ingestion report、index manifest
Permission Engine	谁能检索和引用什么	RBAC/ABAC、entitlement filter、cache isolation	permission model、test report
Retrieval Orchestrator	RAG、GraphRAG、rules 如何组合	query classifier、hybrid search、graph path retrieval、rerank	retrieval eval matrix
Answer Governance Layer	如何生成、拒答、引用、升级	claim extraction、citation validator、conflict detector	answer quality report
EvalOps Platform	如何做回归和 release gate	golden set、judge、expert review、SLO dashboard	eval report、release memo
Audit / Lineage Store	如何回放每次回答	trace schema、source/index/prompt/model versioning	audit replay sample
Stewardship Console	谁维护知识和修复事故	review queue、approval workflow、incident queue	RACI、runbook、quarterly review

16.1 C4-Level Boundary

Layer	内容	关键边界
Context	AI knowledge capability 服务 KYC、AML、Credit、Service 等业务流程	不替代高风险最终决策
Container	Source registry、ingestion、taxonomy/ontology、retrieval、graph、answer governance、EvalOps、audit	source-of-truth 与 index 分离
Component	parser、chunker、entity resolver、claim extractor、metadata filter、citation validator	权限和版本在 retrieval 前生效
Code / Contract	data contract、claim contract、source metadata schema、eval schema	schema 变更走 gate

17. Financial Retail Cases

17.1 KYC Policy Assistant

维度	设计
用户	KYC analyst、branch operations、compliance reviewer
核心问题	根据客户类型、地区、产品和业务日期返回适用 KYC 要求
Source hierarchy	A0 regulator guidance, A1 KYC Policy, A2 onboarding SOP, A4 training FAQ
Semantic model	CustomerSegment、EntityType、Jurisdiction、KYCRequirement、DocumentRequirement、Exception
RAG fit	强 RAG, 需要 metadata filter、claim-level citation、conflict detection
Graph fit	轻量图谱用于客户类型、UBO、关联方和文件要求关系
Release gate	权限 100%, version correctness 100%, high-risk policy claim citation 100%
Portfolio artifact	KYC Source Registry + Clause Ontology + Release Gate Memo

关键设计决策:

用 SKOS 管理 UBO / beneficial owner / ultimate beneficial owner / 最终受益人 等同义词。
用 claim model 表达“某客户类型需要某文件”的政策断言。
对 branch staff 隐藏调查细节, 但允许查看客户需提交文件清单。
当 FAQ 与 policy 冲突时, 回答 policy 并提示 FAQ 需要 steward review。

17.2 AML Investigation Knowledge Graph

维度	设计
用户	AML analyst、case manager、risk reviewer
核心问题	将客户、账户、商户、设备、交易、名单、历史 case 和 typology 连接成可解释证据路径
Source hierarchy	A0 AML regulation, A1 AML policy, A3 transaction monitoring / case system, A5 analyst notes
Semantic model	Customer、Account、Transaction、Merchant、Device、Address、UBO、Case、Typology、EvidenceItem
RAG fit	用于政策解释、case narrative 草稿、typology definition
Graph fit	强 GraphRAG, 因为风险解释依赖多跳关系和路径证据
Release gate	graph path precision、entity resolution QA、human review required for interpretation claim
Portfolio artifact	AML graph schema + evidence path examples + HITL narrative control

关键设计决策:

GraphRAG 输出不得直接生成 SAR filing decision, 只生成证据摘要、缺口清单和风险叙述草稿。
sameDeviceAs、sharesAddressWith、controlledBy 等关系需要 source 和 confidence。
entity resolution false positive 被视为高风险 incident, 需要 analyst adjudication。
每个 risk narrative claim 绑定 transaction、case note、policy typology 或 graph path evidence。

17.3 Credit Policy Assistant

维度	设计
用户	credit officer、underwriter、policy reviewer
核心问题	根据产品、地区、客户类型、收入、抵押品和例外条件解释政策要求
Source hierarchy	A1 credit policy, A2 underwriting SOP, A3 loan origination system, A4 training examples
Semantic model	Product、EligibilityRule、Exception、CollateralType、IncomeEvidence、RiskGrade
RAG fit	政策解释和引用强适合
Graph fit	中等, 用于规则依赖和例外路径, 不替代规则引擎
Release gate	不允许 LLM 做自动授信决定; recommendation claim 必须 HITL
Portfolio artifact	Policy-to-Rule Mapping + Claim Citation Report + No-AI Boundary ADR

关键设计决策:

数值阈值、资格条件、例外流程必须从结构化政策表或规则服务读取。
LLM 可以解释政策、生成 memo 草稿和缺件清单, 不能成为 credit decision owner。
当用户询问“是否批准”时, 系统转为 evidence checklist 和人工审批路径。

17.4 Customer Service SOP Assistant

维度	设计
用户	contact center agent、supervisor、quality analyst
核心问题	快速找到已批准 SOP、话术、升级路径和客户承诺边界
Source hierarchy	A1 product terms, A2 service SOP, A4 approved scripts / FAQ, A5 historical tickets
Semantic model	CustomerIntent、Product、SOPStep、EscalationReason、AllowedCommitment、ForbiddenCommitment
RAG fit	强 RAG, 重点是版本、引用、权限和话术控制
Graph fit	轻量, 用于 intent-to-SOP 和 escalation path
Release gate	禁止越权承诺、费用减免、法律解释; 高风险意图升级 supervisor
Portfolio artifact	SOP Taxonomy + Escalation Decision Table + Agent Answer Quality Dashboard

关键设计决策:

用 taxonomy 统一投诉类型、产品、服务请求和升级原因。
对费用、罚息、赔付、法律解释类问题设置 deterministic guardrail。
客服答案必须显示 SOP 引用和允许承诺边界。

18. Templates / Portfolio Artifacts

18.1 Knowledge Product Canvas

Block	填写要求	示例
Product name	知识产品名称	KYC Policy Knowledge Product
Business workflow	嵌入哪个流程	Entity onboarding, periodic review, remediation
Users	人类和系统消费者	KYC analyst, branch staff, compliance reviewer, RAG API
Decisions supported	支持但不替代的决策	required documents, escalation, exception routing
Excluded decisions	明确不做什么	不自动决定客户是否通过 KYC
Source scope	纳入来源	approved policy, SOP, regulator guidance, system facts
Authority model	冲突时信谁	regulator > approved policy > SOP > FAQ
Semantic assets	taxonomy / ontology / graph	customer segment taxonomy, KYC requirement ontology
Quality SLO	质量目标	permission 100%, critical citation 100%, freshness P95 < 24h
Risk controls	控制措施	refusal, conflict alert, HITL, audit replay
Operating model	责任	knowledge owner, steward, EvalOps, Risk
Value metric	价值指标	analyst search time, missing-document error rate, rework rate

18.2 Source Registry Schema

Field	Purpose	Example
source_id	稳定标识	`src:kyc-policy-v6-1`
title	来源标题	KYC Policy v6.1
authority_level	A0-A6	A1
owner	内容责任人	Head of KYC Policy
steward	日常维护人	KYC Knowledge Steward
approval_status	draft / approved / deprecated / retired	approved
version	版本	6.1
effective_date	生效日期	2026-01-01
expiry_date	失效日期	2026-12-31
jurisdiction	适用地区	US
permission_group	权限组	kyc-analyst
allowed_ai_use	RAG / eval / training / analytics	RAG, eval
retention_class	保留策略	regulated-policy-7y
distribution	文档或 API 分发	SharePoint PDF, policy API
lineage_snapshot	ingestion 快照	`snapshot:kyc-2026-06-15`

18.3 Ontology ADR

Section	内容要求	示例表达
Context	业务知识域和痛点	KYC 文档要求依赖客户类型、地区、产品和例外
Decision	采用的语义模型	SKOS concept scheme + lightweight OWL-style ontology + RAG metadata
Rejected options	拒绝方案和原因	纯向量 RAG 无法稳定处理版本和适用性; full OWL reasoner 当前运维成本过高
Core classes	核心概念	CustomerSegment, Jurisdiction, KYCRequirement, DocumentRequirement
Core relations	核心关系	appliesTo, requires, overrides, supportedBy
Constraints	不变量和约束	approved policy claim must have evidence span and effective period
Release impact	对检索、eval、权限的影响	metadata filter 使用 jurisdiction/effective date; golden set 按 customer segment 切片
Operations	维护机制	monthly steward review, breaking ontology change requires architecture gate

18.4 Eval Matrix

Scenario	Query type	Expected behavior	Gold evidence	Risk
KYC-NRE-001	policy requirement	回答并引用 A1 policy clause	`clause:kyc-v6-1-3-4`	high
KYC-ROLE-002	permission boundary	branch staff 只能看到文件清单, 不能看到 investigation note	`permission:test:branch`	critical
AML-PATH-003	graph multi-hop	展示 customer-account-merchant-device 路径并要求 analyst review	`graphpath:aml-003`	high
CREDIT-REFUSE-004	prohibited decision	拒绝直接给 approval decision, 转为 policy checklist	`clause:credit-policy-2-1`	critical
SOP-CONFLICT-005	conflict	提示 FAQ 与 SOP 冲突, 升级 steward	`conflict:sop-faq-005`	medium

18.5 Portfolio Evidence Pack

Artifact	证明的能力	面试中怎么讲
Knowledge Product Canvas	能把知识域产品化	说明业务价值、边界、owner、SLO
Source Registry	能治理权威来源	展示 authority、version、permission、retention
Taxonomy / SKOS Scheme	能管理术语和召回	展示同义词、层级、owner、变更流程
Ontology ADR	能做语义架构决策	讲清为什么不用纯 RAG 或 full OWL
Entity-Relation-Claim Model	能把证据和断言建模	展示 claim-level citation 和 audit
RAG vs GraphRAG ADR	能做架构选型	用 query pattern 和风险解释选择
Ingestion Control Report	能让文档生产可用	展示 OCR、chunk、metadata、permission QA
Eval Report	能用指标驱动上线	展示 recall、citation、permission、version
Release Gate Memo	能做生产决策	展示 limited go / no-go 条件
Incident Runbook	能运营 AI 能力	展示 stale policy、permission leakage、unsupported claim 的响应

19. 30-Day Lab

目标: 用一个金融零售知识域做出可展示的 AI knowledge governance / ontology portfolio。推荐选择 KYC Policy Assistant 或 Customer Service SOP Assistant; 如果要突出 GraphRAG, 选择 AML Investigation Knowledge Graph。

Day	主题	实操任务	产出
1	Use case framing	选择一个知识域, 定义用户、流程、风险等级、excluded decisions	Knowledge Product Canvas v1
2	Source inventory	列出 15-30 个来源, 标注 owner、authority、version、permission	Source Registry v1
3	Authority hierarchy	设计 A0-A6 权威层级和冲突规则	Authority Matrix
4	Workflow insertion	画 AS-IS / TO-BE 工作流, 标出 AI 插入点和 HITL	Workflow Map
5	Query taxonomy	设计 query 类型: policy、procedure、fact、conflict、permission、no-answer	Query Scenario Taxonomy
6	Concept scheme	建立 50 个业务概念, 标注 prefLabel、altLabel、broader、related	SKOS-style Concept Scheme
7	Ontology scope	定义 8-12 个核心 class 和 10-15 个 relation	Ontology Catalog v1
8	Claim model	从 20 条政策/SOP 中抽取 claim, 绑定 evidence span	Claim Registry v1
9	Source metadata schema	对齐 DCAT 思路设计 source metadata schema	Source Metadata Contract
10	Permission model	设计角色、entitlement、citation 权限和 cache 隔离测试	Permission Model
11	Version model	设计 effective date、expiry、current version、replaces	Versioning Plan
12	Ingestion gate	设计 OCR、chunk、table、metadata、PII、permission QA	Ingestion Checklist
13	Chunking ADR	比较 fixed、section-aware、parent-child、table-preserving	Chunking ADR
14	RAG baseline	定义普通 RAG 架构、metadata filter、citation 策略	RAG Architecture ADR
15	GraphRAG assessment	判断是否需要 graph; 如果需要, 定义 graph schema 和路径样本	GraphRAG Decision ADR
16	Golden set v1	设计 100 条 query, 包含 hard negative、role、version、conflict	Golden Set v1
17	Retrieval metrics	定义 recall@k、context precision、hard-negative avoidance	Retrieval Eval Matrix
18	Answer metrics	定义 faithfulness、claim support、citation accuracy、refusal quality	Answer Eval Rubric
19	Permission tests	设计 same-query different-role、denied citation、cache isolation	Permission Regression Pack
20	Freshness SLO	设计 source freshness、stale warning、route downgrade	Freshness SLO Dashboard Spec
21	Release gate	设计 G0-G8 gate 和 go / limited go / no-go 条件	Release Gate Checklist
22	Incident patterns	写 stale policy、wrong citation、permission leakage 等 runbook	Incident Runbook
23	Audit lineage	设计 trace schema, 能从答案回放到 source/index/prompt/model	Evidence Lineage Schema
24	Stewardship model	设计 RACI、review cadence、change request	Operating Model
25	Financial case 1	完成 KYC 或客服 SOP 端到端案例	Case Study 1
26	Financial case 2	完成 AML 或信贷案例, 强调 graph / HITL / no-AI boundary	Case Study 2
27	Architecture review	用 architecture review questions 自评方案	Architecture Review Report
28	Portfolio pack	整理 canvas、registry、ontology ADR、eval、release memo	Portfolio Evidence Pack
29	Interview story	准备 6 个 STAR-T 故事: governance、ontology、RAG、incident、release、ROI	Interview Storyline
30	Executive memo	写 1 页给 VP/Risk/CTO 的上线建议和风险接受条件	Executive Release Memo

完成标准:

能解释为什么该场景使用 RAG、GraphRAG、rules、HITL 或组合方案。
能展示 source authority、taxonomy/ontology、claim model、permission、version、SLO 和 release gate。
能用金融零售案例说明 AI 产品架构如何降低幻觉、误引、越权和过期知识风险。

20. Architecture Review Questions

20.1 Source and Authority

哪些来源是 source of truth, 哪些只是辅助解释?
冲突发生时, 系统如何选择、提示或升级?
是否有草稿、过期、个人笔记进入 production index?
每个来源是否有 owner、steward、approval status、effective period?

20.2 Semantics

当前问题需要 taxonomy、ontology、knowledge graph 还是普通 metadata?
业务同义词、缩写、产品代码、地区术语如何治理?
哪些关系是业务关键路径, 哪些只是展示?
ontology 变更如何影响 retrieval、eval、权限和 UI?

20.3 Retrieval and Reasoning

query classifier 如何决定走 RAG、GraphRAG、rules 或拒答?
gold evidence 找不到时, 系统是猜测、拒答还是升级?
context packing 是否按 authority、freshness、permission、diversity 排序?
graph path 是否可解释、可验证、可人工复核?

20.4 Answer Governance

关键断言是否有 claim-level citation?
系统如何处理无答案、低证据、权限不足和来源冲突?
哪些输出必须 HITL?
哪些用户承诺、信贷判断、合规解释被禁止自动生成?

20.5 Operations

知识更新触发哪些回归测试?
谁监控 freshness、citation、permission、incident trend?
如何回放历史答案?
发生 stale policy、permission leakage、wrong citation 时如何遏制?

21. Interview Answers

Q1: AI knowledge governance 和传统 data governance 有什么不同?

30 秒版本: 传统 data governance 关注数据质量、权限、血缘和合规; AI knowledge governance 还要把文档、术语、政策、SOP、claim、证据和模型输出连接起来, 确保 AI 能基于正确来源、正确版本、正确权限和可引用证据回答。

2 分钟版本: AI 知识治理的对象不只是结构化数据, 还包括政策条款、流程步骤、FAQ、案例笔记、业务概念、图谱关系和回答中的断言。它必须解决 source authority、taxonomy/ontology、RAG/GraphRAG 检索、claim-level citation、freshness、permission、eval、release gate 和 incident。金融零售里, 比如 KYC policy assistant 如果只做数据治理, 可能知道文档在哪里; 但 AI knowledge governance 要进一步证明当前用户能不能看、适用哪个地区和日期、引用哪条政策、FAQ 是否冲突、回答中的每个关键 claim 是否有证据。

追问准备: 如果面试官问“怎么落地”, 用 Source Registry、Authority Matrix、Concept Scheme、Claim Contract、Eval Report 和 Release Gate Memo 回答。

Q2: Taxonomy、ontology、knowledge graph 如何选择?

30 秒版本: Taxonomy 解决分类和标签, ontology 解决概念和关系语义, knowledge graph 把实体和关系实例化用于路径、证据和多跳推理。选择取决于 query pattern 和风险, 不是技术偏好。

2 分钟版本: 客服 SOP 或 KYC 术语召回通常先用 taxonomy/SKOS, 因为核心是同义词、分类、权限和引用。信贷政策需要轻量 ontology, 因为资格、产品、地区、例外和阈值之间有语义关系。AML 调查更适合 knowledge graph 或 GraphRAG, 因为风险解释依赖客户、账户、商户、设备、交易和历史 case 的多跳路径。如果只是低风险 FAQ, full ontology 和 GraphRAG 会增加治理成本。

追问准备: 用“普通 RAG 找证据, GraphRAG 解释关系路径, ontology 定义语义边界”来区分。

Q3: 什么时候 GraphRAG 是必要的?

30 秒版本: 当答案依赖多实体、多跳关系、路径证据、entity resolution 或社区结构时, GraphRAG 才有明显价值; 单文档政策问答通常不需要 GraphRAG。

2 分钟版本: 以 AML 为例, analyst 不是只问“政策怎么说”, 而是要理解某客户是否与多个商户、设备、账户、地址和交易模式形成可疑网络。这时关系路径本身就是证据, GraphRAG 可以检索子图、解释路径、补充政策和 typology 文档。但 GraphRAG 不能替代 source authority、权限、版本和人工复核。对于 KYC policy assistant, 大多数问题是条款适用和引用, metadata-rich RAG 加轻量 ontology 就够。

追问准备: 强调 GraphRAG 的 release gate 要测 path precision、entity resolution、evidence support 和 HITL。

Q4: 如何设计 source authority hierarchy?

30 秒版本: 先按监管、内部批准政策、SOP、system of record、培训 FAQ、操作笔记、外部资料分层, 再定义冲突规则、版本规则、权限规则和人工升级路径。

2 分钟版本: 金融零售里相似文本不等于权威来源。比如客服 FAQ 和产品条款冲突时, 高风险回答必须引用条款; SOP 与新政策冲突时, 应回答政策并提示 SOP 过期; 客户事实类问题以 system of record 为准。source hierarchy 要进入检索排序、context packing、citation validator 和 release gate, 不只是文档说明。

追问准备: 给出 A0-A6 层级, 并说明每个来源必须有 owner、approval status、effective date、permission group。

Q5: 如何证明 RAG 回答可审计?

30 秒版本: 要做到 answer-to-evidence lineage: 每个关键断言绑定 citation, citation 指向 source version、section、page、paragraph 或 graph path, 并记录用户角色、检索过滤、prompt、model 和 index 版本。

2 分钟版本: 可审计不是答案末尾放链接。审计要能回放当时用户是谁、有什么权限、问题适用什么业务日期、系统检索了哪些候选、哪些证据进入 prompt、回答拆成哪些 claim、每个 claim 的支持证据是什么、模型和 prompt 是哪个版本。高风险场景还要记录 human review 状态。这样 stale policy、wrong citation、permission leakage 发生时才能定位根因。

追问准备: 提 Minimum Audit Record 和 claim-level citation rule。

Q6: 知识质量 SLO 应该怎么定?

30 秒版本: 不要只看答案准确率, 要覆盖 source freshness、authority correctness、retrieval recall、context precision、citation support、version correctness、permission correctness、refusal quality 和 audit replay。

2 分钟版本: KYC 或信贷场景中, 权限和版本应是 100% gate, 因为一次泄露或过期政策误引就是 critical failure。retrieval recall 和 context precision 反映是否找到正确证据并把干净证据放进 prompt。citation support 证明断言被证据支撑。refusal quality 确保无答案、低证据和无权限时不硬答。SLO breach 要绑定行动, 例如 stale warning、route downgrade、release no-go 或 incident。

追问准备: 说明 SLO 要按场景风险分层, 低风险 FAQ 和高风险合规不可用同一阈值。

Q7: 如何处理政策更新?

30 秒版本: 政策更新应触发 source versioning、ontology impact assessment、ingestion QA、retrieval/eval regression、release gate 和 audit snapshot, 不能直接覆盖向量库。

2 分钟版本: 我会保留 previous/current/replaces 关系, 每条 clause 有 effective/expiry date。新政策进入 approved source registry 后, ingestion pipeline 重新解析、打 metadata、抽取 claim, 然后跑 version tests、hard negative tests 和 affected scenario regression。旧版本按业务日期仍可用于历史回放, 但不用于当前生产回答。重大语义变化还要触发 taxonomy/ontology 变更评审。

追问准备: 强调不能删除旧证据导致 audit replay 失败。

Q8: 如何设计 KYC policy assistant 的架构?

30 秒版本: 我会用 source registry 管理权威政策和 SOP, 用 SKOS 管理术语, 用轻量 ontology 表达客户类型、地区、文件要求和例外, 用 metadata-rich RAG 做检索引用, 再用 claim validator、权限过滤和 release gate 控制上线。

2 分钟版本: 架构上分 source registry、ingestion、concept/ontology registry、retrieval orchestrator、answer governance、EvalOps 和 audit。用户问题先识别角色、业务日期、地区和客户类型, retrieval 只召回有权且有效的政策/SOP chunk, rerank 时考虑 authority 和 freshness。回答拆成 policy claim 和 procedure claim, 每个关键 claim 必须有 citation。branch staff 和 compliance reviewer 看到的内容不同。遇到冲突或低证据时升级人工。

追问准备: 说明 excluded decision: 不自动决定客户是否通过 KYC。

Q9: RDF/OWL/SKOS/DCAT 在企业里是不是过度设计?

30 秒版本: 不一定要一开始全量上语义 Web 技术, 但这些标准提供了很好的 conceptual architecture。可以先用 SKOS 和 DCAT 风格字段治理词表和来源, 再按需要引入 RDF/OWL 或映射到 property graph。

2 分钟版本: 过度设计的风险是真实的, 所以我会按问题选择最小语义资产。客服 SOP 可能只需要 SKOS-style taxonomy 和 DCAT-style source registry。AML 多跳调查可能需要 property graph, 同时借鉴 RDF 的稳定 ID、named graph 和 evidence lineage。严格政策约束才考虑 OWL-style ontology 或 reasoner。关键不是用哪个工具, 而是 source、concept、claim、evidence、version、permission 能否被一致治理。

追问准备: 用“standards as design anchors, not implementation religion”表达。

Q10: 如果 AI 引用了过期政策, 你如何处理?

30 秒版本: 先按 incident 遏制受影响 route, 保存 trace, 通知 owner/Risk, 再定位是 source registry、metadata、index refresh、retrieval filter 还是 citation validator 失败, 最后把样本加入 regression。

2 分钟版本: 我会先确认影响范围: 哪些用户、哪些问题、哪些 source version、是否有客户影响。高风险场景先 route downgrade 或强制人工复核。根因分析看 effective/expiry 是否缺失、旧版本是否还在 production index、query 是否指定 business date、retrieval 是否把旧政策排前、context packing 是否忽略 authority/freshness。修复后要跑 version correctness、hard negative 和 citation support 回归, 并更新 freshness SLO alert。

追问准备: 强调事故不只修 prompt, 还要修治理链路和 release gate。

22. One-Page Executive Summary Pattern

向 VP / CTO / Risk 汇报时, 不要从 ontology 术语开始, 要从业务风险和上线控制开始。

Message	表达
Business value	该知识产品减少 analyst 搜索时间、降低缺件返工、提升政策一致性
Risk boundary	不自动做高风险最终决策, 只做证据检索、解释、草稿和升级建议
Governance design	source authority、permissions、version、claim citation、HITL、audit replay 已设计
Release evidence	golden set、retrieval eval、citation support、permission tests、incident runbook 已通过 gate
Residual risk	长尾政策解释、source update delay、entity resolution false positive
Decision ask	批准 limited pilot, 限定用户、场景、监控指标和复核日期

一句话总结:

这个能力不是一个聊天机器人, 而是一个受治理的 AI knowledge product: 它知道信谁、何时有效、谁能看、证据在哪、何时拒答、出了问题谁负责。