RSI-Jevとは何か？Jev流の意思決定モデルを構築する自己改善ループ

RSI-Jevは、Jev流のSystem One意思決定モデルを構築するサードパーティのオープン研究プロジェクトであり、このページが扱うモデルはその4Bリリース、RSI-Jev v6.0-VL（2026-10-06付）です。これはShanghua Gao（@gasvn）によって書かれ、リポジトリの謝辞にはSufian（@SufianTA）がクレジットされており、TypeSafeのJevではなく、TypeSafe AIとも提携していません——プロジェクト自身のライセンス表記がまさにそう述べています。その根底にある発想は、一文で述べられるほど狭いものです。文書、チャット、画像について型付きの質問をする——はい/いいえ、k個から1つ選ぶ、ルーブリックで評価する——すると、1回の順伝播で各選択肢について較正された確率が返ります。何も生成されないため、費やす推論トークンはなく、実際に1つも費やされません。v6.0-VLはこのプロジェクトの最初のリリースではありません。12日間で7番目のリリースであり、この点を理解することが最も重要です。なぜなら、ここで有用な情報は、個々のチェックポイントではなく、この線の形そのものにあるからです。

これらすべての数字の前に一つ言っておかねばならない。それはどの数字にも日付を与えるものだからだ。v6.0-VLが列の先頭に立っていたのは、ちょうど一日だけだった。2026-10-07 07:56 UTC——今朝——プロジェクトはRSI-Jev v6.1-VLを公開した。これはv6.0-VLを、それぞれ重み0.5で平均化したもので、同じQwen3.5-4B-Baseに対して別のデータで2回目のファインチューニングを施したものであり、プロジェクトのDecision Index 0.3キットで50.98を記録するのに対し、v6.0-VLは同じキットで46.23だった。平均化の後に学習は一切行われていない。そのキャリブレーションはv6.0-VLより悪く、自身のカードにもそう書かれている。そのリリースは実在し、現行である。このページはそれについてのものではない。以下のすべての数値は、2026-10-06付のv6.0-VLのリリース記録から読み取ったものであり、その後変動したカウント——リリース数、実験数——については、このページはv6.0-VL時点での数値と、今日時点での数値の両方を示す。

RSI-Jevが何ではないかも、早い段階で述べておく価値があります。というのも、明らかな3つの想定のうち2つは誤っているからです。これは、今日、汎用APIを通じて呼び出せるホスト型製品ではなく、OrcaRouterによって提供されているものでもありません。当社のカタログにはrsi-jev idもshgao idも、そのモデルカードもありません。唯一あるのは、このプロジェクトがHTTP契約を模倣しているモデル、TypeSafeの商用Jevであり、当社はこれを typesafe/jev-1.13としてsystemoneエンドポイントで提供しています。この2つのうち、呼び出せるのは一方で、もう一方は自分でダウンロードして提供するものです。以下の内容はすべて、2026-10-07に読んだプロジェクト自身のリポジトリ、リリースカード、サービング文書に基づいており、数値が外部による測定値ではなくプロジェクト自身のものである場合、このページにはそれが誰のものかが明記されています。

それが実際に何をするのか

このプロジェクトは、自らを一行で「再帰的に自己改善し、Jev-styleのSystem Oneモデルを構築する研究システム」と説明しており、それが生み出す成果物は生成器ではなく決定器です。あなたはそれに状態——文書、チャットの文字起こし、トランザクション、そしてビジョン対応リリースでは最大4枚の画像——と、名前付き基準を伴う1つ以上の型付き質問を渡します。すると、各質問について、すべての選択肢の確率を返します。3つの質問タイプがこの空間をカバーしており、それらはTypeSafeのAPIが定義するものです：

• noul — 真偽の判定であり、単一の確率として返され、分布も信頼度の値も伴わず、参照の回答形式と正確に一致します。

• choice — ラベル付きの選択肢の中から1つを選び、完全な確率分布と信頼度統計とともに返されます。

• スコア — 順序付きルーブリックで評価し、レベルの確率で重み付けした0起点のインデックスとして返します。凡例と分布も付きます。

生成ステップが存在しないため、2回目のモデル呼び出しもサンプリングもありません。モデルがすでに読んだ文書についての判断は、構造上、低コストの操作です。そして、そのコストについてプロジェクト自身が述べている一文——「約10 ms」——は、現在のリリースではなく、その2B時代のものです。v6.0-VLの測定値はさらに下に示します。

所有権に関する2つの事実は、このページのどの内容よりも重要です。RSI-Jev は TypeSafe の成果物ではなく、TypeSafe はそれを推奨していません。ライセンスの記載は、全文を引用すると次のとおりです:「コード: MIT。重み: Apache-2.0（ベースモデルに準拠）。一部の画像トレーニングソースは非商用で、各モデルカードに記載されています。TypeSafe AI とは提携していません。」そして、この関係は一方通行です。このプロジェクトは Jev のワイヤフォーマットを意図的にコピーしており、そう明言しています。なぜなら、互換性のあるサーバーであることが狙いだからです。「Jev-style」は、プロジェクトが構築する種類のモデルを指す、プロジェクト自身の言い回しです。TypeSafe の Jev は別のクローズドな商用モデルであり、より短い名前で呼んでも両者が同じものであるわけではありません。

現在のモデルの内部：3つの出口を備えた4B Qwenタワー

RSI-Jev v6.0-VL は、Qwen3.5-4B-Base タワーを備え、そのタワーはファインチューニングされ、その上に学習済みの決定ヘッドが載っています。それがアーキテクチャの全体です — 専門家の混合も、ルーターも、第2のモデルもありません。ベースモデル全体を実行するため、そのパラメータ数は 4.69B であり、それより小さい何かではありません。3.57B は 32 個のデコーダ層に、0.64B はトークン埋め込みに、0.33B はビジョンタワーに、0.05B はメイン決定ヘッドに、0.10B は 2 つの早期終了ヘッドにあります。公開されたチェックポイントは自己完結型で、bf16 では 9.7 GB です。

3つの決定ヘッドが、ベースの層16、20、32に取り付けられており、それらは現在のリリースが知られているすべてを支える仕組みです。層12にある4つ目の出口は作られ、測定され、そして破棄されました —「層12の出口は、あらゆる比較で16からのカスケードに敗れており、パッケージには含まれていない」— そのため3つは出荷され、4つ目は出荷されません。出口は、それぞれの層の切り離されたコピーを読み取ります。これはプロジェクトが苦労して知った細部です。訓練中に出口が取り付けられていたトランク上でヘッドを再調整しても、深い層の精度は回復しませんでした。したがって、それらを切り離すことが深さを回復させたのです。

このプロジェクトを最も手っ取り早く誤読させるのは、ここにある1つの数字だ。v3.0まで（v3.0を含む）はすべてQwen3.5-2B-Base上の2Bモデルであり、それは系譜であって現在のモデルではない。v4.0-VLは2Bで、v5.0-VLはモデルを3Bに削減し、v6.0-VLは4Bだ。現在のRSI-Jevモデルを2Bと呼んでいるページは、3リリース分古い。

ループこそが実際のプロジェクトだ

モデルは成果物であり、構築されているのはプロセスだ。このプロジェクトは「研究を回しているループこそがAutoScientistsの次のバージョンだ」と述べている。AutoScientistsとは、ハーバード大学のZitnik研究室が発表した自己組織化エージェントチームシステムのことだ。そしてそれは、この一文が示唆するとおりに機能する。AIエージェントは仮説を提案し、自らの予測を登録する前にGPU時間を費やすことはない。実験を実行し、証拠がそう告げるときには自らのチャンピオンを引退させる。二つの数字がそれを具体的に示している。2026年10月7日時点で、リポジトリの見出しは「13日間で8リリース、v1.0からv6.1-VLまで」。v6.0-VL自身の2026年10月6日のリリース時点では「12日間で7リリース」とあり、そのいずれもがこのループによって訓練され、評価され、文書化されている。そして実験数は、このページのリリース時点では471だったが、今日は496——失敗も含め、そのすべてが書き残されている。どちらの数字もプロジェクト自身のものであり、どちらも動き続けている。

その規律があるからこそ、あの数字は意味を持つ。プロジェクトはそれを明快に列挙している。ヌルフロアは仮定されるのではなく実測される——対照と同一であることが証明可能なアームを、GPU時間を消費する前にオブジェクト同一性によって検証し、それによってそれらの間のばらつきはノイズフロアであり、そのばらつきより小さい差は結果とは見なされない。予測は実行前に登録されるので、自ら設定した基準を外したバージョンは、ひそかに作り直されるのではなく、失敗として出荷される。成果物は検証される。チェックポイントはディスクから再読み込みして再スコアリングされ、公開されるのは、そのトレーニング実行の設問ごとの予測を再現した場合だけであり、v1.0のチェックポイントはどちらもそれを1.0000で再現している。汚染は「主張されるのではなく確認される」。そして失敗も出荷される——プロジェクト自身のチャンピオンを倒したものも含めて。

コントリビューションとは何か、プロジェクト自身の言葉をコントリビューティングガイドから引けば：「ここでのコントリビューションは通常、パッチではなく計測である」。リリース済みの記録はスナップショットとしてではなく連鎖として保たれる——「versions/ はリリースごとに1枚のカードを、それらすべてを、main 上に永遠に保持する……その連鎖こそがプロジェクトだ」——だからこそ、古いリリースの数値は、後になってプロジェクトがそれらについて述べる内容と照合できるのであり、以下で論じる1つの訂正が、沈黙するのではなく可視になっているのである。

v6.0-VLが変えたこと：トークンではなく深さを費やす

現行リリースの仕組みは、effortという設定です。これは珍しいものを制御します。つまり、1つのリクエストがモデルの何層まで使用できるかです。ヘッドは3つの深さに位置するため、簡単な質問はレイヤー16で回答でき、難しい質問は32層すべてを実行できます。lowはレイヤー16で停止し、mediumは20で停止し、highは32で停止し、autoは、キャリブレーションされた確率がその出口の閾値を超える最初の出口で回答します。Decision Index サンプルにおけるリクエストあたりの中央値レイテンシは、1台の H200 の bf16 で測定して、23 ms（low）、27 ms（medium）、40 ms（high）、未設定のデフォルトでは40 msです。これらはプロジェクト自身のハードウェア上での独自の測定値であり、サービングドキュメントの GB10 の数値と混同しないでください。それは別のマシンです。

測定された autoの挙動が興味深い部分です：プロジェクトの15ベンチマークスイートでは、質問の20%はレイヤー16で停止し、46%はレイヤー20で、34%は32まで実行され、平均は32レイヤー中23.3です。単一の固定しきい値は平均20.9で、過停止は単一しきい値がもたらすものです。auto は品質の妥協ではありません。これは述べておく価値があります。なぜなら、通常、適応設定とはそういうものだからです：あらゆる設定の中で最高のスイート行（デフォルトの0.770に対して0.771）、最高のMMLU-Pro行（0.440に対して0.444）、最高の最終キャリブレーション（ECE 0.036に対して0.024）を記録します。唯一の場所は highが勝利するホールドアウトセットで、0.702 対 autoの0.696です。一部のタスクは深さとともに測定可能なほど悪化します — BANKING77は0.035、New Yorkerのキャプション照合は0.060 — だからこそ、エフォートレベルはサーバーが押し付けるルールではなく、呼び出し側が下す選択なのです。

これを実験ではなくリリースにした結果は、プロジェクトの公開 Decision Index 0.2.1 にあり、スコアは v5.0-VL の 38.38 から v6.0-VL の 46.24 へ、1 回のリリースで上がった。2026-09-28 付の公開ボードでは、これは 4B モデルおよびそれより小さいものの中で最高スコアで、全体では 71 件中 14 位。同じサイズで次に来るのは JPT-4B の 43.04 だ。この系統の以前のリリースは系譜上のものであり、現行モデルではない。v5.0-VL（2026-10-02）はモデルを 32 層のうち最初の 20 層に切り詰め、質問に答えがないときは「unknown」と言うようにした。v4.0-VL（2026-10-01）は画像を読み取る最初のものだった。そして v3.0（2026-09-28）は、強化学習が初めて役立ったリリースで、リストワイズランキング報酬 — 16 候補に対する NDCG@5 — によって、再ランキング R@1 を教師ありの親モデルに対して 0.192 から 0.308 へ引き上げ、その代償として評価スイート上で 0.0028 のコストを払った。ここがこのプロジェクトの強化学習の話の始まりであり、今では 3 リリース前になる。

数字を、それに付随する注意事項とともに

v6.0-VL の Decision Index 0.2.1 ヘッドラインは 46.24 で、これはスイートの全 150,759 リクエストが回答されたフル実行での値です。知識 28.8、言語 46.2、検索 55.5、ツール 65.8、芸術 37.1。15 ベンチマークのスイートは 0.770、ホールドアウトセットは 0.698、MMLU-Pro は 0.440、最終 ECE は 0.024、autoで。これらの数値と同じ呼吸で述べなければならない注意点が二つあり、それらがなければ数字は誤解を招くからです。

1つ目はスイートからの削除です。内部スイートのタスクopen_jev_oodは579件の学習行と重複していたため、その数値は不明な分だけ水増しされていました。v6.0-VL以降、プロジェクトはこれを含めないスイートを0.770として報告しています。v5.0-VLの0.764はこれを含んだ値であり、v6.0-VLのカードでは、そのリリースをこれ抜きで0.763として言い直しています。この2つの数値は比較可能ではなく、あえて比較するのであれば、言い直された0.763を使い、そうしていることを明示しなければなりません。ホールドアウトセット、MMLU-Pro、BBHには重複がなく、影響を受けません。関連する監査では、Decision Indexキットのテスト行のうち約1,000項目が学習コーパス内で見つかりました——ANLI 274、RouterBench-GSM8K 90、ARC 5、そしてラベルなしのBRIGHT/ToolRetクエリテキストで、キットの行のおよそ0.3%に当たります——これらを除いて再スコアリングしても、プロジェクトのサンプルではインデックスは最大0.04しか動きません。これはv5.0-VLの記録に対する訂正であり、v6.0-VLのカードで公表されており、プロジェクト自身の汚染ルールが数値を1つ犠牲にしたことになります。

二つ目は、これが誰のベンチマークなのかという点です。Decision IndexはRSI-Jev自身の公開ボードであり、第三者の判定ではありません。そして46.24はそのボード上のスコアです。これはTypeSafeが公表したものとは比較できません。なぜなら、この二つの数値は同じハーネスから出たものではなく、RSI-JevとJev 1.13の間で独立した直接対決を行った人は誰もいないからです。言えるのは数値的なことではなく構造的なことです。一方はベンダーのエンドポイント上にあるホスト型商用モデルで、もう一方は自分でダウンロードして提供するチェックポイントです。

さらに2つの文脈情報がこのセットには伴う。プロジェクトは明確にしている。「15のベンチマークのうち10は何らかの形で訓練データを提供しているので、これらの数値はどれもゼロショットではない」と。ホールドアウト集合は、ホールドアウトされた比較対象であり、それ自体も「訓練からホールドアウトされているのであって、探索から封じられているわけではない」。そしてv6.0-VLは自系列で97本のアームを実行した——4つのデータ監査を除けば93本——それが、その指標で7.86ポイントの跳躍を生み出した探索の規模である。

それは Jev のワイヤーフォーマットを採用しており、呼び出し側が知っておくべき 4 つの違いがある

互換性サーフェスは、このプロジェクトが現在の形で存在する理由である。同じリクエスト形状（{state, model, questions}）、同じ判定基準形状を持つ同じ3つの質問タイプ、同じ回答形状、リクエストあたり同じ1～64問、同じエラーエンベロープ、そして同じ信頼度統計量 — ピーク、(K · p_max − 1) / (K − 1)、0..1 にクランプ。そのサーフェスに関するプロジェクト自身の主張は「Jev に対して書かれたものはすべて、変更なしでこれに対しても動作する」というものであり、サーバーは何がコピーされ、何がコピーされないかを文書化している。これはその主張よりも有用である。

• プロンプトと読み出しは、それ固有のものである。 RSI-Jev は、訓練済みの読み出しヘッドを備えたベースモデルであり、訓練時と同じエンコーダとともに提供される。参照元のプロンプトを使うと「モデルを訓練分布から外してしまう」からである。互換性の界面となるのはワイヤ契約であり、プロンプトではない。

• オプションキーはモデルに表示されます。参照実装ではこれらが非表示にされるため、キーの名前を変更してもそこでは回答が変わり得ないことが証明できます。ここでは変わり得るため、サーバーはこれを正直に次のように報告します: option_keys_visible_to_model: true。

• Criteria は文字列または null でなければなりません。 構造化された criterion（オブジェクト）は 422 で拒否されます。どのリリースもその形式でトレーニングされていないためです。リファレンスが受け入れるリクエストがここでは実行されない唯一の箇所が、ここです。

• 何も切り捨てられません。サービングでは最大32,768テキストトークンに画像分の予算を加えた量まで扱え、それを超えるリクエストは暗黙に切り捨てられるのではなく、その旨を示す422で拒否されます。古いカードに載っている2,048トークンという数字は、モデルが学習した長さであり、サービングの上限ではありません。2,048への無言の切り捨てを現在の挙動として説明するのは誤りです。

選択肢数はサービング側に大きく有利な差がある。1質問あたり最大5,120個（RSIJEV_MAX_ANSWERS）で、学習時の160個、参照実装が認める64個とは桁が違う。160をサービングの上限として引用しないこと。v6.0-VLの応答で継承されたのではなく新しい点が一つある。すべての回答が、どの層が回答したかをusage.depthで報告し、較正済み信頼度と併せて示すため、適応的な判断を事後に監査できる。画像は参照実装にはない拡張である。1リクエストあたり1～4枚で、base64データURLとして扱われ、状態はそれぞれをリテラルマーカーで参照する。

読者が実際にそれを実行できる箇所と、そうでない箇所

RSI-Jev はダウンロード提供されています。このプロジェクトは独自のサーバーを同梱しており、それがその Jev 互換 API を提供します。文書化された手順は、リポジトリからの pip install に続いて、チェックポイントエイリアスと effort 設定を指定して serve コマンドを実行するものです。重みは Hugging Face の shgao 組織の下にあり、ベースモデルに従って Apache-2.0 で公開されています。ただし、プロジェクト自身が述べている未解決の論点が1つあります。画像学習ソースのうち5つは非商用または研究専用であり、「非商用データで学習された重みがそれらの条件を継承するかどうかは確定していない」という点です。コードは MIT です。

ハードウェアは制約ではない。このプロジェクトはHP ZGX Nanoで開発されており、それはHPとNVIDIAにクレジットされているNVIDIA GB10マシンだ。そしてサーバーは、あらゆるCUDA GPU上でも、Apple Silicon上でも、通常のCPU上でも動作する——最後のものについては、ドキュメントがGB10自体のArm CPUで単一の質問に733 msという値を付けている。つまり高速というより実用的だ。

これがしないのは、一般的なモデルカタログに掲載されることです。そしてここが、私たち自身の立場について正確に述べておくべき点です。RSI-Jev は OrcaRouter にはなく、ルーティング先となるモデルカードも存在しません。私たちが提供しているのは TypeSafe の商用版 Jev、typesafe/jev-1.13で、専用の systemone エンドポイント上にあり、OpenAI の chat-completions 形式ではなく /v1/systemone への POST でアクセスします。これはこのプロジェクトが実装しているものと同じリクエストとレスポンスの形式であり、その契約をコピーしたモデルによるものです。関係はそれだけです。両者は同じプロトコルを話し、私たちはその一方を提供し、あなたはもう一方を自分で動かします。すでに私たちのキーをお持ちであれば、Jev 1.13 の呼び出し形式は200以上のモデルを0%のマークアップで利用できる単一のAPIにおける第一級のルートです（プロバイダーの定価がそのまま適用されるため、ベンダーの値下げはここでも当日に反映されます）。これは比較において、ある一つの点で重要です。このようなページは、まず商用契約を試し、それからオープンな4Bチェックポイントを自分で運用することが運用上の手間に見合うかどうかを判断できるなら、行動に移すコストが低いのです。

2026-10-07にRSI-Jevを読む方法

プロジェクトが公開する弱点は、その結果と同じくらい具体的であり、日付が重要である。v2.1の外部テストでは、モデルは順序付きの選択肢やルーブリックスコアにおいて、より深刻または高コストな選択肢に傾き、文書が回答できない場合に「不明」を選ぶことはほとんどなく、質問とその否定に対して一貫性のない回答をすることが判明した。その後のリリースでは、「不明」のケースにデータを向けた — KoBBQ unknown-when-ambiguousはv4.0-VLで0.891、v5.0-VLで0.932、v6.0-VLで0.918 / 0.939になった — そしてv6.0-VLのカードは、その向上が深さからではなくデータから来たこと、そしてレイヤー32に行き16または20で止まるであろう質問の10%が、深さポリシーがまだ推測しているところであることを率直に述べている。再ランキングにはさらにやることがある：hippo-memory自身の検索順序は0.484 R@1を記録し、v3.0でモデルが到達した0.308を依然として上回っており、プロジェクトはそれ以来その数字を縮めると主張していない。RLの証拠は1つのシードであり、v3.0は「それ自体にマッチしたSFT対照がない」。トレーニングコーパスとポリシー開発セットは公開されていないため、リポジトリだけから段階を再実行することはできず、再ランキングコーパスビルダー — 約96 GBのメモリ — はエンドツーエンドで再実行されなかった。

トラクション、同日に確認：スター73、フォーク5、オープンイシュー0件、GitHubリリース7件。これらは日々変動し、作成から3週間のリポジトリは、リリース頻度がどうであれ、確立したプロジェクトではない。正直にまとめれば、RSI-Jevはこの分野の一角では比較的読み解きやすい研究活動のひとつであり、日付入りで計測され、時に負けることもあるリリースが連なり、探索はスコアと並べて公開されている。そして、独立した検証が最も少ないもののひとつでもある。このページの数字はほぼすべてが自前のもので、外部の第三者も、互換性のある商用モデルに対してベンチマークしていないからだ。

注目すべきは次のリリースではない。このペースなら数日以内に一つ出るからだ。そうではなく、プロジェクトの外の何かが測定を始めるかどうかだ。状況を変える二つのものは、公開されたチェックポイントに対して実行される独立したベンチマークと、オープンな4BとTypeSafeのホスト型モデルの両方を一つのハーネスに通す決定モデル比較だ。今日、そのどちらも存在しない。どちらかが実現するまでは、46.24のようなスコアを読む有用な方法は、事前に予測を登録し、失敗した実験群も公開するプロジェクトによる、十分に文書化された主張として読むことだ——これは大半より強い証拠の軌跡であり、それでもサードパーティの結果ではない。