自相矛盾的流式响应

模型在第一句说“答案是肯定的”。到了第三段，它又改口说“实际上，经过反思，不——原因如下”。最终状态是正确的。但用户已经离开了。他们读了第一段，将其视为答案，并在模型完成修正之前就付诸行动了。你的评估认为该回答是正确的。但你的用户得到的却是错误的。

这是流式传输 UX 所隐藏的失败模式。逐字渲染（Token-by-token rendering）将每个区块都视为既定事实，但模型并没有“提交”（commit）的概念。在模棱两可的话语和结论之间没有边界，也没有信号表明“接下来的两段将推翻我刚才说的话”。界面将中间状态作为最终状态发布，且回答越长，这种差距就越严重。

流式传输是一种“读未提交”的 UI

数据库对此有一个专门的术语：脏读（dirty reads）。事务正在进行中，磁盘上的值尚未提交，而读取者看到的却是可能回滚的状态。业界很久以前就认定，在不告知用户的情况下显现脏读是一个 Bug —— 大多数数据库默认采用“读已提交”（read-committed），即只有在事务完成后你才能看到这些值。

流式 LLM 输出默认就是“读未提交”的。模型在生成时将其写入可见缓冲区，而读取者没有隔离边界。每个 Token 的视觉权重都与最终答案相同，因为在渲染时没有任何信号表明它是临时性的。对于那个使用接下来的 800 个 Token 来修正立场的推理模型，从 UI 的角度来看，它只是在输入更多的文字。

流式传输最初的理由依然成立：首字时间（TTFT）可以从 10 秒缩短到几百毫秒，感知延迟方面的优势是实打实的。TTFT 低于 1 秒可以保持用户的思路连贯。而 10 秒则是注意力的极限。因此，流式传输以隐形成本为代价赢得了感知竞争：用户在模型完成思考之前，就已经开始阅读并做出决策了。

在短回答中，这是不可见的。第一句话就是唯一的句子。但在任何长到足以包含修正的回答中，权衡就发生了逆转。模型在后续的 Token 中不断自我修复，而用户早已离开了。

矛盾从何而来

这不是流式传输的 Bug。矛盾根植于现代推理模型生成文本的方式中。流式传输只是在错误的时间让它们变得可见。

这种模式出现在多个地方。**修复错误（Restoration errors）**在思维链研究中已有充分记录：模型在第二步出错，在第四步意识到错误，然后默默修正，并像从未出错一样给出修正后的答案。即使最终答案正确，推理轨迹内部也是不一致的。**隐式事后合理化（Implicit post-hoc rationalization）**则更糟：模型通过一条路径确定了答案，然后构建了一个听起来很自信的理由，但这与它得出结论的实际路径并不匹配。单次回答内的自我矛盾在评估套件中也屡见不鲜 —— 模型会在同一个段落中肯定又否定逻辑上互不兼容的主张，特别是当问题引导其模棱两可时。

推理模型，特别是那些被设计为“大声思考”的模型。它们的训练奖励在可见推理过程中的探索，包括撤回错误的中间立场。这正是你在私下深思熟虑时想要的行为。但当这种思虑被逐字流式传输到面向用户的界面时，这种行为就会造成破坏。

长上下文任务让情况变得更糟。回答越长，模型就越需要撤回、限定或反转。开头信心满满，三段之后却加上“然而，数据也显示……”的摘要，并不是一种奇特的失败模式 —— 它们是任何涉及权衡证据的任务的常态输出。

评估错过了它，因为评估看到的是完整回答

标准的评估流程是在生成完成后读取完整回答，并对照参考答案进行评分。最终状态的正确性是核心指标。按照这个指标，一个说“是 —— 实际上不是 —— 原因如下”的回答，与一个直接说“不，原因如下”的回答得分相同。

加载中…