- Lorsque l’utilisateur ne peut pas formuler toutes ses exigences d’un seul coup, les performances de 15 LLM sur des instructions incomplètes à plusieurs tours chutent nettement par rapport à des instructions complètes en un seul tour : la moyenne sur 6 tâches génératives passe de 90 % à 65 %
- L’expérience est construite selon une méthode de sharding qui découpe les instructions de benchmarks existants en un seul tour en plusieurs fragments, de sorte que les conditions et le contexte se révèlent progressivement au fil de la conversation
- La baisse de performance tient davantage à une hausse de l’instabilité qu’à un simple manque de capacité ; sur plus de 200 000 conversations, les modèles s’appuient excessivement sur leurs hypothèses initiales et sur des tentatives de réponse finale trop précoces
- Les modèles testés vont de Llama3.1-8B-Instruct à Gemini 2.5 Pro, avec des tâches de programmation et de génération en langage naturel comme Code, Database, Actions, Math, Data-to-Text et Summary
- Même s’il s’agit d’une simulation simplifiée de conversations humain-IA réelles, toutes les conversations ont été conçues pour se terminer avec suffisamment d’informations pour résoudre la tâche ; la baisse observée pourrait donc être inférieure à celle de véritables conversations incomplètes à plusieurs tours
L’écart entre l’évaluation en un seul tour et l’usage conversationnel réel
- Les LLM sont utilisés via des interfaces conversationnelles comme ChatGPT, Gemini ou Claude, et les utilisateurs peuvent définir, explorer et modifier leurs besoins sur plusieurs tours même s’ils ne les spécifient pas entièrement dès le départ
- Les évaluations existantes des LLM se concentrent surtout sur des environnements à instruction complète en un seul tour, alors que l’incomplétude des consignes utilisateur est courante dans les journaux de conversations avec des LLM
- Beaucoup d’évaluations existantes à plusieurs tours ressemblent à une approche episodic, qui traite la conversation comme une suite de sous-tâches évaluables indépendamment
- Elles exigent parfois de comprendre le contexte entre les tours, mais diffèrent des situations où il faut combiner activement des informations issues d’instructions utilisateur incomplètes
- Ce type de tâche peut donner une image trop favorable des performances des LLM dans les conversations à plusieurs tours
Des conversations incomplètes à plusieurs tours créées par sharding
- L’expérience transforme des instructions complètes issues de benchmarks de haute qualité en sharded instructions
- Le premier shard présente l’intention générale de la tâche
- Les shards suivants fournissent un par un des conditions ou contextes supplémentaires de l’instruction originale
- L’ensemble des shards contient les mêmes informations que l’instruction complète originale
- Par exemple, dans le problème de boules de neige de GSM8K, l’énoncé en un seul bloc fournit toutes les conditions comme « produire 20 unités par heure », « en enregistrer 2 toutes les 15 minutes » et « en avoir 60 au total », tandis que la version sharded les dévoile séparément sur plusieurs tours
- Le processus de sharding a été réalisé de façon semi-automatique : GPT-4o a généré et validé des candidats, puis les chercheurs les ont relus et corrigés
Structure de la simulation de conversation
- La simulation à plusieurs tours comporte trois acteurs
- assistant évalué : le LLM dont on mesure les performances
- user simulator : un LLM qui connaît toute la sharded instruction et révèle le shard suivant à chaque tour
- system : composant qui classe les réponses de l’assistant et évalue les tentatives de réponse
- Au premier tour, le user simulator ne révèle que le premier shard, et l’assistant répond en texte libre
- La réponse de l’assistant est classée dans l’une de 7 stratégies
- clarification
- refusal
- hedging
- interrogation
- discussion
- missing
- answer attempt
- Lorsqu’elle est classée comme answer attempt, un answer extractor extrait la partie de la réponse nécessaire à l’évaluation, comme un morceau de code, un nombre ou du SQL, puis un evaluator propre à la tâche attribue un score
- La conversation s’arrête dans l’un des deux cas suivants
- la tentative de réponse de l’assistant est évaluée comme correcte
- il ne reste plus de shard à révéler au début d’un nouveau tour
- Le user simulator, le strategy classifier et l’answer extractor sont implémentés avec GPT-4o-mini sur la base de prompts
- Après annotation manuelle de plusieurs centaines de conversations, les erreurs du user simulator, du classifier et de l’extractor sont apparues dans moins de 5 % des conversations examinées, et les erreurs défavorables au modèle assistant dans moins de 2 %
Les cinq types de simulation comparés
- FULL est une simulation en un seul tour qui fournit l’instruction complète originale au premier tour ; elle sert de référence de performance de base
- SHARDED est une conversation incomplète à plusieurs tours où les shards sont révélés progressivement ; c’est l’environnement d’évaluation principal
- CONCAT fournit les shards combinés dans une instruction à puces en un seul tour
- Comme FULL, elle supprime l’incomplétude
- Comme SHARDED, elle conserve les reformulations introduites par le processus de sharding
- Si un modèle réussit avec FULL et CONCAT mais échoue avec SHARDED, la cause peut être le caractère incomplet et multi-tour lui-même plutôt qu’une perte d’information
- RECAP redonne tous les shards en une seule fois à la fin d’une conversation SHARDED afin d’offrir au LLM une dernière chance de répondre
- SNOWBALL répète à chaque tour le nouveau shard ainsi que tous les shards déjà révélés, fournissant ainsi un récapitulatif cumulatif à chaque tour
Tâches et benchmarks utilisés
- L’expérience comporte 6 tâches génératives couvrant à la fois des cas d’usage de programmation et de génération en langage naturel
- Pour chaque tâche, 90 à 120 sharded instructions ont été préparées, soit 600 instructions au total
- Composition des tâches :
- Code : écriture de fonctions Python à partir de HumanEval et LiveCodeBench
- Database : génération text-to-SQL à partir de Spider
- Actions : génération d’appels de fonctions API à partir du Berkeley Function Calling Leaderboard
- Math : résolution de problèmes mathématiques élémentaires en texte à partir de GSM8K
- Data-to-Text : génération de phrases décrivant des données tabulaires à partir de ToTTo
- Summary : résumé avec citations d’ensembles de documents à partir de Summary of a Haystack
- Les métriques d’évaluation réutilisent celles des benchmarks d’origine
- Code et Database utilisent une exactitude basée sur l’exécution
- Actions et Math utilisent l’équivalence sémantique avec la réponse de référence ou la bonne réponse numérique
- Data-to-Text utilise BLEU
- Summary utilise un « Joint Score » LLM-as-a-judge mesurant la couverture informationnelle et l’exactitude de l’attribution des sources
- Les exactitudes binaires sont également ramenées sur une échelle de 0 à 100 afin d’agréger les scores de toutes les tâches sur la même échelle
Mesure de la performance, de l’aptitude et de l’instabilité
- Les sorties des LLM étant probabilistes, chaque combinaison d’instruction et de type de simulation est exécutée N=10 fois
- Chaque exécution est évaluée par un score compris entre 0 et 100
- Trois indicateurs sont utilisés
- Performance moyenne P : moyenne des scores des exécutions répétées
- aptitude A90 : 90e percentile des scores, estimant la performance en meilleur cas sur les 10 % meilleures exécutions
- unreliability U90-10 : différence entre le 90e et le 10e percentile, mesurant l’écart entre le meilleur et le pire cas
- En un seul tour, les modèles avec une aptitude élevée avaient tendance à être plus fiables, mais en multi-tour, tous les LLM présentent une forte unreliability indépendamment de leur aptitude
Résultats de l’expérience à grande échelle
- L’expérience principale porte sur 600 instructions, 3 types de simulation (FULL, CONCAT, SHARDED) et 15 LLM
- Chaque combinaison est répétée 10 fois, simulant plus de 200 000 conversations
- Toutes les simulations sont menées avec une temperature par défaut T=1, l’effet de la temperature sur l’aptitude et la fiabilité étant traité dans une expérience auxiliaire séparée
- Globalement, la performance moyenne des conversations incomplètes à plusieurs tours est de 65 %, soit 25 points de moins que la performance en un seul tour avec instruction complète dès le départ, qui atteint 90 %
- La baisse de performance en multi-tour apparaît de façon générale, des petits modèles open-weight aux modèles les plus récents
- Les modèles testés incluent de petits modèles open-weight comme Llama3.1-8B-Instruct et des modèles récents comme Gemini 2.5 Pro
- La Figure 1 montre comme exemples Claude 3.7 Sonnet, Deepseek-R1, o3, GPT-4.1 et Gemini 2.5 Pro
- La baisse moyenne de performance sur les 6 tâches génératives est de 39 %, et la Figure 1 indique une dégradation d’environ -35 % dans le cadre multi-tour
Pourquoi les modèles se perdent
- La baisse de performance se décompose en deux facteurs
- Diminution de l’aptitude : la performance en meilleur cas baisse quelque peu
- Hausse de l’unreliability : l’écart de qualité entre exécutions augmente fortement
- D’après la Figure 1, en multi-tour, l’aptitude diminue de -15 % et l’unreliability augmente de +112 %
- Les modèles ont tendance à formuler de mauvaises hypothèses à partir des seules informations initiales incomplètes, puis à tenter une réponse finale trop tôt dans la conversation
- Même lorsque de nouvelles informations sont fournies ensuite, ils s’appuient excessivement sur leur tentative de réponse erronée précédente et échouent à corriger leur trajectoire
- Le phénomène où, dans une conversation incomplète à plusieurs tours, un modèle ne parvient pas à se rétablir après avoir pris une mauvaise direction est défini comme lost in conversation
Limites et implications pratiques
- Une simulation entièrement automatique ne représente pas telle quelle les conversations humain-IA réelles
- L’environnement expérimental est simplifié et idéalisé
- Il est garanti que la conversation se termine avec suffisamment d’informations pour résoudre la tâche
- Les comportements inattendus possibles en conditions réelles, comme une dérive de la conversation, sont limités
- En raison de cette conception, la baisse de performance observée pourrait sous-estimer celle qui se produit dans de véritables conversations humain-IA incomplètes à plusieurs tours
- Les organisations qui créent des produits conversationnels fondés sur les LLM, ainsi que les utilisateurs finaux, devraient évaluer la fiabilité multi-tour en plus des capacités en un seul tour
- Pour les utilisateurs débutants qui ont du mal à formuler des exigences complètes dès le départ, la baisse de performance en multi-tour pourrait freiner l’adoption des systèmes d’IA
1 commentaires
Avis sur Hacker News
C’est appréciable qu’un article confirme ce que toute personne ayant utilisé des outils LLM sait déjà empiriquement. Garder un contexte propre est important, et la « conversation » n’est qu’une construction créée par l’interface produit, qui nuit à la qualité des réponses du LLM lui-même. Une fois le contexte contaminé, il ne se rétablit pas : il faut repartir de zéro avec un nouveau chat.
Vers la fin des deux semaines, le LLM était devenu beaucoup moins dispersé et, même quand je lui donnais des fils de forum ou des posts Stack Overflow entiers, il savait distinguer : « ce n’est pas le phénomène observé ici, pour telle raison [liée au contexte ou aux découvertes précédentes] ». Je devais éliminer logiquement les impasses et le lui signaler, mais nous avons fini par trouver la cause.
Cela semble aussi cohérent avec l’idée que les LLM sont forts pour compresser des informations complexes en quelque chose de simple, et faibles pour étendre une idée simple en quelque chose de complexe. Quand l’entrée était plus grande ou plus complexe que la sortie, le résultat était satisfaisant.
J’aurais pu le faire sans LLM, mais il m’a aidé comme une sorte de dépôt quand j’avais oublié des faits fournis au début ou que je n’arrivais pas à les retrouver rapidement dans un nouveau contexte, et il a aussi été utile pour repérer des motifs temporels dans de gros fichiers de logs. Je n’ai pas seulement corrigé un problème : j’ai aussi optimisé plusieurs paramètres et beaucoup appris. Il se trompait parfois sur l’état actuel des paramètres, mais c’était facile à corriger. Si l’on sait où l’on va et qu’on le traite comme un outil, c’est utile ; il ne faut simplement pas lui déléguer la décision ni le laisser nous entraîner dans une mauvaise direction.
L’utilisation totale était d’environ 350k tokens. Un billet de blog lié se trouve ici : https://du.nkel.dev/blog/2021-11-19_pfsense_opnsense_ipsec_cgnat/, même s’il ne correspond pas directement à ce problème précis. Je décline les recommandations de WireGuard.
Il est très probable que quelqu’un ait récemment ajusté le prompt pour préciser un point de vue sur le génocide blanc ; pour un chatbot parfait, cela ne devrait pas compter quand on l’interroge sur un autre sujet, mais en réalité cela compte. Comme cela fait partie du contexte, il en parle désormais.
Cela ressemble à un aspect du problème bien connu de surconfiance et d’incapacité à l’introspection. Quand la probabilité a priori est trop faible, il ne se rend pas compte qu’il devrait demander des informations plus détaillées. Quand on regarde la sortie des modèles de raisonnement, l’idée de poser une question de clarification n’apparaît presque jamais ; lorsqu’ils sont confus, ils se contentent de deviner indéfiniment ce que l’utilisateur voulait dire.
Cela a aussi des implications pour la pertinence de l’idée de « remplacer les programmeurs humains ». L’une des parties difficiles de ce métier consiste à interagir avec les parties prenantes pour transformer des idées ambiguës, et souvent confuses, en spécifications précises.
La plupart du temps, l’utilisateur écrit les répliques du personnage User dans un document de scénario de film, et l’algorithme du LLM ne fait que compléter périodiquement les répliques inachevées du personnage Chatbot.
On peut interviewer un vampire appelé DraculaBot, mais ce personnage ne peut « s’introspecter » que de manière superficielle et fictive, comme lorsqu’il « aspire au sang » ou « se transforme en nuée de chauves-souris ».
Donc, quand l’autocomplétion commence à se dégrader, il faut recommencer. Il n’y a aucun concept, seulement d’immenses amas de mots vus dans les textes d’entraînement et de suites possibles.
Je demande souvent au LLM de produire un résumé concis au format prompt de la discussion jusque-là. En le modifiant correctement puis en l’utilisant pour commencer une nouvelle conversation sans bagage, cela s’est révélé très efficace. Ce sera probablement automatisé bientôt.
C’est ainsi qu’est né TSCE (Two-Step Contextual Enrichment). Lors d’un test avec 300 tâches mélangées avec GPT-35-turbo, il a permis une amélioration de +30 points de pourcentage
C’est un framework gratuit et public, que l’on peut essayer directement depuis le dépôt : https://github.com/AutomationOptimization/tsce_demo
Le test a été refait 300 fois avec gpt-4.1 sur une tâche consistant à supprimer les « em-dashes » voyants que les gens détestent. La baseline en passe unique et TSCE ont été comparés avec les mêmes instructions et le même prompt : « Remove the em-dashes from my linkedin post. . . »
Sur 300 exécutions, la baseline a échoué 149/300 fois à supprimer les em-dashes, tandis que TSCE a échoué 18/300 fois. Ça fonctionne, et toutes les données ainsi que l’intégralité des scripts de test sont dans le dépôt
text.replace("—", "-")Prompt système :
"Remove every em-dash (—) from the following text while leaving other characters unchanged.\n\nReturn only the cleaned text."Prompt utilisateur :
Temperature: 0.0
Je travaille avec pas mal de succès sur la résolution de ce problème, et je partagerai bientôt davantage. Le système comporte deux éléments : le premier est le LLM lui-même, et l’autre agit comme une sorte de curateur de pensée
Il ajoute et retire dynamiquement des portions de contexte, sans s’appuyer sur des définitions explicites, mais sur la capacité du LLM à « combler les blancs ». Ce système aide le LLM à décomposer le problème en petites tâches, qui sont ensuite agrégées pour former la tâche globale
À l’avenir, cette séparation des couches de mémoire devrait devenir plus claire. On pourrait avoir une mémoire primaire avec les données d’entraînement, une mémoire secondaire avec le contexte, et une mémoire tertiaire avec le RAG
Je suis surpris que les grands outils de chat ne fassent pas de la ramification/du fork une fonctionnalité centrale. On peut modifier une réponse, mais cela fait disparaître beaucoup d’autre contexte
Mon flux ressemble grosso modo à : 1) planifier 2) implémenter 3) créer une branche (à cause d’une fonctionnalité ou d’un problème de dépendance particulier) 4) revenir à l’étape 2. L’élagage de prompts et les branches devraient être des outils de premier ordre dans toute utilisation de LLM
Les interfaces LLM conçues autour de conversations à un seul tour posent un problème visible. La plupart des gens s’attendent à une conversation linéaire
J’ai créé un bot Telegram http://t.me/experai_bot comme UI généraliste pour les LLM, avec un ensemble de fonctionnalités un peu réduit, et conçu autour de l’idée que « tout message qui n’est pas une réponse démarre une nouvelle conversation ». Si l’on veut conserver le contexte, il suffit de continuer à répondre aux réponses du bot. Les utilisateurs non avancés ont du mal avec cette idée
J’ai aussi constaté qu’avec les modèles OpenAI, même un tout petit message système pouvait dégrader les performances lorsqu’ils répondaient à la même question. Par exemple, la liste d’options dans la réponse devenait plus courte. C’était le cas avec 3.5 et 4o ; je ne sais pas pour les modèles les plus récents. J’ai donc décidé de ne pas inclure de message système par défaut. Il reste possible d’en ajouter si nécessaire, et de les activer, désactiver ou combiner
J’ai l’impression que le domaine des LLM est actuellement rempli de gens qui résolvent encore et encore les mêmes problèmes
C’est la principale raison pour laquelle j’ai créé promptdown. Je voulais pouvoir modifier l’intégralité de l’historique de chat à chaque tour, ce qui n’est pas facile avec l’interface de chat standard, qui ne fait qu’ajouter des messages
https://github.com/t-kalinowski/promptdown
J’ai toujours eu le sentiment que les moqueries autour du terme « prompt engineering » viennent en partie du fait que les gens surestiment l’importance du prompt initial et sous-estiment celle de la gestion du contexte au fil de la conversation
Avec l’expérience, on développe une intuition sur la manière de piloter le modèle et sur le moment où il faut démarrer une nouvelle conversation. Le prompt système ou le prompt initial restent importants, mais si l’on prolonge naïvement la conversation trop longtemps, rien ne pourra vous sauver