RAG 文档更新或撤稿后，怎样验证索引已生效？

知识库负责人已经改了文件，助手却仍引用旧条款；或者文件已经撤稿，向量命中和缓存回答还把它带出来。来源修改、索引请求成功、定时任务结束，只是不同阶段的事件；用户实际看见的新检索和新回答发生得更晚。“索引已更新”必须针对指定来源版本或撤稿事件验证，不能只看一个成功提示。

本文检查的是来源到索引再到回答的传播链。RAG 检索评测检查固定语料能否找到正确段落；引用与时效审计检查回答结论是否被当前证据支持；文档权限验证检查某个用户的权限，包括撤权。本页处理文档本身的更新或撤稿：旧索引与缓存何时消失，新版本何时可见，发布负责人如何拿到可复核的证据。

给每次变更一个编号和期限

按来源事件建记录：稳定文档键、来源修订版或内容摘要、事件编号、更新或撤稿、资料负责人、生效时间，以及流水线观察到该事件的时间。以来源正式发布状态为准；一份刚修改的草稿不一定取代仍然生效的制度。写清必须退出的旧版本，以及预计可检索的新版本；如果新版本将来才生效，写清切换时间。

试验前定好可接受的传播窗口，说明期限使用哪一个时钟，并决定等待更新时用户端怎样处理。对影响较大的撤稿资料，可以用来源权威状态拦住该文档，或暂停相关回答路径，直到清理得到证实。期限是业务运行要求，不是搜索引擎保证；超时要告警并交给指定负责人。

层次	要收集的证据	为什么上一层还不够
来源	事件编号、修订版、生效与撤稿状态	改了文件不代表入库已经开始。
入库	运行编号、游标或高水位、逐条结果与错误	任务结束也可能漏掉变更或单条失败。
搜索索引	父子片段编号、来源版本、关键词与向量可见状态	写入回执可能早于搜索可见。
交付	检索、引用原文入口、结果与回答缓存	索引正确后，旧缓存仍可能给出旧答案。

按真实变更信号检查入库方式

主动推送的流水线要逐文档核对返回结果，保留事件或操作编号，对失败项重试时不能丢失更新和删除。Azure AI Search 的推送更新会在后台处理；成功的索引响应本身不证明下一次查询已看见新文档。拉取式 Indexer 有另一套时钟：Azure 文档说明初次运行后通常处理检测到的变更，但检测方式取决于数据来源和配置。定时运行还有最短间隔，来源修改不会让定时 Indexer 立即醒来。把运行历史、输入版本和最后处理游标与事件放在一起。

删除必须有明确的信号。Azure 的 Blob 指南说明，删除检测不会自动完成：需要从 Indexer 首次运行起配置受支持的原生或自定义软删除策略。软删除的 Blob 必须留到 Indexer 能看到；若提前物理删除，搜索索引中可能残留孤儿文档。尤其要注意：这两种 Blob 软删除机制都不适用于一对多索引；子片段索引文档必须经索引 API 明确删除。其他流水线可以使用墓碑记录、事务外发事件，或按稳定 ID 明确删除。无论使用哪种机制，都要针对实际父子结构写出并实测；“来源文件不见了”不等于所有搜索副本都消失。

如果字段结构、切块规则或嵌入模型变化，先判断是否还能增量更新，还是需要建立替代索引。文本变化后要重新产生对应向量；切块规则变化还可能改变子片段的数量和编号。记录新旧索引及流水线版本，必要时先建立替代版本，完成探针验收后再切换读取。重置或重建请求只是起点，不能作为验收结果。

核对父文档与每一条旧片段

更新文档时，把来源修订版与每个可检索子片段及其向量对照。如果新版本由五段缩成三段，多出的两段旧子片段也必须退出；只覆盖三个相同编号远远不够。保留父文档到子片段的台账，或其他可以枚举的关系，让复核者查到所有旧编号，而不只查预计仍存在的几段。分别检查关键词与向量路径，以及真正传给模型的片段。即使新版本也已经出现，只要旧版本仍被检索到，就不能算通过。

撤稿时，预期的新片段集合为空。检查旧父文档、全部子片段文字与向量、抽取摘要以及直接引用入口是否已经消失或被拦住。再放一个正向对照：无关的有效文档必须仍可检索，防止“所有查询都空”被误判成清理成功。如果无法枚举子片段，或删除事件丢失后无法对账，就暂停宣称完成，并交给入库负责人修复。

分开测试搜索可见性与缓存

Elasticsearch 文档说明存在近实时边界：索引写入已确认后，内容未必立即对搜索可见，要等 refresh。refresh=wait_for 等待刷新；refresh=true 强制刷新，可能增加吞吐代价。如果通过 index.refresh_interval=-1 关闭自动刷新，wait_for 可能一直等待，直到其他操作触发刷新；它不能充当业务截止时间保证。这两种方式都不能修复漏掉的来源事件、陈旧向量或应用缓存。不要为了掩盖验收缺口而给每次写入都强制刷新；要在真实生产读取路径上记录搜索探针何时首次通过。

至少对实时检索链路跑三种输入：新版本独有词组、应命中新向量的自然语言改述，以及旧版本独有且不应再命中的词组。撤稿时，除了普通用户问题，还要按文档与子片段编号直接查。打开检索缓存和生成答案缓存重跑；依据本系统缓存契约，按受影响文档或索引版本失效。保存过的引用或来源预览链接也要单独访问。随后用引用审计检查最终结论是否真的由进入回答的版本支持。

记录最后一次失败和第一次通过的观察时间，不编造“即时生效”时间。不同检索路径、副本和缓存可能先后变更。只有所有必要探针在规定窗口内通过，才标为合格；一条回答正确不证明旧版本已消失。后续重建索引或更换缓存时，还要重跑这些负向探针。

案例：实验室预约规则下周一改版

一所虚构大学的知识库使用实验室预约规则 R4。经审核的 R5 修改了最长预约时长，但下周一才生效。在生效边界之前，助手仍应使用 R4；之后应使用 R5。来源事件要同时记录获批版本与生效时间。Indexer 可能提前把 R5 收入索引，因此检索必须按版本或生效状态筛选，不能简单地让“最新更新时间”胜出。

验收表准备一个包含新上限的问题、一个同义问法，以及一个只会匹配 R4 旧措辞的问题；分别在生效前后测试。记录模型实际收到的片段版本，以及缓存回答。案例只是说明试验设计，不预填传播时长或通过结果；这些单元格要由真实演练填写。

案例：供应商资料被撤稿

一个虚构客服团队撤回了一份内容有误的供应商规格表。之前的入库已产生多个片段、向量、摘要和引用预览。来源负责人在发布台账中标记 S2 撤稿，但存储清理直接物理删除了 Blob，未明确删除子片段索引记录。Azure 的 Blob 软删除策略不能替一对多索引清理这些子片段；复核者应把缺失的删除证据视为待解决风险，而非清理成功。

团队枚举旧子片段编号，搜索 S2 独有的词句，打开保存过的引用，再带着原客服问题检查答案缓存。如果任何旧入口仍在，就不能验收：按后端能力执行定向删除或重建，使受影响缓存失效，然后重跑全部探针。另一份仍然有效的供应商资料作为正向对照。这里也不声称修复结果已经实测。

填写索引刷新验收表

下方工作台记录一项来源事件、新旧预期版本、入库证据、父子片段清理、关键词和向量及缓存回答探针、首次通过时间、期限与指定的后备处理。草稿只保存在当前浏览器，可复制或导出 TXT。请填写合成编号和脱敏结果摘要；受限原文、真实用户问题、凭据及内部索引地址应留在获授权的系统。

不适用边界

这份试验只证明指定版本在已测试路径上的传播结果，不证明来源事实正确、回答引用有效或文档授权正确。只有权限发生变化时，使用文档权限验证；语料不变而排序不佳时，使用检索评测。来源连接器、删除策略、索引结构、切块器、嵌入模型、缓存或读取路径改变后，都应重新演练更新与撤稿。