文章摘要RAG知识库上线后文档、商品、制度、工单和数据库数据都会持续变化。全量重建实现简单但成本高增量索引效率更高但版本与删除治理复杂CDC可以接近实时同步却会引入事件顺序、幂等、事务和回放问题。本文从数据规模、更新频率、一致性、成本、恢复能力和实施复杂度出发比较三种更新架构并给出企业项目的组合选型建议。一、为什么更新架构比首次入库更难首次建设RAG时数据链路通常是全部文档 → 解析 → 分块 → Embedding → 写入向量库上线后数据开始变化新增文件修改制度删除合同商品信息调整权限变化数据库记录更新文档生效和失效多语言版本发布。此时需要回答哪些内容发生变化 哪些Chunk需要重算 旧内容何时失效 删除如何传播 失败后从哪里恢复 线上是否允许短暂不一致二、方案一全量重建流程读取全部数据 → 重新解析 → 重新分块 → 全部Embedding → 建立新索引 → 切换生产别名优点实现最简单最容易保证最终一致不需要复杂的变更识别可以清理历史脏数据适合更换Embedding模型便于重构Chunk策略。缺点Embedding成本高构建时间长数据量越大越难频繁执行可能产生大量重复计算切换和回滚需要双索引空间。适合场景数据量较小更新频率低每天或每周离线同步经常调整解析与分块策略需要更换Embedding模型初期项目优先保证简单可靠。三、全量重建不要覆盖生产索引错误做法清空生产Collection → 开始重新写入构建期间用户只能检索到部分数据。推荐蓝绿索引knowledge_blue当前生产 knowledge_green正在构建构建完成后完整性校验 → 回归测试 → 切换Alias → 保留旧索引用于回滚逻辑knowledge_current → knowledge_green切换后观察稳定再删除旧索引。四、方案二增量索引增量索引只处理变化内容。流程发现新增、修改、删除 → 计算差异 → 更新对应Chunk → 修改版本和状态优点成本低同步速度快对大规模知识库更友好减少重复Embedding可频繁执行。缺点差异识别复杂删除容易遗漏Chunk边界变化会扩大更新范围新旧版本切换需要状态机长期运行可能积累脏数据。适合场景文档数量较多每天有持续变化需要小时级更新数据来源有稳定ID和更新时间有能力建设版本、幂等和补偿机制。五、增量索引如何识别变化文档级Hash文件内容Hash变化 → 重新处理整个文档Chunk级Hash同一章节内容未变化 → 复用旧向量 内容变化 → 重新Embedding更新时间SELECT*FROMproductWHEREupdated_at:last_sync_time;单靠updated_at存在问题时钟偏差批量回填事务未提交同一时间多条记录删除记录无法查询。更可靠的是稳定主键 版本号 内容Hash 删除标记六、方案三CDC事件驱动更新CDC是Change Data Capture即捕获数据库的新增、修改和删除事件。链路业务数据库 → Binlog/WAL → CDC平台 → 消息队列 → RAG索引消费者 → 向量数据库常见工具包括DebeziumKafka ConnectFlink CDC云数据库变更流自研Outbox事件。优点接近实时能捕获删除不需要频繁扫描整库适合结构化业务数据事件可重放。缺点基础设施复杂事件可能重复顺序和事务边界难处理大批量更新可能冲击Embedding服务Schema变更需要兼容失败补偿和积压治理要求高。七、CDC不应该直接调用Embedding错误链路收到数据库事件 → 同步调用Embedding → 写向量库如果Embedding限流CDC消费就会阻塞。推荐CDC事件 → 标准化变更任务 → 任务队列 → 批量聚合 → Embedding Worker → 向量写入任务示例{event_id:EVT-10001,entity_type:PRODUCT,entity_id:P1008,operation:UPDATE,version:18,occurred_at:2026-07-24T02:30:00Z}八、事件幂等与顺序可能先收到version18后收到延迟事件version17如果不校验版本旧数据会覆盖新数据。写入规则incoming_version stored_version → 允许更新 incoming_version stored_version → 忽略事件ID还应去重processed_event_id九、删除如何处理全量重建新索引里不存在的内容自然消失。增量索引需要显式删除向量 或标记DELETEDCDC必须消费DELETE事件。若业务表使用软删除is_deleted true也应转成RAG删除任务。删除传播延迟应单独监控因为它直接影响隐私和权限风险。十、三种方案对比维度全量重建增量索引CDC实现复杂度低中高更新延迟小时或天分钟或小时秒到分钟Embedding成本高低低删除处理简单需显式处理事件驱动一致性治理简单中等复杂故障恢复重跑全量重跑任务回放事件适合数据量小到中中到大大规模实时十一、企业项目通常采用组合方案推荐日常增量或CDC 定期全量重建校准例如实时CDC同步商品与订单 每小时增量同步文档 每周全量一致性校验 每月蓝绿重建索引全量重建可以消除长期积累的漏删重复错误版本Payload漂移历史任务失败。十二、如何选择选择全量重建满足大部分条件数据量小于可接受范围 更新不频繁 成本可控 团队希望降低复杂度选择增量索引文档较多 小时级更新即可 来源有稳定ID 需要控制Embedding成本选择CDC数据来自业务数据库 要求接近实时 更新和删除频繁 已经具备消息与CDC基础设施十三、必须统一的元数据不管选择哪种方式都应记录source_id logical_document_id source_version content_hash chunk_hash index_version embedding_model status updated_at否则无法判断当前向量来自哪个版本是否应该更新是否能够回滚引用是否过期。十四、上线前的故障演练至少演练Embedding限流向量库超时任务重复投递删除事件丢失旧事件晚到索引切换失败新版本质量不合格消息积压数据库Schema变化。十五、核心指标source_to_index_latency pending_index_task_count failed_index_task_count duplicate_event_count stale_event_count delete_propagation_latency index_consistency_rate embedding_reuse_rate full_rebuild_duration总结三种方案没有绝对优劣全量重建 → 简单和最终一致 增量索引 → 成本与复杂度平衡 CDC → 实时但工程要求最高多数企业RAG的稳妥方案是日常使用增量或CDC定期通过蓝绿全量重建校准数据和索引状态。