# Jev's Architecture Unmasked Navigation: [[sources/_index]] | [[index]] ## 出典情報 - **タイトル**: Jev’s Architecture Unmasked - **著者**: Archer Hume - **媒体**: archerhume.com - **公開日**: 2026-09-16 - **URL**: https://archerhume.com/posts/jevs-architecture-unmasked - **分析対象バージョン**: `jev-1.13.0` (TypeSafe / Metaculus) ## 概要 独立研究者 Archer Hume が、10,000 件を超える API コールによる厳密なブラックボックス・プロービング（制御実験、レイテンシ計測、トークナイザ解析、順列・トークン注入テスト、較正性評価）を通じて、TypeSafe / Metaculus が提供する意思決定特化型モデル「[[Jev]]」（System 1 モデル）の内部アーキテクチャを解明したリバースエンジニアリング分析記事。 X（旧 Twitter）等で流布されていた「小型モデルの蒸留」「単なる投機的デコーディング（Speculative Decoding）」「拡散モデル（Diffusion）」といった推測を実証的データに基づいて完全に否定し、**事前学習済み因果的 Transformer バックボーン（おそらく MoE）のコンテキスト計算（Prefill）を共有し、質問ごとに独立したアテンション枝を展開して最終層の数値 Readout Head から直接クラス確率を出力する**という、計算グラフと意思決定タスクを高度に一致させたシステム構造を特定した。 ![[_attachments/jevs-architecture-unmasked/fig01-decision-model.png]] Jev の意思決定モデル計算模式図。メッセージ（State）が共有状態として一度だけエンコードされ、各質問グリッドが共有状態へアテンションを払い並列実行される。質問同士は互いに遮断され、テキスト生成を行わず Readout Head が直接 answer probabilities を出力する。(Source: [Jev's Architecture Unmasked](https://archerhume.com/posts/jevs-architecture-unmasked)) --- ## Jev アーキテクチャの7つの構成要素 ### 1. デコードループを排除した Readout 構造 (End inference with a readout) - **テキスト生成の完全な排除**: - 通常の LLM はプロンプト処理後に1トークンずつ予測して自己入力する逐次生成（デコードループ）を行う。一方 Jev はプロンプト処理（Prefill）直後に推論を終了し、最終隠れベクトル $h$ から直接線形変換とソフトマックスによって選択肢確率を出力する： $z = Wh + b, \qquad p_i = \frac{e^{z_i}}{\sum_{j=1}^{K} e^{z_j}}$ - 生成文のスペリングや JSON フォーマット生成は一切ニューラルネットワーク内で行わず、推論完了後に通常のアプリケーションコードがシリアライズする。 - **`output_tokens` の実態**: - API が返す `output_tokens` は請求・課金用の計算値であり、生成トークン数ではない。質問 ID や固定オーバーヘッド（共通 4 トークン ＋ 1 回答あたり 15 トークン）から機械的に算出されており、選択肢が 2 件から 200 件（1,911 output tokens）に増えてもレイテンシは全く変化しない。255 選択肢で 2,714 output tokens を記録しても、秒間トークン生成速度の指標としては意味をなさない。 ### 2. 共有状態と質問の完全な振る舞い分離 (Share the state, isolate the questions) - **計算の再利用（KV キャッシュ共有）**: - 長大な共通テキスト（State: 障害レポート、カスタマー問い合わせ等）のトークン数を $S$、質問数を $Q$ とすると、通常の個別リクエストでは $Q \times S$ の計算コストがかかる。Jev では State の表現構築（Prefill）を 1 度だけ行い（$S$ トークン）、全質問グリッドがその KV キャッシュを参照するため、重複計算が完全に排除される。 - **質問間の情報遮断実験**: - 一方の質問（Sibling Question）に秘密コード（`ZEBRA-7741`）を埋め込み、隣の質問からそれを読み取れるかテストしたところ、報告確率は `0.00` となり完全に遮断されていた。同じコードを State に移動すると確率は `0.90〜0.92` に跳ね上がり、State のみが各質問に共有されていることが実験的に証明された。 - **スケーリング特性**: - 質問数が 1 件から約 100 件に増えるまで、サーバー処理時間（Median server time）はほとんど増加しない（約 60〜80 ms 前後でフラット）。100 件を超えると線形に増加する。 ### 3. 因果的バックボーン (A causal backbone) - **基盤モデルの推測**: - MMLU-Pro で 84.6% という高いスコアを達成していることから、ゼロから訓練した小型モデルではなく、フロンティア規模の事前学習済み言語モデル（Causal Decoder）をベースにしていると推定。双方向エンコーダ（BERT 型）への変換はプレフィックスキャッシュの恩恵を失うため可能性が低い。 - **トークナイザ解析**: - 公開されている 192 種類のトークナイザと照合した結果、完全一致するものは存在しなかった。OpenAI の `o200k` と語彙体系が極めて近いが、数字を 1 桁ずつ分割する点やマージルールが異なる。Qwen のトークナイザが最も近く（415 件中 348 件一致）、既存モデルの語彙置換または継続事前学習・蒸留が示唆される。 - **選択肢の配置位置と参照実験（Reference card 実験）**: - 選択肢リストの末尾に参照情報（カード）を配置した場合、先頭や中間に置いた場合よりも正解率が向上（末尾配置では 16/16 正解、平均確率 0.88）。決定位置が選択肢全体を因果的に読み取れる構造であることが確認された。 ### 4. 選択肢間の文脈相互作用 (Let the options interact before choosing) - **独立ロジット仮説の棄却（無関係な選択肢の追加実験）**: - 4 つの選択肢（bank, provider, customer, unknown）に対し、全く無関係なダミー選択肢（`weather: Bad weather caused it`）を追加する 10 ブロックの無作為化実験を実施。 - 各選択肢が独立にロジットを算出して同一のソフトマックス温度で正規化されるなら、分母が相殺されて既存選択肢間のオッズ比は不変であるはずである： $\frac{p(\text{customer})}{p(\text{unknown})} = e^{z_{\text{customer}} - z_{\text{unknown}}}$ - しかし実験結果では、ダミー選択肢の追加により対数オッズ比が $+0.38$ から $+0.11$ へ有意に減少（平均変化量 $-0.28$、95%信頼区間 $[-0.36, -0.19]$）。 - これにより、Jev は選択肢を個別にスコアリングしているのではなく、**選択肢リスト全体をひとつの文脈として相互にアテンションさせた上で決定を下している（Listwise Representation）** ことが実証された。 - **Readout Head の構造仮説**: - 候補として (1) 最終位置の表現からスロットごとにスコア化する固定スロット方式（API 上限が 255 件であることと整合）、(2) 各選択肢の最終隠れ状態と決定トークン表現を比較するポインタ方式（Pointer-style scorer）の 2 系統が挙げられている。 ### 5. 確率較正を促す訓練目的 (RLCD: Reinforcement Learning for Calibrated Decisions) - **適切なスコアリングルール (Proper Scoring Rules)**: - TypeSafe は学習手法を RLCD と呼称。単なる流暢なテキスト生成の報酬ではなく、Log loss や Brier loss などのプロパースコアリングルールに基づく目的関数で訓練され、確信度の過不足がない予測分布を学習させている。 - **実測較正性 (Calibration Data)**: - MMLU 1,200 問のサンプル評価において、Expected Calibration Error (ECE) は **0.0313** と極めて優秀な較正性を示した（Reliability diagram 上で対角線にほぼ一致）。 - 新規生成された算術問題（Fresh Maths）でも、3 桁の掛け算（正解率 86.7%、平均確率 0.83）と 2 段階の文章題（正解率 32.0%、平均確率 0.30）の間で難易度に応じた適切な信頼度の低下が観測された。 - **API `confidence` フィールドの正体**: - API が返す `confidence` はニューラルネットワークの追加予測値ではなく、単に出力確率分布から計算された線形変換指標に過ぎない： $c = \frac{p_{\max} - 1/K}{1 - 1/K}$ - これは一様分布からの乖離度を示す指標であり、確率そのもの（predictive distribution）と混同してはならない。 ### 6. スパース容量 (Sparse capacity: MoE) - 30,000 トークンの処理時間を約 160 ms で完了させている。高密度（Dense）70B モデルを 8×H100 で動かした場合に約 1 秒かかることと比較すると、活性化パラメータが約 10B 程度の MoE（Mixture-of-Experts）を採用している蓋然性が極めて高い。 - Prefill 専用の推論基盤では、逐次デコード時のメモリ帯域律速や肥大化する KV キャッシュと重みの競合が生じないため、MoE アーキテクチャの計算削減メリットを最大限に享受できる。 ### 7. バッチ型スケジューリング (Schedule branches as a batch) - 複数質問のサフィックス（Instructions + Options）は、独立したワークアイテムとして動的バッチング（Dynamic batching）され、GPU 上で並行処理される。 - 質問間の依存関係（会話履歴のような連鎖）がないため、会話型推論で生じる同期待ちやキュー滞留が発生しない。 --- ## 本検証が示唆するシステム設計上の意義 1. **意思決定タスクにおける LLM 推論パラダイムの転換**: - 分類、ルーティング、意図判定、トリアージ、リスク評価などのタスクにおいて、生成型 LLM に JSON 文字列を出力させてパースする運用は、不要な逐次デコード遅延、サンプリングの非決定性、フォーマットエラーのリスクを抱える。 - Jev のように「共有 Prefill ＋ 並列 Readout」に割り切ることで、レイテンシとコストを桁違いに削減できる。 2. **選択肢順序への鋭敏さ（Permutation Sensitivity）**: - 選択肢の順序を逆転させたプロービングでは、同一のチケットに対して確率が 0.84〜0.89 から 0.93〜0.96 へ変動する現象が確認された。実運用のポリシーで閾値（例: 0.9 以上で自動エスカレーション）を設ける場合、選択肢の順序バイアスを意識した評価や順列テストが必須となる。