Rendre un agent IA plus efficace grâce à Jev
- La question
- Un petit modèle économique, limité à la classification, peut-il décider de ce qui entre dans le contexte d'un grand modèle sans dégrader les performances de l'agent ?
- Le résultat
- Oui, et c'est rentable : 29 % d'économie en moyenne, 61 % sur la meilleure tâche, avec 99 % de tests qualité réussis pour chaque configuration.
Ce que je voulais découvrir
En juillet, j’ai soutenu que les petits modèles devraient décider de ce que voient les grands modèles, en concluant que l’aspect économique était une raison d’expérimenter plutôt qu’une preuve en soi.
Jev est sorti le 15 septembre. Il ne rédige aucun texte : il renvoie des probabilités calibrées sur des réponses définies par votre code, et coûte 0,042 $ par million de tokens d’entrée. Cela a rendu deux versions concrètes de mon idée assez abordables pour être mesurées, je les ai donc testées :
- Le préchargement des compétences. Le laisser lire la requête et la description d’une ligne de chaque document interne, puis injecter les éléments pertinents avant le premier tour de l’agent, afin que celui-ci n’ait jamais à passer un cycle pour les récupérer.
- Le filtrage du payload des outils. Le laisser noter chaque champ d’une réponse API et supprimer ceux sur lesquels l’agent n’agira pas, avant qu’ils n’entrent dans la fenêtre de contexte et ne soient renvoyés à chaque tour.
Il s’agit dans les deux cas de problèmes de classification. Aucun ne nécessite un modèle capable d’écrire.
Protocole de test
Un SaaS B2B fictif doté de 17 outils dont les payloads imitent la structure réelle de Stripe, Zendesk, HubSpot et d’un CMS de centre d’aide, 11 documents de politique interne (dont plusieurs sont sans rapport), et 8 tâches réparties selon deux axes : le nombre de tours nécessaires et la proportion de bruit dans le payload.
Quatre configurations, six répétitions chacune, soit 192 exécutions. L’évaluation est déterministe : 59 vérifications, chacune étant soit un appel d’outil avec des arguments exacts, soit un fait apparaissant uniquement dans un document de politique. Aucun juge LLM n’est utilisé, ainsi, la question « l’agent avait-il réellement accès à la politique » est mesurable et non sujette à interprétation.
Résultats
Coût moyen d’une exécution d’agent, basé sur Claude Opus 5
La moyenne est 29 % moins chère. La meilleure tâche affiche 61 % d’économie, la moins bonne 13 %. Le nombre de tours passe de 4,44 à 3,71, et les tokens d’entrée frais, les plus coûteux, chutent de 49 %.
Les deux mécanismes répondent à des problématiques totalement différentes, ce qui importe plus que la moyenne si vous devez choisir l’un ou l’autre :
Le préchargement cible les tours supprimablesPas la taille du payload
- Optimal quand une tâche nécessite une politique et passerait un tour à la récupérer
- Inutile quand aucune politique ne s’applique
- Peut devenir contre-productif : un document mal chargé est renvoyé à chaque tour
Le filtrage cible la densité du payloadPas la longueur de la tâche
- Optimal quand la majorité des octets sont du texte que personne ne lit
- Quasi nul quand chaque champ est indispensable
- Effet cumulé, car un champ supprimé n’est pas renvoyé au tour suivant
Ce qu’il faut en retenir
Un champ n’est pas utile en soi. Il est utile en fonction de ce que l’agent s’apprête à en faire, et cette information ne figure pas dans le payload. En indiquant au scoreur quels outils l’agent peut encore appeler, la pertinence du champ dont dépend la tâche passe de 0,18 à 0,73, tout en réduisant le nombre de champs conservés de 51 à 27. Un contexte plus riche rend le filtre à la fois plus sûr et plus agressif.
Le prix de votre modèle principal détermine la rentabilité du filtrage. Cela coûte un nombre fixe de tokens bon marché et permet d’en économiser un nombre variable de tokens coûteux, le bilan change donc selon le prix. Sur un modèle à 0,20 $ par million, cela coûte 21 % de plus que ce que cela rapporte ; sur Opus 5, on économise 29 %. Le point de bascule se situe autour de 0,55 $ par million avec le prompt caching activé.
Un champ supprimé ne produit pas d’erreur. Il produit une réponse erronée mais affirmée. Une version préliminaire avait supprimé un identifiant de compte et son doublon, et l’agent a agi sur le seul identifiant restant, qui correspondait au mauvais objet, avant d’en rédiger un rapport impeccable. Tout déploiement nécessite des chemins critiques déclarés et un seuil calibré en conséquence.
Deux points de départ ont été testés ici. Choisir quels fichiers un agent ouvre, décider quand condenser une conversation, filtrer une écriture avant qu’elle n’ait lieu : rien de tout cela n’a été mesuré, et je ne présumerai pas que cela fonctionne avant d’avoir les preuves.