原文标题：Knowledge needs a meta-knowledge layer
原文链接：https://www.pinecone.io/learn/series/beyond-retrieval/knowledge-needs-meta-knowledge/
在第 1 部分里，我主张：成熟 RAG 系统中的核心失败，并不是狭义上的 retrieval 失败。系统即使能检索到权威且相关的文本，仍可能给出错误答案，因为它从未判断这些证据是否“在这里、现在、在这些条件下”适用。那就是 applicability 问题。
接下来的问题是架构层面的：系统需要什么，才能在生成开始之前强制执行 applicability？
它需要的不只是一个 corpus。它需要一个 meta-layer：描述每个 knowledge base 是做什么的、何时适用、需要哪些输入、应如何查询，以及边界在哪里。它需要“知道自己知道什么”。我把这称为 meta-knowledge layer。
只要 corpus 不再是同质的，meta-knowledge 就是必需的。成熟组织会累积带条件的真值：按地区、套餐层级、产品版本、生效日期、环境或用户状态分叉的策略。最简单的 RAG 架构会把这些都当成一类东西：全部建索引，然后交给相似度搜索去排序。当 corpus 很小且内部一致时，这可能可行；但当同一个问题在不同条件下存在不同有效答案时，这种做法会失效。
延续第 1 部分的用例：用户问“我的烤面包机坏了——我能换新吗？”一个朴素系统会检索到标准零售保修、公共事业计划保修、以及更新后的故障排查要求中的相关段落。每段都“主题相关”，但它们不属于同一个策略分支。系统把它们混在一起时，会输出一段流畅但在真实流程中不会被执行的答案。
这就是 franken-answer：把局部相关的证据跨越不兼容的 applicability frame 拼接在一起。
狭义 retrieval 本身并没有问题。失败是 结构性 的。系统被要求在查询时决定 applicability，但没人告诉它组织内部的“真值分区”是怎样划分的。
组织本来就知道自己的知识并非“一种东西”。不同团队维护不同文档；不同系统记录不同流程；不同访问控制、权威等级与新鲜度规则同时存在。问题不在于这些区分不存在，而在于许多 RAG 栈没有在运行时显式表示它们。
一个有用的思考单位是 knowledge base：位于检索接口之后的一组有边界的文档。一个 knowledge base 可覆盖零售保修策略，另一个覆盖公共事业计划资格，再一个覆盖故障排查流程，还有一个覆盖履约操作。这不要求物理上分离的向量库——可以是独立索引、namespace、过滤视图或其他边界。关键在于运行时必须知道：这些是范围规则、必需输入和权威结构都不同的独立域。
但即便如此，分区只是必要条件，不是充分条件。知识一旦分区，agent 会面对新问题：这个问题该查哪个 knowledge base？它是否有足够信息去“安全地”查询？
这正是 meta-knowledge layer 的作用。
我把 meta-knowledge 的具体实现称为 “manifest”。manifest 是一个 agent 可读取的 knowledge base 契约。它描述 knowledge base 的用途、使用时机、必须先知道哪些输入、查询如何构造、哪些来源是权威，以及这个 knowledge base 的边界到哪里。
可以把它看作 retrieval 的接口描述：它定义如何调用 knowledge base，以及何时调用才是有效的。
这比普通 metadata 更广。metadata 可以告诉你文档日期、所有者、标签；manifest 告诉运行时如何在 retrieval 之前 推理 applicability。它把“关于知识的知识”变成可执行约束。
也需要说明本文不在讨论什么：问题并不是字面上的“单索引坏，多索引好”。成熟系统早已使用过滤器、namespace、ACL 和路由启发式。它们有帮助，但并不足以单独解决 applicability。更深层需求是：范围规则、必需输入、权威条件和边界条件，必须在运行时显式且可检查。
实践里，一个 manifest 可能包含五类信息：
- 身份与用途：knowledge base ID、领域描述、声明能力、期望输出。
- 输入要求：必须先知道的字段、它们的依赖关系、校验规则、哪些缺失值必须触发澄清。
- 路由与范围：knowledge base 服务的用户目标、排除场景、in-scope / out-of-scope 查询示例。
- 查询构造：在具备正确输入后，如何按模板或规则组装稳定、结构化查询。
- 权威与有效性：治理来源、新鲜度预期、生效日期、优先级规则、一致性约束。
这个顺序很重要，因为它对应运行时决策顺序。
采用 manifest 的系统能以更纪律化的方式处理 applicability：
- 路由与范围检查：agent 或 router 读取 manifests，判断哪个 knowledge base 真正匹配用户目标。如果没有任何 knowledge base 在范围内，就应尽早重定向，而不是检索“看起来相关”的文本并生成自信但错误的答案。
- 收集必需输入：manifest 声明 retrieval 有意义前必须知道什么。保修类 knowledge base 可能要求产品型号、购买或注册日期、地区和计划状态。若缺失，系统应先提问，而不是猜。
- 构造查询：选定 knowledge base 且具备必需输入后，系统按 manifest 模板/规则组装查询。这样 retrieval 会与该 knowledge base 的结构对齐，而不是依赖用户原始措辞里“碰巧出现”的词。
- 检索证据：只有此时，系统才向选定 knowledge base 请求上下文。
- 回答前一致性检查：检索结果并不自动安全可用。运行时仍需验证返回材料是否与用户分支一致、时间上仍然有效、且权威性足够支撑答案。若不满足，系统应继续提问、谨慎回答或拒答。
这套结构可处理多种常见 applicability 失败：
- 歧义（Ambiguity）：问题在语言上清楚，但对 corpus 的分支结构而言信息不足。manifest 声明哪些区分是关键、哪些缺失字段应在 retrieval 前触发澄清。
- 隐式条件（Implicit conditions）：有时 applicability 完全存在于文本之外——配置、环境、系统状态。manifest 把这些隐藏选择器（注册状态、套餐层级、发布通道）显式化，让 agent 知道在信任检索结果前必须先解析什么。
- 组合型 applicability（Compositional applicability）：来自不兼容分支的“各自正确”片段会拼出 franken-answer。manifest 声明分支变量、范围假设和一致性约束，确保证据只在同一 applicability frame 内组合。
- 权威条件（Authority conditions）：主题相关文本不一定有足够权威来支撑答案。manifest 区分治理性来源与解释性/从属性来源，使运行时能优先选择规范性材料。
- 粒度不匹配（Granularity mismatch）：agent 可能把窄例外用得太宽，或在需要具体答案时给出泛化答案。manifest 声明 knowledge base 支持的细粒度级别，以及安全收窄答案所需额外输入。
- 路径收敛（Path convergence）：不同逻辑路径可能收敛到表面相同答案，但附带不同约束与后续流程。manifest 让分支边界显式化，使 agent 跟踪自己所处治理路径，而不仅是“答案听起来对不对”。
- 时间适用性（Temporal applicability）：检索信息可能曾经为真，但已不再生效。manifest 声明生效日期、新鲜度预期、版本优先级与替代规则，使运行时区分当前真值与历史真值。
这就是为什么高 recall 不够。向量检索擅长找“相关段落”，但“相关”弱于“适用”。
支持系统可能因为匹配“烤面包机更换”而检索到标准 24 个月零售保修，即便该设备来自公共事业计划，真实条件是 12 个月窗口加注册要求。两种情况下 retrieval 看起来都很好，答案仍可能错误。缺失的不是更多语义相似度，而是可执行的 applicability 约束。
烤面包机示例很清楚地说明了操作层面的差异。
没有 meta-layer 时，agent 会在所有可用来源里搜索并抓住“听起来最近”的指导：检索零售保修、计划保修和 1 月 1 日后新增故障排查要求，再把它们混成一个看似有帮助、却不对应任何有效分支的答案。
引入 meta-layer 后，行为会变化：
- routing 在零售保修、公共事业计划保修、故障排查、履约之间做选择；
- scope 规则阻止 agent 查询不适用于该用户的 knowledge base；
- input gating 收集缺失约束（注册日期、型号、地区、计划成员身份）；
- query construction 为选定 knowledge base 生成稳定且带范围的查询；
- consistency checks 在产出答案前拒绝跨分支或过期证据。
两套系统的 retrieval 骨干可以完全一样。差别是：一个把 applicability 作为显式运行时问题处理，另一个把它交给运气。
这对 agentic 系统更关键。agent 一旦可以调工具、修改状态、触发工作流，选错 knowledge base 带来的就不只是错误段落，而是错误动作。
一个被要求重启支付服务的运维 agent，应先验证环境、权限和部署拓扑，再选择 runbook。一个计费 agent 在变更用户套餐前，应先验证账户状态、套餐层级和地区。原则与 RAG 一样：agent 不能仅因找到语义相关流程就行动；只有该流程的 applicability 条件被满足时才应行动。
这种方法有成本。manifest 需要编写、维护，并与底层 knowledge bases 保持同步；它们会漂移。它们也不能替代高质量 retrieval、来源治理和判断力。但它强制了一种有价值的纪律：同一个组织在整理知识时，也必须以运行时可检查的形式声明范围、权威与前置条件。实践中，这往往比把这些逻辑藏在 prompts、heuristics 和“希望”里更不脆弱。
RAG 的实际上限不是 recall，而是在真实约束下的 applicability。
当 meta-knowledge layer 被表达成具体工件时，它才真正可操作：每个 knowledge base 一个 manifest，再配一个读取 manifests 的 planner，决定该问什么、查什么、如何编排序列调用，以及在什么情况下根本不应回答。
所以，当你看到一个“流畅但错误”的答案，不要只问“系统检索到了什么？”要问更难的问题：它是否为用户目标选对了 knowledge base？它是否具备必需输入，还是应先澄清？证据是否权威、当前有效且内部一致？以及系统是否本就不该回答？
在本系列下一篇里，我们会进入实践部分：用 progressive introspection 技术和基于 LLM 的 planning / routing，创建一个可运行的 manifest 与 planner。
引用
- 原文：Knowledge needs a meta-knowledge layer
https://www.pinecone.io/learn/series/beyond-retrieval/knowledge-needs-meta-knowledge/ - 系列页：Beyond Retrieval
https://www.pinecone.io/learn/series/beyond-retrieval/