Agent 知识检索与治理架构 ​

本篇第一性问题：企业里的事实、规则、文档、数据、实体关系和实时信息，怎样经过可信生产、持续治理和可验证检索，最终以正确权限、正确版本、正确证据提供给 Agent，而不是把“做一个向量数据库（Vector DB）加检索增强生成（RAG）”误当成企业知识架构。

本篇边界：

• Knowledge（知识）负责“企业有哪些可信事实与语义，以及它们从哪里来、谁负责、什么时候有效”；
• Context（上下文）负责“当前这一轮模型应该看到哪些信息与能力，其中哪些知识可以进入，以及如何组织”；
• Memory（记忆）负责“过去哪些交互和经验值得未来继续参考”；
• Skill（技能）负责“遇到某类任务应该怎样做”；
• Runtime（运行时）负责 Run 的持久状态、等待和恢复；
• Tool / Execution（工具 / 执行）负责访问外部系统并产生真实副作用。

因此：

text

State ≠ Knowledge ≠ Memory ≠ Skill ≠ Context

本文保留行业中已经形成稳定含义的英文术语，但首次出现时给出中文释义。几个贯穿全文的概念先统一如下：

一、企业级智能体为什么需要独立知识架构 ​

1.1 企业知识到底是什么 ​

Knowledge（知识）不是“模型知道的所有东西”。

在企业 Agent 系统里，更有用的定义是：

Knowledge 是来自企业权威系统、领域数据源或外部世界，经过来源、权限、版本、时效和语义治理以后，可以被 Agent 查询、引用和验证的事实与关系。

它至少包含五类：

企业 Knowledge 的目标不是：

“让模型看到更多东西。”

而是：

让 Agent 在需要事实时，能找到正确来源、正确版本、正确权限下的正确证据。

1.2 知识和相邻对象怎样划边界 ​

Knowledge vs Context / Memory / Skill（知识与上下文、记忆、技能的区别） ​

Knowledge vs Context（知识与上下文的区别） ​

Knowledge 回答：

企业知道什么？

Context 回答：

当前模型这一轮被允许、被选择看到什么？

完整关系：

Knowledge Source / Memory / State / Skill
              ↓
       Context Engineering
              ↓
     Model-visible Context

因此：

Knowledge 是候选事实空间；Context 是当前决策投影。

Context 可以引用 Knowledge，但不能拥有 Knowledge 的生命周期。

Knowledge vs Memory（知识与记忆的区别） ​

Knowledge 往往来自：

• Source of Truth（权威事实源）；
• 企业文档；
• 数据库；
• 搜索索引；
• 业务系统；
• 外部实时来源。

Memory 往往来自：

• 用户过去明确表达的偏好；
• 历史 Run 中验证过的经验；
• Agent 长期交互总结；
• 过去失败 / 成功轨迹中筛选出来的信息。

例如：

“张三是支付平台负责人”

如果来自组织目录：

→ Knowledge。

如果用户曾告诉 Agent：

“以后代码评审先找张三”

这可能成为 Memory。

如果未来组织 Owner 改了，正确做法通常是重新查询 Knowledge Source，而不是让旧 Memory 覆盖企业事实源。

Knowledge vs Skill（知识与技能的区别） ​

Knowledge 回答：

“是什么 / 事实是什么？”

Skill 回答：

“怎么做？”

例如：

Knowledge：
支付发布窗口是每周二、四 14:00–17:00。

Skill：
如何执行支付服务生产发布。

Skill 可以引用 Knowledge，但不应该把动态生产事实永久复制进自己的正文。

Knowledge Base 为什么不等于 Vector DB ​

很多系统最早从：

Document
→ Chunk
→ Embedding
→ Vector DB
→ Similarity Search
→ Prompt

开始。

这可以解决一个 Demo 问题：

“怎样让模型搜索内部文档？”

但企业很快会遇到完全不同的问题：

谁是事实源？
哪个版本是真的？
这条知识什么时候失效？
当前用户能不能看？
同一个问题多个来源冲突怎么办？
结构化数据要不要也切 Chunk？
文档删除以后索引删干净了吗？
旧 Chunk 为什么仍被搜到？
Citation 指向的到底是不是原始事实？
搜索结果相关，是否代表权威？

所以：

Vector DB 是 Knowledge Architecture 的一个可选索引组件，不是 Knowledge Architecture 本身。

RAG 为什么也不是完整 Knowledge Architecture ​

RAG（Retrieval-Augmented Generation，检索增强生成）主要描述：

Query
→ Retrieve
→ Add to Context
→ Generate

Knowledge Architecture 则覆盖更长的生命周期：

Source
→ Register
→ Ingest
→ Parse
→ Normalize
→ Structure
→ Classify
→ Permission
→ Authority
→ Version
→ Index
→ Publish
→ Retrieve
→ Rerank
→ Evidence
→ Context
→ Update
→ Supersede
→ Delete
→ Evaluate
→ Govern

因此：

RAG 是 Knowledge Consumption（知识消费）的一部分；企业知识架构同时负责 Knowledge Production（知识生产）和 Knowledge Governance（知识治理）。

1.3 什么时候值得建设独立知识平台 ​

不是什么 Agent 都需要建设独立 Knowledge Platform。

如果只是：

10 份稳定 Markdown
+
单团队内部 Bot
+
没有敏感权限
+
更新极少

简单 File Search / Vector Search 已经足够。

真正开始需要平台化通常由五类 Trigger（触发条件）驱动。

Failure Trigger（失败触发） ​

• 搜索到了旧制度；
• 模型引用错文档；
• 用户看到了无权限内容；
• 多个来源互相冲突；
• 删除文档后旧 Chunk 仍可检索；
• Citation 指向错误版本。

Scale Trigger（规模触发） ​

• 百万 / 亿级文档；
• 多源数据；
• 多语言；
• 高频增量更新；
• 多模态；
• 数百 Agent 共用同一知识层。

Risk Trigger（风险触发） ​

• 合同；
• 财务；
• 医疗；
• 生产操作；
• 用户 PII（个人可识别信息）；
• 内部权限隔离；
• 法规 / 合规内容。

Reuse Trigger（复用触发） ​

多个 Agent 都在重复：

接 SharePoint
接 Wiki
接 Data Warehouse
切 Chunk
建 Embedding
写 ACL Filter
做 Citation
做 Refresh

此时平台化开始有明显收益。

Governance Trigger（治理触发） ​

当企业出现：

Source Owner
Knowledge Domain
Schema
Ontology
ACL
Freshness SLA
Lineage
Quality SLA
Deprecation
Cost Allocation

知识已经不再是“应用内 RAG 功能”，而是一等企业资产。

触发条件不是一张“出现一项就建设平台”的清单。决策时还要把故障影响、跨团队复用和治理责任连起来：

反过来，如果来源少、风险低、更新慢且没有跨团队复用，继续使用应用内检索通常更经济。平台化转移了重复建设成本，但会新增契约演进、策略运营和跨团队协作成本。

二、为什么企业知识检索很容易做错 ​

2.1 为什么“搜得相关”仍然可能回答错 ​

Search Relevance 为什么不等于 Knowledge Correctness ​

这是企业 RAG 最常见的认知错误之一。

向量检索可能返回：

“和问题语义最接近的内容。”

但企业真正需要的是：

“当前这个用户，在当前时间，对当前业务问题，有权使用的、最新的、权威的事实。”

因此最终得分不能只有：

Semantic Similarity

而应该至少综合：

Relevance
+
Authority
+
Freshness
+
Permission
+
Domain Applicability
+
Version
+
Conflict Status

一个相似度 0.95 的旧 Wiki：

不应该压过相似度 0.82 的正式 Metric Registry。

2.2 知识表示为什么会破坏原始语义 ​

为什么固定 Chunk 会破坏知识语义 ​

Chunking（切块）解决的是模型与检索系统的大小限制。

但它同时会丢失结构。

例如原文：

第一章：适用范围
第二章：定义
第三章：例外
第四章：审批规则

如果简单按 500 Token 固定切分：

某个 Chunk 可能只剩：

“允许在紧急情况下跳过审批。”

却丢掉前文：

“仅适用于 Sev-1 事故，并且必须由值班总监确认。”

于是检索“是否可以跳过审批”时，会返回一个看起来正确但危险的 Chunk。

因此 Chunking 需要理解：

• Section Boundary（章节边界）；
• Parent / Child（父子层级）；
• Table；
• Heading；
• Code Block；
• Legal Clause；
• Page / Slide；
• Entity / Record；
• Structured Row。

企业最佳实践通常不是“一种 Chunk Size 通吃所有 Source”。

为什么结构化数据不能按文档方式处理 ​

Structured Knowledge（结构化知识）拥有文档没有的语义：

Schema
Column Type
Primary Key
Foreign Key
Partition
Join Relationship
Row-level Security
Time Grain
Metric Definition

例如：

“华东区上月 GMV（商品交易总额）同比是多少？”

正确路径往往不是：

把销售表每 500 行做一个 Chunk
→ Embedding
→ Vector Search

而是：

识别 Metric = GMV
→ 找 Metric Definition
→ 找 Allowed Dataset
→ 生成 SQL
→ 执行
→ 返回聚合结果和 Query Evidence

因此企业 Knowledge 至少要区分：

Text Retrieval
Structured Query
Semantic Metric Resolution
Graph Traversal
Live Tool-backed Retrieval

Freshness 为什么是一等系统属性 ​

知识不是静态事实。

例如：

2026-01-01
支付平台 Owner = 张三

2026-08-01
支付平台 Owner = 李四

如果系统只存：

embedding("张三是支付平台 Owner")
embedding("李四是支付平台 Owner")

两个结果都可能被召回。

因此 Knowledge Object 最好显式表达：

valid_from
valid_to
source_updated_at
indexed_at
last_verified_at
supersedes
status

Freshness 不是：

“每晚重新跑一次索引。”

而是：

系统能不能表达事实什么时候有效、什么时候被替代、当前查询应该使用哪个版本。

Authority 为什么不能由相似度决定 ​

企业经常存在多层 Source：

用户笔记
团队 Wiki
正式制度
数据库
Metric Registry
CMDB
Source System

这些来源的权威级别不同。

例如：

A：旧 PRD 写“退款窗口 30 天”
B：最新正式政策写“退款窗口 14 天”

Reranker 可能觉得 A 更相关。

但业务必须听 B。

因此需要 Authority Model（权威模型），例如：

A0  Source of Record
A1  Official Published Policy
A2  Domain-owned Knowledge
A3  Team-maintained Wiki
A4  User-generated Note
A5  External / Untrusted Content

Authority 不是 Confidence。

一段模型总结可能 Confidence 很高，但 Authority 仍然很低。

Permission 为什么必须在 Retrieval 前生效 ​

危险的设计：

先检索整个公司知识库
→ 得到敏感 Chunk
→ 再告诉模型“不要泄漏”

问题是：

敏感数据已经进入 Model Context。

正确模型应该是：

User / Agent Identity
→ Tenant / Domain / Resource Policy
→ ACL / Row / Column Filter
→ Eligible Candidate Set
→ Retrieval / Rerank
→ Context

权限边界可能包括：

Document ACL
Folder ACL
Tenant
Project
Row-level Security
Column Masking
Field Redaction
Purpose / Use-case Policy

所以：

Permission 是 Retrieval Eligibility（召回资格），不是生成后的内容审查。

Citation 为什么也可能制造假的安全感 ​

“答案后面有引用”不等于 Grounded（有依据）。

Citation Failure 常见有：

1. 引用了相关文档，但文档并没有支持这句话；
2. 引用了旧版本；
3. 引用了二手总结而不是权威源；
4. 引用 Chunk 已经失效；
5. Citation URL 指向文档，但无法定位具体 Evidence；
6. 多个来源冲突，只显示其中一个；
7. 模型合并多个 Chunk 后生成了原文不存在的结论。

企业 Citation 至少应该能够回答：

source_id
source_version
chunk / record id
original location
retrieved_at
authority
validity
permission scope

2.3 索引知识和实时知识怎样选择 ​

有些知识适合 Indexed Knowledge：

• 制度；
• 文档；
• 产品说明；
• 历史故障；
• 知识库文章。

有些事实应该 Query-time Retrieval：

• 当前库存；
• 当前 Owner；
• 实时工单；
• 当前服务健康状态；
• 当前价格；
• 最新权限；
• 实时交易。

因此 Knowledge Source 应区分：

Indexed Source
vs
Remote / Live Source

Microsoft Azure AI Search 2026 的 Knowledge Source 已明确支持 Indexed（预先建索引）和 Remote（查询时远程访问）两类来源；Remote Source 可以通过原生 API 在 Query Time（查询时）获取结果，而无需把内容提前摄取进索引。[^ms-knowledge-source]

这说明：

企业知识平台应该统一“知识访问契约”，而不是强迫所有知识都复制进向量数据库。

Graph 为什么不应该被神化 ​

Knowledge Graph（知识图谱）特别适合：

实体
关系
依赖
时间
多跳路径

例如：

Service A
→ depends_on
Service B
→ owned_by
Team C
→ oncall
User D

但不是所有问题都需要 Graph。

如果问题只是：

“退款制度里关于企业客户的条款是什么？”

Document Retrieval 可能更简单。

Graph 的成本包括：

• Entity Resolution；
• Schema / Ontology；
• Relation Extraction；
• Update；
• Conflict；
• Temporal Edge；
• Query Complexity。

因此：

Graph 是 Relation-heavy Knowledge 的索引 / 推理方式之一，不是企业 Knowledge 的默认终点。

2.4 企业知识最危险的失败是什么 ​

Knowledge Failure 很少表现成：

HTTP 500

它更经常表现成：

搜到了
但不是最新

搜到了
但不是权威

搜到了
但当前用户不该看到

搜到了
但 Chunk 缺上下文

搜到了
但引用支持不了最终结论

因此 Knowledge System 的质量不能只看 Availability。

三、一条企业知识怎样从来源变成可用证据 ​

3.1 知识来源怎样进入治理生命周期 ​

完整 Knowledge Lifecycle ​

一条知识从企业来源进入模型，不是“导入并搜索”两个动作，而是生产、发布、消费和反馈四段生命周期。生产链保留原始证据并建立规范化知识对象；发布链在权限、版本和质量通过后才切换为可检索版本；消费链返回证据包而不是裸文本；反馈链把线上失败带回来源、解析和策略版本。

展开后的主链路是：

Source Registration
→ Ingestion
→ Parse
→ Normalize
→ Structure
→ Metadata / ACL / Provenance
→ Authority / Freshness
→ Chunk / Entity / Record
→ Index
→ Validate
→ Publish
→ Retrieve
→ Rerank
→ Evidence Pack
→ Context
→ Feedback
→ Update / Supersede / Delete

Source Registration（来源注册） ​

每个 Source 至少要描述：

source_id
domain
owner
source_type
source_of_truth_level
update_mode
freshness_sla
permission_model
retention
parser
index_strategy
region
sensitivity

重要的是：

Source Owner 是知识质量责任人，不只是 Connector Owner。

Ingestion 为什么必须可恢复 ​

典型流程：

Discover Changes
→ Fetch
→ Parse
→ Normalize
→ Validate
→ Write Canonical Knowledge
→ Update Index
→ Publish Version

必须考虑：

• 增量同步；
• Full Rebuild；
• Partial Failure；
• Duplicate Delivery；
• Deleted Source；
• Schema Drift；
• Connector Token 过期；
• Rate Limit；
• Backfill；
• Reindex。

因此每次 Ingestion 最好有：

ingestion_run_id
source_version
cursor / watermark
processed_count
failed_count
deleted_count
index_version

3.2 解析、规范化和知识对象怎样设计 ​

Parse 为什么是知识质量第一道门 ​

PDF 解析失败可能导致：

表格列错位
标题层级丢失
脚注和正文混合
两栏文本交叉
图片说明丢失
页眉重复

最后 Embedding 完全正常，但知识已经被破坏。

所以：

Retrieval Quality 上限首先由 Parsing Quality 决定。

复杂企业文档的解析不能只输出“纯文本”，而要尽可能保留原始结构。例如：

• Layout-aware Parser（版面感知解析）：保留标题、段落、两栏排版和区域关系；
• Table Parser（表格解析）：保留行列头、单元格和跨行 / 跨列语义；
• OCR / Vision Parser（OCR / 视觉解析）：处理扫描件、截图和图表；
• Markdown / HTML Structure（结构化标记）：保留 Heading、List、Link；
• Attachment / Embedded Object（附件 / 嵌入对象）：避免只解析正文而漏掉附件；
• Code Block Preservation（代码块保留）：避免代码和说明文字混合；
• Page / Section Provenance（页 / 章节来源）：保证 Citation 能回到原始位置。

Chunking 不应该只有一个固定 Token Size ​

常见策略至少有：

企业最佳实践不是寻找“全局最优 Chunk Size”，而是：

让 Knowledge Unit（知识单元）和 Source 的原生语义尽量一致，再用 Eval 选择检索粒度。

Multimodal Knowledge 为什么不能只做 OCR ​

图片、图表、扫描合同、架构图和截图中的知识不一定能通过 OCR 完整恢复。

例如一个折线图真正包含：

轴
图例
趋势
异常点
数值关系

OCR 只能识别文字。

因此多模态 Knowledge 需要区分：

Raw Media
→ OCR / Vision Parse
→ Structured Representation
→ Text / Image Embedding
→ Citation back to original region

AWS Bedrock Knowledge Bases 和 Google Vertex AI RAG 等当前实现都已经支持或演进到多模态检索 / 视觉解析相关能力，这说明企业 Knowledge Object 最终需要能引用“原始图片 / 页面区域”，而不是只保存抽取文本。[^aws-kb-retrieve][^google-rag-quickstart]

Normalize 为什么要保留原始证据 ​

知识平台通常需要两个层次：

Raw Source
→ 原始不可变证据

Canonical Knowledge
→ 面向检索 / 语义治理的规范化表示

不要直接覆盖 Raw Source。

否则无法回答：

“这条知识是怎么被解析成现在这样的？”

Knowledge Object 应该表达什么 ​

示意：

knowledge_id
source_id
source_record_id
type
domain
title
content
structured_payload
entities
relations
metadata
authority
sensitivity
acl
valid_from
valid_to
source_updated_at
indexed_at
version
status
supersedes
content_hash
provenance

这些字段不是要求照抄。

它们在回答：

这是什么、从哪来、谁能看、什么时候有效、是否被替代、如何追溯。

3.3 知识单元和安全元数据怎样建模 ​

Chunk、Record、Entity 和 Fact 为什么要分开 ​

企业知识最好区分：

Document
Section
Chunk
Record
Entity
Relation
Fact
Metric
Definition

例如：

一个合同 Document 里：

• Section 是结构；
• Chunk 是检索单元；
• Fact 是抽取出来的关键条款；
• Entity 是甲方 / 乙方；
• Relation 是甲方 pays 乙方；
• Citation 指向原始 Clause。

这能避免把所有东西都降维成：

一串文本 Chunk。

ACL / Security Metadata 为什么要在摄取时保留 ​

Knowledge Ingestion 不能只同步 Content。

还要同步：

tenant
workspace
group
user ACL
classification
sensitivity
row policy
source permission

否则到了 Retrieval 阶段已经无法正确做 Permission-aware Search。

3.4 索引和发布为什么必须与知识存储解耦 ​

Index Build 为什么和 Canonical Knowledge 解耦 ​

一个 Knowledge Object 可能进入多个 Index：

Keyword Index
Vector Index
Graph Index
Structured Index
Temporal Index

因此：

Knowledge Store
≠
Search Index

Search Index 是派生视图。

这样：

• 可以重建；
• 可以换 Embedding；
• 可以换 Reranker；
• 可以多 Index 并行 A/B；
• 删除 Source 时可以统一传播。

Publish Gate 解决什么 ​

不要：

Ingest 成功
→ 自动上线检索

至少检查：

Parse Quality
Metadata Completeness
ACL Completeness
Authority
Index Completeness
Citation Integrity
Freshness
Security Scan

高风险 Knowledge Domain 还应该允许：

Draft
→ Reviewed
→ Published
→ Superseded
→ Retired

四、企业知识检索到底应该怎样设计 ​

4.1 查询理解和来源路由怎样决定去哪找 ​

Retrieval 不是一个 Vector Search ​

更完整链路并不是让所有查询依次经过所有算法，而是先把身份、意图、时间和权威要求转换成路由约束，再只调用适合的来源。权限过滤决定候选资格；关键词、向量、SQL、图查询和实时工具负责取回候选；权威、新鲜度和冲突检查决定候选能否成为证据；最后才由 Context Engineering（上下文工程）决定模型看到多少。

对应的详细处理项包括：

User Question
→ Query Understanding
→ Intent / Entity / Time / Scope
→ Knowledge Source Routing
→ Permission Filter
→ Query Decomposition
→ Keyword / Vector / SQL / Graph / Remote Tool
→ Candidate Merge
→ Authority / Freshness / Conflict Check
→ Rerank
→ Evidence Pack
→ Context Engineering

Query Understanding 需要提取什么 ​

至少：

Intent
Entities
Time Range
Domain
Required Freshness
Required Authority
User / Tenant
Output Type

例如：

“现在支付平台谁值班？”

这里：

Intent = current_oncall
Domain = payment
Freshness = realtime
Source = oncall system

不应该去 Vector DB 搜 Wiki。

Source Routing 为什么比 Search Algorithm 更重要 ​

很多失败不是搜索算法差。

而是：

走错 Source。

例如：

“当前 DAU”
→ Data Warehouse / Metric Service

“DAU 的正式定义”
→ Metric Registry

“为什么 DAU 上周下降”
→ Data + Analysis Artifact + Incident Knowledge

“DAU 指标负责人是谁”
→ Org / Ownership System

所以 Source Router 是 Enterprise Retrieval 的重要组件。

4.2 关键词、向量、混合检索和重排怎样组合 ​

Keyword、Vector、Hybrid 分别适合什么 ​

Keyword / Full-text（关键词与全文检索） ​

适合：

• Error Code；
• Product ID；
• 法条编号；
• 精确术语；
• 人名；
• API Name。

Vector / Semantic（向量与语义检索） ​

适合：

• 同义表达；
• 概念问题；
• 用户描述和文档措辞不一致。

Hybrid（混合检索） ​

同时运行：

Keyword
+
Vector

再合并。

这是当前主流企业搜索非常常见的默认路线。

“同时运行再合并”仍不足以构成稳定机制。关键词分数和向量分数通常不在同一量纲，不能直接相加。工程上可以使用 RRF（Reciprocal Rank Fusion，倒数排名融合）按名次合并，或先对不同检索器的分数做校准；同一来源产生的重复候选需要按知识对象和版本去重；ACL、有效时间和来源状态必须在各检索路径取候选前生效，而不是合并后再清理。

一条可解释的混合检索 Trace 至少要记录每个候选来自哪种检索器、原始名次、融合后名次、命中的过滤条件和去重关系。否则离线指标下降时，团队无法判断是关键词召回、向量召回、融合权重还是元数据过滤出了问题。

Databricks AI Search 当前文档明确把 Hybrid 作为大多数场景推荐起点；Snowflake Cortex Search 默认也组合 Vector、Keyword 与 Semantic Reranking。[^databricks-search][^snowflake-search]

Reranking 什么时候值得 ​

典型架构：

Large Candidate Set
→ Cheap Retrieval
→ Top-N
→ Expensive Reranker
→ Top-K Evidence

Reranker 的价值是：

初筛解决 Recall（召回率），二次排序提高 Precision（查准率）。

代价：

• Latency；
• Cost；
• Model Dependency。

Snowflake 明确允许关闭 Reranking 来换取约 100–300ms 延迟下降，并建议基于具体 Workload A/B；Google Ranking API 和 AWS Bedrock 也都把 Rerank 作为独立第二阶段能力。[^snowflake-scoring][^google-ranking][^aws-rerank]

所以：

不要默认 Rerank，也不要默认不用；用 Eval 决定。

这里的 Eval 需要同时比较质量、延迟和成本。只有当 First-stage Retrieval（第一阶段初筛）已经提供足够 Recall，而主要问题是候选排序不准时，Rerank 才可能产生稳定增益。如果正确证据根本没有进入候选集，增加重排模型不会修复漏召回；如果权威版本未被正确标记，重排也不应替业务规则决定真伪。超时或供应商故障时，系统还应能够返回经过权限和权威过滤的初筛结果，或明确降级为“证据不足”，而不是静默使用未经验证的候选。

Metadata Filter 为什么很重要 ​

Metadata 可以表达：

tenant
region
department
document_type
validity
created_at
updated_at
product
language
classification

Filter 应尽量在 Retrieval 前执行。

AWS Bedrock Knowledge Bases 支持显式与隐式 Metadata Filtering；Google Vertex AI RAG Engine 2026 也加入 Schema-based Metadata Search；Databricks 与 Snowflake 都支持 Query-time Filter。[^aws-kb-query][^google-rag-release][^databricks-filter][^snowflake-query]

4.3 复杂问题什么时候需要查询分解和智能体式检索 ​

Query Decomposition 什么时候值得 ​

复杂问题：

“对比欧洲和美国 2025 年退款原因，并解释企业客户和个人客户差异。”

一次 Search Query 很难完成。

可以拆：

EU refund reasons 2025
US refund reasons 2025
enterprise customer refund reasons
consumer refund reasons

再 Merge / Rerank。

Microsoft Azure AI Search 的 Agentic Retrieval 会基于对话上下文生成多个 Subquery，并并行查询多个 Knowledge Source；AWS Bedrock Knowledge Bases 也提供 Query Decomposition。[^azure-search-features][^aws-kb-query]

但代价是：

• Query 数变多；
• Cost 增加；
• Latency 增加；
• Duplicate Evidence；
• Merge 更复杂。

所以复杂度应该由 Query Need 驱动。

Agentic Retrieval 和普通 RAG 有什么区别 ​

普通 RAG：

1 Query
→ Search
→ Context

Agentic Retrieval：

Analyze Question
→ Plan Queries
→ Route Sources
→ Execute in Parallel
→ Inspect Results
→ Refine / Search Again
→ Merge Evidence

优势：

• 多来源；
• 多跳问题；
• 复杂分析；
• 动态决定搜索深度。

但不应该所有简单查询都进入 Agentic Retrieval。

进入智能体式检索前应分配 Retrieval Budget（检索预算），例如最大子查询数、最大来源数、最大迭代轮次、总延迟和总费用。规划器每次扩展查询都要说明当前证据缺口；达到预算后只能基于已有证据回答、请求澄清或声明证据不足。这样才能避免“搜索更多”成为无法终止、无法解释的默认策略。

Microsoft Azure AI Search 当前已经把 Query Planning、Parallel Query、Knowledge Source、Unified Ranking 做成 Agentic Retrieval 管线；Snowflake Analytical Search 则使用 Search-to-prune + AI / SQL Analysis，并根据问题自动选择简单 Search 还是 Analytical Search。[^azure-search-features][^snowflake-analytical]

4.4 结构化、图和实时检索怎样选择 ​

Structured Retrieval 为什么常常应该走 SQL / API ​

如果问题需要：

精确聚合
Join
Group By
Time Window
数值计算

通常应该：

Semantic Resolution
→ SQL / API
→ Structured Result

而不是：

Vector Search
→ 从几个 Chunk 猜答案

AWS Bedrock Knowledge Bases 也支持 Structured Data Store 路线，把自然语言转换成 SQL 查询。[^aws-kb-support]

Graph Retrieval 什么时候真正值得 ​

适合：

• 依赖链；
• 企业关系；
• 组织结构；
• 攻击路径；
• 供应链；
• 多跳 Research；
• 时间关系。

例如：

“这个告警最终影响哪些客户？”

可能需要：

Alert
→ Service
→ Dependency
→ Product
→ Customer

但 Graph 应该和 Document / Search / Structured Query 混合使用，而不是强行替代。

4.5 证据包怎样把检索结果变成可验证证据 ​

Context Engine 最好不要只拿到：

["chunk1", "chunk2", "chunk3"]

而是得到：

Evidence {
  content
  source
  source_version
  authority
  valid_time
  citation
  relevance
  retrieval_method
  permission_scope
  conflict_status
}

这样模型和 Verifier 才能区分：

“这个内容相关”
和
“这个内容值得相信”。

五、权威性、新鲜度、权限和冲突怎样治理 ​

5.1 权威源、权威性和冲突怎样协作 ​

Source of Truth 应该显式建模 ​

Source of Truth（权威事实源）不是：

“Vector Score 最高。”

而是由 Domain Governance 决定。

例如：

Knowledge Platform 只负责统一访问和治理，不应该擅自创造业务权威。

Conflict Resolution 怎么做 ​

两个来源冲突时，不应该直接让模型决定。

推荐链路：

Detect Conflict
→ Compare Authority
→ Compare Version / Validity
→ Compare Scope
→ Resolve if deterministic
→ Escalate if ambiguous
→ Record Decision

冲突本身也应该成为可观测事件。

指标：

Conflict Rate
Auto-resolve Rate
Human Escalation Rate
Wrong Conflict Resolution

5.2 时序知识和新鲜度怎样治理 ​

Temporal Knowledge 为什么必须保留时间 ​

事实可能具有：

valid time
transaction / ingestion time

例如：

“2026-01-01 到 2026-07-31，Owner = 张三”
“2026-08-01 起，Owner = 李四”

查询：

“2026 年 3 月是谁？”

和：

“现在是谁？”

答案不同。

所以简单“保留最新 Chunk”不适合历史审计和时间问题。

Freshness SLA 为什么必须按 Domain 定义 ​

不是所有知识都要实时。

例如：

Policy：小时 / 天
Wiki：小时
Org Owner：分钟 / 小时
Inventory：秒
Service Health：秒
Financial Close：天 / 月

Freshness SLA 影响：

• Push / Pull；
• Index Refresh；
• Cache TTL（缓存有效期）；
• Query-time Remote Fetch；
• Cost。

5.3 权限、信任和知识投毒怎样治理 ​

Permission-aware Retrieval 的完整链路 ​

User Identity
+
Agent Identity
+
Delegated Scope
↓
Knowledge Policy
↓
Eligible Source
↓
Eligible Record / Field
↓
Search
↓
Evidence

Permission 不应该只看：

Agent Service Account

还要保留：

Agent 代表谁？

Source Trust 和 Content Trust 为什么不同 ​

一个正式 Source 里也可能包含：

• 用户输入；
• 外部网页引用；
• Prompt Injection；
• 自动生成内容。

因此需要：

Source Trust
+
Content Origin
+
Author
+
Review Status

例如：

Confluence 是企业系统。

不代表：

Confluence 里每一段文字都有 System Instruction 权力。

Knowledge Poisoning 怎么发生 ​

典型攻击：

攻击者写入一篇高匹配文档
→ SEO / Embedding Optimized
→ 被 RAG 高排名召回
→ 文档包含恶意指令
→ Agent 执行高风险 Tool

正确边界：

Retrieved Knowledge
= Data
≠ Instruction Authority

并且：

• Source Trust；
• Content / Instruction Separation；
• Sensitive Tool Policy；
• Approval；
• Provenance；
• Retrieval Anomaly Detection。

六、企业知识平台应该怎样设计 ​

6.1 企业知识平台应该统一什么 ​

核心原则：统一 Knowledge Contract，不统一所有 Source ​

企业不要把所有知识搬成同一种存储。

更合理：

Stable Knowledge Contract
+
Multiple Source / Retrieval Provider

例如：

Wiki
→ Search Index

Metric
→ Semantic Layer

Warehouse
→ SQL

CMDB
→ API / Graph

SharePoint
→ Indexed / Remote Connector

Internet
→ Web Retrieval

Knowledge Control Plane（知识控制面） ​

建议包含：

Source Registry
Connector Registry
Knowledge Domain Registry
Schema / Ontology Registry
Authority Policy
ACL / Identity Policy
Freshness Policy
Index Registry
Retrieval Policy
Reranker Registry
Eval Registry
Lineage
Quality
Version
Deprecation / Revoke
Cost / Usage

它不存所有 Knowledge 内容本身。

它负责：

企业知识应该怎样被注册、发布、使用和治理。

Data Plane（数据面） ​

真正承载：

Document Store
Search Index
Vector Index
Warehouse
Graph
Remote API
Web
Object Store

Control Plane 决定：

• 哪个 Source；
• 哪个 Index；
• 哪个版本；
• 哪个用户；
• 哪种 Retrieval。

控制面和数据面的边界可以用一条控制关系概括。控制面保存契约、策略和版本选择，不承载所有正文；数据面执行摄取、存储和查询，不自行决定业务权威。一次查询同时受域 Owner 定义的权威规则、安全系统给出的身份范围和平台发布的检索策略约束。

6.2 知识契约怎样统一来源、查询和证据 ​

示意：

KnowledgeSource {
  source_id
  domain
  owner
  type
  authority
  freshness_sla
  permission_model
  retrieval_modes
  provenance
  region
}

Retrieval：

KnowledgeQuery {
  intent
  domain
  entities
  time_range
  user_identity
  required_authority
  freshness_requirement
  top_k
}

Evidence：

KnowledgeEvidence {
  content
  source_ref
  source_version
  authority
  valid_time
  citation
  score
  conflict_status
}

Data Contract 和 Schema Evolution 为什么不能缺席 ​

企业 Knowledge Source 不会永远保持同一种 Schema。

例如：

owner
→ owners[]

status
→ lifecycle_status

metric_id
→ metric_key

如果 Connector / Parser / Index / Retrieval Policy 没有感知 Schema 变化，系统可能出现最危险的一类 Silent Failure（静默失败）：

服务没有报错，但关键字段不再进入 Knowledge Object、Filter 或 Citation。

因此 Source Contract 至少需要：

schema_version
required_fields
optional_fields
semantic_definition
compatibility_rule
owner
deprecation_date
migration_plan

Schema Evolution（模式演进）至少区分：

• Backward-compatible Change（向后兼容变化）：新增可选字段；
• Behavior-changing Change（行为变化）：字段语义改变；
• Breaking Change（破坏性变化）：字段删除、类型变化、权限语义变化。

对应策略：

Detect
→ Compatibility Check
→ Shadow Parse / Reindex
→ Compare Knowledge Diff
→ Migrate
→ Deprecate Old Contract

知识平台不只要版本化 Index，还要版本化“知识语义契约”。

否则即使检索服务 100% 可用，也可能在业务语义上已经失真。

6.3 多来源、多智能体怎样共享知识 ​

Indexed Source 和 Remote Source 怎样统一 ​

Microsoft Azure AI Search 2026 的 Knowledge Source 已经明确支持：

• Indexed Source；
• Remote SharePoint；
• Fabric Data Agent；
• Fabric Ontology；
• MCP Server；
• Web。

并让多个 Knowledge Source 在一个 Knowledge Base 内被统一 Query 和 Rank。[^ms-knowledge-source]

这验证：

企业 Knowledge Layer 的稳定抽象是“可查询知识源”，不是“向量索引”。

多 Agent 怎样共享 Knowledge 而不共享 Context ​

多个 Agent 可以共享：

Knowledge Base / Source

但每个 Agent 当前 Context 应该独立。

即：

Shared Knowledge
≠
Shared Context

Federated Knowledge（联邦式知识）为什么比“全公司一个库”更现实 ​

大型企业通常不会存在一个真正统一的 Knowledge Store。

更常见的是：

Finance Domain
HR Domain
Data Platform
CRM
CMDB
Wiki / SharePoint
Regional Knowledge Service
External Provider

每个 Domain 都有自己的 Owner、Authority、Region 和 Permission Model。

因此企业更适合：

Federated Source
→ Shared Knowledge Contract
→ Common Discovery / Policy
→ Domain-owned Retrieval
→ Unified Evidence

而不是：

把所有数据搬进一个中央 Vector DB

联邦模式的关键是统一：

• Source Registry；
• Identity / Delegation；
• Query Contract；
• Evidence Contract；
• Authority / Freshness 表达；
• Trace / Eval 口径。

但保留：

• Domain Ownership；
• Local Schema；
• Local Storage；
• Region / Residency；
• Source-native ACL。

平台统一访问和治理语义，不等于集中存储所有知识。

这也是跨 Region 企业避免“为了统一检索而破坏数据驻留”的关键。

例如：

Research Agent 和 Coding Agent 都能查询内部产品文档。

但：

• Retrieval Policy；
• Top-K；
• Tool Exposure；
• Context Budget；
• Permission Scope；

可以完全不同。

6.4 知识平台和相邻平台怎样划边界 ​

和 Data Platform 的边界 ​

Data Platform 负责：

• 数据存储；
• 数据计算；
• Warehouse / Lakehouse；
• Schema；
• Pipeline；
• BI / Metric。

Knowledge Platform 负责：

• 面向 Agent / Search 的知识注册；
• Source Authority；
• Retrieval；
• Provenance；
• Citation；
• Knowledge Eval；
• 多源统一访问。

二者会重叠，但不能简单把 Knowledge Platform 等同于 Data Warehouse。

和 Search Platform 的边界 ​

Search Platform 主要回答：

“怎样搜？”

Knowledge Platform 还回答：

“搜什么、谁拥有、谁能看、哪个版本可信、怎样证明、什么时候失效。”

所以：

Search Engine
⊂
Knowledge Platform

6.5 什么时候 Build，什么时候 Buy ​

Build、Buy、OSS（开源软件）和 Managed（托管服务）不是按功能数量选择，而是按企业必须掌握的控制权选择。解析、向量检索和重排通常可以采购；事实权威、身份委托、权限语义、评测集与退出路径必须由企业自己定义，即使底层全部托管也不能外包责任。

可以先使用托管能力 ​

如果只有：

• 单一 Wiki；
• 少量文档；
• 权限简单；
• 低风险；
• 更新不频繁；

可以优先评估托管能力，例如：

• OpenAI File Search；
• Azure AI Search；
• Vertex RAG Engine；
• Bedrock Knowledge Bases；
• Databricks AI Search；
• Snowflake Cortex Search。

但“产品有能力”不等于“当前版本已经满足你的生产 SLA”。正式落地前仍要核对 Region、Preview（预览）/ GA（正式可用）状态、权限模型、数据驻留、可用性保证和成本模型。

什么时候需要企业 Knowledge Control Plane ​

当出现：

多 Knowledge Provider
多 Domain
统一 Authority
跨平台 ACL
统一 Citation
统一 Eval
多 Region
多 Agent 共用
统一成本治理

再建设 Control Plane。

采购 PoC 应该验证什么 ​

PoC（概念验证）不能只比较“同一问题谁回答得更像”。应使用企业自己的脱敏来源、权限结构和失败样本，至少验证五条机制：

其中 TCO（总拥有成本）至少包含连接器维护、解析与嵌入、索引存储与更新、查询和重排、跨区流量、人工治理、评测、迁移以及退出成本。对比时应采用同一批工作负载，并分别测量简单查询和复杂查询，避免用平均值掩盖 Agentic Retrieval 的扇出成本。

合同和退出路径怎样审查 ​

SLA（服务等级协议）除了可用性，还应覆盖限流、索引更新延迟、故障恢复、数据删除时限和安全事件响应。合同需要明确数据是否会用于供应商训练、日志和缓存保存多久、在哪些区域处理、子处理方是谁，以及产品终止时企业能导出什么。

最终决策前应实际执行一次退出演练：暂停一个来源，导出知识对象和治理元数据，在备用检索实现中重放核心评测集，并确认撤销和删除仍然可证明。无法完成退出演练的方案不是不能采购，但必须把锁定风险、替代周期和补偿控制写进架构决策，而不是留给未来项目承担。

七、主流企业知识系统到底验证了什么 ​

7.1 主流实现分别验证了哪些知识机制 ​

Microsoft：Knowledge Source 成为一等资源 ​

Azure AI Search / Foundry IQ 当前已经把：

Knowledge Base
Knowledge Source
Agentic Retrieval
Permission-aware Response
Citation

做成独立对象。

尤其 Knowledge Source 分：

Indexed
Remote

并覆盖多种来源形态：

• Search Index；
• Blob；
• SQL；
• SharePoint；
• OneLake；
• Fabric Data Agent；
• Fabric Ontology；
• MCP Server；
• Web。

但这些能力截至 2026-09 并不处于完全相同的产品成熟度：Knowledge Source / Knowledge Base 与部分 Agentic Retrieval 能力已经进入正式 API；Remote SharePoint、Fabric Data Agent、Fabric Ontology、MCP Server 等部分来源仍处于 Preview（预览）阶段。[^ms-knowledge-source][^azure-search-features]

所以这里真正值得借鉴的是：

Indexed / Remote Source、统一 Query / Rank、Permission-aware Knowledge 这些架构方向，而不是把某个 Preview Feature 直接当成企业生产标准。

Agentic Retrieval 还能：

Query Planning
→ Subquery
→ Parallel Search
→ Unified Rank
→ Grounding + Citation

这验证了三个方向：

1. Knowledge Source 不等于 Index；
2. Retrieval 已经开始 Agentic；
3. Permission-aware Knowledge 是企业必需品。[^ms-knowledge-source][^azure-search-features][^foundry-iq]

AWS：从 Vector RAG 走向 Query Orchestration ​

Amazon Bedrock Knowledge Bases 当前已经覆盖：

• Hybrid / Semantic Search；
• Metadata Filter；
• Implicit Filter；
• Reranker；
• Query Decomposition；
• Structured Data / SQL；
• Multimodal Retrieval；
• Managed Agentic Retrieval。

这说明：

Knowledge Retrieval 已经从“Embedding + Top-K”演进为 Search Strategy + Filter + Rerank + Query Planning。[^aws-kb-query][^aws-kb-retrieve][^aws-kb-support]

另外 AWS 文档特别提醒：

Guardrail 并不会自动作用于所有 Retrieved References。

这说明企业不能把“LLM Guardrail”误当成 Retrieval Security。[^aws-kb-retrieve]

Google：Corpus、Metadata 和 Retrieval Configuration ​

Vertex AI RAG Engine 当前支持：

• Corpus；
• File Import / Upload；
• Chunk Size / Overlap；
• Retrieval Top-K；
• Distance Threshold；
• Metadata Schema / Filter；
• Cross-corpus Retrieval；
• Serverless / Spanner deployment；
• Ranking API。

2026 新增 Metadata Search 和 Cross Corpus Retrieval，说明企业 Knowledge 正在从单 Corpus RAG 演进为：

Multiple Corpus
+
Metadata-aware Retrieval
+
Rerank
+
Managed Scale

[^google-rag-release][^google-rag-quickstart][^google-ranking]

Databricks：Retrieval 和数据治理逐渐合并 ​

Databricks AI Search 当前基于 Delta Table 建立 Index，并支持：

• ANN（近似最近邻检索）；
• Full-text；
• Hybrid；
• Filter；
• Rerank；
• ACL；
• Incremental Sync。

Hybrid 是其推荐的大多数场景起点。[^databricks-search][^databricks-query]

这条路线特别适合：

企业 Knowledge 本来就来自 Lakehouse / Table，并且需要和数据治理、权限、Schema 一起演进。

Snowflake：Search 和 Analytical Retrieval 开始融合 ​

Cortex Search 当前提供：

• Vector；
• Keyword；
• Semantic Rerank；
• Time Decay；
• Numeric Boost；
• Multi-index；
• Metadata Filter。

Cortex Agents 又进一步加入：

• Search Service Routing；
• Dynamic Filter；
• Dynamic Column；
• Dynamic Result Count；
• Analytical Search。

Analytical Search 使用：

Search to Prune
→ AI_FILTER / AI_EXTRACT / AI_AGG
→ SQL Analysis

截至 2026-09，Analytical Search 仍是 Public Preview，因此它更适合作为“检索 + 分析融合”的架构证据，而不是默认生产基线。[^snowflake-analytical]

这代表另一条重要路线：

企业 Knowledge 不只是找到几个 Chunk，还可能要在大规模文本候选集上继续做结构化分析。[^snowflake-search][^snowflake-search-update][^snowflake-analytical]

Framework 层：LangChain / LlamaIndex 为什么强调 Retriever 和 Router 抽象 ​

云平台解决的是 Managed Ingestion / Index / Permission / Scale；Agent Framework 更关注应用层怎样组合不同 Retrieval 能力。

LangChain

LangChain 当前明确区分 Vector Store 和 Retriever：Retriever 只是“给定 Query 返回 Document”的接口，它可以来自 Vector Store，也可以来自外部 API 或其他数据源。LangGraph 的 Agentic RAG 示例又进一步把“是否检索、检索后是否需要重写 Query、怎样判断 Document Relevant”放进 Graph Control Flow。[^langchain-retriever][^langgraph-agentic-rag]

这验证：

Retrieval Interface 不应该绑定 Vector Store；Agent 可以在运行时决定是否检索、检索什么和是否重试检索。

LlamaIndex

LlamaIndex 的 RouterRetriever / Router Query Engine 支持从多个 Retriever / Query Engine 中动态选择一个或多个执行，并允许通过 Metadata 描述每个候选能力。[^llamaindex-router]

这验证：

多 Knowledge Source 场景需要 Source / Retriever Routing，而不是把所有数据强行放进同一个 Index。

Framework 路线与 Microsoft / AWS / Google 的 Agentic Retrieval 本质上在同一方向收敛：

Single Retriever
→ Multiple Retriever
→ Router
→ Query Planning
→ Iterative / Agentic Retrieval

区别只在于：

• 平台更强调托管、权限、索引和企业治理；
• Framework 更强调可组合性和应用级 Control Flow。

7.2 主流路线共同收敛了什么 ​

跨 Microsoft、AWS、Google、Databricks、Snowflake，可以看到八个稳定方向。

1. Hybrid Retrieval 成为常见默认路线；
2. Metadata / Filter 成为一等能力；
3. Reranking 从“高级优化”变成标准第二阶段；
4. Knowledge Source 开始超越单 Vector Index；
5. 复杂 Query 开始进入 Query Planning / Decomposition；
6. Permission / Governance 与 Retrieval 越来越紧密；
7. Structured / Remote / Live Source 开始和文档 Search 统一。
8. Retriever / Source Router 成为稳定抽象：应用不应该被某一种 Vector Store 或 Search Provider 锁死。

因此企业不应该问：

“哪个 Vector DB 最好？”

还要额外问：

这个能力现在是 GA、Preview 还是实验路线？我们的 SLA、Region、权限和合规要求能不能接受？

架构趋势可以借鉴 Preview 能力，但生产基线只能建立在经过自身验证的可用性和治理保证上。

而应该问：

我们的 Knowledge Source、Authority、Permission、Freshness、Retrieval 和 Eval 需要什么保证？

7.3 主流路线真正的分歧在哪里 ​

仍然存在重要分歧。

Fully Managed vs Composable（全托管与可组合） ​

有的平台：

尽量托管 Parsing / Chunk / Embedding / Ranking。

有的平台：

允许企业自定义 Embedding / Index / Reranker。

Indexed vs Live（索引式与实时式） ​

有的 Knowledge 适合复制进 Index。

有的必须 Query-time 访问。

Search-first vs Data-first（搜索优先与数据优先） ​

Databricks / Snowflake 更接近企业数据平台。

Azure / AWS / Google 更像通用 Knowledge / RAG Platform。

Graph / Ontology 的位置 ​

有些企业需要强 Ontology / Entity Layer。

有些 Document Search 已经足够。

权限模型 ​

ACL 是 Source-native 透传，还是 Knowledge Platform 自己维护？

这是企业架构必须明确的 Ownership 问题。

八、知识系统怎样失败、评测并进入生产治理 ​

8.1 先建立失败分类和排查路径 ​

Failure Taxonomy（故障分类） ​

故障分类的价值，是把“答案错了”还原为可定位的系统问题。它只是排查入口，不是看到某个症状就直接执行的修复手册；同一个症状可能跨越多个层次，最终仍要以 Retrieval Trace、版本信息和原始来源为证据确认根因。

8.2 典型故障场景怎样暴露知识机制缺口 ​

以下场景用于架构推演和测试设计，不宣称来自未公开的企业事故。每个场景都按现象、失效原因、正确机制和验证方式展开，目的是把抽象原则转换成可复现的故障注入。

故障场景一：旧政策排名更高 ​

现象

用户问：

“退款期限是多少？”

系统回答：

“30 天。”

但正式政策已经改成 14 天。

为什么旧设计看起来合理

旧 Wiki：

• 内容更长；
• 关键词更多；
• 和问题 Embedding 更接近。

根因

Ranking 只有 Relevance，没有 Authority / Freshness。

错误修复

提高最新文档 Vector Score。

这仍然依赖调参，没有定义业务权威。

正确机制

Authority Filter
+
Validity
+
Latest Published Version
+
Semantic Rank

验证

构造：

• 旧 / 新版本；
• 高相似旧内容；
• 低相似权威内容。

检查系统是否稳定选择权威版本。

架构结论

Enterprise Retrieval 不能把 Relevance 当 Truth。

故障场景二：跨租户知识泄漏 ​

现象

Tenant B 搜到 Tenant A 的合同片段。

根因

ACL 在生成后过滤，而不是 Retrieval 前。

正确机制

Identity
→ ACL Filter
→ Retrieval

并做 Cross-tenant Negative Test。

架构结论

Permission 决定 Candidate Eligibility。

故障场景三：删除原文后旧 Chunk 仍能被搜到 ​

现象

用户要求删除敏感文档。

Source 删除了。

Vector Index 里的旧 Chunk 在删除传播完成前仍然可被召回。

根因

没有 Data Lineage。

正确机制

Source Delete
→ Knowledge Object
→ Chunk
→ Vector
→ Keyword Index
→ Cache
→ Derived Summary
→ Eval Dataset（必要时）

做完整 Delete Propagation。

故障场景四：Chunk 把例外条件切掉 ​

现象

模型引用：

“可以跳过审批。”

但原文完整意思是：

“仅 Sev-1 且值班总监确认时可跳过。”

根因

固定长度 Chunk 丢失 Parent Section。

正确机制

• Structure-aware Chunk；
• Parent Context；
• Clause Boundary；
• Context Expansion；
• Citation to Original Section。

故障场景五：实时 Owner 被缓存成长期知识 ​

现象

服务 Owner 已换人。

Agent 仍然联系旧 Owner。

根因

动态事实被作为静态 Index Knowledge。

正确机制

Stable Description
→ Indexed

Current Owner
→ Live Org / CMDB Tool

故障场景六：相似内容被误当权威内容 ​

现象

一篇用户自己写的排障笔记压过正式 Runbook。

根因

没有 Authority。

正确机制

Source Class + Owner + Publish Status + Authority-aware Rank。

故障场景七：Query Decomposition 成本爆炸 ​

现象

一个本可直接检索的问题被拆成大量 Subquery（子查询），下游来源调用和重排候选随之扩张，Latency（延迟）与 Cost（成本）显著增长。这里描述的是用于故障注入的示意场景，具体子查询数量和成本增幅应由真实查询分布与调用计量确定。

根因

所有 Query 默认 Agentic Retrieval。

正确机制

Simple Query
→ Direct Search

Complex / Multi-source
→ Agentic Retrieval

需要 Retrieval Reasoning Budget。

故障场景八：Graph 架构过度设计 ​

现象

团队投入大量时间建设 Ontology（本体模型），但实际查询主要仍是文档事实查找。

根因

技术先于 Query Distribution。

正确机制

先统计真实 Query：

Document Lookup
Exact Search
Structured Query
Multi-hop Relation
Temporal Query

只有 Multi-hop / Relation 占比足够高再上 Graph。

8.3 评测为什么必须拆成四层 ​

Eval 必须拆层 ​

不能只看：

“最终回答对不对。”

至少拆四层。

Source Quality
Retrieval Quality
Evidence Quality
Answer Quality

Source Quality（来源质量）

来源质量不能只列指标名。最关键的口径需要绑定到可行动的对象和时间窗口：Source Coverage（来源覆盖率）以目标业务任务所需来源为分母，判断关键事实是否存在可查询入口；Source Freshness（来源新鲜度）以发生有效变更的对象为分母，判断它们是否在所属 Domain 的 Freshness SLA 内完成发布；ACL Completeness（权限完整率）以要求继承权限的对象为分母，判断是否都带有可执行的权限元数据；Parse Error Rate（解析错误率）以实际进入解析流程的对象为分母，并区分阻断发布的结构丢失与可容忍的格式瑕疵。Duplicate Rate（重复率）与 Conflict Rate（冲突率）必须按事实域观察，不能把合法多版本或同义表达都算作缺陷。

企业规模上来以后，可以为 Source / Domain 建立可解释的 Knowledge Quality Score（知识质量分），但不要压缩成一个黑盒分数。

更合理的是保留分量：

Freshness
Authority
Completeness
Parse Quality
Conflict Rate
Citation Integrity
ACL Health

并让它影响：

• 是否允许发布；
• 是否进入默认 Retrieval；
• 是否触发 Owner 告警；
• 是否降低 Authority / Rank；
• 是否进入治理看板。

Knowledge Quality Score 是治理摘要，不应该取代底层质量维度。

Retrieval Quality（检索质量）

检索指标必须建立在固定任务集和 qrels（查询—证据相关性标注）上。K 不是越大越好，而应由模型可消费的证据预算、延迟和成本共同确定；同一个总平均值还必须按 Domain、查询类型、权限范围和长尾程度分桶，否则少量高频简单问题会掩盖关键业务失败。

Evidence Quality（证据质量）

至少检查 Citation Correctness（引用正确性）、Citation Completeness（引用完整性）、Authority Accuracy（权威性判断准确率）、Freshness Accuracy（时效性判断准确率）、Conflict Detection Recall（冲突发现召回率）和 Evidence Sufficiency（证据充分性）。每项都要能够回到具体 Evidence Pack 和 Retrieval Trace，而不是只保留聚合分数。

一个答案可能最终“碰巧正确”，但 Evidence 是错的。

这种结果不能算高质量。

Answer / Agent Quality（答案 / 智能体质量）

最终还要观察有依据答案准确率、幻觉率、无证据声明比例、任务成功率变化和人工纠正率。检索质量好不等于任务质量好；模型仍可能忽略证据、错误综合冲突事实，或在证据不足时过度断言。

需要做 Ablation（消融）：

No Knowledge
vs
Keyword
vs
Vector
vs
Hybrid
vs
Hybrid + Rerank
vs
Agentic Retrieval

否则无法证明复杂架构值得。

8.4 安全、新鲜度和在线评测怎样闭环 ​

普通 Recall Eval（召回评测）无法证明权限、时效和运行成本满足企业要求。测试必须注入具体故障，并为每类故障定义不可被破坏的不变量：

不要只追求 Recall 最大化。候选数和 K 持续增加，可能同时推高延迟、Token、无关证据和越权暴露面；企业评测需要在固定任务质量下比较每个有依据答案的完整成本。

Online Eval（在线评测）的作用，是把生产中的 Zero-result Query（零结果查询）、用户改写、人工纠正、错误答案事故、长尾查询、ACL 拒绝和检索超时持续转化为回归样本，而不是直接用线上点击替代真值标注。

形成：

Production Query
→ Failure Mining
→ Eval Dataset
→ Retrieval / Ranking Experiment
→ Release Gate
→ Production

8.5 知识发布、迁移和删除怎样治理 ​

Release 到底版本化什么 ​

至少：

source_version
parser_version
chunking_version
metadata_schema_version
embedding_model_version
keyword_index_version
vector_index_version
reranker_version
retrieval_policy_version
authority_policy_version
acl_policy_version

否则：

“搜索质量下降了”

完全无法归因。

这些版本不能只存在于 Control Plane，还应该绑定到每一次 Retrieval Trace：

query_id
source_version
parser_version
chunking_version
embedding_model_version
index_version
reranker_version
retrieval_policy_version
authority_policy_version
acl_policy_version

这样生产事故才能回答：

这次错误是 Source 变了、解析变了、Embedding 变了、Index 变了，还是 Policy 变了？

没有版本绑定的 Trace，只能看到“搜错了”，不能完成真正的 Root Cause Attribution（根因归因）。

Index Migration（索引迁移） ​

例如 Embedding Model 升级：

不要直接：

Index v1
→ overwrite

更合理：

Build Index v2
→ Backfill
→ Offline Eval
→ Shadow Query
→ Compare
→ Canary
→ Switch Alias
→ Keep v1 Rollback Window

Emergency Revoke（紧急撤销）为什么不同于 Delete ​

Delete（删除）通常是数据生命周期动作；Revoke（撤销）是访问与风险控制动作。

当出现：

• Source 被入侵；
• 错误政策大规模发布；
• 权限配置错误；
• 敏感文档误同步；
• 法务要求立即停止使用；

系统不能等待完整 Cascade Delete 完成以后才停止召回。

需要：

Revoke Source / Version
→ Immediately Remove from Eligible Candidate Set
→ Invalidate Cache
→ Block Remote Fetch
→ Mark Existing Evidence as Revoked
→ Trigger Async Cleanup / Reindex

因此：

Revoke 追求“立刻停止使用”，Delete 追求“最终彻底移除”。

Knowledge Control Plane 应支持：

source status = active / suspended / revoked / retired

并让 Retrieval Policy 在 Query Time 实时尊重状态。

Delete / Retention（删除与保留） ​

知识删除比文件删除复杂。

需要追踪：

Raw File
Canonical Knowledge
Chunk
Embedding
Keyword Index
Cache
Derived Entity
Graph Edge
Summary
Eval Sample

不同对象可能有不同 Retention Policy。

8.6 容量、成本、可观测和责任怎样治理 ​

Capacity（容量） ​

容量治理不是把 Documents、Chunks、Index Size 和 QPS 汇总到看板，而是为一次知识请求建立分层预算。入口按租户和任务等级限制 Retrieval QPS（每秒检索请求数）与 Query Fan-out（单次查询展开的下游请求数）；检索链路继续约束候选数、重排量、远程来源调用和证据体积；摄取链路则分别控制增量积压、解析吞吐和索引发布并发。这样系统才能区分“查询突然增多”“单个查询展开过宽”和“更新积压拖慢新鲜度”三种不同压力。

当队列水位、P95（95 分位）延迟或远程来源限流接近域级预算时，平台应先施加背压，避免继续接受无法在时限内完成的低优先级请求；随后按任务契约降级，例如减少非权威来源、跳过非必要重排、把智能体式检索回退为确定性检索，或明确返回证据不足。容量拐点不是某个固定 QPS，而是增加并发后吞吐不再线性增长，同时 P95 延迟、超时率或单位成功成本持续恶化的位置。压测必须覆盖正常流量、突发查询、批量更新和远程来源降速，才能决定扩容、限流或架构拆分。

Cost（成本） ​

成本应按完整知识生命周期归集，而不是只计算模型或向量检索费用。分子至少包含 Connector、Parsing、Embedding、Index Storage、Index Refresh、Search、Rerank、Agentic Query Planning、Remote API 和 Context Token；分母不是总 Query 数，而是在统一任务评测中同时满足“任务成功、关键主张有正确 Citation、权限与时效不变量未被破坏”的 Grounded Successful Run（有依据的成功运行）数量。

因此，每个有依据成功运行的知识成本可以定位到具体 Retrieval Trace，并按租户、Domain、任务类型和检索策略分桶。如果某个智能体式检索方案提升了总回答率，却没有提高有依据任务成功数，额外查询规划和远程调用不能被解释为有效投入。若分母在一个窗口内为零，应直接报告“没有成功样本”，不能用总调用量摊薄出看似正常的单位成本。

Observability（可观测性） ​

Retrieval Trace 的目标不是多记字段，而是把一次错误答案沿执行链逆向定位。排查从错误 Claim（主张）及其 Citation 开始：先确认引用证据是否真的支持主张，再检查该证据的 Authority、Freshness 和访问资格；如果证据本身不应入选，则比较重排前后的候选与分数；如果必要证据从未出现，则继续回查过滤后的候选、来源路由、查询改写和原始 Query。最后用 Source、Parser、Index、Reranker 与 Retrieval Policy 版本判断问题由内容变化还是策略发布引入。

为支持这条路径，每次 Trace 至少要关联 query、intent、候选与已选来源、身份和过滤决策、召回方法、重排前后候选、authority、freshness、citations、组件版本、latency 和 cost。敏感 Query 与 Evidence 不应无条件明文记录；可观测平台需要执行与知识链路相同的数据分类、租户隔离、驻留和保留策略。一次故障只有能够从 Claim 回到 Evidence、候选、路由和版本，才真正回答了“为什么这条知识被选中，以及在哪一层选错”。

Multi-tenant / Data Residency（多租户 / 数据驻留） ​

企业 Knowledge Platform 的权限边界不能只停留在 Document ACL。

多租户场景至少要明确：

Tenant
→ Knowledge Domain
→ Source
→ Canonical Knowledge
→ Index
→ Cache
→ Retrieval Trace

哪些对象是共享的，哪些必须物理或逻辑隔离。

尤其需要防止：

• Tenant A 的 Chunk 被写入 Tenant B 的共享 Index；
• Query Cache / Embedding Cache 跨租户复用错误；
• Remote Connector 使用了错误的 Delegated Identity；
• Cross-region Retrieval 把敏感数据带出允许 Region；
• Global Reranker / Eval Dataset 意外保存原始敏感内容。

因此 Knowledge Contract 还应该包含：

tenant_id
region / residency
classification
encryption_scope
cache_scope
index_scope
cross_region_policy

多租户平台的核心不变量是：

共享 Retrieval Infrastructure，不等于共享 Knowledge Visibility。

Data Residency（数据驻留）也不只是 Storage Location。Query、Embedding、Rerank、Cache、Trace 和 Eval Pipeline 都可能让数据跨区域流动，所以 Region Policy 必须贯穿整条 Knowledge Path。

Ownership（责任归属） ​

Knowledge Platform Team：

负责：

• Platform；
• Connector SDK（连接器开发工具包）；
• Retrieval Engine；
• Index；
• Eval Infra；
• Governance Contract。

Domain Owner：

负责：

• Source of Truth；
• Meaning；
• Authority；
• Freshness SLA；
• Business Conflict Resolution。

Security / Data Governance：

负责：

• Classification；
• ACL；
• Retention；
• Compliance。

九、不同智能体怎样使用知识，以及企业应该怎样演进 ​

9.1 不同智能体场景怎样使用知识 ​

四类 Agent 的差异不在于是否“接了知识库”，而在于事实形态、变化速度、权威来源和错误后果不同。下面的对照表直接从这些特征推导简单方案的失效方式、关键机制和验收方法，避免把每个场景需要的知识对象重复列成英文清单。

这些机制可以共享来源契约、权限和证据格式，但“谁说了算”和“什么算任务完成”仍由业务域负责。平台如果统一这两类业务判断，得到的不是复用，而是一个无法对所有场景负责的中央规则层。

9.2 企业知识架构应该怎样演进 ​

演进阶段不是产品功能路线图，而是由已出现的问题和可验证证据推动的架构升级。企业不必逐级购买全部能力，也不应该因为图中存在后续阶段就提前建设。

每次升级都应保留前一阶段的回滚路径。例如重排模型升级时保留旧索引和旧策略；多源路由失败时可以降级到确定性来源；智能体式检索超过时间或成本预算时回退到直接检索。没有这些恢复路径，能力越丰富，故障归因和止损越困难。

9.3 企业知识最终应该坚持哪些稳定原则 ​

1. Knowledge ≠ Context ≠ Memory ≠ Skill。
2. RAG ≠ Knowledge Architecture。
3. Relevance ≠ Authority。
4. Permission 必须在 Retrieval 前生效。
5. Vector DB 只是 Index，不是 Source of Truth。
6. 动态事实优先 Live Query，不要盲目复制。
7. Citation 必须可追到版本、权限和原始 Evidence。
8. Knowledge Quality 必须通过 Retrieval / Evidence / Answer 分层 Eval 证明。

9.4 新增知识能力时怎样做架构决策 ​

当你准备增加一种 Knowledge 能力时，统一问：

Problem / Failure
↓
当前哪种知识问题没有解决？

Source
↓
事实真正在哪里？

Authority
↓
谁说了算？

Freshness
↓
多久会变？

Permission
↓
谁能看？

Retrieval
↓
应该 Keyword / Vector / SQL / Graph / Remote？

Evidence
↓
怎样证明来源？

Eval
↓
怎样证明真的变好？

Trade-off
↓
新增了什么成本和治理复杂度？

9.5 最终架构判断 ​

企业级 Agent Knowledge Architecture 的本质，不是建设一个更大的 Vector DB，而是把“企业事实从哪里来、谁有权看、哪个版本可信、什么时候有效、怎样检索、怎样证明、怎样更新和删除”变成一套稳定的生产系统。

好的 Knowledge Platform 不应该让 Agent：

“记住企业的一切。”

而应该让 Agent：

在需要事实的那个时刻，用正确身份，从正确来源，拿到正确版本，并带着可以验证的 Evidence。

附录 A：高频架构问题与快速回答 ​

A.1 核心概念与边界 ​

Q1：Knowledge 和 Context 最大区别是什么？ ​

Knowledge 是可长期治理的事实 / 语义资产；Context 是当前模型可见投影。Knowledge 可以存在但不进入当前 Context。

Q2：Knowledge 和 Memory 最大区别是什么？ ​

Knowledge 主要来自企业 / 外部权威事实源；Memory 主要来自历史交互和经验。动态企业事实不应该由旧 Memory 覆盖。

Q3：RAG 是不是 Knowledge Platform？ ​

不是。RAG 主要描述 Retrieval → Context → Generation；Knowledge Platform 还负责 Source、Authority、ACL、Freshness、Lineage、Update、Delete 和 Eval。

Q4：为什么 Vector DB 不是知识库本身？ ​

因为 Vector Index 不负责事实权威、权限、版本、删除传播和业务语义。

Q5：什么时候不需要独立 Knowledge Platform？ ​

少量稳定文档、单团队、低风险、更新很少时，托管 File Search / Search Service 足够。

A.2 检索与生产机制 ​

Q6：Hybrid Search 为什么常作为默认起点？ ​

Keyword 擅长 ID / 专有名词，Vector 擅长语义，组合通常对混合 Query 更稳。

Q7：为什么还要 Rerank？ ​

First-stage Retrieval 优先 Recall；Reranker 对较小候选集重新判断 Query-Relevance，提高 Precision。

Q8：为什么 Authority 不能只靠 Rerank？ ​

Reranker 判断相关性，不知道哪个企业系统拥有业务权威。

Q9：Metadata Filter 和 Rerank 有什么区别？ ​

Filter 决定候选是否有资格出现；Rerank 决定合格候选谁排前面。

Q10：什么时候应该 Agentic Retrieval？ ​

复杂、多源、多跳、需要 Query Decomposition 时。简单 FAQ 不值得增加额外 Planning、Latency 和 Cost。

Q11：什么时候应该用 SQL 而不是 RAG？ ​

当问题需要精确聚合、Join、数值计算、实时数据时。

Q12：什么时候值得 Knowledge Graph？ ​

多跳关系、实体依赖、组织 / 服务拓扑等 Relation-heavy Query 占比足够高时。

A.3 企业治理 ​

Q13：权限应该在什么时候过滤？ ​

Retrieval 前。未经授权内容不应进入 Candidate Set，更不能先进 Context 再靠 Prompt 禁止泄漏。

Q14：知识更新怎么避免旧版本继续被召回？ ​

显式 Version / Validity / Supersede，索引更新与 Cache Invalidation，同时做 Freshness Eval。

Q15：为什么删除很难？ ​

因为一条 Source 可能派生出 Chunk、Embedding、Keyword Index、Graph Edge、Cache 和 Summary，需要 Lineage 驱动传播。

Q16：Citation 怎么评测？ ​

检查 Citation 是否真的支持 Claim、是否为当前有效版本、是否来自有权访问的 Source。

Q17：Knowledge Poisoning 怎么防？ ​

Source Trust、Content/Instruction Separation、Authority、Anomaly Detection，加上高风险 Tool 的 Policy / Approval。

Q18：Knowledge Control Plane 最值得统一什么？ ​

Source Registry、Authority、ACL、Freshness、Index、Retrieval Policy、Eval、Lineage、Version 和 Cost。

Q19：企业 Knowledge 最核心指标是什么？ ​

不能只有 Recall。至少同时看 Retrieval Recall/Precision、Authority/Freshness Accuracy、Citation Correctness、Permission Leakage 和 Task Success Delta。

Q20：从零建设最合理的顺序是什么？ ​

先做可靠 Search + Citation；再补 Metadata / ACL / Freshness；然后 Hybrid / Rerank / Eval；再进入 Multi-source / Structured / Graph / Agentic Retrieval；最后才是 Knowledge Control Plane。

[^langchain-retriever]: LangChain, Retriever integrations / semantic search abstractions. https://docs.langchain.com/oss/python/integrations/retrievers [^langgraph-agentic-rag]: LangGraph, Build a custom RAG agent. https://docs.langchain.com/oss/python/langgraph/agentic-rag [^llamaindex-router]: LlamaIndex, RouterRetriever. https://docs.llamaindex.ai/en/stable/api_reference/retrievers/router/

附录 B：主要官方资料 ​

动态事实核验基线：2026-09-13。

[^ms-knowledge-source]: Microsoft Azure AI Search, What is a Knowledge Source? https://learn.microsoft.com/en-us/azure/search/agentic-knowledge-source-overview

[^azure-search-features]: Microsoft Azure AI Search, Features and Capabilities / Agentic retrieval. https://learn.microsoft.com/en-us/azure/search/search-features-list

[^foundry-iq]: Microsoft Foundry, What is Foundry IQ? https://learn.microsoft.com/en-us/azure/foundry/agents/concepts/what-is-foundry-iq

[^aws-kb-query]: Amazon Bedrock Knowledge Bases, Configure and customize queries and response generation. https://docs.aws.amazon.com/bedrock/latest/userguide/kb-test-config.html

[^aws-kb-retrieve]: Amazon Bedrock Knowledge Bases, Query a knowledge base and retrieve data. https://docs.aws.amazon.com/bedrock/latest/userguide/kb-test-retrieve.html

[^aws-kb-support]: Amazon Bedrock Knowledge Bases, Supported models and structured data stores. https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base-supported.html

[^aws-rerank]: Amazon Bedrock, Improve relevance with reranker models. https://docs.aws.amazon.com/bedrock/latest/userguide/rerank.html

[^google-rag-release]: Google Vertex AI, Generative AI release notes — RAG Engine metadata search / cross-corpus / serverless. https://docs.cloud.google.com/vertex-ai/generative-ai/docs/release-notes

[^google-rag-quickstart]: Google Vertex AI, RAG Engine quickstart. https://docs.cloud.google.com/vertex-ai/generative-ai/docs/samples/generativeaionvertexai-rag-quickstart

[^google-ranking]: Google Cloud Agent Search, Ranking API. https://docs.cloud.google.com/generative-ai-app-builder/docs/ranking

[^databricks-search]: Databricks AI Search. https://docs.databricks.com/aws/en/ai-search/ai-search

[^databricks-query]: Databricks AI Search, Query retrieval algorithms. https://docs.databricks.com/gcp/en/ai-search/query-ai-search

[^databricks-filter]: Databricks AI Search filtering guide. https://docs.databricks.com/aws/en/ai-search/filtering-guide

[^snowflake-search]: Snowflake Cortex Search overview. https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-search/cortex-search-overview

[^snowflake-scoring]: Snowflake Cortex Search, Customizing scoring. https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-search/cortex-search-customize-scoring

[^snowflake-query]: Snowflake Cortex Search, Query a Cortex Search Service. https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-search/query-cortex-search-service

[^snowflake-search-update]: Snowflake, Mar 12 2026 Cortex Search updates. https://docs.snowflake.com/en/release-notes/2026/other/2026-03-12-recent-cortex-search

[^snowflake-analytical]: Snowflake Cortex Agents, Analytical search. https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-agents-analytical-search