企业知识库不维护，它会开始骗人

一条。

只往检索结果里注入一条过期段落，Llama-70B 的表现就掉了下去。据 HoH 这份 benchmark 的论文正文，在这个条件下，「Llama-70B's perfect scores drop by over 10%, harmful outputs increase by up to 11%, and overall scores decrease by more than 24%」。换成更小的模型更难看：「The smaller models – Llama-8B and Qwen-7B – ... Their perfect scores fall by approximately 20%, and harmful outputs increase by up to 18%.」

一条。不是一半文档过期，不是知识库年久失修，是一条。

十家里有八家，是这么规划知识库预算的：把公司的制度、产品手册、报价单、常见问题一股脑扔进去，算一笔搭建的钱，然后这件事就算完了。搭建这一步的账其实好算，真正没被算进预算的是另一笔——让这批文档一直是对的，需要多少人、多少时间、按什么条件触发。

这一篇不谈怎么搭，只谈那笔没被算的账，以及为什么不算它的后果不是「不好用」，是「它开始骗人」。

一、「骗人」不是修辞：先看这份专门测过期的研究

先把这份研究的身份说清楚，因为它是本文最硬的一块砖。

论文题为 HoH: A Dynamic Benchmark for Evaluating the Impact of Outdated Information on Retrieval-Augmented Generation，arXiv 编号 2503.04800，2025 年 3 月 3 日提交，作者为中国科学技术大学 Jie Ouyang 等。摘要里自陈其定位是「the first benchmark specifically designed to evaluate the impact of outdated information on RAG」。

它给出的结论有两条，而且分得很清楚：

「outdated information significantly degrades RAG performance in two critical ways: (1) it substantially reduces response accuracy by distracting models from correct information, and (2) it can mislead models into generating potentially harmful outputs, even when current information is available.」

请把第二条的后半句读两遍：even when current information is available。也就是说，即便正确的、当期的资料就在检索结果里躺着，一条过期段落照样能把答案带偏。这句话推翻了一个非常普遍的侥幸——「老文档留着没关系，反正新的也在里面」。

摘要的最后一句是：「Current RAG approaches struggle with both retrieval and generation aspects when handling outdated information.」检索这一环和生成这一环，都没解决这件事。

回到开头那三个数。据该论文正文，只注入一条过期段落的条件下：perfect scores 掉超过 10%，harmful outputs 涨最多 11%，overall scores 掉超过 24%。小模型那一组，perfect scores 掉约 20%，harmful outputs 涨最多 18%。

十家里有八家用来做知识库问答的，恰恰是参数量更小、更便宜的那一档。而在这份研究里，小模型那一组的降幅更大。

二、另外三份研究，各自补上了一块，也各自有各自的边界

一份研究撑不起一个结论。所以下面三份要一起看，但每一份的口径都不同，不能混着用。

第一份，ClashEval（arXiv 2404.10198，2024 年 4 月 16 日，斯坦福 Kevin Wu、Eric Wu、James Zou）。 原文写道：「we curate a dataset of over 1200 questions across six domains... We benchmark six top-performing LLMs, including GPT-4o... and find that LLMs are susceptible to adopting incorrect retrieved content, overriding their own correct prior knowledge over 60% of the time.」

六成。模型自己本来是知道正确答案的，检索给它塞了一份错的，它有超过六成的概率放弃自己原本正确的判断，改跟检索走。

但这里必须把口径写清楚：ClashEval 里的错误内容是人为注入的，不是自然过期产生的。 它证明的是「模型倾向于服从检索结果」这个机制，不是「过期文档一定导致六成错误」。拿这个 60% 去描述你自己知识库的错误率，是把两件事混成了一件。

第二份，Contradictions in Context（arXiv 2511.06668，2025 年 11 月 10 日）。 它做的是医学领域，方法是按发表年份分层检索 PubMed 摘要，「stratified across multiple publication years, to enable controlled temporal evaluation of outdated evidence」。结论是：「contradictions between highly similar abstracts do, in fact, degrade performance, leading to inconsistencies and reduced factual accuracy in model answers. These results highlight that retrieval similarity alone is insufficient for reliable medical RAG」。

最后那半句值得单独拎出来：光靠「检索得相似」是不够的。 你的向量检索把最相关的五段找回来了——这五段里如果有两段是三个版本之前的旧制度，相似度不会因为它旧就变低。相似度不认时间。

这份研究的摘要里没有给百分比，所以本文也不给。它能支撑的只有一条定性结论。

第三份，Astute RAG（arXiv 2410.07176，2024 年 10 月 9 日）。 一句话：「we find that imperfect retrieval augmentation is inevitable, common, and harmful. We identify the knowledge conflicts between LLM-internal and external knowledge from retrieval as a bottleneck」。不完美的检索是不可避免的、常见的、有害的。

还有一份更早的，FreshLLMs / FreshQA（arXiv 2310.03214，2023 年 10 月 5 日），基于「more than 50K judgments」的人工评估，结论是「all models (regardless of model size) struggle on questions that involve fast-changing knowledge and false premises」。不分模型大小，都在变化快的知识上栽跟头。

下面说两件本文没有的东西，这一段比上面四份研究更重要。

第一，「企业知识库多久开始出问题」这个时间数字，本文给不出来。 你可能在别处见过「三个月」这类说法——本文不用它，因为查不到任何一手来源支持这个数字。这一篇后面会给一个检查周期，那个周期是本文给出的操作建议值，不是任何研究得出的结论，不要把它当数据引用。

第二，「企业知识库里的文档平均有多少比例是过期的」，以及「国内有没有知识库或智能问答出错导致纠纷、被通报」的公开案例，本轮都没有找到可核验的一手来源。 所以这一篇里不会出现任何过期率的百分比，也不会出现任何「某地某公司因此被投诉」的说法。没有就是没有——在这个话题上补一个听起来合理的数字，恰恰是本文正在反对的那件事。

三、维护三件套：责任人、触发条件、过期标记

前面说的都是「会坏」。这一节说怎么办。

好消息是，这件事的操作规范不需要你自己发明，云厂商的官方架构文档里已经写成条目了。下面三步，每一步都能对应到一句官方原文。

第 1 步：先定新鲜度要求，再定责任人。

微软 Azure Well-Architected Framework 的《Grounding data design》（ms.date 2025 年 5 月 28 日，页面标注更新于 2025 年 10 月 30 日）里有一句反直觉的话：「Measure the window of time between source data creation or modification and its addition to the index as an indicator, and track it against SLOs... An index should only be as fresh as is required.」

索引只需要新到「被要求的那个程度」。 这句话的价值在于它把「多久更新一次」从一个技术问题变成了一个业务问题。报价单和当天的库存，要求是小时级；员工手册和产品说明，可能是季度级；公司历史沿革，可能永远不用更新。

所以第 1 步的动作是：把你扔进知识库的文档分成三档，每一档写明「允许它落后多久」。这个「多久」由业务决定，不由技术决定。定完之后，每一档指定一个具体的人名——不是一个部门，是一个人。部门不会记得更新文档，人会。

这里要诚实一句：上面这句「三档」和后面要给的检查周期，是本文给出的操作建议，微软原文只写了那句「as fresh as is required」和「measure the window」，没有规定档位数。

第 2 步：把更新触发条件写死，而不是靠人想起来。

AWS 在 Bedrock 知识库的官方文档里把机制说得最直白：「Each time you add, modify, or remove files from your data source, you must sync the data source so that it is re-indexed to the knowledge base. Syncing is incremental...」；其 sync scenarios 表里写着：「No changes detected → The document is skipped.」/「Content or metadata changed → The document is re-ingested (re-parsed, re-chunked, re-embedded, and re-indexed).」

要注意这条只能支撑一件事——必须有一套同步流程。它没有说「不同步就会答错」，本文也不这么写。

微软那份《Data platform for AI workloads》（ms.date 2025 年 11 月 11 日）补上了另一半：「Does the index support automatic update capabilities when the data in the data sources changes? Automation is key for maintaining data freshness.... If the platform doesn't offer this natively, you'll need to implement a custom process to detect and push updates.」

翻成中小企业能落地的话：触发条件不能是「谁想起来了谁去更新」，得挂在一个已经存在的动作上。 比如价格调整审批通过的那一刻、制度文件盖章归档的那一刻、产品参数在官网改动的那一刻。挂不上自动化，就挂在一个既有的审批节点上——总之不能挂在记性上。

第 3 步：给过期内容打标记，而不是等它自己消失。

同一份微软文档里写着：「To exclude outdated content from an index, consider the use of metadata that prevents search engines from indexing specific pages or content.」以及关于更新方式的建议：「Update your index to prevent inferencing on stale data. When you update an index, consider adopting a side-by-side deployment strategy for maintenance. Rebuilding the index ensures that deletions and updates are handled because the index becomes a fresh data set.」

这一步在中小企业最容易被跳过，因为「删掉旧文档」这个动作没人敢做——万一以后要查呢。结果就是旧版本一直躺在库里，而第一节那份研究说得很清楚：一条就够了。

可执行的最小做法是给每份文档加两个元数据字段：生效日期和失效条件。失效条件写不出来的文档，说明它压根不该进知识库，该放归档区。至于「多久检查一次」——本文给的建议值是每季度一次全量清点，另加每次触发条件命中时的即时更新。这个季度是本文的操作建议，不是任何研究得出的数字。

三步做完，你的知识库维护有了责任人、有了触发条件、有了过期标记。这三样东西加起来的成本，就是下一节要算的账。

四、这笔账：维护是要花钱的，留着不管同样花钱

先说一个容易被忽略的事实——这三步的代价，微软自己在同一份文档里写了。

原文是这么写的：「Tradeoff. Add, update, and delete actions against an index are expensive... Keeping obsolete documents in the index incurs storage, maintenance, and querying costs.」

请把这两句并排读：对索引做增删改是贵的；而把过期文档留在索引里，同样在产生存储、维护和查询的成本。

两头都要花钱。 这就是这笔账的真实形状——它不是「花钱维护」和「不花钱不维护」的二选一，是「花钱维护」和「花钱养着一堆会骗人的旧文档」的二选一。后者看起来免费，只是因为账单上没有那一行。

第二笔代价是人。第三节那三步里，第 1 步要业务方来定新鲜度档位，第 2 步要有人把触发条件接进现有流程，第 3 步要有人每季度做一次全量清点。这些都不是一次性动作，是固定占用。中小企业最稀缺的资源不是服务器，是那个既懂业务又愿意做这类琐事的人——把这件事排给他，就意味着别的事排不进去。

第三笔代价，是你把维护做到位了，检索本身仍然会失手。

Anthropic 在 2024 年 9 月 19 日公开的一组数据可以说明这件事的量级：「Contextual Embeddings reduced the top-20-chunk retrieval failure rate by 35% (5.7% → 3.7%)」；「Combining Contextual Embeddings and Contextual BM25 reduced the top-20-chunk retrieval failure rate by 49% (5.7% → 2.9%)」；「Reranked Contextual Embedding and Contextual BM25 reduced... by 67% (5.7% → 1.9%)」。

这组数必须带一个说明才能用：它讲的是分块时丢失上下文导致的检索失败率，不是文档过期。 拿它论证「过期」是偷换概念。它在这里只用来说明一件事——即便用上了这一整套优化手段，把失败率从 5.7% 压到 1.9%，仍然有 1.9%。按 1.9% 算，每检索一百次，仍有约两次没能把该拿的那一段拿回来（这个换算是我做的，只是把百分比还原成次数，方便你有个体感）。

所以知识库这件事的期望值要摆正：维护做到位，是把「经常骗人」变成「偶尔答不上来」，不是把它变成永远正确。 谁跟你说做完就万无一失，你可以直接把这一节甩给他看。

什么时候不该建这个知识库

最后说边界，这一段比前面四节都重要。

第一，如果你的文档基本不变，这套维护体系是纯浪费。 一份三年没改过的工艺标准、一套已经定型的产品参数——它们不需要责任人、不需要触发条件、不需要过期标记。第三节那三步全部是为「会变的文档」设计的。文档不变，直接建、建完不管，是对的。

第二，如果你的文档变得太快、快到超过了你能维护的频率，这件事该往回退一步。 火山引擎的官方文档里对这种情形给过一个明确的分流建议：时效性强的信息检索需求，建议走联网内容插件；确定域内的信息检索需求，才走知识库插件。变得比你更新得还快的东西，本来就不该沉淀成知识库文档。

第三，如果你的知识库要回答的问题会直接影响客户的钱或者安全，第一节那三个数字就不是「性能下降」，而是风险。 报价、库存、合同条款、涉及资质与安全的说明——这几类内容如果拿不准是不是最新版，宁可不让机器答，转人工。「答错了但答了」比「转人工慢了十分钟」贵得多。

第四，如果你连「哪份文档是最新版」这件事在人工层面都说不清楚，先别建知识库。 机器不会替你解决版本管理的问题，它只会把混乱按原样、更快地、以更权威的口吻复述出来。知识库不生产准确，它只放大你已有的准确或不准确。 先把线下的版本管理理顺，再谈上系统——这是全篇唯一一个我建议你在读完之后立刻去确认的事。

至于「该不该为这件事去做模型微调」，那是另一笔完全不同的账，本站另有一篇专门讲。