本文导读
引用能够打开、数字也能在原文中找到，并不代表答案适用于今天的版本和现场。本文拆解“带证据的过期答案”为什么难查，并给出一套同时检查来源、时间、状态、冲突与现场的验证方法。
这类错误最难发现。
AI 给出的链接能打开，引用内容也确实存在，甚至每一个数字都能在原文中找到。你检查一圈，以为这次终于没有幻觉了。
结果拿去执行，还是错。
原因可能很简单：资料是真的，但已经失效。
“存在过”不等于“现在有效”
做数据库运维的人对这个问题并不陌生。
一篇官方文档说某个参数默认值是 A，这句话在 19c 可能成立，到 23ai/26ai 已经变了；一篇升级说明给出的版本还在支持期，几个月后可能已经 EOL；某个云服务接口去年允许的字段，今年已经弃用。
如果 Agent 只证明“我找到了官方出处”，没有证明“这条规则适用于当前版本、当前时间和当前环境”，引用越完整，反而越容易让人放松警惕。
我把这种问题叫作“带证据的过期答案”。
它不是编造，所以普通的事实核查很容易漏掉。
为什么 Agent 特别容易踩这个坑
搜索系统通常会优先返回相关性高、被引用多、结构清楚的页面。老文档往往恰好具备这些特点。
知识库也一样。公司里一份写得很完整的旧 SOP，比散落在聊天记录里的新决定更容易被检索出来。Agent 于是给你一份论证严密、但违反上周新规则的方案。
问题不一定出在检索能力，而是知识缺少四个字段：
- 什么时候生效；
- 什么时候失效；
- 适用于哪个版本或对象；
- 被哪条新规则替代。
没有这些信息，Agent 只能把“最像答案的内容”当作答案。
官方资料也要做时间判断
我现在检查 AI 研究结果，会把“来源可信”和“当前适用”分开。
第一步看来源。优先官方文档、Release Notes、产品公告和原始论文。
第二步看时间。页面发布日期、最后更新时间、软件版本、支持周期是否覆盖当前环境。
第三步看状态。内容是正式发布、预览、Beta、已弃用，还是社区方案。
第四步看冲突。有没有更新的文档对同一问题给出不同结论。如果有，不能让 Agent 自己静默选择，必须把冲突摆出来。
第五步回到现场。数据库里当前参数、补丁清单、对象状态和实际返回值，优先级高于一篇通用文档。
一句话：文档证明“厂商怎么说”，现场证明“你的系统现在是什么”。
企业知识库真正缺的不是更多文档
不少公司做 RAG，第一步就是把网盘、飞书和 Wiki 全部灌进去。资料量上去了，答案却不一定更可靠。
因为旧制度、临时通知、会议决定和正式 SOP 混在一起，检索系统不知道谁覆盖谁。它只知道哪段文字与问题最相似。
比继续收集文档更重要的，是治理：
- 给关键规则标注负责人、版本和有效期；
- 新规则发布时，明确关联被替代的旧规则；
- 对价格、接口、组织制度等高时效信息设置复核周期；
- 答案展示资料时间，不只展示链接；
- 找不到当前有效证据时，允许 Agent 回答“不确定”。
最后一条看起来保守，却比生成一份过期但完整的答案便宜得多。
本文小结
解决 AI 幻觉，不能只要求“必须引用来源”。真实来源也可能过期、越界或不适用于当前版本。可靠答案至少要同时回答：出处是什么、何时有效、适用范围是什么、现场是否吻合。对企业 Agent 来说，数据的新鲜度和版本关系，本身就是知识的一部分。
本文小结
要求 AI 引用来源只能解决是否编造，不能证明资料仍然有效。可靠答案还要标明时间、版本、适用范围和替代关系，并回到现场核验；企业知识库如果不治理这些元数据，资料越多，过期答案反而越像真的。
