ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 1em;display: block;letter-spacing: 0.1em;color: rgb(63, 63, 63);">
ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 14px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">15种LLM模型在单轮(FULL)和多轮(SHARDED)对话中的表现对比，展示了多轮对话中的显著性能下降。
ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 14px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">当最先进的大语言模型（LLM）面对多轮对话时，它们的表现会大幅下降，
能力(Aptitude)与可靠性(Reliability)的对比分析，显示多轮对话中可靠性下降是主要问题。
研究者通过创新性的指标分解，将LLM在多轮对话中的性能下降分为两部分：
•可靠性下降（Reliability） ：暴跌了112% 这意味着模型在最好和最差表现之间的差距扩大了一倍多。这种高度不可靠性解释了为什么您的AI助手有时表现出色，有时却莫名其妙地"丢三落四"，即使是同一个问题，多次尝试的结果可能截然不同。
分片模拟：模型迷失的实验设计
研究涵盖的六大任务类型及其分片指令示例，展示了如何将完整指令分解为多个信息片段。
研究者设计了名为"分片模拟"的创新实验框架，将完整指令分解为多个信息片段（shards），然后在多轮对话中逐步披露。这种方法模拟了现实世界中用户逐步明确需求的对话过程，而非传统评估中一次性提供完整信息的场景。研究覆盖六大任务领域：
这样的广泛覆盖确保了研究结果具有普遍适用性。
指令分片与对话模拟类型
这张图展示了研究的核心实验设计方法论，分为两部分：
• 展示了研究者如何将完整的单轮指令（蓝色方块）拆分成多个信息片段（黄色小方块） • 这是论文中"分片模拟"实验的基础，模拟用户在多轮对话中逐步提供信息的场景 •FULL ：完整指令在第一轮就全部提供（基线场景） •SHARDED ：指令被分成多个片段，在不同轮次逐步提供（模拟真实多轮对话） •CONCAT ：所有分片在第一轮就提供，但保持分片形式 •RECAP ：使用分片模式，但在最后添加一轮汇总所有先前信息 这张图直观地解释了为什么多轮对话会导致性能下降，以及RECAP和SNOWBALL等策略如何工作。
助您测试与改进Agent系统 微软研究团队已将《Lost in Conversation》研究的完整代码库和数据集开源，这为您提供了一套强大的工具来测试和改进自己的Agent系统。该代码库包含了完整的对话模拟框架（simulator_full.py、simulator_sharded.py等），覆盖单轮完整指令、多轮分片指令以及RECAP/SNOWBALL策略实现。
代码库与数据集的主要特点：
如果您是Agent开发者，您可以使用这些资源进行三方面测试：
2. 验证您设计的信息整合策略（如RECAP）的实际效果 3. 诊断自己的Agent系统在哪些类型任务上更容易"迷失" 研究者建议先在小规模实验确认设置无误后再进行大规模测试，并注意遵循API提供商的速率限制。这套工具可能是目前最完整的LLM信息整合能力评估工具，对于构建真正可靠的多轮对话系统具有极高的参考价值。
⚠️ 仅需两轮对话，模型就开始崩溃
渐进式分片实验结果，证明即使只是两轮对话，模型可靠性就会显著下降。
最令人担忧的发现是，即使在最简单的两轮对话中 ，LLM的表现也会显著下降。研究者通过"渐进式分片"实验证明，只要对话涉及任何程度的信息逐步披露（哪怕只分为两个片段），模型就会出现可靠性崩溃。这意味着您的Agent系统即使在处理看似简单的多轮对话时也面临风险，用户无需刻意提出复杂问题就可能遇到AI助手"迷失方向"的情况。
为何最强模型也会栽跟头 研究通过深入分析对话日志，确定了四个导致模型"迷失"的关键因素：
1.过早假设 ：模型在信息不完整时就尝试回答问题，做出大量假设 2.答案膨胀 ：过度依赖先前（可能错误的）回答，导致答案逐渐"膨胀"而非重新思考 3.注意力分配不均 ：过度关注对话的第一轮和最后一轮，而忽视中间轮次的信息 4.回答冗长 ：生成过于冗长的回答，引入更多无关假设并分散自身注意力 这些因素共同造成了即使是最先进模型也会在多轮对话中逐渐偏离正轨。
回答冗长度对性能的影响
这张表格揭示了一个重要发现：简短回答通常比冗长回答更有效。
• 横轴表示回答的冗长程度，从最简短(0-20%)到最冗长(80-100%) 关键发现：
• 在大多数任务中（尤其是Code、Database、Summary），回答越简短，性能越好 • 例如，代码任务中，最简短回答(0-20%)的得分为55.3，而最冗长回答(80-100%)仅为42.5 • 只有Actions任务在中等冗长度(40-60%)下表现最佳 • 整体平均而言，简短回答(0-40%)的性能显著高于冗长回答(60-100%) 这说明，模型生成过长回答会引入更多不必要的假设，导致"迷失"。
Claude 3.7与DeepSeekR1 在所有测试的15个模型中，Claude 3.7-Sonnet展现出最强的多轮对话可靠性 ，其性能保留率达到65.9%，领先于其他竞争者。尽管GPT-4.1在单轮对话中表现更为出色，但Claude在从单轮到多轮的转换中损失最小，特别是在Math（85.4→70.0）和Summary（29.3→23.6）任务上保持了较高水平。
适用建议：
• 如果您正在开发需要进行复杂多轮交互的Agent，Claude 3.7-Sonnet可能是当前最佳选择 • 如果您受限于开源模型，则Llama 3.3-70B（性能保留率64.2%）是性价比最高的方案 作为研究中测试的两个专门推理模型（reasoning models）之一，Deepseek-R1展现出了极为鲜明的"两面性"。
单轮对话优势：
多轮对话劣势：
研究者特别指出，尽管Deepseek-R1拥有额外的思考（test-time compute）能力，但这并未帮助它在多轮对话中保持稳定性，表明"思考"并不足以解决信息整合问题。
对Agent开发者的建议：
• 单轮交互场景：Deepseek-R1是极具竞争力的选择 • 复杂多轮对话场景：需要谨慎评估或使用DeepSeekV3替代 ?️ 降温无效：不确定性不是罪魁祸首 不同温度设置下模型的不可靠性测试结果，证明降低温度在多轮对话中无法有效提高可靠性。
一个常见误解是认为降低模型温度（temperature）参数可以提高多轮对话的一致性。研究者特别设计了温度实验，结果显示：
•单轮对话 ：降温有效（从1.0降至0.0可减少50%的不可靠性） •多轮对话 ：降温几乎无效（温度为0.0时，不可靠性仍高达30%左右） 这一发现表明问题的根源不是随机性，而是模型在多轮上下文中处理信息的固有缺陷。工程师们需要注意 ：简单调整生成参数无法解决多轮对话中的"迷失"问题。
RECAP策略：提升多轮对话性能 RECAP和SNOWBALL策略的性能对比，展示这些方法能有效缓解多轮对话中的性能下降。
针对"迷失"问题，研究者测试了两种可能的解决方案：
1.RECAP（最终回顾） ：在多轮对话结束前添加一个额外轮次，汇总之前所有用户提供的信息 2.SNOWBALL（累积重述） ：每轮都重述之前的信息 实验成果显著：RECAP策略可将GPT-4o的多轮表现从59.1%提升至76.6%，缓解约40%的性能下降。
实用建议 ：在设计Agent系统时，可以考虑在关键决策点添加信息回顾机制，虽然这不能完全解决问题，但可以显著降低风险。
Agent架构设计的五点实用建议 基于研究发现，以下五点建议可帮助您设计更可靠的Agent系统：
1.延迟回答生成 ：避免模型过早做出假设，通过明确指示模型在收集足够信息前保持克制 2.控制回答长度 ：研究数据显示简短回答的成功率显著高于冗长回答 5.培养用户提供完整信息 ：研究表明一次性提供完整指令的表现远优于分散指令 这些策略组合使用，可以构建出更加可靠的Agent系统。
研究者的建议 研究结果对LLM开发者提出了严峻挑战：当前主流评估方法过度关注单轮、完全指定场景下的能力（Aptitude），而忽视了多轮、信息逐步明确场景下的可靠性（Reliability）。
研究者呼吁LLM开发者在未来模型迭代中同等重视这两个维度，并提出了具体标准：
• 理想的LLM应在单轮和多轮设置中保持相似的能力水平 这一转变将使下一代LLM更适合构建真正可靠的对话式Agent系统。
写在最后 "Lost in Conversation"研究揭示了当前LLM的关键局限。通过选择最适合您的模型，结合RECAP等信息整合策略，并遵循论文提供的实用建议，您可以显著提高Agent系统在多轮对话中的可靠性。
尽管完美解决方案尚未出现，但认识到问题并采取针对性措施，已是构建下一代可靠Agent系统的重要一步。当用户说"AI总是半途忘记我说过什么"时，您的系统或许能成为打破这一刻板印象的例外 。
