上一篇我们聊了切换模型的隐性成本，这篇回到更常见的场景：知识库上线三个月后，用户反馈「答案不对」的投诉变多了。团队第一反应是调检索参数、换嵌入模型——多半治不好。因为问题不在检索，而在库里的数据已经变质了。
企业知识库不是建好就一劳永逸的资产，更像冷链：出厂那天最新鲜，之后每一天都在靠近保质期。我们项目里把「保鲜」当成和「建库」同等重要的一期工程来做。这篇说清衰败的方式与保鲜的机制。
知识库衰败的三种方式
- 过期：价格表换版了、流程改了、产品参数更新了，库里还是旧文档。检索越是「忠于原文」，答错得越自信；
- 冲突：同一件事有三份文档各说各话——部门各自为政的产物。模型拿到互相矛盾的证据，输出开始在两个口径之间摇摆；
- 空窗：新员工问了 200 次的问题，库里根本没有对应文档。缺口不被发现，就一直空着，用户得不到答案就把整个系统判了死刑。
这三种病都会伪装成「智能体变笨了」。所以先别调参，先给库做体检：抽最近一百条差评问答，归类到过期/冲突/空窗三格子里，哪格最多治哪格。知识库与智能体的关系那篇讲过建库的分段治理，这篇讲的是建完之后。
保鲜机制一：每份文档带有效期
入库时强制填元数据：这份文档归谁维护、什么时候复核、多久过期。制度文档可以两年，价格政策可能只有一个月。到期未复核的文档自动降权直至隔离区，宁可回答「查无依据」，不拿过期材料硬答。
关键是把「保鲜责任」落到人：没有 owner 的文档视同过期。这一条做不到，后面所有机制都是空转。
保鲜机制二：单一事实源与口径裁决
同一主题指定唯一的权威来源，其余文档只留引用不留正文。冲突检出不靠人眼：对同主题文档做口径对比（数字、日期、流程步骤），发现分歧就走裁决流程，由 owner 拍板保留哪个口径，其余归档。
保鲜机制三：增量同步，而不是定期全量重建
按周期全量重建知识库有两个坏处：同步窗口里新旧混杂，以及「反正每周会重建」让没人关心单篇文档的状态。正确做法是事件驱动的增量同步——源系统文档一变更，对应切片立刻重新入库并触发该主题的冲突复检。全量校验退居兜底，低频跑一次即可。这条与上线前的六个指标同理：指标要挂在观测面板上持续看，不是上线前测一次。
保鲜机制四：缺口回流闭环
把「未命中」与「点踩」当成矿：每周从日志里聚合零结果问题与差评问题，按主题聚类后派给对应 owner 补文档或改文档。缺口回流是让知识库越用越好的唯一途径——用户的每一次问不到，都在免费给你出更新清单。
| 指标 | 定义 | 建议阈值 |
|---|---|---|
| 保鲜率 | 有效期内且已复核的文档占比 | ≥ 95%，核心业务域 100% |
| 冲突率 | 同主题存在未裁决口径分歧的比例 | ≤ 1%，发现即裁决 |
| 缺口闭环时长 | 高频未命中问题从聚合到补录的天数 | ≤ 7 天 |
一份保鲜自查清单
- 每份文档是否有 owner、有效期与复核记录；
- 到期未复核的文档是否会被自动降权或隔离；
- 同主题口径冲突是否有检出与裁决流程；
- 源系统变更到入库的延迟是按事件计还是按周计；
- 未命中与差评日志是否每周聚合、是否真的派单闭环；
- 保鲜率、冲突率、缺口闭环时长三个指标是否上面板。
检索调参的收益是百分比，数据保鲜的收益是生死：用户可以对「引用了旧制度」宽容一次，不会宽容第三次。把保鲜机制和建库工程一起交付，才是知识库能长期被信任的原因——这也是鼎上平台企业知识库能力里与解析、分段同等优先级的一层。