Modèles de décision : Jev, OpenAI Decisions et alternatives locales
Un article dispose déjà d’un résumé ; il faut maintenant décider s’il mérite d’être lu tout de suite. Un ticket est arrivé dans le système ; il faut décider quelle équipe doit le traiter. Ces questions demandent de comprendre la langue, mais leurs réponses se réduisent à quelques options. On peut sortir ce genre de jugement d’un grand modèle et le confier à un composant bon marché, à la sortie typée, testable séparément : un modèle de décision.
Un modèle de décision reçoit le contenu à juger et des questions définies à l’avance, puis renvoie des choix, des scores ou des probabilités que le code exploite. Il ne génère ni résumé, ni explication, ni code. Jev, lancé par TypeSafe AI en septembre 2026, a été le premier ; l’entreprise appelle cette catégorie System One, en reprenant la distinction de Kahneman entre intuition rapide et raisonnement lent (annonce de lancement). Fin octobre, OpenAI, la passerelle de Vercel et plusieurs runtimes locaux proposaient le même type d’interface, et la manière de poser les questions et de lire les résultats décrite ici vaut pour tous.
Ce qu’une requête doit fournir
Une requête comporte deux parties : le contenu et les questions, appelés state et questions dans l’interface. Le premier contient les informations que le modèle doit voir ; les secondes disent ce qu’il faut juger et quelles réponses sont autorisées. Une même requête peut contenir plusieurs questions, qui partagent le contenu et sont évaluées indépendamment (définition des questions). Si une question dépend de la réponse précédente, c’est au programme d’enchaîner les appels.
Pour une recommandation de lecture, le contenu est un résumé accompagné de l’intérêt actuel du lecteur, la question est « Ce contenu vaut-il d’être lu maintenant ? », et les réponses autorisées sont :
- Lire maintenant : aide directement à résoudre le problème actuel.
- Garder : utile comme contexte, mais pas urgent.
- Ignorer : sans rapport avec l’intérêt actuel.
- Incertain : pas assez d’informations pour un jugement fiable.
Ces options doivent être définies clairement. Si « Garder » et « Lire maintenant » ne sont expliqués que par « utile », le modèle peine à les distinguer ; sans « Incertain », un contenu trop pauvre est poussé dans une autre catégorie. Le modèle ne juge aussi que ce qu’il reçoit : s’il ne reçoit qu’un titre, sa conclusion ne porte que sur le titre.
Trois types de sortie pour des questions différentes
La valeur d’un Score est la moyenne des indices de niveau pondérée par les probabilités, en partant de 0. Avec trois niveaux, « sans rapport », « contexte » et « directement pertinent », d’indices 0, 1 et 2, si le modèle attribue 0,2, 0,5 et 0,3, le score vaut 0×0,2 + 1×0,5 + 2×0,3 = 1,1 : entre « contexte » et « directement pertinent », plus près du premier. Il n’a pas de sens naturel de pourcentage ; si l’on change la description des niveaux, le nombre change aussi de sens.
Une faible probabilité Noul est utile elle aussi. Une probabilité de 0,02 pour « Le corps du texte manque-t-il ? » signifie que le modèle penche pour un texte présent. La lire comme « le modèle n’est sûr qu’à 2 % » confond la probabilité d’une proposition et l’incertitude du jugement.
Probabilité, confidence et exactitude
Un Choice peut donner 0,51 à « Lire maintenant » et 0,49 à « Garder », ou bien 0,97 et 0,03. Le premier choix est le même, mais le premier résultat n’a presque aucun avantage net. Ne garder que la catégorie finale efface cette différence.
Le confidence de TypeSafe est une statistique de 0 à 1 calculée à partir de toute la distribution d’un Choice ou d’un Score, qui résume sa concentration. Ce n’est ni un second jugement indépendant, ni la probabilité de l’option en tête ; Noul n’a pas ce champ. Une probabilité élevée accompagnée d’un confidence élevé décrit donc deux fois la même distribution, sans fournir deux preuves.
La justesse des probabilités ne se voit que sur de nombreuses prédictions dont l’issue est connue : si un lot de prédictions donne toutes environ 80 % à un événement, une bonne calibration signifie qu’environ 80 % de ces événements se produisent. Une sortie isolée ne le montre pas ; la manière de tester la calibration et de fixer des seuils selon le coût des erreurs se trouve dans Calibration des probabilités, seuils de décision et abstention. Afficher « Incertain » quand la probabilité la plus haute passe sous une valeur donnée est une règle fixée par l’application, et le seuil doit être réglé sur du contenu réel.
Comment comprendre « zéro hallucination »
Définir l’espace de réponse à l’avance supprime une catégorie de problèmes : quand le programme exige l’une des options listées, le modèle ne peut pas inventer une réponse à part. L’interface devient plus facile à vérifier, et les erreurs plus faciles à localiser.
Une réponse correctement typée peut pourtant être fausse. Un classificateur peut renvoyer une catégorie valide et envoyer quand même une réclamation à la mauvaise équipe. Les contraintes de format règlent la conformité à l’interface ; le caractère raisonnable du résultat reste à juger par l’application. C’est la différence entre les contrats d’outils et la justesse de la tâche.
TypeSafe publie les faiblesses connues de Jev 1.13 ; la page a été revue pour la dernière fois le 2 octobre, et 1.14 n’a pas encore la sienne. Ces faiblesses se répartissent en neuf groupes : lecture littérale, nombres et comptage, comparaison de dates et d’heures, indirection, détails non pertinents dans un long contenu, contenu adverse, instructions et critères contradictoires, ordre des options, et génération.
Cela change directement l’usage. Confier les comparaisons de montants au code, et la pertinence du texte au modèle. Une phrase fournie par un lecteur ne doit pas devenir l’autorisation de réécrire les règles de classement. Quand un résultat doit être expliqué, revenir aux éléments d’entrée au lieu de laisser un autre modèle inventer une raison plausible.
Les chiffres « 193,6 fois plus rapide, 444,6 fois moins cher » de la page d’accueil de TypeSafe viennent de sa propre évaluation de workflows, dont les réponses de référence font la moyenne des jugements de deux modèles phares ; ils donnent une raison d’essayer, rien de plus.
Interfaces de décision disponibles aujourd’hui
Vérifié le 29 octobre 2026 :
L’article d’Ollama sur Clef reprend les chiffres de Cloudflare. Sur les 10 évaluations du Jev Decision Index, Clef bat Jev sur 8 ; sa latence médiane est de 209 ms, contre 524 ms pour Jev. Ce sont les comparaisons du fournisseur, à refaire sur vos propres exemples. Quand les étiquettes sont fixes et que des données annotées existent, un petit classificateur entraîné suffit souvent comme référence ; les modèles d’embedding et de reclassement répondent à une autre question, comme l’explique Embeddings, reclasseurs et classificateurs.
Essayer Jev via l’AI SDK
Par défaut, une requête Jev contient au plus 64k tokens, et state plus une question quelconque au plus 32k. L’en-tête TypeSafe-Danger-Zone-Long-Context: true porte les deux limites à 262k, mais la documentation des modèles précise que c’est plus lent et moins précis. L’anglais est la langue principale d’entraînement ; le chinois et les autres langues sont acceptés, sans le même niveau de qualité, d’où la nécessité de valider sur vos propres exemples.
Via Vercel AI Gateway, ai 7.0.128 et versions ultérieures utilisent experimental_decide ; les versions antérieures d’AI SDK 7 utilisent experimental_evaluate, désormais alias obsolète de la même interface. Le scénario de lecture fictif ci-dessous montre la forme de la requête. La clé provient de AI_GATEWAY_API_KEY dans l’environnement serveur, et l’exemple active la restriction d’entraînement sur les prompts :
import { experimental_decide as decide } from 'ai';
const result = await decide({
model: 'typesafe-ai/jev',
state: {
interest: 'Local speech tools and privacy',
excerpt: 'A fictional offline speech tool caches audio locally.',
},
questions: {
reading: {
type: 'choice',
instructions: 'How relevant is this excerpt to the current interest?',
criteria: {
read: 'Directly useful now',
keep: 'Useful background for later',
skip: 'Unrelated',
unsure: 'Not enough information',
},
},
},
maxRetries: 0,
providerOptions: {
gateway: { disallowPromptTraining: true },
},
});
console.log(result.answers.reading);
Sans l’AI SDK, envoyez les mêmes champs model, state et questions à https://ai-gateway.vercel.sh/v1/evaluate. Le confidence de TypeSafe se trouve dans providerMetadata.typesafe.confidence, indexé par identifiant de question, et se lit séparément des distributions de probabilité de answers.
Une première estimation de coût : si 10 000 requêtes consomment au total 20 millions de tokens d’entrée, la facture est d’environ 0,84 USD au tarif de Jev et d’environ 2,00 USD avec OpenAI Decisions. Cela ne couvre que l’usage du modèle ; un contenu plus long, des requêtes supplémentaires et la relecture humaine modifient le coût réel.
Interdire l’entraînement et ne rien conserver sont deux exigences différentes
La passerelle, le fournisseur du modèle et l’application peuvent tous traiter la même requête. L’option disallowPromptTraining de Vercel est ouverte à tous les utilisateurs sans surcoût et n’achemine les requêtes que vers des fournisseurs qui n’entraînent pas sur les données ; elle ne promet pas que rien n’est conservé, et les requêtes avec votre propre clé fournisseur (BYOK) y échappent. zeroDataRetention exige une conservation nulle des données et n’est proposé qu’aux équipes Pro et Enterprise ; TypeSafe figure sur la liste ZDR des fournisseurs de la passerelle.
Ce que cela change pour la répartition du travail dans les agents
Le contrat d’interface, un contenu plus des questions typées qui renvoie une distribution de probabilités, s’est étendu en un mois environ à OpenAI, Vercel, Ollama, vLLM, SGLang et LM Studio. Pour qui construit des agents, les petits jugements fréquents, comme « faut-il passer la main à une personne ? », « quel outil appeler ensuite ? » ou « ce contexte doit-il rester ? », peuvent sortir du modèle principal et passer à un composant bon marché et remplaçable. Chaque jugement extrait a son propre jeu de test et son propre seuil, et se reteste seul quand le modèle change. Le prix à payer est un composant de plus à calibrer et à surveiller, et les seuils ne se transposent pas d’une version de modèle à l’autre.
Quand un modèle de décision vaut la peine
Un bon point de départ est un jugement fréquent et bien délimité d’un système existant, dont les erreurs peuvent être corrigées. Voir d’abord s’il réduit de façon fiable le travail manuel, puis décider de l’étendre ou non. Plutôt que de laisser une seule réponse de modèle décider de tout un workflow, garder les calculs exacts dans le programme et ne confier à la compréhension du langage que l’étape qui en a besoin.
Cette répartition s’accorde avec les boucles d’agent bornées et aide au choix des modèles : à qui la sortie est remise et ce que coûte une erreur comptent souvent davantage que de savoir si un modèle est le plus puissant.