Jev est le premier modèle System One de TypeSafe AI, conçu pour les applications qui nécessitent des décisions structurées plutôt que du texte généré. Il évalue les informations fournies au regard de questions clairement définies et renvoie des réponses typées, des distributions de probabilité et, le cas échéant, des scores de confiance.

Contrairement à un grand modèle de langage classique, Jev n’est pas destiné à discuter, écrire du code ou créer du contenu long. Son objectif est de porter des jugements bornés que les logiciels peuvent utiliser immédiatement pour la classification, l’acheminement, le scoring, la vérification, la priorisation et le contrôle de workflows.

Les informations sur le modèle ont été examinées le 21 septembre 2026.

Spécifications techniques de Jev

Les tarifs, alias et limites de débit peuvent évoluer. Les développeurs doivent vérifier les informations les plus récentes avant de mettre une charge de travail en production.

Qu’est-ce que Jev ?

Jev est un modèle de décision développé par TypeSafe AI. Au lieu de générer une séquence de jetons ouverts, il sélectionne des valeurs dans des espaces de réponse définis par le développeur.

Une requête Jev contient deux composants principaux :

• État : Les informations que le modèle doit évaluer, telles qu’un ticket d’assistance, un enregistrement de transaction, une trace d’agent, une description de produit ou un état d’application au format JSON.
• Questions : Des définitions typées des jugements à porter sur cet état.

Les réponses résultantes sont destinées à une utilisation directe par les logiciels. Une application peut bifurquer selon une catégorie sélectionnée, comparer des scores, inspecter des probabilités, appliquer un seuil de confiance ou envoyer un cas incertain à un réviseur humain.

Jev agit donc comme une couche de décision probabiliste entre les données applicatives et la logique métier déterministe. Il gère des jugements difficiles à exprimer par des règles fixes tout en permettant au code applicatif de conserver le contrôle des seuils, des permissions et des actions.

Comment fonctionne Jev

Trois primitives de décision

Jev prend en charge trois types de questions conçus pour différents types de décisions logicielles.

Choice sélectionne une option parmi un ensemble prédéfini. Il convient à des tâches telles que la classification d’intention, l’acheminement de tickets, la catégorisation de politiques et la sélection de modèles. La réponse inclut l’option sélectionnée, la probabilité attribuée à chaque option et un score de confiance.

Score évalue l’état selon un barème ordonné. Il peut mesurer des qualités comme l’urgence, le risque, la pertinence, la frustration ou la qualité de contenu. La réponse inclut un score, des probabilités pour chaque niveau du barème et un score de confiance.

Noul estime la probabilité qu’une affirmation soit vraie. Il renvoie une valeur entre 0 et 1 et est utile pour la vérification, les contrôles de politique, les décisions d’éligibilité et les étapes de complétion. Contrairement à Choice et Score, Noul ne renvoie pas de champ de confiance séparé car sa sortie est déjà une probabilité.

Évaluation parallèle des questions

Une seule requête peut contenir plusieurs questions Choice, Score et Noul. Jev les évalue indépendamment et en parallèle par rapport au même état.

Par exemple, une plateforme d’assistance peut classer un ticket, évaluer son urgence et estimer s’il faut une escalade humaine en une seule requête. TypeSafe indique que l’ajout de questions indépendantes a peu d’effet sur le temps de réponse.

Les questions d’une même requête ne peuvent pas dépendre des réponses des autres. Les décisions séquentielles doivent être implémentées par des appels séparés reliés par la logique applicative.

Réponses avec sécurité de typage

Les structures de réponse possibles de Jev sont définies avant l’inférence. Cela empêche l’apparition de JSON mal formé, de champs inattendus et de texte explicatif là où une catégorie ou une valeur numérique est requise.

La sécurité de typage garantit uniquement le format de la réponse. Jev peut toujours renvoyer une décision valide mais incorrecte ; les équipes de production doivent donc évaluer sa précision sur des données représentatives.

Probabilité et confiance explicites

Choice et Score exposent la distribution de probabilité derrière chaque réponse. Leur valeur de confiance résume à quel point cette distribution favorise un résultat.

Les applications peuvent utiliser la confiance pour automatiser les décisions claires, demander une confirmation lorsque l’incertitude est modérée et orienter les cas ambigus vers un humain ou un modèle de secours.

Le seuil approprié dépend du risque. Étiqueter un ticket d’assistance tolère plus d’incertitude qu’approuver une transaction ou exécuter une action irréversible.

Inférence à faible latence

TypeSafe indique des temps de réponse de bout en bout d’environ 70 à 500 millisecondes. Cela rend Jev adapté au routage interactif, aux vérifications répétées par agent et à d’autres workflows riches en décisions où un appel à un modèle génératif plus lent pourrait affecter la réactivité.

La latence réelle dépend de la taille de l’état, de la charge du service, des conditions réseau et de la région de déploiement.

Personnalisation au niveau de la requête

Jev n’est pas personnalisé via un fine-tuning spécifique au compte ni des adaptateurs LoRA. Les développeurs l’adaptent en fournissant un état pertinent, en écrivant des instructions précises, en définissant des critères clairs et en combinant des décisions atomiques dans le code applicatif.

Cette approche maintient les règles métier visibles et permet aux équipes de modifier la logique de workflow sans réentraîner le modèle.

Modèles versionnés et alias stables

TypeSafe fournit des IDs de modèle fixes et des alias évolutifs. jev-1.13.0 identifie une version spécifique, tandis que jev-latest pointe vers la dernière version stable. jev-preview peut pointer vers une nouvelle version d’aperçu lorsqu’elle est disponible.

Les alias simplifient l’expérimentation, mais leur comportement peut changer après une mise à jour. Les applications de production avec des seuils calibrés devraient épingler une version testée et enregistrer l’ID de modèle renvoyé avec chaque réponse.

Performances de référence de Jev

Jev n’est pas conçu pour des benchmarks généralistes axés sur l’écriture, le codage, les dérivations mathématiques ou le raisonnement long. Des mesures plus pertinentes incluent la qualité de décision, la calibration des probabilités, la latence, le coût et la fiabilité de sortie.

TypeSafe rapporte :

• Des temps de réponse de bout en bout de 70–500 millisecondes
• Une exécution environ 40–200× plus rapide sur des tâches System One comparables
• Des résultats de flux de travail de pointe de 193.6× plus rapides
• Des améliorations de coût maximales rapportées de 444.6×

Ce sont des résultats rapportés par le fournisseur et ne doivent pas être considérés comme des garanties de performance universelles. Les évaluations de workflow de TypeSafe comparent des modèles sur des graphes de décision structurés et utilisent les prédictions moyennées de modèles externes haut de gamme sélectionnés comme probabilités de référence.

TypeSafe reconnaît également que des membres de son équipe chargée des capacités du modèle ont créé les workflows évalués, ce qui peut introduire un biais. Les gains rapportés sont probablement proches de la limite supérieure de ce que les applications peuvent observer.

Jev vs LLM à sortie structurée vs Classificateur classique vs Moteur de règles

Jev est le plus utile lorsque des règles fixes sont trop fragiles, qu’un classificateur dédié serait coûteux à créer et que l’application n’a pas besoin de texte généré.

Un LLM traditionnel reste un meilleur choix lorsqu’une tâche requiert de la recherche, des explications, de la création de contenu, de la planification ou un raisonnement en plusieurs étapes. Un moteur de règles reste préférable lorsque la condition correcte est déjà explicite et déterministe.

Cas d’utilisation recommandés

Jev convient le mieux aux décisions fréquentes avec un espace de réponse prédéfini.

• Routage et tri : Classer les requêtes, sélectionner des files d’attente ou des outils, et prioriser les cas urgents.
• Contrôle d’agents : Vérifier l’achèvement des tâches, évaluer les actions proposées et identifier les cas nécessitant une confirmation.
• Évaluation de LLM : Évaluer la pertinence, le support par les preuves, la conformité aux politiques ou la qualité des réponses.
• Modération : Catégoriser les violations de politique, noter la gravité et escalader les cas incertains.
• Enrichissement des données : Convertir des messages, avis, prospects et enregistrements en catégories, scores et caractéristiques probabilistes.
• Décisions en temps réel : Soutenir des comportements applicatifs à faible latence lorsque qu’une réponse générative complète est inutile.

Limites de Jev

Jev est volontairement spécialisé, et son design étroit entraîne plusieurs limites importantes.

• Il ne peut pas générer de prose, de code, de résumés ni de réponses conversationnelles.
• Il n’est pas destiné à la recherche approfondie ni au raisonnement multi-étapes.
• La sécurité de typage de la sortie ne garantit pas une décision métier correcte.
• Les images, l’audio, la vidéo et les fichiers binaires doivent être convertis en texte ou en données structurées avant soumission.
• L’anglais est la langue la mieux documentée.
• Les charges de travail non anglophones et CJK nécessitent une évaluation indépendante.
• Les questions d’une même requête sont évaluées indépendamment.
• Le modèle ne peut pas construire une chaîne de raisonnement séquentielle entre ces questions.
• TypeSafe n’a pas divulgué le nombre de paramètres du modèle ni publié ses poids.
• La personnalisation se fait via la requête plutôt que par un affinement spécifique au client.
• Les gains de performance publiés proviennent du propre cadre d’évaluation de TypeSafe.
• Les alias évolutifs peuvent introduire des changements de comportement sans modification du code de l’application.

Jev ne doit pas remplacer du code déterministe pour les permissions, les calculs financiers, les exigences légales, les limites de taille de fichier ou les politiques d’actions irréversibles. Les modèles probabilistes sont utiles pour des jugements incertains, pas pour des conditions que le logiciel peut déjà évaluer exactement.

Comment CometAPI fournit-il l’accès à l’API Jev ?

Jev n’est pas actuellement disponible dans le catalogue public de modèles de CometAPI. CometAPI prévoit d’évaluer et d’intégrer Jev une fois que l’accès au modèle sera disponible et que les permissions de connexion requises seront ouvertes.

Après l’intégration, les développeurs pourront consulter l’annuaire des modèles CometAPI et la documentation de l’API pour l’ID de modèle pris en charge, le format de requête, les tarifs, les limites de débit et la disponibilité des endpoints.

Jusqu’à l’annonce officielle de l’intégration, les développeurs doivent utiliser la console de TypeSafe, l’API native ou les SDK officiels pour accéder à Jev. Une intégration CometAPI ne doit être considérée disponible qu’une fois que Jev apparaît dans le catalogue public de modèles avec des informations d’API vérifiées.