如何检测RAG索引漂移：已删除文档、过期分块与重复嵌入（2026-09-25）

你的RAG系统上线三个月后，回答准确率从92%跌到了67%。模型没变、提示词没变，问题出在索引漂移——源文档和向量库之间悄悄产生了裂痕。

三种最隐蔽的索引漂移

1. 已删除文档的“幽灵分块”

源系统中一份产品手册被标记为“已下架”，但向量库里仍保留着它的嵌入。用户问“XX功能怎么用”，系统自信地引用了一份不该存在的文档。某电商客户实测：下线200个SKU后，仍有37%的旧分块被检索命中。

2. 过期分块：内容更新了，向量没更新

源文档从“支持7天退货”改为“支持15天退货”，但嵌入模型只计算了一次。检索时，旧分块因语义相似度更高（旧文本与用户查询用词更接近）被召回，导致错误回答。数据：内容更新后，过期分块在Top-5结果中的占比平均达18%。

3. 重复嵌入：同一段文本被多次索引

同步脚本异常或手动重跑导致同一分块有2~5个嵌入。检索时多样性丧失，LLM只能反复看到同一句话。测试显示：重复率超过15%时，回答的事实一致性下降23%。

三个可落地的检测方法

方法一：源-库MD5对照表

为每个源文档生成MD5哈希，存入向量库的元数据。每周跑一次差异对比：

方法二：嵌入余弦相似度去重

对索引中每对分块计算余弦相似度。若>0.98且来自同一源文档的不同版本，判定为重复或过期。某团队用此方法一天内清理了1.2万个冗余嵌入。

方法三：检索可信度抽查

随机抽取20个查询，人工检查Top-5结果是否全部来自当前有效的源文档。建议每周执行一次，标记任何“日期戳早于上次同步时间”的分块。

实用建议

行动号召

今天就去检查你的向量库：随机选10个分块，比对源文档的修改时间和删除状态。发现任何不匹配？恭喜你，你找到了索引漂移的第一条裂缝。修复它，然后把这篇文章转发给你的数据工程同事。

免责声明：本文数据基于典型RAG架构的模拟测试，实际效果因嵌入模型、分块策略和同步频率而异。建议在生产环境先小范围验证检测逻辑。