空洞解释问题：当模型的推理只是装饰而非证据

一个贷款审查工具标记了一份申请。审查员点击“解释”，得到了四个整齐的要点：过去六个月的收入波动、信用额度使用率超过 70%、最近的地址变更、两个信用记录较少的被抚养人。这些理由读起来就像一位细心的核保人员写的。审查员批准了覆盖操作并继续。

令人不安的部分是：模型从未利用这些信号做出决定。它们出现在解释中，是因为它们是那种 可以 证明标记合理性的因素——而不是因为标记源自它们。实际的计算是一种模型无法表达的狭窄潜在特征模式，加上一些解释中从未提及的相关性。这些要点是事后合理化（post-hoc rationalization），其编写目的是为了可信，而不是为了真实。

这就是空洞解释问题（hollow explanation problem），它与幻觉（hallucination）不同。该解释中的每一个单独主张在事实层面可能都是正确的。但用户的问题——你为什么这么决定？——被虚假地回答了。

事后合理化是隐藏在眼前的失效模式

两年来，幻觉一直主导着 LLM 信任的讨论，大多数工程团队至少拥有 一些 防御手段：检索增强（RAG）、引用要求、输出验证器。空洞解释的失效可以通过所有这些过滤器。核保示例中引用的每个因素可能都是真实的（申请人 确实 最近更改了地址），解释可能逻辑自洽，它所支持的答案甚至可能是正确的。但这都不能使这个解释真正成为一个解释。

2025 年的一项研究通过将思维链（CoT）分为两种角色，明确了这一区别。“作为计算的 CoT”（CoT-as-computation）是指模型的中间 token 是解决任务的一部分——移除它们，答案就会改变。“作为合理化的 CoT”（CoT-as-rationalization）是指答案本质上是由底层权重决定的，而可见的链条是为了事后证明其合理性而生成的。生产环境中的推理模型在这些模式之间无形地滑动，而且没有任何 API 字段会告诉你当前处于哪种模式。

前沿模型评估的实证数据令人清醒。当研究人员植入暗示以偏导模型的答案，然后要求其解释推理过程时，即使是最强大的推理模型，在暗示明显影响了输出的情况下，也只有不到 20% 的案例在口头表达中提到了该暗示。早期的非思考模型在简单的连贯性检查（如连续询问“X 是否大于 Y？”和“Y 是否大于 X？”）中表现出高达 13% 的隐性事后合理化率——模型会系统地对两者给出相同的回答，并为每个回答产生一个听起来合理的论点。论点并不是原因；偏见才是。

部署后果：如果你的用户界面在模型决策旁边显示生成的理由，那么你正在向用户展示一些东西，而这些东西与实际计算的关系并不是你们双方所假设的那样。

为什么忠实的解释比看起来更难

直觉上的修复方案——“让模型更仔细地解释其推理”——是在与架构作对。Transformer 的前向传播是在注意力头和 MLP 特征之间的密集并行计算；输出 token 序列是该计算的序列化，但它不是它的转录。要求模型解释自己会产生另一次针对问题和答案的前向传播，从而生成基于两者的、看起来合理的推理。没有任何“先前前向传播中实际发生了什么”的特权通道，因为正在进行解释的模型除了其磁带上已有的内容外，无法访问其自身的内部细节。

这就是为什么强化学习（RL）方法在忠实度上很快遇到瓶颈的原因。Anthropic 的评估发现，RL 训练最初在 MMLU 上将 CoT 忠实度提高了 63%，在 GPQA 上提高了 41%，然后便停滞在远低于有用阈值的水平——分别为 28% 和 20%。训练信号可以鼓励模型 提及 某些因素，但不能强制其提及的内容因果性地追踪其计算。模型学会在提示词将诚实表达作为局部奖励行为时诚实地进行口头表达，并在其余时间学会跳过口头表达。

同一时期的机械可解释性（mechanistic interpretability）研究从另一个方向强化了这一观点。对模型内部的归因图分析表明，给定答案背后的潜在计算通常涉及没有清晰语言标签的特征，而口头解释则调用了模型在训练中看到的与类似答案共同出现的标签。这种口头表达对于外部观察者来说是合理的，但对于内部观察者来说并不忠实。

对于产品团队来说，诚实的表述应该是：解释界面并不是观察模型内部的窗口。它是另一次生成，具有与第一次生成相同的失效模式，并受制于之前的输出。

CoT 作为计算的“避风港”（及其狭窄的适用范围）

在一种模式下，思维链（Chain-of-thought）解释具有真正的证据权重：当任务确实需要无法在单次前向传播中完成的多步计算时。多位数算术、多跳检索组合、特定的规划问题。在这种情况下，可见的推理是承重的——模型确实需要这些中间步骤来得出答案。修改一个步骤，结论就会改变。完全删除这些步骤，准确率就会崩溃。在这种模式下，思维链就是计算过程，阅读它能告诉你真实的信息。

这个避风港之所以重要，是因为它诱使团队过度泛化。一个团队看到 CoT 在数学基准测试中有所帮助，观察到模型在产品界面上产生了流畅的推理，便得出结论：对于他们的用例，推理同样是承重的。但大多数生产任务属于另一种情况：分类、摘要、基于检索的回答、工具调用选择。对于这些任务，答案主要由受提示词约束的前向传播决定，而 CoT（如果有的话）只是装饰性的——添加它是为了让用户看到“推理”，或者是因为某些评估指标奖励更长的输出。

值得内化的决策规则：询问消融中间文本是否会改变答案。如果是，那么思维链正在进行计算工作，并具有一定的证据权重。如果不是，它就是装饰，将其作为“推理”展示给用户会误导他们对所见内容的理解。

一个相关的注意事项：即使 CoT 在计算上是承重的，它仍然可能对自己的内部状态描述有误。一个确实需要三步才能解决问题的模型可能会执行这些步骤，然后在可见的 Token 中略微不准确地描述它们——例如，在内部计算出一个数字，在痕迹中写下另一个数字，但最终仍然得出正确的答案。思维链帮助模型得出正确答案这一事实，并不意味着思维链准确地报告了模型到达那里的路径。

在不伪造可解释性的情况下保持信任的设计模式

在生产实践中处理过这个问题的团队已经收敛于一套小型的模式，这些模式尊重模型能够且无法诚实告诉用户的内容。

在推理之前呈现不确定性，而不是作为附言。 大多数产品先展示一个自信的答案，并将不确定性（如果有的话）作为隐藏在底部的规避说明。颠倒这个顺序会改变你阅读后续内容的方式。校准后的拒绝（Calibrated abstention）——“我没有足够的信号来自信地回答这个问题”——当作为一等输出而非备选方案展示时，可以让模型在任何解释都属于虚构的查询上优雅地拒绝回答。一份 2025 年关于拒绝回答方法的研究记录了，即使底层模型支持，也很少有生产系统真正暴露了这个界面。

归因于证据，而非内部推理。 当答案来自检索到的文档时，引用文档并让你追溯该主张。这把解释的负担从“模型在想什么？”（无法诚实回答）转移到了“系统使用了什么证据？”（可验证）。基于出处的回答并不完美——模型仍可能忽略引用的证据并基于训练先验进行模式匹配——但至少你可以抽查引用来源与陈述主张之间的关系。

展示中间产物，而非合理化解释。 如果模型使用了工具，展示工具调用及其输出。如果它发起了数据库查询，展示该查询。如果它参考了政策文档，展示该片段。这些产物具有因果性——模型的回答是以一种可审计的方式被它们塑造的。工具调用列表比生成的推理段落是更诚实的“为什么”解释，因为你可以验证工具调用确实发生了，并检查它们返回了什么。

“我不知道为什么”作为一等输出。 这是团队最抵制的模式，因为它感觉像是在承认弱点。但是，如果模型说“这匹配了一个我无法清晰表达的模式——这是答案，这里有一些可能相关的相邻因素，请将此解释视为探索性的”，那么它表现出的诚实是那些产生四个干练要点的模型所不具备的。用户对认知谦逊（Epistemic humility）的容忍度高于对经不起压力测试的合理化解释的容忍度。

将解释界面锚定在系统可验证的内容上。 一个经验法则：对于一类无法根据计算审计解释的决策，不要暴露“为什么”的界面。对于低风险的推荐，生成的解释是可以接受的——空洞的合理化成本很低。对于会影响用户行为且你随后可能质疑的决策（贷款、招聘、医疗分诊、内容审核），解释界面需要引用可审计的输入（工具调用、检索到的文档、结构化特征），而不是生成的叙述。

信任数学：为什么空洞的解释比承认局限性失效得更快

搞错这一点的产品成本并非抽象的。当用户发现——他们确实会发现，特别是在利益攸关的情况下——模型的解释实际上并没有驱动其决策时，信任的损失比模型预先承认不确定性所导致的信任损失要惨重得多。原因在于校准（Calibration）。如果用户被告知“我不确定为什么匹配，但结果在这里”，他们会形成一个校准后的预期：这个系统是有用的，但只是临时性的，在根据其输出采取行动之前我应该进行验证。而如果用户被告知“我标记这个是因为 A、B 和 C”，随后却发现 A、B 和 C 与该标记毫无关系，他们不仅会更新对这个答案的看法，还会质疑系统之前给出的每一个解释。信任是断崖式下跌，而不是缓慢下滑。

这种损害还会产生复合的下游效应：**合理化（Rationalizations）**会在错误的方向上起到“帮助”作用。它们足够连贯，以至于用户会基于这些解释建立系统运作的心智模型。当合理化被证明是空洞的时，那些心智模型也随之错误，用户不得不丢弃数月积累的启发式经验。代价不仅仅是“这个答案错了”，而是“我不再知道这个系统在做什么”。这是终结产品采用的失效模式。

发布解释界面的团队至少应该问：如果监管机构或深思熟虑的用户审计我们的解释与实际计算之间的关系，会发生什么？如果答案是“我们会感到尴尬”，那么这个界面带来的伤害就大于好处，即使单个用户在阅读它时感到很有信心。

周一该怎么做

对于目前正在发布生成式解释的团队，这里有三个具体的行动：

1. 审计一类决策。 选择一个模型同时产生答案和理由的单一产品界面。对这些答案的样本进行反事实探测（Counterfactual probe）——如果修改其中一个引用的因素，相同的输入是否会产生不同的答案？如果不会，那么这种解释就是装饰性的，你应该掌握这种情况发生的比例。

2. 尽可能用呈现的产物（Artifacts）代替生成的推理。 工具调用追踪、检索片段、结构化特征归因。这些东西比一段生成的文字占用更多的产品空间，但它们为用户提供了可以验证的因果依据。

3. 增加一个真正可用的“我不确定”路径。 大多数生产环境的提示词（Prompts）都会引导模型去产生答案。反转一个分支——衡量如果“弃权”得到同样的奖励，模型会有多频繁地选择不回答——这能为你提供一个目前尚未掌握的校准基准。

这一切背后的架构认知是：模型的解释是一个独立的生成过程，而不是窥视第一个生成过程的窗口。请这样对待它。发布计算逻辑能够支撑的解释界面，并将“推理”一词留给那些逻辑链真正发挥作用的情况。除此之外的一切都是装饰，而伪装成证据的装饰比承认局限性更容易侵蚀用户信任。