Was ist RSI-Jev? Eine selbstverbessernde Schleife, die Entscheidungsmodelle im Jev-Style erstellt

RSI-Jev ist ein offenes Forschungsprojekt eines Dritten, das Jev-artige System-One-Entscheidungsmodelle entwickelt, und das Modell, um das es auf dieser Seite geht, ist sein 4B-Release, RSI-Jev v6.0-VL, datiert auf den 2026-10-06. Es wurde von Shanghua Gao (@gasvn) geschrieben, wobei Sufian (@SufianTA) in den Danksagungen des Repositorys genannt wird, und es ist nicht das Jev von TypeSafe und nicht mit TypeSafe AI verbunden — die eigene Lizenzzeile des Projekts sagt genau das. Die dahinterstehende Idee ist eng genug, um sie in einem Satz zu formulieren: Man stellt eine typisierte Frage zu einem Dokument, einem Chat oder einem Bild — Ja/Nein, Auswahl einer von k, Bewertung nach einer Rubrik — und ein einziger Vorwärtsdurchlauf liefert eine kalibrierte Wahrscheinlichkeit für jede Option. Nichts wird generiert, daher gibt es keine Reasoning-Tokens zu verbrauchen, und es werden auch keine verbraucht. v6.0-VL ist nicht die erste Veröffentlichung des Projekts; es ist die siebte in zwölf Tagen, und das ist das mit Abstand Wichtigste, was man darüber verstehen muss, denn die nützliche Information liegt hier in der Form der Linie und nicht in einem einzelnen Checkpoint.

Eines muss vor allen Zahlen gesagt werden, denn es gibt ihnen allen ein Datum. v6.0-VL stand genau einen Tag lang an der Spitze. Am 2026-10-07 um 07:56 UTC — heute Morgen — veröffentlichte das ProjektRSI-Jev v6.1-VL, ein Mittelwert von v6.0-VL mit einem Gewicht von je 0,5, mit einem zweiten Fine-Tuning desselben Qwen3.5-4B-Base, das auf anderen Daten trainiert wurde, und das im Decision-Index-0.3-Kit des Projekts 50,98 erzielt, gegenüber 46,23 für v6.0-VL im selben Kit. Nach dem Mittelwert wurde nichts mehr trainiert. Seine Kalibrierung ist schlechter als die von v6.0-VL, und seine eigene Karte sagt das auch. Diese Veröffentlichung ist real und aktuell; diese Seite handelt nicht davon. Jede Zahl unten stammt aus dem Release-Eintrag von v6.0-VL, datiert auf den 2026-10-06, und wo sich eine Zahl seitdem verändert hat — die Release-Zählung, die Experiment-Zählung —, nennt diese Seite sowohl die Zahl, wie sie für v6.0-VL stand, als auch die Zahl, wie sie heute lautet.

Was RSI-Jev nicht ist, gehört ebenfalls an den Anfang, denn zwei der drei naheliegenden Annahmen sind falsch. Es ist kein gehostetes Produkt, das man heute über eine allgemeine API aufrufen kann, und es wird nicht von OrcaRouter bereitgestellt – unser Katalog führt keine rsi-jev-ID, keine shgao-ID und keine Modellkarte dafür. Das Einzige, was wir haben, ist das Modell, dessen HTTP-Vertrag dieses Projekt nachbildet: TypeSafe's kommerzielles Jev, das wir als typesafe/jev-1.13 auf dem systemone-Endpunkt bereitstellen. Eines der beiden ruft man auf, das andere lädt man herunter und betreibt es selbst. Alles Folgende stammt aus dem Repository des Projekts selbst, aus seinen Release-Karten und seiner Serving-Dokumentation, gelesen am 07.10.2026, und wo eine Zahl vom Projekt selbst stammt und nicht von einer externen Messung, gibt diese Seite an, von wem sie ist.

Was die Sache tatsächlich macht

Das Projekt beschreibt sich selbst in einer Zeile als „ein rekursiv selbstverbesserndes Forschungssystem, das Jev-style-System-One-Modelle entwickelt“, und die Artefakte, die es erzeugt, sind Entscheider statt Generatoren. Man übergibt ihm einen Zustand – ein Dokument, ein Chat-Transkript, eine Transaktion und in den Vision-Releases bis zu vier Bilder – sowie eine oder mehrere typisierte Fragen mit benannten Kriterien. Es gibt für jede Frage eine Wahrscheinlichkeit für jede Option zurück. Drei Fragetypen decken den Raum ab, und sie sind die, die die API von TypeSafe definiert:

• noul — ein Wahr/Falsch-Urteil, das als einzelne Wahrscheinlichkeit zurückgegeben wird, ohne Verteilung und ohne Konfidenzwert, und das exakt der Antwortform der Referenz entspricht.

• Auswahl — wähle eine aus einer Reihe beschrifteter Optionen, die zusammen mit der vollständigen Wahrscheinlichkeitsverteilung und einer Konfidenzstatistik zurückgegeben wird.

• Bewertung — Bewertung auf Basis eines geordneten Bewertungsschemas; zurückgegeben wird ein wahrscheinlichkeitsgewichteter, nullbasierter Index in die Ebenen, samt Legende und Verteilung.

Da es keinen Generierungsschritt gibt, gibt es keinen zweiten Modellaufruf und kein Sampling. Eine Entscheidung über ein Dokument, das das Modell bereits gelesen hat, ist konstruktionsbedingt ein günstiger Vorgang, und die projektseigene Angabe zu diesen Kosten – „etwa 10 ms“ – gehört zu seiner 2B-Ära, nicht zur aktuellen Version; die gemessenen Werte für v6.0-VL sind weiter unten angegeben.

Zwei Tatsachen über die Eigentümerschaft sind wichtiger als alles andere auf dieser Seite. RSI-Jev ist nicht die Arbeit von TypeSafe, und TypeSafe hat es nicht gebilligt. Die Lizenzzeile, vollständig zitiert: „Code: MIT. Gewichte: Apache-2.0, dem Basismodell folgend; einige Bild-Trainingsquellen sind nicht kommerziell und auf jeder Modellkarte aufgeführt. Nicht mit TypeSafe AI verbunden.“ Und die Beziehung verläuft in nur eine Richtung: Das Projekt kopiert Jevs Wire-Format bewusst und sagt das auch, denn ein kompatibler Server ist der Sinn und Zweck. „Jev-style“ ist die eigene Formulierung des Projekts für die Art von Modell, die es baut. TypeSafes Jev ist ein anderes, geschlossenes, kommerzielles Modell, und die beiden sind nicht dasselbe unter einem kürzeren Namen.

Im aktuellen Modell: ein 4B-Qwen-Tower mit drei Ausgängen

RSI-Jev v6.0-VL ist ein Qwen3.5-4B-Base-Tower, wobei der Tower feinabgestimmt und ein trainierter Entscheidungskopf daraufgesetzt wurde. Das ist die gesamte Architektur – es gibt keine Mixture of Experts, keinen Router und kein zweites Modell. Es wird das gesamte Basismodell ausgeführt, weshalb seine Parameterzahl 4,69B beträgt und nicht kleiner ist: 3,57B entfallen auf die 32 Decoder-Schichten, 0,64B auf die Token-Embeddings, 0,33B auf den Vision-Tower, 0,05B auf den Haupt-Entscheidungskopf und 0,10B auf die beiden Early-Exit-Köpfe. Der veröffentlichte Checkpoint ist eigenständig und 9,7 GB groß in bf16.

Drei Entscheidungsköpfe sind an den Schichten 16, 20 und 32 des Basismodells angebracht, und sie sind der Mechanismus hinter allem, wofür die aktuelle Version bekannt ist. Ein vierter Exit auf Schicht 12 wurde gebaut, gemessen und verworfen – „Der Schicht-12-Exit verlor in jedem Vergleich gegen die Kaskade von 16 und ist nicht im Paket enthalten“ – also werden drei ausgeliefert und vier nicht. Die Exits lesen eine abgetrennte Kopie ihrer Schicht, ein Detail, das das Projekt auf die harte Tour lernen musste: Das erneute Abstimmen von Köpfen an einem Trunk, dessen Exits während des Trainings angehängt worden waren, hatte die Genauigkeit der tiefen Schichten nicht wiederhergestellt, daher war es das Abtrennen, das die Tiefe wiederherstellte.

Eine Zahl hier ist der einfachste Weg, das Projekt falsch zu verstehen. Alles bis einschließlich v3.0 war ein 2B-Modell auf Qwen3.5-2B-Base, und das ist die Abstammungslinie, nicht das aktuelle Modell. v4.0-VL war 2B, v5.0-VL reduzierte ein Modell auf 3B, und v6.0-VL ist 4B. Eine Seite, die das aktuelle RSI-Jev-Modell als 2B bezeichnet, ist drei Releases veraltet.

Die Schleife ist das eigentliche Projekt.

Die Modelle sind das Ergebnis; das, was gebaut wird, ist der Prozess. Das Projekt erklärt, dass „die Schleife, die die Forschung betreibt, die nächste Version von AutoScientists ist“, das selbstorganisierende Agenten-Team-System, das vom Zitnik-Lab in Harvard veröffentlicht wurde, und es funktioniert so, wie dieser Satz es nahelegt. KI-Agenten schlagen Hypothesen vor, registrieren ihre Vorhersagen bevor sie GPU-Zeit aufwenden, führen die Experimente durch und mustern ihre eigenen Champions aus, wenn die Evidenz dafür spricht. Zwei Zahlen machen das konkret. Gelesen am 2026-10-07, lautet die Schlagzeile des Repositorys acht Releases in dreizehn Tagen, von v1.0 bis v6.1-VL; für v6.0-VLs eigenes Release am 2026-10-06 lautete sie sieben Releases in zwölf Tagen, jedes einzelne von der Schleife trainiert, evaluiert und dokumentiert. Und die Experimentanzahl, die bei 471 stand, als das Release dieser Seite veröffentlicht wurde, lautet heute 496 — jedes einzelne dokumentiert, Fehlschläge inklusive. Beide Zahlen stammen aus dem Projekt selbst, und beide bewegen sich.

Die Disziplin ist das, was diese Zahlen bedeutsam macht, und das Projekt benennt sie schlicht. Null-Böden werden gemessen statt angenommen — Arme, die nachweislich identisch mit der Kontrolle sind, durch Objektidentität verifiziert, bevor jegliche GPU-Zeit anfällt, sodass gilt: die Streuung zwischen ihnen ist der Rauschboden, und eine Differenz, die kleiner als diese Streuung ist, ist kein Ergebnis. Vorhersagen werden vor dem Lauf registriert, sodass eine Version, die ihre eigene Messlatte verfehlt, als Fehlschlag ausgeliefert wird, statt stillschweigend neu zugeschnitten zu werden. Artefakte werden verifiziert: Ein Checkpoint wird von der Platte neu geladen und neu bewertet und nur veröffentlicht, wenn er die Vorhersagen pro Frage seines Trainingslaufs reproduziert, was beide v1.0-Checkpoints bei 1.0000 tun. Kontamination wird „geprüft statt behauptet“. Und Fehlschläge werden ausgeliefert, einschließlich derer, die den eigenen Champion des Projekts getötet haben.

Was ein Beitrag ist, in den eigenen Worten des Projekts aus seinem Mitwirkungsleitfaden: „Ein Beitrag ist hier üblicherweise eine Messung, kein Patch.“ Die veröffentlichte Aufzeichnung wird als Kette statt als Momentaufnahme geführt – „versions/ behält eine Karte pro Release, alle davon, für immer auf main … Diese Kette IST das Projekt“ – weshalb sich die Zahlen eines alten Releases später mit dem abgleichen lassen, was das Projekt über sie sagt, und weshalb die eine unten besprochene Korrektur sichtbar statt stillschweigend ist.

Was v6.0-VL verändert hat: Es gibt Tiefe statt Tokens aus.

Der Mechanismus der aktuellen Version ist eine Einstellung namens Aufwand, und sie steuert etwas Ungewöhnliches: wie viele Schichten des Modells eine Anfrage verwenden darf. Da die Heads auf drei Tiefen sitzen, kann eine einfache Frage auf Schicht 16 beantwortet werden, und eine schwierige Frage kann alle 32 durchlaufen. Niedrig stoppt bei Schicht 16, Mittel bei 20, Hoch bei 32, und Auto antwortet am ersten Exit, dessen kalibrierte Wahrscheinlichkeit den Schwellenwert dieses Exits überschreitet. Die mediane Latenz pro Anfrage auf der Stichprobe des Decision Index, gemessen auf einer H200 in bf16: 23 ms bei Niedrig, 27 ms bei Mittel, 40 ms bei Hoch, und 40 ms für die nicht gesetzte Standardeinstellung. Dies sind die eigenen Messungen des Projekts auf eigener Hardware und sie sollten nicht mit den GB10-Zahlen der Serving-Dokumentation vermischt werden, die von einer anderen Maschine stammen.

Das gemessene Verhalten von auto ist der interessante Teil: In der Fünfzehn-Benchmark-Suite des Projekts stoppen 20 % der Fragen bei Layer 16, 46 % bei Layer 20 und 34 % laufen bis 32, was durchschnittlich 23,3 von 32 Layern entspricht. Ein einzelner fester Schwellenwert liegt im Durchschnitt bei 20,9, und Überstoppen ist das, was man sich mit einem einzelnen Schwellenwert erkauft. auto ist kein Kompromiss bei der Qualität, was erwähnenswert ist, denn genau das ist üblicherweise eine adaptive Einstellung: Sie erzielt die beste Suite-Zeile aller Einstellungen (0,771 gegenüber 0,770 beim Standard), die beste MMLU-Pro-Zeile (0,444 gegenüber 0,440) und die beste finale Kalibrierung (ECE 0,024 gegenüber 0,036). Die einzige Stelle, an der high gewinnt, ist das Hold-out-Set, 0,702 gegenüber autos 0,696. Einige Aufgaben werden mit zunehmender Tiefe messbar schlechter — BANKING77 um 0,035, New Yorker-Caption-Matching um 0,060 — weshalb die Effort-Stufe eine Wahl ist, die der Aufrufer trifft, statt einer Regel, die der Server auferlegt.

Das Ergebnis, das daraus ein Release statt eines Experiments machte, steht im öffentlichen Decision Index 0.2.1 des Projekts, wo die Punktzahl in einem einzigen Release von 38,38 für v5.0-VL auf 46,24 für v6.0-VL stieg. Auf der öffentlichen Bestenliste vom 28.09.2026 ist das die höchste Punktzahl unter 4B-Modellen und allem Kleineren sowie insgesamt Platz 14 von 71; der nächste Eintrag in dieser Größenklasse ist JPT-4B mit 43,04. Die früheren Releases dieser Linie sind Vorläufer, nicht das aktuelle Modell: v5.0-VL (02.10.2026) reduzierte das Modell auf die ersten 20 von 32 Layern und brachte es dazu, „unknown“ auszugeben, wenn eine Frage keine Antwort hat; v4.0-VL (01.10.2026) war das erste Modell, das Bilder liest; und v3.0 (28.09.2026) ist das Release, in dem Reinforcement Learning erstmals half – über eine Listwise-Ranking-Belohnung (NDCG@5 über 16 Kandidaten), die R@1 beim Reranking von 0,192 auf 0,308 gegenüber seinem überwachten Elternmodell hob – bei Kosten von 0,0028 in der Suite. Dort beginnt die RL-Geschichte des Projekts, und sie liegt jetzt drei Releases zurück.

Die Zahlen, mit den Vorbehalten, die mit ihnen einhergehen

Der Decision Index 0.2.1 kommt für v6.0-VL auf einen Headline-Wert von 46.24, in einem vollständigen Durchlauf, in dem alle 150.759 Anfragen der Suite beantwortet wurden: Wissen 28.8, Sprache 46.2, Retrieval 55.5, Werkzeuge 65.8, Künste 37.1. Die Suite aus fünfzehn Benchmarks erreicht 0.770, das Held-out-Set 0.698, MMLU-Pro 0.440 und die finale ECE 0.024 mit Automatik. Zwei Einschränkungen müssen zusammen mit diesen Zahlen genannt werden, denn ohne sie führen die Zahlen in die Irre.

Das erste ist eine Kürzung in der Suite. Die interne Suite-Aufgabe open_jev_ood überlappte 579 Trainingszeilen, sodass ihre Zahl um einen unbekannten Betrag aufgebläht wurde; ab v6.0-VL berichtet das Projekt die Suite ohne sie, bei 0,770. Die 0,764 von v5.0-VL war mit ihr, und die Karte von v6.0-VL gibt diese Veröffentlichung als 0,763 ohne sie erneut an. Die beiden Zahlen sind nicht vergleichbar, und wenn Sie sie doch vergleichen, müssen Sie die neu angegebene 0,763 verwenden und sagen, dass Sie genau das tun. Das Held-out-Set, MMLU-Pro und BBH haben keine Überlappung und sind nicht betroffen. Ein verwandtes Audit fand etwa 1.000 Elemente der Testzeilen des Decision Index Kit in den Trainingskorpora – ANLI 274, RouterBench-GSM8K 90, ARC 5 und BRIGHT/ToolRet-Abfragetext ohne Labels, ungefähr 0,3 % der Zeilen des Kits – und eine Neubewertung ohne sie verschiebt den Index um höchstens 0,04 in der Stichprobe des Projekts. Das ist eine Korrektur am Eintrag zu v5.0-VL, veröffentlicht in der Karte von v6.0-VL, und es ist die eigene Kontaminationsregel des Projekts, die es eine Zahl kostet.

Das Zweite ist, wessen Benchmark das hier ist. Der Decision Index ist RSI-Jevs eigenes öffentliches Board, kein Urteil eines Dritten, und 46,24 ist eine Punktzahl auf diesem Board. Sie ist nicht mit irgendetwas vergleichbar, das TypeSafe veröffentlicht hat, weil die beiden Zahlen nicht aus demselben Harness stammen und niemand einen unabhängigen direkten Vergleich zwischen RSI-Jev und Jev 1.13 durchgeführt hat. Was sich sagen lässt, ist eher struktureller als numerischer Art: Das eine ist ein gehostetes kommerzielles Modell auf dem Endpunkt eines Anbieters, und das andere ist ein Checkpoint, den man selbst herunterlädt und selbst bereitstellt.

Zwei weitere Kontextbausteine gehören zu diesem Set. Das Projekt stellt ausdrücklich klar, dass „zehn der fünfzehn Benchmarks in irgendeiner Form Trainingsdaten beitragen, also ist keine dieser Zahlen Zero-Shot“; das Hold-out-Set ist der Vergleich, der zurückgehalten wird, und selbst es „wird vom Training zurückgehalten, nicht von der Suche abgeschirmt“. Und v6.0-VL ließ 97 Arme in seiner eigenen Reihe laufen — 93, wenn man die vier Daten-Audits ausklammert —, was der Umfang der Suche ist, der einen Sprung von 7,86 Punkten auf diesem Index bewirkt hat.

Es spricht Jevs Wire-Format, mit vier Unterschieden, die ein Aufrufer kennen sollte

Die Kompatibilitätsoberfläche ist der Grund dafür, dass dieses Projekt in der Form existiert, in der es existiert. Dieselbe Anfrageform ({state, model, questions}), dieselben drei Fragetypen mit denselben Kriterienformen, dieselben Antwortformen, dieselben 1 bis 64 Fragen pro Anfrage, dieselben Fehlerhüllen und dieselbe Konfidenzstatistik – der Spitzenwert, (K · p_max − 1) / (K − 1), begrenzt auf 0..1. Die eigene Behauptung des Projekts über diese Oberfläche lautet, dass „alles, was für Jev geschrieben wurde, ohne Änderungen damit funktioniert“, und der Server dokumentiert, was kopiert wird und was nicht, was nützlicher ist als die Behauptung.

• Der Prompt und der Readout sind seine eigenen. RSI-Jev ist ein Basismodell mit einem trainierten Readout-Head, das mit dem Encoder bereitgestellt wird, mit dem es trainiert wurde, weil die Verwendung des Referenz-Prompts „das Modell aus seiner Trainingsverteilung bringen würde“. Der Wire-Contract ist die Kompatibilitätsoberfläche; der Prompt nicht.

• Optionsschlüssel sind für das Modell sichtbar. Die Referenz verbirgt sie, daher kann das Umbenennen eines Schlüssels dort nachweislich keine Antwort ändern. Hier kann es das, und der Server meldet dies ehrlich als option_keys_visible_to_model: true.

• Kriterien müssen Zeichenketten oder null sein. Ein strukturiertes Kriterium – ein Objekt – wird mit einem 422 abgelehnt, weil kein Release darauf trainiert wurde. Dies ist die einzige Stelle, an der eine Anfrage, die die Referenz akzeptiert, hier nicht ausgeführt wird.

• Nichts wird abgeschnitten. Beim Serving sind bis zu 32.768 Text-Token plus das Bildbudget möglich, und eine längere Anfrage wird mit einem 422 abgelehnt, der dies angibt, statt stillschweigend abgeschnitten zu werden. Die 2.048-Token-Angabe, die in den älteren Karten erscheint, ist die Länge, auf die die Modelle trainiert wurden, keine Serving-Obergrenze, und eine stillschweigende Kürzung auf 2.048 als aktuelles Verhalten zu beschreiben, ist falsch.

Die Anzahl der Optionen unterscheidet sich deutlich zugunsten des Servings: bis zu 5.120 Optionen pro Frage (RSIJEV_MAX_ANSWERS), gegenüber 160 im Training und 64, die die Referenz zulässt. 160 darf nicht als Obergrenze für das Serving angegeben werden. Eine Sache ist in den Antworten von v6.0-VL neu statt übernommen: Jede Antwort meldet, welche Ebene geantwortet hat, in usage.depth, zusammen mit der kalibrierten Konfidenz, sodass eine adaptive Entscheidung im Nachhinein überprüft werden kann. Bilder sind eine Erweiterung, die die Referenz nicht hat – ein bis vier pro Anfrage, als Base64-Daten-URLs, wobei der Zustand jedes durch einen literalen Marker referenziert.

Wo ein Leser es tatsächlich ausführen kann und wo nicht

RSI-Jev ist ein Download. Das Projekt liefert seinen eigenen Server mit, der diese Jev-kompatible API spricht, und der dokumentierte Weg ist eine pip-Installation aus dem Repository, gefolgt von seinem serve-Befehl mit dem Checkpoint-Alias und einer Effort-Einstellung. Die Gewichte liegen auf Hugging Face unter der Organisation shgao, veröffentlicht unter Apache-2.0, dem Basismodell folgend, mit einer offenen Frage, die das Projekt selbst benennt: Fünf der Bild-Trainingsquellen sind nicht kommerziell oder nur für Forschungszwecke, und „ob Gewichte, die auf nicht kommerziellen Daten trainiert wurden, diese Bedingungen erben, ist nicht geklärt.“ Der Code steht unter MIT.

Hardware ist nicht der limitierende Faktor. Das Projekt wird auf einem HP ZGX Nano entwickelt, einer NVIDIA GB10-Maschine, die es HP und NVIDIA zuschreibt, und der Server läuft auf jeder CUDA-GPU, auf Apple Silicon oder auf einer herkömmlichen CPU – wobei die Dokumentation Letztere mit 733 ms für eine einzelne Frage auf der Arm-CPU des GB10 selbst beziffert, also brauchbar statt schnell.

Was es nicht tut, ist in einem allgemeinen Modellkatalog zu erscheinen, und genau hier müssen wir in Bezug auf unsere eigene Position präzise sein. RSI-Jev ist nicht auf OrcaRouter, und es gibt keine Modellkarte, an die es weitergeleitet werden könnte. Was wir bereitstellen, ist das kommerzielle Jev von TypeSafe, typesafe/jev-1.13, auf dem dedizierten systemone-Endpunkt, erreichbar mit einem POST an /v1/systemone statt des OpenAI-Chat-Completions-Formats — dieselben Anfrage- und Antwortformate, die dieses Projekt implementiert, von dem Modell, dessen Vertrag es kopiert. Das ist die gesamte Beziehung: Die beiden sprechen dasselbe Protokoll, wir stellen eines davon bereit, und das andere betreibst du selbst. Wenn du bereits einen Schlüssel bei uns hast, ist das Aufrufformat von Jev 1.13 eine erstklassige Route auf einer API für über 200 Modelle mit 0 % Aufschlag (der Listenpreis des Anbieters wird durchgereicht, Preissenkungen der Anbieter sind hier also am selben Tag live) — was für den Vergleich in einer bestimmten Hinsicht wichtig ist. Eine Seite wie diese lässt sich leicht umsetzen, wenn du zuerst den kommerziellen Vertrag ausprobieren kannst und erst dann entscheidest, ob der eigene Betrieb eines offenen 4B-Checkpoints den operativen Aufwand wert ist.

Wie man RSI-Jev am 2026-10-07 liest

Die Schwächen, die das Projekt veröffentlicht, sind so spezifisch wie seine Ergebnisse, und die Daten spielen eine Rolle. Externe Tests von v2.1 ergaben, dass das Modell bei geordneten Entscheidungen und Rubrikbewertungen zur schwerwiegenderen oder teureren Option neigt, selten „unknown“ wählt, wenn das Dokument keine Antwort geben kann, und eine Frage und ihre Verneinung inkonsistent beantwortet. Spätere Releases richteten Daten auf den „unknown“-Fall — KoBBQ unknown-when-ambiguous erreichte 0,891 bei v4.0-VL, 0,932 bei v5.0-VL und 0,918 / 0,939 bei v6.0-VL — und die v6.0-VL-Karte gibt offen zu, dass die Zugewinne aus Daten statt aus Tiefe kamen, und dass die 10 % der Fragen, die zu Layer 32 gehen würden und bei 16 oder 20 stoppen, der Bereich sind, in dem die Tiefenpolitik noch rät. Beim Reranking ist noch mehr zu erreichen: Die eigene Retrieval-Reihenfolge von hippo-memory erzielt 0,484 R@1 und liegt weiterhin vor den 0,308, die das Modell bei v3.0 erreichte, eine Zahl, die das Projekt seitdem nicht mehr erreicht zu haben beansprucht. Die RL-Evidenz ist ein Seed, und v3.0 „hat selbst keine passende SFT-Kontrolle.“ Die Trainingskorpora und Policy-Entwicklungssets sind nicht öffentlich, daher können die Stufen nicht allein aus dem Repository erneut ausgeführt werden, und der Reranking-Korpus-Builder — etwa 96 GB Speicher — wurde nicht von Anfang bis Ende erneut ausgeführt.

Traktion, am selben Tag abgelesen: 73 Stars, 5 Forks, 0 offene Issues, 7 GitHub-Releases. Diese Zahlen ändern sich täglich, und ein Repository, das drei Wochen alt ist, ist kein etabliertes Projekt, unabhängig von seiner Release-Kadenz. Die ehrliche Zusammenfassung ist, dass RSI-Jev eine der besser nachvollziehbaren Forschungsbemühungen in dieser Ecke des Feldes ist – eine Kette datierter, gemessener, manchmal verlierender Releases, bei denen die Suche zusammen mit den Bewertungen veröffentlicht wird – und eine der am wenigsten unabhängig überprüften, da fast jede Zahl auf dieser Seite aus eigener Quelle stammt und keine externe Stelle einen Benchmark-Vergleich mit dem kommerziellen Modell durchgeführt hat, mit dem er kompatibel ist.

Worauf es zu achten gilt, ist nicht die nächste Veröffentlichung – denn bei dieser Taktung wird es innerhalb von Tagen eine geben –, sondern ob irgendetwas außerhalb des Projekts beginnt zu messen. Die zwei Dinge, die das Bild verändern würden, sind ein unabhängiger Benchmark-Lauf auf den veröffentlichten Checkpoints und ein Vergleich von Entscheidungsmodellen, der sowohl das offene 4B als auch TypeSafes gehostetes Modell durch ein und dieselbe Testumgebung schickt. Beides gibt es heute nicht. Bis eines davon existiert, besteht die nützliche Art, eine Punktzahl wie 46.24 zu lesen, darin, sie als eine gut dokumentierte Behauptung eines Projekts zu verstehen, das seine Vorhersagen im Voraus registriert und die gescheiterten Versuchsarme ausliefert – was eine stärkere Beweiskette ist als bei den meisten und dennoch kein Ergebnis eines Dritten.