5000 万向量、日均 300 次文档更新：RAG 增量一致性架构的实战复盘关键词：RAG、增量索引、Transactional Outbox、Kafka、Milvus、版本发布、最终一致性凌晨三点，客服机器人又报出了已经失效三个月的企业报价。报价 PDF 三天前已上传到对象存储，业务库也记录了新版本；但 embedding 服务超时后，索引任务只写入了一部分 chunk，旧 chunk 仍可检索。模型没有“记错”，它拿到的是一组过期且矛盾的证据。这是RAG Index Drift（索引漂移）：事实源已改变，派生检索索引没有收敛。对于约 5000 万向量、日均约 300 次新增/修改/删除的知识库，全量重建一次需要 6～8 小时，不能作为日常同步方案。本文以这次脱敏后的报价事故为案例，先解释设计，再给出一个可复制的最小实现。其目标不是让所有系统瞬时强一致，而是保证：失败、重复、乱序和删除发生后，用户只会检索到一个完整、可解释的文档版本。一、贯穿案例：报价从 v17 更新到 v18 时发生了什么文档price-enterprise.pdf的稳定业务主键为doc-42。事故过程如下：时间事件旧系统结果周日 10:00报价 v17 发布10 个 v17 chunk 可检索周一 09:05上传 v18，价格变更对象存储、业务库已是 v18周一 09:06embedding 超时v18 仅写入 3 个 chunk周一 09:07任务先删除部分 v17查询为空或混召新旧价格周三 03:00客服告警索引漂移持续三天错误不只在于“旧向量没有删干净”。真正缺少的是可见性协议：当 v18 还未完整构建时，它不应对用户可见；v17 也不应被提前删除。对任一(tenant_id, doc_id)，检索只能看到一个已完整构建且已发布的active_index_version；候选、失败和撤销版本不得参与召回。上传 API对象存储不可变版本对象PostgreSQL文档状态 + OutboxOutbox Relay / CDCKafka索引 Consumer解析 · 切块 · EmbeddingMilvus候选向量RAG Query API二、事实源与版本模型向量数据库是可重建的派生索引，不是事实源。PostgreSQL 决定文档是否存在、哪个源版本是期望版本、哪个索引版本已发布、租户与 ACL 是什么；对象存储提供不可变内容快照；向量库只做相似度检索。不要把内容哈希称作“文档 ID”。至少要拆开如下身份：字段用途doc_id不随文件名或内容变化的业务主键source_version上传/删除事件的单调递增版本object_uri + etagConsumer 必须读取的不可变文件快照content_hash规范化 chunk 文本的去重与 embedding 缓存键index_version一次完整候选索引的发布版本embedding_model、chunker_version生成条件与兼容性边界chunk_key = sha256(doc_id + index_version + ordinal + content_hash)可作为 Milvus 主键。文本未变时，可以从(content_hash, embedding_model)缓存复用 embedding；但新发布版本仍应拥有独立的 chunk key，避免与旧版本互相覆盖。