rag模型的知识更新与维护

知识库最怕的不是第一版搭得糙，是上线半年后没人敢动它：文档改了不知道要不要重嵌、切片参数一动全库重跑、答案变差了也说不清是哪一步的锅。这篇面向运维和开发者，把「什么变了要重跑哪一段」「多久检查一次」「怎么确认没跑坏」拆成可执行的清单，帮你把一次性搭建变成能长期维护的流程。

知识库最怕的不是第一版搭得糙，是上线半年后没人敢动它：文档改了不知道要不要重嵌、切片参数一动全库重跑、答案变差了也说不清是哪一步的锅。很多团队的 RAG 系统就是这么慢慢烂掉的——不是技术不行，是没人给「维护」这件事定规矩。

这篇面向运维和开发者，把「什么变了要重跑哪一段」「多久检查一次」「怎么确认没跑坏」拆成可执行的清单。目标很简单：让知识库从一次性搭建，变成一个有节奏、可追溯、能退回的长期流程。下面按变更分层、增量落地、重建触发、巡检节奏、回归验证五个环节展开。

先分清到底是哪一层变了

维护混乱的根源，往往是没分清变更发生在哪一层。同样是「文档更新了」，改一段正文和换掉整个嵌入模型，代价差着几个数量级。先分类再动手，能省掉大量无谓的全量重跑。

也有一类改动不必动向量：纯元数据层面的变化，比如标签、权限、生效时间、文档归属。这些通常只需更新存储里的字段，查询时按新字段过滤即可。什么情况下不适用这条？当元数据被拼进了切片的正文或参与了向量计算时，就得按内容变更处理，重新走一遍管道。

增量更新怎么落地：从变更捕获到入库

增量更新的核心是留一条固定的管道，让每次变更都走同一条路。管道本身要稳定，参数要可记录，否则出了问题根本没法复现。建议把「来源 → 内容指纹 → 分块 → 向量 → 索引」做成流水线，每一环都能单独重跑。

1. 用内容哈希做主键给每份文档算一个内容指纹，重复投递同一条不会产生重复切片。验证方法：同一文档连投两次，检查索引里的切片数是否只增加一份。
2. 标记旧切片失效先写新切片、再切换生效版本，不要原地覆盖。验证方法：在切换的中间时刻发起一次查询，确认返回的是完整旧版或完整新版，不是半新半旧。
3. 按批次跑并记录日志批量重嵌容易撞上游限流，按批次投递、失败重投。日志至少记下文档 ID、内容哈希、分块参数、嵌入模型标识、耗时与状态。
4. 先量出延迟基线并发档位别凭感觉设，先跑一轮测出自己环境下单批的延迟，再决定批大小。可以到 /tools/speed-test 先量出基线再压测。

日志这件事值得单独强调：出问题时，「这个切片是什么时候、用什么参数、由哪次任务生成的」如果答不上来，排查就只能靠猜。把这几项固定写进记录，是后续所有回滚和验证的前提。

什么时候必须全量重建，而不是打补丁

全量重建代价高，但该建的时候不能省。判断标准很直接：只要新旧向量不在同一个空间里可比，就必须整库重建，否则检索结果会莫名其妙地变差，而你还以为是数据问题。

• 必须全量重建：换了嵌入模型、改了分块大小或重叠、解析器升级导致正文结构变了、向量库版本或索引参数调整。
• 只需增量补齐：新增文档、文档小改、删除文档、权限或标签变更。
• 拿不准就先小样本试跑：抽一小批文档走一遍新老两套参数，比对召回结果再决定是否全量，别一上来就拿全库赌。
• 重建前先冻结写入：全量期间的新变更先排队，建完再补，否则新旧数据会交错在一起。

小样本试跑的成本很低，收益却很高。挑一批有代表性的文档——高频问答涉及的、结构最复杂的、边界情况最多的——跑一遍对照，基本就能看出新参数是变好还是变坏。对照的指标口径可以参考站内已有的检索评测文章，这里只讲什么时候该触发这次对照。

维护节奏：多久检查一次、检查什么

维护频率不该拍脑袋定，而是跟着内容波动走。更新频繁的文档源，做成每次提交触发或每日跑；稳定的手册类内容，周级或月级巡检就够。关键是周期一旦定了，就要有地方记录「上次检查是什么时候」。

把「知识库最后更新时间」当成一个对外可见的指标。如果被问到这个问题你答不上来，通常意味着流程里缺了记录环节，而不是内容真的没更新。这个指标本身也是判断管道健康的最快方式。

更新完怎么确认没跑坏，以及怎么退回去

每次更新后都需要一组固定的评测问题来兜底，覆盖高频问法、边界问法和只有新文档才答得出的问题。跑完比对召回和答案是否退化，不要等用户投诉才发现问题。

• 保留上一版索引，用版本号或集合名区分，出问题能一键切回旧版，而不是现场重建。
• 评测问题集要版本化，跟索引版本对应，避免换了问题集之后结果不可比。
• 答案变差时按顺序排查：先看检索回来的片段对不对，再看拼装与提示词有没有变，最后才怀疑模型本身。
• 更新失败要能自动回退，别让半成品索引对外提供服务。

这套流程不追求一次做完美，而是让每次更新都可追溯、可回退。开始可以把巡检周期放长、评测问题放少，跑顺了再逐步收紧。真正要避免的是「上线后再也没人敢动」的状态，那才是知识库最大的隐患。