RAG知识库新鲜度：团队最后才解决的数据陈旧问题
大多数RAG团队会花数月时间调整分块大小、尝试不同的嵌入模型、争论混合搜索配置。然后他们上线，宣告成功，转身离开。六个月后，用户开始抱怨系统给出错误答案——团队才发现，当初精心构建的索引已经悄然腐化。
索引新鲜度是最后才被解决的问题，通常是在用户投诉事故之后才被重视，而非之前。与检索质量问题会立即在评测中暴露不同，数据陈旧是无声无息的退化：延迟保持平稳，检索看似正常，上下文召回率和忠实度等标准RAG指标评分良好——直到系统自信地返回几个月前就已更新的政策时，才会东窗事发。
这就是知识衰减问题。它比论文中描述的更为普遍。对企业RAG部署的研究发现，在成功完成概念验证后失败的项目中，60%失败的原因不是检索质量，而是无法在规模化场景下维持数据新鲜度。
为什么新鲜度比分块更难
当分块配置错误时——尺寸不当、没有语义边界检测、重叠过多——你会立即得到反馈。检索质量显而易见地下降，你去调整、修复、上线。
数据陈旧的方式则截然不同。思考一个典型知识库随时间会发生什么：
- 一份政策文档被更新了，但旧版本仍在索引中。关于该政策的查询返回自信、语义相关的结果——只不过结果是错的。
- 产品定价页面已经更改，RAG系统继续提供上个季度的价格。
- 一个已废弃的API端点从文档中移除了，系统却还在推荐它。
在每一种情况下，陈旧文档的嵌入在语义上仍然有意义，仍然能匹配相关查询。向量搜索没有机制去优先选择更新的文档，除非明确注入新鲜度信号。标准RAG评测套件——基于固定基准事实衡量忠实度和相关性——没有时间维度。一个系统可以在所有标准指标上得到95分，同时返回已被替代数周的信息。
更深层的问题是陈旧性会复利累积。单个陈旧文档是一个bug，语料库中20%的文档超过其有效生命周期则是架构级失败。而大多数团队要等到用户告知才会去度量这一问题。
变更检测策略
在刷新陈旧文档之前，你需要知道它们已经发生了变更。正确的检测策略取决于源数据的存储位置。
基于时间戳的轮询是最简单的方法。记录每个已索引文档的last_modified时间戳，定期查询自上次索引运行以来被修改的文档。这对于修改时间戳可靠的文件系统和数据库效果良好。失败的场景是 删除操作：被删除的行无法被查询到，因此硬删除会在索引中悄然留下孤立向量。
事务日志挖掘是数据库驱动知识库的生产级方法。Debezium和Striim等工具监控数据库事务日志，而非轮询记录。每次插入、更新和删除都会生成一个变更事件。这种方法不增加写入性能开销（不像基于触发器的CDC），且能捕获时间戳轮询遗漏的删除操作。事件流可以直接馈送到摄取管道，实现近实时的索引更新。
Webhook和事件驱动集成适用于第三方来源。Notion、Google Drive、Confluence和大多数企业内容平台都可以发出变更事件。构建一个事件消费者，将源文档更新映射到重索引任务。主要的运维挑战是可靠性：事件队列可能滞后，你需要为失败的更新设置死信处理。
基于爬取的刷新是没有事件API的Web来源的兜底方案。按计划爬取完整的源站点或站点地图，将内容哈希与已索引版本进行比较，仅重新处理已更改的文档。这里应使用哈希比较而非时间戳比较，因为Web爬虫无法可靠地信任HTTP的Last-Modified头。
增量重索引与全量重建
当索引出现问题时，本能反应是从头重建。全量重建能给你一个干净的起点，但在运维上代价高昂，且往往没有必要。
增量重索引只处理已变更的文档：检测变更、提取修改后的分块、仅对这些分块重新嵌入、在存储中更新相应向量，并使触达该文档的任何缓存失效。对于一个修改了5到20个分块的典型文档更新，这在数秒内即可完成。对于百万文档规模的语料库，这是唯一可行的方法——全量重建需要数小时，并会阻碍团队发布语料库更新。
真正需要全量重建的情形：
- 你在升级嵌入模型。旧向量和新向量处于几何上不兼容的空间，混合使用会产生不可靠的最近邻结果。
- 你更改了分块配置。不同的分块边界产生不同的语义表示，混合不同版本会导致无声的检索退化。
- 你观察到了大范围的嵌入漂移——一种因不同管道版本的累积局部重索引导致向量空间逐渐扭曲的状态。
运维原则：将全量重建视为模式迁移。它很少发生，需要规划，并需要切换策略（双索引服务、流量逐步迁移，或根据你的SLA容忍度安排维护窗口）。其他所有情况都应是增量式的。
LangChain的Record Manager和LlamaIndex的摄取管道都实现了基于哈希的变更检测，以自动支持增量更新。哈希值基于文档内容和元数据计算；如果与存储的哈希匹配，文档将被跳过；否则将重新处理，旧向量被替换。
文档生命周期：新增、更新与删除
大多数摄取管道是为新增文档而构建的。更新和删除是事后考虑，而这恰恰是新鲜度失败最集中的地方。
新增很简单：分块、嵌入、写入向量存储。唯一的错误是在用户请求路径上同步执行，这会增加延迟。使用队列的后台摄取才是正确的模式。
