Jev peut-il réduire le coût des agents IA ? Un calcul complet, du routage des modèles à la vérification des résultats

Résumé

Un appel à Jev coûte peu cher, mais ajouter un modèle de décision à faible coût à un agent IA ne rend pas automatiquement l’ensemble de la tâche moins coûteux.

La véritable question est de savoir si Jev peut orienter une partie des requêtes vers du code déterministe ou un modèle moins cher, réduire le contexte envoyé au modèle principal et éviter des relances inutiles grâce à la vérification des résultats. En parallèle, ses propres erreurs de classification, sa latence, la revue humaine et la maintenance technique ont elles aussi un coût.

Cet article analyse trois architectures courantes — routage des modèles, filtrage du contexte et vérification des résultats — et propose un cadre complet pour répondre à une question concrète : dans quels cas Jev peut-il réduire le coût total d’un agent, et dans quels cas ne fait-il qu’ajouter un appel API supplémentaire ?

---

De nombreux problèmes de coût liés aux agents IA semblent, en surface, venir d’un modèle principal trop cher. En pratique, le problème plus profond est souvent que le workflow ne distingue pas les différents types de tâches.

Une requête comme « Vérifie le statut de ma commande » peut ne nécessiter qu’une consultation de base de données. Une demande comme « Analyse les causes des anomalies de commande au cours des six derniers mois » peut exiger un modèle puissant capable de synthétiser plusieurs sources. D’autres requêtes ne contiennent tout simplement pas assez d’informations : la meilleure action n’est alors pas d’appeler un modèle, mais de demander une précision à l’utilisateur.

Si toutes les requêtes sont envoyées directement au même modèle puissant, le système reste simple, mais il paie le même prix pour de nombreuses tâches que du code classique ou un modèle plus petit auraient pu accomplir.

Jev propose une autre approche.

Il n’est pas conçu pour discuter ni pour générer de longs textes. Le développeur lui fournit un state et pose un ensemble de questions typées ; Jev renvoie des décisions structurées et des probabilités, par exemple Choice, Score ou Noul. La logique métier décide ensuite s’il faut appeler un outil, utiliser un modèle moins cher, escalader vers un modèle plus puissant ou transmettre le cas à une personne. TypeSafe présente Jev comme le premier modèle System One, c’est-à-dire un modèle conçu spécifiquement pour prendre des décisions rapides et structurées au sein d’un logiciel. (typesafe.ai)

Du point de vue du prix, ce type de décision paraît presque négligeable.

Lors du lancement de Jev, TypeSafe a annoncé un tarif de 0,042 dollar par million de tokens d’entrée, sans facturation des tokens de sortie. L’entreprise a également indiqué une latence de bout en bout typique de 70 à 500 millisecondes, tout en précisant que ces chiffres provenaient de régions et de conditions de test particulières et ne devaient pas être considérés comme représentatifs de tous les environnements de déploiement. (typesafe.ai)

Le problème est le suivant :

Une décision peu coûteuse ne rend pas automatiquement tout le workflow de l’agent moins cher.

La capacité de Jev à faire économiser de l’argent dépend de ce qu’il change dans les étapes suivantes, et pas seulement du faible coût de son propre appel.

La facture réelle d’un agent IA ne se limite pas aux frais du modèle

L’exécution d’une tâche par un agent génère généralement au moins six catégories de coûts :

Catégorie de coût	Ce qu’elle comprend
Coût de décision	Classification de l’intention, routage du modèle, évaluation du risque et décision d’appeler ou non un outil
Coût du contexte	Historique de conversation, résultats de recherche, sortie des outils, journaux et documents
Coût de génération	Tokens d’entrée, de sortie et de raisonnement du modèle principal
Coût des nouvelles tentatives	Timeouts du modèle, échecs d’outils, erreurs de format et nouvelle génération
Coût humain	Revue, correction, gestion des exceptions et validation des actions à haut risque
Coût des mauvaises décisions	Remédiation après un mauvais routage, une information omise ou l’exécution d’une mauvaise action

Un coût par tâche plus complet peut donc s’écrire ainsi :

Coût total
= coût de décision
+ coût de traitement du contexte
+ coût des modèles et outils en aval
+ coût des nouvelles tentatives et du fallback
+ coût de la revue humaine
+ coût de remédiation provoqué par les mauvaises décisions

L’appel à Jev ne représente généralement qu’une très petite partie de ce total.

Sa véritable possibilité de réduction se trouve dans les postes qui suivent : éviter un appel à un modèle cher, ne pas envoyer un contexte inutile, empêcher la réexécution d’une tâche échouée ou permettre aux humains de ne revoir que les cas réellement incertains.

Les principaux schémas d’économie peuvent être regroupés en trois catégories :

1. Pré-routage : décider d’abord, puis choisir ce qu’il faut appeler.
2. Filtrage du contexte : retirer les informations inutiles avant d’appeler le modèle principal.
3. Vérification a posteriori : laisser un modèle bon marché agir en premier et n’escalader qu’en cas d’échec de la vérification.

---

Première manière d’économiser : placer Jev avant le modèle principal comme routeur

L’architecture la plus directe est la suivante :

Requête de l’utilisateur
   ↓
Jev évalue l’intention, la complexité et le risque
   ↓
Code déterministe / modèle bon marché / modèle puissant / humain

Le modèle de routage officiel de TypeSafe repose sur la même idée : toutes les requêtes n’ont pas besoin d’entrer dans le même LLM. Certaines peuvent aller vers du code déterministe, d’autres vers un modèle spécialisé, tandis que les requêtes complexes ou risquées peuvent être escaladées vers un modèle plus coûteux ou vers une personne. (docs.typesafe.ai)

Par exemple, un agent de support client peut d’abord déterminer :

• S’agit-il simplement d’une demande de statut de commande ?
• La requête concerne-t-elle un remboursement ou une contestation de paiement ?
• Doit-elle aller vers la facturation, le support technique ou les ventes ?
• Une intervention humaine est-elle nécessaire ?
• Un modèle de raisonnement de pointe est-il réellement requis ?

Jev se limite à prendre ces décisions.

La requête en base de données, le remboursement, la génération de la réponse et le traitement humain du ticket restent assurés par le système environnant.

Quel est le coût d’une décision de routage ?

Dans un test API réel consigné dans le matériel source, dix tickets de support ont été placés dans une seule requête. Chaque ticket a été évalué pour son routage et pour la nécessité d’une revue humaine, soit 20 questions au total :

• Entrée totale : 2 571 tokens ;
• Durée de l’appel : environ 405 millisecondes ;
• Coût total au tarif public : environ 0,000108 dollar ;
• Coût moyen par ticket : environ 0,0000108 dollar ;
• Extrapolation avec le même profil de tokens : environ 10,8 dollars par million de tickets.

Lorsque les mêmes dix tickets ont été envoyés en dix appels séparés, la durée totale a atteint environ 3 664 millisecondes. Les principaux résultats de routage sont restés identiques, mais certaines probabilités sur les cas limites ont nettement varié. Cela montre que le traitement en lot peut réduire fortement la surcharge liée aux requêtes, mais ne prouve pas la précision du routage dans tous les domaines métier et ne démontre pas qu’un même seuil convient aux garde-fous à haut risque.

Le seuil de rentabilité du routage de modèles

Supposons que :

• C_high soit le coût d’un appel au modèle puissant ;
• C_low soit le coût d’un appel au modèle bon marché ;
• C_jev soit le coût de la décision Jev ;
• P_code soit la proportion de requêtes que du code déterministe peut terminer ;
• P_low soit la proportion de requêtes que le modèle bon marché peut terminer ;
• P_error soit la proportion de requêtes nécessitant une remédiation à cause d’un mauvais routage.

Si toutes les requêtes sont envoyées directement au modèle puissant, le coût attendu est :

C_direct = C_high

Après ajout du routage, le coût attendu devient :

C_route
= C_jev
+ P_low × C_low
+ P_high × C_high
+ P_error × C_repair

Le routage ne fait donc économiser de l’argent que si :

Coût du modèle puissant évité
>
coût de Jev + coût de remédiation dû aux erreurs de routage

Comme Jev lui-même est peu coûteux, l’économie finale dépend généralement de deux questions :

1. Combien de requêtes peuvent réellement éviter le modèle puissant ?
2. Quel est le coût des conséquences d’un mauvais routage ?

Un calcul purement illustratif

Les prix suivants servent uniquement à illustrer la logique et ne représentent le tarif réel d’aucun modèle précis :

• Modèle puissant : 0,01 dollar par appel ;
• Modèle bon marché : 0,002 dollar par appel ;
• Jev : environ 0,0000108 dollar par appel ;
• Volume total : 100 000 requêtes.

Supposons qu’après routage :

• 20 % soient traitées par du code déterministe ;
• 50 % soient envoyées au modèle bon marché ;
• 30 % soient envoyées au modèle puissant ;
• 5 % supplémentaires nécessitent un appel de remédiation au modèle puissant en raison d’une erreur ou d’un échec.

On obtient alors :

Poste	Coût
Sans routage : toutes les requêtes utilisent le modèle puissant	1 000 dollars
100 000 décisions Jev	1,08 dollar
50 000 appels au modèle bon marché	100 dollars
30 000 appels au modèle puissant	300 dollars
5 000 appels de remédiation	50 dollars
Coût total après routage	451,08 dollars

Avec ces hypothèses, le coût total baisse d’environ 55 %.

Mais si seulement 10 % des requêtes peuvent utiliser le modèle bon marché, si 90 % atteignent malgré tout le modèle puissant et si 5 % supplémentaires nécessitent une remédiation, le coût total devient proche de 971,08 dollars.

L’économie est alors d’environ 2,9 %.

Une fois inclus le développement, la supervision, la calibration des seuils et la latence supplémentaire, cette couche de routage peut ne plus valoir la peine d’être construite.

La première chose à mesurer n’est donc pas le tarif unitaire de Jev, mais :

Quelle part de votre trafic réel n’a véritablement pas besoin d’un modèle puissant ?

---

Deuxième manière d’économiser : réduire le contexte envoyé au modèle principal

Le contexte est une autre grande source de coût pour les agents.

Un agent qui fonctionne longtemps peut accumuler :

• L’historique de la conversation ;
• Plusieurs séries de sorties d’outils ;
• Des logs Bash ou de build ;
• Le contenu de pages web ;
• Des passages récupérés par la recherche ;
• Des plans et résultats intermédiaires devenus obsolètes.

De nombreux systèmes renvoient l’ensemble au modèle principal. Même si la tâche actuelle n’en nécessite qu’une petite partie, tous les tokens d’entrée sont facturés.

Jev peut être placé avant le modèle principal afin de déterminer :

• Quels résultats de recherche sont pertinents pour la question actuelle ;
• Quelles sorties d’outils pourront encore être utiles ;
• Quels messages antérieurs contiennent des contraintes ou du travail inachevé ;
• Quels passages peuvent contenir une prompt injection ;
• Quelles informations peuvent être supprimées ou conservées uniquement sous forme de résumé.

La carte officielle des cas d’usage de TypeSafe comprend également la sélection de contexte, la recherche sémantique, le filtrage de passages RAG et la gestion du contexte dans les agent harnesses. (docs.typesafe.ai)

L’effet financier peut être approximé ainsi :

Bénéfice net du contexte
= tokens supprimés × prix d’entrée du modèle principal
- coût du filtrage Jev
- coût de récupération et de nouvelles tentatives provoqué par des informations manquantes

Les deux premiers termes sont simples à calculer. Le troisième est celui que l’on oublie le plus souvent.

Supprimer des dizaines de lignes de logs non pertinentes représente généralement un gain net. Supprimer une contrainte importante formulée plus tôt par l’utilisateur peut conduire le modèle principal à produire un résultat entièrement faux, nécessitant une nouvelle recherche, un nouvel appel ou une correction manuelle.

Une seule réexécution peut absorber les économies réalisées par de nombreuses opérations de filtrage réussies.

Jev convient donc mieux pour déterminer quels éléments sont probablement pertinents que pour devenir l’unique gestionnaire permanent de mémoire. Un système en production devrait au minimum :

• Toujours conserver les instructions système, les contraintes fermes de l’utilisateur et les règles de sécurité ;
• Préserver un index ou une copie originale des contenus supprimés ;
• Permettre à l’agent de récupérer les éléments omis si l’information devient insuffisante ;
• Évaluer la réussite par le résultat de la tâche en aval, et pas seulement par le taux de compression.

Pour la compression du contexte, la quantité la plus utile à suivre est :

Total de tokens après compression
+ tokens de nouvelle récupération
+ tokens de nouvelles tentatives provoquées par les omissions

et non simplement « le nombre de tokens retirés à cette étape ».

---

Troisième manière d’économiser : laisser un modèle bon marché agir d’abord, puis vérifier avec Jev

Dans une autre architecture courante, Jev ne choisit pas le modèle à appeler. Il vérifie la sortie d’un autre modèle.

Le flux peut s’écrire ainsi :

Le modèle bon marché produit un résultat
       ↓
Jev vérifie les fondements factuels, les champs extraits, le risque de politique ou le degré d’achèvement
       ↓
Validé : utiliser le résultat
Refusé : réessayer, escalader vers le modèle puissant ou transmettre à une personne

TypeSafe appelle cette catégorie de schémas Universal Verification. Ses documents officiels mentionnent la vérification des citations RAG, la validation des appels d’outils, l’évaluation de la qualité d’une sortie et les cascades d’extraction de données structurées. L’exemple officiel SDE Cascade utilise « extraction avec un modèle bon marché → vérification champ par champ avec Jev → escalade vers un modèle de raisonnement uniquement lorsqu’un signal d’alerte apparaît ». Il s’agit de résultats issus d’un cookbook fournisseur ; ils ne démontrent pas que toutes les tâches d’extraction obtiendront la même réduction de coûts. (docs.typesafe.ai)

Le coût attendu de cette cascade est approximativement :

C_cascade
= C_low
+ C_jev
+ P_escalate × C_high
+ C_failure

La variable la plus importante est P_escalate, c’est-à-dire la proportion de résultats du modèle bon marché qui doivent tout de même être repris par le modèle puissant.

En ignorant le coût des échecs, une cascade est moins chère qu’un envoi direct systématique au modèle puissant lorsque :

P_escalate
<
1 - (C_low + C_jev) / C_high

Reprenons les mêmes tarifs hypothétiques :

• Modèle puissant : 0,01 dollar ;
• Modèle bon marché : 0,002 dollar ;
• Jev : environ 0,0000108 dollar.

Le taux d’escalade au seuil de rentabilité est donc d’environ 80 %. Autrement dit, tant que moins d’environ 80 % des requêtes finissent par être escaladées, la facture nominale des modèles peut rester inférieure à celle du scénario « modèle puissant pour toutes les requêtes ».

Mais il s’agit du seuil de rentabilité du prix, pas de celui de la qualité.

« Proche du modèle puissant » et « même qualité que le modèle puissant » sont deux objectifs économiques distincts

Une évaluation indépendante préenregistrée a testé une cascade Jev → modèle puissant sur un échantillon CLINC150 :

• Lorsque la précision finale pouvait être inférieure d’un point de pourcentage à celle du modèle puissant, Jev ne devait escalader qu’environ 22 % des requêtes ;
• Lorsque l’objectif exigeait exactement la même précision que le modèle puissant, la cascade devait escalader toutes les requêtes et se réduisait de fait à « toujours appeler le modèle puissant ».

Les chercheurs ont donc insisté sur la bonne lecture du résultat : « se rapprocher de la qualité du modèle puissant à moindre coût », et non « obtenir une qualité identique avec moins d’appels ». L’expérience ne comportait que 200 échantillons, un jeu de données et un chemin de service ; elle ne peut donc pas être généralisée directement à d’autres agents. Elle illustre néanmoins une propriété économique importante : une légère hausse de l’objectif de qualité peut entraîner une forte augmentation du taux d’escalade. (github.com)

L’évaluation d’une cascade ne peut donc pas se limiter à indiquer :

• Le nombre d’appels au modèle puissant évités ;
• La part du trafic traitée automatiquement.

Elle doit aussi indiquer :

• La précision de la partie traitée automatiquement ;
• Le taux final de réussite de bout en bout ;
• La qualité perdue par rapport à un traitement intégral par le modèle puissant ;
• Les erreurs qui sont amplifiées par les étapes ultérieures.

---

Poser plusieurs questions dans un seul appel est souvent plus important que regrouper les requêtes

Jev permet de poser plusieurs questions sur un même state et de renvoyer les réponses en parallèle. La documentation officielle recommande de décomposer les décisions complexes en questions atomiques et de combiner leurs résultats dans le code, plutôt que de cacher plusieurs jugements dans une question vague. (docs.typesafe.ai)

Par exemple, au lieu de demander :

Comment ce ticket de support doit-il être traité ?

On peut décomposer en :

• Vers quelle file métier doit-il être envoyé ?
• Demande-t-il explicitement un remboursement ?
• Mentionne-t-il une contestation de paiement, une action en justice ou un régulateur ?
• Dans quelle tranche d’urgence se situe-t-il ?
• Une personne doit-elle intervenir ?
• Vaut-il la peine d’appeler un modèle plus puissant ?

Dans les mesures du matériel source, faire passer un même state d’une question à huit puis à 32 a conservé, après échauffement, une latence située approximativement dans la même plage de 350 à 400 millisecondes. Le nombre de tokens d’entrée augmentait avec les questions, mais les allers-retours réseau n’augmentaient pas de manière linéaire.

Un schéma raisonnable consiste donc à :

Poser en une seule requête toutes les questions atomiques réellement nécessaires à l’étape courante, au lieu d’envoyer un appel API distinct pour chaque décision.

Le batching ne signifie toutefois pas regrouper tous les utilisateurs, tous les documents et toutes les tâches dans un state gigantesque. L’expérience sur les tickets a également montré que le regroupement sous forme de tableau conservait les classifications principales, mais modifiait certaines probabilités sur les cas limites.

La stratégie de batching doit toujours être validée sur la distribution réelle des données de l’application.

---

Quatre coûts cachés faciles à oublier

1. confidence n’est pas la précision

Une sortie typée peut garantir que la réponse respecte l’interface. Elle ne peut pas garantir que la décision métier est correcte.

Une évaluation indépendante a constaté que, sur 200 échantillons, Jev renvoyait un confidence exactement égal à 1.0 dans 102 cas, dont six étaient erronés. Les chercheurs n’ont pas non plus montré que la confiance de Jev classait mieux ses propres erreurs que la confiance auto-déclarée d’un petit LLM. (github.com)

Cela signifie que la logique de production ne doit pas se réduire à :

if (confidence === 1) {
  executeDestructiveAction();
}

Une approche plus sûre consiste à :

• Privilégier les probabilities par option lorsqu’une règle de décision précise est nécessaire ;
• Choisir les seuils sur un jeu de données étiqueté propre à l’application ;
• Utiliser des seuils différents selon le niveau de risque ;
• Conserver une confirmation humaine pour les paiements, suppressions, suspensions et actions similaires ;
• Enregistrer la version du modèle, les probabilités et le résultat final afin de surveiller la dérive.

Une autre évaluation préenregistrée de la calibration a elle aussi produit des résultats contrastés : l’ECE était de 0,0204 sur CLINC150 et de 0,0936 sur Banking77, avec une surconfiance systématique sur ce dernier. Cela montre que la calibration dépend de la tâche et du corpus ; un seuil calibré sur un dataset ne doit pas être transféré directement à un autre domaine métier. (systemonemodels.org)

2. Les erreurs de routage ne sont pas gratuites

Si un routeur envoie une requête simple au modèle puissant, la conséquence principale peut n’être que la perte d’une occasion d’économiser. S’il envoie une requête complexe vers du code déterministe, le résultat peut être une réponse erronée, du travail en double ou le départ de l’utilisateur.

Dans une tâche à haut risque, le coût d’une seule mauvaise décision peut dépasser celui de tous les appels de modèles concernés.

Il est donc utile de suivre séparément quatre types d’erreurs :

• Fausse escalade : une requête qui pouvait être traitée à bas coût est envoyée au modèle puissant ;
• Faux déclassement : une requête qui nécessitait le modèle puissant est affectée à une voie bon marché ;
• Faux passage : le vérificateur laisse passer un résultat défectueux ;
• Faux blocage : un résultat correct est forcé à être régénéré ou revu par une personne.

Un taux de précision agrégé unique ne reflète pas le coût de ces quatre catégories.

3. La latence et les échecs sont aussi des coûts

Dans le matériel source, les appels sériels après échauffement se situaient pour la plupart autour de 340 à 450 millisecondes. Lors d’un test avec 24 requêtes concurrentes, la latence médiane est montée à environ 1,2 seconde et trois échecs de transport se sont produits. Il s’agissait d’un petit test dans un environnement particulier, qui ne décrit pas la disponibilité générale du service officiel, mais il suffit à montrer qu’une architecture de production ne peut pas traiter la couche de décision comme une fonction locale infaillible.

Le système doit au minimum définir à l’avance :

• Si un timeout entraîne un fail-open, un fail-closed ou une escalade humaine ;
• S’il faut réessayer, et combien de fois ;
• Si l’indisponibilité de Jev doit déclencher un appel direct au modèle principal ;
• Si l’échec du service de routage peut bloquer l’agent entier ;
• Si les latences p95 et p99 restent compatibles avec le budget d’interaction du produit.

Une évaluation tierce préenregistrée a mesuré un temps médian d’appel à Jev d’environ 0,42 à 0,44 seconde, tout en précisant explicitement que cette valeur reflétait un client, un gateway, une région et une charge particuliers, et non la vitesse d’inférence pure du modèle. (github.com)

4. Lorsque des données étiquetées existent déjà, Jev n’est peut-être pas l’option la moins chère

L’un des avantages importants de Jev est le démarrage à froid : lorsqu’aucune donnée étiquetée n’existe, il peut prendre des décisions zero-shot à partir de descriptions en langage naturel.

Mais lorsqu’un workflow stable a déjà accumulé de nombreux exemples annotés par des humains, un petit modèle conventionnel peut être plus intéressant.

Dans une évaluation préenregistrée sur Banking77, un modèle d’embeddings bge-small gelé associé à une régression logistique, entraîné sur 10 003 exemples, a obtenu une précision de 0,933, contre 0,832 pour Jev. L’encodeur s’exécutait en environ 9 millisecondes sur le matériel de test et ne générait aucun coût API par requête. Les chercheurs ont aussi souligné que les conditions d’information différaient : l’encodeur avait vu un grand dataset étiqueté issu de la même distribution, tandis que Jev était évalué en zero-shot. Il ne s’agissait donc pas d’une comparaison de capacité dans des conditions identiques, mais d’une comparaison entre solutions de déploiement réalistes. (github.com)

Une trajectoire d’évolution pratique peut être la suivante :

Étape	Option à évaluer
Aucune donnée étiquetée et règles qui changent souvent	Un modèle de décision zero-shot comme Jev
Un petit jeu de données étiqueté a été accumulé	Jev + calibration des seuils + revue humaine
Les étiquettes sont stables et un grand dataset existe	Encodeur local, classificateur ou modèle affiné
Les tâches de longue traîne continuent d’évoluer	Conserver Jev comme fallback

Jev peut être particulièrement utile comme accélérateur de démarrage à froid et couche de décision pour la longue traîne, sans nécessairement constituer la destination permanente de chaque tâche de classification stable.

---

Comment calculer l’économie avant le lancement

Commencez par un ensemble de tâches historiques issues de l’application réelle et comparez hors ligne trois voies :

A. Envoyer toutes les tâches au modèle puissant
B. Routage Jev → code / modèle bon marché / modèle puissant
C. Modèle bon marché → vérification Jev → escalade vers le modèle puissant si nécessaire

Enregistrez au minimum les métriques suivantes :

Métrique	Question à laquelle elle répond
Coût total moyen	Combien a réellement coûté chaque tâche terminée avec succès ?
Taux d’appels au modèle puissant	Combien d’appels coûteux Jev a-t-il réellement évités ?
Couverture du traitement automatique	Combien de tâches ont évité à la fois l’humain et le modèle puissant ?
Précision des tâches traitées automatiquement	Parmi les tâches automatisées, combien étaient réellement correctes ?
Taux d’escalade	Combien de tâches de la cascade ont tout de même fini au modèle puissant ?
Taux de nouvelles tentatives	Combien d’appels supplémentaires ont été provoqués par des erreurs de routage ou de vérification ?
Taux de revue humaine	Le workflow a-t-il réduit le travail humain ou l’a-t-il simplement déplacé ?
Latence p95	Quelle latence de queue les utilisateurs ont-ils réellement subie ?
Taux de réussite de bout en bout	La qualité finale est-elle descendue sous la référence ?

La métrique la plus significative n’est pas « la précision des décisions de Jev », mais :

Coût par tâche terminée avec succès

Même une API de décision extrêmement bon marché peut détériorer l’économie de l’agent si elle entraîne davantage de nouvelles tentatives, de revue humaine ou d’exécutions incorrectes.

---

Quand Jev mérite d’être testé en priorité

Plus les conditions suivantes sont remplies, plus Jev est susceptible de créer une valeur pratique :

• Le volume de requêtes est élevé et les décisions sont fréquentes ;
• Les limites de la tâche sont claires et peuvent être décomposées en questions sémantiques à une étape ;
• De nombreuses requêtes peuvent être gérées par du code déterministe ou un modèle bon marché ;
• Il n’existe pas encore assez de données étiquetées pour entraîner un classificateur dédié ;
• L’appel au modèle principal est nettement plus coûteux que l’appel de décision ;
• Les erreurs peuvent être contenues par escalade, nouvelle tentative ou revue humaine ;
• Le système peut enregistrer les probabilités, les seuils et les résultats finaux ;
• Les critères de décision doivent être ajoutés ou modifiés rapidement.

À l’inverse, ajouter Jev ne devrait pas être la première mesure lorsque :

• Presque toutes les requêtes finissent par nécessiter le modèle puissant ;
• Le trafic est faible et les économies d’API ne justifient pas la complexité technique ;
• La tâche exige un raisonnement en plusieurs étapes, de l’arithmétique, une comparaison de dates ou une génération longue ;
• Une mauvaise décision peut déclencher directement une action irréversible ;
• Un grand jeu de données étiqueté et stable existe déjà et permet d’entraîner un petit modèle local ;
• Il est impossible de construire des chemins fiables de fallback et de revue humaine ;
• Le plan consiste à copier directement en production les seuils d’une démonstration officielle.

---

Conclusion : Jev ne fait pas économiser sur la décision, mais sur le travail qui suit

Un appel à Jev est effectivement peu coûteux, mais ce n’est pas ce qui détermine s’il réduira le coût d’un agent IA.

Sa véritable valeur est de pouvoir séparer un workflow qui, autrement, enverrait tout à un seul modèle puissant :

• Les requêtes simples vont vers du code déterministe ;
• Les requêtes routinières vont vers un modèle bon marché ;
• Les requêtes complexes vont vers le modèle puissant ;
• Les requêtes incertaines vont vers une personne ;
• Le contexte redondant n’est pas envoyé ;
• Les résultats défectueux sont arrêtés avant d’atteindre l’utilisateur.

Si Jev est placé devant le modèle principal mais que toutes les requêtes continuent malgré tout vers ce modèle, il n’a fait qu’ajouter un appel API.

S’il réduit de manière fiable les appels coûteux, la taille du contexte ou les reprises, il devient alors un véritable levier de coût.

La bonne question n’est donc pas :

Combien coûte un appel à Jev ?

Mais :

Après cette décision, quel travail coûteux le système n’a-t-il plus eu besoin d’effectuer ?

C’est ce calcul complet qu’un agent IA doit effectuer.