Les LLM dégradent les documents lorsqu’on leur délègue des tâches

 (arxiv.org)
1 points par GN⁺ 4 시간 전 | 1 commentaires | Partager sur WhatsApp
  • DELEGATE-52 est un benchmark qui évalue dans quelle mesure un document reste fidèle dans des workflows délégués où l’utilisateur confie à un LLM des tâches d’édition de longs documents
  • Ce benchmark couvre des tâches nécessitant une édition approfondie de documents dans 52 domaines spécialisés, dont le code, la cristallographie et la notation musicale, et l’exemple de simulation se compose de 20 tâches consécutives déléguées
  • Dans 19 expériences sur des LLM, même des modèles de pointe comme Gemini 3.1 Pro, Claude 4.6 Opus et GPT 5.4 dégradent en moyenne 25 % du contenu du document à la fin de longs workflows
  • La dégradation des documents apparaît sous forme d’erreurs rares mais graves, et elle s’aggrave à mesure que la taille du document, la longueur des interactions et le nombre de fichiers perturbateurs augmentent ; l’usage d’outils de type agent n’améliore pas non plus les performances
  • Les LLM actuels sont difficilement considérés comme des mandataires fiables pour l’édition de documents par délégation, et microsoft/DELEGATE52 ainsi que datasets/microsoft/DELEGATE52 sont publiés comme ressources liées à DELEGATE-52

Modes d’échec de l’édition déléguée

  • Le travail délégué repose sur la confiance selon laquelle l’utilisateur confie une tâche à un LLM et que celui-ci l’exécutera sans introduire d’erreurs dans le document
  • Dans une vaste expérimentation menée sur 19 LLM, les modèles actuels dégradent les documents pendant le processus de délégation
  • Les autres modèles échouent plus sévèrement encore que les modèles de pointe
  • La dégradation du document s’accumule au fil des longues interactions et finit par le corrompre silencieusement

Exemples d’évolution des documents

  • Dans la catégorie Graph Diagrams, le document Linux Kernel Architecture est indiqué à 79 % du niveau de l’original après 4 itérations avec Gemini 3.1 Pro, 49 % après 10, 48 % après 14 et 48 % après 20
  • Dans la catégorie Textile Patterns, le document 12-Shaft Twill Diamond est indiqué à 100 % du niveau de l’original après 4 itérations avec Claude 4.6 Opus, 40 % après 10, 27 % après 14 et 34 % après 20
  • Dans la catégorie 3D Objects, le document ActionBoy Palm Tree est indiqué à 100 % du niveau de l’original après 4 itérations avec GPT-5.2, 31 % après 10, 15 % après 14 et 6 % après 20

Ressources publiées

  • microsoft/DELEGATE52
  • datasets/microsoft/DELEGATE52

À lire aussi

1 commentaires

 
GN⁺ 4 시간 전
Commentaires sur Hacker News

  • Je reste sceptique quant aux résultats sur l’usage d’outils

    Il n’y a rien d’étonnant à ce qu’un long contenu se détériore quand on le fait passer aller-retour à travers un LLM. Les gens qui utilisent souvent des LLM savent déjà qu’il ne faut pas faire ça.

    J’ai été surpris que l’article conclue que l’usage d’outils n’a pas aidé, mais il précise en même temps qu’ils ont implémenté un « agent harness de base » et non un système moderne optimisé.

    En pratique, le harness ne contient que read_file() et write_file(), donc c’est presque juste une étape de plus dans le traitement aller-retour. Les harnesses modernes pour agents de code accordent beaucoup d’attention à la conception des outils d’édition de fichiers ; par exemple, il y a l’ensemble d’outils d’édition de Claude : https://platform.claude.com/docs/en/agents-and-tools/tool-us...

    Les commandes str_replace et insert sont essentielles pour éviter les modifications risquées qui réécrivent le fichier entier.

    Ils fournissent au moins un outil run_python(), donc de meilleurs modèles ont peut-être pu s’en servir pour faire des remplacements de chaînes. J’aimerais voir si le prompt système encourageait des manipulations via Python, ou au contraire poussait à lire puis réécrire les fichiers.

    Le code du harness est ici : https://github.com/microsoft/delegate52/blob/main/model_agen...

    Le fragment de prompt concerné dit en gros : « vous pouvez aborder cela de la manière que vous jugez la plus efficace, que ce soit de façon programmatique ou en écrivant directement dans les fichiers ».

    Comme souvent avec ce genre d’articles, les résultats reflètent davantage la conception du harness utilisée par les auteurs que le modèle lui-même. Qu’il s’agisse d’un ingénieur IA expérimenté ou d’un prompt engineer, je pense qu’en itérant sur le harness lui-même on pourrait obtenir de meilleurs résultats à ce test.

    • Je suis d’accord dans l’ensemble, sauf sur « les gens qui utilisent souvent des LLM savent déjà qu’il ne faut pas faire ça »

      Avec l’adoption des LLM qui se diffuse aujourd’hui dans les organisations et les équipes, il y a beaucoup de gens — peut-être même une majorité — qui utilisent des LLM tous les jours sans avoir jamais touché à quoi que ce soit d’aussi technique qu’un harness.

      Pour ces gens-là, le comportement décrit ici est un vrai problème.

    • C’est un peu connexe, mais j’aimerais voir un harness qui utilise ed comme outil de base pour lire/éditer des fichiers. La moitié du bash que Claude exécute ressemble déjà de toute façon à du sed, donc si ed conservait un état, ça pourrait aider.

      Que faire quand un éditeur complet consomme trop de bande passante^H jetons ? Utiliser l’éditeur standard, ed.

    • On est presque dans un cas d’homme de paille du travail avec les LLM

      Pour les tâches d’édition, on ne devrait autoriser que des commandes d’édition programmatiques, et le texte ne devrait pas traverser le LLM. Le LLM doit analyser le texte puis produire des commandes pour atteindre l’objectif selon le retour reçu.

    • Sur HN, il y a une tendance à interpréter les résultats de la manière la plus négative possible, parce que les gens y voient une menace pour leur métier et leur identité.

      En réalité, si on demande à quelqu’un de lire un document, d’appliquer des modifications, puis de redire tout le document, un humain peut obtenir un résultat pire qu’une dégradation de 25 %. Il est certes possible qu’un humain atteigne 0 % de dégradation, mais seulement s’il a reçu le document des centaines de fois jusqu’à le mémoriser. L’équivalent pour un LLM, c’est l’entraînement ; si on entraîne le LLM sur le document, alors dans ce cas il peut devenir équivalent à l’édition par une personne l’ayant mémorisé.

      Mais ce n’est pas le cœur du sujet. Les LLM ressemblent aux humains sur ce point, donc le harness doit être conçu pour qu’ils éditent comme les humains éditent les documents : par recherche et modifications chirurgicales. Tous les agents de code fonctionnent ainsi, donc cet article n’est pas très pertinent.

    • Que ce soit à cause de contraintes de ressources ou pour simplifier, ces articles perdent malheureusement de la valeur à cause de méthodologies difficiles à comprendre.

  • Je le dis depuis longtemps : dès qu’on repasse au pinceau de l’IA sur un texte, la qualité baisse, et l’effet s’accumule à chaque itération.

    Le terme que je préfère pour ça, c’est « ablation sémantique » : https://www.theregister.com/software/2026/02/16/semantic-abl...

    • Moi, j’appelle ça un retour vers l’intelligence moyenne
    • Je me demande si « à chaque itération » veut dire dans une même session, ou bien à chaque fois dans une nouvelle session ou une nouvelle fenêtre de contexte.

  • L’idée est que « la délégation exige de la confiance. Il faut pouvoir s’attendre à ce que le LLM accomplisse fidèlement la tâche sans introduire d’erreurs dans le document ». Et c’est précisément pour cela que tout le rituel de prompts et de harnesses qui écrivent des dizaines de fichiers Markdown ne fonctionne pas comme on le vend. En réalité, c’est presque du pseudo-scientifique rebaptisé agent engineering.

    L’agent engineering revient au fond presque à la même chose que ce qu’on appelle prompt engineering, sauf que maintenant les prompts sont dispersés dans des dizaines de fichiers Markdown et de répertoires.

  • C’est probablement la chose la moins surprenante que j’aie lue récemment sur les LLM.

    Les LLM ressemblent au mème du JPEG. Comme quand on enregistre un JPEG encore et encore et que la qualité se dégrade un peu à chaque fois jusqu’à devenir méconnaissable.

    Sauf qu’avec les LLM, le point de départ, c’est l’intention. À chaque passage dans un LLM, l’intention se dégrade, et dans le cas d’un article scientifique précis, des nuances subtiles et de la précision se perdent peu à peu au moment de reformuler.

    Les LLM sont des machines à revenir vers la moyenne. Plus le contexte ou la charge de travail que vous leur donnez sort de leur domaine d’entraînement, plus ils ont tendance à le tirer vers une sorte d’état d’équilibre abstrait et homogène.

    • Je l’ai clairement constaté en codant avec des LLM. Après une grosse rafale de travail sur des fonctionnalités, même quand je pensais avoir été assez prudent, il m’arrive souvent plus tard de regarder de petits morceaux de code en détail et de me dire « mon dieu ».

      Ensuite, je passe plusieurs heures à tout relire et à corriger soigneusement ce qui n’a pas tourné comme je voulais, ce sur quoi je n’avais pas été assez clair, ou les moments où les habitudes bizarres du LLM se sont déclenchées.

      La qualité du code compte en soi, mais c’est précisément ce problème de compression itérative qui m’inquiète. Si la base de code reste propre et que mon modèle mental est à jour, le LLM peut aider à avancer vite sur les fonctionnalités tout en laissant le code dans un état correct. Mais dès que le LLM commence à salir la base de code, les erreurs passées ou les malentendus s’accumulent, et la probabilité qu’il se trompe sur toujours plus de choses augmente. C’est pour ça que j’ai besoin de la « restaurer » dans un bon état avant d’oser réutiliser un LLM.

    • Le cas où ce résultat est vraiment intéressant et pertinent, c’est quand un agent de code découpe un gros fichier source en plusieurs petits fichiers. Opus et Claude Code, au lieu d’utiliser des manipulations de type copier-coller comme le ferait un humain, essaient de réciter de mémoire de longs segments de code source pour les placer dans les nouveaux fichiers.

      Déplacer des fichiers est un peu plus simple. Le LLM essaie parfois aussi de redire les fichiers de mémoire, mais si on lui dit d’utiliser git mv et de corriger les erreurs du compilateur, il s’en sort généralement bien.

      En revanche, pour l’édition ordinaire, avec un modèle raisonnable et de bons outils, ça marche généralement bien. Même Qwen3.6 27B s’en sort correctement. Pour les modifications sur place, on peut aussi examiner les changements inattendus avec git diff.

    • Il existe aussi un jeu d’enfants qui illustre ça : https://en.wikipedia.org/wiki/Telephone_game

    • Un collègue appelle les LLM une « couche de bullshit ». Ce n’est pas totalement péjoratif ; c’est une manière de souligner que chaque fois qu’on fait passer quelque chose dans un LLM, ce qui ressort de l’autre côté peut ne pas correspondre à ce qu’on attend ou à ce qu’on veut.

      C’est un peu comme quelqu’un qui a bu quelques verres dans un bar et vous raconte une info vue quelque part en ligne. C’est peut-être juste, mais le risque que ce ne soit pas le cas reste assez élevé.

      Par exemple, il ne faut pas utiliser un LLM pour appeler une API, collecter des données puis produire un rapport. On ferait passer des données critiques à travers une couche de bullshit, donc le résultat ne serait pas fiable. En revanche, il vaut mieux utiliser le LLM pour écrire le code qui produit une sortie déterministe à partir de données déterministes.

      J’ai déjà vu des collègues faire résumer par un LLM des données déterministes issues d’une API, avec des rapports aussi souvent complètement à côté de la plaque que corrects. Selon le contexte, le risque peut être catastrophique.

    • J’ai vécu ça en éditant mon CV. Le LLM retirait tous les éléments qui distinguaient mon CV de celui d’un profil junior générique à l’expérience moyenne. Tout ce qui était spécial, unique ou différent finissait remplacé par des formulations banales.

      Évidemment, je n’ai pas utilisé le résultat, mais c’était vraiment frustrant de voir le LLM insister en disant que c’était meilleur que ma version initiale.

      Le LLM m’a été bien plus utile pour de très petits morceaux, par exemple pour suggérer des modifications sur une phrase ou trois phrases.

  • Le problème, c’est qu’on demande trop de choses aux LLM. Les agents devraient être conçus comme une couche aussi fine que possible utilisant le LLM pour traduire une intention en langage naturel en processus déterministes, tout en réduisant au maximum les allers-retours avec le LLM.

    • Quiconque essaie de faire quelque chose d’un peu complexe s’en rend vite compte. Si on construit un pipeline qui combine flux de prétraitement, ciblage sémantique et appels de contexte minimaux avec l’API d’un LLM, on obtient une étape d’automatisation puissante.

      Combiné à une phase de validation séparée, le LLM cesse d’être un jouet et devient un outil utile.

    • Si des humains font encore partie de cette boucle itérative, alors ce n’est pas vraiment un processus automatisé.

  • En général, je dis aux agents de ne traiter la rédaction du document que comme l’ultime étape de rendu. Les LLM sont très bons pour rassembler et tisser des connaissances éparses, donc je préfère stocker la connaissance sous forme d’idées et de faits combinables.

    Une méthode qui a vraiment bien marché consistait à donner à l’agent un répertoire et à lui demander de créer un fichier Markdown indépendant pour chaque fait ou découverte trouvé. Je lui faisais aussi mettre en tête de chaque fichier des métadonnées pour faciliter la recherche.

    Cela permet de séparer l’essentiel du travail, au lieu d’un enchevêtrement du type « faire de la recherche et stocker en répétant le format du document final », en deux tâches plus cohérentes : « rechercher des faits et découvertes utiles au document » et « assembler le document ».

    Ce n’est pas une solution complète, mais comme lorsqu’un humain travaille, cela améliore la réutilisabilité des découvertes.

  • Est-ce que ça ne s’applique pas aussi aux humains ? C’est justement pour ça que les enfants jouent au « téléphone arabe » et voient comment le message se déforme. La solution, c’est de fournir une source unique de vérité.

  • Je suis en train de construire des outils pour lutter contre ce type de dégradation : https://github.com/JigSpec/JigSpec

  • J’ai vraiment aimé la méthodologie d’évaluation ici. Elle teste la fidélité en faisant faire un aller-retour à une chaîne d’étapes réversibles.

    J’ai trouvé frappant que même les modèles de pointe accumulent des erreurs sur des tâches qui, en apparence, semblent faciles à traiter pour un ordinateur.

    Je me demande si les meilleurs résultats obtenus en Python sont simplement un artefact d’une évaluation spécialisée Python, ou si cela se généralise à d’autres langages courants généralistes, et si cela vient de certains éléments particuliers du processus d’entraînement.

  • On savait déjà en grande partie que les modèles n’échouent pas à cause d’une multitude de petites erreurs, d’un « millier de coupures », mais à cause d’échecs catastrophiques dans quelques tours, où ils peuvent perdre d’un coup 10 à 30 points ou plus après avoir presque parfaitement reconstruit le contenu dans d’autres tours.

    De même, on savait déjà que, pour les modèles faibles, la dégradation vient surtout de suppressions de contenu, alors que pour les modèles de pointe elle vient surtout de corruptions du contenu. C’est justement pour cela qu’on passe notre temps à ajuster le harness, la température, etc.