先说一个让很多技术负责人意外的事实：知识库召回率低、Agent 答非所问，90% 的情况下不是 embedding 模型不行，也不是检索策略拉胯，而是你往里塞的"知识"本身就没有治理。
我做过几年企业 AI 落地，见过最夸张的一个客户：知识库 8000 多篇文档，RAG 链路调了三轮，召回准确率从 62% 提到 68%，天花板死活破不了。最后一看库，三千多篇是重复的、过期的、或只适用某个已停售区域的旧政策。技术做到头，问题在内容。
这篇写给正在搭企业知识库 / 要做 RAG / 要上 Agent 的开发者，把失效根因和一套能落地的治理框架讲透，并附两个完整案例、一张成本账、一份 90 天计划。
一、五个根因，每一个都和"文档量"无关
- 时间衰减，没有生效日期。 知识库里"促销规则 v3"和"促销规则 v2"共存，谁新谁旧靠上传者手感。召回时按相似度，旧版本经常顶上来。我们见过一条 2024 年的临时补贴规则，到 2026 年还在被 Agent 当作常态答复。
- 范围漂移，没有市场/区域标记。 同一套 SOP，在国内和海外执行口径不同，文档不标市场，Agent 只能赌。跨境、多区域业务尤其高发，这也是"德国客户收到美国规则"这类事故的根源。
- 责任人真空。 文档过期了谁改？没人。业务方改了规则不会通知库管，库管也不知道哪条失效。知识库管理员往往是兼任岗位，本职一忙就顾不上。
- 冲突失明，没有取代关系。 新政策出来，旧的还在。两条打架时 Agent 没有裁决规则，拼概率。用户感受到的就是"同一个问题它每次答案都不一样"。
- 只存文档、不存结构化事实。 最致命。文档是给人读的，Agent 要的是字段级事实——这条事实来源是哪、什么时候生效、管哪个市场、谁负责、被谁取代过。不结构化，检索到的永远是非结构化文本，证明不了真假。
二、五个字段让事实"可证明"
治理的核心动作，是给每条事实贴五个字段：
source: 来源系统/文档，可溯源
effective_date: 生效日期，过期自动降权
market: 适用市场/区域/渠道
owner: 责任人，过期找谁
supersedes: 取代哪条旧事实
有了这五个字段，检索时可以按"过滤 → 排序 → 冲突转人工"三步走：
- 过滤：按 market + effective_date 筛掉失效/错配版本。这一步必须在向量召回之前做，而不是靠 prompt 让模型"自己理解版本"——因为相似度检索在召回阶段就决定了模型能见到的候选，旧版本一旦被召回，模型无从判断时效。
- 排序：source 权威、生效中、有 owner 的优先。一条带 owner 的当前事实，权重天然高于孤儿文档。
- 冲突转人工：同 market 同主题两条矛盾，不直接答，转人工或标"待确认"。拒绝瞎猜本身就是一个 feature。
某客户上了字段后，误答率两周内从 11% 降到 2% 以内——模型没换，只是它终于只见到该见的事实。
三、三层分层：结构化事实 / 规则文档 / 案例库
别把所有东西塞进同一个向量库。按稳定性和用途分三层：
| 层 | 内容 | 存储 | 取数方式 |
|---|---|---|---|
| 结构化事实 | 价格、库存、BSR、促销起止 | 数据库字段 | 实时 API |
| 规则文档 | 政策、SOP、合规 | 文档 + 4 字段 | 检索增强 |
| 案例库 | 真实对话、工单 | 带时间标签片段 | 少样本参考 |
Agent 路由：问"现在多少钱"走第一层实时接口；问"能不能退"走第二层规则；问"类似情况怎么处理"走第三层案例。把实时数值从文档剥离成接口，是降低知识库过期率最有效的一步。
四、一个开发视角的坑：召回前过滤比模型后处理重要
很多团队把"版本判断"寄托在 prompt 里让模型自己甄别。但事实是：相似度检索在召回阶段就决定了模型能见到的候选，旧版本一旦被召回，模型无从判断时效——它只会基于手头文本推理。所以时效必须在召回前用字段过滤掉，而不是交给模型"理解"。这是架构层面的事，不是 prompt 工程能补的。我们也见过有人想用更大的模型"自动识别过期"，结果误答率只降了零点几个百分点，成本却翻倍——方向错了。
五、完整案例一：退款判定的知识流
客户问"我上周买的扫地机想退，能退吗"。没治理时 Agent 捞一条"支持七天无理由"直接回"可以退"。真实情况：该 SKU 属大家电类目需质检退换、下单已满 9 天超窗口、德国仓当前暂停退换。
有治理后，Agent 判定链：先查结构化事实层——类目=大家电、下单日=9 天前、所在仓=德国仓（暂停）；再查规则文档层——大家电退换走质检、七天窗口以签收日算；三者冲突时按"专项规则 + 生效中 + 有 owner"优先，且仓库暂停状态是实时事实，直接否决泛化答复。最终 Agent 回："您这款属大家电，需质检退换，且已超七天窗口，德国仓目前暂停退换，请走厂家质检通道。"准确且可解释。关键不是模型聪明，是事实底座被治理过。
六、完整案例二：制造业采购知识库
一家零部件制造商把"供应商资质、交期、合规证书"塞进知识库给采购 Agent 用。没治理时，Agent 引了一条"供应商 A 通过 ISO 认证"，但该证书半年前因违规被吊销，旧文档没下架。采购 Agent 据此下了单，货到发现认证失效，整批返工。上治理后，证书类事实带"生效日期 + 监管源 + owner"，过期自动降权，同类事故归零。这个案例说明：治理不只影响客服体验，直接影响供应链与实物成本。
七、三个治理误区
误区一：文档多=知识全。 八千篇无字段文档的检索质量不会比八百篇好。治理密度比数量重要十倍。
误区二：让模型自己理解版本。 时效必须在召回前过滤，prompt 救不了被召回的旧版本。
误区三：上线即终点。 没有监控，知识库静默退化，三个月后没人信。
八、隐性成本账本（算给你看）
很多团队算不清"不治理"的代价，所以一直拖。我帮你算一笔：
- 人工复核成本：Agent 答完，人工还要核对，等于双倍人力。某客户上线前客服 30 人，上线后没治理，复核岗反而加到 12 人。
- 客诉与赔偿：误答一次退换政策，平均赔付 + 客诉处理成本约数百元，月度误答 200 次就是六位数。
- 返工成本：知识库过期导致 Agent 训练数据脏，回头清洗比一开始治理贵三倍。
- 信任破产：员工和顾客一旦不信任机器人，后续再准也没人用，前期投入全沉没。
对比：上五字段 + 每周过期扫描 + 抽样问答，一个兼职 owner 每周 2 小时就能维持。这笔账，怎么算都该先做治理。
九、90 天落地计划
- 第 1–2 周：盘点 top 50 高频事实，补五字段，先治"最常被问"的。
- 第 3–4 周：搭三层分层，把实时数值（价格/库存/排名）从文档剥离成接口。
- 第 5–8 周：上过期扫描脚本，每周推 owner；建抽样问答机制。
- 第 9–12 周：复盘误答率，扩到全量事实，固化流程。
十、15 分钟周自检清单
- 随机抽 10 条最常被问的事实，能否立刻说出生效日期、市场、owner？
- 过去一个月业务规则变过几次？对应的旧文档下架了吗？
- 有没有"同一问题两种答案"的矛盾事实？谁仲裁？
- 知识库最近一次过期清理是何时？超过 30 天即红灯。
- 跨市场业务，文档是否都带了市场标签？
命中两条以上，知识库已在退化，优先治理。
十一、把"治理"写进流程，而非靠自觉
治理最大的敌人是"靠人自觉"。建议三个硬关卡：文档入库前必须填五字段（否则拒收）；每月自动跑过期扫描（无人认领即标红）；每次 Agent 上线前必须过一遍抽样问答准确率。流程卡住，比任何口号都管用。
十二、金融合规场景的额外提醒
做金融、医疗等强监管行业，治理不是"更好"是"必须"。监管口径一旦过期被 Agent 引用，后果是罚单。这类事实的 owner 必须绑定合规岗，生效日期与监管发布日期强绑定，保留完整变更审计。我们给一家券商做投顾 Agent 时，单"产品风险等级"一条事实就拆了来源（监管文件号）、生效日、适用客户类型、owner（合规部）、取代关系五个字段，任何变动都要双人复核才允许上线。
十三、三个信号：你该先做治理，还是先上 Agent
- 你答不上来"最常被问的 10 条事实，谁负责、什么时候生效"——先做治理。
- 你的知识库超过半年没做过过期清理——先做治理。
- 你的业务跨三个以上市场/区域——先做治理。
三条命中任一条，别急着上 Agent，先把事实底座治好。
十四、亚马逊场景：外部事实层别自己补
做亚马逊的开发者注意：你知识库最容易过期的恰恰是想自己维护的外部事实——竞品价格、BSR、评论情感、广告位。这些每天变，人工维护不现实。
Pangolinfo 把亚马逊实时事实做成 API/MCP 工具，Agent 取这类外部事实直接调接口拿当天数据，而不是从两周前的文档里猜。我们做客服 Agent 时，凡涉及"竞品卖多少、广告位稳不稳"一律走 Pangolinfo 实时接口，文档库只管内部政策类事实。两层分开，知识库才不容易过期。
十五、结论
知识库治理的不是文档量，是事实的可信度。五字段 + 三层分层 + 持续监控，缺一不可。下次有人让你"再灌点文档提召回率"，先反问：你那条事实，什么时间、什么范围、谁负责、被谁取代过？答不上来，灌得越多只是把混乱搬进向量库。
十六、常见疑问快答（Q&A）
Q：小团队文档少，也需要治理吗？ 需要，但轻量。你不需要建复杂系统，只要给每条事实记"生效日期 + 负责人"两字段，过期有人管，就能避开 80% 的翻车。治理是习惯，不是规模。
Q：知识库和向量库是同一个东西吗？ 不是。向量库是检索基础设施，知识库是内容本身。很多人把"换向量库"当治理，但内容没治，换什么库都救不了准确率。
Q：五字段会不会让录入成本爆炸？ 不会。我们建议只对"高频被问"和"高风险"事实强制五字段，长尾事实先记来源+生效日期即可。先治重点，再扩全量。
Q：Agent 能不能自动给文档打字段？ 可以辅助，但不能全信。用模型从文档抽取建议字段，再由 owner 确认，能降低录入成本。但 owner 确认这一步不能省——责任必须落在人身上。
Q：多久做一次全量清理？ 高频变动业务（如电商、促销）建议月度；稳定业务（如合规 SOP）季度即可。关键是"有过期扫描"，而不是频率本身。
十七、一张对比表：治理前 vs 治理后
| 维度 | 治理前 | 治理后 |
|---|---|---|
| 误答率 | 8%–15% | 2% 以内 |
| 旧版本被引用 | 频繁 | 召回前过滤 |
| 冲突事实 | 拼概率 | 转人工/标注 |
| 过期无人管 | 常态 | 扫描告警 |
| 跨市场错配 | 高发 | 市场字段过滤 |
| 信任度 | 三个月衰减 | 稳定 |
十八、工具与落地清单
- 字段存储：数据库表或带元数据的文档系统，别只存纯文本。
- 过期扫描：定时脚本 / 云函数，每周跑。
- 抽样问答：用真实日志抽样，人工抽检。
- 版本管理：每条事实带 supersedes，旧版自动降权。
- 监控看板：事实过期率、冲突率、抽样准确率三指标。
十九、如果只能做一件事，先做哪件？
给 top 50 高频事实补"生效日期 + 负责人"两个字段，并跑一次过期扫描。这一件事，能拦住绝大多数上线即翻车的事故。其余分层、监控可以分阶段补。
