RAG 索引维护：文档改了，知识库要不要重建？

MomentYY 2026-08-19 0 阅读4分钟

《AI 知识卡片》第 16 期 · 建库不是一次性工程，难的是进行索引维护

  知识库建好之后，文档还会继续修改更新。比如：新写了一篇说明、参数从 500 改成 800、某个功能下线了、去年的政策作废了......。知识库更新很正常，但是索引不会自己跟着变——它还是建库那天的样子。

  于是问题就来了：文档变了，知识库怎么同步更新？

两种做法：全量重建 & 增量更新

全量重建就是推倒重来：所有文档重新读一遍、重新切块、重新嵌入、重建索引。

  优点：逻辑简单，而且天然一致。每次都从当前的文档状态出发，不用考虑历史残留，也不需要维护任何额外信息。库不大的时候，写个定时任务半夜跑一遍就完事。

  代价：成本跟着规模线性长。当知识库达上百万个块就是几小时的机器满负荷，而且还要回答一个尴尬的问题：重建期间线上用哪个索引？ 通常得留着旧的顶着、新的建好再切换，于是磁盘备双份，切换那一刻还要考虑正在进行的查询。

增量更新则只处理变动的那部分：新增一篇文档，就只把它切块、嵌入、追加进现有索引。

  优点：节省开销，且改完立刻就能被检索到。

  代价：全量重建帮你兜住的一致性，现在得你自己兜。 库里到底有没有这篇、旧版本删干净了没、id 对不对得上——这些问题以前不存在，现在都需要考虑。

两种做法怎么选择？

å ¸åž‹åœºæ™¯	建议
å›¢é˜Ÿå† éƒ¨çš„å‡ ç™¾ç¯‡äº§å“æ–‡æ¡£ã€API 说明，一周改几次	ç›´æŽ¥å ¨é‡é‡å»ºï¼Œå‡Œæ™¨å®šæ—¶è·‘ä¸€éï¼Œçœå¿ƒ
电商客服知识库，每天上下架几千个商品、改几百条政策	走增量，把下面三样东西老实备齐
法规合规库，量大但每季度集中更新一次	趁更新窗口整体重建，反而比增量简单
å† éƒ¨ç»´åŸºï¼Œæ¯å¤©é›¶æ•£ç¼–è¾‘å‡ åç¯‡ï¼Œæ€»é‡å·²åˆ°ç™¾ä¸‡å—	日常增量 + æ¯å‘¨å ¨é‡é‡å»ºå¯¹è´¦

增量更新做法的关键

第一：稳定且可重算的块 id

  用文件路径加内容哈希这类方式生成，保证同一篇文档无论处理多少次都得到同一个 id。这样“追加”就变成了幂等操作——已经在库里的会被覆盖，而不是又存一份。

第二：一份“文档 和 块 id”的映射表

  一篇文档会被切成很多块，散落在索引里。想删掉它，就得知道它对应哪些块。这件事的关键认知是：索引里没有“修订”这个操作。改一篇文档，实际动作是先把旧块全删掉，再把新块加进去。

  删不干净的后果可能导致你知识库里面两份内容的描述冲突，检索把两条都捞回来交给模型，而模型压根没有判断谁更新的依据。这种问题在客服、合规、财务这类场景里，代价可不只是体验不好。

第三：攒一批再写

  嵌入模型吃批量：一次喂几十条，矩阵运算能并行摊薄开销；一条一条地喂，固定成本全压在这一条上，单价反而更高。频繁写盘也不划算。

  所以增量真正省的是总量，不是单价。实践上的推论是：别一有改动就立刻追加，用队列攒一批，或者按分钟级的窗口合并处理。

维护可能更复杂

一个复杂 RAG 系统里需要跟着文档变的东西可能更多：

• 关键词索引。BM25 和向量索引通常是两套东西，各有各的更新方式。库小的时候不少实现干脆每次启动在内存里重算，库大了就得和向量索引一样单独设计增量。
• 知识图谱。加图谱节点容易，难的是它该不该和已有实体合并，在持续更新的场景里只会越滚越大。
• 元数据。文档正文没改，但分类、权限、有效期改了。如果只需要改元数据，前提是你的存储支持单独更新元数据，而不是连向量一起重写。

  还有一种情况会让所有增量手段一起作废：换 Embedding 模型。存和查必须用同一把尺子，换了模型，旧向量和新向量压根不在一个空间里，只能全量重建，没有第二条路。所以选模型这件事，前期多花点时间是值得的。

一句话总结

  建立知识库不是一次性工程，它更像是维护一份始终在变的副本。小库直接重建最省心，大库走增量。