Why Do LLMs Lie?

为什么大语言模型会撒谎？ - ByteByteGo 电子报

为什么大语言模型会撒谎？

ByteByteGo

2026年9月29日

在不同环境中调试代理 - 实时研讨会（赞助）

你的代理返回了奇怪的结果。是提示词的问题？某个工具调用超时了？还是代码无法解析响应？没有追踪信息，你只能猜测。

在本次实践研讨会中，Sentry 的 Serge 将使用 Sentry Agent Tracing 为三个代理添加追踪功能：电商商店中的聊天机器人、自定义 Slack 代理，以及用于审查 PR 的 GitHub Action。你将学习如何捕获错误的工具调用和意外输出，以及如何跟踪所有代理运行过程中的令牌消耗和性能表现。

立即预留席位

一位客户询问公司新推出的基于 AI 的客服助手，15 天前购买的订阅是否符合退款条件。假设助手立即回应，解释公司提供 30 天的退款窗口，描述取消流程，并承诺款项将在 5 个工作日内到账。所有内容听起来都十分有帮助、自信且完整。

但问题只有一个。

实际上，公司仅允许 14 天内退款。此外，也没有关于 5 天处理时间的承诺。助手实际上从一个看似合理的政策中拼凑信息，并凭空捏造了虚假承诺。换句话说，它撒了谎。客户现在期待着公司从未提供的服务。

尽管这个例子听起来像是虚构的，但它展示了使用 LLM 构建的应用程序中最重要问题之一。虽然 LLM 可以生成优秀的语言，但它们可能会完全错误地理解底层信息。

在本文中，我们将探讨为什么 LLM 会出现这种幻觉现象，以及可以帮助提高 LLM 回答可靠性的技术。以下是本文内容：

• 幻觉在 LLM 中的实际含义
• 回答出错的三种方式
• 预测文本如何产生虚构事实
• 为什么模型难以承认不确定性
• 通过 RAG 为模型提供证据
• 使用工具查找缺失的事实
• 编写有用的回答
• 为什么解释不等于证明
• 在回答到达用户之前进行检查

幻觉的实际含义

在 LLM 的上下文中，幻觉是指生成的信息在事实层面错误、虚构或与模型应使用的材料不一致。以下是幻觉是如何发生的：

整个回答可能并不错误。事实上，一个有用的解释可能只包含一个捏造的日期、未经支持的承诺，或对不存在文档的引用。这个小细节可能是读者所依赖的部分。

我们不能直接将这种行为称为撒谎，但其与撒谎非常接近。回答看起来像是自信的虚假信息。然而，撒谎通常意味着有欺骗的意图。幻觉并不表明这种意图。模型可能通过其正常的生成过程产生错误答案。在前面的客服示例中，立即出现的问题是应用程序将错误生成的政策呈现为已确立的公司信息。

上下文在这里非常重要。为虚构公司发明退款政策在任务要求时是合适的。但将同样的虚构内容作为实际企业的政策呈现，则是事实性失败。最终，差异更多在于回答声称代表的内容。

AI 支持助手的错误可分为三个有用的类别，这有助于我们更清晰地分析问题：

• 事实性幻觉与现实相矛盾。例如，当公司实际的退款窗口是14天，但助手错误地声称是30天时，就属于此类错误。公司确实存在，且有明确的政策，但助手的描述不正确。

• 忠实性幻觉涉及回答与其提供的证据之间的关系。例如，如果应用程序提供的政策要求未使用账户，但助手却声称使用情况无关紧要，这就与原始证据相矛盾。

• 虚构指的是编造内容，例如虚构政策条款、确认号码或研究论文。

这三个类别之间存在重叠。

一个虚构的政策条款可能既与事实不符，也未在提供的文件中找到支持。我们也可以将事实性和忠实性视为两个更广泛的类别，其中虚构属于事实性错误的范畴。主要区别在于：检查回答是否与现实一致，还是检查回答是否与提供的证据一致。

这种区别揭示了一个有趣的情况：AI 助手可以忠实地总结一份过时的文件，但仍可能对当前政策给出错误的回答。要修正这种回答，我们需要同时关注模型本身和作为信息来源的数据。

构建并扩展成功的 AI 代理策略（赞助内容）

将代理部署到生产环境只是简单的一步。保持其可靠性、可控性，并随时间推移持续改进，才是大多数企业级 AI 项目遇到瓶颈的地方。

顶级团队是如何做到的？他们采用了一种代理运营模型（Agentic Operating Model, AOM），这是一个逐步框架，用于对齐人员、流程和技术，使企业级代理在扩展过程中持续改进。

在 LangChain 最新指南中，你将学习到：

• 为什么 AI 代理不会像传统软件那样崩溃
• 覆盖代理整个生命周期的工程架构
• 从“构建和部署”转向“运营和持续改进”

了解更多

文本预测如何产生幻觉

为了清晰理解其机制，让我们看看 LLM（大语言模型）是如何生成特定回答的。

如你所知，LLM 以称为token的小单位处理文本。一个 token 可以是一个词、词的一部分或标点符号。对于给定的输入和当前生成的回答，模型会计算可能的下一个 token 的概率。生成方法会选择一个 token，将其添加到回答中，然后重复整个过程。根据设置，选择可能基于最可能的 token，或从可能的续写中进行采样。

一个可能的续写并不等同于经过验证的陈述。用于选择下一个 token 的概率仅涉及文本生成，它并不能证明整个回答的正确性。同样，“肯定”“无疑”等词是生成的语言，它们的出现并不能证明模型已检查过政策或拥有可靠证据。

模型在训练过程中学习这些模式。

在初始阶段，称为预训练的阶段，模型会处理大量文本并学习预测续写。其内部的数值设置（称为参数或权重）会逐渐捕捉到涉及语法、概念、关系和事实的模式。这产生了有用的知识，并使其能够处理各种不同的语言任务。

然而，对某一主题的熟悉程度无法确定其所有具体事实。模型可能会遇到数千条退款政策，其中提到14天、30天、未使用的账户和处理延迟等信息。这些例子能帮助它以适当的方式讨论退款问题，但它们无法说明当前这家公司在当前客户身上适用的具体条件。

类似的情况也出现在虚构的引用中。模型学习到研究引用的格式，包括作者姓名、出版年份和技术标题。即使没有真实的参考文献支持，它也能复现这种结构。

为什么模型难以承认不确定性

大型语言模型（LLMs）主要被优化为生成合理的文本。它们会接受额外训练以提高准确性、有用性和对不确定性的响应能力。然而，流畅的续写并不能证明模型生成的每个陈述都是正确的。

某些训练激励机制也可能鼓励猜测。例如，考虑一种评估方法：正确回答得一分，错误回答和承认不确定性同样得一分。在这种机制下，猜测有机会获得分数，而放弃猜测则得不到任何分数。这种激励方式会训练模型倾向于猜测，从而导致幻觉。

不过，说幻觉是不可避免的并不完全正确，因为它们并非模型架构的固有属性。模型可以识别部分不确定性并检测部分错误。在特定条件下，模型具备有用的自我评估能力，但当这些能力需要推广到不熟悉的任务时，也会存在局限性。然而，并没有可靠的内部机制能明确区分每个正确答案和每个猜测。

要求模型提供置信度百分比也无法自动解决这个问题。例如，声称95%置信度的回复需要证明这种评分对任务本身有意义。校准（calibration）衡量的是置信度估计值与大量案例中实际准确率的匹配程度。如果没有这种评估，一个令人印象深刻的百分比可能会为本就充满不确定性的答案增添另一个模糊的细节。

通过RAG为模型提供证据

第一个主要防御机制直接解决了信息缺失问题。

检索增强生成（RAG）会找到相关材料，并在生成前将其添加到模型的输入中。检索获取信息，增强补充内容，生成产生答案。

在我们的示例支持应用中，退款问题会触发对已批准公司文档的搜索。应用会检索描述适用政策的段落，并将其与问题一并添加。现在，助手在撰写回复时可以访问公司实际的条件。

这改变了有用且有效的答案的定义。例如，检索到的政策明确指出，退款必须在购买后的14天内完成，且账户必须未使用。客户的查询只建立了购买时间。助手应意识到还有一个条件尚未解决。

RAG仍然存在失效点。搜索可能返回过时的政策、选择错误产品的政策或遗漏例外情况。模型也可能误解正确的段落或添加未经支持的承诺。

对于该应用，文档需要明确的产品名称、生效日期和审批状态。需要明确处理冲突的政策，以便模型能够确定适用的是哪一项。

文档准备还包括将相关条件放在一起。假设退款期限出现在某段文字的末尾，而未使用账户的要求则出现在下一段的开头。仅检索第一段文字可能导致助理获得不完整的规则。定期检查模型实际接收到的内容，有助于区分检索问题与未能解释完整证据的故障。

使用工具查找缺失的事实

文档解释一般规则，但基于LLM的助理还需要关于个别客户的具体事实。这正是工具使用变得非常重要的地方。

工具可以让应用获取模型范围之外的信息或执行定义的操作。例如包括搜索网络、检索账户记录和运行计算。与外部信息源的交互可以减少评估任务中的错误。

API为一个程序请求另一个程序的信息或操作提供了定义方式。支持应用可能提供一个账户查询API，返回购买日期和订阅是否已被使用。模型发起查询请求，应用执行该请求，返回的结果可用于生成正确的答案。

RAG和工具使用可能会重叠，因为文档检索本身可以作为工具暴露出来。在此示例中，它们提供了互补的证据。政策说明了条件，而账户查询则提供了应用这些条件所需的客户事实。

重要的是查找操作必须真正发生。生成一句“已检查账户”的话并不能证明任何事情。如果工具失败，这种失败必须对应用可见。假设账户未使用只会在此处引入幻觉。

资格和支付也是独立的事实。即使确认客户符合条件，助理在支付系统报告成功之前也不能如实说明退款已发出。生成一个虚构的确认号并不能创建交易。在描述该操作完成之前，应用需要实际操作及其结果。

编写有用的答案

对抗幻觉的另一种方法是将证据不足视为有效结果。

明确的指令可以告诉助理识别缺失信息并避免不支持的结论。在适当的情况下，可以通过限制答案仅限于提供的材料来消除不确定性，并将主张建立在支持段落的基础上。这些措施可以减少幻觉，但无法完全消除它们。

无论如何，这样做比单纯承认无知更有帮助。在我们的示例中，助理可以解释购买在14天窗口内，但账户使用情况仍需检查。这保留了已建立的信息，并确定了完整答案的精确障碍。

软件还需要一种方式来表示这一结果。要求每个响应都包含“符合条件”或“不符合条件”会没有空间容纳缺失证据。像“需要审核”这样的第三种状态允许不确定性影响应用的下一步操作。

为何解释不等于证明

另一种提出的防御方法是思维链提示（chain-of-thought prompting），它要求模型通过中间步骤逐步解决问题。

将任务分解为更小的部分可以提升某些答案的质量，并使错误更容易被发现。然而，生成的解释可能包含错误的前提，或未能准确描述影响结果的因素。

例如，假设助手解释称客户15天前购买了商品，退款窗口期为30天，因此客户符合退款条件。这个论证逻辑清晰，但依赖于错误的政策。更多的解释内容无法补充缺失的事实。

更有效的应用方式是要求提供与可验证证据相关的简洁理由。助手应明确识别政策条款、相关账户信息以及条件如何适用。这为审查者提供了具体的可核查主张，而非将解释本身视为证据。

在答案到达客户前进行验证

将验证作为独立的工作流程环节，可以有效减少幻觉现象。这是因为起草答案、生成验证问题以及独立回答这些问题的流程，降低了评估任务中的幻觉率。这种方式支持结构化检查，同时保留检查者也可能犯错的可能性。

以客服助手为例，句子"客户符合退款条件，退款将在5天内到账"包含多个独立主张。资格认定需要政策和账户事实作为依据。处理时间需要独立的证据支持。如果没有任何内容能证明5天的承诺，这个承诺就应被删除。

引用资料可以简化这些检查，前提是引用本身也需要被验证。文档必须真实存在、适用于问题，并支持附加的特定声明。系统可以通过检索到的文档标识符构建链接，并检查引用内容是否确实出现在这些文档中。仅仅在未经证实的主张旁边放置真实链接，仍无法构成可靠答案。

一些更简单的技术方案也存在，但它们的适用范围更有限。

降低温度参数通常会使token采样更集中于可能的续写内容，但这并不能确保事实准确性。助手可能在重复错误政策时表现得更一致。要求特定输出格式也有助于软件处理响应，但这并不能证明内容本身的正确性。

对于明确的规则，普通应用代码可以执行部分决策。如果政策有明确的条件定义，代码可以将验证后的购买日期和使用状态与这些条件进行比对。模型随后可以解释结果。然而，例外情况和模糊的政策表述仍需要显式处理。

结论

减少幻觉的改进支持工作流程可以看作是一个清晰的序列过程。

它首先检索适用政策，获取必要的账户事实，检查条件并准备解释。然后验证解释中的事实主张和引用来源。如果发现信息缺失，将生成特定的未解决状态。最后，需要判断的案例将被转交给进一步审查。

此类设置的可靠性必须通过现实案例进行衡量。测试用例应包含符合条件的购买、已使用的账户、缺失的记录、过时的政策以及包含错误假设的问题。当客户询问如何申请“保证30天退款”时，助手不应在未核实的情况下直接接受该保证。

评估还需要考虑实用性。一个总是给出回答的助手可能会做出缺乏依据的声明，而一个总是拒绝回答的助手则几乎没有价值。我们需要衡量提供的答案是否准确且有依据，未解答的案例是否得到适当处理，以及可解答的问题是否被不必要的拒绝。

回到最初的客户场景，基于LLM的助手现在可以解释哪些条件已满足、哪些问题尚未解决，以及哪些证据支持其回答。当信息缺失时，回答的措辞可能显得不够自信，但答案的实用性却得到了提升。开发者的责任是构建一个流程，使证据能够决定应用程序以负责任的方式可以主张哪些内容。