La qualité des sorties de l'agent IA est corrélée à la brûlure de jetons

Auteur : Systematic Long Short

Traduction : Deep潮 TechFlow

DeepChao Summary : L'argument central de cet article se résume à une seule phrase : la qualité des sorties d'un agent IA est proportionnelle au nombre de tokens que vous y investissez.

L'auteur ne parle pas de théories générales, mais propose deux méthodes concrètes que vous pouvez commencer à utiliser dès aujourd'hui, et définit clairement les limites que les jetons ne peuvent pas franchir — le « problème de la nouveauté ».

Pour les lecteurs qui utilisent des agents pour écrire du code ou exécuter des flux de travail, la densité d'informations et la faisabilité sont très élevées.

D'accord, vous devez admettre que ce titre est vraiment accrocheur — mais sérieusement, ce n'est pas une blague.

En 2023, lorsque nous utilisions encore des LLM pour produire du code en environnement de production, tout le monde était stupéfait, car la perception générale à l'époque était que les LLM ne pouvaient produire que des déchets inutilisables. Mais nous savions une chose que les autres n'avaient pas réalisée : la qualité des sorties d'un Agent est une fonction du nombre de tokens que vous investissez. C'est aussi simple que cela.

Vous pouvez le constater vous-même en effectuant quelques expériences. Faites accomplir à l’agent une tâche de programmation complexe et un peu niche — par exemple, implémenter depuis zéro un algorithme d’optimisation convexe avec contraintes. Commencez avec le niveau de réflexion le plus bas ; puis passez au niveau de réflexion le plus élevé, et demandez-lui de revoir son propre code pour voir combien de bogues il peut détecter. Essayez également les niveaux intermédiaires et élevés. Vous verrez intuitivement que le nombre de bogues diminue de manière monotone avec la quantité de tokens dépensée.

C'est facile à comprendre, n'est-ce pas ?

Plus de tokens = moins d'erreurs. Vous pouvez pousser cette logique plus loin : c'est essentiellement l'idée centrale (simplifiée) derrière les produits d'analyse de code. Dans un tout autre contexte, investissez une quantité massive de tokens (par exemple, faites-les analyser le code ligne par ligne pour détecter les bogues à chaque ligne) — cela permettra de repérer la grande majorité, voire la totalité, des bogues. Ce processus peut être répété dix fois, cent fois, en examinant la base de code sous un « angle différent » à chaque fois, et vous finirez par déceler tous les bogues.

L'idée selon laquelle « plus de tokens sont brûlés, meilleure est la qualité de l'agent » est soutenue par une preuve empirique : les équipes prétendant pouvoir écrire entièrement du code avec un agent et le déployer directement en production sont soit des fournisseurs de modèles de base, soit des entreprises disposant de fonds extrêmement importants.

Alors, si vous êtes encore en train de vous débattre parce que l'agent ne génère pas de code de qualité production — disons-le franchement, le problème vient de vous. Ou plus précisément, de votre portefeuille.

J'ai écrit un article entier affirmant que le problème ne venait absolument pas de votre cadre (harness) — on peut tout de même produire d'excellents résultats en gardant les choses simples, et je maintiens toujours cette opinion. Vous avez lu cet article, avez suivi les conseils, mais êtes toujours déçu par les sorties de l'Agent. Vous m'avez envoyé un message privé, j'ai lu le message mais n'ai pas répondu.

This one is the reply.

Votre Agent performe mal et ne résout pas les problèmes, dans la plupart des cas, parce que vous n'avez pas suffisamment brûlé de Token.

Le nombre de tokens requis pour résoudre un problème dépend entièrement de la taille, de la complexité et de la nouveauté de ce problème.

« 2 + 2 égalent combien ? » Cela ne nécessite pas beaucoup de tokens.

« Écris-moi un bot qui scanne tous les marchés entre Polymarket et Kalshi, identifie les marchés sémantiquement similaires qui devraient être réglés sur le même événement, définit des limites d’arbitrage sans risque, et effectue automatiquement des transactions à faible latence dès qu’une opportunité d’arbitrage apparaît » — cela nécessite de brûler énormément de tokens.

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

Si vous investissez suffisamment de tokens pour traiter les problèmes posés par l'échelle et la complexité, l'agent pourra toujours les résoudre. Autrement dit, si vous souhaitez construire quelque chose d'extrêmement complexe, avec de nombreux composants et lignes de code, tant que vous injectez suffisamment de tokens dans ces problèmes, ils finiront par être entièrement résolus.

Il y a une petite mais importante exception.

Votre question ne peut pas être trop originale. À ce stade, aucune quantité de tokens ne peut résoudre le problème de « nouveauté ». Un nombre suffisant de tokens peut réduire à zéro les erreurs dues à la complexité, mais ne permet pas à un agent d'inventer quelque chose qu'il ne connaît pas.

Cette conclusion nous rassure en réalité.

Nous avons consacré énormément d'efforts, brûlé — un nombre incroyablement élevé — de jetons, pour essayer de voir si un agent pouvait reconstituer un processus d'investissement institutionnel sans aucune orientation. Cette partie de l'expérience visait à comprendre à quelle distance nous (en tant que chercheurs en quantitatif) sommes encore de être entièrement remplacés par l'IA. Il s'est avéré que l'agent ne peut même pas approcher un processus d'investissement institutionnel crédible. Nous pensons que cette incapacité provient du fait qu'ils n'ont jamais été exposés à ce type de processus — c'est-à-dire que les processus d'investissement institutionnel n'existent tout simplement pas dans les données d'entraînement.

Donc, si votre problème est novateur, ne comptez pas sur l'accumulation de tokens pour le résoudre. Vous devez guider vous-même le processus d'exploration. Mais une fois que vous avez déterminé la solution à mettre en œuvre, vous pouvez librement accumuler des tokens pour l'exécuter — peu importe la taille du codebase ou la complexité des composants.

Voici un principe heuristique simple : le budget de jetons devrait augmenter proportionnellement au nombre de lignes de code.

En pratique, les jetons supplémentaires améliorent généralement la qualité du projet Agent de plusieurs manières :

Passez plus de temps à raisonner lors de la même tentative, afin d'avoir l'occasion de découvrir vous-même les erreurs logiques. Plus la réflexion est approfondie = meilleure la planification = plus élevée la probabilité de réussir du premier coup.

Permettez-lui de faire plusieurs tentatives indépendantes, en empruntant des chemins de résolution différents. Certains chemins sont meilleurs que d'autres. En autorisant plusieurs tentatives, il pourra choisir l'option optimale.

De même, davantage d'initiatives indépendantes tentent de lui permettre d'abandonner les directions faibles et de conserver les plus prometteuses.

Plus de tokens lui permettent de critiquer son propre travail dans un tout nouveau contexte, lui offrant une chance de s'améliorer plutôt que de rester bloqué dans une « inertie de raisonnement ».

Bien sûr, et ce que j'aime le plus : plus de tokens signifient qu'ils peuvent être vérifiés avec des tests et des outils. Exécuter réellement le code pour voir s'il fonctionne est le moyen le plus fiable de confirmer que la réponse est correcte.

Cette logique fonctionne parce que l'échec ingénierie de l'Agent n'est pas aléatoire. Il est presque toujours dû à un choix erroné prématuré de chemin, à l'absence de vérification de la faisabilité de ce chemin (au début), ou à un budget insuffisant pour rétablir ou revenir en arrière après avoir détecté une erreur.

C'est ainsi que l'histoire se déroule. Le token est littéralement la qualité de la décision que vous achetez. Imaginez-le comme un travail de recherche : si vous demandez à quelqu'un de répondre immédiatement à une question difficile, la qualité de la réponse diminue à mesure que la pression temporelle augmente.

La recherche, au fond, est ce qui produit la base même de « connaître la réponse ». Les humains dépensent du temps au sens biologique pour produire de meilleures réponses, tandis que les agents dépensent davantage de temps de calcul pour produire de meilleures réponses.

Vous pourriez encore être sceptique, mais de nombreux articles scientifiques soutiennent ce point ; franchement, l'existence même du bouton de réglage de l'inférence constitue la preuve dont vous avez besoin.

Un article que j'aime particulièrement : les chercheurs ont entraîné un modèle avec un petit ensemble d'exemples de raisonnement soigneusement sélectionnés, puis ont utilisé une méthode pour forcer le modèle à continuer de réfléchir lorsqu'il voulait s'arrêter — en ajoutant « Wait » (attendez) à l'endroit où il souhaitait s'arrêter. Ce seul changement a fait passer une mesure de référence de 50 % à 57 %.

Je veux être aussi clair que possible : si vous vous plaignez toujours que le code écrit par l'Agent est médiocre, le niveau de réflexion maximal unique est probablement encore insuffisant pour vous.

Je vous propose deux solutions très simples.

Méthode simple 1 : WAIT (attendre)

La chose la plus simple que vous pouvez commencer à faire aujourd’hui : mettre en place un cycle automatique — une fois construit, faites en sorte que l’Agent révise N fois avec un nouveau contexte, et corrigez chaque problème détecté.

Si tu as constaté que ce simple astuce améliore l'efficacité de ton agent engineering, alors tu as au moins compris que ton problème n'était qu'une question de nombre de tokens — rejoins donc le club de la consommation de tokens.

Deuxième méthode simple : VERIFY

Vérifiez régulièrement et précocement le travail de l'Agent. Écrivez des tests pour prouver que le chemin sélectionné fonctionne réellement. Cela est particulièrement utile pour les projets hautement complexes et profondément imbriqués — une fonction peut être appelée par de nombreuses autres fonctions en aval. Détecter les erreurs en amont vous fera économiser une quantité considérable de temps de calcul (tokens). Par conséquent, si possible, installez des « points de vérification » tout au long du processus de construction.

Après avoir rédigé un passage, l'agent principal dit « C'est fait » ? Faites vérifier par un second agent. Les flux de réflexion non liés peuvent couvrir les sources de biais systémiques.

C'est à peu près tout. Je pourrais écrire beaucoup plus sur ce sujet, mais je pense que simplement prendre conscience de ces deux points et les mettre en œuvre efficacement vous aidera à résoudre 95 % des problèmes. Je suis convaincu que faire parfaitement les choses simples, puis ajouter de la complexité selon les besoins, est la meilleure approche.

J'ai mentionné que la « nouveauté » est un problème que les tokens ne peuvent pas résoudre, et je veux insister à nouveau, car vous finirez inévitablement par tomber dans ce piège, puis venir vous plaindre auprès de moi en disant que cumuler des tokens ne sert à rien.

Lorsque le problème que vous souhaitez résoudre n'est pas dans l'ensemble d'entraînement, vous êtes la personne qui doit véritablement fournir une solution. Ainsi, les connaissances spécialisées dans le domaine restent extrêmement importantes.