Jev expliqué clairement

Nous utilisons les LLM comme un marteau pour tous les problèmes d'IA, même pour des décisions simples. Jev gère ces décisions en quelques millisecondes et à une fraction du coût. Voyons comment cela fonctionne et où il s'intègre.

TypeSafe AI a lancé Jev le 15 septembre 2026, et la réaction a été exceptionnellement forte pour un modèle incapable de tenir une conversation, d'écrire du code ou de générer un seul paragraphe utile.

Eh bien, cette limitation est précisément l'objectif.

La plupart des logiciels n'ont pas besoin d'un autre chatbot. Ils ont besoin de prendre des milliers de petites décisions, par exemple : Ce ticket est-il urgent ? Quel modèle doit traiter cette requête ? Cette commande shell est-elle dangereuse ? Le passage récupéré répond-il à la question ?

Les équipes envoient souvent chaque décision à un LLM généraliste. Le modèle génère une réponse token par token, l'application l'analyse, la valide et effectue des tentatives supplémentaires lorsque le format est incorrect. Cela fonctionne, mais c'est lent et coûteux pour une décision qui n'a que cinq réponses possibles.

Jev est conçu spécifiquement pour ces décisions. TypeSafe le qualifie de modèle « Système One » : on y injecte un état non structuré, et il en ressort des réponses typées et des probabilités.

Décomposons ce que cela signifie, où cela s'intègre, et là où le marketing devrait faire preuve d'un peu plus de retenue.

Le problème que Jev résout

Il est devenu beaucoup plus facile de connecter les LLM aux logiciels dès l'arrivée des appels d'outils (tool calling) et des sorties structurées.

L'appel d'outils permet au modèle de demander une fonction dans un format prévisible. Les sorties structurées lui permettent de renvoyer du JSON respectant un schéma. Ces deux innovations ont éliminé une grande partie de l'analyse fragile (parsing).

Mais le modèle sous-jacent reste génératif. Même si la réponse ne consiste qu'en un seul mot « billing », il produit les tokens séquentiellement. Vous payez pour l'entrée, attendez la génération, et payez souvent plus cher pour la sortie.

Placez maintenant cela dans une boucle agentique.

1while not done:
2    action = llm(context)
3    result = run_tool(action)
4    context += result

Le modèle peut être appelé à nouveau pour choisir un outil, juger un résultat, détecter un risque, décider si la tâche est terminée et sélectionner le prochain modèle. Une seule exécution d'agent peut contenir de nombreux appels nécessitant un jugement mais aucune prose générée.

Jev cible ces appels.

Son pari est simple : la génération de langage est la mauvaise interface lorsque le code connaît déjà les réponses possibles.

Ce qu'est réellement Jev

La description courte et précise est celle d'un moteur de décision sémantique.

Vous envoyez à Jev deux éléments :

• État : le texte ou le JSON décrivant la situation actuelle.
• Questions : les décisions que vous souhaitez qu'il prenne concernant cet état.

Chaque question déclare sa forme de réponse à l'avance. Jev prend en charge trois primitives :

• Choice sélectionne une option dans une liste que vous définissez et retourne une probabilité pour chaque option.
• Score place l'entrée sur une échelle ordonnée que vous définissez, telle que faible, moyen et élevé.
• Noul répond à une question oui/non en retournant la probabilité que la réponse soit vraie.

Noul est le nom donné par TypeSafe à la primitive de type booléen. Le nom inhabituel importe moins que la sortie (un nombre entre 0 et 1 sur lequel votre code peut agir).

1{
2  "model": "jev-latest",
3  "state": "The deploy failed twice and customers are seeing 500s.",
4  "questions": {
5    "urgent": {
6      "type": "noul",
7      "instructions": "Does this need attention right now?"
8    },
9    "owner": {
10      "type": "choice",
11      "instructions": "Which team should handle this?",
12      "criteria": {
13        "engineering": "Product failures and outages",
14        "billing": "Charges, invoices, and refunds",
15        "sales": "Pricing and new accounts"
16      }
17    }
18  }
19}

La réponse contient une probabilité d'urgence et une distribution de probabilités sur les trois équipes. Il n'y a pas de paragraphe à interpréter ni de quatrième équipe que le modèle pourrait inventer.

Votre programme garde le contrôle :

1if urgent > 0.9 and owner == "engineering":
2    page_on_call()
3elif confidence < 0.6:
4    send_to_human_review()
5else:
6    add_to_queue(owner)

C'est pourquoi les gens continuent d'appeler Jev une instruction switch intelligente. La phrase semble péjorative, mais elle capture la partie utile de la conception. Le code ordinaire possède les branches. Le modèle fournit le jugement flou que le code ordinaire ne peut pas calculer de manière fiable.

La différence importante avec un LLM

Un LLM traditionnel et Jev peuvent tous deux classifier un ticket de support. Ils parviennent à la réponse différemment et sont utiles dans différentes parties d'un système.

TypeSafe affirme que Jev évalue chaque question d'une requête en parallèle. Cela change la façon dont vous concevez le flux de travail. Au lieu de poser une question, d'attendre et de décider quelle question vient ensuite, vous pouvez poser toutes les questions indépendantes sur le même état dans une seule requête et laisser le code utiliser les réponses dont il a besoin.

L'entreprise rapporte une latence de bout en bout comprise entre 70 et 500 millisecondes et un prix de 0,042 $ par million de tokens d'entrée, avec une sortie gratuite. Ses affirmations phares atteignent environ 200 fois plus vite et 400 fois moins cher que les flux de travail LLM comparables.

Ces grands multiples proviennent des évaluations de flux de travail internes de TypeSafe et se situent à l'extrémité favorable de la comparaison. Traitez-les comme un plafond, pas comme une promesse pour chaque application. L'avantage sous-jacent reste crédible, car Jev évite les longues traces de raisonnement et la sortie générée puisqu'il a été conçu pour des décisions bornées.

Pourquoi les probabilités comptent

Une réponse typée ne résout que la moitié du problème.

Supposons que Jev route un ticket vers la facturation. L'étiquette sélectionnée vous indique ce qui a gagné. La distribution de probabilités vous indique combien la course était serrée.

1{
2  "choice": "billing",
3  "probabilities": {
4    "billing": 0.52,
5    "technical": 0.46,
6    "sales": 0.02
7  },
8  "confidence": 0.18
9}

Router automatiquement ce ticket serait imprudent. La facturation a gagné, mais de justesse. Une réponse à faible confiance devrait déclencher une branche différente.

Cela donne aux développeurs un modèle pratique :

• Confiance élevée : agir automatiquement lorsque la conséquence est mineure.
• Confiance moyenne : demander une confirmation ou appeler un modèle plus puissant.
• Confiance faible : envoyer le cas à une personne ou collecter plus d'informations.

Les seuils appartiennent au code, où ils peuvent être examinés et modifiés. Une étiquette de tableau de bord peut tolérer une prédiction faible. Une commande qui supprime des données devrait exiger une barre beaucoup plus haute.

TypeSafe entraîne Jev en utilisant l'apprentissage par renforcement pour des décisions calibrées (RLCD). L'objectif est que la confiance reflète la précision sur de nombreuses prédictions. Si un modèle donne un ensemble de réponses avec une probabilité de 90 %, environ 90 % de ces réponses devraient être correctes.

L'affirmation sur l'hallucination nécessite de la précision

TypeSafe dit que Jev ne peut pas halluciner. Cette affirmation n'est vraie que selon une définition étroite.

Jev ne peut pas retourner une option hors du schéma. Si vous définissez facturation, technique et ventes, la réponse ne peut pas inventer juridique. Il ne peut pas non plus produire de prose mal formée là où votre code attendait une étiquette.

Mais il peut choisir avec assurance la mauvaise option valide.

La sécurité des types empêche les formes invalides. Elle ne garantit pas un jugement correct. Cette distinction est importante car une erreur valide selon le schéma peut toujours rembourser le mauvais client, router un incident incorrectement ou approuver une commande dangereuse.

Une phrase plus sûre est : « Jev ne peut pas casser le schéma de sortie déclaré, mais il peut encore se tromper ».

Où Jev s'intègre dans un agent

Jev fonctionne mieux lorsqu'il est utilisé avec un LLM plutôt que de le remplacer.

Le LLM gère le travail qui nécessite du langage ou un raisonnement plus profond. Il planifie, écrit, explique et utilise des outils. Jev gère les décisions fréquentes autour de ce travail.

Trois placements sont particulièrement convaincants.

Routage de modèles

Une recherche simple n'a pas besoin du même modèle qu'une revue d'architecture. Jev peut noter la requête et choisir le modèle le moins susceptible de la compléter.

1route = jev.choice(
2    state=user_request,
3    options={
4        "fast": "Lookups, extraction, and small local edits",
5        "powerful": "Architecture, ambiguity, and high-stakes work",
6    },
7)
8
9model = fast_model if route == "fast" else powerful_model

Le routeur ne répond pas à la requête. Il décide quel modèle devrait le faire.

Filtrage des risques liés aux outils

Avant qu'un agent n'exécute une commande shell, Jev peut la classer comme lecture seule, réversible ou destructive. Des questions séparées peuvent vérifier si elle supprime des fichiers, modifie l'historique Git, touche à la production ou quitte le dépôt.

Les actions en lecture seule à haute confiance peuvent continuer. Les actions destructives ou incertaines peuvent mettre en pause pour approbation humaine. L'intégration Jev de LangChain applique ce modèle via un middleware qui vérifie un appel d'outil avant l'exécution.

Vérification et supervision

Un agent peut affirmer qu'une tâche est terminée alors que les tests échouent encore. Jev peut inspecter l'état et répondre à des questions bornées : Les tests ont-ils réussi ? L'agent répète-t-il la même action ? La sortie suit-elle la politique ? Ce résultat doit-il être examiné ?

Il ne remplacera pas un test dur lorsqu'il existe. Il ajoute une vérification sémantique là où la règle dépend du sens.

Problèmes que Jev peut résoudre aujourd'hui

Les meilleurs cas d'utilisation partagent trois propriétés. Vous pouvez nommer les réponses possibles, un humain attentif pourrait juger l'entrée rapidement, et la décision se produit assez souvent pour que la latence ou le coût compte.

Support et opérations

• Classifier l'intention, l'urgence, le département, le spam et la frustration du client.
• Router les remboursements et les exceptions de politique via plusieurs petits contrôles.
• Classer les journaux et les incidents par gravité sémantique avant qu'une personne ne les lise.

Une seule requête peut poser toutes ces questions sur le même ticket. Le code combine ensuite les réponses dans la politique de routage réelle de l'entreprise.

Recherche et récupération

• Re-classer les passages récupérés selon qu'ils répondent à la requête.
• Vérifier si une citation soutient une affirmation.
• Filtrer les chunks irrélevants avant d'envoyer le contexte à un LLM coûteux.

Les embeddings sont excellents pour trouver du texte sémantiquement lié. Jev peut prendre la décision plus étroite de savoir si un passage particulier est utile pour cette question.

Qualité et sécurité

• Écran les prompts contre les jailbreaks ou l'injection de prompt.
• Vérifier le contenu généré contre une politique ou une grille d'évaluation.
• Signaler les modifications de code risquées ou les appels d'outils avant leur exécution.

Ces contrôles devraient se situer à côté des contrôles déterministes. Un classificateur sémantique est utile pour le risque flou, tandis que les permissions, les sandboxes et les tests appliquent des règles que le logiciel peut vérifier exactement.

Classification à haut volume

• Étiqueter des documents, des articles de recherche, des fiches produits ou des messages clients.
• Transformer du texte libre en caractéristiques pour un modèle d'apprentissage automatique traditionnel.
• Noter chaque élément d'un grand corpus contre la même grille d'évaluation.

C'est là que le faible coût par appel devient plus qu'un chiffre de benchmark. Une décision trop coûteuse pour être exécutée sur chaque ligne peut entrer dans le pipeline de données normal.

Interfaces temps réel

• Choisir la prochaine action du navigateur parmi les éléments de page connus.
• Noter le ton ou la clarté pendant qu'une personne écrit.
• Sélectionner une action à partir d'un état de jeu ou de simulateur structuré.

Jev est uniquement textuel aujourd'hui, donc ces systèmes doivent convertir l'environnement en texte ou en JSON d'abord. Il ne regarde pas l'écran ni ne joue à partir des pixels.

Où Jev est le mauvais choix

Jev devient moins utile dès que l'espace de réponses cesse d'être connu.

• Il ne peut pas écrire une réponse, résumer un document, générer du code ou expliquer son raisonnement.
• Il n'est pas fiable pour l'arithmétique, le comptage, la comparaison de dates ou la manipulation exacte de chaînes. Gardez ces opérations dans le code.
• Il lutte lorsqu'une décision nécessite plusieurs étapes de raisonnement cachées. Divisez la décision en questions plus petites ou utilisez un modèle de raisonnement.
• Il ne peut pas extraire une valeur inconnue directement. Trouvez d'abord les valeurs candidates, puis laissez Jev choisir parmi elles.
• Le contexte irrélevant peut réduire la précision. Envoyez uniquement l'état requis pour la décision.
• Poids fermés, accès anticipé, entrée uniquement textuelle et données de calibration indépendantes limitées rendent la confiance aveugle prématurée.

Il y a aussi une règle plus simple : si le code déterministe résout déjà le problème correctement, gardez le code. Une instruction if normale est plus rapide, moins chère et plus facile à tester que n'importe quel modèle.

Comment utiliser Jev sans créer un nouveau mode de défaillance

Un modèle bon marché peut encore être coûteux si ses erreurs créent des tentatives supplémentaires, des examens manuels ou des incidents de production. Mesurez tout le flux de travail, pas seulement le prix des tokens.

Un déploiement judicieux ressemble à ceci :

1. Choisissez une décision bornée et à faible risque avec des réponses possibles claires.
2. Écrivez la grille d'évaluation avant d'appeler le modèle. Définissez ce qui appartient à chaque option.
3. Collectez des exemples représentatifs avec les réponses attendues, y compris les cas ambigus et adversariaux.
4. Exécutez Jev en mode ombre à côté du flux de travail actuel sans lui permettre de changer le comportement.
5. Tracez la précision contre la confiance et définissez les seuils à partir de vos données.
6. Automatisez d'abord la branche la plus sûre et gardez un humain ou un modèle plus puissant pour les cas incertains.
7. Épinglez ou journalisez la version du modèle, les questions, les critères et les seuils afin que les changements puissent être rejoués contre le même ensemble d'évaluation.

Les questions font partie du programme. Traitez-les comme du code : versionnez-les, examinez-les et testez-les chaque fois que le modèle ou la grille d'évaluation change.

Le véritable changement

Jev n'est pas intéressant parce qu'il bat un LLM à l'écriture. Il refuse d'écrire.

Sa contribution est une interface de modèle façonnée comme un logiciel : types de réponses fixes, incertitude explicite, questions parallèles et branchement contrôlé par le code.

Cela en fait un compagnon utile aux modèles génératifs. Le LLM produit le plan, l'explication ou le code. Jev route la requête, filtre l'action risquée, vérifie le résultat et décide quand l'incertitude est assez élevée pour escalader.

L'idée plus large compte même si un autre modèle finit par remplacer Jev. Nous avons passé des années à demander aux modèles génératifs d'effectuer tous les types d'intelligence via le texte. De nombreux systèmes de production n'ont pas besoin de plus de mots. Ils ont besoin d'une petite décision rapide que le logiciel ordinaire peut utiliser en toute sécurité.

C'est la catégorie que Jev essaie de construire.

Par où commencer

Ne commencez pas par reconstruire votre agent autour de Jev. Trouvez une décision qui nécessite actuellement un appel LLM lent ou une regex qui continue de casser.

Donnez à Jev l'état minimum, définissez les réponses possibles et journalisez ses probabilités à côté du résultat actuel. Laissez-le prouver qu'il mérite une branche avant de lui confier tout le flux de travail.

Le modèle mental le plus utile reste le plus simple → Jev ajoute du jugement là où une instruction if ordinaire comprend les valeurs mais pas leur signification.

Sources et lectures complémentaires

• TypeSafe AI : Présentation des modèles Système One et de Jev
• LangChain : Construire un harnais avec Jev
• Flavio Copes : Une plongée en profondeur dans Jev

J'espère que vous avez apprécié la lecture.

À la prochaine !

Salutations ! :)