L'agent IA produit des déchets ? Le problème, c'est que tu n'es pas prêt à dépenser des tokens

Auteur : Systematic Long Short

Traduction : Deep潮 TechFlow

Deep潮 Introduction : Le point central de cet article est une seule phrase : la qualité de sortie d’un Agent IA est proportionnelle au nombre de Tokens que vous y investissez.

L’auteur ne parle pas en termes abstraits, mais propose deux méthodes concrètes que vous pouvez commencer à utiliser dès aujourd’hui, tout en délimitant clairement la frontière au-delà de laquelle le « problème de nouveauté » empêche d’accumuler plus de Tokens.

Pour les lecteurs utilisant des Agents pour coder ou exécuter des workflows, l’information est dense et directement exploitable.

Introduction

Bon, il faut reconnaître que ce titre est vraiment accrocheur — mais sérieusement, ce n’est pas une blague.

En 2023, alors que nous utilisons encore des LLM pour produire du code en production, tout le monde était sidéré, car la perception dominante était que les LLM ne pouvaient que générer des déchets inutilisables. Mais nous savons une chose que d’autres ignorent : la qualité de sortie d’un Agent dépend du nombre de Tokens que vous lui consacrez. C’est aussi simple que ça.

Vous pouvez le vérifier par vous-même en faisant quelques expériences. Par exemple, demander à un Agent de réaliser une tâche complexe et peu courante, comme implémenter de zéro un algorithme d’optimisation convexe avec contraintes. Commencez avec un niveau de réflexion minimal ; puis passez au niveau maximal, en lui demandant de revoir son propre code pour détecter des bugs. Essayez aussi un niveau intermédiaire. Vous constaterez intuitivement que le nombre de bugs diminue de façon monotone avec l’augmentation du nombre de Tokens investis.

Ce n’est pas difficile à comprendre, n’est-ce pas ?

Plus de Tokens = Moins d’erreurs. Vous pouvez pousser cette logique encore plus loin : c’est essentiellement le principe derrière la revue de code automatisée (version simplifiée). Dans un contexte totalement nouveau, en investissant une quantité massive de Tokens (par exemple, en lui demandant d’analyser ligne par ligne le code pour détecter d’éventuels bugs), vous pouvez repérer la majorité, voire la totalité, des bugs. Ce processus peut être répété dix, cent fois, en adoptant « différents angles » pour examiner le code, jusqu’à ce que tous les bugs soient identifiés.

L’idée selon laquelle « plus de Tokens améliore la qualité de l’Agent » est également étayée par des preuves : les équipes qui prétendent faire écrire tout le code en utilisant uniquement des Agents pour le déploiement en production sont soit des fournisseurs de modèles de base, soit des entreprises disposant de ressources financières très importantes.

Donc, si vous avez du mal à faire produire à votre Agent un code prêt pour la production — pour être franc — le problème vient de vous. Ou plutôt, de votre budget.

Comment savoir si vous avez investi assez de Tokens

J’ai déjà écrit un article entier pour expliquer que le problème ne vient pas de votre cadre (harness). « Rester simple » permet aussi de produire des résultats excellents, et je maintiens cette position. Si vous avez lu cet article, suivi ses conseils, mais que vous êtes toujours déçu par la sortie de votre Agent, envoyez-moi un DM. Je l’ai lu, mais je n’ai pas répondu.

Ce message est une réponse.

Dans la majorité des cas, la mauvaise performance ou l’incapacité à résoudre un problème vient d’un investissement insuffisant en Tokens.

La quantité de Tokens nécessaire pour résoudre un problème dépend entièrement de sa taille, de sa complexité et de sa nouveauté.

Par exemple, « 2+2 = ? » ne nécessite pas beaucoup de Tokens.

En revanche, « Crée-moi un bot capable de scanner tous les marchés entre Polymarket et Kalshi, d’identifier ceux qui sont sémantiquement similaires et qui devraient être réglés dans le même sens ou dans des sens opposés, en fixant une limite d’arbitrage, et d’effectuer des trades à faible latence dès qu’une opportunité apparaît » — cela demande une quantité énorme de Tokens.

Nous avons constaté quelque chose d’intéressant en pratique.

Si vous investissez suffisamment de Tokens pour traiter des problèmes liés à leur taille et leur complexité, l’Agent pourra toujours les résoudre. En d’autres termes, si vous souhaitez construire quelque chose de très complexe, avec de nombreux composants et lignes de code, en y investissant suffisamment de Tokens, vous pourrez finir par tout résoudre.

Il y a une petite mais importante exception.

Votre problème ne doit pas être trop novateur. À ce stade, aucune quantité de Tokens ne peut résoudre le « problème de nouveauté ». Les Tokens peuvent réduire à zéro les erreurs dues à la complexité, mais ne peuvent pas faire inventer à l’Agent quelque chose qu’il ne connaît pas.

Ce constat est en réalité une bonne nouvelle.

Nous avons consacré énormément d’efforts, investi énormément de Tokens — beaucoup, beaucoup — pour voir si, avec peu d’orientation, l’Agent pouvait reconstituer un processus d’investissement institutionnel. L’objectif était aussi de comprendre combien de temps il nous faudrait, en tant que chercheurs quantitatifs, pour être totalement remplacés par l’IA. Résultat : l’Agent ne peut pas approcher un processus d’investissement institutionnel crédible. La raison probable est qu’il n’a tout simplement jamais vu ce genre de processus dans ses données d’entraînement — ils n’existent pas dans ses données.

Donc, si votre problème est trop nouveau, ne comptez pas sur l’accumulation de Tokens pour le résoudre. Vous devrez guider vous-même le processus d’exploration. Mais une fois que vous avez défini une solution, vous pouvez investir en toute confiance dans le déploiement — peu importe la taille du code ou la complexité des composants.

Voici une règle heuristique simple : le budget en Tokens doit croître proportionnellement au nombre de lignes de code.

Ce que font réellement les Tokens supplémentaires

En pratique, l’investissement supplémentaire en Tokens améliore généralement la qualité de l’ingénierie de l’Agent de plusieurs façons :

Lui permettre de consacrer plus de temps à la réflexion lors d’une même tentative, lui donnant ainsi l’opportunité de découvrir des erreurs logiques. Plus la réflexion est approfondie, meilleure sera la planification, et plus la probabilité de succès augmente.

Lui permettre de faire plusieurs tentatives indépendantes, en explorant différentes solutions. Certaines seront meilleures que d’autres. En multipliant les essais, il pourra choisir la meilleure.

De même, plus de tentatives de planification indépendantes permettent à l’Agent d’abandonner les pistes faibles pour se concentrer sur celles qui ont le plus de potentiel.

Plus de Tokens permettent aussi d’utiliser un contexte entièrement nouveau pour critiquer son propre travail précédent, lui offrant une nouvelle chance d’amélioration, plutôt que de rester bloqué dans une « inertie de raisonnement ».

Et puis, ma préférée : plus de Tokens, c’est aussi la possibilité d’utiliser des tests et des outils pour vérifier le travail effectué. Exécuter le code pour voir s’il fonctionne réellement reste la méthode la plus fiable pour confirmer la correction.

Ce raisonnement fonctionne parce que l’échec de l’Agent en ingénierie n’est pas aléatoire. Il résulte presque toujours d’un choix prématuré de solution, d’un manque de vérification de la faisabilité à un stade précoce, ou d’un budget insuffisant pour corriger et revenir en arrière après avoir détecté une erreur.

L’histoire est ainsi. Les Tokens, au sens littéral, sont la qualité décisionnelle que vous achetez. Imaginez cela comme un travail de recherche : si vous demandez à une personne de répondre à une question difficile dans l’instant, la qualité de sa réponse diminue avec la pression du temps.

La recherche, en fin de compte, consiste à produire cette « connaissance de la réponse » fondamentale. Les humains consacrent du temps biologique pour produire de meilleures réponses, l’Agent consacre plus de calcul pour produire de meilleures réponses.

Comment améliorer votre Agent

Vous êtes peut-être encore sceptique, mais de nombreuses publications le soutiennent : la seule preuve dont vous avez besoin, c’est la capacité de « régler » le paramètre de « raisonnement » (reasoning).

Une étude que j’aime particulièrement a entraîné un petit ensemble d’échantillons de raisonnement soigneusement conçus, puis a forcé le modèle à continuer à réfléchir en ajoutant simplement « Wait » (attendre) là où il voulait s’arrêter. Rien qu’avec cette astuce, un benchmark est passé de 50 % à 57 %.

Je vais être clair : si vous vous plaignez que votre Agent écrit du mauvais code, il est probable que le niveau maximal de réflexion n’est pas suffisant.

Voici deux solutions très simples.

Solution 1 : WAIT (attendre)

Ce que vous pouvez faire dès aujourd’hui : mettre en place une boucle automatique — après la construction, faire en sorte que l’Agent revoie N fois son travail dans un contexte renouvelé, en corrigeant à chaque fois ses erreurs.

Si vous constatez que cette technique simple améliore la performance de votre Agent, vous comprendrez que le problème vient probablement du nombre de Tokens — alors, rejoignez le club des gros investisseurs en Tokens.

Solution 2 : VERIFY (vérifier)

Faites en sorte que l’Agent vérifie son travail dès que possible et aussi fréquemment que possible. Écrivez des tests pour prouver que le chemin choisi fonctionne réellement. C’est particulièrement utile pour des projets très complexes ou profondément imbriqués — une fonction appelée par de nombreuses autres. Pouvoir repérer les erreurs en amont vous fait économiser énormément de Tokens en calculs ultérieurs. Donc, si possible, insérez des points de vérification tout au long du processus de construction.

Une fois qu’une partie est terminée et que le principal Agent déclare que c’est bon, faites-la vérifier par un second Agent. Des flux de réflexion indépendants peuvent couvrir les biais systémiques.

Voilà, c’est tout. Je pourrais écrire encore beaucoup sur ce sujet, mais je pense que si vous comprenez ces deux points et que vous les appliquez correctement, vous résoudrez 95 % de vos problèmes. Je suis convaincu qu’en simplifiant à l’extrême, puis en ajoutant la complexité au besoin, vous progresserez.

J’ai mentionné que le « problème de nouveauté » ne peut pas être résolu par des Tokens, je tiens à le souligner encore une fois, car tôt ou tard, vous rencontrerez cette difficulté et viendrez pleurer que l’investissement en Tokens ne sert à rien.

Lorsque votre problème n’est pas dans l’ensemble d’entraînement, c’est vous le vrai responsable de fournir une solution. La connaissance spécialisée dans le domaine reste donc essentielle.