当你的 RAG 流读取时发生的 Wiki 中途编辑问题

版本固定与孤儿切片的消亡​

CDC 缩小了新鲜度差距，但它本身并不能解决孤儿切片（orphan-chunk）问题。如果一个页面被删除，该删除操作必须进行传播。如果一个切片被更新的版本替换，旧版本就必须消失——而在向量数据库中，“消失”比听起来要复杂得多，因为新版本通常不会生成完全相同的切片。重新表述的段落会产生具有新嵌入、新 ID 和新位置的切片。旧切片不会被 ID 覆盖；它们会因为缺失而变得孤立。

弥合这一差距的方法是切片级别的版本固定（version pinning）。每个切片的标识不仅包括页面 URL，还包括页面版本号。当新版本到达时，所有标记为该页面前一版本的切片都会在同一次写入中被标记删除（tombstoned）。向量存储会保留旧切片，直到真空清理（vacuum pass）将其清除，但检索时的过滤会排除任何版本号不是其源页面最新版本的切片。

之所以奏效，是因为事实来源（Source-of-truth）——维基（Wiki）——已经将版本号作为一个一等公民概念来维护。摄取流水线的工作是将该版本概念镜像到向量存储中，从而使“最新”成为检索层可以执行的属性。前一节提到的孤儿草稿之所以会消失，是因为删除事件将页面版本 N 标记为墓碑，而所有版本号小于 N 的切片在查询时都会被过滤掉。

对于删除操作，同样的原则也适用：删除事件会创建一个最终的“页面在版本 N 被删除”的记录，任何标记有该页面的切片都会被排除在检索之外，直到垃圾回收将其移除。向量存储不是内容存储——它是一个派生索引，其生命周期必须从属于源系统的生命周期。

写入静默与多页面事务​

版本固定修复方案可以干净地处理单个页面的更新。但它仍然无法处理本文开头提到的情况——即事务跨越四个页面的文案编辑。从编辑者的角度来看，这四次编辑是一个逻辑上的变更。从维基的角度来看，它们是四个独立的提交。从摄取流水线的角度来看，它们是四个独立的事件，按事件流交付的任何顺序进行处理。

目前还没有“多页面编辑是一个事务”的平台级原语，因为维基并不将人类编辑建模为事务。这个修复方案必须存在于摄取层。

最简单的版本是写入静默窗口（write-quiescence window）：当某个命名空间（例如你的工程运行指南空间、你的产品规格区域）中的页面收到编辑事件，且该空间经常发生多页面事务时，摄取程序会等待 90 到 180 秒再进行处理；如果来自同一作者的相关页面有更多事件到达，则重新计时。当编辑者变得安静时，流水线会处理这批数据——这是“事务已结算”的一个软代理。

更高级的版本是草稿状态过滤器。大多数维基都区分草稿和已发布页面，而很大一部分运行中的不一致性仅仅是那些标记为“进行中”的页面。如果摄取程序排除处于草稿或待评审状态的页面，最严重的不一致性就会消失——代价是索引的页面总量会减少。对于那些作者确实会使用草稿标签的团队来说，这是投资回报率（ROI）最高的单项改进。

Neither pattern is perfect. Both are dramatically better than the implicit assumption that fifteen-minute polling will produce a consistent index. The general principle: the ingest pipeline has to know that the source is concurrent, and has to model that concurrency rather than ignore it. 这两种模式都不是完美的。但它们都比“假设 15 分钟轮询就能产生一致索引”的隐含假设要好得多。通用原则是：摄取流水线必须知道源系统是并发的，并且必须对这种并发性进行建模，而不是忽略它。

能够捕获此类问题的评估体系​

这些漏洞之所以能在生产环境中存续，是因为没有人对它们进行测试。标准的 RAG 评估——针对策划好的问题集的 recall@k、针对检索切片的忠实度得分——都是针对静态语料库快照计算的。从设计上讲，它们无法发现那些仅在你摄取任务与作者编辑重叠的几秒钟内存在的漏洞。

能够捕获运行中不一致性的评估体系在形态上是模拟合成的。构建对抗性场景，让两个页面相互矛盾，并根据 Agent 是否揭示矛盾而不是绕过矛盾进行合成来评分。构建删除场景，添加、索引并删除一个草稿，检查 Agent 是否返回过已删除草稿的内容。构建多页面编辑场景，评估套件显式地分阶段模拟一个不一致的索引状态，并探测 Agent 是否察觉。

关键指标不是“Agent 是否检索到了正确的切片”。而是“Agent 是否检测到检索到的切片相互矛盾，并因此询问、升级或拒绝”。如果模型经过训练或提示能够察觉，那么返回不一致上下文的检索层就是可以补救的。目前的默认行为——在不一致的切片之间进行自信的合成——是导致短暂的摄取竞态（ingest race）演变为永久性信任丧失的根源。

这对你的架构意味着什么​

知识库是一个拥有并发写入者的动态系统。你的 RAG 流水线则是一个读取者。如果读取者没有一致性契约，它就是在进行大规模的脏读，而其上层的模型正在将这些脏读“洗白”成语气笃定的回答，用户根本无法将其与事实真相区分开来。

解决方法并非单一的工具或模式。而是在架构层面意识到：摄入层（ingest layer）并非一个转换流水线——它是两个有状态系统之间的复制层，而复制具有众所周知的故障模式（写后读不一致、写写冲突、孤立记录、墓碑传播），这些在分布式数据库领域已经研究了几十年。大多数 RAG 摄入流水线都在重新发明这些问题，却并未意识到它们正是被重新发明出的老问题。

做得好的团队会像对待数据库客户端一样对待他们的 RAG 流水线。尽可能采用事件驱动。全程具备版本意识。即使在源头没有明确定义事务时也能感知事务。立足于能探测出不一致性而非将其通过平均值抹平的评测（evals）。并且诚实地面对这样一个事实：对于“你的索引现在是否与你的 Wiki 保持一致”这个问题，默认的回答是“不”——而工程工作的重点在于不断缩小那个时间窗口，直到回答为“是”的频率足以维持信任。