RAG 不是万能记忆：知识库效果取决于内容治理

检索增强生成常被解释为：让模型先找到相关资料，再根据资料回答问题。相比完全依赖模型记忆，它提高了可追溯性，也允许组织使用自己的内容。但当知识库效果不好时，很多团队第一反应是更换模型或调整提示词，忽略了更基础的部分：资料本身是否清楚、可靠、可被找到。

知识库不会自动把混乱文档变成可靠事实。重复版本、过期政策、模糊标题和缺失权限都会进入检索结果。RAG 只是把问题暴露得更快。如果没有内容治理，更懂检索的模型可能更迅速地引用一份早就失效的说明。

文档要有单一事实来源

同一个主题存在多个版本时，系统需要知道哪一份是当前有效内容。可以设置明确的主文档、归档状态和更新时间，其他副本只作历史参考。文件名和标题应描述问题与范围，而不是“最终版”“新版”“张三修改版”。

主文档还要有负责人。负责人不需要亲自回答每次提问，但要决定内容何时更新、哪些变更影响其他文档。知识库可以显示最近确认日期，帮助读者判断信息的新鲜程度。对于价格、限制条件和流程，来源系统通常比复制文本更可靠。

为了检索，长文档会被切成多个片段。切得过短，模型可能看不到上下文；切得过长，又会混入无关内容并降低匹配精度。好的切分通常顺应自然结构，让标题、步骤和前提条件与被解释的内容保持在一起。

表格和复杂流程最难处理。只抽取表格中的一行，可能丢失列标题和适用范围；把整张流程图转成文字，也可能引入错误。对关键表格，应保留结构化版本，让检索同时返回完整表头与必要说明。不能为了统一格式破坏原信息。

知识库测试不应只问几个已经知道答案的问题。准备一组真实工作场景，包括直接查询、需要综合两份文档的问题、权限受限的问题和资料不足的问题。记录答案是否正确、引用是否准确、是否承认不知道，以及用户完成判断所需时间。

还要加入过时内容干扰。把一份旧政策与新版同时放入测试库，观察系统是否优先返回当前有效版本；加入相似但不相关的文档，检查是否会拼接错误。只有测试错误案例，才能知道治理规则是否有效。

评价集需要持续维护。产品、制度和团队语言会变化，旧问题可能不再代表当前工作。每个季度补充新案例，删除已经失效的测试，并记录模型或检索策略的变化。把评价当成一次性验收，很容易在系统更新后失去比较基础。

用户反馈也应进入流程。遇到答案错误时，不只点击“不喜欢”，还要标记对应的文档片段。这样内容团队可以修正原文，技术团队可以判断切分或排序是否有问题，而不是反复猜测模型为什么出错。

文档更新后，系统应处理旧索引、缓存摘要和历史引用。如果一份政策已经删除，问答仍引用旧文本，用户就无法判断结果是否可靠。更新流程需要包含失效检测、重新索引和验证，而不是依赖人工偶然发现。

版本发布说明也有价值。告诉用户哪些内容发生变化、何时生效，可以减少旧答案被继续传播。对于长期知识库，更新时间本身就是可信度的一部分。

历史问题与删除权也要一起考虑。用户问过的问题可能包含个人或项目信息，知识库不应为了“优化体验”无限保留。系统需要区分必要的审计日志、可用于改进的匿名统计和原始对话内容，并设置不同的访问权限与保留期限。

内容所有者应能看到自己的文档被哪些场景引用。若一份内部说明频繁出现在不该出现的答案里，就能及时调整范围。可见性不是公开所有日志，而是给负责人足够证据做出管理判断。

检索系统能找到什么与用户能看什么，是两个不同问题。权限继承设计缺失时，模型可能把用户无权查看的片段写进摘要。治理流程应明确资料分级、访问规则和错误处理方式，再让检索层执行这些规则。

对高敏感材料，宁可让系统回答“没有足够可访问的资料”，也不要使用模糊内容拼出看似完整的答案。知识库的目标是帮助工作，不是让所有问题都得到回复。

RAG 可以帮助组织更快利用已有材料，却无法替代写作、归档和责任人制度。先把当前有效内容找出来，把重复和过期材料清理掉，再建立一个围绕真实任务的评价集，模型升级才会带来稳定收益。

知识库建设更像长期编辑工作，而不是一次技术部署。每次问答都在检验组织是否知道自己的事实放在哪里。资料越清楚，检索和生成才有可靠的基础。