实时 RAG 怎么做？业务数据变更怎么秒级同步到向量库？
面试怎么回答
我会先区分：价格、库存、订单状态这类实时状态不该放进向量库，而是让模型通过工具实时查；需要实时进向量库的是商品描述、公告、FAQ 这类需要语义检索的内容。链路上数据库内容用 CDC、文档系统用变更事件，统一进消息队列；流式处理解析清洗，用内容哈希跳过没实质变化的更新，切分后小批量调用 Embedding；写入时按文档 ID 先删旧片段再写新片段，删除事件直接删除，权限和有效期等元数据同步更新。要注意按文档 ID 分区保证顺序、消费幂等、突发批量变更限流或走离线通道、索引刷新带来的可见性延迟，实时和离线用同样的处理逻辑并定期对账。监控端到端延迟、积压、失败数和数据量。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
客服 AI 回答商品问题，商品价格和库存刚改过，AI 还在按旧数据回答；新发布的公告，要第二天才能被检索到。很多 RAG 系统的知识库是每天全量或增量离线更新的，对时效要求高的场景就不够用了。面试官问这题，想看你能不能把实时数据链路的经验用到 RAG 上。
先区分：什么数据需要实时进向量库
- 商品价格、库存、订单状态这类结构化的实时状态：其实不应该放进向量库，而是通过工具实时查询接口或数据库；
- 文档类内容（商品描述、公告、FAQ、工单知识）：需要被语义检索，变更后要尽快可检索，这才是实时 RAG 要解决的。
实时同步链路
- 捕获变更：
- 数据库中的内容（商品描述、FAQ）：通过 CDC 捕获变更；
- 文档系统（Wiki、CMS）：通过变更事件或 Webhook；
- 统一写入消息队列；
- 流式处理：用 Flink 或流式消费程序：
- 解析和清洗内容；
- 判断是否真的需要重新处理（比如内容哈希没变，只是更新时间变了，就跳过）；
- 切分成片段；
- 调用 Embedding 服务生成向量（小批量聚合后调用，提高吞吐）；
- 写入向量库：
- 按文档 ID 先删除旧的片段，再写入新的片段（或者用版本号覆盖），保证同一文档不会新旧片段并存；
- 删除事件直接删除对应的片段；
- 元数据同步：权限、有效期、分类的变化也要同步，权限变更尤其要及时。
需要注意的问题
- 顺序：同一文档的多次变更要按顺序处理，按文档 ID 分区；
- 幂等：重复消费不能产生重复片段；
- Embedding 服务的压力：突发的大量变更（比如批量导入）会冲击在线 Embedding 服务，需要限流和削峰，大批量变更走离线通道；
- 可见性延迟：向量库写入后到可被检索可能有延迟（索引刷新），要明确告知业务的时效预期；
- 一致性：实时链路和离线全量重建要用同样的处理逻辑，定期用离线全量结果校验实时链路有没有漏数据。
监控
- 端到端延迟：从内容变更到可被检索的时间；
- 消费积压；
- 处理失败的文档数；
- 实时和离线的数据量对账。