文章を生成しない AI、Jev を 1 万回呼んで解剖した

日本語ナレーション · 720p · 字幕トラック付き · MP4

記事：1万回のAPI呼び出しで、Jevの中身を外側から描き出す

顧客からのクレームをどのチームに回すか、大規模言語モデルに判断を頼んだとします。返ってきたのは「90%の自信で支払いチームです」という答えでした。頼もしく聞こえますが、この90%はモデルが一文字ずつつなげて作った文章にすぎません。人がチャット欄に「9割くらい」と打ち込むのと本質は同じで、訓練で裏付けられた数字ではないため、後段のシステムに確率として渡すことはできません。

この問題を解こうとしているのがJevです。JevはTypeSafeが公開した「決定モデル」で、文章を作らずに判断だけを返します。出力するのは、訓練で調整された確率分布そのものです。公開直後からXには分析が数多く投稿されましたが、Archer Humeさんはその多くが的外れだと考えました。そこで約1万回のAPI呼び出しを使い、遅延の曲線、トークン数、選択肢の順序への反応などを調べて、Jevの構造を外側から推定しました。その結果が記事「Jev's Architecture Unmasked」です。

この記事では、動画に沿って彼の発見を整理します。先に断っておくと、結論の確かさはまちまちです。TypeSafeが公式に述べていること、実験で観測できたこと、作者の推測を、それぞれ区別して書きます。

Jevの使い方：共有状態と質問のリスト

JevのAPIに送るリクエストは2つの部分でできています。1つ目は「共有状態」で、すべての質問が共通で参照する前提の情報です。先ほどの例なら、クレームの本文がここに入ります。2つ目は答えてほしい質問のリストです。「どのチームに回すか」に支払い・口座・その他の選択肢を付け、さらに「緊急対応が必要か」をはい・いいえの2択で加える、といった形です。

Jevは文章の代わりに、質問ごとの確率分布を返します。たとえば支払い91%、口座6%、その他3%、緊急対応ははい42%、いいえ58%という具合です。数字なので、業務のコードはそのまま判断に使えます。支払いの確率がしきい値を超えれば自動で振り分け、緊急対応の確率が低ければ通常の流れに乗せればよいわけです。

TypeSafeの公式説明では、Jevの出力は「並列に求めた確率」であり、トークンを1つずつ順に生成する自己回帰とは違うとされています。扱える質問は、有限の選択肢からの選択、二者択一、順序付きの採点の3種類です。どれも出力の個数が決まっているので、一文字ずつ書く必要がありません。

文章を生成していない証拠

作者はまず、APIの応答にあるoutput_tokensという項目を調べました。名前からは生成したトークン数のように見えますが、二者択一の質問では、共有部分の4トークンに、答えごとの15トークンと、質問の識別子のトークン長を足した値にぴったり一致しました。ところがTypeSafeの文書には、この識別子は「下のモデルには送られず、推論にも関わらない」と明記されています。モデルが見てもいない文字列で値が変わるのですから、この数字は推論の後に応答を組み立てながら数えた請求用の数字だと考えられます。

さらに決定的なのが遅延の実験です。選択肢が200個ある質問（output_tokensは計算上1911）と、選択肢が2個だけの質問を比べると、返ってくる速さはほとんど同じでした。サーバーの処理時間は入力の長さに応じて増えるだけで、選択肢の数では変わりません。本当に答えを一文字ずつ書いているなら、200個の選択肢を持つ返事は必ず遅くなるはずです。

確率の出し方：readout（作者の推測）

TypeSafeは「並列に出す」と言うだけで、仕組みは公開していません。作者が推測した仕組みはreadout、つまり「読み出し」です。入力を処理し終えたモデルの最終層から隠れベクトルを取り出し、重み行列を掛けてバイアスを足し、softmaxに通します。softmaxは、一組の生の点数を合計1の確率分布に直す標準的な処理です。これで選択肢ごとの確率がそのまま得られます。二者択一なら、スカラー1つにsigmoidをかければ済みます。この流れには「次の単語」を選ぶ繰り返しがありません。

共有状態と、互いに隔離された質問

長い障害報告書を状態に置き、その後ろに50個の質問を並べたとします。質問を別々に処理すれば、モデルは同じ報告書を50回読み直すことになります。状態を一度だけ符号化し、各質問は自分の指示と選択肢だけを処理してから状態の表現を参照するようにすれば、計算量は大きく減ります。

トランスフォーマーは文章を処理する途中で、KV cacheと呼ばれるキャッシュを作ります。処理済みのトークンが残した中間情報の置き場です。作者の推測では、Jevはまず共有状態をKV cacheに符号化し、各質問は独立した「分岐」として同じキャッシュを使い回して、自分の分だけを追加で処理しています。

実験の結果はこの推測を支えています。質問を1つに固定して状態を長くしていくと、処理時間は数十ミリ秒から緩やかに伸び、約3万トークンでもおよそ218ミリ秒でした。逆に短い状態を固定して質問を1500個まで増やしても、処理時間は数百ミリ秒に伸びただけでした。質問ごとに状態を読み直していたら、この時間では終わりません。

もう1つの巧みな実験が「秘密のコード」のテストです。ある質問に「この依頼の秘密のコードはZEBRA-7741」と書き、別の質問で「さっきの秘密のコードは何か」と尋ねます。別の質問からはコードがまったく見えず、確率は0.00でした。同じ一文を共有状態に移すと、確率は0.90〜0.92に跳ね上がりました。どの条件も5回ずつ繰り返して同じ結果です。質問同士は隔離されていて、共有状態だけは全員が見えるということです。製品としても理にかなっています。「顧客が怒っているか」という質問が「担当チームはどこか」の判断に影響してはいけません。2つの質問は同じ証拠を見ながら、互いに干渉しないのです。

Jevには2つの上限があります。状態に質問を1つ足した「分岐」は約32768トークンまで、リクエスト全体は約65536トークンまでです。全体の上限では状態を一度しか数えないため、23000トークンの状態に5000個の質問を付けても収まります。作者はこれを、最大2の16乗トークンの詰め込み配列に、状態を先頭に一度だけ置き、その後ろに全部の質問を並べた形だと見ています。

選択肢は互いに影響し合っている

ここが特に面白い実験です。モデルが選択肢を独立に採点し、同じsoftmaxの温度で正規化しているなら、無関係な選択肢を足しても、元の選択肢同士の確率の比は変わらないはずです。分母が共通なので、割り算で消えてしまうからです。これは数学的に厳密に確かめられる予測です。

作者は、ある支払いの失敗の原因を銀行・事業者・顧客・不明の4つから選ばせる質問を用意し、そこに「悪天候のせい」という完全に無関係な5つ目を足しました。無作為化した区画を10組作り、各区画に元の版、選択肢を足した版、それぞれの対照群を入れています。指標のlog-oddsは、2つの確率の比の対数です。顧客対不明のlog-oddsは+0.38から+0.11に下がり、変化の平均は−0.28、10組すべてで低下しました。対応のあるt検定による95%区間はおよそ−0.36から−0.19です。

つまり選択肢は独立に採点されておらず、モデルは判断の前に選択肢全体を1つのまとまりとして読んでいます。作者は、Jevが選択肢のリスト全体を1つの文脈として扱うlistwiseという方式を使い、最後の位置で全部の情報を合わせてから分布を出していると推測しています。

これを裏付けるのが「参考カード」の実験です。選択肢の中に「状態＝琥珀色」と書いたカードを1枚紛れ込ませ、条件を満たす選択肢を選ばせます。カードをリストの最後に置くと16回すべて正解で、平均確率はおよそ0.88でした。先頭に置くと正解は12回、真ん中では11回に減りました。参考情報を共有状態に移すと48回すべて正解です。さらに、カードの値だけを琥珀色から藍色に書き換えると、文面をまったく変えていない前の選択肢の間で勝者が入れ替わりました。後ろの選択肢の内容が、前の選択肢の順位に影響する情報の通り道があるということです。ただし作者は、この実験には位置への敏感さがあり、背後の注意機構のマスク構造までは一意に決められないと断っています。

キャリブレーション：その確率は信じられるか

確率を出すこと自体より、その確率を信頼できるものにする方が難しい課題です。これをキャリブレーション（確率の校正）と呼びます。モデルがある一群の事例に80%の確率を付けたなら、実際の正解率も80%前後であるべき、という条件です。TypeSafeは自社の訓練法をRLCD（Reinforcement Learning for Calibrated Decisions、校正された決定のための強化学習）と呼んでいます。公式説明では、事前学習済みの言語モデルに追加の訓練を施し、「認知的に誠実な確率付きのSystem Oneの答え」を目指すとしていますが、具体的な手順は公開されていません。

作者は、多分野の大型ベンチマークであるMMLUから1200問を取り出して検証しました。最高確率を10個の区間に分け、区間ごとに実際の正答率が合っているかを見ます。全体の期待校正誤差ECE（予測と実際の正答率のずれを平均した指標）は0.0313で、なかなか良い数字です。ただし1200問のうち990問が0.9〜1.0の区間に集まっており、モデルは大半の問題にかなりの自信を持っています。

新しく作った数学の問題でも試しています。

掛け算と文章題では予測と実際がかなり近く、苦手な文章題では低い確率を付けて、自分の苦手をちゃんと分かっています。べき乗の剰余だけは例外で、明らかに自分を低く見積もっていました。

もう1つ誤解されやすいのが、APIが返すconfidenceという項目です。モデルが持つ「二段目の自信」のように見えますが、実際は計算式で求めた値です。選択問題では、最高確率をp_max、選択肢の数をKとして、confidence＝(p_max−1/K)/(1−1/K)です。選択肢3つで最高確率が0.8なら、confidenceは0.7になります。最高確率が一様分布よりどれだけ高いかを測るだけで、独立に訓練された信頼度ではありません。

骨格はMoEか（最も不確かな推測）

作者は、Jevの骨格がMoE（Mixture of Experts、混合専門家モデル）だと推測しています。全体のパラメータは多いものの、推論のたびに動くのは一部の専門家ネットワークだけで、どのトークンをどの専門家に任せるかはルーターが決めます。大きなモデルの知識量を持ちながら、毎回すべてのパラメータを回さずに済むのが利点です。

根拠は、Jevが入力を一括で読むprefillだけを行い、トークンを1つずつ出す復号をしないことです。prefillで足を引っ張るのは計算量で、MoEはまさにそこを節約できます。逆に、自己回帰の復号でMoEが抱える弱点、つまりメモリ帯域の制約や、結局大半の専門家が動いてしまうことは、Jevの使い方では表に出ません。数字もつじつまが合います。Jevは約3万トークンの入力をおよそ160ミリ秒で処理しますが、毎回全パラメータを使う700億パラメータの密なモデルは、業務用GPUのH100を8枚並べてもおよそ1秒かかります。動くパラメータが約100億のMoEなら、この速さに追いつけます。DeepSeek-V3、Qwen3、GLM-4.5など、最近の強い基盤モデルのほとんどがMoEであることも挙げています。

ただし作者自身、これが推測の中で一番あやふやな部分だと認めています。疎な専門家の存在は外側からは観測できず、専用のハードウェアなら密なモデルでも同じ速さが出るかもしれません。肝心なのは、ほかの推測がMoEという仮定に依存していないことです。密なモデルに置き換えても、共有状態、隔離された分岐、確率の読み出しは何も変わりません。

処理の割り振りと、結果のわずかな揺れ

最後の部品は推論エンジンです。作者の見立てでは、Jevは質問の分岐を対話の1往復ではなく、独立した仕事の単位として割り振ります。各分岐の後半だけを1つのバッチにまとめ、同じ状態の表現を共有しながら計算し、数値の結果を質問の識別子に対応づけてJSONで返すのはアプリ層のコードです。

実験では、まったく同じリクエストを繰り返し送ると確率がわずかに違い、同じリクエストの中で質問を重複させても答えが少しずつ変わることが分かりました。APIが完全に決定的だとは考えない方がよさそうです。ただしこれは、モデルが文章を生成したり標本抽出したりしている証拠ではありません。数値計算の精度、動的なバッチ処理、ルーティングの方針でも小さな揺れは起こります。

主張の確かさと、まだ分からないこと

この分析はjev-1.13.0という版を対象に、約1万回のAPI呼び出しで行われました。内訳は探索用の記録1029件、ベンチマークの記録6800件、そして数百回の個別実験です。すべてのリクエストと、個人情報を伏せた応答が公開されています。作者は主張の確かさにも線を引いています。確率を直接出すことはTypeSafeの公式な説明です。質問の隔離と選択肢の順序の効果は、観測できた振る舞いです。KV cacheの共有、因果的な注意、読み出しの具体的な形、MoEはその先の推測で、一段進むごとに確かさは下がります。

答えの出ていない問いもあります。Jevの基盤モデルが何かは分かっていません。トークナイザーは公開されている192種類のどれとも完全には一致せず、OpenAIのo200kに最も似ているものの差があります。最も近かったのはQwen系列で、415個の探索用文字列のうち348個で一致しましたが、それでも同じではありません。また、MMLU-Proでの84.6%という高い正答率と、新しく作った数学の問題での大きな落差が、訓練データへの混入によるものか、課題の構造の違いによるものかも分かりません。

分類、ルーティング、不正検知、内容審査のような判断の仕事にとって、文章を作らず確率だけを返すJevの考え方は注目に値します。今回の外部からの検証で、Jevが一文字ずつ生成していないこと、質問同士が隔離されつつ共有状態を参照していること、一方で選択肢同士は独立ではないことが見えてきました。ただし校正が効くのは訓練した分布の近くだけです。自分の業務に持ち込むなら、必ず自分のデータで確かめる必要があります。

動画では各節で「公式 / 実験 / 推測」を分けています。元記事：Jev's Architecture Unmasked。中国語版は 中文ページ。