Pourquoi les agents d’IA épuisent le budget sans terminer leur travail, et comment y remédier
Découvrez pourquoi les agents d’appel d’outils tournent en boucle lorsque le statut « terminé » n’est pas défini, où vont les tokens dépensés, et quelles conditions d’arrêt sont plus efficaces que la simple augmentation des plafonds de pas ou de budget.
Considérons un exemple modeste : une exécution l’après-midi sans surveillance qui coûte 40 dollars et ne produit rien. Selon les normes des opérations d’agent, il s’agit d’une somme négligeable ; les équipes se racontent des histoires d’exécutions nocturnes non surveillées dont le coût atteignait des chiffres à quatre chiffres. La taille de la facture n’est pas l’aspect intéressant. Ce qui compte, c’est ce qu’elle a permis d’acheter. L’agent n’était pas bloqué et aucun erreur pouvant servir de référence n’a été générée. Il était occupé tout le temps, sans pour autant accomplir quoi que ce soit.
À quoi ressemble un agent dérouté dans les transcriptions
Ouvrez le journal d’un agent qui a dévié de sa trajectoire et vous trouverez rarement un suivi d’erreurs. Ce que vous lirez ressemble à celui d’un employé consciencieux qui a perdu de vue l’objectif initial de sa tâche.
L’agent ouvre un fichier et en fait un résumé, puis ouvre le même contenu présenté de manière légèrement différente et en fait à nouveau un résumé. Il effectue une recherche, juge que la réponse n’est pas tout à fait satisfaisante, et réitère la requête en changeant quelques mots. Chaque étape, considérée isolément, est justifiable. C’est précisément pour cette raison que ce schéma est difficile à détecter en parcourant rapidement le texte : aucune étape ne semble anormale. La recherche ne converge tout simplement jamais.
Pourquoi le modèle décide quand il a terminé
Ce comportement a une cause concrète qu’il est utile de comprendre si l’on développe ou gère des agents. Chaque réponse d’un modèle capable d’appeler des outils, comme Claude, se termine par une raison d’arrêt tirée d’une liste courte et fixe. Le guide d’Anthropic sur la gestion des raisons d’arrêt couvre plusieurs cas ; deux d’entre eux sont particulièrement importants pour les boucles d’agents. Le premier indique que le modèle estime avoir terminé son travail :
"stop_reason": "end_turn"
Le second indique qu’il souhaite invoquer un outil et continuer :
"stop_reason": "tool_use"
Une boucle d’agent est un code d’application ordinaire. Elle envoie une requête, exécute n’importe quel outil demandé par le modèle, renvoie le résultat et répète ce processus jusqu’à ce que le modèle retourne end_turn. Rien en dehors du modèle ne déclare que la tâche est terminée. À chaque tour, c’est le modèle lui-même qui effectue cette appel pour déterminer si le travail à accomplir semble achevé. D’autres raisons d’arrêt existent, comme atteindre la limite de tokens de sortie, mais il s’agit d’interruptions et non d’une décision indiquant que la tâche est terminée.
Ce seul fait explique l’échec global. Lorsque l’objectif est trop vague pour que le modèle puisse déterminer qu’il a été atteint, il y a toujours autre chose à vérifier, et la boucle se poursuit jusqu’à ce qu’un facteur externe, généralement une alerte budgétaire, intervienne. Pour en savoir plus sur la conception de boucles au niveau du code, consultez les boucles agentiques bornées et les modèles TypeScript fiables pour l’utilisation d’outils LLM.
Quelle est la fréquence de ce phénomène
Il est tentant de considérer cela comme une particularité d’un outil donné. Cependant, des preuves plus larges suggèrent le contraire. Une étude de la RAND Corporation, basée sur des entretiens menés avec 65 scientifiques et ingénieurs en données expérimentés, indique que le taux d’échec des projets d’IA dépasse 80 pour cent, soit environ le double de celui du travail informatique traditionnel. Cette étude porte sur les projets d’IA en général, et non spécifiquement sur des agents, mais les boucles qui tournent sans apporter de valeur font partie des facteurs courants et quotidiens responsables de ce type de gaspillage. Elles ne figurent jamais dans les discours principaux des conférences ; on les trouve plutôt sur les factures.
Des versions plus détaillées de cet article circulent également. Un rapport fréquemment cité décrit un boucle récursive dont les dépenses ont atteint cinq chiffres avant que quiconque n’intervienne. Ce chiffre n’a pas été vérifié de manière indépendante, et tout nombre aussi élevé mérite un certain scepticisme. Le mécanisme en question existe cependant bel et bien, et il ne fait que s’aggraver : la même boucle qui dépense 40 dollars en une après-midi peut en dépenser 4 000 pendant un week-end sans surveillance.
Où s’accumulent les dépenses
Lorsque l’on examine ces coûts hors contrôle et que l’on les compare à ce que rapportent les opérateurs de grandes flottes d’agents, on constate que l’argent a tendance à se concentrer dans quelques endroits bien précis :
- Recherche sur le web sans limite. Chaque page chargée et chaque recherche répétée a un coût. Sans plafond, la recherche infinie se poursuit tant que le modèle pense qu’une autre source utile pourrait exister.
- Un modèle coûteux pour des tâches simples. Les modèles de pointe sont plus chers car ils raisonnent mieux, mais de nombreuses actions d’agent, comme le reformatage d’un fichier, la vérification d’un statut ou la tentative répétée d’une appel, n’ont pas besoin de ces capacités. Un modèle plus petit pourrait les gérer pour une fraction du prix.
- Des conversations qui ne se terminent jamais. Un agent travaillant au sein d’une longue conversation retraite l’intégralité de son historique accumulé à chaque tour, ce qui rend une conversation vieille de plusieurs semaines plus chère par requête aujourd’hui qu’au début, quel que soit la taille de la requête. Le cache des prompts peut atténuer cet effet si votre fournisseur le prend en charge, mais le contexte continue de croître.
Aucun de ces problèmes n’est particulièrement complexe. Ensemble, ils se comportent comme une abonnement oublié qui facture en fonction du nombre d’opérations effectuées plutôt qu’en fonction du mois. Pour une vue structurée de la manière dont ces coûts s’accumulent, l’article sur pourquoi les coûts de l’IA agente explosent offre des explications plus approfondies.
Résolvez la condition d’arrêt, pas le plafond
Après une exécution coûteuse, la réaction instinctive est d’augmenter les limites de pas ou de dépenses. Cela a généralement l’effet inverse, car un plafond plus élevé ne fait que permettre au même cycle bloqué de tourner plus longtemps avant de heurter cette limite. Ce qui aide réellement, c’est de donner au cycle un moyen de détecter que les progrès se sont arrêtés, ce qui est une question différente de savoir s’il a épuisé son quota de pas.
Placer la ligne d’arrivée dans l’objectif
Définissez ce qu’est « terminé » comme faisant partie de la tâche, et non en tant que considération ultérieure. Une instruction comme « corriger le test qui échoue » laisse place à des tâches secondaires telles que nettoyer les imports ou reformater tout le fichier. « Faire en sorte que ce seul test passe, puis arrêter » fournit un point final que le modèle peut réellement détecter. Plus le critère de finition est observable, plus il est facile pour le modèle de retourner end_turn au bon moment.
Rendre les résultats des outils sans équivoque
Les retours des outils doivent indiquer clairement si une action a réussi ou échoué. Un résultat flou est interprété par l’agent comme une invitation à réessayer, et non comme un signal d’arrêt. Des champs de statut explicites et des messages d’erreur clairs éliminent l’incertitude qui pousse à réessayer.
Détecter la répétition plutôt que de compter les étapes
Ajouter un point de contrôle humain et une limite stricte de dépenses
Toute tâche laissée sans surveillance pendant plus de quelques minutes doit prévoir un moment où un humain vérifie les progrès. Les mécanismes de surveillance automatisés viennent compléter cela. Par exemple, gh-aw de GitHub propose une barrière de sécurité que l’on peut configurer pour arrêter un flux de travail dès que ses dépenses dépassent une limite prédéfinie, au lieu de laisser la détection aux seules personnes qui consultent la facture. Un tel mécanisme constitue un filet de sécurité, mais il ne remplace pas une condition d’arrêt adéquate ; il limite cependant les dommages en cas de défaillance des autres systèmes.
L’activité n’est pas synonyme de progrès
La partie la plus inquiétante d’un exécution débridée n’est pas le coût, mais plutôt la confiance excessive. Les résultats générés par l’agent ne présentent jamais d’hésitations et n’admettent jamais d’incertitude quant à l’utilité du travail effectué. Il produit des étapes plausibles jusqu’à ce qu’un facteur externe, souvent une personne intriguée par une facture inattendue, vienne l’arrêter.
L’enseignement n’est pas de ne pas faire confiance aux agents de manière générale. Il s’agit d’arrêter de confondre le mouvement avec le progrès, tant dans les systèmes automatisés que dans de nombreux travaux humains.
Points clés
- Dans une boucle d’appel d’outils, c’est le modèle seul qui décide quand il a terminé en renvoyant
end_turn; s’il n’existe pas de point final reconnaissable, il ne le fera peut-être jamais. - Les dépenses incontrôlées se concentrent dans des recherches sans limite, des modèles surdimensionnés pour des tâches simples, des threads en croissance continue et des tâches planifiées oubliées.
- Augmenter les budgets ou les limites de pas ne fait qu’ajourner la même défaillance ; il convient plutôt de définir explicitement la fin de la tâche.
- Renvoyez des résultats d’outils sans ambiguïté et détectez les appels répétés identiques aux outils, plutôt que de vous fier au comptage des pas.
- Pour les exécutions non supervisées, combinez des points de contrôle humains avec une limite stricte de dépenses.
Lectures complémentaires
- Agents d’IA vs. IA agente : une feuille de route pratique pour le déploiement en entreprise — Découvrez comment distinguer les agents d’IA des systèmes d’IA agente et comment appliquer un cadre structuré pour choisir les voies de déploiement, gérer les risques et planifier l’architecture future.
- Chatbot vs. agent d’IA : ce qui les différencie réellement au-delà des LLM — Comprenez pourquoi la véritable différence entre les chatbots et les agents d’IA réside dans l’architecture du système qui les entoure — outils, planification et actions — et non dans le LLM lui-même.