La sortie de l’agent IA est-elle médiocre ? Le problème réside dans votre réticence à « brûler » des jetons.
TechFlow SélectionTechFlow Sélection
La sortie de l’agent IA est-elle médiocre ? Le problème réside dans votre réticence à « brûler » des jetons.
Le problème ne vient pas des prompts !
Dédié à des analyses Web3 approfondiesAuteur : Systematic Long Short
Traduction et adaptation : TechFlow
Introduction de TechFlow : L’idée centrale de cet article tient en une seule phrase : la qualité des sorties d’un agent IA est directement proportionnelle au nombre de jetons (tokens) que vous y consacrez.
L’auteur ne se contente pas d’exposer une théorie abstraite : il propose deux méthodes concrètes, immédiatement applicables dès aujourd’hui, et délimite clairement la frontière au-delà de laquelle l’augmentation du budget en jetons ne fonctionne plus — à savoir les « problèmes de nouveauté ».
Pour les lecteurs qui utilisent déjà des agents pour écrire du code ou exécuter des workflows, cet article offre une densité d’information et une praticabilité exceptionnelles.
Introduction
Bon, avouons-le : ce titre attire effectivement l’attention — mais ce n’est vraiment pas une blague.
En 2023, alors que nous utilisions déjà les grands modèles linguistiques (LLM) pour générer du code en production, nos collègues restaient bouche bée. À l’époque, la croyance dominante était que les LLM ne produisaient que des résultats inutilisables. Or, nous savions quelque chose que personne d’autre n’avait encore compris : la qualité des sorties d’un agent dépend directement du nombre de jetons investis. C’est aussi simple que cela.
Vous pouvez le vérifier vous-même en réalisant quelques expériences. Demandez à un agent de résoudre une tâche de programmation complexe et peu courante — par exemple, implémenter entièrement depuis zéro un algorithme d’optimisation convexe avec contraintes. Exécutez d’abord la tâche avec le niveau de réflexion minimal ; puis passez au niveau maximal, afin que l’agent relise son propre code et identifie autant de bogues que possible. Testez également les niveaux intermédiaire et élevé. Vous constaterez intuitivement que le nombre de bogues diminue de façon monotone à mesure que le budget en jetons augmente.
Cela ne surprend guère, n’est-ce pas ?
Plus il y a de jetons, moins il y a d’erreurs. Vous pouvez pousser ce raisonnement encore plus loin : c’est précisément cette logique simplifiée qui sous-tend la plupart des outils de relecture de code (code review). En changeant complètement le contexte — par exemple, en demandant à l’agent d’analyser ligne par ligne le code afin de détecter toute erreur potentielle — vous parviendrez à identifier la quasi-totalité, voire la totalité, des bogues. Ce processus peut être répété dix fois, cent fois, chaque itération examinant le code sous un angle différent ; à la fin, vous aurez ainsi mis au jour tous les bogues existants.
Cette idée selon laquelle « augmenter le budget en jetons améliore la qualité de l’agent » est étayée par des preuves concrètes : les équipes capables de faire écrire du code directement en production à un agent sont soit des fournisseurs de modèles de base, soit des entreprises disposant de ressources financières extrêmement importantes.
Ainsi, si vous êtes encore frustré par l’incapacité de votre agent à produire du code opérationnel, disons-le clairement : le problème vient de vous — ou plutôt, de votre portefeuille.
Comment savoir si votre budget en jetons est suffisant
J’ai déjà consacré un article entier à expliquer que le problème ne réside absolument pas dans l’architecture (le « harness ») que vous avez conçue : « garder les choses simples » permet tout à fait d’obtenir des résultats excellents, et je maintiens pleinement cette position. Vous avez lu cet article, appliqué ses recommandations — et pourtant, vous restez profondément déçu par les sorties de votre agent. Vous m’avez envoyé un message privé (DM), que j’ai bien lu… sans répondre.
Cet article est ma réponse.
Dans la grande majorité des cas, les mauvaises performances de votre agent — ou son incapacité à résoudre un problème — découlent simplement d’un budget en jetons insuffisant.
Le nombre de jetons requis pour résoudre un problème dépend entièrement de son ampleur, de sa complexité et de son caractère novateur.
« Combien font 2 + 2 ? » ne nécessite qu’un très petit nombre de jetons.
« Écris-moi un bot capable de scanner l’ensemble des marchés sur Polymarket et Kalshi, d’identifier ceux qui sont sémantiquement similaires et devraient être réglés autour du même événement, de définir des bornes d’absence d’arbitrage, puis d’exécuter automatiquement des transactions à très faible latence dès qu’une opportunité d’arbitrage apparaît » — cela requiert un budget en jetons massif.
Dans notre pratique, nous avons observé un phénomène intéressant.
Lorsqu’on consacre un budget en jetons suffisamment élevé aux problèmes liés à l’ampleur et à la complexité, l’agent parvient toujours à les résoudre. Autrement dit, si vous souhaitez construire un système extrêmement complexe, comportant de nombreux composants et lignes de code, il suffit d’y injecter assez de jetons pour que ces problèmes soient intégralement résolus.
Il existe toutefois une exception mineure, mais cruciale.
Votre problème ne doit pas être trop novateur. À ce stade, aucune quantité de jetons ne permet de résoudre un « problème de nouveauté ». Un budget en jetons suffisant peut ramener à zéro les erreurs dues à la complexité, mais il ne permettra jamais à un agent d’inventer ex nihilo quelque chose qu’il ignore totalement.
Ce constat nous a d’ailleurs soulagés.
Nous avons consacré d’énormes efforts — et brûlé une quantité phénoménale de jetons — afin de tester la capacité d’un agent à reconstruire, presque sans aucune indication préalable, un processus d’investissement institutionnel. Cette expérience visait notamment à évaluer combien d’années nous séparent encore, en tant que chercheurs en finance quantitative, d’une substitution complète par l’IA. Le résultat fut sans appel : l’agent s’est révélé incapable de reproduire un processus d’investissement institutionnel crédible. Nous pensons que cela s’explique en partie par le fait que ce type de processus n’apparaît tout simplement pas dans les données d’entraînement.
Si votre problème est novateur, ne comptez donc pas sur un simple surcroît de jetons pour le résoudre. Vous devrez guider vous-même le processus d’exploration. Mais une fois la solution identifiée, vous pouvez sans hésiter augmenter le budget en jetons pour son exécution — quelle que soit la taille du code ou la complexité des composants, cela ne posera aucun problème.
Voici une règle heuristique simple : le budget en jetons devrait croître proportionnellement au nombre de lignes de code.
Que font exactement les jetons supplémentaires ?
Dans la pratique, les jetons supplémentaires améliorent la qualité du travail d’ingénierie de l’agent selon plusieurs axes :
- Ils lui permettent de consacrer davantage de temps à la réflexion au sein d’une même tentative, augmentant ainsi ses chances de détecter lui-même des erreurs logiques. Plus la réflexion est approfondie, meilleure est la planification, et plus élevée la probabilité de réussir du premier coup.
- Ils autorisent plusieurs tentatives indépendantes, empruntant chacune des chemins de résolution différents. Certains de ces chemins s’avèrent plus efficaces que d’autres. Permettre plusieurs essais donne à l’agent la possibilité de sélectionner la solution optimale.
- De même, davantage de tentatives de planification indépendantes lui permettent d’abandonner les pistes faibles et de conserver uniquement celles qui semblent les plus prometteuses.
- Un budget accru en jetons lui permet également de critiquer son propre travail antérieur dans un contexte entièrement nouveau, offrant ainsi une véritable opportunité d’amélioration, plutôt que de le laisser coincé dans une « inertie de raisonnement ».
- Et enfin — mon point préféré — davantage de jetons signifient qu’il peut utiliser des tests et des outils pour valider ses résultats. Exécuter effectivement le code pour vérifier qu’il fonctionne constitue la méthode la plus fiable pour confirmer la justesse de la réponse.
Cette logique fonctionne parce que les échecs d’ingénierie d’un agent ne sont pas aléatoires. Ils résultent presque systématiquement d’un choix prématuré d’une mauvaise piste, de l’absence de vérification précoce de la faisabilité de cette piste, ou d’un budget insuffisant pour récupérer et revenir en arrière une fois l’erreur détectée.
C’est tout simplement cela. Les jetons représentent littéralement la qualité des décisions que vous achetez. Imaginez-les comme du temps de recherche : si vous demandez à une personne de résoudre sur-le-champ un problème difficile, la qualité de sa réponse se dégradera sous la pression temporelle.
La recherche, au fond, consiste à produire cette chose fondamentale qu’est la « connaissance de la bonne réponse ». Les humains dépensent du temps biologique pour obtenir de meilleures réponses ; les agents dépensent du temps de calcul — autrement dit, des jetons — pour obtenir de meilleures réponses.
Comment améliorer votre agent
Vous êtes peut-être encore sceptique, mais de nombreux articles scientifiques viennent étayer ce point de vue. Honnêtement, la simple existence d’un « bouton de réglage de la réflexion » constitue à elle seule la preuve dont vous avez besoin.
Un article particulièrement remarquable montre comment, après avoir entraîné un modèle sur un petit jeu d’échantillons de raisonnement soigneusement sélectionnés, les chercheurs ont forcé ce dernier à poursuivre sa réflexion là où il aurait naturellement voulu s’arrêter — en ajoutant simplement le mot « Wait » (« Attends ») à chaque point d’arrêt prévu. Ce seul ajout a fait passer le score sur un benchmark donné de 50 % à 57 %.
Je vais être franc : si vous vous plaignez régulièrement de la médiocrité du code produit par vos agents, il est fort probable que même le niveau maximal de réflexion autorisé lors d’une seule tentative ne vous suffise pas.
Je vous propose donc deux solutions extrêmement simples.
Solution simple n°1 : WAIT (Attends)
La chose la plus simple que vous puissiez faire dès aujourd’hui : mettre en place une boucle automatique — une fois la construction terminée, demandez à l’agent de relire (review) son travail N fois dans un contexte entièrement nouveau, en corrigeant chaque erreur détectée.
Si vous constatez que cette astuce simple améliore significativement les performances de votre agent, vous aurez au moins compris que le problème était purement lié au volume de jetons utilisé — bienvenue au club des « brûleurs de jetons » !
Solution simple n°2 : VERIFY (Vérifie)
Faites en sorte que l’agent vérifie très tôt et très fréquemment son propre travail. Écrivez des tests permettant de prouver que la piste choisie fonctionne effectivement. Cette méthode est particulièrement utile pour les projets hautement complexes et profondément imbriqués — une fonction pouvant être appelée par de nombreuses autres fonctions en aval. Détecter une erreur en amont vous fera économiser une quantité considérable de temps de calcul (de jetons) ultérieurement. Si possible, placez donc des « points de vérification » à divers endroits tout au long du processus de construction.
Une section de code est-elle achevée ? L’agent principal déclare avoir terminé ? Faites-la vérifier par un second agent. Des flux de raisonnement indépendants permettent de compenser les biais systémiques.
C’est à peu près tout. Je pourrais encore beaucoup écrire sur ce sujet, mais je suis convaincu que la simple prise de conscience de ces deux principes — et leur application rigoureuse — résoudra 95 % de vos problèmes. Je crois profondément qu’il faut pousser à l’extrême la maîtrise des choses simples, avant d’y ajouter progressivement la complexité nécessaire.
J’ai mentionné que la « nouveauté » constituait un problème intrinsèquement insoluble par l’augmentation du budget en jetons. Je tiens à insister une nouvelle fois sur ce point, car vous tomberez inévitablement dans ce piège — puis viendrez me dire, en pleurant, que « brûler plus de jetons ne sert à rien ».
Lorsque le problème que vous cherchez à résoudre n’apparaît pas dans l’ensemble d’entraînement, c’est vous qui devez véritablement fournir la solution. Ainsi, l’expertise métier demeure plus que jamais essentielle.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@systematicls
