Les LLM se perdent dans les conversations multi-tours

• Les grands modèles de langage (LLM) montrent une baisse de performance et une diminution de fiabilité dans les conversations à plusieurs tours
• Par rapport au mode single-turn, une baisse moyenne de 39 % des performances a été confirmée expérimentalement en situation multi-tour
• Les causes principales sont une légère baisse d’aptitude et une très forte dégradation de la fiabilité, c’est-à-dire un manque de cohérence des résultats
• Les LLM ont tendance à formuler très tôt de mauvaises hypothèses ou à tenter trop vite la réponse finale
• En conséquence, lorsqu’un LLM commet une erreur au début de la conversation, on observe qu’il ne parvient pas à se rétablir et perd le fil de l’échange

---

ABSTRACT

• Les grands modèles de langage (LLM), en tant qu’interfaces conversationnelles, ont le potentiel d’aider les utilisateurs à définir, explorer et corriger progressivement leurs besoins au fil d’une conversation multi-tour, même lorsqu’ils ne peuvent pas les exprimer complètement dès le départ
• Pourtant, alors que la plupart des évaluations de LLM se concentrent uniquement sur des consignes single-turn entièrement spécifiées, l’analyse de journaux de conversations réelles montre que l’underspecification y est fréquente
• Cette étude compare à grande échelle les performances des LLM entre des contextes single-turn et multi-turn (underspecified) au moyen de simulations
• Les résultats montrent que, pour les 15 principaux LLM étudiés, les conversations multi-tours entraînent une baisse moyenne de performance de 39 %, expliquée par une légère diminution d’aptitude et une forte dégradation de la fiabilité
• Lorsque les LLM empruntent une mauvaise trajectoire au début de la conversation, on constate ensuite qu’ils ne parviennent pas à récupérer et errent en perdant leur direction

Introduction

• Les LLM récents (par ex. ChatGPT, Gemini, Claude, etc.) proposent des interfaces capables de conversation multi-tour
• Même si l’utilisateur ne décrit pas clairement toutes ses exigences dès le départ, un échange itératif de questions-réponses (underspecified → refined) permet de préciser progressivement la demande
• En pratique, de nombreux utilisateurs formulent des besoins flous en début de conversation, mais la plupart des évaluations restent limitées au single-turn entièrement spécifié
• Certaines recherches antérieures ont tenté des évaluations multi-tours, mais elles traitent souvent chaque tour de conversation comme un épisode indépendant, ce qui sous-estime l’effet de l’ambiguïté si fréquente dans les échanges humains réels
• Pour combler cet écart, cette étude propose un cadre de sharded simulation (où l’information est divisée en plusieurs fragments et révélée un par un à chaque tour) afin de simuler avec précision des situations de dialogue multi-tour avec consignes incomplètes

Résumé des principaux résultats

• En single-turn, lorsque le LLM reçoit l’intégralité de la consigne d’un coup, il atteint 90 % de performance ; en consigne multi-tour incomplète, ce score tombe à 65 % (baisse moyenne de 25 points)
• Le phénomène apparaît après seulement deux tours de conversation et est observé de façon uniforme sur tous les LLM, ouverts ou fermés, grands ou petits
• L’analyse des causes de la baisse de performance met en évidence : (1) une perte d’aptitude (aptitude loss) et (2) une forte hausse de l’instabilité (unreliability)
  • En single-turn, les modèles ayant une forte aptitude présentent aussi une forte fiabilité, mais en multi-tour la fiabilité devient faible indépendamment de l’aptitude
  • Autrement dit, lorsqu’un LLM s’engage dans une mauvaise direction pendant une conversation multi-tour, il devient incapable de se rétablir — phénomène que les auteurs appellent « lost in conversation »
• Principales causes
  • Réponses verbeuses et tentatives trop précoces de fournir la réponse finale
  • Hypothèses erronées face à des informations incomplètes
  • Dépendance excessive aux tentatives précédentes erronées
• Il existe un écart important entre les usages réels des LLM et la manière dont les modèles sont évalués
  • Les utilisateurs débutants, en particulier, donnent souvent des consignes incomplètes au départ, ce qui fait de ce phénomène l’un des principaux freins à l’usage en conditions réelles
• L’article présente ensuite : un résumé des travaux antérieurs, la description de l’environnement de simulation, 6 tâches de génération et leurs métriques d’évaluation, des expériences à grande échelle sur 15 LLM, puis des implications pratiques et des recommandations concrètes pour les produits et les usages métier

Background and Related Work

• Les générations précédentes de modèles de langage (par ex. BART, GPT-2, T5) ne géraient pas réellement les conversations multi-tours, et étaient donc évaluées principalement en single-turn
• Depuis l’arrivée de ChatGPT, l’intérêt pour l’évaluation multi-tour a fortement augmenté, avec notamment des évaluations crowdsourcées comme MT-bench
• Mais la plupart de ces cadres d’évaluation restent centrés sur des conversations épisodiques (évaluation séparée de chaque tour), sans prendre en compte la continuité propre aux conversations réellement ambiguës
• Dans le monde réel, selon le « principe du moindre effort », les humains donnent souvent des instructions imprécises (a.k.a. underspecification), et les LLM voient alors leurs performances baisser à cause de conclusions hâtives en situation de manque d’information et d’une capacité d’adaptation insuffisante
• Cette étude vise donc une évaluation plus proche des conditions réelles, où l’incomplétude de l’information est centrale

Simulating Underspecified, Multi-Turn Conversation

3.1 Sharding Process

• La consigne entièrement spécifiée d’origine est découpée en plusieurs shards (fragments d’information)
  • Exemple : au lieu de réunir toutes les conditions dans une seule phrase, une seule information (cadre, valeur numérique, contrainte, etc.) est révélée à chaque tour
• Le premier shard décrit toujours l’objectif général de la consigne, puis les shards suivants ajoutent progressivement des informations supplémentaires (contexte, contraintes, etc.) à chaque tour
• Ce processus de sharding a été construit avec des propositions + validation par LLM (GPT-4o), puis complété manuellement, afin d’obtenir un jeu de données de consignes multi-tours de haute qualité
• Pour chaque tâche, 90 à 120 consignes découpées ont été produites, avec plusieurs heures de vérification manuelle

3.2 Simulating Sharded Conversations

• La simulation de conversation repose sur trois rôles : le LLM évalué (assistant), un simulateur d’utilisateur connaissant tous les shards, et un système de classification et de notation des réponses
• Premier tour : le simulateur d’utilisateur transmet uniquement le premier shard à l’assistant → l’assistant répond → sa stratégie (clarification, question, tentative de réponse, etc.) est classée et la réponse est extraite → la réponse est évaluée
• Tours suivants : un seul shard supplémentaire parmi ceux qui restent est révélé, et le processus est répété / à chaque tour, l’assistant peut répondre librement
• Fin de conversation : (1) l’évaluateur considère que la bonne réponse a été obtenue, ou (2) il n’y a plus de shards à fournir
• Le simulateur d’utilisateur est implémenté avec un LLM (GPT-4o-mini), capable de fournir les shards de manière naturelle et de les reformuler automatiquement
• Sur l’ensemble des expériences, les erreurs de classification ou d’extraction des LLM auxiliaires restent sous 5 %, et dans moins de 2 % des cas elles désavantagent l’assistant
• L’assistant est évalué dans son état par défaut, sans information particulière sur l’environnement, afin de se rapprocher de conditions d’usage réelles

3.3 Simulation Types

• FULLY-SPECIFIED (FULL): toute la consigne est fournie en un seul tour ; sert de baseline de performance
• SHARDED: un seul fragment d’information est révélé à chaque tour ; c’est l’expérience centrale de l’étude sur les conversations multi-tours incomplètes
• CONCAT: l’ensemble des consignes découpées est fourni d’un coup sous forme de bullet points ; permet d’évaluer uniquement la perte d’information due au format
• RECAP: après la conversation sharded, tous les shards sont récapitulés / fournis à nouveau à la fin ; forme simple d’intervention de type agent
• SNOWBALL: à chaque tour, le nouveau shard est ajouté tout en répétant tous les shards précédemment révélés, afin que l’assistant n’oublie aucune information ; expérience de renforcement mémoire

Task and Metric Selection

4.1 Task Selection

• 6 tâches au total : programmation (Code), base de données (génération SQL), appels de fonctions API (Actions), mathématiques (Math), tableau → texte (Data-to-Text), résumé sous forme de questions-réponses (Summary)
  • Exemples : écrire une fonction Python, convertir une requête en langage naturel en requête SQL, etc.
• Pour chaque tâche, 90 à 120 consignes ont été sélectionnées à partir de benchmarks de haute qualité, puis découpées et vérifiées manuellement
• Ces 6 tâches couvrent à la fois des scénarios de programmation et hors programmation, y compris des cas variés comme Summary qui nécessite un long contexte

4.2 Metric Selection

• Métriques d’évaluation
  • Performance moyenne (P) : score moyen obtenu sur plusieurs simulations (0 à 100)
  • Aptitude (A90) : valeur des 10 % meilleures simulations (90th percentile, best-case)
  • Fiabilité (U90_10) : écart entre les scores du top 90 % et du bottom 10 % (mesure de la cohérence / variabilité des résultats)
• Exemple : dans un box-plot, la partie supérieure représente l’aptitude, et l’étendue haut-bas la fiabilité
• Les scores sont agrégés de manière cohérente sur les 6 tâches (exactitude, similarité, BLEU, etc.)
• Les paramètres expérimentaux, exemples, méthodes d’échantillonnage et le code détaillé figurent également en annexe / Appendix

Simulation Scale and Parameters

• Un total de 600 instructions a été constitué sur 6 tâches, puis testé dans les scénarios FULL / CONCAT / SHARDED
• 15 LLM (GPT-4, Claude, Gemini, etc.) ont été simulés 10 fois pour chaque combinaison, ce qui représente plus de 200 000 expériences
• Toutes les expériences ont été menées avec une température de 1 (sampling), et des expériences supplémentaires (7.2) analysent aussi l’effet de la température
• Cet immense volume de données de simulation permet d’identifier les principaux types et causes des comportements problématiques et de la baisse de performance des LLM dans les conversations multi-tours underspecified

Lost in Conversation Experiment

• La suite de l’article détaille successivement le protocole expérimental, les résultats par modèle, l’analyse des causes de la dégradation, les tentatives de correction (RECAP / SNOWBALL), puis les implications pratiques et recommandations concrètes

[GN⁺]

Commentaires sur Hacker News

• Je suis content de voir un article qui confirme quelque chose que toute personne ayant réellement utilisé des outils LLM sait déjà empiriquement. La notion de « conversation » a été créée par l’interface produit. Il est important de garder le contexte propre. Une fois le contexte contaminé, il ne se rétablit pas, donc il faut repartir dans une nouvelle conversation

  • Mon expérience ressemble à cette observation, mais avec quelques différences. J’ai débogué un problème IPSEC avec Gemini pendant deux semaines. Au début, je lui ai fait ingérer la documentation IPSEC d’OPNsense et de pfSense et je lui ai fourni le contexte général. Ensuite, j’ai partagé les informations de configuration et j’ai poursuivi les questions-réponses. Vers la fin, le LLM se dispersait moins, et même lorsque j’ajoutais des messages de forum ou des posts SO, le LLM disait parfois : « ce n’est pas ce qu’on observe ici ». On a éliminé logiquement toutes les impasses, et le LLM aidait à réfléchir, mais c’était à l’humain de décider. J’ai finalement trouvé la cause du problème et, comme d’autres l’ont dit, les LLM excellent à simplifier des informations complexes, mais sont faibles pour complexifier des concepts simples. Je suis plus satisfait du résultat quand l’entrée est plus complexe ou plus longue que la sortie. J’aurais pu le faire sans LLM, mais c’était utile pour stocker des faits dont je ne me souvenais pas bien ou que je ne pouvais pas reproduire rapidement. Il a aussi aidé à repérer des motifs temporels dans un grand volume de logs. J’ai également amélioré plusieurs configurations. J’ai appris beaucoup de choses, pas seulement résolu le problème. Son évaluation de l’état était parfois fausse, mais facile à corriger moi-même. Autrement dit, c’est utile si l’on connaît l’objectif et qu’on s’en sert comme d’un outil, mais inefficace si on lui délègue les décisions ou si on se laisse entraîner dans une mauvaise direction. J’ai utilisé 350 000 tokens (environ 300 000 mots). J’ai un billet de blog à ce sujet. Pas besoin de recommandations pour wireguard
  • Mon expérience correspond totalement. Le mot « contaminé » est exactement juste. Quand quelque chose tourne mal, toutes les réponses suivantes commencent à se dégrader. C’est pour ça que je n’aime pas la fonction memory de ChatGPT. Ce n’est pas un énorme problème, mais ça m’inquiète de ne pas comprendre complètement comment la contamination du contexte se produit
  • Mon meilleur conseil est d’utiliser activement le minuscule bouton « modifier », bien caché, dans ChatGPT et Claude. Si une mauvaise réponse sort, ne continuez pas comme si de rien n’était : arrêtez-vous, corrigez-la, puis obtenez une meilleure réponse. Sinon, le bazar continue de se multiplier
  • J’ai toujours envie de forker une conversation pour expérimenter plusieurs directions. Je voudrais éviter qu’un flux prometteur subisse une contamination irréversible. Je ne peux pas faire ça dans ChatGPT ; je me demande s’il existe un service qui le propose
  • Un exemple intéressant de ce problème, c’est le prompt initial. C’est en pratique un contexte permanent et caché. Le bot Grok de Twitter mentionne récemment souvent « White Genocide », parce que quelqu’un a modifié le prompt pour l’orienter vers ce sujet. Un chatbot parfait ne devrait pas être influencé sur d’autres sujets, mais en réalité il l’est. Au final, le contexte a changé et il reste obsédé par ce sujet en permanence
  • C’est pour ça que j’ai créé FileKitty. C’est un outil qui fusionne rapidement plusieurs fichiers source en Markdown. Quand on se fait assister par un LLM pour le développement logiciel, s’appuyer sur le LLM pour explorer la base de code augmente le risque d’erreur. À cause de la perte liée à la compression du contexte, le résultat peut aussi se diluer. On obtient les meilleurs résultats quand un contexte spécifique est clairement établi dès le départ puis actualisé au fil de la conversation. Malgré cela, il faut quand même faire attention à la longueur de la conversation. Il existe aussi des prompts qui capturent bien le contexte pour le transmettre à une nouvelle session. On peut aussi choisir les fichiers à inclure et les mettre dans un nouveau prompt. On peut consulter une discussion liée dans un autre thread HN
  • Ce schéma fait désormais partie de mon workflow. Parfois, je demande au LLM : « Bon progrès, j’aimerais passer à l’étape suivante, mais vaut-il mieux continuer dans cette conversation ou en démarrer une nouvelle ? » Si le modèle dit qu’il vaut mieux repartir, il prépare un bon prompt de synthèse ; sinon, il répond qu’on peut continuer. J’ai plusieurs notes intitulées « ensemble de points de départ à explorer ensuite ». Il y a aussi, dans le post-training basé sur le RL, une tendance des chatbots à vouloir poursuivre la conversation. En RL, le post-training n’utilise, contrairement au vrai RL, qu’un mécanisme ponctuel fondé sur les préférences. Les préférences de long terme ou les conversations longues voient leur complexité de calcul augmenter de façon exponentielle, donc il y a peu de recherche dessus
  • Je me demande s’il existe des interfaces qui implémentent un « rangement » de l’historique de conversation. Une fonction qui nettoie les chemins morts ou les éléments sans rapport dans une conversation. On garde l’historique complet, mais on élague ou on remet en ordre les parties inutiles selon le parcours thématique. Ce serait moins un résumé qu’une réorganisation organique
  • Je n’utilise les LLM que pour l’autocomplétion, mais je pense qu’ajouter un bouton ou une option « supprimer le message » dans l’UI de chat des LLM résoudrait ce problème. Si on supprime le dernier message du LLM, on peut obtenir une nouvelle réponse. C’est particulièrement utile avec des LLM à forte aléa (temperature). Si l’on supprime d’autres messages, le contexte devrait être mis à jour pour que les réponses suivantes en tiennent compte. Cela permettrait aussi de corriger l’illusion des utilisateurs selon laquelle le LLM serait intelligent. Je ne sais pas si c’est déjà un standard. Si ce n’est pas le cas, je place l’idée dans le domaine public. D’un autre côté, il serait aussi pratique d’avoir un « sous-contexte LLM » chargé de gérer le contexte principal. Autrement dit, quand les réponses deviennent trop longues ou trop volumineuses, un LLM secondaire résume/réorganise pour affiner le contexte global de la conversation. Ou alors, plus simplement, il suffit d’un bouton « modifier le message » pour que l’humain fasse lui-même le ménage
  • Une fois le contexte contaminé, il est difficile de récupérer la situation. Ce serait mieux si on pouvait périodiquement réinitialiser ou purifier certaines parties pour le LLM. Mais la difficulté est de savoir quelles parties nettoyer sans perdre les informations essentielles. Une gestion de contexte plus intelligente pourrait aider à maintenir la cohérence des longues conversations, mais l’équilibre est délicat. Peut-être qu’un autre agent pourrait automatiser cela
  • Dans les chatbots IA, les prompts de type chain-of-thought montrent aussi leurs limites pour la même raison
  • À propos de l’idée selon laquelle la « conversation » n’est qu’un produit de l’interface produit : l’apprentissage sur des jeux de données d’évaluation multi-turn en RL a modifié cette dynamique. La fenêtre de contexte est recréée à chaque fois, mais la tendance à interpréter chaque prompt comme faisant partie d’une conversation plus longue s’est renforcée. Publiquement, le post-training multi-turn n’est pas encore déployé à grande échelle, mais à long terme il sera probablement adopté pour atteindre davantage d’objectifs
  • Même quand je code, je démarre souvent de nouvelles conversations sans poursuivre la précédente, puis je réexplique à partir du code actuel. Cela donne souvent de meilleurs résultats que de marteler la même conversation. On pourrait probablement résoudre ce problème en explicitant au modèle, via des commandes manuelles, ce qu’il doit résumer et oublier. Cela correspond aussi en partie au fonctionnement humain (mémoire de travail vs mémoire narrative/épisodique)
  • L’une des fonctions les plus frustrantes de ChatGPT est la « mémoire ». La contamination de la conversation peut même se propager d’un chat à l’autre
  • « Contaminé » est vraiment le terme exact. J’aimerais qu’on introduise un « contrôle de version » dans les conversations/API, pour pouvoir revenir à un état antérieur ou dupliquer vers une nouvelle conversation. C’est d’autant plus vrai que même une faute de frappe ou la modification d’un message peut introduire un biais subtil dans les réponses suivantes
  • J’aime vraiment l’UX de chat de zed. On peut modifier tout l’historique comme un fichier texte, ce qui permet de nettoyer, supprimer, corriger et compléter les parties indésirables, puis de poursuivre la conversation avec un contexte beaucoup plus propre et pertinent. C’est pourquoi j’utilise zed comme l’une de mes principales interfaces de conversation LLM, même hors programmation
  • La contamination peut aussi venir de questions ou réponses hors sujet, ou d’une « dilution » répétée. Même pour la génération de contenu, j’observe souvent que des consignes claires au départ se dégradent progressivement
  • J’essaie toujours de garder en tête que la « conversation » n’est qu’un produit de l’interface, mais en pratique ce n’est pas facile à cause des nombreux indices de style conversationnel
  • J’ai regretté d’avoir activé la mémoire. Les conversations se contaminent avec des informations inutiles
  • Ce qui est surprenant, c’est à quel point le modèle fixe très tôt de mauvaises hypothèses et s’y accroche
  • En y réfléchissant, ça arrive souvent aussi chez les humains
  • Maintenant que ChatGPT peut accéder aux anciennes conversations via la « mémoire », la contamination peut devenir permanente. Une fois qu’il s’accroche à une mauvaise idée, même si l’utilisateur insiste plusieurs fois pour ne plus jamais la mentionner, il continue à l’injecter dans ses réponses. Il lui arrive même d’afficher par erreur un prompt interne (« l’utilisateur est très mécontent, il faut retirer xyz »), ce qui produit une situation absurde où il se met justement à insister encore plus sur xyz

• C’est un phénomène qui vient de la tendance bien connue des LLM à l’excès de confiance, de leur absence d’auto-réflexion, et de leur incapacité à reconnaître quand ils devraient demander davantage d’informations. Quand on regarde les résultats des modèles de raisonnement, on voit que lorsqu’ils sont confus, ils ne demandent pas d’explications supplémentaires et se contentent de répéter des suppositions sur ce que l’utilisateur voulait dire. Cela montre la limite très concrète de l’idée selon laquelle ils pourraient remplacer les programmeurs humains. La partie vraiment difficile consiste à transformer des demandes ambiguës en exigences claires via « l’interaction avec les parties prenantes »

  • Concernant l’incapacité à l’auto-réflexion, il n’y a en réalité aucun véritable agent dans le LLM, et l’utilisateur tombe dans une sorte de « récit de maintien de la croyance ». Si l’on laisse en entrée un texte jouant le rôle de l’utilisateur dans un script de film, le LLM ne fait qu’autocompléter une intrigue incomplète dans le rôle du chatbot. Par exemple, une interview avec DraculaBot n’imite l’auto-réflexion qu’en surface, comme « avoir soif de sang » ou « se transformer en nuée de chauves-souris »
  • Je partage la même déception sur l’incapacité des LLM à demander clairement des précisions dans des problèmes ouverts où l’information est ambiguë (en particulier les paradoxes). Je l’ai testé avec DeepSeek-R1 et Claude-3.7-Sonnet, et il existe aussi un billet de blog expérimental à ce sujet
  • Gemini 2.5 Pro et ChatGPT-o3 demandent parfois des informations supplémentaires avant d’exécuter une tâche. Gemini présente même plusieurs options et me demande mon avis
  • Les vrais programmeurs passent en réalité la majeure partie de leur temps à clarifier les exigences. Les LLM traitent encore le fait de deviner comme une fonctionnalité à part entière
  • Ironiquement, c’est similaire quand on travaille avec des développeurs débutants. On leur confie une tâche et ils foncent tout droit, font des hypothèses sans poser la moindre question, puis finissent perdus si profondément dans la forêt qu’il faut envoyer une équipe de secours les récupérer
  • Je pense qu’on pourrait changer cela assez facilement. De la même manière que les prompts chain of thought remplacent le dernier token par « hmm », quand un LLM s’apprête à dire « je suppose que c’est probablement ~ », on pourrait remplacer ce token par « je vais d’abord demander des précisions supplémentaires »
  • Demander plus d’informations ou faire preuve d’auto-réflexion, ils savent déjà assez bien le faire si on le leur demande

• J’aime bien la technique qui consiste à demander au LLM de résumer ce qui a été discuté jusqu’ici sous la forme d’un prompt concis, puis à le corriger et l’éditer moi-même avant de lancer une nouvelle conversation. Cette méthode a été plutôt efficace pour moi, et je pense qu’elle sera bientôt automatisée

  • Cursor a essayé de le faire automatiquement, mais (sauf à utiliser un modèle à très grand contexte) le résumé perdait trop de détails pour être vraiment utile en pratique
  • Claude Code dispose de la commande /compact, qui résume la conversation pour réduire l’usage de tokens

• J’ai moi-même conçu TSCE (Two-Step Contextual Enrichment). Utilisé sur 300 tâches avec GPT-35-turbo, cela a amélioré les performances de +30 pp. C’est librement utilisable dans un framework open. J’ai aussi réalisé 300 expériences supplémentaires avec gpt-4.1. Sur la baseline, l’échec de suppression des tirets cadratins est survenu 149 fois sur 300 ; avec TSCE, 18 fois sur 300. Les données complètes et les scripts sont également publics

  • Des kilowattheures gaspillés pour une simple opération de find and replace. Je me demande si tu as essayé quelque chose comme text.replace("—", "-")
  • En changeant légèrement le prompt de baseline, j’ai obtenu 100 % de réussite avec GPT-4.1. Pas besoin d’appels supplémentaires, de dépenses en tokens ni de technique compliquée

• J’ai déjà résolu un problème en utilisant deux systèmes (LMM + curator automatique). L’un est le LLM lui-même, l’autre un « curateur de pensée » qui remplace et gère dynamiquement certaines parties du contexte. Cela repose non pas sur des règles explicites, mais sur la capacité du LLM à compléter ce qui manque. Il aide à découper le problème en petites parties traitables, et l’agrégation de ces résultats permet d’atteindre l’objectif final

  • Belle idée. Ce que tu fais actuellement ressemble à une sorte de RAG conversationnel. À l’avenir, la séparation des couches de mémoire (données d’entraînement / contexte courant / RAG) deviendra probablement plus claire
  • Je trouve l’idée intéressante. Même une version simple partagée publiquement permettrait à beaucoup de gens de l’améliorer, et la communauté pourrait la faire grandir d’elle-même
  • Cela ressemble au système de critique interne évoqué dans Emotion Machine
  • J’aimerais en savoir plus sur le projet que tu construis. Ça a l’air intéressant
  • Au final, on pourrait donc appeler cela du Map-Reduce-of-Thought

• Je trouve étonnant que le branching/forking ne soit pas natif dans les principaux outils de chat. On peut certes modifier des réponses, mais dans ce cas on perd beaucoup d’autres contextes. Mon workflow, c’est 1. planifier 2. construire 3. brancher 4. itérer. Je pense que l’élagage/la création de branches de prompts devrait devenir un outil central de l’usage des LLM

  • Google AI Studio propose au moins cette fonction. Mais son implémentation était confuse, ce qui explique peut-être pourquoi elle ne s’est pas davantage diffusée
  • J’ai envie de construire ça moi-même depuis longtemps. BetterChatGPT a au moins une bonne interface de suppression d’historique, mais pour moi le branching est clairement l’étape suivante

• Les problèmes apparaissent quand les interfaces LLM sont conçues autour de conversations mono-tour. La plupart des utilisateurs s’attendent à une conversation linéaire. J’ai donc créé le bot Telegram experai_bot comme UI universelle pour les LLM, avec l’approche « pas une réponse = nouvelle conversation ». Pour conserver le contexte, il faut absolument continuer dans une structure arborescente de réponses. Les non-spécialistes ont du mal à comprendre cette manière de faire. De plus, avec les modèles OpenAI (3.5, 4o), plus on répète la même question, plus les espaces ou les options se raccourcissent et plus le résultat devient imprécis. Les résultats se maintiennent relativement mieux si l’on minimise les messages système. Si nécessaire, on peut ajouter un message système en option

• La raison principale pour laquelle j’ai créé promptdown était de pouvoir éditer complètement tout l’historique du chat à chaque tour. La structure « append-only » des interfaces standard rend ce genre de chose difficile

• En ce moment, dans le domaine des LLM, on a l’impression que tout le monde résout sans cesse le même problème

  • Comme les LLM en conversation multi-tour, tout le monde répète le même problème
  • Ce n’est pas de « l’apprentissage », c’est du « gardiennage de chats », mais pour certains workflows ça convient bien
  • Tout le monde veut exhiber ses propres talents de prompt engineering

• Les LLM ressemblent vraiment à un génie dans une bouteille. Ils répondent à trois questions, puis ensuite ils se mettent à raconter n’importe quoi