Every LLM Lies：大模型幻觉背后的工程应对之道

大模型会编造一个根本不存在的 API，还能自信地解释它为何有效，甚至给出一个看起来完全合理的调用示例。语法熟悉、语气笃定、附上引用——一切符合我们对“可信回答”的直觉，但答案本身可能是虚构的。这正是开发者面临的尴尬处境：一个答案看起来可用，和它值得信任，之间隔着巨大的鸿沟。

“说谎”是一种系统属性，而非模型道德问题

“Every LLM Lies”这个说法是刻意挑衅的。这里的“说谎”并非指模型主观上相信虚假信息并蓄意欺骗，而是一个操作性定义：系统在呈现可信信号的同时，输出了错误或缺乏依据的论断。对工程师而言，真正的问题不是模型有没有恶意，而是你的架构能否检测出输出何时是错的。

原文提出了一个值得记住的概念规则——House Principle：

一个诚实的系统，是虚假信息被检测成本足够低的系统。

这把注意力从模型的“表面真诚”转移到周边基础设施上：用户能否查看一项论断背后的证据？应用能否区分“生成的答案”和“已验证的结果”？错误输出能否在成为持久记录之前被纠正？一个系统不会仅仅因为模型少犯错就变得可信，它还必须让剩下的错误变得可见。

流畅性只是界面，不是保证

机器的“不真实”不是单一失败模式。助手可能凭空捏造事实，可能迎合用户表达的信念而调整回答，也可能给出一个并未忠实反映其真实生成过程的解释。这些失败需要不同的测试手段：事实性基准测不出过度顺从，有说服力的解释证明不了推理可靠，自信的语气更无法告诉你支撑证据是否存在。

连界面本身都值得审视。第一人称语言和“我检查过了”这类表述会影响用户对答案的解读。不过原文也提醒，这种语言会系统性诱导不合理信任的强假设，仍需实证检验而非假设。对产品设计来说，当下的教训更具体：不要让界面暗示一个系统并未执行的验证过程。“生成了答案”“检索到文档”“已验证断言”应当描述三种不同的状态。

最危险的时刻：输出变成证据

一次临时对话里的错误答案是一回事，错误答案进入文档、知识库、报告或未来的检索语料，则是另一回事。原文描述了一条值得警惕的链条：助手生成无依据的说法，有人把它复制进内部文档，另一份文档重复引用，检索系统把两份文档都找出来，后来的助手于是把这个被重复的说法当作“已获佐证”呈现。

系统并没有获得独立证据，它获得的只是副本。来源数量不等于证据多样性——五份继承了同一无依据断言的文档，并不等于五次独立观察。这里需要与“模型崩溃”区分开：递归合成训练导致的学习分布变化，和某条虚假陈述在信息生态中扩散，是两件不同的事。保留原始数据或许能缓解某些分布问题，但它本身并不能确立某条具体论断为真。

第二个模型不等于独立校验

问另一个模型是否有用？有用，但“一致”本身是极弱的验证定义。两个模型可能得出同一个错误答案，两条检索结果可能指向同一来源，两个代理可能重复工作流早期引入的假设。因此架构层面的问题不是“有多少系统同意”，而是：什么独立证据能证明它们是错的？

对于一个生成的 API 调用，证据可能是已安装的包及其真实接口；对于一段引文，证据可能是原始段落；对于一次计算，证据可能是独立执行的计算结果。验证器应该挑战论断，而不是复现它的风格。

模型崩溃（Model Collapse）是理解“虚假论断扩散”时需要区分的一个邻近概念。它最早由 Shumailov 等人在 2023 年的研究中系统描述：当生成模型被反复用自己（或同类模型）产生的数据训练时，会逐步丢失原始数据分布中的尾部信息，输出多样性收窄、偏差被放大，最终导致模型对真实世界的建模能力退化。其关键机制是递归训练造成的分布漂移，属于学习层面的问题。

与之相对，本文讨论的是单条无依据论断通过文档复制、检索引用在信息生态中扩散——这是内容层面的污染，即使模型本身没有退化也可能发生。两者的联系在于都可能造成“信息环境整体变差”，但干预手段不同：前者需要保留原始数据、控制合成数据比例；后者需要建立溯源谱系与独立验证。把两者混为一谈，会让人误以为“保留原始数据”就能解决虚假论断扩散，实际上它无法确立某条具体断言的正确性。

虚假论断会被锁死吗？

原文引用的一个探索性玩具模型考察了两个量：参考语料中机器传播的虚假论断占比，以及可用于检测和纠正它们的人力。模型追问反馈能否产生两种稳定结局——相对干净的信息环境和严重污染的环境。在大多数采样参数下并不能。只有当模型加入阈值型强化（广泛重复使虚假论断更难被检测）时，双稳态才出现在狭窄区间；在某一配置下，约 0.05% 的参数集呈现双稳态。

原文明确强调，这个数字不是对现实世界风险的估计，它只描述任意、未校准参数下的结果，而且阈值机制是在更简单形式几乎不产生双稳态之后才引入的，属于探索性发现而非确证性结论。真正有价值的是那个条件式问题：表面佐证是否可能强到，即使纠正单个输出也无法恢复信息环境？模型没有证明这在现实中发生，它指出了一个值得测试的机制。

**双稳态（bistability）**是动力系统中的概念，指同一组参数下系统存在两个稳定平衡点，最终落入哪一个取决于初始条件或历史路径。原文玩具模型追问的正是这一点：信息环境是否可能同时存在“相对干净”和“严重污染”两个稳定态，而一旦滑入污染态，仅靠纠正个别输出无法回到干净态。

这类现象常用阈值动力学描述：当虚假论断被广泛重复后，检测它需要付出的成本超过可投入的人力，于是纠正机制失效，污染得以自我维持。模型中加入的“阈值型强化”正是刻画这种边际效应。原文强调约 0.05% 参数集呈现双稳态，是在任意、未校准参数下的探索性结果，并非现实风险估计。它的价值在于指出一种机制——纠正能力被重复成本压垮——供后续实证检验，而不是给出一个可以引用的概率数字。

把原则落成工程要求

概念论证只有转化为明确的设计选择才有用。原文给出了几条可操作路径：

分离生成与验证。把生成输出视为候选结果，尽可能对照相关环境验证——执行测试、检查 schema、解析引用、与权威记录比对。一次成功的生成步骤不应悄悄变成一次成功的验证步骤。

保留证据谱系。存储足够溯源信息，区分原始来源与摘要、副本、模型生成的衍生内容。检索应帮助回答“这项论断源自何处”，而不只是“这段措辞出现在哪里”。

让不确定性可操作。泛泛的免责声明把全部工作丢给用户，更有用的状态应指明未解决之处：引用的文档未被检索到、引文未能定位、代码尚未执行、来源共享同一祖先、答案依赖未经检验的假设。这些不是产品失败的招认，而是关于验证边界的信息。

在错误变得持久的地方设置摩擦。不是每句生成内容都需要人工批准，但发布、持久知识库更新和后果重大的外部动作，理应比可逆草稿有更强的把关。关键边界往往就是答案变成他人日后当作证据的记录之处。

评估整个工作流。模型准确率只是一个测量维度，系统级评估还应追问：用户多大比例接受了错误输出？哪些错误在验证流程中存活下来？持久性错误被纠正的速度有多快？号称独立的来源多大比例共享同一祖先？这些指标才把模型行为与实际可靠性连接起来。

为纠错而建，而非为表面确定性而建

最强的 AI 产品未必是语气最自信、解释最冗长的那个，而是让自己的证据边界可供检视的那个。更好的模型依然重要，检索、评估、溯源、人类判断同样重要，但它们的价值取决于如何组合在一起。

审查一个 LLM 功能时，不妨只问一个架构问题：如果这个答案是错的，系统里有什么会注意到——然后会发生什么？