《AI 知识卡片》第 16 期 · 建库不是一次性工程，难的是进行索引维护
知识库建好之后，文档还会继续修改更新。比如：新写了一篇说明、参数从 500 改成 800、某个功能下线了、去年的政策作废了......。知识库更新很正常，但是索引不会自己跟着变------它还是建库那天的样子。
于是问题就来了：文档变了，知识库怎么同步更新？
两种做法：全量重建 & 增量更新
全量重建就是推倒重来：所有文档重新读一遍、重新切块、重新嵌入、重建索引。
优点：逻辑简单，而且天然一致。每次都从当前的文档状态出发，不用考虑历史残留，也不需要维护任何额外信息。库不大的时候，写个定时任务半夜跑一遍就完事。
代价：成本跟着规模线性长 。当知识库达上百万个块就是几小时的机器满负荷，而且还要回答一个尴尬的问题：重建期间线上用哪个索引？ 通常得留着旧的顶着、新的建好再切换，于是磁盘备双份，切换那一刻还要考虑正在进行的查询。
增量更新则只处理变动的那部分：新增一篇文档，就只把它切块、嵌入、追加进现有索引。
优点：节省开销，且改完立刻就能被检索到。
代价：全量重建帮你兜住的一致性，现在得你自己兜。 库里到底有没有这篇、旧版本删干净了没、id 对不对得上------这些问题以前不存在，现在都需要考虑。
两种做法怎么选择？
| 典型场景 | 建议 |
|---|---|
| 团队内部的几百篇产品文档、API 说明，一周改几次 | 直接全量重建，凌晨定时跑一遍，省心 |
| 电商客服知识库，每天上下架几千个商品、改几百条政策 | 走增量，把下面三样东西老实备齐 |
| 法规合规库，量大但每季度集中更新一次 | 趁更新窗口整体重建，反而比增量简单 |
| 内部维基，每天零散编辑几十篇，总量已到百万块 | 日常增量 + 每周全量重建对账 |
增量更新做法的关键
第一：稳定且可重算的块 id
用文件路径加内容哈希这类方式生成，保证同一篇文档无论处理多少次都得到同一个 id。这样"追加"就变成了幂等操作------已经在库里的会被覆盖，而不是又存一份。
第二：一份"文档 和 块 id"的映射表
一篇文档会被切成很多块，散落在索引里。想删掉它，就得知道它对应哪些块。这件事的关键认知是：索引里没有"修订"这个操作 。改一篇文档，实际动作是先把旧块全删掉，再把新块加进去。
删不干净的后果可能导致你知识库里面两份内容的描述冲突，检索把两条都捞回来交给模型，而模型压根没有判断谁更新的依据。这种问题在客服、合规、财务这类场景里，代价可不只是体验不好。
第三：攒一批再写
嵌入模型吃批量：一次喂几十条，矩阵运算能并行摊薄开销；一条一条地喂，固定成本全压在这一条上，单价反而更高。频繁写盘也不划算。
所以增量真正省的是总量 ，不是单价。实践上的推论是：别一有改动就立刻追加，用队列攒一批，或者按分钟级的窗口合并处理。
维护可能更复杂
一个复杂 RAG 系统里需要跟着文档变的东西可能更多：
- 关键词索引。BM25 和向量索引通常是两套东西，各有各的更新方式。库小的时候不少实现干脆每次启动在内存里重算，库大了就得和向量索引一样单独设计增量。
- 知识图谱。加图谱节点容易，难的是它该不该和已有实体合并，在持续更新的场景里只会越滚越大。
- 元数据。文档正文没改，但分类、权限、有效期改了。如果只需要改元数据，前提是你的存储支持单独更新元数据，而不是连向量一起重写。
还有一种情况会让所有增量手段一起作废：换 Embedding 模型 。存和查必须用同一把尺子，换了模型，旧向量和新向量压根不在一个空间里，只能全量重建，没有第二条路。所以选模型这件事，前期多花点时间是值得的。
一句话总结
建立知识库不是一次性工程，它更像是维护一份始终在变的副本。小库直接重建最省心，大库走增量。