如何保证知识库的质量

本文只讨论通用方法与判定策略，不涉及任何具体业务、系统与数据。文中出现的比例来自一次真实盘点的形状，不同知识库差异会很大，不必直接套用。

一、先接受一个事实：错误的内容比没有内容更糟

一个 RAG 系统答错了，排查顺序通常是：改 prompt → 换 embedding → 调 chunk 大小 → 加 rerank。这个顺序在大多数时候是错的。

因为如果知识库里躺着一篇两年前就已经下线的功能说明，那么无论检索多准、模型多强，结果都是准确地检索到了错误答案，然后自信地讲了出来。更糟的是，这种错误在评测集上往往抓不到——评测集是照着"应该有的知识"写的，而不是照着"库里实际有什么"写的。

所以知识库质量不是内容运营的事，是系统质量的一部分。而它的第一性问题是：

知识库里的内容会腐坏，而腐坏是持续发生的。

一次性清理解决不了持续发生的问题。所以真正要建立的不是"一次治理"，而是一套可重复执行的判定标准。

二、腐坏有固定的形状

好消息是，知识库的腐坏不是随机的。把一个真实知识库扫一遍，问题几乎全部落在五类模式里：

A · 文档级废弃——整篇已经作废。信号有两处：

• 标题标记：DEPRECATED / Archived / Obsolete / Sunset / [INACTIVE]，中文的「已下线」「已废弃」「已停用」「作废」；
• 状态横幅：正文开头的声明，如「本文档已废弃」「this doc has been deprecated」「please refer to the latest version」，以及草稿水印「WIP - do not use」「尚未审批，请勿使用」。

一个实现细节：状态横幅只扫前若干行非空内容（比如 25 行）。因为「deprecated」这个词出现在文档中段时，通常是在讲某个功能废弃了，而不是在说这篇文档废了。位置本身携带语义。

B · 段落级废弃——文档还有效，但其中某段描述的功能已经下线。信号是明确的完成时表述：has been sunset / discontinued / removed / phased out、no longer available / supported、X has been replaced by Y。

注意必须是已生效的下线，而不是「计划于下季度下线」。预告下线的内容此刻仍然正确，提前删掉反而制造了信息缺口。

C · 冲突——同一件事在库里有多个说法，分三种：

• 正文完全重复：抛开标题，正文一字不差。这是纯冗余；
• 版本重叠：同一主题的多种形态（简介版 / 一页纸 / 完整手册）并存，内容有出入；
• 废弃与在用并存：同一份文档里，某功能在一处被声明废弃，在另一处仍被当作在用。

三种里，只有第一种机器能自己解决。

D · 陈旧——最后更新时间距今超过一年（重点是超过两年）。

E · 旧稿残留——作者自己标了 OLD: / [OLD] 前缀的历史版本，但一直挂在库里没删。

一次真实盘点里，这几类问题的分布大致是这个形状：

这个分布里最值得注意的是：接近六成的问题是机器可以独立判定的（完全重复 + 标题标记废弃 + OLD 旧稿）。这就是为什么治理必须先做分类——如果一上来就组织人工逐篇审阅，一大半的人力会花在机器三秒钟就能给出答案的事情上。

三、真正的难点：区分"废弃信息"和"废弃的信息"

这是整件事里最容易做错的一步，也是我认为最有洞察力的一条判定规则。

假设一个段落写着：

「X 功能已于上月下线，请改用 Y。」

一个粗糙的规则会命中「已下线」，把这段标记为待清理。但这段话恰恰是知识库里最有价值的内容之一——它是一条转场指引，它的作用就是防止使用者继续用旧功能。删掉它，一线的人只会更困惑：他记得有个 X，搜不到任何说明，于是继续用错。

真正需要治理的，不是「提到废弃」的段落，而是「这条废弃注记本身已经发霉」的段落——文档整体很久无人维护，里面的下线说明写于三年前，指向的替代方案 Y 现在也已经不存在了。

所以判定的关键不在段落里那个词，而在这份文档还有没有人在维护。同样一句「X 已下线，请改用 Y」，出现在上个月刚更新过的文档里是资产，出现在三年没动过的文档里是负债。

这条规则可以推广成一个更一般的原则：

判定内容是否有效，不能只看内容本身，要看它所在文档的生命体征。

四、按"判定可靠性 × 危害"分级处置

把七类问题放进一个二维坐标：横轴是判定结论的可靠性（机器判完能不能直接执行），纵轴是危害程度（进入答案后造成错误的可能）。

处置矩阵：象限决定处置方式，而不是问题的严重程度决定

四个象限对应四种完全不同的处置方式：

② 自动处理（高可靠 + 高危害）——文档级废弃。标题里写着 DEPRECATED，几乎不可能是误判，而它一旦被检索到就会直接给出错误答案。这类应该直接下架，不需要人工排队。

④ 批量清理（高可靠 + 低危害）——正文完全重复、OLD 旧稿。判定极其可靠（归一化后哈希相同），但危害有限——重复内容不会让答案变错，只会稀释检索排序、浪费索引空间。可以攒着批量做。

去重有两个实现要点：归一化（去掉 Markdown 符号、图片、链接、长数字再算哈希，否则一个换行差异就判不出重复）和跨标题检测（同样的正文换个标题挂两处，是最常见的重复形态）。

还有一个原文没有回答、但实际必须回答的问题：留哪一份？ 更新时间最新的？访问量最高的？入口层级最浅的？这个选择必须写成明确规则，否则"每组留一份"在执行时会变成一次次的临时决策。我的建议是按「最后更新时间」优先，相同则取入口路径最短的——理由是它更可能是被主动维护的那一份。

① 人工优先队列（低可靠 + 高危害）——版本重叠、段落级废弃、解析丢失。这类危害最大，但机器给不出可执行的结论：简介版和完整手册哪个是权威版本，只有业务方知道。

关键是，"交给人"不等于"甩给人"。系统仍然应该做完所有能做的准备工作：把同组文档的差异点自动 diff 出来、标出各自的最后更新时间和访问频次、给出一个推荐答案让人确认而不是让人从零判断。把人工环节的输入从"一堆文档"变成"一个待确认的结论"，效率差一个数量级。

③ 标记观察（低可靠 + 低危害）——陈旧文档。

五、陈旧是最弱的信号

时间是所有信号里判别力最差的一个：旧不等于错。一份三年没更新的基础概念说明可能依然完全正确，而一份上周更新的文档可能正在描述一个昨天刚下线的功能。

从实际分布看，未更新时长的长尾是这样的：一到两年的文档数量最多，但其中大部分仍然有效；两到三年的失修风险明显上升；超过三年的数量最少，但内容可信度最存疑。

所以陈旧的正确用法不是触发删除，而是触发复核，且要按时长分层给不同的动作：

这里的「降权」比「删除」重要得多。删除是不可逆的，而降权只是让它在有更新鲜的答案时排不上去——当没有别的答案时，一份三年前的文档仍然好过没有答案。

六、一个更隐蔽的问题：内容根本没进来

前面讲的都是"库里有错的内容"。还有一类问题更难发现：库里少了本该有的内容。

典型场景：文档里的表格不是直接写在这篇文档里的，而是引用自另一个数据源（协作文档平台普遍支持这种引用式嵌入）。解析器抓取正文时，拿到的只是一个引用占位，表格里的实际数据从未进入切片。

于是知识库看起来一切正常——文档在、字数够、索引建好了——但那份关键的价格表、参数表、对照表，从来就不在里面。用户提问，检索命中了这篇文档，模型看着一段没有表格的正文，只能含糊其辞或者干脆编一个。

这类问题的隐蔽性在于：它在任何"内容质量"指标上都不会报警。要发现它，只能主动做一次"解析完整性"审计——抽样比对原始文档和解析后的切片，看有没有整块内容凭空消失。至少要覆盖这几种结构：引用式表格、嵌入的子文档、图片中的文字、折叠区块、附件。

我的判断是：任何知识库上线前，都应该先跑一次解析完整性抽检，而不是等到答不好再回头查。 这件事的成本远低于它暴露的风险。

七、一次性治理必然失败

前面所有内容，如果只执行一次，那么半年后知识库会回到原样。因为腐坏是持续的，而治理是一次性的。

要让质量稳定，必须把判定标准从"一次盘点脚本"变成"三个常驻机制"：

写入侧的约束。 让文档带上结构化状态：status（有效 / 已废弃 / 草稿）、valid_until（可选的有效期）、superseded_by（被哪篇替代）。有了这三个字段，规则 A、B、C 的绝大部分判定从"猜"变成"读"。这是投入产出比最高的一步，也是最难推动的一步——因为它要求写文档的人多做一件事。

入库前的检查。 新文档进库时就跑一遍判定：和现有内容哈希重复吗？标题带 OLD 前缀吗？状态字段是废弃吗？解析后内容是否明显短于原文？在入口拦住，比进库后再清理便宜一个数量级。

周期性扫描 + 责任归属。 定期重跑全量判定，产出的不应该是一张表格，而是带负责人、带截止时间的工单。这是最关键的一点：一份没有归属人的废弃文档，永远不会有人去废弃它。治理清单发给"所有人"等于发给没有人。

八、最后

把这件事抽象一层：知识库是一个持续增熵的系统。每写入一篇文档，就多一份未来会过期的内容；每复制一次，就多一处将来会分叉的版本。

而质量保证做的事情，就是持续地往里注入负熵：用规则把可判定的腐坏自动清掉，用流程把不可判定的部分分派给能判定的人，用约束让新增内容自带可判定的元数据。

这三件事里，只有第一件是技术问题。后两件是组织问题——而知识库质量最终的天花板，往往正是由后两件决定的。