Jev et la nouvelle couche de décision pour les agents IA

Pourquoi les modèles System One pourraient séparer le jugement rapide du raisonnement lent

De nombreux agents IA utilisent un modèle de langage pour presque toutes leurs décisions. Le modèle de langage choisit un outil, évalue les résultats, détermine s’il doit continuer, puis génère finalement des réponses. Flexible ; cependant, ce processus peut être coûteux lorsque des décisions oui‑ou‑non sont répétées à grande échelle. Unite.AI a déjà évoqué comment les flux de travail agentiques augmentent les appels de modèle, le contexte et les tentatives. Chaque décision supplémentaire peut ajouter du temps et de l’argent avant de fournir aux utilisateurs des informations utiles.

Jev suggère de diviser la tâche différemment. Utilisez un modèle conçu pour des jugements bornés dans lequel l’ensemble des réponses est défini. Utilisez un modèle génératif pour le raisonnement ouvert et le langage. Jev indique que l’idée principale n’est pas que tous les agents doivent acquérir un nouveau produit. Le concept clé est qu’un agent n’a pas besoin du même type d’intelligence à chaque instant.

Ce que fait réellement Jev

TypeSafe a lancé Jev en septembre 2026, le premier de leurs nouveaux modèles System One. Jev ne rédige pas de texte. Au lieu de cela, vous lui envoyez un état (comme un message de support et des données utilisateur). Vous envoyez également une ou plusieurs questions qui ont des types de réponses prédéfinis. Ensuite, Jev répond avec des réponses typées et des probabilités.

Selon la documentation officielle de l’entreprise, il existe trois primitives pour prendre des jugements :

• Choice vous permet de choisir parmi des options prédéfinies.
• Score vous permet d’évaluer quelque chose selon une grille ordonnée.
• Noul estime la probabilité qu’une affirmation soit vraie.

Vous pouvez poser plusieurs questions indépendantes concernant le même état dans une seule requête.

Par exemple, supposons que vous traitiez un problème de service client. Un système pourrait vouloir déterminer quelle équipe doit prendre en charge ce cas. Il peut également déterminer la rapidité de la réponse nécessaire et vérifier si le client a demandé un remboursement.

Un modèle de chat pourrait potentiellement exécuter les trois tâches. Cependant, il devra renvoyer les résultats à votre application sous forme de réponse structurée. En revanche, Jev ne fournit que ces décisions bornées. Votre application décidera alors quelle action entreprendre ensuite en fonction de ces décisions.

Le changement d’architecture compte plus que le modèle

La plupart de ces débats comparent les grands modèles aux petits. Jev propose une frontière alternative. Certaines étapes impliquent la génération de texte. D’autres sont des jugements restreints que le logiciel peut consommer.

Cela crée une couche de décision dans l’agent. Le modèle estimera. Le logiciel appliquera la politique. Si la probabilité estimée dépasse un seuil testé et que l’action est à faible risque et réversible, le flux de travail peut se poursuivre. S’il y a incertitude dans les résultats ou si l’action pourrait avoir des conséquences graves, le système peut solliciter une supervision humaine. Un modèle de raisonnement peut aider à examiner l’incertitude, mais il ne remplace pas l’approbation humaine requise.

Figure 1. Un chemin de décision borné conserve les seuils, les autorisations et l’escalade dans le code.

Il existe des similitudes avec le routage de modèles, mais il y a une différence cruciale. RouteLLM prend des décisions sur le modèle de langage à choisir parmi deux. Il sélectionne entre un modèle plus puissant et un modèle plus faible afin d’équilibrer qualité et prix. Un modèle System One produit des jugements bornés que le code peut utiliser directement. Ces jugements peuvent soutenir le routage de modèles ainsi que d’autres décisions au sein d’un agent.

Pourquoi les boucles d’agents sont naturellement adaptées

La nature des boucles d’agents les rend particulièrement adaptées à la prise de nombreux jugements à un niveau très granulaire. Ces jugements aident à atteindre le résultat final. En d’autres termes, les agents doivent effectuer de nombreux jugements « mineurs » après qu’un utilisateur a soumis sa question ou sa requête. Ces jugements se produisent avant que la réponse ou le résultat ne soit renvoyé.

Un exemple serait de décider quels outils utiliser, classer les enregistrements récupérés et évaluer le risque. Le système détermine également si suffisamment de preuves existent et si le processus doit se poursuivre. Il est très probable que tout cela se répète. De plus, les délais entre chaque boucle peuvent s’accumuler avec le temps.

Ce rôle des boucles d’agents est illustré par intégration Jev de LangChain, où Jev peut effectuer à la fois le routage de modèles et les vérifications d’appels d’outils. Bien que Jev s’intègre autour des bords du modèle génératif, le modèle génératif lui-même continue de planifier et de générer du contenu. Cela représente un cas d’utilisation bien plus réaliste pour Jev. Il complète un modèle de langage à usage général plutôt que de le remplacer.

De plus, la parallélisation des questions modifie également la façon dont les équipes envisagent la décomposition des tâches. Plus précisément, les équipes peuvent décomposer une instruction ambiguë en plusieurs questions d’évaluation distinctes. Cela peut potentiellement entraîner une séquence d’appels de modèle beaucoup plus courte. Cela peut créer un flux de travail beaucoup plus facile à évaluer. Cela permet également aux développeurs d’utiliser une logique métier explicite pour combiner les jugements résultants.

Les modèles de langage à usage général peuvent produire des sorties structurées et pourraient être le meilleur choix dans certains cas. Par exemple, une détermination et une explication peuvent devoir être fournies ensemble. Par conséquent, Jev doit démontrer plus que la simple conformité au schéma pour être considéré comme efficace.

L’efficacité de Jev dépend de la réalisation de réductions de la latence globale du système. Elle dépend également de la production d’estimations de probabilité utiles et de la stabilité des performances face à des entrées variables. Si Jev ne parvient pas à fournir ces avantages, choisir un autre modèle n’ajoutera qu’une charge supplémentaire de développement et d’exploitation.

Typed signifie-t-il correct ?

Le langage utilisé lorsqu’on formule des affirmations sur Jev doit également être soigneusement formulé. Puisque l’espace de sortie est défini à l’avance, le modèle ne doit pas renvoyer un champ inventé ou un paragraphe incompréhensible. Cela élimine une forme d’échec ; cela n’élimine pas les erreurs sémantiques. Rien n’empêche un système de renvoyer un département incorrect, d’attribuer un niveau de risque erroné ou d’affirmer trop de certitude. Il peut faire tout cela tout en étant totalement type‑safe.

Les propres documentation de System One font une distinction importante. La calibration est mesurée sur des groupes de prédictions ; elle ne garantit pas la justesse d’une prédiction individuelle. En production, cela a des implications. Les équipes doivent vérifier si les probabilités prédites correspondent aux résultats observés sur leurs propres données.

Les preuves de performance restent préliminaires

TypeSafe indique des temps de réponse de 70 à 500 millisecondes. Il fait également référence à d’importantes économies de coûts et à des améliorations de vitesse dans ses évaluations internes de flux de travail. De plus, TypeSafe indique que ces gains annoncés se situent probablement près du maximum des gains observés dans le monde réel. TypeSafe’s tests de workflow publiquement disponibles utilisent des probabilités de référence fournies par d’autres modèles de pointe plutôt que des étiquettes de vérité terrain. Les résultats sont utiles pour formuler des hypothèses. Les résultats ne peuvent pas remplacer un test indépendant sur une charge de travail réelle.

Un test pratique avant adoption

Lorsque vous créez votre premier flux de décision alimenté par l’IA, ne choisissez pas vos décisions les plus critiques (par exemple, les approbations médicales ou les suspensions de comptes). Choisissez plutôt quelque chose de très courant, réversible et facile à examiner par d’autres membres de l’équipe. Cela comprend, sans s’y limiter, le routage des tickets, la catégorisation de documents, la sélection de modèles et l’assurance qualité à faible risque.

Quatre questions vous aideront à juger si cela fonctionnera :

• La sortie possède-t-elle un nombre fini de réponses possibles ?
• Pouvez‑vous formuler clairement les critères du jugement ?
• Existe‑t‑il des résultats mesurables ?Suivez la prédiction, sa probabilité, l’action et les résultats subséquents. Vérifiez régulièrement la calibration en comparant les probabilités prédites aux résultats observés.
• Disposez‑vous d’un plan alternatif au cas où le processus de décision automatisé échouerait ?Identifiez un moment précis où utiliser un modèle de raisonnement, demander plus d’informations ou impliquer un humain.

Votre analyse doit couvrir l’ensemble du flux de travail, y compris le processus de prise de décision. Utilisez des indicateurs tels que la précision des décisions, les taux d’abstention ou d’escalade, le temps total de traitement de bout en bout, le coût par tâche réalisée avec succès et l’impact des erreurs. Effectuez des tests dans des conditions défavorables : variations de l’usage des mots, omission de données pertinentes, catégories rares et entrées adversariales. Un classificateur optimisé qui engendre des coûts supplémentaires en aval n’est pas une optimisation.

La leçon à long terme ici

Si Jev réussit, change de façon significative ou est remplacé rapidement, une chose demeure constante. La question architecturale persiste. Est‑il nécessaire que chaque décision automatisée soit rendue sous forme de langage généré ?

Dans de nombreux cas, la réponse est « non ». Dans un environnement de production, un système utilisant des modèles génératifs peut produire des interprétations, des plans et des explications. En utilisant des modèles de décision bornés, le même système peut acheminer, évaluer et filtrer. Le code peut continuer à définir les valeurs de seuil acceptables et les autorisations. Les humains doivent rester responsables des décisions qui affectent la vie d’autrui.

Bien que cela représente une perspective moins spectaculaire que de confier à un modèle autonome l’exécution fiable de toutes les tâches, cela reflète la manière dont les systèmes fiables sont construits. La prochaine avancée de performance pour les agents pourrait dépendre de la sélection des zones du système où la réflexion prend plus de temps. D’autres zones nécessitent des décisions rapides, et certaines ne requièrent aucune action.