Qu'est-ce que RSI-Jev ? Une boucle d'auto-amélioration qui construit des modèles de décision de style Jev

RSI-Jev est un projet de recherche ouvert tiers qui construit des modèles de décision System One dans le style de Jev, et le modèle dont traite cette page est sa version 4B, RSI-Jev v6.0-VL, datée du 2026-10-06. Il est écrit par Shanghua Gao (@gasvn), avec Sufian (@SufianTA) crédité dans les remerciements du dépôt, et il n’est pas le Jev de TypeSafe ni affilié à TypeSafe AI — la mention de licence du projet lui-même dit exactement cela. L’idée qui la sous-tend est assez simple pour être énoncée en une phrase : posez une question typée à propos d’un document, d’une conversation ou d’une image — oui/non, choix unique parmi k, notation selon une grille d’évaluation — et une seule passe avant renvoie une probabilité calibrée pour chaque option. Rien n’est généré, donc il n’y a pas de jetons de raisonnement à dépenser, et aucun n’est dépensé. v6.0-VL n’est pas la première version du projet ; c’est sa septième en douze jours, ce qui est la chose la plus importante à comprendre à son sujet, car l’information utile ici réside dans la forme de la courbe plutôt que dans un quelconque checkpoint.

Une chose doit être dite avant tous les chiffres, car elle permet de les dater tous. v6.0-VL a été en tête pendant exactement un jour. Le 2026-10-07 à 07:56 UTC — ce matin — le projet a publié RSI-Jev v6.1-VL, qui est la moyenne de v6.0-VL et d'un second fine-tune du même Qwen3.5-4B-Base entraîné sur d'autres données, à raison de 0,5 chacun, et qui obtient 50,98 sur le kit Decision Index 0.3 du projet, contre 46,23 pour v6.0-VL sur ce même kit. Rien n'a été entraîné après la moyenne. Sa calibration est moins bonne que celle de v6.0-VL, et sa propre fiche le dit. Cette publication est bien réelle et actuelle ; cette page ne la concerne pas. Chaque chiffre ci-dessous est tiré de la fiche de publication de v6.0-VL, datée du 2026-10-06, et lorsqu'un décompte a évolué depuis — le décompte des versions publiées, le décompte des expériences — cette page donne à la fois le chiffre tel qu'il était pour v6.0-VL et le chiffre tel qu'il se lit aujourd'hui.

Ce que RSI-Jev n'est pas mérite aussi d'être dit d'emblée, car deux des trois hypothèses évidentes sont fausses. Ce n'est pas un produit hébergé que l'on peut appeler aujourd'hui via une API générale, et il n'est pas servi par OrcaRouter — notre catalogue ne contient aucun identifiant rsi-jev, aucun identifiant shgao ni de fiche modèle pour lui. La seule chose que nous ayons, c'est le modèle dont ce projet copie le contrat HTTP : le Jev commercial de TypeSafe, que nous servons soustypesafe/jev-1.13 sur le point de terminaison systemone. L'un des deux, vous l'appelez, et l'autre, vous le téléchargez et le servez vous-même. Tout ce qui suit provient du dépôt propre au projet, de ses fiches de version et de sa documentation de service, consultés le 2026-10-07, et lorsqu'un chiffre est celui du projet plutôt qu'une mesure externe, cette page précise à qui il appartient.

Ce que la chose fait réellement

Le projet se décrit en une ligne comme « un système de recherche à auto-amélioration récursive qui construit des modèles System One de style Jev », et les artefacts qu’il produit sont des décideurs plutôt que des générateurs. Vous lui donnez un état — un document, une transcription de chat, une transaction, et, dans les versions avec vision, jusqu’à quatre images — ainsi qu’une ou plusieurs questions typées avec des critères nommés. Il renvoie, pour chaque question, une probabilité pour chaque option. Trois types de questions couvrent cet espace, et ce sont ceux que l’API de TypeSafe définit :

• booléen — un jugement vrai/faux, renvoyé sous forme d'une probabilité unique, sans distribution ni valeur de confiance, correspondant exactement à la forme de réponse de la référence.

• choix — sélectionnez une option parmi un ensemble d'options étiquetées, renvoyée avec la distribution de probabilités complète et une statistique de confiance.

• score — notation sur une grille d’évaluation ordonnée, renvoyée sous la forme d’un indice à base zéro dans les niveaux, pondéré par les probabilités, ainsi que la légende et la distribution.

Comme il n'y a pas d'étape de génération, il n'y a pas de second appel au modèle ni d'échantillonnage. Une décision concernant un document que le modèle a déjà lu est, par construction, une opération peu coûteuse, et la mention du projet lui-même pour ce coût — « environ 10 ms » — appartient à son ère 2B, pas à la version actuelle ; les chiffres mesurés pour v6.0-VL sont donnés plus bas.

Deux faits concernant la propriété comptent plus que tout le reste sur cette page. RSI-Jev n'est pas l'œuvre de TypeSafe et TypeSafe ne l'a pas cautionné. La mention de licence, citée intégralement : « Code : MIT. Poids : Apache-2.0, suivant le modèle de base ; certaines sources d'entraînement d'images sont non commerciales, listées sur chaque fiche de modèle. Non affilié à TypeSafe AI. » Et la relation ne va que dans un sens : le projet copie délibérément le format de transmission de Jev, et le dit, parce qu'un serveur compatible est l'objectif. « Jev-style » est la formule employée par le projet lui-même pour le type de modèle qu'il construit. Le Jev de TypeSafe est un modèle différent, fermé et commercial, et les deux ne sont pas la même chose sous un nom plus court.

À l’intérieur du modèle actuel : une tour Qwen 4B avec trois sorties

RSI-Jev v6.0-VL est une tour Qwen3.5-4B-Base avec la tour affinée et une tête de décision entraînée par-dessus. C’est toute l’architecture — il n’y a pas de mélange d’experts, pas de routeur et pas de second modèle. Il exécute l’intégralité du modèle de base, c’est pourquoi son nombre de paramètres est de 4,69 B et non quelque chose de plus petit : 3,57 B se trouvent dans les 32 couches de décodeur, 0,64 B dans les embeddings de tokens, 0,33 B dans la tour de vision, 0,05 B dans la tête de décision principale et 0,10 B dans les deux têtes de sortie anticipée. Le checkpoint publié est autonome et fait 9,7 Go en bf16.

Trois têtes de décision sont attachées, aux couches 16, 20 et 32 de la base, et elles constituent le mécanisme derrière tout ce pour quoi la version actuelle est connue. Une quatrième sortie, à la couche 12, a été construite, mesurée puis abandonnée — « La sortie de la couche 12 a perdu face à la cascade issue de la couche 16 dans chaque comparaison et ne fait pas partie du paquet » — donc trois sont livrées et quatre ne le sont pas. Les sorties lisent une copie détachée de leur couche, un détail que le projet a découvert à ses dépens : le réajustement des têtes sur un tronc dont les sorties avaient été attachées pendant l'entraînement n'avait pas permis de retrouver la précision des couches profondes, c'est donc leur détachement qui a restauré la profondeur.

Un seul chiffre suffit ici à se tromper sur le projet. Tout jusqu'à v3.0 inclus était un modèle 2B sur Qwen3.5-2B-Base, et c'est la lignée, pas le modèle actuel. v4.0-VL était un 2B, v5.0-VL a ramené un modèle à 3B, et v6.0-VL est un 4B. Une page qui qualifie de 2B le modèle RSI-Jev actuel accuse trois versions de retard.

La boucle est le véritable projet

Les modèles sont le résultat ; ce qui est en train d'être construit, c'est le processus. Le projet déclare que « la boucle qui fait tourner la recherche est la prochaine version d'AutoScientists », le système auto-organisé d'équipes d'agents publié par le laboratoire Zitnik à Harvard, et il fonctionne comme cette phrase le laisse entendre. Des agents IA proposent des hypothèses, enregistrent leurs prédictions avant de consacrer du temps GPU, réalisent les expériences et mettent à la retraite leurs propres champions lorsque les preuves le commandent. Deux décomptes rendent cela concret. Consulté le 2026-10-07, le titre du dépôt annonce huit versions en treize jours, de la v1.0 à la v6.1-VL ; pour la sortie propre de la v6.0-VL, le 2026-10-06, il indiquait sept versions en douze jours, chacune entraînée, évaluée et documentée par la boucle. Et le nombre d'expériences, qui s'élevait à 471 lors de la publication de la version de cette page, affiche 496 aujourd'hui — chacune faisant l'objet d'un compte rendu, échecs inclus. Les deux décomptes sont ceux du projet, et tous deux évoluent.

La discipline est ce qui donne du sens à ces chiffres, et le projet l'énonce sans détour. Les planchers nuls sont mesurés plutôt que présumés — des bras prouvablement identiques au contrôle, vérifiés par identité d'objet avant toute dépense de temps GPU, de sorte que l'écart entre eux est le plancher de bruit et qu'une différence inférieure à cet écart ne constitue pas un résultat. Les prédictions sont enregistrées avant l'exécution, de sorte qu'une version qui rate son propre seuil est livrée comme un échec plutôt que d'être discrètement retaillée. Les artefacts sont vérifiés : un point de contrôle est rechargé depuis le disque et réévalué, puis publié uniquement s'il reproduit les prédictions par question de son exécution d'entraînement, ce que font les deux points de contrôle v1.0, à 1,0000. La contamination est « vérifiée plutôt qu'affirmée ». Et les échecs sont livrés, y compris ceux qui ont tué le champion du projet lui-même.

Ce qu’est une contribution, dans les mots mêmes du projet tirés de son guide de contribution : « Une contribution ici est généralement une mesure, pas un correctif. » L’historique des versions publiées est conservé sous forme de chaîne plutôt que d’instantané — « versions/ conserve une fiche par version, toutes, sur main pour toujours… Cette chaîne EST le projet » — c’est pourquoi les chiffres d’une ancienne version peuvent être vérifiés par rapport à ce que le projet en dit plus tard, et pourquoi l’unique correction évoquée ci-dessous est visible au lieu d’être silencieuse.

Ce que v6.0-VL a changé : il dépense de la profondeur au lieu de jetons

Le mécanisme de la version actuelle est un réglage appelé effort, et il contrôle quelque chose d'inhabituel : le nombre de couches du modèle qu'une requête est autorisée à utiliser. Comme les têtes se situent à trois profondeurs, une question facile peut recevoir une réponse à la couche 16 et une question difficile peut parcourir les 32 couches. faible s'arrête à la couche 16, moyen à 20, élevé à 32, et auto répond à la première sortie dont la probabilité calibrée franchit le seuil de cette sortie. Latence médiane par requête sur l'échantillon Decision Index, mesurée sur un H200 en bf16 : 23 ms à faible, 27 ms à moyen, 40 ms à élevé, et 40 ms pour la valeur par défaut lorsqu'aucun réglage n'est défini. Ce sont les mesures du projet sur son propre matériel et elles ne doivent pas être mélangées aux chiffres GB10 de la documentation de serving, qui correspondent à une autre machine.

Le comportement mesuré de auto est la partie intéressante : sur la suite de quinze benchmarks du projet, 20 % des questions s'arrêtent à la couche 16, 46 % à la couche 20 et 34 % vont jusqu'à la couche 32, soit une moyenne de 23,3 couches sur 32. Un seuil fixe unique donne une moyenne de 20,9, et le sur-arrêt est précisément ce qu'un seuil unique vous offre. auto n'est pas un compromis sur la qualité, ce qui mérite d'être dit, car c'est habituellement ce qu'est un réglage adaptatif : il affiche la meilleure ligne de suite tous réglages confondus (0,771 contre 0,770 pour la valeur par défaut), la meilleure ligne MMLU-Pro (0,444 contre 0,440) et la meilleure calibration finale (ECE 0,024 contre 0,036). Le seul endroit où high l'emporte, c'est l'ensemble de validation, avec 0,702 contre les 0,696 obtenus par auto. Certaines tâches se dégradent de façon mesurable avec la profondeur — BANKING77 de 0,035, l'appariement de légendes du New Yorker de 0,060 —, et c'est pourquoi le niveau d'effort est un choix que fait l'appelant plutôt qu'une règle que le serveur impose.

Le résultat qui a fait de ceci une version plutôt qu’une expérience figure sur le Decision Index public 0.2.1 du projet, où le score est passé de 38,38 pour v5.0-VL à 46,24 pour v6.0-VL en une seule version. Dans le classement public daté du 2026-09-28, c’est le score le plus élevé parmi les modèles 4B et tout ce qui est plus petit, et le 14e sur 71 au total ; l’entrée suivante dans cette taille est JPT-4B à 43,04. Les versions antérieures de cette lignée relèvent de la généalogie et non du modèle actuel : v5.0-VL (2026-10-02) a réduit le modèle aux 20 premières couches sur 32 et l’a fait répondre « unknown » lorsqu’une question n’a pas de réponse ; v4.0-VL (2026-10-01) a été la première à lire les images ; et v3.0 (2026-09-28) est la version où l’apprentissage par renforcement a aidé pour la première fois, via une récompense de classement par liste — NDCG@5 sur 16 candidats — qui a fait passer le R@1 de reranking de 0,192 à 0,308 par rapport à son parent supervisé, au prix de 0,0028 sur la suite. C’est là que commence l’histoire de l’apprentissage par renforcement du projet, et cela remonte maintenant à trois versions.

Les chiffres, avec les réserves qui les accompagnent

Le chiffre phare du Decision Index 0.2.1 pour v6.0-VL est de 46,24, sur une exécution complète au cours de laquelle les 150 759 requêtes de la suite ont toutes reçu une réponse : connaissances 28,8, langue 46,2, récupération 55,5, outils 65,8, arts 37,1. La suite de quinze benchmarks affiche 0,770, l'ensemble tenu à l'écart 0,698, MMLU-Pro 0,440, et l'ECE final 0,024 avec auto. Deux réserves doivent être formulées dans le même souffle que ces chiffres, car sans elles, les chiffres induisent en erreur.

Le premier est une suppression dans la suite. La tâche interne de la suite open_jev_ood chevauchait 579 lignes d'entraînement, son chiffre a donc été gonflé d'une quantité inconnue ; à partir de la v6.0-VL, le projet publie la suite sans elle, à 0,770. Le 0,764 de la v5.0-VL était avec elle, et la fiche de la v6.0-VL reformule cette version à 0,763 sans elle. Les deux chiffres ne sont pas comparables, et si vous les comparez, vous devez utiliser le 0,763 reformulé et préciser que c'est ce que vous faites. L'ensemble held-out, MMLU-Pro et BBH ne présentent aucun chevauchement et ne sont pas affectés. Un audit connexe a trouvé environ 1 000 éléments des lignes de test du kit Decision Index dans les corpus d'entraînement — ANLI 274, RouterBench-GSM8K 90, ARC 5, et du texte de requête BRIGHT/ToolRet sans étiquettes, soit environ 0,3 % des lignes du kit — et un nouveau calcul du score sans eux déplace l'indice d'au plus 0,04 sur l'échantillon du projet. C'est une correction au relevé de la v5.0-VL, publiée dans la fiche de la v6.0-VL, et c'est la propre règle de contamination du projet qui lui coûte un chiffre.

Le deuxième point, c’est de savoir à qui appartient ce benchmark. Le Decision Index est le classement public de RSI-Jev lui-même, pas le verdict d’un tiers, et 46,24 est un score dans ce classement. Il n’est comparable à rien de ce que TypeSafe a publié, car les deux chiffres ne proviennent pas du même banc d’essai, et personne n’a mené de comparaison directe indépendante entre RSI-Jev et Jev 1.13. Ce que l’on peut dire est structurel plutôt que numérique : l’un est un modèle commercial hébergé sur le point de terminaison d’un fournisseur, et l’autre est un checkpoint que vous téléchargez et servez vous-même.

Deux autres éléments de contexte accompagnent cet ensemble. Le projet précise explicitement que « dix des quinze benchmarks contribuent aux données d'entraînement sous une forme ou une autre, donc aucun de ces chiffres n'est en zero-shot » ; l'ensemble mis de côté est la comparaison qui est mise de côté, et même lui « est mis de côté pour l'entraînement, pas scellé vis-à-vis de la recherche ». Et v6.0-VL a exécuté 97 bras sur sa propre ligne — 93 si l'on exclut les quatre audits de données — ce qui correspond à l'échelle de recherche qui a produit un bond de 7,86 points sur cet indice.

Il parle le format de transmission de Jev, avec quatre différences qu’un appelant doit connaître

La surface de compatibilité est la raison pour laquelle ce projet existe sous la forme qu'il a. La même forme de requête ({state, model, questions}), les mêmes trois types de questions avec les mêmes formes de critères, les mêmes formes de réponse, le même nombre de 1 à 64 questions par requête, les mêmes enveloppes d'erreur et la même statistique de confiance — le pic, (K · p_max − 1) / (K − 1), borné à 0..1. L'affirmation du projet lui-même à propos de cette surface est que « tout ce qui est écrit pour Jev fonctionne avec ceci sans modifications », et le serveur documente ce qui est copié et ce qui ne l'est pas, ce qui est plus utile que cette affirmation.

• Le prompt et la tête de lecture lui sont propres. RSI-Jev est un modèle de base doté d’une tête de lecture entraînée, servi avec l’encodeur avec lequel il a été entraîné, car utiliser le prompt de la référence « sortirait le modèle de sa distribution d’entraînement ». Le contrat de fil est la surface de compatibilité ; le prompt ne l’est pas.

• Les clés d'option sont visibles par le modèle. La référence les masque, si bien qu'il est démontrable que renommer une clé ne peut pas y modifier une réponse. Ici, c'est possible, et le serveur le signale honnêtement comme option_keys_visible_to_model: true.

• Les critères doivent être des chaînes de caractères ou null. Un critère structuré — un objet — est rejeté avec une 422, car aucune release n'a été entraînée sur un tel critère. C'est le seul endroit où une requête que la référence accepte ne s'exécutera pas ici.

• Rien n’est tronqué. Le service prend en charge jusqu’à 32 768 jetons de texte, en plus du budget d’image, et une requête plus longue est refusée avec une erreur 422 qui l’indique, plutôt que d’être tronquée silencieusement. Le chiffre de 2 048 jetons qui apparaît dans les anciennes fiches correspond à la longueur sur laquelle les modèles ont été entraînés, et non à une limite de service, et décrire une troncature silencieuse à 2 048 comme le comportement actuel est erroné.

Le nombre d'options diffère largement en faveur du serving : jusqu'à 5 120 options par question (RSIJEV_MAX_ANSWERS), contre 160 en entraînement et 64 admises par la référence. Ne citez pas 160 comme plafond du serving. Une chose est nouvelle dans les réponses de v6.0-VL plutôt qu'héritée : chaque réponse indique quelle couche a répondu, dans usage.depth, aux côtés de la confiance calibrée, afin qu'une décision adaptative puisse être auditée après coup. Les images sont une extension que la référence n'a pas — une à quatre par requête, sous forme d'URL de données base64, l'état faisant référence à chacune par un marqueur littéral.

Là où un lecteur peut réellement l’exécuter, et là où il ne peut pas.

RSI-Jev est téléchargeable. Le projet fournit son propre serveur, qui parle cette API compatible avec Jev, et la procédure documentée consiste en une installation pip depuis le dépôt, suivie de sa commande serve avec l’alias de checkpoint et un réglage d’effort. Les poids sont hébergés sur Hugging Face sous l’organisation shgao, publiés sous Apache-2.0 comme le modèle de base, avec une question ouverte que le projet énonce lui-même : cinq des sources d’entraînement d’images sont non commerciales ou réservées à la recherche, et « la question de savoir si les poids entraînés sur des données non commerciales héritent de ces conditions n’est pas tranchée. » Le code est sous licence MIT.

Le matériel n'est pas la contrainte. Le projet se développe sur un HP ZGX Nano, une machine NVIDIA GB10 qu'il crédite à HP et NVIDIA, et le serveur tourne sur n'importe quel GPU CUDA, sur Apple Silicon ou sur un simple CPU — ce dernier étant annoncé par la documentation à 733 ms pour une seule question sur le CPU Arm propre au GB10, donc utilisable plutôt que rapide.

Ce qu'il ne fait pas, c'est figurer dans un catalogue général de modèles, et c'est là qu'il nous faut être précis sur notre propre position. RSI-Jev n'est pas sur OrcaRouter et il n'existe aucune fiche de modèle vers laquelle le router. Ce que nous servons, c'est le Jev commercial de TypeSafe, typesafe/jev-1.13, sur le point de terminaison dédié systemone, atteint par un POST vers /v1/systemone plutôt que par la forme chat-completions d'OpenAI — les mêmes formes de requête et de réponse que ce projet met en œuvre, issues du modèle dont il copie le contrat. Telle est toute la relation : les deux parlent le même protocole, nous en servons un, et vous exécutez l'autre vous-même. Si vous détenez déjà une clé chez nous, la forme d'appel de Jev 1.13 est une route de premier ordre sur une API unique pour plus de 200 modèles, avec 0 % de marge (prix catalogue du fournisseur répercuté, si bien que les baisses de prix des fournisseurs sont effectives ici le jour même) — ce qui compte pour la comparaison d'une manière bien précise. Une page comme celle-ci est peu coûteuse à exploiter si vous pouvez essayer d'abord le contrat commercial et ne décider qu'ensuite si exécuter vous-même un checkpoint ouvert de 4B vaut le travail opérationnel.

Comment lire RSI-Jev le 2026-10-07

Les faiblesses que le projet publie sont aussi précises que ses résultats, et les dates comptent. Les tests externes de la v2.1 ont montré que le modèle penche vers l’option la plus sévère ou la plus coûteuse dans les choix ordonnés et les scores de grille d’évaluation, choisit rarement « unknown » lorsque le document ne permet pas de répondre, et répond de façon incohérente à une question et à sa négation. Les versions ultérieures ont dirigé les données vers le cas « unknown » — KoBBQ unknown-when-ambiguous est passé à 0,891 en v4.0-VL, 0,932 en v5.0-VL, et 0,918 / 0,939 en v6.0-VL — et la fiche de la v6.0-VL reconnaît franchement que les gains viennent des données plutôt que de la profondeur, et que les 10 % de questions qui iraient à la couche 32 et s’arrêtent à 16 ou 20 sont précisément là où la politique de profondeur devine encore. Le reranking a encore du chemin à faire : l’ordre de récupération propre à hippo-memory obtient 0,484 R@1 et reste devant les 0,308 atteints par le modèle en v3.0, un chiffre que le projet n’a pas prétendu combler depuis. Les preuves RL reposent sur une seule graine, et la v3.0 « n’a elle-même aucun contrôle SFT apparié ». Les corpus d’entraînement et les ensembles de développement de politiques ne sont pas publics, de sorte que les étapes ne peuvent pas être réexécutées à partir du seul dépôt, et le constructeur de corpus de reranking — environ 96 Go de mémoire — n’a pas été réexécuté de bout en bout.

Traction, relevée le jour même : 73 étoiles, 5 forks, 0 issue ouverte, 7 releases GitHub. Ces chiffres évoluent quotidiennement, et un dépôt vieux de trois semaines n’est pas un projet établi, quel que soit son rythme de publication. Le résumé honnête, c’est que RSI-Jev est l’un des efforts de recherche les plus lisibles dans ce coin du domaine — une série de versions datées, mesurées, parfois perdantes, avec la recherche publiée aux côtés des scores — et l’un des moins vérifiés de façon indépendante, puisque presque tous les chiffres de cette page sont les siens et qu’aucun acteur extérieur ne l’a comparé au modèle commercial avec lequel il est compatible.

Ce qu'il faut surveiller, ce n'est pas la prochaine version, car il y en aura une d'ici quelques jours à ce rythme ; c'est de savoir si quelque chose en dehors du projet commence à mesurer. Les deux éléments qui changeraient la donne sont un benchmark indépendant exécuté sur les checkpoints publiés, et une comparaison de modèles de décision qui fait passer à la fois le 4B ouvert et le modèle hébergé de TypeSafe par un même harnais. Aucun des deux n'existe aujourd'hui. Tant qu'il n'en existe pas un, la manière utile de lire un score comme 46.24 est de le voir comme une affirmation bien documentée d'un projet qui enregistre ses prédictions à l'avance et publie les bras qui ont échoué — ce qui constitue une trace de preuves plus solide que la plupart, et n'est toujours pas un résultat tiers.