知识库要保持“活”的状态，就需要一套清晰的更新机制。根据数据变动的范围和时效性要求，实践中主要采用三种更新方式：全量更新、增量更新、实时更新。这三种方式并非互斥，很多系统会组合使用，在不同场景下采用最合适的策略。
3.3.1 全量更新
全量更新是指一次性清空或完全替换知识库中的全部内容，再重新导入所有文档。就像给整个知识库“重装系统”，最终状态与源数据完全一致。
典型流程：
- 准备完整的文档集合（如最新的产品手册、政策汇编、FAQ 全集）。
- 清空旧有的向量索引，或创建一个全新的索引。
- 对所有文档进行切块、向量化，写入新的索引。
- 切换线上服务到新索引，下线旧索引。
适用场景：
- 文档经过大规模修订，旧版本与新版本差异巨大，增量修补难以保证一致性。
- 知识库整体结构发生变化（如切块策略调整、嵌入模型更换），旧索引无法继续使用。
- 定期（如每一季度）进行全量刷新，确保无残留过时信息。
优点：
- 数据绝对一致，不会有新旧版本混存的风险。
- 操作逻辑简单，没有累计偏差。
缺点：
- 数据量大时，索引构建时间较长，期间可能需要暂停服务或采用蓝绿部署。
- 每次更新都要处理全量数据，消耗计算资源。
实践经验：某中型企业将 5000 份内部文档的全量更新耗时约 40 分钟，他们选择在凌晨业务低峰期执行，并预先生成新索引，通过切换别名实现零停机。
3.3.2 增量更新
增量更新是指仅针对新增、修改或删除的少量文档进行局部索引调整，不动用其他数据。就像只修补墙上掉漆的部分，不需整面重新粉刷。
典型流程：
- 识别变更范围：哪些文档是新增的，哪些文档内容发生了修改，哪些文档应当被移除。
- 对于新增或修改的文档，单独切块、向量化，将新向量写入数据库，同时标记（或删除）对应的旧片段。
- 对于要删除的文档，直接根据其元数据（如文件 ID）将相关向量从数据库中移除。
适用场景：
- 日常的文档维护，如新增一篇技术公告、修订一条报销标准、下架一个过时产品说明。
- 数据量较大，全量更新成本过高，每天只需更新一小部分内容。
优点：
- 快速，分钟级生效。
- 资源消耗低，只处理变化的文档。
- 对线上服务几乎无影响。
缺点：
- 需要有良好的元数据管理，确保能正确关联文档与其切片，避免删除不完全或重复。
- 长期频繁增量更新可能产生碎片或微小不一致，偶尔仍需要全量刷新进行“保洁”。
实践经验：一个电商知识库每天接收数十条商品描述变更，增量更新机制让新信息在 5 分钟内即可被检索到，完全支撑大促期间的高频变动。
3.3.3 实时更新
实时更新是增量更新的极致形态：当源数据发生变化时，系统自动检测变更，立即对相应的文档切片进行更新，无需人工触发。
典型流程：
- 通过消息队列、数据库变更捕获（CDC）或文件系统监听，实时感知文档内容变更。
- 接收到变更事件后，自动执行局部的切片、向量化和索引写入。
- 配合向量数据库的实时刷新能力，让新内容即刻对检索可见。
适用场景：
- 对信息时效性要求极高的业务，如金融市场行情解读、突发故障处理知识库、实时更新的客服话术。
- 已建设完善的 CI/CD 或数据管道，能产出事件流的团队。
优点：
- 最大程度缩短“文档生效”与“检索可见”之间的延迟。
- 完全自动化，减少人工介入，适合高频变更环境。
缺点：
- 架构复杂度增加，需要建设和维护事件驱动管道。
- 必须有完善的校验和回滚机制，避免错误文档自动流入线上。
实践经验：某证券公司的研报解读系统接入了研究部门的文档发布事件，一旦分析师上传新的快评，系统在 10 秒内即可基于最新观点回答客户提问，显著提升了信息传递效率。
选择指南
| 更新方式 | 生效速度 | 运维复杂度 | 适用变更规模 |
|----------|----------|------------|--------------|
| 全量更新 | 分钟至小时级 | 低 | 大规模重构、周期刷新 |
| 增量更新 | 秒至分钟级 | 中（需元数据管理） | 日常少量文档变更 |
| 实时更新 | 秒级 | 高（需事件管道） | 高频、时效性极强的变更 |
大多数企业的最佳实践是：日常使用增量更新，按周或月执行一次全量更新以防微小的索引漂移，仅对某些核心、高频变数据使用实时更新。这种分层策略在维护成本和时效性之间取得了良好平衡。