AI 事实性：让模型找到证据，而不是生成答案

发表于 分类于 本文字数： 3.9k 阅读时长 ≈ 14 分钟

这两年用 AI，最容易让人产生错觉的一件事，是它太会把答案写得像答案。

你问一个库的参数，它能列出名字、类型、默认值和示例。你问一篇论文，它能说出作者、年份、方法和结论。你问一个报错，它能给出原因、修复步骤和注意事项。很多时候这些确实有用。问题在于，只要它的语气足够完整，我们就很容易跳过一个最朴素的问题：

这些东西是它找到的，还是它生成的？

这两个动作完全不同。

生成，是模型根据上下文和语言模式补出一个最可能的回答。找到，是它从文件、日志、数据库、官方文档、论文、搜索结果或测试输出里拿到证据。前者可以很快，后者才接近事实。

所以这篇想接着 AI 上下文工程：把正确的信息放到正确的位置 往下谈一个更窄的问题：AI 为什么会一本正经地胡说，日常使用里又该怎样让它找到真实的东西，而不是生成一个像真的答案。

流畅不等于真实

AI 的危险不总是来自明显的错误。

明显的错误反而容易处理。代码跑不起来，链接打不开，数字离谱，概念混乱，人一眼就能发现。真正麻烦的是那些“刚好像对”的回答：结构完整，术语准确，语气稳定，还附带几个看起来很专业的解释。

比如它说某个 API 有一个参数。这个参数名很像这个库的命名风格，示例也很自然，甚至连异常情况都写出来了。读的人如果没有打开官方文档，就很容易把它当成事实。

这不是因为模型“故意骗你”。更常见的情况是，它在做自己最擅长的事：根据上下文补全一个合理的文本。

问题在于，合理文本不等于真实世界。

软件开发里尤其如此。一个字段应该在订单创建时确定，还是在支付成功时确定；一个缓存能不能写；一个数据库事务边界在哪里；一个 API 参数是否真的存在。这些都不是“语言上合理”就能决定的事实。它们要么来自业务规则，要么来自代码现状，要么来自文档、测试和运行结果。

AI 可以帮助我们解释这些事实，但不能凭语气让事实成立。

AI 为什么会自信地错

大语言模型的基础训练目标，通常不是判断一个命题是真还是假，而是在给定上下文后预测后续 token。它从大量文本里学到语言模式、概念关系、格式习惯和一部分世界知识，但这不等于它内置了一个稳定的事实裁判。Kalai 等人在关于语言模型幻觉的研究里，也把预训练目标和评测激励视为幻觉持续存在的重要原因之一。[1][2]

这能解释很多现象。

语法、常见概念、经典算法、热门框架的基本用法，因为在训练文本里重复很多，模型往往能说得不错。可具体版本、冷门参数、最新价格、某个仓库当前状态、某个团队内部约定，就没有这么稳定。它可能见过相似文本，于是生成一个“像那类事实”的答案。

还有一种更微妙的错误，是模仿人类错误。

TruthfulQA 这类研究专门测试模型是否会复述常见误解。它提醒我们：训练语料里不只有事实，也有误解、过时说法、谣言、玩笑、转述错误和大量自信但错误的人类文本。模型越会模仿人类表达，就越可能学到这些表达方式。[3]

所以“模型更大”不自动等于“更真实”。规模通常会带来更强的语言能力、推理能力和知识覆盖，但事实性还需要另外的东西：证据、检索、工具、校准、评测和允许它停下来的机制。

“不要幻觉”不是一句 Prompt 能解决的

很多人会在提示词里写：不要编造，不知道就说不知道，必须真实。

这当然比什么都不写要好。但它只能解决一小部分问题。

如果模型没有看到正确资料，它仍然只能在已有上下文和参数知识里猜。如果搜索结果本身错了，它会基于错误材料总结。如果 RAG 检索拿到了相似但不相关的 chunk，它会把噪声包装成答案。如果引用没有被打开验证，它甚至可能给你一个存在但不支持结论的链接。

提示词能改变回答风格，却不能凭空创造事实。

这也是为什么我现在越来越不把“减少幻觉”理解成一个模型问题，而是理解成一个工作流问题。我们真正要设计的，不是让 AI 在没有证据时说得更保守一点，而是让它在需要事实时走向证据。

有些事实要查官方文档，有些要读本地代码，有些要跑测试，有些要查数据库，有些要搜索最新来源，有些要直接问人。把这些通道区分开，比在 prompt 里重复“请真实”更有用。

事实要先有真源

让 AI 找真实东西，第一步不是搜索，而是判断真源在哪里。

不同事实的真源不一样。

如果问题是“RAG 是什么”，可以先看论文、教材、已有知识页和权威解释。如果问题是“某个 API 现在支持什么参数”，默认应该看官方文档、release note 或源码。如果问题是“这个项目为什么测试失败”，真源就在当前仓库、日志、测试输出和复现步骤里。如果问题是“这个价格、政策、版本是不是最新”，就必须查当前页面或 API。

我现在会先把事实分成几类：

事实类型 更可靠的来源
稳定概念 论文、教材、权威文档、已审知识库
实时信息 官方页面、API、公告、原始新闻
项目事实 源码、测试、日志、配置、数据库记录
可计算结果 脚本、计算器、测试、解析器
规范要求 标准、法条、官方文档、源码
社区经验 多个独立案例，且只能标注为观察

这张表看起来很朴素，但它能挡住很多幻觉。

因为它把问题从“AI 知不知道”换成了“这个事实应该去哪里确认”。这一步一换，AI 的角色也变了。它不再是一个凭空回答的专家，而是一个检索、整理、核验和表达证据的助手。

搜索、RAG 和工具各自解决什么问题

很多人谈 AI 事实性时，会很快跳到 RAG。

RAG 确实重要。它的基本思路是把外部资料检索出来，再让模型基于这些资料回答。RAG 原始论文把这种方式描述成参数化记忆和非参数化外部记忆的结合，用来改善知识密集任务中的事实性和可追溯性。[4]

但 RAG 不是真理机器。

它解决的是“模型没看到资料”的问题，不自动解决“检索资料是否正确”“chunk 是否完整”“排序是否合理”“模型是否忠实使用资料”的问题。RAGAS 之所以会把 RAG 评估拆成 context precision、context recall、faithfulness 等指标，就是因为检索和生成都有可能出错。[5]

搜索也一样。

搜索能帮 AI 找到候选来源，但搜索结果第一条不是事实。SEO 页面、转引文章、AI 摘要、旧教程、营销材料，都可能排在前面。搜索只能扩大候选范围，不能替代来源判断。

工具调用又是另一类东西。

如果问题能被执行工具回答，就不要让模型猜。代码能不能跑，跑测试。文件是否存在，读文件系统。JSON 是否合法，用解析器。SQL 是否返回某条记录，查数据库。算术是否正确，用计算器或脚本。

我更愿意把它们分成三层：

  • 搜索和 RAG：帮 AI 找候选证据。
  • 工具和 API：帮 AI 获取可执行事实。
  • 人和规则：决定高风险场景里什么算足够证据。

这三层不能互相替代。尤其是生产变更、财务、医疗、法律、安全这类场景，AI 的证据整理不能替代责任主体。

引用不是装饰，引用要支撑结论

我以前也会被“带引用的回答”安抚。

有链接，看起来就靠谱一点。可后来发现，引用本身也会幻觉。

有时链接根本不存在。有时链接存在，但文章里没有支持那个结论。有时来源支持的是一个更窄的说法，AI 把它扩成了普遍结论。有时来源已经过时，只适用于旧版本。还有时几个页面互相转引，看似很多来源，其实只有一条没有追到原文的引用链。

所以引用不能只看有没有。

要看它是否直接支撑 claim。

一个更稳的做法，是把答案拆成几条关键断言，然后逐条问：

1
2
3
4
5
6
这个 claim 是什么？
证据在哪里？
来源是一手还是二手？
适用日期、版本、地区是什么？
来源是否直接支持这个结论？
有没有冲突来源？

FActScore 和 SAFE 这类长文本事实性评估方法，也是在把长答案拆成更细的原子事实，再逐条检查。[6][7]

日常不一定要做得这么正式。但思路很有价值：不要让一整段流畅文字整体通过。把它拆开，逐条看证据。

什么时候应该让 AI 说不知道

好的 AI 系统不应该只会回答。

它还应该会停下来。

这句话听起来像产品体验问题，其实是事实性问题。如果评测和使用习惯只奖励“给出答案”，不奖励合理的“不知道”，模型就会被推向猜测。Kalai 等人的研究里就指出，很多 accuracy-only 评测会让猜测比 abstain 更有收益。[1:1]

在日常使用里，我会把这些情况视为应该停下来的信号：

  • 没有找到一手来源。
  • 来源之间冲突，还没判断哪个更新或更权威。
  • 问题里带着未经确认的前提。
  • 事实依赖当前时间、地区、版本或账号权限。
  • AI 给出了引用，但引用没有直接支撑结论。
  • 输出会影响钱、健康、法律、安全、生产系统或对外发布。

这时好的回答不是“我猜一个最可能的”。而是：

我现在只能确认到哪里。

还缺什么证据。

下一步应该查哪里。

这个结论暂时不能写成事实。

能说不知道，是事实工作的一部分。

一个更稳的事实获取流程

把前面的东西合起来，日常可以用一个不太重的流程。

第一，判断事实类型。

这是稳定概念、实时信息、项目事实、可计算结果、规范要求，还是社区经验？不同类型对应不同真源。

第二，选择证据通道。

能用文件、日志、测试、数据库、API 解决的，优先用工具。资料规模很大、需要找少量证据时，再用搜索、RAG、rerank。稳定概念可以先用已有知识解释，但关键结论最好仍然能回到来源。

第三，抽取关键 claim。

不要把一整段答案整体看成“对”或“错”。拆出关键断言：版本、原因、规则、步骤、限制、风险、结论。

第四，做来源核验。

来源是否一手？是否过时？是否直接支持 claim？是否存在冲突？如果只是社区经验，就不要写成普遍事实。

第五，决定输出方式。

证据足够，就回答并标出边界。证据不足，就澄清、补检索或说不知道。高风险场景，要把人工审核放在流程里，而不是最后让人扫一眼。

这个流程不复杂，但会明显改变 AI 的使用方式。

以前是：我问，AI 答。

更稳的是：我问，AI 找证据，AI 解释证据，我检查关键 claim，最后才形成答案。

管理 AI 的事实性，就是管理证据链

我现在越来越觉得，AI 不是不能参与事实判断。

恰恰相反，它很适合参与。它能帮我们列搜索词、读文档、比较来源、整理冲突、抽取 claim、生成检查清单、把零散证据写成清楚的解释。

但它不应该凭空拥有事实最终裁决权。

事实不是从模型嘴里自然长出来的。事实来自世界里的某个位置：文件、日志、数据库、论文、标准、官方文档、用户确认、测试结果、实际运行状态。AI 的工作，是把我们带到这些位置，再帮我们理解它们。

如果说 AI 上下文工程：把正确的信息放到正确的位置 讲的是“让 AI 在正确的信息现场工作”，那这篇想补上的就是：事实性要求这个现场里必须有证据链。

不要只问 AI 知不知道。

要问它证据在哪里。

参考与延伸阅读

  1. Adam Tauman Kalai et al., Why Language Models Hallucinate, Nature, 2026。这里引用的是论文对语言模型幻觉、预训练目标和评测激励的分析。 ↩︎ ↩︎

  2. OpenAI, Why language models hallucinate。这里引用的是 OpenAI 对幻觉成因和 accuracy-only 评测激励的解释。 ↩︎

  3. Stephanie Lin, Jacob Hilton, Owain Evans, TruthfulQA: Measuring How Models Mimic Human Falsehoods。这里引用它来支撑“模型可能复述训练语料中的常见误解，规模本身不保证 truthfulness”的判断。 ↩︎

  4. Patrick Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks。这里引用 RAG 的原始问题定位：把参数化模型与外部非参数记忆结合，以支持知识密集任务。 ↩︎

  5. Ragas 文档，Available Metrics。这里引用 context precision、context recall、faithfulness 等指标，说明 RAG 需要同时评估检索上下文和生成忠实度。 ↩︎

  6. Alex Min et al., FActScore: Fine-grained Atomic Evaluation of Factual Precision in Long Form Text Generation。这里引用的是把长答案拆成原子事实进行评估的思路。 ↩︎

  7. Google Research, Long-form factuality in large language models。这里引用 SAFE 使用搜索增强方式评估长文本事实性的思路。 ↩︎