大语言模型的知识固化在训练参数中，更新知识的唯一途径是重新训练或微调，这对于需要频繁更新信息的业务场景几乎不可行。RAG 通过将知识与模型分离，彻底改变了这一局面：更新知识库就是更新系统的知识边界，模型本身无需任何变动。
1. 为什么传统方式不够用
- 微调成本高、周期长：需要准备高质量标注数据、消耗 GPU 算力，训练完成后还要评估、部署，整个流程动辄数天甚至数周。
- 频繁微调会引入不稳定：每次微调都可能影响模型在其他任务上的表现，需要反复验证，得不偿失。
- 知识“粒度”难以控制：很难做到只更新某一条政策或某一个产品参数，而不影响其他内容。
在真实业务中，信息几乎是持续变化的——上午发布的调价通知、下午更新的退换货规则、临时上线的活动说明。这些变动要求系统能在分钟级内反映最新信息，传统的模型更新流程完全跟不上这个节奏。
2. RAG 的更新机制：知识库即知识状态
RAG 将知识库作为系统唯一的知识来源。所有事实性信息都以文档形式存储在外部向量数据库中，模型本身只负责检索后的理解与表达。这样一来，“更新知识”就简化为“更新知识库里的文档”。
具体操作步骤极为轻量：
- 准备新文档或修订内容：将需要新增或修改的信息整理为文本（如新版政策、产品变更说明、FAQ 条目等）。
- 重新切片与向量化：对新增或修改的部分进行切分（chunking），生成对应的向量嵌入。
- 写入向量数据库：在数据库中新增这些向量，或者将对应的旧切片标记删除、替换为新版本。
整个流程可以在几分钟内完成，无需重启服务、无需等待。更新生效的时间仅取决于数据写入和索引刷新的延迟，对于大多数向量数据库来说几乎可以忽略不计。
3. 一个真实的更新场景
某电商公司使用 RAG 搭建客服助手，知识库中存有《退换货政策》。原先政策规定：“商品签收后 7 天内可无理由退货。”后来公司为了提升客户体验，将期限延长到 15 天。
更新流程非常简单：
- 编辑原政策文档，将“7 天”改为“15 天”；
- 运行同步脚本，对文档重新分块，生成新向量，覆盖旧的对应片段；
- 无需改动模型、提示词或任何生成逻辑。
一分钟后，当用户询问“我能多久内退货？”时，系统检索到的已经是新政策片段，回答自动变为：“您可以在签收后 15 天内申请无理由退货。”整个过程不需要技术团队深度介入，甚至可由运营人员直接操作。
4. 支持高频增量更新
基于这种机制，RAG 特别适合以下更新频率高的场景：
- 金融信息：每日利率、汇率、行情解读；
- 规章制度：公司内部流程、报销标准、差旅政策；
- 产品数据：价格、规格、库存状态；
- 技术支持：新增故障排查手册、补丁说明。
而且，知识库可以随时新增领域知识，无需担心与已有知识冲突。例如在引入一个全新产品线时，只需将相关技术文档一次性入库，系统就能回答新产品的相关问题，完全不需要重新训练模型。
5. 与微调方案的对比
| 特性 | 模型微调 | RAG 知识库更新 |
|------|----------|----------------|
| 更新耗时 | 数小时到数天 | 分钟级 |
| 技术门槛 | 需要 ML 工程师 | 可由业务人员操作 |
| 更新范围 | 整体模型行为可能漂移 | 精准更新特定知识点 |
| 验证成本 | 需全面回归测试 | 只需核对文档内容 |
| 回滚能力 | 重新训练/切换模型版本 | 直接恢复旧版文档切片 |
6. 注意事项
知识更新虽然快速，但也要确保知识库内容的质量。实践中需要做到：
- 更新的文档经过审核，避免错误信息直接入库；
- 删除旧信息时保证彻底，防止新旧版本共存导致矛盾回答；
- 定期清理过时、失效的文档，保持知识库的“干净”。
只要知识库维护得当，RAG 就能真正做到“知识常新、回答常准”，让大模型应用摆脱训练周期束缚，适应快节奏的现实信息环境。