知识库难的不是搭建 很多人第一次做 RAG，最有成就感的阶段就是把知识库首建跑通：文档解析、切分、入向量库、完成检索，整个链路一旦打通，会有一种“系统已经搭起来了”的感觉。但真到了业务里，你很快就会发现，最麻烦的不是第一次建好，而是后面长期更新。 首建是工程问题，更新是系统设计问题。 为什么这么说？因为首建面对的是静态数据，你只需要把现有资料导进去；更新面对的是动态世界，文档会修改、规则会过期、版本会冲突、目录会变化。系统这时不再只是“能不能查”，而是“能不能一直查对”。 很多项目后期翻车，通常不是因为检索能力不行，而是更新机制太粗糙。最典型的坑有三种。 第一，新文档进来了，旧版本没清干净，结果检索时新旧答案同时出现。 第二，每次更新都走全量重建，成本高、耗时长，一旦文档规模上来就根本跑不动。 第三，没有版本和生效时间概念，出了问题根本追不回去，不知道哪份内容是什么时候进入系统的。 这时候你会发现，知识库更像数据库，而不是网盘。它需要考虑版本、去重、失效、回滚、灰度，而不是只考虑“把文件放进去”。很多团队前期过于关注 embedding、chunk、rerank，却忽略了更新治理，最后系统表面还活着，实际答案已经越来越不可信。 真正能上线的知识库，不是“建过一次”，而是“能长期维护”。 这也是为什么我越来越看重增量索引、文档版本标识、失效清理策略这些能力。它们看起来不如模型和检索那么吸引眼球，但决定了系统能不能稳定跑三个月、半年，甚至更久。 如果你现在正在做项目，不妨提前补一个简单机制：每份文档都带上版本号和更新时间，入库时记录来源，更新时明确替换策略。哪怕系统还很小，这一步也会在后面救你很多次。 一句话总结：会首建的 RAG 是 Demo，会更新的 RAG 才是生产系统。 #AI #RAG #知识库更新 #向量数据库 #系统设计 #AI工程化 #大模型应用