Comment mettre en place le routage et les garde-fous LLM ? Un exemple de collaboration entre Jev et les grands modèles de langage

Divulgation des intérêts et des preuves : PandaNpc développe une couche de décision d'Agent utilisant Jev. La suite cite respectivement la documentation officielle TypeSafe, le guide pratique officiel, ainsi que de vrais appels Jev et une calibration de scénarios synthétiques dans notre dépôt. Notre calibration utilise un fournisseur LLM factice scripté et ne peut pas représenter le trafic utilisateur réel ni les performances d'une chaîne de production complète.

Le routage LLM peut se faire ainsi : laissez d'abord Jev déterminer à quelle catégorie appartient la requête et quel est son niveau de risque, puis laissez le code décider de la confier à une fonction ordinaire, à un LLM spécialisé ou à une relecture humaine. Jev peut aussi être placé entre la recherche et la génération pour filtrer les preuves, ou après la sortie du LLM pour vérifier le résultat. Il renvoie des options fermées, des scores et des probabilités ; les réponses ouvertes, la génération de code et le raisonnement long restent à la charge du LLM. L'explication de TypeSafe sur les agents de codage indique clairement que Jev ne peut pas remplacer directement le modèle de chat derrière Claude Code ou Codex.

Cet article utilise une requête de service client, un pipeline de questions-réponses RAG et nos propres enregistrements de calibration d'Agent pour expliquer où les deux types de modèles se rencontrent exactement, et pourquoi les résultats à faible confiance doivent avoir une destination explicite.

Que peut juger Jev, et de quoi le LLM continue-t-il de s'occuper ?

Au 23 septembre 2026, le modèle stable listé sur la page des modèles TypeSafe est jev-1.13.0. L'API accepte un state et un ensemble de questions, et renvoie les answers structurées correspondantes via POST /v1/systemone. jev-latest pointait ce jour-là vers 1.13.0, mais l'alias change selon les versions ; un système dont les seuils ont été calibrés a intérêt à figer la version et à consigner l'ID de modèle réel dans la réponse.

Noul n'a pas de champ confidence indépendant ; on ne peut pas présenter directement une probabilité Noul comme une « confiance du modèle ». Score ne doit pas non plus servir à calculer un montant exact. Les montants, les comparaisons de dates, les quotas et les contrôles de permissions doivent rester dans des programmes déterministes ; la documentation officielle liste ces limites de Jev 1.13.

Forme minimale d'un appel

La forme de requête ci-dessous correspond à la référence API officielle ; les questions d'exemple sont une configuration illustrative construite pour cet article, et aucun test en ligne n'a été réalisé pour elle dans cet article :

Le JSON ci-dessous utilise un message client en anglais ; en français, le client dirait « Ma commande a été débitée en double, pouvez-vous me rembourser s'il vous plaît. »

{
  "model": "jev-1.13.0",
  "state": {
    "message": "My order was charged twice. Please help me get a refund.",
    "account_note": "Customer asks about an order charge"
  },
  "questions": {
    "intent": {
      "type": "choice",
      "instructions": "What does state.message primarily request?",
      "criteria": {
        "refund": "Money returned for a charge",
        "information": "An explanation only",
        "other": "Neither option fits"
      }
    },
    "asks_refund": {
      "type": "noul",
      "instructions": "Does state.message explicitly ask for money back?"
    }
  }
}

Un système réel devrait d'abord vérifier dans le code si les débits concernent la même commande et si un remboursement est autorisé. L'exemple ci-dessus ne sert qu'à interpréter l'intention de l'utilisateur ; le fait qu'un utilisateur demande un remboursement ne prouve pas qu'il y a droit, et ne constitue encore moins une autorisation d'exécuter directement le remboursement.

Utiliser Jev pour le routage LLM : trois chemins de passation

Exemple officiel de routage d’intentions de TypeSafe confie d'abord la requête du service client à Jev pour déterminer l'intention et la complexité, puis le code oriente : la consultation du statut de commande passe par une fonction de base de données ; les questions produit et les retours/échanges passent par des LLM spécialisés chargés de documents différents ; les réclamations complexes ou les résultats à faible confiance entrent dans une file de traitement humain. C'est là la collaboration la plus facile à comprendre entre Jev et un LLM : le premier fournit un jugement structuré, le second n'intervient que lorsqu'il faut générer une explication ou un dialogue.

Lors de la mise en œuvre, on peut concevoir dans l'ordre suivant, plutôt que de laisser le modèle décider librement de toutes les actions :

1. Définir d'abord les chemins : lister clairement les requêtes que peuvent traiter les fonctions ordinaires, chaque LLM spécialisé et la relecture humaine, et prévoir pour Choice une option other ou un filet de sécurité équivalent.
2. Placer les faits dans le state : les propos bruts de l'utilisateur, l'état du compte et l'historique des commandes deviennent des champs distincts ; ne pas traiter du texte web d'origine inconnue comme une instruction système.
3. Poser des questions étroites à la fois : utiliser Choice pour l'intention, Score pour le risque ou l'urgence, et Noul pour un fait ponctuel à confirmer. La documentation officielle recommande d'évaluer en parallèle plusieurs questions indépendantes portant sur le même state dans une même requête.
4. Laisser le code faire le routage final : vérifier d'abord les permissions et les règles strictes, puis examiner les probabilités de Jev et les seuils calibrés pour cette activité ; les requêtes à faible confiance ou manquant de preuves passent par une relecture humaine ou une question complémentaire.
5. Consigner les résultats et les réexaminer : conserver la version du modèle, la version des questions, les probabilités, la destination finale et les corrections humaines, afin de pouvoir juger si les seuils sont adaptés.

Source de l'image : TypeSafe AI, « Introducing System One Models & Jev », 2026-09-15. Les quatre workflows ont été construits par TypeSafe ; les métriques sont agrégées à pondération égale par workflow ; la méthode d'évaluation est décrite dans Évaluations de workflows TypeSafe.

Ce graphique officiel aide à comprendre pourquoi l'accent est mis sur le fait de « faire entrer plusieurs jugements étroits dans un workflow logiciel ». L'axe vertical reprend le nom « accuracy » utilisé par le fournisseur, mais sa réponse de référence provient d'un consensus de probabilités prédites par deux grands modèles, et non d'une réponse unique correcte vérifiée humainement ; les coûts et les métriques dépendent aussi de ces quatre workflows et de la méthode d'évaluation du fournisseur, et ne peuvent pas être convertis en « combien on peut économiser dans n'importe quel scénario ».

Génération augmentée par récupération : Jev filtre les preuves avant la réponse du LLM

Le guide pratique TypeSafe sur les passages RAG fournit un exemple multi-modèle plus concret : OpenAI embedding récupère d'abord des passages, puis Jev pose quatre Noul pour chaque « question + passage » — pertinent ou non, contient ou non une preuve utilisable pour répondre, réfute ou non une prémisse de la question, tente ou non de donner des instructions au modèle de réponse. Le code traite les quatre probabilités dans l'ordre et décide de placer le passage dans la zone de preuves, la zone de preuves contradictoires, ou de le rejeter ; enfin Claude Sonnet 5 rédige la réponse.

Cette étape résout un problème fréquent : un passage à forte similarité vectorielle n'est pas forcément utilisable. Il peut n'employer que des mots similaires, ou contenir, dans un post de forum, une injection de prompt du type « ignore ce qui précède ». L'exemple du guide pratique place la vérification d'injection au tout début des règles de routage, tout en rappelant que le seuil est un point de départ choisi pour ce corpus, et non une valeur par défaut pour toutes les applications RAG. Ses chiffres de démonstration proviennent de jev-1.12 le 2026-08-27 et ne doivent pas être pris pour de nouveaux résultats d'évaluation de jev-1.13.0.

Après la génération, une couche de vérification supplémentaire est possible. Le guide pratique TypeSafe de vérification des citations utilise d'abord un programme pour retrouver le texte source cité, puis Jev pour juger si ce passage soutient, réfute ou ne mentionne pas l'affirmation générée. Il peut faire ressortir les citations qui méritent un réexamen ; le jugement du modèle peut lui-même se tromper, et « avoir passé la vérification » ne doit pas être présenté comme une garantie factuelle.

Notre calibration d'Agent : où l'escalade à faible confiance peut-elle se bloquer ?

Dans le dépôt PandaNpc, le client Jev, la banque de questions et l'orchestrateur utilisent Jev pour la reconnaissance d'intention de l'Agent, la notation des modifications candidates, la vérification des conditions d'achèvement et la décision de soumission. Le client effectue aussi des tentatives limitées sur les délais d'attente dépassés, les 429 et les 5xx, et limite le budget de requêtes et les résultats périmés ; les permissions d'exécution sont détenues par l'orchestrateur et la couche d'outils contrôlés, et ne sont pas accordées directement par un jugement de Jev.

Le 2026-09-22, nous avons utilisé jev-1.13.0 pour exécuter 19 turns synthétiques une fois en shadow et une fois en enforce, soit 38 exécutions au total, et consigné 165 décisions Jev réelles. Ce rapport de calibration interne et les réponses réelles conservées utilisent un fournisseur LLM factice scripté ; ces données ne décrivent donc que la performance décisionnelle dans un scénario contrôlé. Elles ne prouvent ni le taux de réussite global, ni le pourcentage d'économies, ni la latence de bout en bout sur de vraies requêtes utilisateur.

La découverte la plus utile n'est pas la vitesse moyenne, mais un seuil « apparemment sûr » qui a provoqué un blocage : sur les 19 turns en enforce, 13 ont été escaladés à la Q2 « les informations sont-elles suffisantes pour commencer une modification ? », parce que la probabilité Noul tombait dans l'intervalle d'incertitude initial de 0,15–0,85 ; le LLM Worker n'a pas eu l'occasion d'exécuter les étapes suivantes. Les enregistrements de calibration montrent que, parmi 34 décisions Q2 annotées comme suffisamment informées, beaucoup avaient des probabilités dans la zone médiane. Le rapport recommande de découper la Q2 complexe en jugements plus atomiques, ou d'ajuster les règles d'escalade ; ce sont des recommandations, pas des seuils déjà déployés.

Notre banque de questions classe l'entrée en answer_only, inspect, modify ou out_of_scope ; sur le chemin d'écriture, les modifications candidates proposées par le Worker sont d'abord classées par Score, puis le contenu final et le résumé des changements passent par une validation et une décision de soumission. Ce ne sont que des points de décision : la possibilité réelle de lire ou d'écrire un objet reste accordée par étapes par l'exécuteur contrôlé. Jev n'a pas le pouvoir d'assouplir lui-même la liste blanche des outils, ni de contourner la vérification de cohérence avant soumission.

Les données de calibration révèlent un autre compromis. En mode shadow, Jev donne la réponse et la distribution complète, mais ne modifie pas le chemin d'exécution initial du Worker ; en mode enforce, la réponse influence la poursuite, l'escalade ou l'abandon. Prendre directement l'exactitude du shadow pour le taux d'achèvement de l'enforce serait mal comprendre le système : l'escalade de la Q2 intercepte la tâche plus tôt, si bien que les questions suivantes de notation des candidats, de validation et de soumission n'ont même pas l'occasion d'apparaître. C'est pourquoi ce rapport lit séparément la distribution par question, la direction d'escalade et l'état final.

Un contraste concret parmi les modifications candidates : dans le même turn, une candidate qui modifie précisément la cible a obtenu 2,94 points, tandis qu'une candidate qui écrase tout le fichier a obtenu 0,38 point ; la candidate la mieux notée a été sélectionnée. Cet exemple montre seulement que, dans ce scénario synthétique, la question de notation a distingué les deux propositions. À l'inverse, une candidate dont les preuves étaient tronquées a obtenu 2,27 points ; il ne faut pas ignorer sa faible confiance et son marqueur de troncature parce que la valeur paraît « plutôt bonne ». Notre code signale séparément les preuves incomplètes, afin d'éviter que le modèle prenne une décision d'écriture certaine sur la seule base du préfixe conservé.

Nous séparons aussi « quel candidat choisir » et « l'autoriser à écrire » en deux étapes distinctes. Une fois la candidate notée par Jev, l'exécuteur contrôlé n'ouvre les outils d'écriture qu'à la phase ACT/modify ; le ticket à usage unique émis est lié à l'ID d'appel d'outil, au numéro de révision courant, au hash de l'objet cible et au résumé des paramètres. Même si le texte de la candidate incite le modèle à « ignorer les restrictions », il n'obtient pas les permissions d'outil permettant de franchir ces vérifications. C'est une leçon tirée de notre intégration au niveau du code : le jugement probabiliste détermine quelle voie mérite d'être suivie, tandis que les permissions d'effet de bord sont déterminées par des conditions logicielles vérifiables.

Les chemins d'échec doivent aussi être conçus. Le client ne fait des tentatives limitées qu'en cas de délai d'attente dépassé, d'erreur réseau, de 429 ou de 5xx ; les réponses annulées ou dépassant l'échéance du turn sont directement abandonnées. Si Jev est indisponible en mode enforce, l'exécution ne peut pas continuer sans autorisation de dégradation ; si le passage à llm_only est autorisé, l'exécuteur se verrouille en lecture seule. Si une branche a déjà été modifiée avant la perte de Jev, l'orchestrateur marque tout le tour comme échoué, plutôt que de laisser le LLM suivant effectuer des écritures de rattrapage sans couche de décision. Ces chemins ont un coût pour l'expérience utilisateur, mais ils évitent que « le modèle est temporairement indisponible » ne devienne discrètement « les permissions d'écriture restent les mêmes ».

Le rapport de calibration distingue aussi « escalade à faible confiance » et « refus d'exécution ». Par exemple, un discard correct dont la confiance n'atteint pas le seuil uniforme de 0,85 est enregistré comme nécessitant une intervention de l'utilisateur ; cela n'équivaut pas à un passage erroné. Le rapport recommande donc de séparer les seuils de soumission et de rejet, mais cela reste pour l'instant une recommandation. Lorsqu'on écrit un workflow, il faut distinguer trois résultats — passage erroné, refus erroné et mise en attente —, sinon le même jeu de données conduit à des conclusions erronées sur les seuils.

Ce cas montre que la collaboration entre Jev et un LLM ne peut pas se résumer à « Jev juge d'abord, le LLM travaille ensuite ». Chaque jugement doit poser les questions suivantes : quelle est la largeur de l'intervalle d'incertitude ? Empêchera-t-il le processeur suivant de recevoir un jour la tâche ? Si les preuves d'entrée sont tronquées, peut-on escalader explicitement plutôt que deviner ? Dans notre implémentation, le constructeur de state consigne evidence_truncated et demande à l'appelant de considérer les chemins sans preuves comme incertains ; les calculs déterministes comme le comptage et le tri sont effectués d'abord dans le code, et non confiés à Jev. Les limites connues officielles de Jev 1.13 recommandent également de laisser le comptage et l'arithmétique dans le code.

Où placer les garde-fous LLM ?

Le guide pratique TypeSafe sur les garde-fous LLM place Jev des deux côtés de l'entrée et de la sortie du LLM. Il utilise un ensemble de Noul pour identifier différents risques, Score pour mesurer la gravité, puis le code décide selon la politique d'autoriser, de faire réviser par un humain, de bloquer ou de transférer au support. La sortie doit aussi être vérifiée, car une entrée ordinaire peut malgré tout produire un résultat inapproprié.

Les limites de ce type de garde-fou sont tout aussi claires : Jev peut vérifier un contenu selon des questions écrites à l'avance, mais il ne constitue pas une preuve de sécurité universelle. La documentation officielle des limites mentionne explicitement que du contenu malveillant peut influencer le jugement, et demande de bien écrire les criteria et de tester les limites. Dans nos échantillons synthétiques, nous avons réalisé 16 sondes d'injection visant les paramètres candidats et enregistré 0 inversion de classement ; l'échantillon est trop petit pour en conclure que « l'injection de prompt est résolue ». Ce qui détermine réellement ce que les outils peuvent faire reste la liste d'autorisation, les barrières par phase et les vérifications avant soumission dans le code.

Quand est-ce adapté, et quand faut-il l'éviter ?

Jev convient lorsque : l'ensemble des candidats est connu, la question peut être découpée en quelques jugements courts, et le logiciel a besoin de probabilités pour décider d'un traitement automatique ou d'une escalade humaine. Par exemple le routage du service client, le filtrage de passages RAG, la notation d'actions candidates d'Agent, la vérification des citations dans un résultat généré. Si la tâche demande d'écrire une réponse, de modifier un bout de code ou d'expliquer un raisonnement complexe, c'est le LLM qui prend le relais. Si la tâche consiste à calculer précisément de l'argent, comparer des dates ou vérifier un contrôle d'accès, le programme doit calculer directement. La page des modèles précise aussi que Jev n'accepte que du texte, et que l'anglais est la langue d'entraînement la plus performante actuellement ; un scénario en chinois doit être évalué avec ses propres données, sans reprendre tel quel les seuils d'un guide pratique anglais.

Pour observer comment un Agent réel gère les permissions et les appels d'outils, on peut d'abord consulter PandaNpc Agent ; pour les limites et les cas d'usage des agents de codage, on peut aussi se référer à Comparaison entre Claude Code et Codex.

Le lecteur peut commencer avec un très petit ensemble de validation : préparer quatre catégories d'échantillons — « clairement traitable automatiquement », « clairement à refuser », « sémantiquement ambigu », « contenant des instructions malveillantes » ; établir d'abord l'annotation humaine, puis consigner les probabilités de Jev pour chaque question et les résultats de routage. Le critère de réussite n'est pas que chaque cas passe automatiquement, mais que le taux d'erreur du chemin de traitement automatique et le volume d'escalades humaines restent dans une plage acceptable pour vous. Si de nombreux échantillons ambigus bloquent sur la même question, vérifier d'abord si la question mélange plusieurs jugements, si le state est trop long, ou si les seuils sont calibrés sur les données locales.

FAQ

Jev peut-il remplacer Claude Code, Codex ou un modèle de chat ? Non. TypeSafe le positionne comme un modèle de décision structuré au sein d'un logiciel ; le chat, la rédaction et la génération de code nécessitent toujours un LLM.

Le type de retour étant fixe, cela signifie-t-il qu'il ne peut pas se tromper ? Non. Un type fixe réduit les problèmes d'analyse et de sortie hors limites, mais la classification, la notation et le jugement factuel peuvent encore se tromper. Les chemins à faible confiance et à haut risque doivent conserver une relecture humaine.

Combien de questions peut-on poser dans une même requête ? On peut placer dans une même requête plusieurs questions indépendantes Choice, Score et Noul partageant le même state. Chaque question est évaluée séparément ; les jugements complexes doivent encore être découpés, puis combinés par le code.

Le chinois est-il utilisable ? La documentation officielle indique qu'il prend en charge les langues naturelles, y compris les écritures chise, japonaise et coréenne, mais'anglais offre actuellement la meilleure exactitude. charge de travail en chinois nécessite une validation et une calibration distinctes.