上百万个文档块的知识库，全量重建一次要跑几个小时，磁盘还得备双份。这事最反直觉的判断是：RAG 落地的成本高峰，从来不在建库那一天，而在之后每一次文档更新。

这是什么

RAG（Retrieval-Augmented Generation，检索增强生成）是一种让大模型回答问题时，先去企业自己的资料库里"翻一遍"再开口的技术路径。政策文档、产品手册、客服话术，都能塞进去。

问题在于：资料不是死的。参数改了、政策作废了、产品下线了，AI 知识库里的"索引"（相当于图书馆的目录卡）不会自己跟变——它还是建库那天的样子。

于是两条路：

  • 全量重建：所有文档重新处理一遍。逻辑简单，但库一大，几小时机器满负荷，磁盘还要双份。
  • 增量更新：只处理变动的部分。快，但要自己解决"旧版本删干净没""新版本和已有内容冲不冲突"这类问题。

作者的朴素判断：小库（几百篇内部文档）定时全量重建最省心；大库（百万级文档块）必须走增量，但要备齐三样东西——稳定的块 ID、文档到块的映射表、批量写入。

行业怎么看

支持方认为，增量更新是规模化的必经之路。客服系统每天上下架几千个商品、合规库每季度集中更新法规，这些场景下全量重建既不现实也不划算。关键是把"文档到块的映射表"做扎实，旧版本必须删干净——否则检索会同时召回新旧两条内容，模型没能力判断谁新，客服、财务、合规场景里代价是真实的。

但反对声音同样值得听。一位资深架构师指出：很多团队低估了"换 Embedding 模型"的代价。Embedding 是把文字转成向量的工具，一旦更换，存量和增量向量不在同一个语义空间里，所有历史数据必须全量重建，没有第二条路。选模型那一步决策的成本，远比想象的高。

还有一种被忽视的复杂度：BM25 关键词索引（基于词频的传统检索方式）和向量索引是两套体系，知识图谱（把实体关系结构化的网络）又叠加进来。一个认真的 RAG 系统里，要跟着文档同步更新的可能有三到四套东西，每套更新逻辑都不一样。

对普通人的影响

对企业的 IT 部门：评估 AI 知识库项目时，不能只看"建库要花多少钱"，要算"文档一年改多少次 × 每次处理的算力成本"。维护账可能比建库账大几倍。

对个人职场：未来企业内部知识库的"维护角色"会变得具体而稀缺——这既不是纯算法工程师，也不是传统文档管理员，是新的复合岗位。

对消费市场：用 AI 客服查订单、问政策时，如果对方答非所问或给出过时信息，别急着骂客服——很可能是上游知识库更新没跟上。