面试题 · 评估
搜索「RAG 架构」匹配到追问内容，相关段落已展开。查看匹配内容 ↓
在基于知识库的大模型应用（如RAG系统）中，知识库的更新策略有哪些？如何保证更新的实时性、一致性和检索准确性？
按更新粒度分类
全量重建：定期（如每天/每周）重新拉取全部数据、重新分块、重新生成embedding
增量更新：仅处理变更数据（新增、修改、删除）
学习内容与项目面试，在同一条路上。
按触发方式
| 方式 | 延迟 | 适用场景 |
|---|---|---|
| 实时/近实时（秒级） | 低 | 金融价格、库存等强时效数据 |
| 定时任务（分钟/小时级） | 中 | 一般文档、FAQ |
| 手动触发 | 高 | 法规、标准等低频更新 |
写入一致性
校验与修复
关键权衡：实时性 vs 成本 vs 准确性，需按业务场景选择（如客服FAQ可接受分钟级延迟，股票数据需秒级）。
场景切入
假设你们做一个电商客服RAG系统，商品信息每天变价好几次，文档也频繁更新。你会怎么设计知识库的更新策略，让机器人回答的库存和价格都是最新的？
层层追问
RAG系统的知识库你们一般怎么更新？……如果数据实时在变，怎么保证检索到的信息不滞后？……那如果更新过程中用户正好在查，怎么避免读到脏数据？
直球架构
设计一个RAG知识库的更新方案，需要支持近实时更新、保证数据一致性、同时检索准确性不下降。你会选哪些技术组件？核心权衡点是什么？
这道题其实问的不是单纯的“怎么把数据灌进去”，它本质是在问：在一个实时性、一致性和检索质量三方博弈的系统里，你怎么做工程取舍。如果只让我说一句话，那就是：没有万能的更新策略，只有按场景配比的方案。
先说策略的边界。全量重建，就是每天或每周把整个知识库重新[[分块]]、重新生成 [[Embedding]]，再全量替换。好处是数据一致性最强，能彻底清理脏数据，坏处是成本高、耗时长，适合数据量小或者变更不频繁的场景，比如企业内部的合规文档，半年更新一次，你全量重建完全没问题。但如果是电商的实时库存，或者金融的实时价格，全量重建根本来不及，这时候就要上增量更新。增量更新只处理变更的数据，新增、修改、删除分别走不同的逻辑。真正落地的时候，很少只用一种策略，往往是全量加增量混用。比如白天跑增量，凌晨低峰期跑一次全量做对账修复。
具体到增量更新的实时性方案，我一般会分几层。最底层是数据源变更捕获，比如监听数据库的 binlog 或者业务的消息队列。如果业务系统本身就发变更事件到 Kafka，那就直接消费。如果没有，就需要自己搭 CDC 组件。拿到变更之后，不能直接写[[向量库]]，因为向量库的索引对高频写入很敏感。我的做法是：新增数据直接插入，修改数据拆成“旧版本软删除加新版本新增”，删除数据不原地动索引，而是维护一个删除标记列表，后台异步重建索引。这里有个坑：千万不要在 [[HNSW]] 或 [[IVF]] 这种图索引/聚类索引上直接做删除操作，否则检索质量会崩。
一致性保障是另一个难点。说白了，你要保证业务数据库和向量库最终一致。我常用的手段是：消费端做幂等处理，每条记录带版本号或时间戳，写向量库时做 upsert 语义。检索的时候，带版本过滤，只取最新版本。这还不够，我会加一个定期对账任务，比如每小时比对源库和向量库的记录数、计算 hash，发现不一致就自动补发。上线前还要做灰度，新索引先在小流量上跑，对比召回率，达标了再全量切换。
还有一个容易被忽视的点：更新对检索质量的影响不只是数据对不对，还有向量空间的漂移。比如你新增了一批文档，它们的 embedding 分布可能跟旧数据有偏移，导致召回率下降。这个怎么监控和修复，其实比单纯的数据同步更复杂。
所以我的整体判断是：知识库更新不能只当成数据管道来做，要当成一个带质量门禁的系统。我更倾向按变更类型分类处理，低频重要数据用全量加双写事务，高频海量数据用增量加异步对账。每轮更新上线前，必须用固定 query 集回放，对比 Recall@K 和延迟，通过才原子切换，不通过就回滚。