我是小兵，一个动手派AI架构师。“AI工程化实战”系列第 11 篇。

先别查模型，查粮仓

第 10 篇《Human-in-the-Loop 反馈闭环》结尾我讲过一句话：用户问的知识点，模型答得没错，是知识库里根本没有、或者躺着过期版本。上周我自己踩进去了：用户问“新款 X100 的保修政策”，库里没有 X100 的保修页，躺的是上一代 X90 的过期政策。那一刻我认了：这类反馈不是模型的问题。正确率掉，先别查模型，查粮仓。

库是活的，会缺、会腐、会乱

我们的系统模型没换、prompt 没动，订单抽取正确率却一个月比一个月难看。为什么“库建好就完事”会让人白查三天？三个误区我挨个踩过。

第一，正确率一掉就查模型、回滚 prompt。你查的是脑，馊的是粮。约七成的 RAG 生产部署失败或不达标，第一归因是数据质量——Forrester 口径里 67% 算在它头上，不是模型也不是检索算法。你以为的模型幻觉，多半是知识库借模型的嘴在背过期料。

第二，把知识库当一次性建好的静态资产，上线后没人喂。库从上线那天就开始烂，只是烂得慢。过期信息能造成至少 20 个百分点的绝对准确率衰减，某些配置下比纯 LLM 基线还差；同一套架构，治理过的语料检索准确率能到 85%~92%，没治理的只有 45%~60%。

第三，偶尔发现脏料，就上线后手动改那几篇——打地鼠不是治理。原地改正在服务的索引，改到一半新旧混读，改坏了还回不了滚。

结论：知识库是活体，会缺、会腐、会乱。防腐坏 = 巡检找病 + 治理软下架止血 + 灰度换版治本还能回滚，三件事循环成一条持续管线，库才跟得上业务。

体检、止血、换血，还留退路

一句话：线上用 V_k 版答 → 巡检摸缺/腐/乱 → 治理先把能自动判的软下架止血 → 处置攒成 V_{k+1} → 过换版门 → 小流量放量、原子切换、V_k 可回滚 → 回巡检做术后复查。

① 巡检：体检找病，先算自己的账单。三路情报源按成本拆两档。线上探针便宜，天天测：空检率、高频未命中 query 聚类，检索打点白拿，再并上反馈闭环篇打标的 kb_flag 桶。内容扫描贵，按周/月跑：时效超期、同实体冲突、近似重复、孤儿切片。防腐坏最大的隐藏成本是巡检本身——天天全量扫，账单比腐败还难看。第三路是上游比对，专抓“应入未入”：权威源已发布、库里没收录，这就是缺。缺漏在库外，巡检只能报“缺了哪批料”，补料还得等权威源。

② 治理：能自动判的先自动，缺漏挂起。四种病四套处置：过期软下架、矛盾标 pending 暂停命中、重复合并去重、缺漏登记待补清单。最后这刀最反直觉，单独讲。

为什么缺漏绝不自动补。过期、矛盾、重复是“库内可判”，机器能自动处置；缺漏是“库外才知道”——库里没有的料，巡检只能得出“缺了”。让模型按用户问题批量生成 FAQ 补进库，看着“查不到”少了，其实把幻觉一字不差写进了库，以后每次都被当权威料召回。补料在库外，巡检是报警器不是消防队——缺只能报警，不能自愈。

为什么矛盾不二选一。同一款 X100 两份 active 参数页，一份保修 24 个月、一份 36 个月，让模型硬选一个答，等于随机挑一个错。宁可查不到，也别硬选——把“查不到”变成可观测、可仲裁的信号。重复那刀也有数字：某案例 80% 重复率，去重后 answer correctness 从 0.57 涨到 0.76。

③ 灰度更新：知识库不能 UPDATE，只能换版本。为什么不能原地改？正在服务的索引上改文档，会造成新旧混读、检索空间不一致，改坏了还不可回滚。所以把“更新”拆成两个动作：软下架压症状，打标 + 检索端过滤，秒级生效、不重建索引；换版治本，根治动作攒成 V_{k+1} 快照，过换版门、小流量放量、原子切换，旧快照保留，回滚就是指针指回去、零重建。“治本还不伤线上”靠换版门两道闸：第一道检索回归，新版在 golden 用例上召回不破地板；第二道影子验证，新版跑留痕的真实 query，命中集不比旧版差。两道都绿才放量。这等于把“改库”从“偷偷改几篇文档”升级成“发布一个版本”——索引是发布物，不是草稿纸，跟发服务、发 prompt 一个纪律。换版记得把库版本号写进缓存 key，别让语义缓存替旧粮吐答案。

demo：一份会烂的 mock 库，体检止血换血全跑通

最小实现纯标准库、离线可跑，把向量库、embedding、权威源藏在可替换接口后，生产换 Qdrant alias 原子切、换检索回归 harness，防腐坏逻辑一行不改。mock 库刻意埋四种病：X90 过期保修、X100 两份参数页保修月数打架、X80 同文档三个版本都 active、上游已发布但库里没有的 X200。

跑完是确定性数字：过期 1 条软下架、矛盾 1 组暂停、重复 1 组合并、缺漏 1 类挂起，权威源补料后换版门放行 canary，V_k 旧快照保留可一键回滚。7 个断言一条锁一个承诺，最锋利是这对对照：pipeline 里根本没有“自动补料”的函数，调用直接报错——缺漏不自动补是代码结构保证，不是靠自觉；混假料则 golden 破地板、门直接 hold。

踩过的坑，都真付过费

正确率阴跌一个月，我先查了三天模型。回滚 prompt、换模型全没用，最后翻反馈闭环篇打标的 kb_flag 桶才定位：新款上市三个月，库里保修页还躺着上一代 X90。过期伤是阴性的——不报错、不告警，只是答案慢慢不对，监控还是绿的。教训：脑和粮两条线，排查也得分。

让模型自动补 FAQ，把幻觉写进库。为了填“查不到”的缺漏，我用模型批量生成 FAQ，看着“查不到”确实少了。两周后新模型评测，golden set 里多了好几条照着假 FAQ 答的错答案。让模型自动补料，就是把幻觉制度化——巡检是报警器，不是消防队。

工具面一句话收口：快照/切库用 alias 原子切 + 旧版保留，文档版本用 DVC，回归门用 RAGAS/TruLens——都不是原地 UPDATE，全是“换版本 + 可回滚”。6 问清单抄走就能用：有“查不到/过期”的线上情报源吗？文档带时效/来源/版本元数据吗？过期软下架还是原地改？缺漏挂起等权威源还是自动补？换版走灰度、可回滚吗？

烂了能被发现、能止血、能换血

回到 kb_flag 桶那批“模型没答错”的样本。同样的“查不到/查到过期”，这次走完三件事，从偶发客诉变成体检单上定期复查的数字。知识库不是从此不烂了——是烂了能被发现、能快速止血、能整版换血还不伤线上。记住一句：对活体不能 UPDATE，只能换版本；正确率掉，先别查模型，查粮仓。

跑完我也看清：巡检能报“缺了哪批料”，可真要把料补进来、把版本和血缘管住、把离线批量加在线增量接进底座，得靠一整套数据工程底座，不是一条巡检管线能单独干的活。粮仓的地基，下一篇《数据工程底座》接着挖。

这篇是脱水版。完整版含可离线跑的 mini_kb_anticorruption.py + 7 个断言的测试、缺/腐/乱体检大表、三个付费踩坑、选型对比和工具对接，已同步发布在 CSDN。点文末“阅读原文”看完整代码和可跑 Demo。

评论区聊聊：你们的 RAG 正确率往下掉时，是先查模型还是先查库？有没有过“模型没答错、是库里躺着过期版本”的时刻？

我是小兵，一个动手派AI架构师。这里只写自己跑过、摔过、复盘过的AI工程化案例。如果你想持续收到这类实战内容，点击关注，下篇见。