RAG 真正难的不是检索，是知识真源
RAG 项目最常见的优化讨论，围绕切分长度、召回数量、向量模型和重排展开。它们当然重要，却默认了一个更基础的前提：进入索引的知识本身是对的，而且系统知道什么时候该用哪一份。
现实里，答案错误往往不是“没搜到相似文本”，而是搜到了旧版规则、无权访问的材料、未经批准的草稿，或者两份互相冲突的正式文件。检索越准，反而可能越稳定地返回错误来源。
因此，RAG 的第一产品问题不是怎么搜，而是哪份知识最后算数。
从带资料回答，到带证据回答
RAG 改变的不是模型记住了多少，而是回答时可以读取外部证据。一个最小链路包括：理解问题、检索候选、排序、装配上下文、生成答案和展示引用。
但“引用了一段原文”不等于证据成立。产品还需要确认，这段原文属于哪个文档和章节，是否已经批准，何时生效，适用于谁，是否被新版本替代，用户是否有权看到。
文本相似度只能回答“意思像不像”，不能回答“现在能不能用”。后者必须由元数据、权限和业务规则共同决定。
每一块知识都要有身份证
一段内容进入索引前，至少应该绑定文档标识、段落位置、内容版本、状态、生效与失效时间、权威级别、适用对象、访问范围、Owner、来源位置和内容摘要。
这些字段不是为了让知识库看起来专业，而是为了支持真实决定：
- 两段内容冲突时，系统能判断哪一份级别更高；
- 用户询问历史情形时，能按当时生效版本回答；
- 权限变化后，无权材料不会继续通过向量检索泄露；
- 来源更新后，可以找到受影响的索引、缓存和答案。
如果两个同级正式来源冲突，系统也不该选一句更顺耳的。正确行为是展示冲突，说明无法自动决定，并交给知识 Owner 收口。
Owner 比 Top K 更重要
每类知识都需要明确谁对内容正确和更新负责。平台团队可以保证解析、索引和服务可用，模型可以组织语言，产品可以定义回答边界，但它们都不能代替业务 Owner 确认规则本身。
没有 Owner 的知识库，更新依赖偶然发现。用户报错后，团队会围着 Prompt 和检索参数排查，却没人决定旧文件是否应当失效。技术层不断优化，知识层仍在腐烂。
一个健康的知识源清单应该能回答：更新由什么事件触发，多久检查一次，冲突如何升级，撤回由谁发起，哪些问题必须拒答。RAG 不是一次性导入项目，而是一条知识生命周期。
更新、过期和删除不是一件事
新版本生效时，旧版本可能还要保留用于历史审计，但不能再进入默认当前回答。这是过期，不等于物理删除。
来源因授权、错误或保存要求被撤回时，则要触发删除闭环：原文、分块、向量索引、关键词索引、缓存和派生摘要都要被处理。只删网页、保留旧向量，用户仍可能从问答中看到已经不存在的知识。
删除后的验收也不能只看旧链接是否失效。还要用原句、同义问法、编号和缓存路径查询，证明它不再参与回答。
更新解决新旧交接，过期控制默认适用范围，删除处理继续使用的权利。三者混在一起，系统就无法同时满足当前回答、历史解释和真正撤回。
评测要沿知识链分层
只看最终答案，会把所有错误都推给模型。更有效的评测至少分四层：
- 数据与索引层：应该进入的资料是否完整、可解析、有正确元数据。
- 检索层：正确证据是否被召回，错误版本和越权内容是否被过滤。
- 回答层：结论是否忠实于证据，引用是否支持前面的判断。
- 系统与业务层：延迟、权限、反馈、拒答和人工升级是否可用。
同一个错答案，可能是证据根本不存在、解析丢表格、切分破坏语义、排序靠后、上下文装配遗漏，也可能是模型无视证据。只有定位到责任层，修复才不会退化成无休止调参。
复杂 RAG 不是默认答案
多路召回、重排、图结构和 Agentic RAG 都能解决特定问题，也会增加版本、成本、调试和治理负担。引入复杂度前，应先证明基础知识治理已经成立，并说明新组件要减少哪个明确失败。
如果旧规则没有失效、权限没有过滤、来源没有 Owner，再复杂的检索只能把不可靠知识送得更快。
可信来自治理，不来自语气
RAG 很容易让回答听起来更有依据，因为页面上出现了引用。但真正的可信不是“像证据”，而是证据有身份、有效期、权限、责任人和撤回路径。
检索是找到候选，知识真源才决定候选有没有资格进入答案。先治理知识，再优化检索，通常是 RAG 产品最不性感、也最不能跳过的一步。