为什么 AI 会令人信服地出错

夸张一点说，语言模型完全可以非常有说服力地解释为什么 1 + 1 = 3。它可以构建一条整洁的论证链，写出中间步骤，并用几乎像教科书一样笃定的语气给出结果。

在这个例子里，风险还不算大。我们知道正确答案，因此很快就能识别错误。

真正更值得关注的是另一种情况：我们自己并没有足够的专业知识去验证其中的前提。一条关于罕见 Framework API 的错误说法，看起来可能像一段完全正确的技术解释；一条关于事务边界的错误判断，对于没有分布式系统经验的人，也可能显得完全合理；在安全相关的问题里，一个错误前提甚至可能只有真正研究过这类系统的人才能看出来。

因此，关键问题并不是我们能不能识别明显的胡说八道。

真正的问题是：如果人类自己都不知道刚才那句 1 + 1 = 3 是错的，会怎样？

日常语言里，人们很容易直接说 AI “在撒谎”。这种说法作为修辞可以成立，但从技术上看并不准确。撒谎通常意味着说话者知道某个陈述是错的，却仍然带着欺骗意图把它说出来。我们不应该轻易把这种意图投射到 Large Language Model 身上。

更准确的表述是：

模型可能会令人信服地出错。

而这正是本文想强调的一点：

Plausibility 并不是判断真假的标准。

最危险的 Hallucination 看起来并不危险

明显的胡说八道相对容易处理。如果 Agent 调用了一个在语法上根本不可能存在的方法，Compiler 可以直接反驳。如果生成的测试甚至无法编译，我们会立刻得到反馈。如果模型声称柏林位于法国，大多数人也不需要额外工具就会产生怀疑。

真正困难的是那些能够无缝嵌入现有知识的错误。

一个回答可以在术语上完全像回事，可以使用熟悉的 Pattern，可以结构清晰，也可以给出很合理的理由。甚至可能十句话里有九句都正确。只有第十句——而且恰好是后续方案所依赖的那一句——是错的。

这并不会让问题变得更轻。恰恰相反。

最危险的 Hallucination，是那种只有具备领域知识的人才能识别其错误的 Hallucination。

人很容易把语言上的笃定，当作事实上的笃定。但面对 LLM，这两层不能简单等同。优雅的解释，首先只是优雅的解释。逻辑结构并不能证明它的前提是真的。看起来专业的代码块，也不能证明里面使用的 API 真的存在。

乍看之下，这似乎只是某些模型的质量问题。但这个机制更深，它从语言模型最基本的文本生成方式开始。

为什么会产生 Hallucination？

如今，Hallucination 这个词的使用范围已经很宽。它有时指捏造的事实，有时泛指所有错误答案，偶尔甚至被用来描述 Agent 做出的任何不符合预期的决策。

如果要进行技术讨论，范围收窄一些会更有帮助。并非所有错误都有相同的成因。

语言模型不是真值登记簿

Large Language Model 并没有一个简单的内部数据库，其结构如下：

陈述
↓
真 / 假

在预训练阶段，模型首先从海量文本中学习统计结构和关系。简化来说，它学习的是：在给定条件下，哪些后续内容更可能出现。训练数据中的每一句话，并不会都附带一个明确标记，说明“这是真的”或“这是假的”。

OpenAI 在 2025 年发布的一篇分析中，正是从这个角度解释了部分 Hallucination 问题：可预测的语言结构可以通过大量样本得到很好学习，而罕见或高度任意的事实未必会形成足够稳定的模式，让模型可靠地还原其具体内容。此外，如果错误作答的代价低于选择不答，常见的评测方式还可能让猜测比承认不确定更有吸引力。

这并不意味着 LLM 只是在随机猜事实。现代模型拥有海量可用知识，也能以惊人的精度复述许多关联。关键在于另一点：当某处缺少可靠信息时，模型生成貌似合理文本的能力并不会随之自动消失。

知识缺口在输出中未必看起来像知识缺口。

因此，模型可以对某个主题了解很多，却没有充分表征恰好对当前任务至关重要的那条信息。

缺失或过时的信息

知识快速老化时，这个问题尤其明显。

Framework 会增加新 API，Library 会改变行为，标准会持续演进，云服务会替换产品，企业内部系统则根本不会出现在公开训练数据中。

例如，模型可能知道 Angular 组件如何组织、Dependency Injection 如何工作、RxJS 与 Change Detection 分别扮演什么角色，以及多年来常见的 Coding Pattern。即便如此，它对刚发布的 API 仍可能了解不完整。

此时会出现一种很微妙的情况：模型拥有足够的 Context，可以生成一段看起来像 Angular 的答案；它也可能掌握了足够的信息，能正确使用新 API 的名称和基本思路；但它对细节的理解还不足以把各部分在技术上正确地组合起来。

结果可能在语法上很有说服力、在概念上也看似合理，却根本无法工作。

冷门 Library、专有 API、专业领域知识或非常新的标准，同样可能出现这种情况。

知道得很多，并不能避免在决定成败的那个点上知道得太少。

错误或不完整的 Context

并非每个错误答案都源于模型自身的知识缺口。

Agent 即便使用能力很强的模型，也可能依据质量很差的证据工作。

Repository Search 也许找到了过时的实现；旧文档页面也许描述的是已经被替代的概念；关键 Requirements 也许缺失；两份 Agent File 也许互相矛盾；Tool 也许返回了一个被 Agent 错误解读的报错；Memory 中也许记录了一项对当前系统版本已经不再成立的决策。

在这些情况下，一概称之为 Hallucination 并不精确。

相关信息甚至可能已经存在于 Context 中，却被错误地赋予权重、错误地组合，或者被排在相关性较低的证据之后。

这更接近于对现有证据的错误解读。

这种区分具有实际意义。面对缺失知识，最新文档或 Search 可能有效；面对劣质证据，增加更多 Context 却不一定有用。再多的过时文档，也不会让错误结论变得正确。

错误结论

还有第三种情况。

模型可能正确掌握了相关事实，却仍然得出错误结论。

例如，模型可能正确识别出两处事务，但由此推导出的原子性判断仍然是错的；两个 API 可以分别描述正确，但在当前生命周期情境中组合使用却无效；某个 Security Mechanism 可以解释得完全正确，却被用在了错误的 Trust Boundary 上。

因此，我们至少应该区分四类错误：

• 缺失或过时的知识，
• 确实被捏造或缺乏依据的信息，
• 对现有证据的错误解读，
• Reasoning 或推导中的错误。

在实践中，这些类别可能彼此重叠。但在验证时，我们面对的是哪一类问题，仍然会带来不同的处理方式。

知识缺口与语言上的不确定，并不是一回事

人类同样没有完美的自我校准能力。我们会高估自己的知识、记错事情，也会用超出实际证据强度的语气回答问题。

但语言模型还多了一层困难：我们无法根据答案的语气，可靠地判断其底层证据到底有多强。

模型并不会自动拥有一块完美的内部状态面板：

我确定知道
我知道一部分
我不知道

确实有研究表明，模型可能掌握关于自身答案正确概率的信息。Anthropic 早在 2022 年就研究过模型能否估计自己陈述正确的概率。结果显示，在合适的任务和格式下，模型可以实现颇有用的校准，但迁移到新任务时也存在问题。

这是一个重要区别：“模型永远无法评估自己的不确定性”和“模型用语言表达的信心天然就校准良好”，这两种说法同样错误。

因此，较新的研究会明确考察“很可能”“我不确定”或极度自信的措辞，是否真的与模型内部的不确定性相匹配。2025 年的 EMNLP 论文 MetaFaith 表明，对论文所研究的模型和方法而言，如果不采取针对性措施，这种语言层面的校准依然可能明显不可靠。

对 LLM 而言，知识缺口和语言上的不确定并不是一回事。

正因如此，Abstention——也就是在证据不足时不做出具体断言——已经成为一个独立的优化目标。

OpenAI 的 SimpleQA 提供了一个有意思的例子。在一项评估中，不使用 Web 的 gpt-5-thinking-mini 达到 22% 的 Accuracy，Hallucination Rate 为 26%。o4-mini 的 Accuracy 十分接近，为 24%，但 Hallucination Rate 达到 75%。关键差异在于，较新的模型更经常放弃给出具体答案：Abstention Rate 为 52%，而后者只有 1%。这些数字并不说明某个模型普遍具有某种固定的 Hallucination Rate。SimpleQA 是一个专门设计得很困难的短事实问答 Benchmark。但它很好地说明了：回答更多和回答得更好并不是同一个目标。

2023 与今天，已经不是同一个世界

长期使用 LLM、从 ChatGPT 早期一路走来的人，很容易犯两种方向相反的错误。

第一种，是把 2023 年的使用经验原封不动地套到今天的模型上。第二种，是把模型的巨大进步误认为问题已经彻底解决。

这两种判断都无法准确描述实际发展。

早期 Factuality Benchmark 很好地解释了，为什么 Hallucination 当时会如此迅速地成为核心话题。例如，在 2023 年发布的 HaluEval Benchmark 中，作者报告称，在其特定测试类别所考察的用户问题里，ChatGPT 大约有 19.5% 的回答生成了无法验证的信息。这不是 2023 年 ChatGPT 的通用 Hallucination Rate，只是该 Benchmark 方法下的结果。

同年，FActScore 研究的是完全不同的问题：它把较长的生成式人物传记拆分成原子事实，再检查其中有多少比例能够得到可靠来源支持。作者在人工评估中报告，ChatGPT 的 FActScore 为 58%。这个数字同样只描述这项具体任务，不能与 HaluEval 的 19.5% 合并计算，也不能直接比较。

更早的 TruthfulQA 已经展示过，即便看似简单的事实性也很难做到：在最初的 Benchmark 中，表现最好的被测模型有 58% 的回答符合事实，人类则为 94%。不过，TruthfulQA 于 2021 年就已提出，测试的是较早的模型世代，并且有意选择了容易受普遍误解影响的问题。因此，这些数字更适合作为历史背景，而不是评估当前系统的比较值。

另一方面，较新的测量呈现出不同的质量级别。

GPT-5 System Card 使用 LongFact 和 FActScore 的开放式事实问题，在启用与不启用 Browsing 的情况下进行了评估。启用 Browsing 后，gpt-5-thinking 在其 claim-level 指标上的 Hallucination Rate 分别为：LongFact Concepts 0.7%、LongFact Objects 0.8%、FActScore 1.0%。OpenAI o3 在同一评估中的数值为 4.5%、5.1% 和 5.7%。不启用 Browsing 时，gpt-5-thinking 的 FActScore 数值升至 3.7%。这些数字只适用于 OpenAI 的具体评估和 Grading Pipeline，却同时展示了两点：更好的模型可以显著减少错误，而 Search 等外部证据还能进一步提高事实准确性。

此后发展仍在继续。在 GPT-5.6 的 August Update 中，OpenAI 针对三组有意挑选的高难度 Factuality 数据——偏重事实性的生产 Prompt、此前由用户标记的错误案例，以及医疗、法律和金融领域的 High-Stakes Prompt——报告了相较 GPT-5.5 Instant 的进一步明显提升。对 GPT-5.6 Sol 而言，三组数据上的事实错误率大约降低了 60%。OpenAI 特别强调，这些 Benchmark 专门选择了困难且容易诱发 Hallucination 的案例，并不代表普通 ChatGPT 流量中的平均错误率。

Anthropic 从另一种评估路径得出了类似图景。Claude Opus 4.8 System Card 考察了多个 Closed-Book Factuality Benchmark，模型不得使用 Web Search 或其他 Tool。在参与比较的六个模型中，Opus 4.8 在四个 Benchmark 上的 Incorrect Rate 都最低。进步的重要来源不仅是更多正确答案，也包括在不确定时更频繁地 Abstain。不过在 Net Score（Correct 减去 Incorrect）上，与 Opus 4.7 的差异并不具有统计显著性。Anthropic 同时强调，在没有外部 Tool 的情况下，Factual Hallucination 仍不能被视为已经解决。

这些 Benchmark 测量的内容各不相同，绝对数值无法直接比较。把它们画成一条所谓全局“AI Hallucination Rate”曲线，在方法论上是错误的。

但它们共同展示了一个方向。

现代模型的事实准确性显著优于早期 Chat Model，但更好并不等于已经解决。

我在 LLM 早期使用阶段的 Angular 经验

我对这种变化的感受，非常直接地来自实践。

模型整体上对 Angular 的了解其实相当出色。组件、Service、Dependency Injection、RxJS、传统的 Change Detection Pattern——即便当时的模型，在这些领域也已经能够生成很有帮助的代码。

随后 Signals 出现了。

Angular 16 在 2023 年首次以 Developer Preview 的形式引入了基于 Signals 的新响应式模型。API 和围绕它形成的 Pattern 确实都非常新。

我当时的个人感受是，在 Angular 的最新状态上，模型有时明显落后于我正在实践中使用的内容。这不是科学测量，也不是说当时每一个模型都恰好“落后”了某个固定年数。

真正有意思的地方在于行为：模型对 Angular 知道得很多——只是恰好在决定性的那个点上知道得还不够。

我要求模型给出基于 Signals 的现代实现。模型知道这个术语，也理解我想要的方向，并把它与已有的 Angular 模式结合起来。结果看起来像 Angular 代码，甚至也看起来像 Signals 代码。但问题在于：其中某些 API 根本不是那样存在的，某些概念被混在一起了，某些来自 RxJS 时代的模式被硬套到了新 API 上，而那样从技术上根本无法工作。

正因为周围很多东西都正确，要识别错误，反而需要自己足够了解 Angular。

今天的体验已经完全不同。现在的模型了解更近的 Framework 版本。Agent 可以搜索 Repository Code、加载当前文档、查 API，再让实现经过 TypeScript、Angular Compiler 和测试。

底层机制并没有消失。但避免一个错误前提，或者在它扩散之前把它发现的机会，已经显著提高。

今天已经是另一种质量级别

现代 Coding Agent 不只是一个被塞进超长 Prompt 的语言模型。

根据系统不同，它可以把 Repository Search、文档、Web Search、Compiler、Type System、Test Runner、Linter、Eval 以及更多专用 Tool 纳入工作流程。因此，缺失或不确定的知识，如今更经常可以依据外部证据得到核验。

这显著改变了错误出现的情境。

假设模型不确定某个新 API 的 Signature。纯 Chat 可能只能依据参数化知识回答；Agent 则可以读取 package.json 中安装的版本，搜索 Type Definition，调取最新文档，生成实现，再让 Compiler 检查。

原本是：

我认为 API 应该这样工作

理想情况下，现在会变成：

假设
↓
文档
↓
Repository
↓
实现
↓
Compiler
↓
测试
↓
反馈

因此，如果仅凭早期 Chat Model 的 Hallucination 问题来评价现代 Coding Agent，会产生误导。

Tool 改变了整个系统。

LongFact 本身就是一个有意思的例子。与之配套的 SAFE 方法会把长答案拆成单个事实，再通过搜索查询对照外部证据逐项检查。这项工作展示的不只是一个新 Benchmark，也体现了一个基本模式：Generation 与 Verification 可以在技术上拆成不同步骤。

但这里仍有一项重要限制。

Tool 并不保证真相。Agent 可能选错文档，Search Result 可能已经过时，测试可能验证了错误的属性，Compiler 只确认类型正确，并不会自动确认业务语义正确；绿色 Build 也无法说明 Security Boundary 是否建模正确。

底层机制并未消失，但错误发生的概率和纠正错误的机会都发生了巨大变化。

为什么领域知识仍然有价值

这时经常会出现一个很奇怪的问题。

如果模型越来越能生成代码，我们为什么还需要有几十年经验的人？

这个问题把软件开发简化成了代码生产。

有经验的开发者，不只是“能更快敲出同一个方法的人”。恰恰在 Coding Agent 时代，另一种能力变得更明显：判断一个看起来合理的方案，是否真的适合这个问题和这个系统。

有经验的工程师可能会发现：某个 API 在这个 Framework 版本里根本不存在；所谓 Security Fix 实际上保护的是错误的 Trust Boundary；两个单独看都正确的数据库操作，合在一起并不构成原子操作；每个局部代码块看起来都没问题，但 Race Condition 仍然存在；新的 Dependency 违反了 Architecture Boundary；一个局部优雅的方案，长期来看却并不适合这个系统。

这些都不是打字速度的问题。

它们要求人拥有这个系统和业务领域的 Mental Model。

我对一个领域知道得越少，就越难区分“令人信服的 Hallucination”和“令人信服的正确答案”。

这并不意味着人必须自己能够从零生成所有答案。我不需要把某个 Library 的每个细节都背下来。但我需要足够的理解，知道哪些陈述是关键的，哪些假设必须被验证，以及什么 Tool 才能给出足够可靠的证据。

Expertise 之所以有价值，不是因为人生成得更快，而是因为它能带来更好的判断。

这并不是反对 Junior Developer 的论点

上述结论不应该被误读为“只有 Senior Developer 才应该使用 Coding Agent”。

经验毕竟不是靠把人隔离在困难任务之外建立起来的。

Coding Agent 甚至可以是非常好的学习工具。它可以解释陌生代码、展示替代方案、生成测试、回答追问，也可以讨论不同设计带来的后果。

真正的问题，是 Generation 完全替代了自己的思考过程。

如果一个人只是因为测试是绿色、代码看起来专业，就直接接受某个方案，那么他对“为什么这个方案成立”学到的东西会更少。如果这种理解长期没有建立起来，将来恰恰可能缺少识别“看起来合理但其实错误”的方案所需要的判断力。

所以，这里真正支持的是 Mentoring、Review 和有意识的学习，而不是反对 Junior Developer。经验不会一夜之间出现，它仍然需要被培养出来。

从 Chat 到 Agent：错误会变得可执行

到这里为止，我们还可以把 Hallucination 大体看成经典的 Chat 问题。

错误答案出现在文本里。人类读取它、验证它，或者拒绝它。

Coding Agent 改变了这个情境。

本系列第 5 篇文章把 Agent 的解题路径描述为一系列 Decision、Action、Observation 和不断变化的 Context。正因为这样，错误前提会获得新的性质。

错误假设
↓
看似合理的决策
↓
代码修改
↓
Repository 状态
↓
未来的 Context

假设一个 Agent 错误理解了一条 Architecture Rule。

它随后在两个 Module 之间建立了一条新的 Dependency。代码可以编译。测试仍然是绿色。这个改动甚至可能真的解决了当前 Ticket。

此时，错误假设已经不再只是文本。

它改变了 Repository。

下一个 Task 到来时，同一个 Agent 或另一个 Agent 会看到这条 Dependency。对它而言，这首先只是“已经存在的代码”——也就是系统似乎就是这样工作的 Local Evidence。

这正是一个局部偏差可能演变成长期影响的起点。

当然，不是每个错误假设都会走到这一步。Compiler、Type System、测试、Review、Architecture Rule，或者一个足够警觉的开发者，都可能立刻阻止它。

但如果没有被阻止，这次 Action 就会改变下一次 Decision 所处的 Context。

Broken Windows 与本地证据

Repository Code 对 Coding Agent 有一种特殊意义。

Agent 一开始并不知道每一行代码背后的历史。

它不会自动知道某个 Class 是四年前在时间压力下写出来的。它看不到某种奇怪访问方式只是因为当年的 Migration 必须分两步进行。它也未必知道某次 Review 里有人明确写过：“不要把这个当成 Pattern 复制。”

它最先看到的，只是代码。

于是，一次性的 Workaround 就可能变成 Local Evidence：

一次性 Workaround
↓
被 commit
↓
现有 Repository Code
↓
后来被解释成 Pattern
↓
再次被复制
↓
越来越像既定 Pattern

这个现象当然早在 AI 之前就存在。开发者几十年来一直会复制现有代码。Legacy System 往往正是因为一个局部决策被反复当成模板，才会非常“一致地朝错误方向生长”。

Agent 改变的主要是这个机制的速度和规模。

AI 并不是让糟糕架构第一次成为可能。它只是可能让糟糕架构更快地变得“一致”。

好消息是，同样的强化机制也可以朝正面方向工作。

如果一套 Codebase 拥有清晰边界、使用一致 Pattern、维护了好的 Example，并且让 Architecture Rule 能够被机械验证，那么 Agent 同样会把这些当作 Local Evidence。

于是形成：

好的 Pattern
↓
现有 Repository Code
↓
Local Evidence
↓
再次复制
↓
更高一致性

因此，Coding Agent 并不是天然会放大坏架构。它首先放大的，是 Repository、文档、测试和规则所呈现给它的本地信号。

真正值得问的架构问题越来越变成：我们到底在给它什么信号？

Hallucination、误解读与 Drift 并不是同一回事

到了这里，把三个相近但不同的概念区分开来会很有帮助。

本文所说的 Hallucination，指的是错误或缺乏依据的陈述与假设。例如，模型声称某个 API 存在，而它实际上并不存在。

误解读，指的是信息其实存在，只是被错误地加权或组合。文档明明存在，Agent 却把 Version 18 的规则套到 Version 21 上，或者把 Legacy Workaround 当成当前的 Architecture Rule。

Drift 则描述一个跨越多个步骤的过程：解题路径或逐渐形成的架构不断偏离最初希望的方向。

Hallucination 可以触发 Drift。

但不一定。

Hallucination
↓
Compiler Error
↓
修正

这里不会产生值得关注的 Drift。

反过来，Drift 甚至可以完全没有经典意义上的 Hallucination。

一个局部 Decision 本身可以是合理的。后来它被多次复制。于是 Codebase 的结构发生变化。其他修改开始继续沿着这条路走。一开始的 Exception 变成 Convention，却从来没人真正“捏造过一个错误事实”。

所以，Drift 与其说是一次模型错误，不如说是一种 Feedback Mechanism。

偏差如何逐渐演变成 Drift

一个简化后的过程可以这样表示：

偏差
↓
被接受
↓
成为代码库的一部分
↓
成为未来的 Context
↓
再次被复制
↓
新的本地惯例

关键在于反馈。

Agent 不只是根据 Context 生成 Output。它还通过自己的 Action，改变未来 Context 所要再次读取的环境。

Agent Decision
      ↓
Repository State
      ↓
Context
      ↓
Agent Decision

这并不是什么神秘的“AI Drift”。它更像是决策与被这些决策不断改写的环境之间形成的 Feedback Loop。

因此，早期偏差尤其值得关注。一条额外 Dependency 单独看也许没什么问题。但后面如果有十次修改都把它当成先例，它就可能慢慢变成一套新的结构。

第 5 篇文章已经说明，结果的 Variance 首先只意味着存在多条 Plausible 的解题路径。这本身还不是 Drift。但如果 Agent 在一个 Plausible 的错误假设上继续工作，并由此推导出更多决策，偏差就可能沿着一条更长的 Action Chain 不断被放大。这条链越长、越自主，明确的 Boundary、可检验的中间结果和 Feedback 就越重要。

安全相关的问题，需要的不仅仅是 Plausibility

普通的 UI Refactoring 里，一个错误假设很麻烦。

但在 Security-Critical 的决策里，“看起来合理”从根本上就不够。

一个对具体安全问题了解有限的 Agent，并不一定只能盲目回答。设计良好的 Agent System 可以加载更多文档、搜索内部 Policy、使用 Tool、验证具体事实、提出追问，或者在证据不足时拒绝行动并升级给人类。

真正关键的措辞是：一个设计良好的 Agent System 可以这样做。

这些是整个系统、Tool、Training Objective 和 Guardrail 的属性。它们不会因为“这里用了一个很强的 LLM”就自动出现。

就连 Abstention 也并不简单。系统不仅要找到信息，还要识别：现有 Evidence 什么时候已经不足以支持一个可靠答案。

所以，在高风险领域尤其需要明确一条原则：

对于安全关键决策，语言上的 Plausibility 绝不能成为唯一的质量证明。

我们需要 Evidence、技术检查，并在必要时需要合格的人类判断。

Generation 与 Verification 是两种不同的任务

Coding Agent 显著降低了额外 Generation 的成本。再生成一个实现变体、再补一个测试、再提出一个假设，今天往往比手工做同样的事情便宜得多。

这会改变工作重心。

问题不再只是：

我们怎样生成一个方案？

越来越多时候，问题变成：

我们怎样知道这个方案是可接受的？

Compiler 验证的是一类属性。Type System 验证另一类。测试只验证真正被 Specification 和实现覆盖到的东西。Architecture Test 可以约束 Dependency Rule。Security Scanner 能找到某些已知问题类型。Review 则把额外的领域知识带进来。

这些工具没有任何一个单独就是“Truth Machine”。

但组合起来，它们可以显著缩小“看起来合理、同时却是错误的”方案空间。

Generation 的成本可以下降，而 Verification 的重要性反而上升。

这个关系在本系列后面还会继续展开。此处只需要保留一个观察：如果一个系统可以非常快速地产生很多 Plausible Solution，那么我们区分它们的能力并不会因此变得没那么重要。

它会变得更重要。

仅有 Plausibility 并不够

Hallucination 是早期 LLM System 最显眼的弱点之一。但如果一路跟踪了 2023 之后的发展，也应该承认它在实践中的意义已经发生了多大变化。

模型的 Factuality 更强了。Abstention 被更明确地训练。Context 的使用更好。Search 和 Retrieval 提供更新的信息。Coding Agent 可以把 Compiler、Type System、测试作为外部 Feedback Channel。当前 System Card 也持续显示，相对各自前代模型，Factuality 还在继续改进。

我们完全可以对这种进步感到惊讶，同时又不把核心问题轻描淡写。模型可以知道很多，却仍然缺少那一个决定性的事实；一个答案可以写得极其漂亮，却仍然建立在脆弱证据之上；一个局部上看似合理的 Agent 决策，可以修改 Repository，变成后续决策的证据，并把原本孤立的、被接受的偏差慢慢发展成长期 Drift。

Plausibility 并不是判断真假的标准。

第 5 篇文章说明：Agent 的解题路径并不是 Deterministic 的。

第 6 篇再补上一句：

一个 Plausible 的解题路径，可能建立在错误假设之上。

解决办法不可能是预先规定 Agent 将要做出的每一个 Decision。那样的话，我们就不需要 Agent 了。

我们真正需要的是，更清楚地描述哪些 Solution 本身才算可接受，哪些属性绝不能被违反，以及什么信号能够让错误路径尽早显现。

下一篇文章就从这里开始。

第一道这样的边界，就是 Requirements。

---

来源与说明

OpenAI – Why Language Models Hallucinate，2025。 这项工作研究了 Hallucination 的统计成因，以及偏好猜测而非 Abstention 的评估机制会带来什么影响。它尤其有助于解释：为什么知识缺口不会自动在输出中表现为不确定。Why Language Models Hallucinate – OpenAI

Li 等 – HaluEval，EMNLP 2023。 HaluEval 研究 Hallucination 内容的生成和识别。本文提到的大约 19.5%，指的是该 Benchmark 内针对 ChatGPT 回答所做的特定研究，并不是通用的产品 Hallucination Rate。HaluEval – ACL Anthology

Min 等 – FActScore，EMNLP 2023。 FActScore 将长答案拆成原子事实，并衡量其中有多少比例得到可靠知识来源支持。本文提到的 ChatGPT 58%，来自对生成式人物传记的人工评估。FActScore – ACL Anthology

Lin、Hilton、Evans – TruthfulQA。 这个 Benchmark 专门研究容易因人类普遍误解而诱发错误回答的问题。其历史结果适合作为早期 Truthfulness 问题的背景，而不是评估当前模型的直接比较指标。TruthfulQA – OpenAI

Wei 等 – Long-form factuality in large language models / LongFact & SAFE，2024。 LongFact 衡量开放式长答案的事实准确性。SAFE 将答案拆成事实，再借助 Search 逐项检查。这项工作尤其有助于说明 Generation 与外部 Verification 可以彼此分离。Long-form factuality – Google DeepMind

OpenAI – GPT-5 System Card，2025。 文中提到的 LongFact、FActScore 和 SimpleQA 数值都来自该 System Card 的特定评估。OpenAI 使用了启用与不启用 Browsing 的不同设置，以及自己的 Grading 方法，因此这些数值不能被解释为通用 Hallucination Rate。GPT-5 System Card

OpenAI – GPT-5.6 August Update，2026。 该更新报告了专门针对高难度 Prompt Set 的 Factuality 评估，包括偏重事实性的生产 Prompt、此前由用户标记的错误案例，以及 High-Stakes 问题。其数值明确不代表生产环境中的平均错误率。GPT-5.6 August Update

Anthropic – Claude Opus 4.8 System Card，2026。 Anthropic 通过四个 Closed-Book Benchmark 等方式研究 Factual Hallucination，并分别考察 Correct、Incorrect 和 Abstention 行为。在参与比较的六个模型中，Opus 4.8 在四个 Benchmark 上的 Incorrect Rate 都最低；结果的重要组成部分，是模型在不确定时更频繁地 Abstain。Net Score 与 Opus 4.7 相比没有统计显著差异。Claude Opus 4.8 System Card，第 6.3.3.1 节

Kadavath 等 – Language Models (Mostly) Know What They Know，2022。 这项工作研究语言模型的自我评估和校准。结果表明，模型确实可能掌握关于自身答案正确概率的信息，但这种能力取决于任务格式，也无法完美泛化。Anthropic Research – Language Models (Mostly) Know What They Know

Liu 等 – MetaFaith，EMNLP 2025。 这项工作研究自然语言中的不确定性表述能否可靠反映模型实际的不确定性，并记录了被测模型中依然明显存在的校准问题。MetaFaith – ACL Anthology

Feng 等 – Don’t Hallucinate, Abstain，ACL 2024。 这项工作明确研究知识缺口，以及如何让模型在缺少知识时更倾向于选择不答。Don’t Hallucinate, Abstain – ACL Anthology