Comment nous avons éliminé en une heure 1 million de dollars par an de dépenses inutiles liées aux agents AI

Les ingénieurs de Databricks s'appuient fortement sur les agents d'IA pour simplifier et accélérer leur travail. À leur tour, ces agents ont besoin d'accéder non seulement à différents modèles de fondation, mais aussi à des serveurs MCP dotés d'outils qui permettent d'accéder aux artefacts pertinents (par exemple, les journaux système, les tables d'utilisation, les tickets d'assistance, les wikis). Dans un article de blog précédent, nous avons partagé le fait que la gestion des coûts de l'IA à grande échelle nécessite d'optimiser non seulement la sélection des modèles, mais aussi la manière dont les agents utilisent les outils. Dans cet article, nous décrivons comment nous avons recherché des économies de coûts dans l'utilisation des outils par nos agents, les défis que nous avons rencontrés en chemin, et comment le traçage OTel dans Unity Gateway a réduit à une seule heure le parcours allant de l'analyse à 1,2 million de dollars d'économies par an.

Permettre à nos développeurs de concevoir leurs propres agents a considérablement libéré la productivité, mais à mesure que l'utilisation augmentait, nous avons également été confrontés à une hausse des coûts. Nous avons commencé à étudier plusieurs pistes d'optimisation, et l'un de nos soupçons portait sur le coût caché des échecs d'appels d'outils. Plus précisément, lorsque les outils fonctionnent mal, l'agent appelant échoue rarement de manière visible. Au lieu de cela, il réessaie, fait des suppositions et finit par contourner le problème, consommant discrètement des tokens et du temps de développement tout au long du processus. Ce type de gaspillage est dangereux : de l'extérieur, la tâche se termine toujours, et un tableau de bord des coûts globaux peut afficher une hausse de 10 % des dépenses en tokens qui peut facilement être interprétée à tort comme une croissance de l'utilisation. 

Nous avons étudié ce soupçon au sein de notre flotte d'agents en utilisant le traçage (tracing) de Unity Gateway et Genie One. Nous avons découvert sept petits bugs dans nos serveurs d'outils qui coûtaient environ 499 000 $ par an en tokens gaspillés et environ 12 000 heures d'ingénierie par an en temps d'attente des agents. Au total, cela représente une perte de productivité estimée à 1,2 million de dollars par an. 

Trouver ces sept bugs, les quantifier et les corriger a pris environ une heure. Cet article décrit le processus que nous avons suivi et ce qu'il nous a appris sur la création d'outils pour les agents.

Comment surveiller l'activité des agents d'IA et de MCP

Lorsque nous avons déployé pour la première fois des agents d'IA à grande échelle chez Databricks pour le codage et les flux de travail internes, il était impossible de gérer ou même de comprendre pleinement les coûts, car nous manquions de visibilité sur les appels d'outils des agents et sur leur activité globale. Pour résoudre ce problème, nous avons exploité Unity Gateway, qui émet automatiquement une trace OpenTelemetry pour toutes les invocations d'outils MCP, y compris le nom de l'outil, les arguments, l'erreur (le cas échéant), le nombre de tokens, la latence et un ID de session qui relie les appels entre eux. Ces traces arrivent dans une table unique qui enregistre exactement ce que nos agents ont fait sur n'importe quelle période. Aucune nouvelle instrumentation n'a été nécessaire, et la passerelle se trouvant déjà sur le chemin de chaque appel, les données étaient immédiatement disponibles.

Cela rend la gestion des coûts des agents d'IA plus exploitable : au lieu de voir uniquement les dépenses globales en tokens, nous pouvons attribuer les dépenses inutiles à des outils, des erreurs et des sessions d'agents spécifiques.

Maintenant que les données sont disponibles, l'étape suivante est l'exploration :

• Quelles erreurs d'outils reviennent le plus souvent ?
• Lorsqu'un agent en rencontre une, combien de tours lui faut-il pour s'en remettre ?
• Combien coûte chaque erreur en tokens et en temps d'attente réel ?

Normalement, la partie la plus coûteuse de ce type d'analyse réside dans le SQL et l'exploration des schémas. Mais avec Genie One, il nous a suffi de le pointer vers la table de traces, de poser ces questions exactes en langage naturel, et d'obtenir des réponses en quelques minutes. La majeure partie de notre heure a été consacrée à la lecture de ces réponses plutôt qu'à la rédaction de requêtes.

Ce que les traces ont révélé : comment les échecs des outils MCP font grimper les coûts des agents d'IA

Genie One a transformé un vague soupçon (« les agents semblent s'emballer sur les appels Jira ») en une liste de bugs classés et quantifiés en quelques minutes. Voici un exemple sur une seule période de 24 heures, montrant des bugs dans nos serveurs d'outils Jira et Google Drive/Docs :

Prenons l'exemple du bug au volume le plus élevé, soit 535 échecs par jour. L'outil Jira issues.search prend un paramètre fields, et le serveur a fait ceci :

Il s'attendait à une chaîne de caractères séparée par des virgules comme "key,summary,status". Mais un tableau est le type JSON sémantiquement naturel pour « une liste de champs », et c'est ce que le modèle a déduit de sa connaissance générale des conventions JSON et des appels d'outils adjacents dans la même session. Il a donc transmis la valeur structurée qu'un appelant raisonnable transmettrait :

Une liste n'a pas de .split(), le serveur a donc renvoyé 'list' object has no attribute 'split', un traceback Python brut qui n'indique en rien à l'agent ce qu'il a mal fait. L'agent a donc fait une autre supposition. Parfois, il réessayait la même liste et échouait de la même manière ; parfois, il relisait le schéma ou s'en remettait à des essais successifs. En moyenne, il a fallu 12 tours pour s'en remettre, et 30 % des sessions ont rencontré l'erreur plus d'une fois. Un seul appel .split() coûtait environ 87 k$/an en tokens et 4 850 heures d'attente pour l'agent.

L'erreur Google Drive Invalid field selection était encore plus frappante en termes de volume : 49,6 % de tous les appels drive_file_get ont échoué, car le modèle continuait de transmettre des noms de champs de l'API Drive d'apparence valide (id, name, mimeType) que le point de terminaison de l'outil n'acceptait pas.

La vraie leçon : comment concevoir des outils MCP pour les agents d'IA et les LLM

La conclusion évidente est qu'il faut « écrire de meilleurs messages d'erreur », et les données le confirment. Le coût de récupération suit presque parfaitement la qualité des messages d'erreur :

Mais le fait que « de bons messages d'erreur sont utiles » n'est pas nouveau. La question la plus intéressante est de savoir pourquoi le modèle a appelé ces outils de manière « incorrecte » en premier lieu. Dans la plupart de ces cas, ce n'était pas le cas.

Les signatures d'outils MCP sont souvent délibérément sous-spécifiées. Nous les laissons volontairement souples : en partie pour des raisons de généralité, et en partie pour économiser des tokens de contexte, car chaque description de paramètre coûte des tokens que le modèle paie à chaque appel. La conséquence est que lorsqu'une signature est vague concernant les champs, le modèle comble le vide avec une supposition raisonnable, et un tableau JSON est une supposition raisonnable pour une liste de champs. Le bug n'était pas que le modèle appelait l'outil de manière incorrecte. C'était que le serveur n'acceptait qu'une seule des nombreuses interprétations raisonnables et plantait sur les autres.

Le principe de conception est donc l'inverse du principe réflexif : les outils pour les agents doivent s'adapter à la façon dont les LLM les appellent naturellement, par exemple en convertissant la liste en chaîne, en définissant par défaut le paramètre omis, en absorbant l'argument inattendu, etc. Une signature sous-spécifiée est une promesse de flexibilité, et l'outil doit honorer cette promesse à la réception plutôt que de planter dès la première entrée qui ne correspond pas à la forme unique que son auteur avait en tête.

La partie facile : comment nous avons réduit les dépenses inutiles des agents AI en une heure

Les corrections elles-mêmes étaient simples et ne constituent pas la partie la plus intéressante de cette histoire. Une fois que Genie One nous a fourni une liste classée des erreurs à corriger et de ce que le modèle envoyait réellement, l'application des corrections sur les serveurs d'outils s'est faite rapidement avec un agent de codage. L'ensemble du cycle (trouver, quantifier, corriger) a pris environ une heure.

L'étape rare et coûteuse n'a jamais été d'écrire la correction. C'était de savoir quoi corriger. Le traçage associé à Genie One a transformé cette étape d'un projet de recherche en une question que vous pouvez poser à haute voix.

Boucler la boucle : comment surveiller en continu et réduire les coûts des agents AI

À mesure que le travail réel se déplace vers les agents, les défaillances silencieuses des outils deviennent un centre de coûts de premier ordre, du genre de ceux qui se cachent derrière la « croissance de l'utilisation » et n'alertent jamais personne. Le cycle pour les détecter est économique et reproductible : Unity Gateway rend le comportement des agents observable, et Genie One permet d'interroger ce comportement sans SQL.

Ensemble, cela donne aux équipes un moyen reproductible de surveiller les agents AI, de diagnostiquer les défaillances des outils MCP et de réduire les dépenses AI inutiles. Si vous exécutez des agents sur vos propres outils, faites de même. Tracez les appels et demandez à Genie One ce qui ne va pas.

Démarrez avec l'analyse des traces Unity Gateway grâce à Genie One

Unity Gateway est en disponibilité générale, et vous pouvez désormais surveiller toute l'activité AI à l'aide de la table de traçage unifiée, actuellement en version bêta. Consultez notre documentation pour savoir comment démarrer. 

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original