Pourquoi un Jev qui ne sait pas discuter convient à un Agent

Un Agent manque souvent d'un jugement qui peut entrer dans une branche, pas d'un autre tronçon de texte long. Ce texte explique les trois questions, ce que compare l'évaluation de workflow, et pourquoi un chemin chaud ne peut pas attendre un chat.

Folkbench folkbench.com

Co-auteur : folkbench.com (Folkbench est une plateforme vérifiable d’évaluation et de sélection pour les API d’IA, les services de modèles et les sites associés. Elle s’appuie sur les informations publiées sur le service, les prix, la disponibilité, la latence et les fenêtres de preuve pour aider les utilisateurs à comparer des voies et à en choisir une.)

Dix textes dans cette série :

Ce qui manque souvent à un Agent, ce n'est pas un autre tronçon de texte long. C'est un jugement qui peut entrer directement dans le flux de contrôle. Les cas usuels : est-ce que cette alerte reste fermée, est-ce que cette facture est payée, est-ce que cette trace a besoin d'une personne, et est-ce que la prochaine phrase du service client doit escalader. Ces nœuds ne sont pas là pour que le modèle écrive une analyse. Le code a besoin d'une valeur qu'il peut comparer, et sur laquelle il peut brancher. C'est cela que fait Jev.

La formulation de TypeSafe veut dire un appel de fonction d'intelligence de frontière. L'état entre. Une décision probabiliste typée sort. Il ne génère pas de chaînes. La phrase pour une personne, et le jugement pour un programme, ne sont pas la même sortie.

Fixer d'abord la sortie

La sortie des grands modèles actuels est une chaîne. Le logiciel qui doit continuer doit encore l'analyser, la valider, et se garder de la dérive. Un champ de trop apparaît. Le paragraphe a l'air complet, et l'enum ne correspond pas. Une personne, dans une boîte de chat, s'en aperçoit et redemande. Le code ne s'en aperçoit pas, et continue avec l'erreur. Enfouie à plusieurs appels de profondeur, un modèle plus intelligent ne peut pas la remettre en place.

Jev fixe l'espace de sortie d'avance. Vous dites ce qu'il a le droit de renvoyer, et il n'assigne de probabilité qu'à l'intérieur de cet espace. Une erreur de type ne peut pas arriver, mathématiquement. Il ne peut pas rendre une forme que vous n'avez pas définie. Ce n'est pas la même chose que le jugement correct. La probabilité peut pencher du mauvais côté, et l'option peut être la mauvaise. La sûreté de type ferme la forme, pas le vrai et le faux. Une fois la forme fixée, les branches d'après peuvent s'écrire. Vous n'avez pas à aller pêcher une valeur dans un paragraphe d'abord.

Il n'y a que trois questions.

Noul, c'est le oui-non. Le modèle donne une probabilité de 0 à 1. Près de 1, c'est oui. Près de 0, c'est non. Près de 0.5, il n'est pas sûr. Il n'attache pas une confiance à part. La probabilité est le signal. Choice, c'est le choix unique. Vous listez d'abord les options, avec un plafond de 255. Ce qui revient, c'est l'option choisie, la distribution sur chaque option, et une confiance. Le code se sert de cette distribution pour décider s'il agit ou s'il remet le cas à une personne. Score, ce sont les niveaux. Les niveaux vont de 2 à 10, et vous écrivez ce que chaque niveau veut dire. Ce qui revient, c'est un score, la distribution sur les niveaux, et une confiance. Le score peut se poser entre deux niveaux, comme une position sur l'échelle.

Un oui-non s'écrit comme une condition. Le choix unique et les niveaux diffèrent : le premier regarde sur quelle option il est tombé, le second pose un seuil sur le score. Une bonne question reste étroite. Un jugement qu'une personne du métier peut faire en une seconde après avoir lu le matériau, c'est le genre à lui donner. Savoir si le client demande un remboursement, c'est ce genre de question. Lire toute la lettre, puis décider de la meilleure action, ce n'est pas cela. La seconde phrase veut un raisonnement lent. Découpez, puis demandez. Les questions découpées font face au même état, indépendantes les unes des autres, et reviennent ensemble dans une seule requête. Les poids restent dans le code. Quand la politique change, vous changez les nombres. Vous ne réécrivez pas tout le prompt.

Ce qui bloque, c'est la bifurcation

Ce qui bloque vraiment les gens, c'est souvent un nœud de cette forme. Une alerte arrive avec des enregistrements que la machine a déjà, et la conclusion est de la fermer, de l'envoyer à un analyste, ou d'isoler tout de suite. Une facture est suspendue à une commande et à un bon de livraison, et quelqu'un doit décider de payer, de retenir, ou de la renvoyer. Un Agent de service client a fini, les appels d'outils sont tous dans la trace, et quelqu'un doit décider si cette trace est regardée, et dans quel délai. Le client réécrit, et le fil comme l'état du compte sont là. Comment la phrase suivante doit continuer, et si elle doit escalader, c'est la même forme de question.

La partie que les règles peuvent figer, c'est du code. Ce qui est fragile, ce sont les exceptions qu'on ne peut pas finir. Le reçu correspond, le motif est vague, et un pas de la trace a l'air étrange. La logique écrite à la main se brise là-dessus. Vous fourrez toute la politique dans un seul prompt et vous laissez le modèle y réfléchir une fois, et vous écrivez moins de conditions. La sortie redevient un morceau de texte. Pour que le texte entre dans le flux de contrôle, vous écrivez une autre couche d'analyse. Cette couche peut se tromper toute seule.

Le workflow eval de TypeSafe mesure cette façon de relier. L'évaluation découpe une tâche en beaucoup de questions étroites. Ce que le code peut trancher, le code le tranche. Le modèle ne répond qu'aux jugements que le code ne peut pas régler. Les quatre flux publics sont un incident de sécurité, l'observabilité des traces d'Agent, le traitement des factures, et le service client. Sous le même flux, un modèle sur le workflow est plus exact que si l'on fourre toute la politique dans un seul prompt, et il coûte moins, et prend moins de temps. En moyenne sur les quatre tâches, les modèles sous test vont dans ce sens.

Les actions d'après suivent la probabilité, pas une étiquette qu'on a claquée fermée. Le résultat qui quitte le système est encore une action discrète. L'ingénierie du milieu doit se faire de la même façon à chaque fois.

L'évaluation mesure la proximité

Cette évaluation ne débat pas avec vous pour savoir si le flux lui-même a été mal écrit. Elle suppose que le harnais est juste. La réponse de référence n'est pas une étiquette or posée à la main, question par question. GPT-6 Astra et Claude Fable 5.1 répondent à chaque question en high thinking, et les deux réponses sont moyennées. Les autres modèles utilisent le raisonnement par défaut du fournisseur. Ce n'est qu'une fois le flux fixé qu'on peut les comparer. L'évaluation compare à quel point un modèle se rapproche des jugements de ces deux grands modèles, plus la vitesse et le coût.

Donc le graphique ne prouve pas que Jev comprend le métier mieux qu'Astra. Astra et Fable sont ici le mètre. Jev doit se rapprocher de leurs jugements, et il doit aussi ouvrir un écart sur la latence et le coût. Si les questions ont été mal découpées, un mètre plus proche ne sert à rien. Découper les questions, c'est le travail de la personne qui écrit le flux.

Jev se tient loin sur la frontière du « vite et bon marché ». Les multiples plus hauts du site officiel, environ 193.6 fois plus vite et 444.6 fois moins cher, sont le haut de cette évaluation. Ce multiple n'est pas chaque appel. Les appels ici sont plus proches de la charge d'automatisation que vous mettriez vraiment en service.

Ce dont il se rapproche, c'est la probabilité sur ces questions étroites après le découpage, pas l'écriture d'une longue analyse. Jev n'écrit pas cette longue analyse.

Un chemin chaud ne peut pas attendre

La latence est dure pour un Agent. Une personne peut encore attendre trois secondes. Une fois que les couches s'enveloppent, elle ne le peut plus. La même chaîne a aussi une recherche, une écriture en base, et l'appel suivant, et chaque saut dépense le même temps. Entre 70 et 500 millisecondes, un jugement peut se poser sur un chemin chaud. Hors de cet intervalle, la pile d'appels le traite comme un blocage.

Pour parler à une personne, les modèles de frontière actuels prennent couramment de 3 secondes à plus de 300 secondes, de bout en bout. Cette vitesse a du sens pour un copilote, ou pour un Agent de code qu'une personne surveille. Comme condition sur un chemin chaud, cette vitesse n'en a pas. Jev n'émet pas une phrase token par token. Les probabilités qui doivent revenir arrivent ensemble. La vitesse vient de là.

TypeSafe se sert aussi de Jev pour vérifier. Les prompts, les traces de raisonnement, et les sorties d'autres modèles, Jev les note, et il sert aussi de garde-fou et cherche les jailbreaks. La génération reste au modèle de chat. Savoir si cette porte est passée, c'est un modèle qui ne génère pas de chaînes qui le décide. C'est une articulation dans un Agent, pas du chat. Si le signe de tête et la revue restent sur du texte long, il vous faut un autre programme pour le lire. Jev referme le résultat en probabilités et en niveaux, et la revue peut s'écrire en code.

La phrase écrite pour l'utilisateur reste le travail du modèle de chat. Jev ne prend pas cette phrase. Il prend le routage devant, et la vérification derrière. Ce qui manque ici à un Agent, ce n'est pas une explication de plus, plus longue. C'est un jugement dont le type est déjà fixé, pour que le code puisse avancer avec lui.

Sources

Série