RAG 不只是检索：把文档生命周期当作数据工程来做

本文是对 Microsoft Foundry Blog 一篇文章的原创分析。事实部分以原文为准，评论部分是我的个人判断。原文链接见文末。

文章在讨论什么问题

这篇文章发表于 2026 年 10 月 22 日，作者来自微软。它关注的不是模型或检索效果，而是一类“基础设施都正常、答案却是错的”的故障。典型例子是：制度文件已经更新，问答助手仍然引用旧版本。

文章的核心观点是，搭建 RAG 流水线是检索问题，让它在数据变化后依然正确，则是数据生命周期的工程问题。

三种变化场景

文章把文档变化分为新增、更新和删除三类。

新增：索引完成之前，内容对问答不可见。

更新：如果旧版本没有被正确停用，新旧内容可能同时被检索到，模型可能混用冲突信息。

删除：只删除存储中的原文件，并不会自动清除搜索索引里的分块，内容可能继续被检索到。

我的观察是，这三种场景里删除风险最高，因为它可能涉及已撤销或未授权的内容。

架构上的几个关键选择

文章把系统拆成文档管理、异步处理和查询三条路径。上传接口只负责保存文件和元数据并投递任务，耗时的文本提取、分块和向量化交给后台工作进程。这样做的好处是上传延迟更低，摄取可以独立于查询流量扩展，重试也更容易管理。

其中最值得借鉴的是“权威状态”的设计。文章把 Azure Cosmos DB 作为生命周期元数据的权威来源，把 Azure AI Search 定位为检索索引。它还区分了“期望版本”和“已索引版本”，避免误以为刚上传的文件已经可被检索。

一致性与可靠性要点

1. 幂等：消息可能重复投递，分块 ID 应由文档、版本和分块编号确定性生成，重复处理才不会产生重复内容。 2. 版本保护：较早启动的任务可能晚于新版本完成，必须用条件更新或乐观并发，防止旧版本被重新激活。 3. 更新策略：可以保持旧版本可用直到新版本索引完成，也可以在接受更新时立即停用旧版本。前者更偏可用性，后者更偏严格时效。 4. 删除分两步：先在元数据中让文档不再可检索，再异步清理索引，并在清理后做校验。 5. 无跨服务事务：需要显式状态、可重试操作、死信队列和定期对账作为兜底。 6. 事务性发件箱：文章提到可用它来协调元数据变更与消息发布。

对开发者的影响

这套思路适合企业知识库、制度问答和合同检索等内容会变化、且错误代价较高的场景。如果只是静态资料库，其中一部分设计可能偏重。

我认为最实用的是两点：把“是否可被检索”交给元数据判断，而不是依赖索引里是否存在记录；同时把对账当作常规能力，而不是事故后的补救。

仍待观察

文章给出的是设计原则和示意代码，并非完整的生产实现，授权、缓存失效等细节仍需自行补全。

对已在处理中的查询，删除后的保证应怎样定义，需要结合业务要求明确。这一点原文也提到需要明确策略。

推测：随着 Agent 框架更多介入检索流程，生命周期状态检查可能需要进入工具调用层，具体做法尚待实践验证。

来源

Microsoft Foundry Blog：https://techcommunity.microsoft.com/blog/azure-ai-foundry-blog/building-a-self-updating-rag-system-handling-document-uploads-updates-and-deleti/4564036