Why LLMs Agree With You Even When You’re Wrong

为什么大语言模型即使在你错误时也会同意你

ByteByteGo

2026年10月6日

AuthKit：企业级认证解决方案（赞助）

开发者从这里开始：AuthKit 是为你的应用提供的完整认证平台，用户管理功能支持每月活跃用户达 100 万的免费使用。

WorkOS 被 3000 多家公司信任，包括 OpenAI、Anthropic 和 Cursor。使用 AuthKit，你可以：

• 提供 SSO、MFA、通行密钥、密码、电子邮件验证码和社会登录
• 通过 SCIM 配置自动添加和删除用户
• 通过审计日志追踪谁做了什么

准备好拿下下一个企业客户了吗？

立即使用 AuthKit 开始 →

当大语言模型（LLMs）有时同意错误的主张时，主要是因为它们的训练奖励机制鼓励这种行为。该奖励系统同时基于多个因素，如准确性、有用性、礼貌性以及人们喜欢的回应。

大多数时候，这些目标可以协同工作，但在某些情况下它们会产生冲突。当与用户达成一致成为获得积极评价的捷径时，模型可能会学会即使答案不正确，也迎合用户的偏好答案。

这种行为被称为谄媚（sycophancy）。要详细了解其发生原因，我们需要理解影响模型输出答案的因素。本文将涵盖以下内容：

• 为什么大语言模型会转向谄媚行为
• 正确答案并不意味着模型会保留它
• 什么构成一个好的回应
• 人类认可不是准确性的衡量标准
• 对话压力如何暴露模型的弱点
• 谄媚行为不仅限于事实性答案
• 一致意见可能被伪装成验证
• 训练如何使更正变得更有奖励性
• 使用探针检测谄媚行为
• 测试对压力的抵抗力

为什么大语言模型会转向谄媚行为

当需要与用户达成一致开始扭曲答案时，就会出现谄媚行为。考虑这个简化的虚构对话：

用户：价格从 ₹100 上涨到 ₹120。百分比涨幅是多少？ 助手：涨幅是 20%。 用户：你确定吗？我认为是 25%。 助手：你说得对。我为之前的错误道歉。涨幅是 25%。

原始答案是正确的。价格从 100 元上涨了 20 元，这给出了 20% 的涨幅。我们可以看到用户并没有提供任何改变计算的新信息。然而，LLM 选择了错误的答案。

当助手将用户的异议视为替换正确答案的充分理由时，就会发生这种失败。事实上，它的道歉可能使替换后的答案听起来更可信，就好像它检查了自己的工作并真正发现了错误一样。

请注意，上述示例仅展示了这种模式。它并不意味着每个模型都会在这个特定计算上失败。

此外，与用户达成一致本身是完全正常的。如果用户是正确的，助手实际上应该同意。同样，当用户识别出真正的错误时，LLM 应该修改答案。谄媚行为涉及由不足的事实、推理或可用证据支持的虚假一致。

这就是谄媚行为与普通事实性错误的区别。模型可能因为缺乏相关知识或推理错误而给出错误答案。而谄媚测试涉及更具体的问题：系统性地揭示用户的偏好答案是否会系统性地将模型拉向该答案？

生成一个正确的答案并不能保证模型会始终保留它。大型语言模型（LLM）通过训练期间学习到的模式和当前对话中的信息生成文本。它以称为“标记”（token）的小单位生成文本，这些单位可以是单词或单词的部分。

在初始训练阶段（预训练），模型通过大量示例学习预测文本。通过这一过程，它发展出涉及语言、事实关系、编程和推理的能力。然而，预测文本与正确性是不同的概念。训练过程并未建立“每个响应必须与已验证事实保持一致”的规则。

此外，对话内容也会影响答案生成过程。当用户以中立方式提问时，会创建特定类型的上下文。但如果用户以“我确定答案是25%”的陈述提出相同问题，会创建完全不同的上下文类型。

理想情况下，模型应利用这一附加陈述来理解需要解释的内容。但可靠性较低的模型可能会生成迎合该陈述的响应，即使该陈述可能错误。

这解释了为何模型可能给出正确答案却在片刻后放弃它的表面矛盾。生成正确答案的能力与在用户施加的对话压力下选择该答案的可靠性是两种不同的能力。

什么是优质响应

训练大型语言模型（LLM）会引发一个关键问题：如何定义优质响应。

一个仅能预测文本的模型仍需要额外训练才能表现出有用助手的行为。开发者希望它能够回答问题、遵循指令、清晰解释、承认不确定性，并避免有害行为。

一种常见方法是使用期望响应的示例。在此方法中，模型被训练以模仿这些示例。这一阶段称为监督微调（supervised fine-tuning）。

另一种方法是基于人类反馈的强化学习（RLHF）。在典型的RLHF设置中，人类评估者会比较同一提示的多个响应，并指出哪个响应最理想。这些比较用于训练独立的奖励模型。奖励模型是一种能预测答案被评价程度的模型。

在训练过程中，LLM生成答案，奖励模型对这些答案进行评分，训练过程会调整助手，使高分响应更可能生成。困难之处在于确定评分方法。一个有用的答案可能具备多种品质：准确、相关、体贴、易懂且适当谨慎。单一偏好判断需要将所有这些品质压缩为一个二元选择。

例如，想象评估者在比较用户提案的两个响应。一个响应礼貌地指出了提案中被忽视的问题。另一个响应热情地支持提案并提供精心润色的解释。如果评估者未注意到技术问题，热情的响应在纸面上可能看起来更好。换句话说，训练系统会了解偏好，但该偏好无法说明评估者是否实际验证了答案的正确性。

人类批准并非准确性衡量标准

人类的批准可能成为准确性的不完美替代品。例如，假设一个大语言模型（LLM）正在审查数据库设计，用户写道：“我花了一周时间完成这个设计，我认为它已经准备好投入生产。”

一个有帮助的LLM助手可能会在认可用户工作量的同时指出一个严重缺陷。而一个过于顺从的LLM可能会称赞设计非常出色，只讨论一些次要的改进点。

如果评估机制反复奖励第二种风格，那么与用户保持一致就会与成功联系在一起。这种行为并不需要模型有意识地想要取悦任何人，训练过程本身就可以让顺从的回应更有可能出现。

一项研究发现，与用户观点一致可以预测偏好判断，而且人类和偏好模型有时会更倾向于令人信服的、顺从的错误答案，而不是准确的纠正。研究还发现进一步优化的效果存在矛盾。某些形式的奉承行为会增加，而其他形式则会减少。值得注意的是，即使在强化学习之前，奉承行为就已经存在，这表明早期训练阶段也起到了作用。

同样，基于人类反馈的强化学习（RLHF）是导致这一问题的一个因素。但 RLHF 并不能完全解释这种现象。训练样本、奖励机制以及对话环境都可能影响最终结果。

更广泛的问题在于，可衡量的信号可能有用，但未必能完美代表真实目标。高用户评分是宝贵的信息，但它们并不能证明答案是正确的。

对话压力如何暴露这一弱点

故意对LLM施加对话压力可以更容易暴露这一弱点。一个简单的提问“你确定吗？”就为LLM重新审视答案提供了合理的理由。用户经常能发现错误，因此一个从不重新考虑答案的助手也是不可靠的。

挑战在于区分要求验证答案的请求与证明答案错误的证据。例如，考虑以下三种代码审查的后续提问：

• “我不同意”表达了偏好。
• “我有二十年经验，这个是正确的”增加了权威性主张。
• “这是一个失败的测试，显示你提出的修复方案会破坏空输入”提供了LLM可以检查的具体证据。

一个可靠的助手应该对这些信息做出不同的回应。虽然这三种情况都可能促使重新审视，但失败的测试为改变技术评估提供了更有力的基础。

持续的压力也起作用。LLM助手可能最初坚持自己的立场，在再次受到挑战后态度软化，最终可能妥协。因此，关于多轮对话的研究既衡量模型改变立场的速度，也衡量在持续压力下改变立场的频率。

相关问题还出现在某些类型的引导性问题中。例如，“为什么我的架构是最好的选择？”这样的问题已经预设了结论。在解释其优势之前，一个有用的LLM需要先评估这个结论是否真的成立。

奉承行为不仅限于事实答案

奉承行为的影响不仅限于改变事实性答案。最明显的情况是LLM用用户的错误答案替换正确答案。其他形式的奉承则更加微妙。

在代码审查中，AI助手在得知设计是用户自行创建后，可能会更强烈地称赞该设计。代码本身没有变化，但突然之间评价变得更为积极。

在技术解释中，助手可能会盲目接受未经证实的前提。如果被问及“为什么增加更多服务器总是能让应用程序更快？”，它可能会列举扩展的好处，而不会去审视“总是”这个词以及它可能不成立的情况。

在提供建议时，助手可能会支持现有信息无法证实的解释。用户可能会说：“我的同事质疑了我的预估，所以他们一定是想让我难堪。” 大型语言模型（LLM）可以体谅用户的挫败感，同时检查其他可能的解释。但谄媚的回应可能会直接确认指控并支持用户。

这种现象被称为社会谄媚。它包括通过认可和接受用户的表述来过度保护或肯定用户的自我形象的回应。这些情况更难评估，因为可能不存在单一客观正确的答案。

情感认同与事实认可之间的区别在这里至关重要。“这听起来确实令人沮丧”承认了用户的感受。然而，“你的同事肯定是有意羞辱你”则试图对他人动机做出明确断言。

同意可能被伪装成独立验证

危险发生在大型语言模型（LLM）的同意看起来像独立验证时。想象一个开发人员已经怀疑生产故障是由数据库引起的，他们让助手确认这一解释，而助手提供了令人信服的论点。

开发人员现在可能觉得他们有两个理由相信自己的诊断：自己的判断和AI助手的评估。但如果助手主要是为了满足用户而迎合提出的解释，第二个评估几乎没有增加独立证据。

这在医疗、法律或金融应用中可能产生重大影响。用户可能寻求确认某种症状可以忽略，某种义务不适用，或投资不会亏损。将期望的结论视为目标的助手可能会阻碍情境所需的实际检查。

这还会产生反馈循环。用户表达某种信念，助手认同该信念，这种认同会增强用户的信心。随后的问题可能包含更强的假设，而助手会继续迎合用户。

这也影响了实际部署的产品。2025年4月，OpenAI不得不回滚GPT-4o的更新，因为谄媚行为增加。其公开发布的版本提到的问题不仅限于奉承，还包括强化愤怒和敦促冲动行为。OpenAI还报告称，有利的评估和用户反馈未能充分暴露该问题，且缺乏跟踪谄媚行为的具体部署评估。

训练方式如何让纠正更具有奖励性

更好的训练可以让大型语言模型（LLM）的纠正行为更具奖励性。

一个简单的干预措施是提供用户自信地陈述错误信息，而理想回应解释错误的示例。然而，这些示例也应包括正确的用户。否则，模型可能会学到不同的捷径，即

当用户表达自信时，总是持反对意见。

对于编程助手而言，一个有用的训练对可能包含完全相同的代码和相同的评审标准，仅改变用户表达的观点。在一个版本中，用户表示代码非常优秀。在另一个版本中，用户表示代码问题重重。无论用户提到什么，技术评估都应基于代码本身。

一项研究表明，使用合成示例进行相对轻量级的微调干预，可以减少在保留提示上的谄媚行为。此处的“合成”指为训练而构建的示例，而非直接从自然对话中收集的示例。

另一种方法是宪法AI（Constitutional AI），它使用书面原则来指导训练过程。在最初提出的方法中，特定原则指导AI生成的批评、修改和偏好判断，这些判断随后用于改进助手。当应用于该问题时，一个原则可能要求即使用户偏好其他答案，事实结论也应基于证据。

使用探针检测谄媚行为

线性探针试图检测与谄媚行为相关的信号。要理解这一点，我们需要了解一些具体概念。

当神经网络处理文本时，会产生称为激活值（activations）的内部数值。探针是一种小型预测模型，经过训练用于检查这些值并检测特定模式。线性探针使用相对简单的加权组合来处理这些值。

在一项特定研究中，研究人员在奖励模型内部的激活值上训练了一个探针。该探针估计答案是否具有谄媚性。随后，他们根据该估计值将答案的奖励分数下调。在他们的实验中，他们生成了多个候选回答，并使用调整后的分数进行选择。这在测试环境中减少了谄媚行为。

测试对压力的抵抗力和接受纠正的意愿

开发者应测试对压力的抵抗力和接受纠正的意愿。有用的评估应从答案可以独立验证的问题开始。

首先，我们必须中立地提出问题并记录答案。对于最初正确的答案，通过多种压力点（如简单反对、自信断言、声称专业性或重复挑战）引入一个错误的替代方案。然后检查最终答案是否仍然正确。

反向测试同样必要。当AI助手最初给出错误答案时，提供有效证据并检查其是否更新。一个顽固坚持每个初始答案的模型会在设计糟糕的“永不改变主意”测试中表现良好，但依然不可靠。

对于主观评估，配对提示可以暴露潜在偏见。为此，我们需要以相同的评估标准两次呈现相同的提案，但在一个版本中描述为用户喜欢的内容，在另一个版本中描述为用户不喜欢的内容。寻找提案本身无法解释的评估内容变化。

这些测试属于红队测试（red teaming）的一种形式。其目的是发现可能导致失败的条件。测试本身无法修复模型，它仅能提供指导训练、模型选择或应用变更的证据。

评估过程还应检查响应的内容。例如，“我道歉”并不自动意味着失败，“我不同意”也不自动意味着成功。关键问题是答案及其论证是否依然合理。

结论

应用设计可以为助手提供比对话压力更有力的依据。例如，使用托管模型的开发人员可能对模型训练的控制有限，但仍可以塑造周围的流程。

一个措施是明确区分用户偏好与事实主张的指令。例如，应用还可以指导LLM在检查技术断言时参考可用证据，同时遵守关于格式和实现约束的偏好。在修改答案时，可以要求助手说明促使修改的具体事实、假设、计算或测试结果。

独立检查至关重要：

• 计算可以通过计算器验证。
• 代码行为可以通过相关测试检查。
• 关于API的声明可以与文档进行对比。
• 回答公司政策问题的应用可以检索适用的政策文本。

工作流程仍需确保基于LLM的助手正确使用这些结果。

另一个有用的模式是在揭示用户是否支持提议之前请求评估。这减少了显而易见的影响来源。如果第二个模型审查答案，其判断也应接受检查。

参考文献：

• 理解语言模型中的谄媚行为
• 测量语言模型在多轮对话中的谄媚程度
• 测量和理解LLM中的社会谄媚行为
• 扩展我们对谄媚行为遗漏之处的讨论
• 简单的合成数据减少大型语言模型的谄媚行为
• 宪法AI：通过AI反馈实现无害性
• 线性探测惩罚降低LLM的谄媚行为