Pourquoi les modèles de langage se perdent-ils dans la conversation ?

Un nouvel article de recherche de Microsoft Research et Salesforce révèle que même les modèles de langage les plus capables (LLM) s’effondrent lorsqu’ils reçoivent des instructions étape par étape plutôt que toutes à la fois. Les auteurs ont constaté que les performances chutent en moyenne de 39 % sur six tâches lorsque une invite est divisée en plusieurs tours :

Une conversation en un seul tour (à gauche) obtient les meilleurs résultats, mais est peu naturelle pour l’utilisateur final. Une conversation en plusieurs tours (à droite) montre même les LLM les plus performants perdant leur efficacité dans une conversation. Source: https://arxiv.org/pdf/2505.06120

Plus frappant encore, la fiabilité des réponses prend un plongeon, avec des modèles prestigieux tels que ChatGPT-4.1 et Gemini 2.5 Pro oscillant entre des réponses quasi parfaites et des échecs flagrants, en fonction de la façon dont la même tâche est formulée ; de plus, la cohérence de la sortie peut chuter de plus de la moitié au cours du processus.

Pour explorer ce comportement, l’article introduit une méthode appelée sharding*, qui divise les invites complètes en petits fragments et les libère un à un dans une conversation.

Dans les termes les plus basiques, cela équivaut à donner une commande cohérente et complète à un restaurant, laissant le serveur avec rien à faire qu’acknowledger la demande ; ou décider d’aborder la question de manière collaborative:

Deux versions extrêmes d’une conversation au restaurant (pas de l’article, à des fins d’illustration uniquement).

Pour insister, l’exemple ci-dessus met peut-être le client dans une lumière négative. Mais l’idée de base représentée dans la deuxième colonne est celle d’un échange transactionnel qui clarifie un ensemble de problèmes, avant de résoudre les problèmes – apparemment une façon rationnelle et raisonnable d’aborder une tâche.

Ce dispositif est reflété dans la nouvelle approche de l’interaction LLM, avec une approche sharded et progressive. Les auteurs notent que les LLM génèrent souvent des réponses trop longues et continuent à s’appuyer sur leurs propres connaissances même après que ces connaissances ont été révélées incorrectes ou non pertinentes. Cette tendance, combinée à d’autres facteurs, peut causer au système de perdre la trace de l’échange entièrement.

En fait, les chercheurs notent ce que beaucoup d’entre nous ont découvert de manière anecdotique – que la meilleure façon de ramener la conversation sur les rails est de commencer une nouvelle conversation avec le LLM.

‘Si une conversation avec un LLM n’a pas conduit aux résultats attendus, commencer une nouvelle conversation qui répète les mêmes informations pourrait conduire à de meilleurs résultats que la poursuite d’une conversation en cours.

‘Ceci est dû au fait que les LLM actuels peuvent se perdre dans la conversation, et nos expériences montrent que persister dans une conversation avec le modèle est inefficace. De plus, puisque les LLM génèrent du texte avec aléatoire, une nouvelle conversation peut conduire à de meilleurs résultats.’

Les auteurs reconnaissent que les systèmes agents tels que Autogen ou LangChain peuvent potentiellement améliorer les résultats en agissant comme des couches interprétatives entre l’utilisateur final et le LLM, ne communiquant avec le LLM que lorsqu’ils ont rassemblé suffisamment de réponses sharded pour coaguler en une seule requête cohérente (que l’utilisateur final ne sera pas exposé).

‘Un argument pourrait être avancé selon lequel les capacités multi-tours ne sont pas une fonctionnalité nécessaire des LLM, car elles peuvent être déléguées au cadre d’agent. En d’autres termes, avons-nous besoin d’un support natif multi-tour dans les LLM lorsque un cadre d’agent peut orchestrer les interactions avec les utilisateurs et exploiter les LLM uniquement en tant qu’opérateurs à tour unique ?…’

Mais après avoir testé la proposition à travers leur ensemble d’exemples, ils concluent:

‘[S’appuyer] sur un cadre d’agent pour traiter les informations pourrait être limitant, et nous soutenons que les LLM devraient prendre en charge nativement l’interaction multi-tour’

Cet article intéressant nouveau est intitulé LLM Get Lost In Multi-Turn Conversation, et provient de quatre chercheurs de MS Research et Salesforce,

Conversations fragmentées

La nouvelle méthode divise d’abord les instructions conventionnelles à tour unique en petits fragments, conçus pour être introduits à des moments clés pendant une interaction LLM, une structure qui reflète le style d’engagement exploratoire et aller-retour vu dans des systèmes tels que ChatGPT ou Google Gemini.

Chaque instruction originale est une invite autonome qui livre l’ensemble de la tâche en une seule fois, combinant une question de haut niveau, un contexte de support et des conditions pertinentes. La version sharded divise cela en plusieurs parties plus petites, avec chaque fragment ajoutant juste une pièce d’information:

Instructions appariées montrant (a) une invite complète livrée en un seul tour et (b) sa version sharded utilisée pour simuler une interaction multi-tour sous-spécifiée. Sémantiquement, chaque version livre la même charge informationnelle.

Le premier fragment introduit toujours l’objectif principal de la tâche, tandis que le reste fournit des détails de clarification. Ensemble, ils livrent le même contenu que l’invite originale, mais réparti naturellement sur plusieurs tours dans la conversation.

Chaque conversation simulée se déroule entre trois composants: l’assistant, le modèle sous évaluation ; l’utilisateur, un agent simulé avec accès à l’instruction complète sous forme de fragments ; et le système, qui supervise et évalue l’échange.

La conversation commence avec l’utilisateur révélant le premier fragment et l’assistant répondant librement. Le système classe ensuite la réponse dans l’une des plusieurs catégories, telles qu’une demande de clarification ou une tentative de réponse complète.

Si le modèle essaie de répondre, un composant distinct extrait juste la plage pertinente pour l’évaluation, en ignorant tout texte environnant. À chaque nouveau tour, l’utilisateur révèle un fragment supplémentaire, provoquant une autre réponse. L’échange se poursuit jusqu’à ce que le modèle obtienne la bonne réponse ou qu’il n’y ait plus de fragments à révéler:

Diagramme d’une simulation de conversation sharded, avec le modèle évalué mis en évidence en rouge.

Les premiers tests ont montré que les modèles demandaient souvent des informations qui n’avaient pas encore été partagées, les auteurs ont donc abandonné l’idée de révéler les fragments dans un ordre fixe. Au lieu de cela, un simulateur a été utilisé pour décider quel fragment révéler ensuite, en fonction de la façon dont la conversation se déroulait.

Le simulateur d’utilisateur, mis en œuvre à l’aide de GPT-4o-mini, a donc eu un accès complet à la fois à l’instruction complète et à l’historique de la conversation, chargé de décider, à chaque tour, quel fragment révéler ensuite, en fonction de la façon dont l’échange se déroulait.

Le simulateur d’utilisateur a également reformulé chaque fragment pour maintenir le flux conversationnel, sans altérer le sens. Cela a permis à la simulation de refléter le ‘donne-et-reçoit’ du dialogue réel, tout en préservant le contrôle sur la structure de la tâche.

Avant le début de la conversation, l’assistant n’est donné que les informations de base nécessaires pour compléter la tâche, telles qu’un schéma de base de données ou une référence d’API. Il n’est pas informé que les instructions seront divisées, et il n’est pas guidé vers une façon spécifique de gérer la conversation. Cela est fait intentionnellement: dans les conditions du monde réel, les modèles sont presque jamais informés qu’une invite sera incomplète ou mise à jour au fil du temps, et laisser de côté ce contexte aide la simulation à refléter la façon dont le modèle se comporte dans un contexte plus réaliste.

GPT-4o-mini a également été utilisé pour décider de la façon dont les réponses du modèle devraient être classées, et pour extraire les réponses finales de ces réponses. Cela a aidé la simulation à rester flexible, mais a introduit occasionnellement des erreurs: cependant, après avoir vérifié plusieurs centaines de conversations à la main, les auteurs ont constaté que moins de cinq pour cent avaient des problèmes, et moins de deux pour cent ont montré un changement de résultat en raison de ceux-ci, et ils ont considéré que c’était un taux d’erreur suffisamment faible dans les paramètres du projet.

Scénarios de simulation

Les auteurs ont utilisé cinq types de simulation pour tester le comportement du modèle dans différentes conditions, chaque variante étant une variation de la façon et du moment où les parties de l’instruction sont révélées.

Dans le paramètre Full, le modèle reçoit l’instruction complète en un seul tour. Cela représente le format de référence standard et sert de ligne de base pour les performances.

Le paramètre Sharded divise l’instruction en plusieurs parties et les livre une à une, simulant une conversation plus réaliste et sous-spécifiée. C’est le paramètre principal utilisé pour tester la façon dont les modèles gèrent les entrées multi-tours.

Dans le paramètre Concat, les fragments sont réunis en une seule liste, en préservant leur formulation mais en supprimant la structure tour par tour. Cela aide à isoler les effets de la fragmentation conversationnelle de la rephrasation ou de la perte de contenu.

Le paramètre Recap fonctionne comme Sharded, mais ajoute un tour final où tous les fragments précédents sont répétés avant que le modèle ne donne une réponse finale. Cela teste si une invite de résumé peut aider à récupérer le contexte perdu.

Enfin, Snowball va plus loin en répétant tous les fragments précédents à chaque tour, en gardant l’instruction complète visible au fur et à mesure que la conversation se déroule – et en offrant un test plus indulgent de la capacité multi-tour.

Types de simulation basés sur des instructions sharded. Une invite complète est divisée en parties plus petites, qui peuvent ensuite être utilisées pour simuler soit des conversations à tour unique (Full, Concat) soit des conversations multi-tours (Sharded, Recap, Snowball), en fonction de la rapidité avec laquelle les informations sont révélées.

Tâches et métriques

Six tâches de génération ont été choisies pour couvrir à la fois les domaines de programmation et de langage naturel: les invites de génération de code provenaient de HumanEval et LiveCodeBench ; les requêtes Text-to-SQL provenaient de Spider ; les appels d’API ont été construits à l’aide de données du Berkeley Function Calling Leaderboard ; les problèmes mathématiques élémentaires ont été fournis par GSM8K ; les tâches de légendage de tableau ont été basées sur ToTTo ; et les résumés de plusieurs documents ont été tirés du Summary of a Haystack dataset.

Les performances du modèle ont été mesurées à l’aide de trois métriques de base: performance moyenne, aptitude et fiabilité.

Performance moyenne a capturé la façon dont un modèle se comportait globalement sur plusieurs tentatives ; aptitude a reflété les meilleurs résultats qu’un modèle pouvait atteindre, basés sur ses sorties à score élevé ; et fiabilité a mesuré à quel point ces résultats variaient, avec des écarts plus importants entre les meilleurs et les pires résultats indiquant un comportement moins stable.

Tous les scores ont été placés sur une échelle de 0 à 100 pour assurer la cohérence à travers les tâches, et les métriques ont été calculées pour chaque instruction – puis moyennées pour fournir une image globale des performances du modèle.

Six tâches sharded utilisées dans les expériences, couvrant à la fois la programmation et la génération de langage naturel. Chaque tâche est présentée avec une instruction complète et sa version sharded. Entre 90 et 120 instructions ont été adaptées à partir de références établies pour chaque tâche.

Candidats et tests

Dans les simulations initiales (avec un coût estimé de 5 000 $), 600 instructions couvrant six tâches ont été sharded et utilisées pour simuler trois types de conversations: full, concat et sharded. Pour chaque combinaison de modèle, d’instruction et de type de simulation, dix conversations ont été exécutées, produisant plus de 200 000 simulations au total – un schéma qui a permis de capturer à la fois les performances globales et des mesures plus approfondies d’aptitude et de fiabilité.

Quinze modèles ont été testés, couvrant une large gamme de fournisseurs et d’architectures: les modèles OpenAI GPT-4o (version 2024-11-20), GPT-4o-mini (2024-07-18), GPT-4.1 (2025-04-14), et le modèle de réflexion o3 (2025-04-16).

Les modèles Anthropic étaient Claude 3 Haiku (2024-03-07) et Claude 3.7 Sonnet (2025-02-19), accessibles via Amazon Bedrock.

Google a contribué Gemini 2.5 Flash (preview-04-17) et Gemini 2.5 Pro (preview-03-25). Les modèles Meta étaient Llama 3.1-8B-Instruct et Llama 3.3-70B-Instruct, ainsi que Llama 4 Scout-17B-16E, via Together AI.

Les autres entrées étaient OLMo 2 13B, Phi-4, et Command-A, tous accessibles localement via Ollama ou Cohere API ; et Deepseek-R1, accessible via Amazon Bedrock.

Pour les deux modèles de ‘réflexion’ (o3 et R1), les limites de jeton ont été augmentées à 10 000 pour accommoder des chaînes de raisonnement plus longues:

Scores de performance moyenne pour chaque modèle sur six tâches: code, base de données, actions, données vers texte, mathématiques et résumé. Les résultats sont présentés pour trois types de simulation: full, concat et sharded. Les modèles sont classés par leur score full moyen. L’ombrage reflète le degré de chute de performance par rapport au paramètre full, avec les deux dernières colonnes signalant les baisses moyennes pour concat et sharded par rapport à full.

En ce qui concerne ces résultats, les auteurs déclarent^†:

‘Au niveau supérieur, chaque modèle voit ses performances se dégrader sur chaque tâche lors de la comparaison des performances FULL et SHARDED, avec une dégradation moyenne de -39%. Nous nommons ce phénomène Lost in Conversation: les modèles qui atteignent des performances exceptionnelles (90%+) dans le cadre de référence d’une conversation à tour unique et complètement spécifiée luttent sur les mêmes tâches dans un cadre plus réaliste lorsque la conversation est sous-spécifiée et multi-tour.’

Concat scores moyens étaient de 95% de full, indiquant que la chute de performance dans le paramètre sharded ne peut pas être expliquée par une perte d’informations. Les modèles plus petits tels que Llama3.1-8B-Instruct, OLMo-2-13B et Claude 3 Haiku ont montré une dégradation plus prononcée sous concat, suggérant que les modèles plus petits sont généralement moins robustes à la rephrasation que les plus grands.

Les auteurs observent^†:

‘Étonnamment, les modèles les plus performants (Claude 3.7 Sonnet, Gemini 2.5, GPT-4.1) se perdent autant dans la conversation que les modèles plus petits (Llama3.1-8B-Instruct, Phi-4), avec des dégradations moyennes de 30-40%. Cela est en partie dû aux définitions de métriques. Puisque les modèles plus petits atteignent des scores absolus plus bas dans FULL, ils ont moins de marge pour la dégradation que les meilleurs modèles.

‘En bref, quelle que soit la force des performances à tour unique d’un LLM, nous observons de grandes dégradations de performance dans le paramètre multi-tour.’

Le test initial indique que certains modèles ont mieux résisté à certaines tâches: Command-A sur les actions, Claude 3.7 Sonnet et GPT-4.1 sur le code ; et Gemini 2.5 Pro sur les données vers texte, indiquant que la capacité multi-tour varie selon le domaine. Les modèles de raisonnement tels que o3 et Deepseek-R1 n’ont pas obtenu de meilleurs résultats globaux, peut-être parce que leurs réponses plus longues introduisaient plus d’hypothèses, qui tendaient à confondre la conversation.

Fiabilité

La relation entre l’aptitude et la fiabilité, claire dans les simulations à tour unique, semble se défaire dans les conditions multi-tours. Alors que l’aptitude ne chute que modestement, la fiabilité doubles en moyenne. Les modèles qui étaient stables dans les invites complètes, tels que GPT-4.1 et Gemini 2.5 Pro, sont devenus tout aussi erratiques que les modèles plus faibles comme Llama3.1-8B-Instruct ou OLMo-2-13B une fois l’instruction fragmentée.

Vue d’ensemble de l’aptitude et de la fiabilité, présentée sous forme de boîte à moustaches (a), suivie des résultats de fiabilité issus d’expériences avec quinze modèles (b), et des résultats du test de sharding progressif où les instructions ont été divisées en un à huit fragments (c).

Les réponses du modèle variaient souvent de jusqu’à 50 points sur la même tâche, même lorsque rien de nouveau n’était ajouté, suggérant que la chute de performance n’était pas due à un manque de compétence, mais à ce que le modèle devenait de plus en plus instable au fil des tours.

L’article indique^†:

‘[Bien que] les meilleurs modèles aient tendance à avoir une aptitude multi-tour légèrement plus élevée, tous les modèles ont tendance à avoir des niveaux de fiabilité similaires. En d’autres termes, en multi-tour, dans des paramètres sous-spécifiés, tous les modèles que nous testons présentent une fiabilité très élevée, avec une performance qui se dégrade de 50 points en moyenne entre la meilleure et la pire exécution simulée pour une instruction fixe.’

Pour tester si la dégradation des performances était liée au nombre de tours, les auteurs ont mené une expérience de sharding progressif, divisant chaque instruction en un à huit fragments (voir colonne la plus à droite de l’image ci-dessus).

À mesure que le nombre de fragments augmentait, la fiabilité a augmenté de manière constante, confirmant que même de légères augmentations du nombre de tours rendaient les modèles plus instables. L’aptitude est restée principalement inchangée, renforçant que le problème réside dans la cohérence, et non dans la capacité.

Contrôle de la température

Un ensemble distinct d’expériences a testé si la fiabilité était simplement un sous-produit de l’aléatoire. Pour cela, les auteurs ont varié le paramètre de température de l’assistant et du simulateur d’utilisateur sur trois valeurs: 1,0, 0,5 et 0,0.

Dans les formats à tour unique comme full et concat, la réduction de la température de l’assistant a amélioré de manière significative la fiabilité, réduisant la variation de jusqu’à 80 pour cent ; mais dans le paramètre sharded, la même intervention a eu peu d’effet:

Scores de fiabilité pour différentes combinaisons de température d’assistant et d’utilisateur sur les paramètres full, concat et sharded, avec des valeurs plus basses indiquant une cohérence de réponse plus élevée.

Même lorsque l’assistant et l’utilisateur étaient tous deux réglés à une température nulle, la fiabilité est restée élevée, avec GPT-4o montrant une variation d’environ 30 pour cent, suggérant que l’instabilité observée dans les conversations multi-tours n’est pas simplement du bruit stochastique, mais une faiblesse structurelle dans la façon dont les modèles gèrent les entrées fragmentées.

Implications

Les auteurs écrivent sur les implications de leurs découvertes à une longueur inhabituelle à la conclusion de l’article, soutenant que de fortes performances à tour unique ne garantissent pas la fiabilité multi-tour, et mettant en garde contre une confiance excessive dans les références complètement spécifiées lors de l’évaluation de la préparation au monde réel (puisqu’une telle référence masque l’instabilité dans les interactions plus naturelles et fragmentées).

Ils suggèrent également que la fiabilité n’est pas simplement un artifact d’échantillonnage, mais une limitation fondamentale de la façon dont les modèles actuels traitent les entrées en évolution, et ils soutiennent que cela soulève des préoccupations pour les cadres d’agent, qui dépendent d’une raison soutenue à travers les tours.

Enfin, ils soutiennent que la capacité multi-tour devrait être traitée comme une capacité de base des LLM, et non comme quelque chose qui peut être délégué à des systèmes externes.

Les auteurs notent que leurs résultats sous-estiment probablement l’ampleur réelle du problème, et attirent l’attention sur les conditions idéales du test: le simulateur d’utilisateur dans leur dispositif avait un accès complet à l’instruction et pouvait révéler les fragments dans un ordre optimal, ce qui donnait à l’assistant un contexte irréaliste (dans l’utilisation réelle, les utilisateurs fournissent souvent des invites fragmentées ou ambiguës sans savoir ce dont le modèle a besoin pour répondre).

De plus, l’assistant a été évalué immédiatement après chaque tour, avant que la conversation complète ne se déroule, empêchant ainsi toute confusion ou auto-contradiction ultérieure d’être pénalisée, ce qui aurait autrement détérioré les performances. Ces choix, bien que nécessaires pour le contrôle expérimental, signifient que les écarts de fiabilité observés dans la pratique sont susceptibles d’être encore plus importants que ceux rapportés.

Ils concluent:

‘[Nous] croyons que les simulations menées représentent un terrain de test bénin pour les capacités multi-tours des LLM. Puisque les conditions de simulation sont excessivement simplifiées, nous croyons que la dégradation observée dans les expériences est probablement une sous-estimation de la fiabilité des LLM, et de la fréquence à laquelle les LLM se perdent dans la conversation dans les paramètres du monde réel.‘

Conclusion

Quiconque a passé un temps significatif avec un LLM reconnaîtra probablement les problèmes formulés ici, issus de l’expérience pratique ; et la plupart d’entre nous, je suppose, ont intuitivement abandonné les conversations ‘perdues’ de LLM pour en commencer de nouvelles, dans l’espoir que le LLM puisse ‘recommencer’ et cesser de s’obséder sur le matériel qui est apparu dans un long et de plus en plus frustrant échange.

Il est intéressant de noter que jeter plus de contexte sur le problème peut ne pas nécessairement le résoudre ; et qu’en effet, on observe que l’article soulève plus de questions qu’il n’apporte de réponses (excepté en termes de façons de contourner le problème).

* Confusément, cela n’est pas lié à la signification conventionnelle de ‘sharding’ en IA.

† Emphases de bold des auteurs.

Publié pour la première fois lundi 12 mai 2025