LLM多轮对话性能暴跌39%：你的AI应用可能在第三轮就开始胡说八道

最近在做一个多轮对话的AI功能，用户反馈”聊着聊着AI就不对劲了”。一开始以为是prompt写得有问题，排查了两天，最后发现这是LLM的通病——多轮对话场景下，模型性能会断崖式下跌。

Microsoft和Salesforce的研究团队做了一个系统性测试，结论很扎心：当用户分多轮逐步提需求时（这不就是正常聊天吗），模型准确率从90%暴跌到51%，平均下降39%。2026年初的跟进研究显示，最新一代模型（GPT-5之后）把这个数字改善到了33%，但问题远没有解决。

为什么多轮对话这么难

研究团队用了一个叫”sharding”的方法来模拟真实用户行为——把一个完整任务拆成多轮小指令，逐步告诉模型。这其实就是我们日常跟ChatGPT聊天的方式：先说个大概，再补充细节，中途可能还会改需求。

测试了15个模型，从Llama-3.1-8B到GPT-4o，无一幸免。即使是当时最强的Claude 3.7 Sonnet、Gemini 2.5 Pro和GPT-4.1，多轮场景下性能也掉了30%-40%。

研究者总结了四个核心问题：

实测：同一个任务，单轮vs多轮

我用一个真实的前端需求来做对比。任务是：写一个带搜索、分页、排序的用户列表组件，数据从API获取，要处理loading和error状态。

单轮方式——把所有需求一次性丢给模型：

写一个React组件UserList，要求：
1. 从 /api/users 获取数据，支持分页（每页20条）
2. 顶部搜索框，输入时防抖300ms，搜索name字段
3. 表头点击排序，支持name和createdAt两列
4. loading时显示skeleton，error时显示重试按钮
5. 用TypeScript，用React Query管理请求状态

GPT-4o和Claude Sonnet都能一次性给出完整、可用的组件代码，包含所有5个需求点。

多轮方式——模拟真实开发场景，逐步提需求：

第1轮：写一个React组件，从/api/users获取用户列表
第2轮：加个搜索功能，搜name字段
第3轮：搜索加个防抖，300ms
第4轮：表头能点击排序，name和createdAt
第5轮：对了，要分页，每页20条
第6轮：loading的时候显示skeleton，报错显示重试
第7轮：用TypeScript重写一下，状态管理换成React Query

结果很有意思：

注意看：不是模型不会写这些功能，单轮全都能搞定。问题出在多轮迭代时，新需求会”挤掉”之前的需求。尤其是第3-5轮提的东西最容易丢，跟研究论文说的”中间信息丢失”完全吻合。

技术手段能修吗？研究者试了，不太行

研究团队尝试了几种修复方案：

• 降低temperature：减少随机性，结果基本没改善
• 让agent复述用户指令：强制模型在回答前重复一遍需求，效果不明显
• 调整每轮信息量：每轮多说点或少说点，都没用

唯一有效的方法：把所有信息在第一轮就给全。但这在实际产品里根本不现实——用户不可能一次把需求说清楚。

开发者能做什么：四个实战策略

1. 对话摘要重置法

这是研究者推荐的方法，也是我实测最有效的。当对话超过5轮，让模型先总结之前所有需求，然后用这个摘要开一个新对话：

interface ConversationManager {
  messages: Message[];
  turnCount: number;
  maxTurnsBeforeReset: number; // 建议5-7轮
}

async function handleNewMessage(
  manager: ConversationManager,
  userMessage: string,
  llmClient: LLMClient
): Promise {
  manager.messages.push({ role: 'user', content: userMessage });
  manager.turnCount++;

  if (manager.turnCount >= manager.maxTurnsBeforeReset) {
    // 让模型总结之前的所有需求
    const summary = await llmClient.chat([
      ...manager.messages,
      {
        role: 'user',
        content: '请总结我们之前讨论的所有需求和已确认的细节，用清晰的列表格式。'
      }
    ]);

    // 用摘要重开对话
    manager.messages = [
      {
        role: 'system',
        content: `之前的对话摘要：
${summary}

请基于以上需求继续工作。`
      },
      { role: 'user', content: userMessage }
    ];
    manager.turnCount = 1;
  }

  return llmClient.chat(manager.messages);
}

实测这个方法能把多轮场景下的需求完整度从60%提升到85%左右。

2. 需求累积器模式

在前端维护一个需求列表，每轮对话都把完整需求列表注入context：

class RequirementAccumulator {
  private requirements: Map<string, string> = new Map();

  add(key: string, detail: string) {
    this.requirements.set(key, detail);
  }

  toPrompt(): string {
    const items = Array.from(this.requirements.entries())
      .map(([key, val]) => `- ${key}: ${val}`)
      .join('
');
    return `当前已确认的完整需求：
${items}

请确保输出包含以上所有需求。`;
  }
}

// 使用
const acc = new RequirementAccumulator();
acc.add('数据源', '/api/users，分页每页20条');
acc.add('搜索', 'name字段，防抖300ms');
acc.add('排序', '表头点击，支持name和createdAt');
// 每轮都把 acc.toPrompt() 加到system message里

这个方法的好处是不依赖模型自己记住需求，缺点是token消耗会随轮数线性增长。

3. 结构化输出校验

让模型在每轮输出时，同时返回一个需求checklist：

const systemPrompt = `每次生成代码后，附带一个JSON格式的需求检查清单：
{
  "implemented": ["已实现的需求列表"],
  "missing": ["检测到但未实现的需求"],
  "assumptions": ["你做的假设，用户未明确说明的"]
}`;

前端拿到这个checklist后自动校验，如果missing不为空就提醒用户确认。

4. 关键轮次检测

不是所有轮次都会出问题。根据研究数据，第3-5轮是高危区间。可以在这些轮次自动插入一个”确认步骤”：

function shouldInsertCheckpoint(turnCount: number): boolean {
  // 第3、5、8轮自动插入确认
  return [3, 5, 8].includes(turnCount);
}

// 确认prompt
const checkpointPrompt = '在继续之前，请列出你目前理解的所有需求，让我确认是否遗漏。';

对产品设计的启示

这个研究改变了我对AI产品交互设计的一些看法：

表单式引导优于开放对话。如果你知道用户需要提供哪些信息，用结构化的表单或选项引导，比让用户自由聊天靠谱得多。很多AI产品喜欢做成纯对话界面，觉得这样”更自然”，但从可靠性角度看，适当的UI引导反而能提高产出质量。

对话历史可视化很重要。在聊天界面侧边栏显示一个”已确认需求”列表，让用户能直观看到模型当前理解了哪些需求。这不光对用户友好，还能作为每轮prompt的context注入。

不要迷信”越长的对话越好”。很多AI产品把”支持超长对话”作为卖点，128K、200K的context window听着很唬人。但context window大不等于多轮对话质量好。该重置就重置，用户体验反而更好。

写在最后

LLM多轮对话的可靠性问题不是个小bug，是当前架构的系统性限制。2026年初的跟进研究显示新模型把性能衰减从39%改善到了33%，Python相关任务好一点（只降10%-20%），但整体问题还在。

作为开发者，现阶段能做的就是在应用层做补偿：定期摘要重置、需求累积、结构化校验。不要假设模型能完美处理长对话——它做不到，至少现在做不到。

研究论文：Philippe Laban et al., “Lost in Conversation: LLMs Struggle with Multi-Turn Tasks”