Veille IA

llmagentsevaluation

Jev (TypeSafe AI) et ses tentatives de réimplémentations open source

TypeSafe AI a sorti Jev, un modèle qui ne génère pas de texte mais des décisions typées avec probabilités. En 72 h, la communauté en a reproduit l'interface avec des modèles ouverts ; une rétro-ingénierie de l'API, un modèle ouvert (Laya) et une réplique fidèle (kev) ont suivi. Ce que personne n'a démontré : la calibration hors distribution.

Jev a été annoncé le 15-16 septembre 2026 : tout ce qui suit a moins d'une semaine, les chiffres et l'état des dépôts bougent vite.

En bref

  • TypeSafe AI a sorti Jev, un modèle qui ne génère pas de texte : il renvoie des décisions typées avec probabilités (choix, score, booléen), consommables directement par du code.
  • L'API est fermée, hébergée aux US, sur liste d'attente. Aucun poids ouvert.
  • En 72 h, la communauté a reproduit l'interface avec des modèles ouverts de 2 à 4 milliards de paramètres, en local (GPU grand public ou Mac).
  • Un premier modèle ouvert entraîné de bout en bout pour cet usage vient de sortir : Laya (421 M de paramètres, Apache 2.0). Prometteur sur l'architecture, mais ses benchmarks « supérieurs à Jev » ne sont pas comparables et il est limité à l'anglais.
  • Une rétro-ingénierie par sondage de l'API (Archer Hume, ~10 000 appels) donne désormais un plan d'architecture crédible : état encodé une fois, questions en branches isolées, lecture directe des probabilités. kev (Jared Palmer) l'implémente sur un modèle de 0,5 Md de paramètres, entraînable sur un MacBook, compatible avec le SDK officiel.
  • Les premiers retours indépendants sur la calibration de Jev sont mitigés : bons sur benchmark académique, décevants sur des tâches de production réelles. À valider localement avant toute automatisation.
  • Ce que personne n'a reproduit de façon démontrée : la calibration des probabilités et la qualité de jugement sur les cas subtils. C'est là qu'est la vraie valeur de Jev.
  • Pour un domaine étroit avec des données étiquetées, un petit modèle spécialisé fait le travail en quelques millisecondes.

1. Le concept : un modèle « System One »

Le problème visé

Une grande partie des appels LLM en production ne sont pas de la génération, ce sont des micro-décisions : router un ticket, classer un contenu, vérifier qu'une preuve soutient une affirmation, choisir la prochaine action d'un agent. Avec un LLM classique, on demande du texte (souvent du JSON), on attend le décodage token par token, puis on re-parse ce texte pour alimenter un if. C'est lent, coûteux, et fragile (JSON invalide, verbosité, réponses hors cadre).

La proposition de TypeSafe

TypeSafe AI a été fondée par Diogo Almeida, ancien chercheur d'OpenAI et co-inventeur du RLHF et de ChatGPT, avec 40 M$ de financement. Leur thèse : si l'IA doit transformer le travail, les humains ne peuvent pas être les seuls consommateurs d'intelligence, il faut des modèles conçus pour être appelés par des programmes.

Jev prend en entrée un état non structuré (texte, objet ou tableau JSON) et un ensemble de questions typées, et renvoie des valeurs typées en une seule passe parallèle. Il ne peut ni écrire, ni coder, ni s'expliquer.

Les trois primitives

Primitive Entrée Sortie
Choice Alternatives déclarées (jusqu'à 255), chacune avec une description Option retenue, distribution de probabilités, confiance
Score Niveaux ordonnés décrits en clair Score continu (moyenne pondérée), distribution par niveau, confiance
Noul Proposition binaire Probabilité que la proposition soit vraie

Plusieurs questions se combinent dans une même requête sur le même état, et sont évaluées en parallèle et en isolation. Exemple type sur un ticket de support : « quel service ? » (Choice), « quel niveau de frustration ? » (Score), « demande-t-il un remboursement ? » (Noul). Le modèle fournit le jugement sémantique, le code applique la règle métier.

L'entraînement : RLCD

TypeSafe annonce une méthode maison, Reinforcement Learning for Calibrated Decisions. L'objectif : que la confiance renvoyée soit réellement corrélée à la justesse. Une probabilité calibrée permet de poser des seuils fiables (au-dessus on automatise, en dessous on escalade vers un LLM ou un humain). Aucun détail d'implémentation n'a été publié.

Architecture reconstituée par rétro-ingénierie

Source : Jev's Architecture Unmasked (Archer Hume, 17 septembre 2026), avec jeux de données des sondes publiés. TypeSafe n'a rien confirmé : l'auteur distingue soigneusement ce qui est publié, observé et inféré.

Élément Niveau de preuve Observation clé
Lecture directe de probabilités, pas de décodage Publié + observé Le champ output_tokens est un chiffre de facturation calculé sur la réponse sérialisée ; une question à 200 options répond aussi vite qu'une à 2.
État partagé, questions isolées Observé Un « secret » placé dans une question voisine est invisible (p = 0,00) ; placé dans l'état, il est trouvé (p ≈ 0,9). La limite de requête compte l'état une seule fois.
État calculé une fois (cache KV de préfixe) Inféré Temps serveur quasi constant jusqu'à ~100 questions ; 1 500 questions en quelques centaines de ms ; 30 000 tokens d'état en ~200 ms.
Transformer causal (décodeur), pas un encodeur Inféré 84,6 % sur MMLU-Pro suppose un pré-entraînement de classe frontière, et TypeSafe décrit RLCD comme un post-entraînement de modèle de langage.
Options lues ensemble avant la décision (listwise) Observé Ajouter une option hors sujet modifie le rapport de probabilités entre deux options existantes, ce qu'un score indépendant par option ne permettrait pas.
Délimiteurs d'options non falsifiables Observé De fausses options injectées dans le texte ne déplacent jamais les vraies.
Mixture-of-experts creux Spéculatif Déduit du débit ; rien d'autre n'en dépend.

Trois enseignements pratiques :

  • Sensibilité à l'ordre des options, y compris chez Jev. Inverser l'ordre fait passer une probabilité de ~0,85 à ~0,95 sur un cas banal. Avec un seuil à 0,9, l'action change à données identiques. Les tests de permutation doivent faire partie de toute évaluation.
  • Calibration réelle mais inégale. ECE de 0,031 sur 1 200 items MMLU ; bonne tenue sur des problèmes de maths générés ; mais une famille (exponentiation modulaire) juste à 56 % pour une probabilité moyenne de 35 %.
  • Des mesures indépendantes moins flatteuses circulent sur X (non vérifiées par nos soins, relevées dans le rapport Scoble cité en sources) : un ECE de 0,144 sur une évaluation (@latent_node), et un test de 16 000 décisions sur huit tâches réelles concluant que Jev est rapide et bon marché mais pas prêt pour cette production (@chrismdp). L'écart avec le 0,031 mesuré sur MMLU illustre le point central : une calibration sur benchmark ne préjuge pas d'une calibration sur nos données.
  • Le champ confidence n'est pas appris. C'est une formule arithmétique sur la distribution, (p_max − 1/K) / (1 − 1/K), visible dans l'adaptateur Python officiel. Une distribution concentrée peut être fausse avec assurance.

L'auteur note aussi qu'un objectif naturel pour ce type d'entraînement est une simple perte logarithmique ou de Brier (règles de score propres) : rien n'établit que RLCD soit du renforcement au sens algorithmique strict.

Chiffres annoncés (par TypeSafe, non vérifiés indépendamment)

  • Latence de 70 à 500 ms
  • Jusqu'à ~190× plus rapide qu'un LLM frontière sur des workflows multi-étapes
  • 0,042 $ par million de tokens en entrée, sortie non facturée
  • Démos : un bot Doom à 10 décisions/s, du wikiracing

Limites et critiques

  • Tous les benchmarks viennent de l'éditeur.
  • Critique récurrente (Sean Goedecke, fil Hacker News) : sur le fond, ce n'est pas très éloigné d'un LLM avec sortie structurée et lecture des logprobs ; la vraie nouveauté est la qualité de l'interface et, si elle se confirme, la calibration.
  • API fermée, hébergement US, liste d'attente : incompatible avec une exigence de souveraineté des données.
  • « Ne peut pas halluciner » signifie seulement que Jev ne peut pas renvoyer une réponse hors schéma. Il peut toujours se tromper, et TypeSafe reconnaît dans son billet de lancement que son chiffre de 0 % n'est pas une mesure empirique (voir l'analyse de ModemGuides).

Liens du projet d'origine

2. L'écosystème autour de l'API officielle

La majorité des dépôts « jev-* » sont des clients de l'API TypeSafe, pas des alternatives. Ils sont utiles pour repérer les patterns d'usage :

  • Routage de modèles : Jev choisit quel LLM sert chaque requête (jev-router, pi-jev-router, jcm-router).
  • Garde-fous d'agents : vérification de chaque appel d'outil avant exécution, détection d'injection de prompt (jev-guard, pi-jev).
  • Agents navigateur : browser-use/jev-ultrafast. Le DOM est aplati en éléments numérotés, Jev choisit l'opération et la cible en un aller-retour, un petit LLM n'intervient que pour saisir du texte. La sortie du modèle n'est jamais qu'un index vers un élément déjà observé, ce qui ferme la porte à l'exécution de contenu injecté.
  • Intégrations : serveurs MCP, clients Python, Scala, Laravel, et Vercel qui l'intègre comme modèle d'évaluation par défaut dans eve.
  • Domotique : HA-Jev, intégration Home Assistant qui transforme des questions typées sur l'état des entités en capteurs et en actions, avec budget de tokens. Son auteur précise que, les réponses n'étant pas expliquées, ce n'est pas adapté à des décisions de sécurité.
  • SDK : Rust (s1-rs, couche derive avec seuils de confiance), RubyLLM, et quatre SDK Elixir sortis le même jour.

Distribution : où Jev est déjà branché

L'adoption côté plateformes a été très rapide, ce qui abaisse le coût d'un essai :

Couche Intégrations annoncées
Accès au modèle OpenRouter (bêta), Vercel AI Gateway, Cloudflare
Orchestration d'agents LangChain
Typage applicatif Pydantic AI (le output_type existant devient la question, avec une confiance par champ)
Workflows visuels Dify (nœud Question Classifier)
Multi-langages AX (TypeScript, Python, Go, Rust, Java, C++)

OpenRouter relaie les chiffres de l'éditeur : jusqu'à 190× plus rapide et 440× moins cher que les alternatives comparées. Ce sont des affirmations de l'éditeur et de ses partenaires.

Cas d'usage démontrés la première semaine

Démonstrations publiées sur X (non vérifiées individuellement). Leur cohérence est le meilleur argument en faveur de la catégorie : à chaque fois un état connu, une question bornée, une décision consommable par du code.

Cas d'usage Exemple Point d'attention
Classification documentaire en masse 1 018 articles de recherche classés pour 0,08 $, latence médiane 256 ms Taxonomies qui dérivent, documents multi-classes
Vérification de preuves Étiquette soutient / contredit / hors sujet entre la recherche documentaire et la génération Implication subtile, contexte temporel, jargon métier
Routage d'agents et de compétences Choix du skill ou du sous-agent, LLM-as-judge Outils qui se recouvrent, descriptions périmées
Classement et reranking Résultats de recherche, flux, passages récupérés Les critères de classement encodent des valeurs
Rapprochement de schémas Mapping de champs entre un gabarit et une source client (Bannerbear) Champs homonymes aux unités ou sémantiques différentes
Tableur prédictif Chaque ligne scorée en ~100 ms selon l'intitulé de colonne Scores probabilistes lus comme des faits
Lanceur de commandes prédictif Actions classées avant la fin de la saisie Distraction, fuite de contexte sensible
Sélection d'action navigateur Jev Browser, recherche Google Flights en 7,1 s Choisir parmi des actions fournies n'est pas du computer use ouvert ; tenue sur longues séquences non démontrée
Coordination de simulation Restaurant virtuel, affectation de tâches Choix localement plausibles, comportement global instable
Boucle de trading à 300 ms Achat / vente sur carnet d'ordres on-chain Fenêtre de contrôle humain réduite à néant : plafonds, coupe-circuits, journalisation rejouable obligatoires
Tri de documents fiscaux Classification en aval d'un pipeline d'ingestion LLM Exceptions juridiques, coût d'une erreur de classement

Schéma d'architecture qui se dégage : le code contraint, le modèle de décision juge, le LLM délibère, l'humain gouverne. Code déterministe pour les permissions, budgets et règles ; modèle de décision pour le flux courant ; LLM frontière pour les cas nouveaux ou ambigus ; revue humaine pour les cas à fort enjeu ou faible confiance.

Listes de référence : AbdelStark/awesome-typesafe (la plus structurée), yibie/awesome-jev et AnotiaWang/awesome-jev.

3. Les réimplémentations open source

Cinq approches techniques, par ordre d'effort croissant.

3.1 Lecture des logits sur un LLM gelé (aucun entraînement)

Principe : on présente l'état, la question et les options, puis au lieu de générer une réponse on lit directement les logits des tokens d'option et on applique un softmax. Un seul forward, zéro token généré. C'est la technique des harness d'évaluation type QCM, appliquée en production.

Projet Modèle / cible Points notables
TheoLeeCJ/openjev Qwen3.5-4B, RTX 3090 Le plus rigoureux sur la méthode : fixtures, résultats bruts et limites publiés. Démo WebGPU sur https://openjev.com.
kvnloo/openjev Fork du précédent Ajoute la tête entraînable de jevlike quand le zero-shot ne suffit pas.
lukevs/jev-at-home Qwen3-4B-Instruct, Mac (MPS) N questions en un forward batché, labels mono-token. ~195 ms. Précise que les probabilités ne sont pas calibrées.
daseinlabs/open-jev Gemma 3 4B, MLX (Apple silicon) Endpoint POST /v1/systemone compatible avec le contrat TypeSafe. ~90 ms par requête.
PocketJev Qwen3-VL, iPhone (MLX) Décisions visuelles embarquées. Non examiné en détail.

Mesures d'openjev (mêmes 21 critères binaires, même état, une RTX 3090) :

Chemin Temps Tokens générés
Lecture directe des logits 1,02 s 0
Génération d'un tableau JSON compact 5,33 s 111

Avec réutilisation du préfixe (KV cache de l'état partagé) et suffixes en parallèle, le débit passe de 2,3 à 20 décisions/s. Sur le sous-ensemble aligné des évaluations publiques de TypeSafe (102 lignes sur 711), l'accord modal est de 0,845 contre 0,883 publié pour Jev. Sur WANLI (inférence en langage naturel), la précision équilibrée tombe à 0,637.

À noter aussi, l'issue #1 de kvnloo/z0int, cahier des charges d'un « juge local » conforme System One (Qwen3-0.6B en test, Qwen3.5-4B en runtime). Deux principes à retenir : ne pas chercher à reproduire RLCD mais l'API et la lecture des logits ; ne pas basculer sur le local tant que la calibration n'est pas prouvée sur un jeu étiqueté figé, avec repli automatique vers l'API ou un juge LLM en cas de panne.

La comparaison de daseinlabs sur l'exemple de la documentation TypeSafe illustre bien la limite du zero-shot :

Réponse Jev (doc officielle) Gemma 3 4B zero-shot
Service (Choice) technique, p = 0,84 technique, p = 1,00
Frustration (Score) 1,04 (agacé mais poli) 2,00 (furieux)
Urgent ? (Noul) 0,999 0,005

Même décision de routage, mais sur-confiance et désaccord sur les deux jugements fins.

3.2 Petite tête entraînée sur un encodeur

  • vinnylarouge/jevlike : le projet fondateur de cette branche. Chaque option devient un vecteur requête qui pondère par attention les tokens du contexte ; un produit scalaire donne un score par paire, puis softmax sur les options. Encodeur d'octets appris from scratch par défaut, ou encodeur Hugging Face gelé. Démos Doom, échecs (vision) et Wikispeedia.
  • Sur tâche synthétique, la tête minuscule atteint 0,998 en top-1 en moins de 10 ms, contre ~86 ms pour Gemma 4B en zero-shot.
  • Un retour sur X indique qu'un simple MLP posé sur Qwen 4B reproduit déjà un comportement comparable.

3.3 Fine-tuning complet orienté calibration

  • Mapika/decider : le plus abouti techniquement, et le plus proche de l'esprit RLCD.
    • Base Qwen3.5-2B, un slot de réponse par question, logits restreints aux lettres d'option, toutes les décisions en un forward.
    • Entraînement en cross-entropie (règle de score propre) sur ~60 jeux de données publics de décision, température ajustée a posteriori.
    • Évaluation sur 16 tâches jamais vues à l'entraînement, avec métriques de calibration (ECE, Brier, AURC). ECE hors distribution d'environ 0,07.
    • Performance sur un GH200 : 4 ms par requête, ~1 670 décisions/s en batch 32 (CUDA graphs, torch.compile, FP8).
    • Démo Mario instructive : en zero-shot le modèle échoue au premier obstacle ; 5 minutes de fine-tune sur 6 000 états étiquetés suffisent à égaler la politique de référence, y compris sur des niveaux jamais vus.
    • Poids annoncés sur Hugging Face (Mapika/decider-2b).
  • Parallel Constrained Decoding (Qwen2.5-1B-RLCD) : tentative de reproduction de RLCD sur un modèle 1B. Non examiné en détail, à surveiller.

3.4 Encodeur bidirectionnel entraîné de bout en bout : Laya

Annoncé le 18 septembre sur r/LocalLLaMA par un auteur indépendant (Convai Innovations) qui dit avoir construit cette architecture un an avant Jev. C'est la première tentative publique de modèle conçu pour la décision typée, et non un LLM détourné.

Architecture. ModernBERT-large (395 M, encodeur bidirectionnel, entièrement fine-tuné) plus une tête de décision entraînée from scratch (2 couches Transformer, un scoreur de marqueurs d'option, une tête « agir / escalader »), 421 M de paramètres au total. Chaque option est scorée sur son propre token [MASK], puis softmax par question. Mêmes primitives et même forme de requête que Jev (choice, score, noul).

Entraînement. Un « RLCD non officiel » : la politique émet une distribution, l'exploration ajoute un bruit gaussien aux logits, et la récompense est une règle de score strictement propre (score logarithmique + sphérique, plus ranked probability score pour les questions ordinales). Plus de 25 000 exemples annotés par des humains, sans données synthétiques, sur routage d'intention, vérification de faits, modération, garde-fous de prompt, notation par barème et trajectoires de conversation. Une seule époque, environ 2 heures sur une RTX 6000 Pro.

Résultats publiés par l'auteur.

Mesure Valeur
Latence, 1 question (GPU) ~38 ms
Latence, 10 questions ~156 ms
Latence, 50 questions ~721 ms
Précision macro, tâches vues à l'entraînement 0,838 (ECE 0,060)
Précision macro, familles de tâches jamais vues 0,651 (ECE 0,207)
Routage d'intention 0,991 (ECE 0,009)
Modération 0,967 (ECE 0,061)
Tri d'e-mails et phishing 0,732 (ECE 0,017)

Lecture critique. Le titre « surpasse tous les benchmarks de Jev » ne tient pas à l'examen :

  1. La comparaison n'est pas à périmètre égal. Le 83,8 % de Laya est mesuré sur les jeux de test de ses propres tâches d'entraînement ; le 67,8 % attribué à Jev vient d'un autre jeu d'évaluation (4 workflows de production), où Jev reçoit ses questions à la volée sans entraînement spécifique. Le chiffre honnêtement comparable est le zero-shot de Laya : 0,651, en dessous de Jev.
  2. La calibration ne se transfère pas. Un ECE de 0,207 hors distribution est mauvais, et nettement moins bon que les ~0,07 de decider sur tâches jamais vues. Or toute la promesse System One est de poser des questions arbitraires à l'exécution.
  3. Incohérence interne. Le tableau comparatif annonce « 86,3 % en zero-shot » sur une ligne, alors que la fiche du modèle donne 0,651 en macro zero-shot.
  4. Latence : pas réellement une passe unique. Le temps croît presque linéairement avec le nombre de questions (~15 ms par question) : chaque question ré-encode l'état dans une fenêtre de 512 tokens, regroupée en mini-batch. Et comparer un GPU local à une API distante, réseau compris, n'a pas grand sens.
  5. L'apport du « RL » est discutable. Maximiser une règle de score propre est un objectif différentiable : une descente de gradient classique sur la log-vraisemblance (ce que fait decider) optimise la même chose sans le bruit de l'estimateur par policy gradient. Indice supplémentaire : le modèle applique malgré tout des températures de calibration a posteriori (1,25 à 1,98), toutes supérieures à 1, ce qui signifie qu'il restait sur-confiant après entraînement.
  6. Limites pratiques. Anglais uniquement, texte uniquement, 512 tokens par question avec troncature au-delà. L'idée de scorer des marqueurs d'option masqués sur un encodeur n'est pas nouvelle non plus (travaux de type UniMC, GLiClass, classifieurs zero-shot par NLI).

Ce qu'il faut en retenir. L'architecture est la bonne pour ce problème : un encodeur bidirectionnel de quelques centaines de millions de paramètres est plus rapide, moins cher et souvent meilleur en classification qu'un LLM décodeur de 4 milliards, et tourne sur CPU. Les excellents scores en tâche connue (routage à 0,99) confirment la conclusion générale : ce type de modèle brille une fois fine-tuné sur le domaine cible. Laya est donc moins un « Jev ouvert » qu'un bon point de départ à ré-entraîner, à condition de repartir d'un encodeur multilingue pour du contenu en français (par exemple mmBERT ou EuroBERT, à valider).

3.5 Réplique architecturale fidèle : kev

  • Dépôt : https://github.com/jaredpalmer/kev (Apache 2.0), par Jared Palmer (auteur de Formik et Turborepo), construit avec l'agent Devin.
  • Poids : adaptateur LoRA + tête de lecture + tokenizer, 38 Mo, en release GitHub. Base Qwen2.5-0.5B.

C'est la première implémentation qui suit le plan d'Archer Hume plutôt que d'approcher l'interface.

Mécanisme. L'état et toutes les questions sont empaquetés dans une seule séquence, avec des tokens réservés (<state>, <q>, <opt>, <decide>). Un masque bloc-causal laisse chaque question voir l'état mais jamais une autre question ; les positions redémarrent après l'état pour chaque branche, donc l'ordre des questions est sans effet. Une tête pointeur compare l'état caché du token <decide> à celui de chaque </opt>, puis softmax. Le token de décision venant après toutes les options, le modèle lit la liste complète avant de trancher, ce qui rend possible une option « aucune de ces réponses ». Entraînement : LoRA (r = 16) + tête from scratch, en cross-entropie, sans renforcement.

Compatibilité. POST /v1/systemone avec les formes de requête et de réponse de TypeSafe : le SDK officiel fonctionne en changeant seulement base_url, et la suite de tests rejoue les exemples de la documentation TypeSafe. Un playground web permet de comparer requête groupée et requêtes séparées, et de permuter les options.

Résultats publiés (précision / ECE, jeux de test issus des mêmes sources que l'entraînement) :

Tâche Qwen 0,5B zero-shot kev-0.5b
Choice 4 options (AG News) 0,813 / 0,069 0,940 / 0,028
Choice 3 options (MNLI) 0,460 / 0,225 0,747 / 0,100
Choice 77 options (Banking77) non mesuré 0,860 / 0,057
Noul (BoolQ) 0,427 / 0,274 0,753 / 0,136
Score 5 niveaux (Yelp) 0,313 / 0,043 0,553 / 0,118
Ensemble (1 350 questions) 0,799 / 0,065 (0,031 après température)

Tests de mécanisme : isolation exacte (requête groupée et requêtes séparées concordent à 4e-6 près, la première étant 2× plus rapide), injection de faux délimiteurs sans effet, mais 7,4 % de changements de réponse selon l'ordre des options. Entraînement en ~1 h 45 sur un Apple M5 (9 000 exemples, 6 jeux publics), ~160 ms pour une requête de 6 questions.

Limites, énoncées par l'auteur. Un modèle de 0,5 Md se trompe là où Jev voit juste sur les exemples de la documentation ; six jeux de données seulement ; calibration mesurée en distribution uniquement, qui ne dit rien d'un nouveau workflow ; contexte d'entraînement court (384 tokens d'état) ; service en fp32 sur MPS, une requête à la fois, CUDA non testé, aucune authentification.

Intérêt pour nous. C'est le meilleur banc d'entraînement du lot : recette complète et reproductible sur un Mac, option --holdout pour mesurer hors source, termes optionnels de régularisation (cohérence sous permutation des options, terme ordinal pour Score), base remplaçable via --base par un Qwen plus gros. Qwen2.5 est multilingue, contrairement à ModernBERT (Laya), mais les données d'entraînement de kev sont en anglais : à réentraîner sur nos propres exemples en français.

4. Analyse

  1. L'interface est devenue un standard de fait en trois jours. Un serveur local compatible /v1/systemone rend tout l'écosystème client réutilisable sans dépendre de TypeSafe. C'est le scénario des API « compatibles OpenAI » qui se rejoue.
  2. Le gain de vitesse vient surtout de l'absence de décodage, pas d'une architecture exotique. Préfill partagé + batch des questions : vLLM, SGLang, llama.cpp et MLX savent déjà le faire.
  3. Le fossé réel est la calibration hors distribution. Tous les réimplémenteurs le disent : le zero-shot donne la forme et la latence, pas des probabilités fiables ni le jugement fin. Laya le confirme à sa manière : excellent sur ses tâches d'entraînement, mal calibré dès qu'on en sort. La voie crédible reste celle de decider : fine-tune multi-tâches large et calibration mesurée sur des tâches jamais vues.
  4. Sur un domaine étroit, le spécialisé bat le généraliste. Quelques milliers d'exemples étiquetés suffisent à un petit modèle pour décider en millisecondes. La calibration se traite alors simplement (temperature scaling ou régression isotonique sur un jeu de validation).
  5. Le moat de TypeSafe tient à trois choses : la calibration à l'échelle, la qualité du modèle sous-jacent, et le prix. Si un labo ouvert publie un modèle post-entraîné pour la décision calibrée, l'avantage fond vite.
  6. Le plan d'architecture est désormais public, et il favorise le décodeur. Avec un transformer causal, l'état est encodé une fois et son cache KV est partagé par toutes les questions ; un encodeur bidirectionnel comme Laya doit ré-encoder l'état pour chaque question. Sur des documents longs avec beaucoup de questions, l'écart de coût est d'un ordre de grandeur. kev montre que ce schéma tient en quelques centaines de lignes (masque bloc-causal + tête pointeur).
  7. La cross-entropie suffit probablement. decider et kev obtiennent une calibration correcte sans renforcement, et la rétro-ingénierie de Hume va dans le même sens. Le « RL » de RLCD relève peut-être autant du positionnement que de l'algorithme ; la vraie difficulté est la largeur et la qualité des données étiquetées par résultat.
  8. Deux familles d'architecture se dessinent. LLM décodeur avec lecture de logits (souple, bon en zero-shot, multilingue, plus lourd) contre encodeur bidirectionnel avec tête dédiée (très rapide, léger, excellent une fois spécialisé, faible en zero-shot). Le choix dépend de la question : questions arbitraires à l'exécution, ou jeu de questions stable sur un domaine connu ?
  9. Se méfier des annonces « bat Jev ». Vérifier systématiquement : même jeu d'évaluation ? tâches vues ou non à l'entraînement ? calibration mesurée hors distribution ? langue ?

Points de vigilance techniques

  • Options multi-tokens : sommer les logprobs ou imposer des labels mono-token (A, B, C…).
  • Biais de position et de label : mélanger l'ordre des options à l'entraînement (decider), ou pénaliser l'écart entre deux ordres (option --perm_kl de kev). Jev lui-même y est sensible : à tester systématiquement, surtout près des seuils de décision.
  • Non-déterminisme numérique : openjev constate 5 à 6 argmax modifiés sur 777 entre le chemin rapide (BF16, cache partagé) et le scoring frais. À surveiller avec des seuils serrés.
  • Probabilités conditionnelles aux options fournies : si la bonne réponse n'est pas dans la liste, le modèle répartit quand même 100 %. Prévoir une option « autre / aucune ».
  • Langue : la plupart des démonstrations sont en anglais. Laya est explicitement anglais uniquement ; les LLM de la section 3.1 sont multilingues mais leur calibration en français reste à mesurer.
  • Maturité : tous ces dépôts ont quelques jours, 2 à 7 commits, et une bonne part de code généré par agents. Ce sont des preuves de concept, pas des dépendances.

5. Pistes pour nous

Cas d'usage candidats : classification et catégorisation de contenus à haut débit, routage, filtrage (spam, modération), contrôles de cohérence, garde-fous autour d'agents.

Démarche proposée :

  1. Constituer un jeu étiqueté de quelques centaines d'exemples sur un cas réel. C'est le prérequis de tout le reste, y compris pour évaluer Jev lui-même.
  2. Mesurer la baseline zero-shot en local avec daseinlabs/open-jev (Mac) ou TheoLeeCJ/openjev (GPU NVIDIA), et la comparer à une baseline classique (TF-IDF, embeddings + régression logistique). Si la baseline classique tient, inutile d'aller plus loin.
  3. Si le zero-shot est insuffisant : partir de la recette kev (LoRA + tête pointeur sur un petit Qwen, entraînable sur un Mac) avec nos exemples, en comparant au besoin à decider ou à un encodeur multilingue façon Laya, puis calibration sur un jeu de validation.
  4. Exposer le tout derrière le contrat /v1/systemone pour rester interchangeable avec l'API officielle et l'outillage existant.
  5. Séparer recommandation et exécution, et tout journaliser. Le modèle recommande, du code déterministe vérifie permissions et limites avant d'agir. Conserver de quoi rejouer chaque décision : version du modèle, état, question, options, distribution renvoyée, seuil appliqué, action exécutée, résultat constaté, correction humaine éventuelle. C'est ce journal qui permet de recalibrer et de détecter la dérive.
  6. Escalade par paliers : confiance haute et enjeu faible, on automatise ; confiance moyenne, on passe à un LLM ; confiance basse ou enjeu fort, revue humaine ; état hors distribution, abstention. Prévoir l'abstention comme option explicite dans chaque question.

À garder en tête : l'API officielle implique l'envoi des données à un service US, ce qui exclut les contenus sensibles. Toutes les approches ci-dessus tournent entièrement en local.

Note de méthode

  • Projet d'origine : voir la section « Liens du projet d'origine ».
  • Jev: The Emerging Decision Layer for AI Software (18 septembre 2026), rapport généré par un agent de Levangie Labs et Robert Scoble à partir de ses listes X : https://docs.google.com/document/d/1Y-b-02bPae2rUwTiB1dFkkvedqdP1pjOCH7a_CPE9uI. Sources exclusivement issues de X, non vérifiées par nos soins ; utilisé pour la distribution, le catalogue de cas d'usage et les retours indépendants sur la calibration.
  • Archer Hume, Jev's Architecture Unmasked (17 septembre 2026), et ses jeux de données de sondes.
  • Post r/LocalLLaMA de présentation de Laya (18 septembre 2026), dépôt GitHub et fiche Hugging Face du modèle.
  • Dépôts cités, consultés le 18 septembre 2026. Les chiffres de performance et de qualité sont ceux publiés par chaque auteur dans son README, non reproduits par nos soins.

Sources