Pourquoi les modèles de langage se « perdent » dans la conversation

Un nouveau document de recherche de Microsoft Research et Salesforce constate que même les modèles de langage les plus capables (LLM) se décomposent lorsqu’ils reçoivent des instructions par étapes plutôt que toutes à la fois. Les auteurs ont constaté que les performances chutent en moyenne de 39 pour cent 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) constate que même les modèles LLM les plus performants perdent l’impulsion effective dans une conversation. Source : https://arxiv.org/pdf/2505.06120

De manière plus frappante, la fiabilité des réponses prend un plongeon, avec des modèles prestigieux tels que ChatGPT-4.1 et Gemini 2.5 Pro qui oscillent entre des réponses presque parfaites et des échecs manifestes, en fonction de la manière 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, le document introduit une méthode appelée sharding*, qui divise les invites entièrement spécifiées en fragments plus petits et les libère un à la fois dans une conversation.

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

Deux versions extrêmes d’une conversation dans un restaurant (non issues du nouveau document, à 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 les aborder – apparemment une manière rationnelle et raisonnable d’aborder une tâche.

Ce dispositif est reflété dans la nouvelle méthode de sharding de l’interaction LLM. Les auteurs notent que les LLM génèrent souvent des réponses trop longues et continuent de s’appuyer sur leurs propres idées même après que ces idées ont été prouvé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 constaté de manière anecdotique – que la meilleure façon d’amener la conversation sur la bonne voie 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 peut conduire à de meilleurs résultats que la poursuite d’une conversation en cours.

‘C’est parce 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 shardées pour coaguler en une seule requête cohérente (que l’utilisateur final ne sera pas exposé).

Cependant, les auteurs soutiennent qu’une couche d’abstraction distincte ne devrait pas être nécessaire, ou devrait être intégrée directement dans le LLM source :

‘Un argument pourrait être fait que les capacités multi-tours ne sont pas une fonctionnalité nécessaire des LLM, car elles peuvent être déchargées sur le cadre de l’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 de manière native l’interaction multi-tour’

Ce document intéressant nouveau s’intitule 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 morceaux, 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 d’origine est une invite unique, autonome, qui livre l’ensemble de la tâche en une seule fois, combinant une question de haut niveau, un contexte de soutien et des conditions pertinentes. La version shardée la divise en plusieurs parties plus petites, avec chaque shard ajoutant juste une pièce d’information :

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

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

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

La conversation commence avec l’utilisateur révélant le premier shard et l’assistant répondant librement. Le système classe alors cette 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 fait une tentative de réponse, un composant distinct extrait juste la partie pertinente pour l’évaluation, en ignorant tout texte environnant. À chaque nouveau tour, l’utilisateur révèle un shard 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 shards à révéler :

Schéma de simulation de conversation shardée, avec le modèle évalué mis en évidence en rouge.

Des tests précoces 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 shards dans un ordre fixe. Au lieu de cela, un simulateur a été utilisé pour décider quel shard révéler ensuite, en fonction de la manière 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’ensemble de l’instruction et à l’historique de la conversation, chargé de décider, à chaque tour, quel shard révéler ensuite, en fonction de la manière dont l’échange se déroulait.

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

Avant que la conversation ne commence, l’assistant n’a reçu 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 ne lui a pas été indiqué que les instructions seraient fragmentées, et il n’a pas été guidé vers une manière spécifique de gérer la conversation. Cela a été 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 manière dont le modèle se comporte dans un contexte plus réaliste.

GPT-4o-mini a également été utilisé pour décider de la manière 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érents contextes, chaque scénario étant une variation de la manière 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’ensemble de l’instruction en un seul tour. Cela représente le format de référence standard et sert de référence de performance.

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

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

Le paramètre Recap fonctionne comme Sharded, mais ajoute un tour final où tous les shards 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 shards précédents à chaque tour, en gardant l’ensemble de l’instruction visible à 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 invites shardées. Une invite entièrement spécifiée 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 provenaient de GSM8K ; les tâches de légendage de tableaux étaient basées sur ToTTo ; et les résumés de plusieurs documents provenaient du jeu de données Summary of a Haystack.

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

La performance moyenne a capturé la manière dont un modèle se comportait globalement sur plusieurs tentatives ; l’aptitude a reflété les meilleurs résultats qu’un modèle pouvait atteindre, sur la base de ses sorties à haute notation ; et la 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 shardées 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 entièrement spécifiée et sa version shardée. Entre 90 et 120 instructions ont été adaptées à partir de références établies pour chaque tâche.

Concurrents et tests

Dans les simulations initiales (avec un coût estimé à 5 000 $), 600 instructions couvrant six tâches ont été shardées 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 jetons 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 moyen dans le paramètre full. L’ombrage reflète le degré de chute de performance par rapport au paramètre full, avec les deux dernières colonnes rapportant les baisses moyennes pour concat et sharded par rapport à full.

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

‘Au niveau le plus élevé, chaque modèle voit ses performances se dégrader sur chaque tâche lorsqu’on compare les performances FULL et SHARDED, avec une dégradation moyenne de -39 %. Nous appelons ce phénomène Lost in Conversation : les modèles qui atteignent des performances étoilées (90 %+) dans le cadre de référence de conversations à tour unique et entièrement spécifiées luttent sur les mêmes tâches dans un contexte plus réaliste lorsque la conversation est sous-spécifiée et multi-tour.’

Concat scores ont en moyenne 95 pour cent 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 face à la reformulation 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 de dégradation que les meilleurs modèles.

‘En bref, peu importe à quel point les performances à tour unique d’un LLM sont fortes, nous observons de grandes dégradations de performances dans le paramètre multi-tour.’

Le test initial indique que certains modèles tiennent mieux dans des tâches spécifiques : 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 ne se comportent pas mieux dans l’ensemble, peut-être parce que leurs réponses plus longues introduisaient plus d’hypothèses, qui avaient tendance à 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 décline que modestement, la fiabilité doubles en moyenne. Les modèles qui étaient stables dans les invites à format plein, 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 que l’instruction a été fragmentée.

Vue d’ensemble de l’aptitude et de la fiabilité, présentée dans un graphique en boîte (a), suivie des résultats de fiabilité des 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 shards (c).

Les réponses des modèles variaient souvent d’autant que 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 à travers les tours.

Le document déclare^† :

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

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

À mesure que le nombre de shards augmentait, la fiabilité augmentait régulièrement, confirmant que même des augmentations mineures du nombre de tours rendaient les modèles plus instables. L’aptitude est restée en grande partie inchangée, renforçant que le problème réside dans la cohérence, et non dans la capacité.

Contrôle de température

Un ensemble distinct d’expériences a testé si la fiabilité était simplement un sous-produit de l’aléatoire. Pour ce faire, les auteurs ont varié le paramètre de température des deux l’assistant et le 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 de simulateur d’utilisateur à travers les paramètres full, concat et sharded, avec des valeurs plus basses indiquant une plus grande cohérence de réponse.

Même lorsque l’assistant et le simulateur d’utilisateur étaient tous deux réglés sur 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 juste du bruit stochastique, mais une faiblesse structurelle dans la manière dont les modèles gèrent les entrées fragmentées.

Implications

Les auteurs écrivent longuement sur les implications de leurs découvertes à la conclusion du document, 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 entièrement 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 des interactions plus naturelles et fragmentées).

Ils suggèrent également que la fiabilité n’est pas juste un artifact d’échantillonnage, mais une limitation fondamentale de la manière dont les modèles actuels traitent les entrées évolutives, et ils soulignent que cela soulève des préoccupations pour les cadres d’agent, qui dépendent d’une raison prolongée à 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échargé sur 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 shards dans un ordre optimal, ce qui donnait à l’assistant un contexte favorable (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 comprendre).

De plus, l’assistant a été évalué immédiatement après chaque tour, avant que la conversation entière ne se déroule, empêchant ainsi toute confusion ou auto-contradiction ultérieure de pénaliser les performances, ce qui aurait autrement empiré les résultats.

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. En raison des conditions de simulation 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 abandonné des conversations LLM ‘perdues’ 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 tortueux échange de plus en plus frustrant.

Il est intéressant de noter que jeter plus de contexte sur le problème peut ne pas nécessairement le résoudre ; et en fait, observer que le document pose plus de questions qu’il n’apporte de réponses (sauf en termes de moyens de contourner le problème).

* De manière confuse, cela n’est pas lié à la signification conventionnelle de ‘sharding’ en IA.

† Les auteurs mettent eux-mêmes l’accent sur ces points.

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