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

Un nouveau document de Microsoft Research et Salesforce révèle que même les plus compétents grands modèles linguistiques (Les LLM) s'effondrent lorsque des instructions sont données dans stages plutôt que d'un seul coup. Les auteurs ont constaté que les performances chutent en moyenne de 39 % sur six tâches lorsqu'une invite est réparti sur plusieurs tours:

Une conversation à un tour (à gauche) donne les meilleurs résultats, mais est peu naturelle pour l'utilisateur final. Une conversation à plusieurs tours (à droite) fait perdre l'élan nécessaire même aux LLM les mieux classés et les plus performants. Source : https://arxiv.org/pdf/2505.06120

Plus frappant encore, le fiabilité des réponses chutent, avec des modèles prestigieux tels que ChatGPT-4.1 et Gémeaux 2.5 Pro oscillant entre des réponses presque parfaites et des échecs manifestes, selon la manière dont la même tâche est formulée ; en outre, la cohérence des résultats peut chuter de plus de moitié au cours du processus.

Pour explorer ce comportement, l’article présente une méthode appelée sharding*, qui divise les invites entièrement spécifiées en fragments plus petits et les libère une par une dans une conversation.

En termes simples, cela revient à donner une commande unique, cohérente et complète dans un restaurant, laissant le serveur sans autre chose à faire que d'accepter la demande ; ou bien de décider d'attaquer le problème de manière collaborative :

Deux versions extrêmes d'une conversation au restaurant (non tirées du nouveau journal, à titre d'illustration uniquement).

Pour souligner le propos, l'exemple ci-dessus présente peut-être le client sous un jour négatif. Mais l'idée centrale illustrée dans la deuxième colonne est celle d'un échange transactionnel qui clarifie un problème avant de le résoudre – une approche apparemment rationnelle et raisonnable d'une tâche.

Cette configuration se reflète dans le goutte-à-goutte de la nouvelle œuvre, fragmenté Approche de l'interaction avec les LLM. Les auteurs constatent que les LLM génèrent souvent des réponses trop longues et continuent ensuite de s'appuyer sur leurs propres connaissances. même après que ces informations se soient avérées incorrectes ou non pertinentesCette tendance, combinée à d’autres facteurs, peut amener le système à perdre complètement la trace de l’échange.

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

« Si une conversation avec un LLM n’a pas conduit aux résultats escomptés, démarrer une nouvelle conversation qui répète les mêmes informations pourrait donner des résultats nettement meilleurs que de poursuivre une conversation en cours.

« Cela s'explique par le 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, comme les LLM génèrent du texte aléatoire, une nouvelle conversation peut conduire à de meilleurs résultats. »

Les auteurs reconnaissent que les systèmes agentiques tels que autogène or LangChaîne peut potentiellement améliorer les résultats en agissant comme des couches interprétatives entre l'utilisateur final et le LLM, en ne communiquant avec le LLM que lorsqu'il a rassemblé suffisamment de réponses « fragmentées » pour les coaguler en une seule requête cohérente (à laquelle l'utilisateur final ne sera pas exposé).

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

On pourrait soutenir que les capacités multi-tours ne sont pas indispensables aux LLM, car elles peuvent être déportées vers l'infrastructure d'agent. Autrement dit, avons-nous besoin d'une prise en charge multi-tours native dans les LLM alors qu'une infrastructure d'agent peut orchestrer les interactions avec les utilisateurs et exploiter les LLM uniquement comme des opérateurs mono-tour ?…

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

« [S'appuyer] sur un cadre de type agent pour traiter les informations pourrait être limitatif, et nous pensons que les LLM devraient prendre en charge nativement l'interaction multi-tours »

Cette intéressante nouveau papier est intitulé Les LLM se perdent dans des conversations à plusieurs tours, et provient de quatre chercheurs de MS Research et Salesforce,

Conversations fragmentées

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

Chaque instruction originale est une invite unique et autonome qui exécute la tâche dans son intégralité en une seule fois, combinant une question générale, un contexte et toutes les conditions pertinentes. La version fragmentée décompose cette tâche en plusieurs parties plus petites, chaque fragment n'ajoutant qu'une seule information :

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

Le premier fragment présente toujours l'objectif principal de la tâche, tandis que les autres apportent des précisions. Ensemble, ils reprennent le même contenu que l'invite initiale, mais s'étalent naturellement sur plusieurs tours de conversation.

Chaque conversation simulée se déroule entre trois composants : le assistant, le modèle en cours d'évaluation ; le utilisateur, un agent simulé avec accès à l'instruction complète sous forme fragmentée ; et le Système, qui surveille et note l'échange.

La conversation débute lorsque l'utilisateur révèle le premier fragment et que l'assistant répond librement. Le système classe ensuite cette réponse en plusieurs catégories, par exemple : demande de clarification tentative de réponse complète.

Si le modèle cela Lorsqu'un joueur tente une réponse, un composant distinct extrait uniquement la partie pertinente pour l'évaluation, ignorant le texte environnant. À chaque tour, l'utilisateur révèle un fragment supplémentaire, provoquant une nouvelle réponse. L'échange se poursuit jusqu'à ce que le modèle obtienne la bonne réponse ou qu'il ne reste plus de fragments à révéler :

Diagramme d'une simulation de conversation fragmentée, avec le modèle évalué surligné 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. Un simulateur a été utilisé pour décider quel fragment révéler ensuite, en fonction du déroulement de la conversation.

Le simulateur utilisateur, implémenté à l'aide de GPT-4o-mini, a donc eu un accès complet à la fois à l'intégralité de l'instruction et à l'historique des conversations, chargé de décider, à chaque tour, quel fragment révéler ensuite, en fonction du déroulement de l'échange.

Le simulateur d'utilisateur également reformulé Chaque fragment permet de maintenir le flux conversationnel sans en altérer le sens. Cela permet à la simulation de refléter les échanges d'un dialogue réel, tout en préservant le contrôle de la structure de la tâche.

Avant le début de la conversation, l'assistant ne reçoit que les informations de base nécessaires à la réalisation de la tâche, comme un schéma de base de données ou une référence d'API. Il n'est pas indiqué que les instructions seront fragmentées et aucune méthode spécifique de gestion de la conversation n'est indiquée. Ceci est intentionnel : en situation réelle, les modèles ne sont presque jamais informés qu'une invite sera incomplète ou mise à jour au fil du temps, et l'omission de ce contexte permet à la simulation de refléter le comportement du modèle dans un contexte plus réaliste.

GPT-4o-mini a également été utilisé pour déterminer la classification des réponses du modèle et en extraire les réponses finales. Cela a permis à la simulation de rester flexible, mais a introduit des erreurs occasionnelles : après avoir vérifié manuellement plusieurs centaines de conversations, les auteurs ont constaté que moins de XNUMX % présentaient des problèmes et que moins de XNUMX % affichaient un changement de résultat, ce qui constituait un taux d'erreur suffisamment faible dans le cadre 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, chacune étant une variation sur la manière et le moment où des parties de l'instruction sont révélées.

Dans l' Full Le modèle reçoit l'intégralité de l'instruction en un seul tour. Ce format de référence standard sert de référence de performance.

L'espace Éclaté Ce paramètre décompose l'instruction en plusieurs parties et les transmet une à une, simulant ainsi une conversation plus réaliste et simplifiée. Il s'agit du paramètre principal utilisé pour tester la capacité des modèles à gérer les entrées multitours.

Dans l' Concaténer Dans ce cas, les fragments sont reconstitués en une seule liste, préservant leur formulation mais supprimant la structure tour par tour. Cela permet d'isoler les effets de la fragmentation conversationnelle, de la reformulation ou de la perte de contenu.

L'espace RECAP le réglage fonctionne comme Éclaté, mais ajoute un tour final où tous les fragments précédents sont réitérés avant que le modèle ne donne une réponse finale. Cela permet de tester si une invite récapitulative peut aider à retrouver le contexte perdu.

Enfin, des Snowball va plus loin, en répétant tous les éclats 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é à effectuer plusieurs tours.

Types de simulation basés sur des instructions fragmentées. Une invite entièrement spécifiée est divisée en parties plus petites, qui peuvent ensuite être utilisées pour simuler des conversations à un tour (complètes, concaténées) ou à plusieurs tours (fragmentées, récapitulatives, boule de neige), selon 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 la programmation et du langage naturel : les invites de génération de code ont été tirées de HumanEval et LiveCodeBench; Les requêtes texte-SQL proviennent de Spider; Les appels API ont été construits à l'aide de données provenant du Classement des appels de fonctions à Berkeley; des problèmes mathématiques élémentaires ont été fournis par GSM8K; les tâches de sous-titrage tabulaire étaient basées sur ToTTo; et des résumés multi-documents ont été tirés des Résumé d'une botte de foin jeu de données.

Les performances du modèle ont été mesurées à l’aide de trois indicateurs principaux : performances moyennes, aptitude et manque de fiabilité.

Performance moyenne a capturé les performances globales d’un modèle à travers plusieurs tentatives ; aptitude reflétait les meilleurs résultats qu'un modèle pouvait atteindre, en fonction de ses résultats les plus performants ; et manque de fiabilité ont mesuré dans quelle mesure ces résultats variaient, les é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 garantir la cohérence entre les tâches, et les mesures ont été calculées pour chaque instruction, puis moyennées pour fournir une image globale des performances du modèle.

Six tâches fragmentées ont été 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 fragmenté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 (d'un coût estimé à 5000 600 $), XNUMX instructions couvrant six tâches ont été fragmentées et utilisées pour simuler trois types de conversation : plein, concat et fragmentéPour chaque combinaison de modèle, d’instruction et de type de simulation, dix conversations ont été menées, produisant plus de 200,000 XNUMX 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 un large éventail 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 pensée o3 (2025-04-16).

Les modèles anthropiques étaient Claude 3 Haïku (2024-03-07) et Claude 3.7 Sonnet (2025-02-19), accessible via Amazon Bedrock.

Google a contribué Gémeaux 2.5 Flash (aperçu-04-17) et Gémeaux 2.5 Pro (aperçu-03-25). Les méta-modèles étaient Lama 3.1-8B-Instruct et Lama 3.3-70B-Instruct, aussi bien que Llama 4 Scout-17B-16E, via Together AI.

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

Pour les deux 'pensée' modèles (o3 et R1), limites des jetons ont été augmentés à 10,000 XNUMX pour s'adapter à des chaînes de raisonnement plus longues :

Scores de performance moyens pour chaque modèle sur six tâches : code, base de données, actions, conversion de données en texte, mathématiques et synthèse. Les résultats sont présentés pour trois types de simulation : complète, concaténée et fragmentée. Les modèles sont classés selon leur score moyen en configuration complète. L'ombrage reflète le degré de baisse de performance par rapport à la configuration complète, les deux dernières colonnes indiquant les baisses moyennes pour les simulations concaténées et fragmentées par rapport à la configuration complète.

Concernant ces résultats, les auteurs déclarent^†:

« À un niveau élevé, chaque modèle voit ses performances se dégrader à chaque tâche lorsque l'on compare les performances FULL et SHARDED, avec une dégradation moyenne de -39 %. Nous appelons ce phénomène Perdu dans la conversation: les modèles qui atteignent des performances exceptionnelles (plus de 90 %) dans le cadre d'une conversation à tour unique entièrement spécifiée, de type laboratoire, ont du mal à sur exactement les mêmes tâches dans un cadre plus réaliste lorsque la conversation est sous-spécifiée et à plusieurs tours.

Concaténer les scores étaient en moyenne de 95 pour cent de plein, ce qui indique que la baisse de performance dans le cadre fragmenté ne peut s'expliquer par une perte d'information. Des 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 dans le cadre fragmenté. concat, ce qui suggère que les modèles plus petits sont généralement moins robustes à la reformulation que les plus grands.

Les auteurs observent^†:

« Étonnamment, les modèles plus performants (Claude 3.7 Sonnet, Gemini 2.5, GPT-4.1) se perdent tout autant dans la conversation que les modèles plus petits (Llama3.1-8B-Instruct, Phi-4), avec des dégradations moyennes de 30 à 40 %. Ceci est en partie dû aux définitions des métriques. Étant donné que les modèles plus petits obtiennent des scores absolus plus faibles FULL, ils ont moins de possibilités de dégradation que les meilleurs modèles.

« En bref, quelle que soit la performance d’un LLM sur un seul tour, nous observons de grandes dégradations de performance dans le cadre multitours. »

Le test initial indique que certains modèles ont mieux résisté à des tâches spécifiques : Command-A pour les actions, Claude 3.7 Sonnet et GPT-4.1 pour le code ; et Gemini 2.5 Pro pour la conversion de données en texte, ce qui indique que la capacité à effectuer plusieurs tours varie selon le domaine. Les modèles de raisonnement tels que o3 et Deepseek-R1 n'ont pas obtenu de meilleurs résultats dans l'ensemble, peut-être parce que leurs réponses plus longues introduisaient davantage d'hypothèses, ce qui tendait à brouiller la conversation.

Fiabilité

La relation entre aptitude et fiabilité, évidente dans les simulations à un tour, semble s'effondrer dans des conditions à plusieurs tours. Si l'aptitude n'a que légèrement diminué, le manque de fiabilité Doublé en moyenne. Les modèles stables dans les invites plein format, 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.

Aperçu de l'aptitude et du manque de fiabilité tel qu'illustré dans un diagramme en boîte (a), suivi des résultats de fiabilité issus d'expériences avec quinze modèles (b) et des résultats du test de partitionnement progressif où les instructions ont été divisées en un à huit fragments (c).

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

Le document indique^†:

« [Bien que] les meilleurs modèles aient tendance à avoir une aptitude multi-tours légèrement supérieure, tous les modèles ont tendance à présenter des niveaux similaires de manque de fiabilité. En d'autres termes, dans des configurations multitours sous-spécifiées, tous les modèles que nous testons présentent un très haut niveau de fiabilité, avec des performances se dégradant de 50 points de pourcentage 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 mené une expérience de partitionnement progressif, en divisant chaque instruction en un à huit fragments (voir la colonne la plus à droite de l'image ci-dessus).

À mesure que le nombre de fragments augmentait, le manque de 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 pratiquement inchangée, ce qui renforce l'idée que le problème réside dans Réplicabilité, pas la capacité.

Contrôle de la température

Une série d'expériences distinctes a permis de vérifier si le manque de fiabilité était simplement une conséquence du caractère aléatoire. Pour ce faire, les auteurs ont fait varier la température de l'assistant et du simulateur utilisateur sur trois valeurs : 1.0, 0.5 et 0.0.

Dans des formats à un seul tour comme plein et concat, la réduction de la température de l'assistant a considérablement amélioré la fiabilité, réduisant les variations jusqu'à 80 pour cent ; mais dans le fragmenté contexte, la même intervention a eu peu d’effet :

Scores de non-fiabilité pour différentes combinaisons de température de l'assistant et de l'utilisateur dans les paramètres complets, concaténés et fragmentés, avec des valeurs inférieures indiquant une plus grande cohérence de réponse.

Même lorsque l'assistant et l'utilisateur étaient tous deux réglés sur une température zéro, le manque de fiabilité restait élevé, le GPT-4o présentant une variation d'environ 30 %, ce qui suggère que l'instabilité observée dans les conversations à plusieurs tours n'est pas seulement bruit stochastique, mais une faiblesse structurelle dans la façon dont les modèles gèrent les entrées fragmentées.

Implications

Les auteurs décrivent les implications de leurs résultats de manière inhabituellement longue dans la conclusion de l'article, affirmant que de solides performances sur un seul tour ne garantissent pas la fiabilité sur plusieurs tours, et mettant en garde contre une dépendance excessive à des repères entièrement spécifiés lors de l'évaluation de l'état de préparation au monde réel (puisque de tels repères masquent l'instabilité dans des interactions plus naturelles et fragmentées).

Ils suggèrent également que le manque de fiabilité n’est pas seulement un artefact d’échantillonnage, mais un limitation fondamentale dans la manière dont les modèles actuels traitent les entrées en évolution, et ils suggèrent que cela soulève des inquiétudes pour les cadres d'agents, qui dépendent d'un raisonnement soutenu à travers les tours.

Enfin, ils soutiennent que la capacité multi-tours devrait être considérée comme une capacité essentielle des LLM, et non comme quelque chose de délégué à des systèmes externes.

Les auteurs notent que leurs résultats sont probablement sous-estimer l'ampleur réelle du problème et attirer l'attention sur les conditions idéales du test : le simulateur utilisateur dans leur configuration avait un accès complet à l'instruction et pouvait révéler des fragments dans un ordre optimal, ce qui donnait à l'assistant un contexte irréaliste et favorable (dans le monde réel, les utilisateurs fournissent souvent des invites fragmentées ou ambiguës sans savoir ce que le modèle doit entendre ensuite).

De plus, l'assistant a été évalué immédiatement Après chaque tour, avant le déroulement complet de la conversation, évitant ainsi toute confusion ou contradiction ultérieure, qui dégraderait les performances. Ces choix, bien que nécessaires au contrôle expérimental, signifient que les écarts de fiabilité observés en pratique sont probablement encore plus importants que ceux rapportés.

Ils concluent:

« [Nous] pensons que les simulations menées représentent un terrain d’essai bénin pour les capacités multi-tours du LLM. En raison des conditions de simulation trop simplifiées, nous pensons que la dégradation observée dans les expériences est très probablement une sous-estimation du manque de fiabilité des LLM et de la fréquence à laquelle les LLM se perdent dans les conversations dans des contextes réels.»

Conclusion

Quiconque a passé beaucoup de temps avec un LLM reconnaîtra probablement les problèmes formulés ici, à partir de l'expérience pratique ; et la plupart d'entre nous, j'imagine, ont intuitivement abandonné les conversations LLM « perdues » pour de nouvelles, dans l'espoir que le LLM puisse « recommencer » et cesser d'être obsédé par le matériel qui est apparu dans un échange long, sinueux et de plus en plus exaspérant.

Il est intéressant de noter que le fait d’apporter plus de contexte au problème ne le résout pas nécessairement ; et en effet, d’observer que l’article soulève plus de questions qu’il n’apporte de réponses (sauf en termes de moyens de contourner le problème).

* De manière déroutante, cela n’a aucun rapport avec la signification conventionnelle de « sharding » en IA.

† Les auteurs mettent en valeur leurs propres mots.

Première publication le lundi 12 mai 2025