ICLR 2026 的另一篇杰出论文来自 Microsoft Research 与 Salesforce Research 的合作：LLMs Get Lost In Multi-Turn Conversation。结论也直白：把同样一个任务拆成多轮渐进式给出，15 个主流 LLM（包括 GPT-4.1、Gemini 2.5 Pro、Claude 3.7 Sonnet、o3、DeepSeek-R1）全部出现性能下降，平均降幅 39%。论文特别强调 unreliability 的增加在所有模型上水平接近，与模型规模、是否带 reasoning、是否闭源无关。

更有意思的是降幅的构成：aptitude（能力）只下降约 15%，unreliability（不可靠性）暴涨 112%。换句话说，模型多轮场景下并不是变笨了，而是变得不稳定，同一个任务跑十次得到的最好与最差结果之间能差出 50 个百分点。

论文地址： arxiv.org/abs/2505.06120

单轮 benchmark 的局限

现有的 LLM 评测几乎都是单轮：把一个完整的、信息齐全的 instruction 喂给模型，让模型一次性输出答案。MMLU、HumanEval、GSM8K、MT-Bench 大都如此。即便有所谓的多轮评测（如 MT-Bench 的第二轮），论文称之为"episodic"：每一轮其实是一个独立的子任务，可以单独评分。

但实际用户不是这样用的。Herlihy et al. 2024 的对话日志研究指出，underspecification 是真实交互中的常态：用户经常先抛半句话试探，再根据模型反应补充细节。这种情况下，模型必须把分散在多轮中的线索拼起来才能解出题。

作者把这两种范式之间的断裂作为研究起点：如果把同一个完整 instruction 拆成几"份"信息（shard），让用户在每轮逐步揭开一份，模型在 single-turn 场景下的能力还能保住吗？

sharded simulation 的实验设计

要规模化研究多轮迷路，最大的设计难点其实不是"怎么模拟用户"，而是"怎么让单轮和多轮的分数能直接比"。以往的多轮 benchmark 都是 episodic 的，每一轮自己是个独立子任务，单轮分数和多轮分数对应的根本不是同一件事，掉了多少没法归因。作者的设计核心就一句话：保留同一个原始 instruction 不变，只改变信息揭示的方式，然后看分数怎么动。

围绕这个核心拉出三种设置：FULL 一次性给完整 instruction，是单轮上限；SHARDED 把同一个 instruction 切成若干 shard 逐轮揭示，是真实多轮；CONCAT 把所有 shard 一次性拼成 bullet list 喂进去，作为对照组排除"sharding 本身丢信息"或"rephrase 影响理解"。三者共享同一份底层任务和同一个 evaluator，FULL 与 SHARDED 之间的差距才能干净地归因到"underspecified 多轮"这一个变量上。

具体 pipeline 有四步：

1. Sharding：用半自动流程把现成 benchmark（HumanEval、LiveCodeBench、Spider、GSM8K、ToTTo、BFCL、Summary of a Haystack）的单轮 instruction 拆成若干 shard，每个 shard 是一个原子信息单元，所有 shard 拼起来等价于原始 instruction。CONCAT 设置作为事后验证，得分与 FULL 平均相差不超过 5%，说明 sharding 没丢信息。
2. 三个 LLM 角色：assistant 是被测模型；user 由 GPT-4o-mini 扮演，手里握着完整 sharded instruction，根据当前对话历史决定下一轮揭哪个 shard 并轻微 rephrase；system 负责给 assistant 每轮的回复打标签（clarify / hedge / answer attempt 等七类）并对 answer attempt 抽取打分。被测 assistant 不知道自己在跟模拟器对话，也不知道对话会是 underspecified 的。
3. 每轮严格 ≤ 1 shard：这是整个实验的硬约束。模型必须等下一轮才能拿到下一份信息，没法绕过"信息渐进"这个设定。
4. Scoring：一次对话的最终分数取所有 answer attempt 中最高的那个。这其实是给 SHARDED 设置的"红利"，单轮只能猜一次，多轮可以猜 N 次。即便如此，SHARDED 仍然显著低于 FULL。

下图中是一些论文中的例子，把六个任务的"原始 instruction（Fully-Specified）“和对应"sharded instruction"并排放在一起：

以 Math 列（GSM8K）为例。FULL 设置下原题是：

Josh decides to try flipping a house. He buys a house for $80k and then puts in $50k in repairs. This increased the value of the house by 150%. How much profit did he make?

sharding 之后变成 5 个 shard，模拟器按对话节奏一轮揭一个：先说"我朋友 Josh 卖房了，想知道赚了多少”，再依次补"买入 $80,000"“装修花了 $50k"“房价涨了 150%"，最后追一句"就这些信息，利润是多少”。

assistant 在轮 1 看到的只是"想算 Josh 卖房赚了多少”，连买入价都没有。论文观察到：多数模型在轮 1 就会给一个完整 answer attempt（“假设买入价是 X、装修花了 Y，那么利润是 Z”），把后面三轮才该出现的信息全靠 assumption 补上。后续 shard 真正揭出来后，模型不会推翻第一轮的框架，而是基于错误前提反复打补丁。即使最终分数取所有 attempt 中最高那个，多轮还是显著输给单轮。

这套设计的妙处在于，原始题目和评分函数都没动，FULL 与 SHARDED 之间的所有差距都来自"信息怎么被揭露"这一个维度，归因非常干净。

实验对 15 个 LLM 在 6 个任务上各跑 N=10 次，共 20 万+ 对话，总成本约 5000 美元。

性能下降的规模与构成

每个模型在每个任务上都掉，平均 -39%。Aptitude 平均掉 15%，Unreliability 平均涨 112%。下图是 15 个模型在三种设置下（FULL / CONCAT / SHARDED）的箱线图：

几个值得注意的细节：

CONCAT（把所有 shard 一次性拼起来）的得分基本与 FULL 持平（平均 95%），这排除了"sharding 本身丢了信息"或"rephrase 影响理解"这两种解释。性能下降确实是 multi-turn underspecified 这个结构带来的。

强模型并没有更抗。看 Fig 5b 的箱线图，Gemini 2.5 Pro、GPT-4.1、Claude 3.7 Sonnet 这些 FULL 平均分在 80 上下的模型，到 SHARDED 设置下普遍掉到 65-75 这一档，与 Llama3.1-8B 的 SHARDED 分数（59）差距远比 FULL 时小得多。论文给的部分解释是：强模型 FULL 起点高，掉的绝对值就显得更大；但 unreliability 增长是普遍的，与强弱无关。

加 test-time compute 也救不回来。o3 和 DeepSeek-R1 这两个 reasoning 模型掉得跟非 reasoning 模型一样厉害，甚至更厉害一些（reasoning 模型回答平均长 33%，更长的回复夹带更多 assumption，反而成了负担）。

迷路的四个根因

论文在附录 F 给出了四个可观测到的根因，每个都对应一种具体的失败模式。

过早回答。SHARDED 设置下，多数模型在拿到第一个 shard（信息最少）时就尝试给出完整答案。论文按"首次 answer attempt 出现的对话进度"把对话分桶：在前 20% 出现首次 attempt 的对话平均得分 30.9，等到 80%-100% 才首次 attempt 的对话得分 64.4（这一分析仅基于 Code 和 Math 两个任务，因为其他任务模型几乎都是第一轮就抢答，无法分桶）。论文将其归因为模型对 underspecified 输入做出的错误 assumption 在后续轮次里持续干扰，并未明确归因到 RLHF 训练目标。

Answer bloat。对话越往后，answer attempt 越长。Code 任务里，仅看真正得到正确解的子集，FULL 平均 668 字符，SHARDED 平均 850 字符（多约 27%）。模型在前几轮基于不全信息生成的 answer attempt，后续即使 invalidate 了也不会真正抛弃，而是不断在上面叠加 patch。最后的"正确答案"通常是一团缝合怪。

Loss-of-middle-turns。在 summary 任务里（每轮引入新文档，要求最终 summary 引用所有文档），作者统计了"第 Y 轮生成的 summary 引用了第 X 轮文档的比例"。结果呈典型的 U 形：第一轮和最后一轮的文档被引用最多，中间几轮的文档被严重忽略。这与 Liu et al. “Lost in the Middle” 在长文本里观察到的 attention U 形分布是同源现象，但发生在 turn 维度上（论文仅在 summary 任务上做了这一分析，是否在其他任务上同样存在尚不确定）。

回复啰嗦。SHARDED 下回复平均比 FULL 长 20-300%，长出来的部分主要是模型自己脑补的 assumption。这些 assumption 一旦成文，就成了模型后续回合的"上下文锚点"，比真正的用户输入还显眼。

四个现象在同一段对话里往往同时出现，彼此放大：早回答会锚定错误 assumption，模型为这个 assumption 反复打补丁就变成 bloat，bloat 又把中间几轮真正的用户输入挤到 attention 分布的低谷。这条因果链是论文呈现完四个现象后的合理解读，不是论文显式给出的实验结论。

几种补救方案的失败

作者试了几种直觉上应该能补救的方案：

RECAP：在最后多加一轮，把所有 shard 重新汇总成 bullet list 喂给模型。这相当于给模型"再来一次"的机会，也接近现在 agent 框架（LangChain、AutoGen）默认在做的事。结果有改善但远不及 FULL，因为前几轮的错误 attempt 还在 context 里干扰。

SNOWBALL：每轮把所有历史 shard 重新拼一遍。改善幅度 15-20%，是几种补救里相对实用的，但成本是每轮 context 越来越长。

降温度：T=1 的时候 sharded unreliability 高，那 T=0 应该好吧？事实是 T=0 下 sharded unreliability 仍有 30%。原因是早期生成的微小随机分歧会级联放大，第一轮选了不同的 clarification 措辞，后面整条对话路径就分叉了。降温度无法消除这种 cascading effect。

Prompt hint：在 system prompt 里告诉模型"对话可能是多轮、underspecified 的，请耐心 clarify"。提升 +1%，可以忽略。

这几个失败的尝试本身比成功的修复更有信息量。它们说明 multi-turn 不可靠不是某个表层 prompt 工程能解决的，要么改训练（让模型在 SFT/RLHF 阶段学会多轮策略），要么改 inference 协议（每轮都重启对话并重新汇总）。

三个错位

论文给出了几条针对不同读者的建议，但更有意思的是它揭示出来的几个错位。

第一个错位是 benchmark 与真实使用的脱节。我们用 90 分的模型做生产，但 90 分是在 lab 条件下测出来的；同样的任务在真实 underspecified 多轮场景里可能只剩 50-60。这部分差距既不会出现在 leaderboard 上，也不容易归因，出错的时候用户大概率怪自己 prompt 没写好。

第二个错位是 agent 框架与 LLM 本体的责任划分。RECAP 和 SNOWBALL 实质上就是在给 LLM “外挂记忆”，让模型每轮都假装是在 single-turn。Agent 框架如此流行，部分原因正是底层 LLM 多轮能力不行，所以应用层不得不补偿。但论文实验表明，agent 式的拼接补偿不能完全拉回到 FULL 水准，这是 LLM 训练目标里的根本缺失，不是上层包一层就能修的。

第三个错位是 reasoning model 的承诺。o3 和 R1 加了大量 test-time compute，单轮性能也确实领先，但 multi-turn unreliability 一样高。这说明 reasoning model 的"想得多"主要发生在已知充分信息之后，对"如何处理信息逐步揭露"这个 meta 层面没什么帮助。

实用层面，论文给普通用户的建议反而是最朴素的两条：如果当前对话感觉不对劲，重开一个新对话，把所有要求一次性写清楚（“if time allows, try again”）；或者让 LLM 帮你把已有对话整合成一个完整 instruction，再用这个 instruction 重开（“consolidate before retrying”）。

这两条 workaround 本身就说明了问题：本该模型做的事，目前还得用户自己来。