jev-latest

Jev est le modèle phare de TypeSafe et le premier modèle de la nouvelle classe System One. Il ne rédige pas de texte, mais prend rapidement des décisions qu’un programme peut utiliser directement : vous fournissez un état (state) — du texte ou du JSON — et un ensemble de questions, et recevez des valeurs typées avec des probabilités calibrées.

Les modèles de langage écrivent des mots pour les humains ; selon TypeSafe, Jev est plus proche du code : la réponse a immédiatement la forme requise par le code, avec une grande vitesse et aucune valeur en dehors des options définies. Le modèle est conçu pour donner des réponses stables aux requêtes répétées.

En quoi System One diffère d’un modèle de langage

• Il ne génère pas. Jev ne rédige pas de réponses à l’utilisateur, n’écrit pas de code et n’explique pas son raisonnement. Vous définissez les réponses possibles au moyen de l’un des trois types de questions.
• Il est entraîné à prendre des décisions calibrées. TypeSafe entraîne le modèle par RLCD (Reinforcement Learning for Calibrated Decisions) : les probabilités sont ajustées aux résultats réels et reflètent l’incertitude. Sur un grand nombre de réponses avec une probabilité de 0,8, environ 80% devraient être correctes. La calibration est une propriété d’un grand échantillon, et non une garantie d’exactitude d’une réponse particulière.
• L’objectif d’entraînement est différent. Les modèles de chat sont entraînés à plaire aux humains (RLHF), ce qui, selon les observations de TypeSafe, encourage la complaisance et les erreurs formulées avec assurance. L’un des coauteurs du RLHF, Diogo Almeida, est cofondateur de TypeSafe.

Le nom fait référence au « Système 1 » du livre de Daniel Kahneman « Les deux vitesses de la pensée » : le jugement intuitif rapide s’oppose à la réflexion lente et délibérée du « Système 2 ». Jev est conçu pour les jugements rapides et ciblés.

Trois types de questions

Une question est un jugement sur l’état ; la réponse est une valeur que le code compare à un seuil, trie ou transmet à la suite du processus.

1. Choice — choisir une option. Le service auquel adresser une demande, la catégorie d’un produit, le langage d’un fragment de code. Les options forment un dictionnaire « option → description », avec jusqu’à 255 entrées. La réponse comprend le choice sélectionné, les probabilities de toutes les options (dont la somme est 1) et la confiance confidence. Si la liste risque de ne pas couvrir tous les cas, ajoutez « autre » ou « aucune des options ».
2. Score — noter sur une échelle. La position sur une échelle ordonnée que vous décrivez : gravité d’une erreur, irritation du client, niveau de compétence. De 2 à 10 niveaux, du plus faible au plus élevé ; le modèle évalue chaque niveau séparément, sans voir son numéro ni ses voisins. La réponse comprend le score (la somme des numéros des niveaux multipliés par leurs probabilités, ce qui peut donner une valeur entre les niveaux), la legend décrivant les niveaux, les probabilities et la confidence.
3. Noul — oui ou non. L’affirmation est-elle vraie ? La réponse noul est la probabilité du « oui », de 0 à 1 : près de 1, un « oui » assuré ; près de 0, un « non » assuré ; près de 0,5, le modèle hésite. Il n’y a pas de confidence distincte : un seul nombre décrit entièrement la réponse. Le paramètre facultatif criteria précise ce qu’il faut considérer comme « oui » ou « non ».

Comment choisir : des options connues sans ordre — choice ; des degrés sur un spectre — score ; un simple « oui/non » où la probabilité elle-même compte — noul. Noul 0,5 signifie des chances égales de « oui » et de « non », et non un « niveau moyen » : le degré se mesure avec score. Entre deux types adaptés, choisissez celui sur lequel le code agit directement : choice pour les branches, score pour le seuil, noul pour if.

Les types peuvent être mélangés dans une même requête. La réponse est toujours limitée à vos options et ne dépend pas des autres questions : les questions peuvent être ajoutées ou retirées sans modifier les autres réponses.

L’état

L’état est ce que le modèle évalue : un message client, un segment de document, une entrée de base de données ou l’état de votre application.

• Chaîne — lorsqu’il n’y a qu’un texte : message, article, extrait.
• Objet — champs nommés, entrées liées, état de l’application. TypeSafe recommande un objet pour la plupart des requêtes : chaque partie porte un nom clair.
• Tableau — une séquence de messages ou d’entrées.

Préparez-le comme des documents destinés à des experts : réunissez les échanges, la commande et les conditions de retour si la décision nécessite de les comparer. Placez le contenu dans l’état et les jugements dans les questions. Si une question concerne une partie de l’état, indiquez-y le chemin entre accents graves, par exemple ticket.messages[0].text.

Comment poser les questions

• Un jugement rapide par question. Une bonne question est celle à laquelle une personne compétente disposant du contexte nécessaire répondrait en une seconde : « Le message exprime-t-il une urgence ? ». « Analyse le message et décide quoi faire » relève déjà d’un raisonnement lent et doit être décomposé en questions simples.
• La question entière dans instructions. La clé de la question, par exemple refund_requested, sert uniquement à votre code et n’est pas transmise au modèle.
• Toutes les questions sur un même état dans une seule requête. Le modèle les évalue en parallèle : selon TypeSafe, les questions supplémentaires augmentent très peu le temps de réponse et ne coûtent que leurs propres tokens. Une question posée « au cas où » coûte presque rien ; le code décidera lui-même des réponses à utiliser.
• Un jugement complexe en plusieurs parties. Au lieu d’« évalue la candidature de la start-up », posez des questions distinctes sur la taille du marché, la faisabilité technique et les différences avec les concurrents, puis calculez le résultat dans le code avec des poids. Si les priorités changent, modifiez les poids plutôt que de réécrire la question.
• Les questions dépendantes dans une deuxième requête. Les réponses d’une même requête ne servent pas de contexte les unes aux autres. Une deuxième requête n’est nécessaire que si elle ne peut pas être construite sans la première réponse : il faut charger des données ou choisir les options de la question suivante.
• Une question longue sous forme d’objet. instructions et criteria sont généralement des chaînes, mais peuvent être un objet ou un tableau : la question dans un champ, les données dans les autres. Cela permet de comparer un CV aux entrées d’une base avec une seule question.

La confiance

Pour choice et score, confidence, de 0 à 1, indique à quel point la probabilité est concentrée sur une réponse : 1 signifie qu’elle est entièrement concentrée sur une option, 0 qu’elle est répartie également entre toutes. Pour score, un niveau voisin réduit moins la confiance qu’un niveau éloigné. Pour noul, la confiance est la valeur elle-même : plus elle s’éloigne de 0,5, plus la réponse est ferme.

TypeSafe recommande trois plages :

1. Confiance élevée — agir automatiquement.
2. Confiance moyenne — agir avec prudence, par exemple demander une confirmation à l’utilisateur.
3. Confiance faible — confier le cas à une personne, préciser la requête ou utiliser une solution de repli, par exemple un modèle plus puissant avec raisonnement.

Plus une erreur coûte cher, plus le seuil doit être strict : plus élevé pour les actions irréversibles que pour la lecture. La réponse indique quoi choisir, et la confiance s’il faut agir. Ajustez les seuils sur vos propres données, en comparant la confiance à la précision.

Comment construire un système autour de Jev

Jev vise les programmes où le code pilote le processus et où le modèle répond à des questions sémantiques ciblées, plutôt que les agents qui choisissent eux-mêmes l’étape suivante et peuvent dévier à chaque cycle. Les huit étapes de conception selon TypeSafe :

1. Faites en code tout ce qui peut l’être, de façon fiable et peu coûteuse.
2. Ne placez dans l’état que ce dont les questions actuelles ont besoin ; tirez les faits récents de votre base de connaissances, et non de la mémoire du modèle.
3. Structurez l’état avec du JSON imbriqué et indiquez dans la question le chemin vers le champ nécessaire entre accents graves si cela réduit l’ambiguïté.
4. Posez les questions les plus ciblées et les plus concrètes possible : selon TypeSafe, c’est peut-être la règle principale ; une question large cache plusieurs jugements derrière une seule réponse.
5. Structurez les questions : gardez la question elle-même courte ; placez les explications, les exemples et les valeurs de votre base dans des champs voisins de l’objet instructions ou criteria, plutôt que dans une longue chaîne unique.
6. Posez de nombreuses questions indépendantes sur un même état dans une seule requête pour obtenir davantage de valeur par dollar.
7. Le code combine les réponses : avec des règles, une somme pondérée ou comme caractéristiques d’un modèle classique d’apprentissage automatique.
8. Créez des branches selon la confiance : les cas incertains vont à une personne ou à un modèle avec raisonnement.

Jev n’est ni un chat ni un modèle de complétion de code ; il ne peut pas remplacer un modèle de langage dans un agent de programmation. En revanche, un agent peut écrire pour vous du code qui appelle Jev lorsqu’une réponse rapide et calibrée est nécessaire.

Les usages

• Automatisation en arrière-plan — des décisions exécutées un million de fois sans présence humaine.
• Temps réel — selon TypeSafe, la plupart des requêtes prennent environ 100 ms : assez pour le traitement à la volée et les interfaces.
• Données massives — recherche dans d’immenses corpus, annotation des journaux de travail des agents, caractéristiques pour les prévisions.
• Vérification d’autres modèles — requêtes, extractions, raisonnements et appels d’outils : contournements des limites, erreurs de citation, inventions.
• Recherche et classement — pertinence d’une paire « requête — candidat », reclassement, sélection du contexte.
• Orientation selon l’intention — ce que souhaite l’utilisateur et le traitement nécessaire : logique simple, modèle spécialisé ou personne ; le sujet, la difficulté et le risque déterminent le modèle de langage auquel confier la requête.
• Vérifications de protection — entrées, sorties et appels d’outils du modèle de langage : instructions injectées, violations des règles, fuites de données personnelles.
• Support — sujet et intention de la demande, urgence, irritation, risque de départ, demande de retour, file d’attente.
• Modération — selon les règles de votre plateforme : toxicité, harcèlement, spam, fraude, conseils dangereux, données personnelles ; selon la gravité et la confiance, autoriser, avertir, vérifier ou bloquer.
• Secteurs — sinistres, enquêtes financières et KYC, contrats et publicité, fiches produits, recrutement, prospects, jeux, risques, prévision de la demande, graphes de connaissances, revues scientifiques, vérifications sémantiques du code en CI.

Les caractéristiques

• jev-latest — alias de la dernière version stable, actuellement Jev 1.13 ; la version ayant répondu figure dans le champ model, par exemple jev-1.13.0. Avec une nouvelle version, l’alias pointe vers elle, et les réponses peuvent changer sans modification de votre part : surveillez ce champ si vos seuils sont ajustés à une version.
• Contexte — 64K tokens par requête : l’état et toutes les questions réunis ; l’état avec la question la plus longue, jusqu’à 32K. Le modèle lit l’état une fois et évalue toutes les questions en parallèle par rapport à lui.
• Entrée — uniquement du texte : une chaîne, un objet JSON ou un tableau de textes. Les images, l’audio et la vidéo ne sont pas encore pris en charge ; transformez-les d’abord en texte.
• Langue — la langue principale de l’entraînement est l’anglais, et la précision y est actuellement la plus élevée. Le modèle accepte d’autres langues, dont le chinois, le japonais et le coréen, mais avec une précision moindre : vérifiez sur vos propres données.
• Tarifs et facturation dans Ailoot API — les conditions dépendent de la méthode choisie et sont indiquées dans sa fiche.
• Personnalisation — Jev n’est pas affiné sur les données du client : vos contenus vont dans state, et les règles du domaine dans instructions et criteria.
• Données — TypeSafe indique que Jev n’est pas entraîné sur les requêtes et les réponses des clients.

Les faiblesses connues de Jev 1.13

TypeSafe énumère ouvertement les faiblesses de la version actuelle et promet d’en corriger beaucoup dans les suivantes. Le modèle est rapide, calibré et exerce un bon jugement de bon sens, mais :

1. Il lit littéralement. Il répond à la question écrite, et non à celle sous-entendue : réserves, négations et conditions implicites sont comprises littéralement. Écrivez la condition précise et les cas limites dans criteria ; décomposez une interprétation inévitable en deux questions littérales.
2. Ce n’est pas une calculatrice. Le comptage des caractères, des répétitions et des éléments d’une liste n’est pas fiable, et l’erreur augmente avec la taille : comptez dans le code, avec une question par candidat. Le modèle comprend moins bien les couleurs en hex ou RGB que leurs noms. score convient à un seuil, mais pas à un nombre exact entre les niveaux.
3. Dates et heures. Déterminer quelle date précède une autre, l’intervalle entre elles ou l’appartenance d’une date à une période n’est pas fiable, surtout avec des formats mélangés et des dates relatives. Extrayez les parties de la date avec choice (avec une option « non indiqué »), et comparez-les dans le code.
4. Formulations indirectes. Les doubles négations et les questions sur la propriété d’une propriété réduisent la précision. Écrivez directement et nommez les parties de l’état.
5. Contenu superflu dans l’état. Les textes étrangers à la tâche réduisent la précision. Filtrez dans le code ou, si ce n’est pas possible, écartez le contenu non pertinent par des questions noul.
6. Texte hostile. Le modèle ne s’attend pas par défaut à des pièges dans l’état : une instruction injectée ou un texte contestant sa propre classification peut déplacer la réponse. Écrivez des critères précis et vérifiez les cas limites avant le lancement.
7. Contradictions. Si instructions et criteria demandent des choses différentes — par exemple si, pour noul, « oui » est décrit comme « non » — la précision baisse. Les critères prolongent la question.
8. Ordre des options. Le modèle penche parfois vers la première option choice. Réordonnez les options et vérifiez que la réponse ne change pas.
9. Génération. Jev n’est pas entraîné à écrire du texte. Pour extraire des données, trouvez les candidats avec une expression régulière ou un modèle génératif, puis laissez Jev choisir le bon avec choice.