LLMs Get Lost in Multi-Turn Conversation

People rarely give a language model everything it needs in the first message. They start with a vague request and add details as the model responds. Benchmarks, though, hand the model a complete instruction in one turn. Philippe Laban and Jennifer Neville at Microsoft Research, with Hiroaki Hayashi and Yingbo Zhou at Salesforce Research, measured what happens when the same task is delivered gradually.

Their tool is sharding. A fully specified instruction, such as a GSM8K word problem about Jay making snowballs, is split into shards: the first states the high-level question ("How long before Jay's ready?"), and each later one adds a single fact (20 per hour, 60 needed, 2 melt every 15 minutes). Together the shards hold the same information as the original. In a sharded simulation, a GPT-4o-mini user simulator reveals at most one shard per turn, rephrased to fit the conversation. Each reply is classified (clarification, hedge, answer attempt and so on), answer attempts are extracted and scored, and the conversation ends when the model answers correctly or the shards run out. Two controls: full, the original instruction in one turn, and concat, all shards in one turn as bullet points.

They sharded 600 instructions across six tasks: Python functions (HumanEval, LiveCodeBench), SQL (Spider), function calling (BFCL), math (GSM8K), table captions (ToTTo) and multi-document summaries (Summary of a Haystack). Fifteen models, from Llama 3.1 8B to Gemini 2.5 Pro, o3 and DeepSeek-R1, each ran ten times per instruction and setting at temperature 1, for over 200,000 conversations.

Every model did worse in conversation, on every task: on average 39% below its single-turn score. Concat stayed at 95% of full, so the shards were not missing information. The authors split the loss into aptitude (the best runs, 90th percentile) and unreliability (the gap between best and worst runs). Aptitude fell modestly; unreliability more than doubled. Their account: models attempt full answers too early, fill gaps with assumptions, then build on those wrong attempts instead of starting over. They get lost and do not recover.

Almost every assistant you deploy is multi-turn, and almost every evaluation you are shown is single-turn. This paper puts a number on the gap.

Your evals overstate conversational quality. If the customer's test set gives the model complete requests, it measures the best case. Build part of the eval set the way users actually talk: start vague, add requirements over turns.

Premature answers are the failure to design against. Systems that ask a clarifying question, or hold off on a full solution until requirements settle, did better in the paper's data. Short, focused replies did better than long ones that pile up assumptions.

Restating requirements helps, partly. Gathering everything the user said into one message recovered about half the loss in the paper's best case. Products can do this automatically: summarize requirements and restart with a clean context.

Lowering temperature does not fix it. At temperature 0 for both user and model, the spread between runs stayed around 30 points. One different token early in a conversation compounds.