知识半衰期问题：为什么你的 RAG 系统现在就已经出错了

你的 RAG 系统通过了所有检索基准测试。准确率看起来很稳健。LLM 评估器评分全部绿灯。然而，在你的索引某处，存在一份描述八个月前已废弃 API 端点的文档、一个已不复存在的定价层级，以及一项在第三季度被新法规取代的合规政策。检索器对此毫不知情。语义相似度没有时间概念。

这就是知识半衰期问题：一种隐蔽的失效模式——RAG 系统在你所有监控指标上看起来健康运行，却在向用户提供越来越陈旧的决策依据。73% 的组织报告称，RAG 部署在 90 天内出现准确率下滑——原因不是检索架构缺陷或 Embedding 模型质量问题，而是没有人将知识过期建模为可靠性关注点。

为什么语义相似度无法拯救你

根本问题在于架构设计。向量相似度衡量的是查询与文档语义的匹配程度，而非该文档最后一次准确的时间。一段描述 18 个月前已废弃认证流程的内容，在用户询问登录问题时可能获得 0.92 的相似度分数——因为内容在语义上高度对齐。检索器返回它，LLM 采纳它，用户得到了被自信传递的错误信息。

这个悖论在规模扩大时愈发明显。1000 份文档的语料库可以相对容易地维持亚小时级的新鲜度。在 10 万份文档时，每晚批量重建索引会造成 12 小时的过期窗口作为底线。在百万文档规模时，多天延迟成为常态。大多数团队还会雪上加霜——让所有领域在同一条流水线节奏下运行，让那些以月为单位过期的法规指南与以小时为单位过期的竞争定价数据执行同样的夜间任务。

这一问题之所以严重，是因为这种失效模式在用户眼中和为捕捉幻觉而设计的 LLM 评估器眼中，看起来与幻觉一模一样。当模型声称 SAML 在企业版计划中受支持——因为索引文档如此记载，而 SAML 在 v3 版本中已被移除——没有任何检索评分器能捕获这个错误。该文档语义相关，其中的信息曾经为真，评估通过。只有实际在生产环境中配置 SAML 的用户才会发现问题所在。

文档的老化速度并不相同

解决这一问题的第一步，是承认新鲜度是领域属性，而非系统属性。不同类型的内容以根本不同的速率衰减：

• 定价和配置数据会在数天内变得不可靠。引用上周每席位定价的智能体，可能正在引用一个已不存在的价格。
• API 文档和版本说明在两到四周内就可能因版本漂移而引入实质性的不准确。
• 法规指南和合规政策按月或季度周期运作，但单次更新可能立即使大量语料库失效。
• 架构概述和基础概念的半衰期以年计——每周重建索引纯属浪费计算资源。

让所有内容通过统一的夜间流水线并不是一个中立的选择。这意味着你同时在过度索引稳定内容（浪费计算）和欠索引易变内容（提供过期答案）。这种不匹配是系统性的。

操作层面的解决方案是在摄入时分配新鲜度分类，而非在查询时。当文档进入流水线时，一个分类步骤——无论是基于文档路径和类型的规则，还是在你的语料库上训练的轻量级分类器——都应为其标注新鲜度层级和可接受的过期阈值。此后，刷新调度器以新鲜度类别作为主要输入，而非全语料库统一计划。

真正有效的三层架构

在生产环境中解决了这一问题的团队，通常都会收敛到具有不同层级更新节奏的多层架构上。

热层处理过期容忍度以分钟计的内容：实时定价 API、功能标志、安全公告，以及任何来自 Webhook 或变更数据捕获流水线的内容。这一层使用流式摄入而非批处理任务——变更通过消息队列在秒级内从源头流向索引。运营开销很大（约为批处理流水线复杂度的三倍），但从 24 小时过期到亚分钟级的 SLA 改善，是这类内容唯一可接受的权衡。

温层处理按小时到每天刷新适当的内容：API 文档、功能指南、流程文档。大多数增量索引逻辑都在这里——通过时间戳或内容哈希进行变更检测，仅对修改过的文本块重新嵌入，显式删除追踪以淘汰已删除内容的向量。这里的核心洞见是：在能做增量更新时，绝不做全量重建索引。为更新 200 份已更改文档而触及 10 万个文本块的全量重建，不仅是浪费；它还会造成一个一致性窗口，使同一内容的新旧版本在索引中共存。

冷层覆盖鲜少变更的内容：架构文档、历史材料、基础指南。这些内容按月或按季度重建。此处的计算成本微乎其微，将其与易变内容放在同一热路径上，只会稀释你流式流水线的容量。

实际实现需要在查询时进行路由逻辑：智能体和检索流水线需要根据被问问题的类型知道查询哪个层级。关于当前定价的问题路由到热层，关于架构权衡的问题路由到冷层。这种路由可以是显式的（应用程序知道它在询问什么），也可以是分类器驱动的（轻量级意图模型从查询本身推断新鲜度需求）。

在过期成为用户问题之前检测它

新鲜度分层解决了刷新调度问题，但无法捕获索引中已经存在的过期内容，或源系统变更速度超出分类模型预测的情况。

过期检测问题有两个层次。在文档层面，可以用元数据追踪：每个被索引的文本块携带最后验证时间戳、版本标识符和可接受的新鲜度阈值。查询时的检索逻辑在语义相似度分数之外还会检查这些字段。一份相关性得分为 0.90 但已超出新鲜度窗口 47 天的文档，可以在进入 LLM 上下文之前被降权或标记。

在答案层面，捕获过期引发的错误需要像对待其他幻觉向量一样对待它。生产追踪记录最佳的方法是将词元相似度（检索上下文与生成答案之间的 BLEU/ROUGE 评分——速度快，能捕捉明显偏差）与复杂情况下基于 LLM 的自我验证相结合。两种方法单独使用都不可靠：词元相似度会漏掉改写的过期事实，基于 LLM 的检测会漏掉模型未能识别某个被引用事实曾经为真但现已不成立的情况。

在过期漂移演变为关键问题之前捕捉它的监控设置：

• 追踪出现在检索结果中的文档的年龄分布，而不仅仅是索引中文档的年龄分布。如果某类查询的前 10 个检索结果持续来自 60 天以上的文档，无论这些文档是否已超过名义新鲜度阈值，这都是一个信号。
• 每月在高风险查询类别上运行固定的评估集。关于定价、合规和产品功能的问题，由已知年龄的文档作答。该评估集上的准确率下降就是你的过期信号。
• 当超过新鲜度窗口的索引文档比例超过阈值时设置自动告警。这是一个与 p99 延迟或错误率同等级别的运营健康指标。

几乎无人关注的删除问题

所有关于 RAG 新鲜度的讨论都聚焦于更新内容。删除问题得到的关注少得多，造成的损害却不成比例地多。

当文档从源系统中被删除——一个已下线的产品页面、一个已退役的 API 版本、一项已被取代的政策——批处理流水线通常会在索引中留下孤立的向量数天之久。文档在源头已不复存在，向量却依然保留。用户得到指向 404 内容的搜索结果，或者检索结果来自一个对已不存在的事物具有权威性的知识库。

解决方案并不复杂，但需要将删除作为摄入流水线中的一等事件来对待。每一份从源语料库中退出的文档，都需要针对向量索引进行相应的删除操作。当源是数据库时，变更数据捕获流水线能自然地处理这一问题。对于基于文件或爬取的知识库，流水线需要一个显式的核对步骤，识别没有对应实时源文档的向量并按计划删除它们。这不是什么华丽的工程，但跳过它的团队最终会把客户投诉追溯到一个指向六个月前被删除文档的向量。

将新鲜度作为基础设施，而非积压工作

这里的元模式是一个治理问题，与工程问题同等重要。生产级 RAG 系统中的知识库需要与数据库相同的运营纪律：清晰的所有权、监控，以及应对新鲜度故障的应急程序。

在实践中，这意味着明确将文档过期责任分配给工程或数据团队中的某人——而不是将其作为共同假设搁置。这意味着将新鲜度指标与延迟和错误率一起纳入可靠性仪表盘。这还意味着当新鲜度违规影响时间敏感的业务逻辑时，将其作为故障事件而非积压工作来处理。

60% 的企业级 RAG 部署在规模化时失败，不是因为检索架构有误，而是因为没有人将知识库视为需要持续维护的基础设施。构建 RAG 系统的初始阶段相对简单。在第三个月、第九个月、第十八个月——文档已经漂移、政策已经变更、产品已经演进——保持其准确性，才是更难也更重要的问题。

做到这一点的团队，从第一天起就在摄入流水线中构建新鲜度分类，按照内容衰减率运营与之匹配的分层更新计划，将过期检测作为持续的后台进程运行，并以与更新相同的严格程度对待删除事件。做不到这一点的团队，将把时间花在调试上，追问为什么他们的 RAG 系统——在演示中运行完美——正在对六个月前为真的事情自信地给出错误答案。