jevals : des évals d'agents à verdicts typés, sans juge LLM

Ce que décrit le README de jevals

jevals est une bibliothèque Python open source publiée dans l'organisation GitHub openlayer-ai. Son README la présente comme des « evals et garde-fous pour agents » qui utilisent des modèles de décision de type Jev à la place d'un juge LLM. L'argument central porte sur le coût et la vitesse. Toutes les évaluations d'une trace d'agent partent dans une seule requête. Selon le README, cette requête coûte quelques millièmes de centime et revient en quelques centaines de millisecondes. C'est assez rapide, dit-il, pour l'exécuter sur chaque trace et même à l'intérieur de la boucle de l'agent.

Cet article suit uniquement le README. Nous n'avons ni installé ni exécuté l'outil. Tous les chiffres ci-dessous sont des affirmations de l'auteur, et nous signalons les endroits où le README indique lui-même qu'un chiffre est une estimation ou une illustration.

Les faits clés du README

L'idée du modèle. Le README explique que Jev ne génère pas de texte. On lui envoie un état et un ensemble de questions typées : oui/non, choix parmi plusieurs options, ou note selon une grille. Il renvoie, en une seule passe avant, une probabilité calibrée pour chaque question. Les questions sont évaluées indépendamment et en parallèle, si bien qu'en poser 40 coûte à peu près la même latence qu'en poser une. Le README donne un prix de 0,042 $ par million de jetons d'entrée, sans jetons de sortie, et mesure un p50 de 244 ms et un p95 de 371 ms par requête via la passerelle de Vercel. Le démarrage rapide. Un seul appel à `evaluate()` prend les messages et les schémas d'outils, plus une liste d'objets d'évaluation tels que `ToolChoice`, `UsedToolResult`, `Grounded`, `StayedInScope`, `AnswerRelevancy`, `Completeness`, `IndirectInjection` et `PHI`. Le README indique que huit évaluations ont tenu dans une seule requête HTTP : 1 388 jetons, 0,00006 $ et 0,33 seconde. Les backends. La bibliothèque choisit son backend à partir de variables d'environnement. Les options sont Jev en direct via `TYPESAFE_API_KEY` (ce qui demande aujourd'hui un accès par liste d'attente, selon le README), Jev via Vercel AI Gateway, un Kev auto-hébergé, Laya exécuté dans le processus sur Apple Silicon, ou un LLM de chat ordinaire via OpenRouter, émulé par un prompt qui demande des probabilités. Le README avertit qu'il faut relancer `jevals calibrate` après un changement de backend, car les probabilités ne sont pas alignées d'un modèle à l'autre.

Le catalogue. Le README énumère des évaluations d'agents (par exemple `ToolChoice`, `Grounded`, `StayedInScope`, `LoopDetection`, `GoalCompletion` et `ToolCallRisk`), des évaluations de sécurité (`PromptInjection`, `IndirectInjection`, `Jailbreak`, `PII`, `PHI`, `SecretsExposure` et d'autres) et des métriques de qualité dans le style de Ragas (`Faithfulness`, `AnswerRelevancy`, `ContextPrecision`, `ContextRecall` et d'autres). Il compte 37 évaluations au total. Le tableau de mesures. Le README compare jevals à Ragas sur les mêmes 20 lignes d'un petit jeu de données RAG, mesurées le 2026-09-20. Ragas avec gpt-4.1-mini demande 6,0 requêtes LLM par échantillon plus des embeddings, environ 2,60 $ pour 1 000 échantillons, et 22 à 35 secondes pour les 20 échantillons. jevals avec Jev demande 1,0 requête par échantillon, environ 0,03 $ pour 1 000 échantillons et 0,8 seconde. jevals avec gpt-4.1-mini qui émule Jev demande 1,0 requête, 0,46 $ pour 1 000 échantillons et 4 secondes. Les lignes Kev-4B et Laya sont présentées comme des estimations. La fidélité (faithfulness) sort entre 0,90 et 0,92 dans les trois lignes mesurées, et la précision et le rappel du contexte à 1,0.

Comment fonctionnent les évaluations et les portes

Une évaluation est une classe à trois méthodes. `state()` choisit ce que le modèle doit regarder. `questions()` dit ce qu'il faut demander. `reduce()` transforme les probabilités renvoyées en un score. Quand on passe plusieurs évaluations à `evaluate()`, le README dit que leurs états sont fusionnés et que leurs questions sont regroupées dans une seule requête. Comme une évaluation ne dépend que de l'échantillon, la même classe peut servir de métrique hors ligne, de moniteur sur les traces de production ou de porte à l'intérieur de l'agent.

Une porte (gate) est une évaluation plus une politique qui associe les réponses à autoriser, escalader ou bloquer. Le README montre une porte YAML pour le risque d'un appel d'outil. Sa politique autorise l'appel si `action.approve >= 0.85` et `grounded >= 0.7`, le bloque si `action.block >= 0.6`, et escalade dans les autres cas. Le README montre le branchement sur le SDK OpenAI Agents, sur une simple boucle asynchrone, sur LangGraph et sur un hook `PreToolUse` du SDK Claude Agent. Si le backend reste indisponible après les nouvelles tentatives, une porte laisse passer l'appel par défaut. Passer `on_error="block"` inverse ce comportement pour tout ce qui est irréversible.

Pour les données PII et PHI, le README décrit deux étapes. La détection d'entités vient d'abord. Ensuite, une question part vers le modèle : s'agit-il d'une information de santé sur une personne identifiable, ou d'une adresse e-mail de support ? Le README affirme que la détection d'entités seule ne sait pas les distinguer, et que c'est la source de la plupart des faux positifs sur les PII.

Contexte et notre lecture

*Cette section est notre analyse, pas celle du README.* Un juge LLM consiste à demander à un modèle de chat généraliste de noter une sortie, en général par un prompt qui réclame un raisonnement et une réponse en JSON. Le README soutient que la plupart des décisions d'un juge entrent dans trois types de questions, et que ce que l'on garde du juge est de toute façon une étiquette. Si un petit modèle peut renvoyer cette étiquette avec une probabilité en une seule passe, on peut se permettre de l'exécuter bien plus souvent. Cela change l'usage des évaluations. Un échantillon nocturne devient un contrôle sur chaque trace, et un contrôle sur chaque trace peut entrer dans le chemin de la requête.

Le README aborde aussi la variance. Il cite une comparaison de LangChain où les juges GPT et Claude montraient une variance de score de 92 à 913 fois celle de Jev sur des traces identiques. Nous n'avons pas lu cet article. Par ailleurs, une probabilité, contrairement à un paragraphe de texte, peut être soumise à un seuil, ce qui permet de régler le compromis action par action. L'exemple `jevals calibrate` du README met en regard des seuils, des passages erronés et des passages manqués, et le README conseille des seuils par action, car un remboursement et une simple consultation ne devraient pas partager le même.

L'affirmation inventée dans l'exemple du README montre pourquoi plusieurs métriques aident. L'agent a répondu qu'il ferait « beau toute la semaine » alors que l'outil ne renvoyait que la prévision du jour. L'évaluation `grounded` a donné à cette phrase p=0,05, tandis que `answer_relevancy` restait à 0,84. Le README en conclut que les métriques de type RAG seules auraient laissé passer la trace.

Limites et questions ouvertes

Le README est franc sur ses limites. Il dit que le projet est en alpha et vieux d'une semaine, et que les modèles sous-jacents ont le même âge. Le backend TypeSafe direct est écrit d'après le format de communication documenté et testé contre un mock, pas encore exécuté en réel. Les adaptateurs de frameworks sont écrits d'après la documentation des SDK et testés contre des doublures. Les lignes Kev et Laya du tableau sont des estimations, obtenues en multipliant des chiffres publiés par les auteurs de ces modèles. Plusieurs blocs de sortie portent la mention « Illustrative output ». Le README précise aussi que l'outil ne génère pas de jeux de test, n'a pas de tableau de bord, et ne remplacera pas un juge LLM pour un travail qui exige un raisonnement en plusieurs étapes ou une critique rédigée.

Sur la précision, le README cite JevBench, un benchmark indépendant, qui place Jev à peu près au niveau des plus petits LLM sur des tâches de classification (83 à 87 % sur Banking77 et CLINC150) et constate que la calibration varie selon la tâche. Le résultat de LangChain, avec 100 % d'accord avec un humain sur 500 répétitions contre 80 % pour Claude, portait sur cinq traces, note le README. Il rapporte aussi que la passerelle s'est bloquée sur certaines connexions pendant une exécution, ce qui a porté le p95 de cette exécution à une minute, même si le client a réessayé et que l'exécution s'est terminée. Nous avons relevé de petites incohérences dans le README. L'introduction montre huit évaluations pour 1 388 jetons et 0,33 seconde, alors que l'exemple plus long en montre neuf pour 1 423 jetons et 0,50 seconde. Le texte parle de « six centièmes de centime » pour un coût affiché de 0,00006 $, ce qui fait six millièmes de centime. Cela ressemble à des glissements de formulation entre des exécutions différentes, pas à un problème de fond, mais cela montre pourquoi il faut refaire les mesures soi-même. Notre lecture : les économies dépendent de la façon dont vos questions entrent dans les trois types et de la ressemblance de vos données avec le petit échantillon du tableau. Le README donne lui-même la mise en garde la plus nette : ne laissez pas le classifieur devenir l'autorité qui autorise. Savoir si un remboursement doit s'exécuter dépend de l'état du compte et de permissions que le modèle ne peut pas voir.

Conseils pratiques pour les lecteurs

1. Si vous faites déjà tourner un juge LLM sur un échantillon de trafic, le backend d'émulation par LLM du README est le moyen le moins coûteux d'essayer l'API. Le README dit qu'il fonctionne dès aujourd'hui, mais qu'il renvoie des probabilités de 0,00 ou 1,00 au lieu de valeurs calibrées.

2. Étiquetez une partie de vos propres traces et lancez `jevals calibrate` avant de faire confiance à un seuil.

Le README dit que les données de calibration sont la contribution qui aiderait le plus.

3. Gardez un humain sur les actions irréversibles, et réglez `on_error="block"` sur les portes placées devant elles.

4. Suivez les conseils d'écriture du README : une question par sujet, des options décrites plutôt que simplement nommées, un état réduit, et une option « preuves insuffisantes » quand l'état peut ne pas contenir la réponse.

5. Considérez les adaptateurs de frameworks comme rugueux tant que personne ne les a exécutés en réel, et le tableau des coûts comme une affirmation de l'auteur. Refaites la comparaison sur vos propres traces avant de bâtir un plan dessus.