别让分布式数据库的同步延迟成了 AI 幻觉的罪魁祸首
起初我怀疑是 LLM 的上下文窗口丢失或者 RAG 的检索召回出了问题，但经过全链路日志排查，我发现这根本不是模型层面的“幻觉”，而是典型的分布式数据库 Replication Lag（主从同步延迟）导致的。
在我们的架构中，写操作全部由主库（Primary）承接，而为了分担压力，AI 检索模块的读取请求被路由到了多个只读从库（Read Replicas）。在低并发时，主从同步几乎是瞬时的，用户感知不到延迟。但当请求密集度提高，主库产生的 Binlog 传输到从库并执行回放的时间差就开始显现。用户点击保存的请求在主库完成，但 AI 紧随其后的读取请求命中了尚未同步完的从库，导致 AI 读到了过时的数据。
这种“最终一致性”在大多数业务场景下没问题，但在 AI Agent 这种对实时性要求极高的工作流中，它简直是开发者的噩梦。因为 AI 的输出具有不可预测性，如果底层数据不对，模型会基于错误信息一本正经地胡说八道，而你很难第一时间通过简单的 API 返回值判断出这是数据同步问题。
为了彻底解决这个一致性崩塌的问题，我尝试并落地了两种方案：
第一种是最直接的“强制读主库”策略。对于 RAG 工作流中那些强依赖实时更新的环节，我直接在数据库连接层做了标记，强制跳过从库路由，直接请求主库。虽然这会增加主库的压力，但对于这种关键路径的读写，确保强一致性比追求高可用更重要。
第二种方案是引入版本号（Version ID）校验机制。我在文档写入时强制生成一个单调递增的 version_id 并随响应返回给前端。当 AI 发起请求时，前端必须带上这个版本号。后端在读取从库数据后，会先对比当前记录的版本号与请求中的 ID 是否一致。如果发现 current_version < request_version，说明当前从库还处于同步延迟状态，此时程序会触发一个短暂的指数退避重试（Exponential Backoff），直到读到正确版本或达到超时阈值。
这次经历给我最大的启发是：在构建 AI 应用时，尤其是涉及实时数据检索的场景，千万不要盲目信任分布式数据库的“最终一致性”。很多时候，AI 表现出的“胡言乱语”其实是底层数据同步延迟导致的伪幻觉。如果你的业务逻辑要求必须看到最新结果，就必须在架构层面强制实现强一致性，否则你可能会在模型调优上浪费大量时间，而真正的病根其实在数据库的同步延迟上。
