RAG索引漂移检测指南：识别已删除文档、过期分块与重复嵌入（2026-09-11）

你的RAG系统上线三个月后，是否开始出现答非所问、引用过时政策、甚至凭空捏造？问题往往不在大模型，而在索引漂移——向量数据库与源文档逐渐脱节。本指南教你用三个信号检测并修复。

什么是索引漂移？

索引漂移指RAG索引中的向量与真实知识库状态不一致。常见三种表现：

• 已删除文档仍被检索：源文件已删，向量还在“幽灵作答”。
• 过期分块未更新：政策从v1改到v3，索引仍返回v1片段。
• 重复嵌入：同一内容被多次切分嵌入，导致相似结果霸屏。

案例与数据：漂移有多严重？

某客服RAG系统运行6个月后审计发现：

• 12%的检索结果来自已删除的旧工单。
• 8%的答案引用过期价格（已涨价30%）。
• 重复嵌入导致Top-5结果中3条来自同一文档。

结果：人工纠正率上升47%，用户满意度下降22%。

三步检测法

1. 已删除文档检测

维护源文档ID与向量元数据doc_id的映射表。每日对比：源库不存在的doc_id即为幽灵向量。建议用orphan_ratio = 幽灵向量数 / 总向量数，超过2%告警。

2. 过期分块检测

为每个分块记录source_version或updated_at。检索时，若分块版本低于源文档当前版本，标记为过期。可设置“版本差≥2”才触发重嵌入。

3. 重复嵌入检测

计算向量间的余弦相似度。若同一doc_id下有>3个分块相似度>0.95，视为冗余。用聚类去重，保留最长或最新分块。

实用建议

• 每日轻量巡检：只查orphan_ratio和版本差，耗时<1分钟。
• 每周全量去重：用Faiss或HNSW做近邻聚类。
• 写入时防漂移：删除文档时同步删除向量；更新文档时标记旧分块为deprecated而非直接删。
• 监控看板：跟踪幽灵率、过期率、重复率三个指标。

行动号召

今天就去检查你的向量库：随机抽100个检索结果，人工核对来源是否仍存在且最新。发现问题？立即建立doc_id映射表与版本字段。别让索引漂移悄悄毁掉你的RAG可信度。

免责声明：本文所述方法为通用技术建议，不构成任何特定系统的运维保证。实施前请结合自身数据安全与合规要求进行评估。