Jev的なDecision Modelの実現方式を分類してみる
JevはTypeSafe AI社からリリースされた意思決定のためのモデルです。その推論速度と汎用性の高さから注目されていますが、具体的なアーキテクチャは公開されておらず、モデルの再現を試みる取り組みも活発に行われています。
自分自身もJevそのものを使って遊ぶというより、その方式の解明や、それを通したローカル環境での実現に興味があり、色々調べていました。 せっかくなので、見つけた実現方式を分類しながらまとめておこうと思います。
Jevとは
Jevは意思決定モデルとして、背景情報であるState、そのStateにおける質問群Questions、これらの質問に対する回答の選択肢Candidatesを自然言語で与えると、モデルが選択した回答を確信度（Confidence）付きで返すモデルです。 この回答は、従来のLLMのように1トークンずつ推論するdecode過程を経ずに行われるとされています。 また、複数の質問に対してもその回答時間はあまり増加しないともされています。
これらの特徴により、複雑な背景情報や高度な推論が必要とされず、かつ、即時性が求められる意思決定の場面への適用が考えられます。 加えて、LLMのように自然言語で幅広いタスクを扱え、タスクごとの追加学習なしで導入できるという汎用性の高さも注目すべきところです。
以下では、このような要件を再現するためのいくつかの取り組みを分類していきます。
分類について
このエントリでは、実現方式を大きくは「既存のLM headをそのまま利用する方式」と「潜在表現から専用のHeadを学習する方式」の2系統に分類しています。 それぞれ、Direct Logit型、Decision Head型と呼ぶことにします。 特に、Decision Head型の方はいくつかの派生があり、候補の処理方法や複数質問の並列化方法がそれぞれ異なるため小分類を示します。
Direct Logit型
Jev再現実装として最初に想起されるのは、学習済みのLLMに対してState/Question/Candidatesを渡し、prefill過程を経て得られた次トークン用の語彙全体に対するlogits（以下、語彙logits）を用いる方式です。 通常の推論ではこの語彙logitsを素として次の1トークンの選択を繰り返すdecode過程が発生しますが、プロンプトを工夫して、回答候補を1トークンで識別（例えば、A: chicken、B: beefの、A/B）できるようにするだけで、decode過程を省略して候補を選択できます。 これだけであれば構造化出力のdecode部分を省いたものと考えられますが、この方式では、候補に対応する種類数のトークンのlogitを用いてsoftmax操作を実行することで、候補のスコアも求められます。
この方式での再現実装としては、以下が挙げられます。
この方式の利点はなんと言っても、学習済みのオープンウェイトモデルをそのまま利用できる点だと思います。実際に、Jev対応forkでは、様々なモデルをそのままJevっぽく振る舞わせることができるようになっています。 大きなモデルの知識量や指示追従性能の恩恵に預かることができるので汎用性も高いと言えそうです。
一方で、複数質問への対応は、バッチ推論での解決です（State部分のKVキャッシュの共有などによる冗長計算の削減の仕組みなどは提供されていました）。 この課題へのモデルのアーキテクチャ水準での解決策として、拡散推論モデルであるDiffusionGemmaなどを使った並列回答が提案されています。 推論サーバーであるvLLM上でこの機能の実装提案では、質問や回答欄を初期canvasとして用いて、canvas中の全トークンに対して並列推論した結果のうち、回答欄に対応するトークンのlogitから選択結果を得ます。 ただし、手元で試した中では、canvas中の全てのトークンが推論対象であったり、初期canvasのランダム性に依存して回答が変動し、単純にノイズを取り除くためのラウンド数を増やしても安定するとは限らなかったです。
なお、この方式での選択結果のスコアは、どのtokenを次に出すかの相対比率であり、その回答が正しい確率としてキャリブレーションされた値ではないことにも注意する必要があります。
Decision Head型
次に、潜在表現から専用のHeadを学習する方式について整理します。 この系統では、潜在表現を作る方式にBERTなどのEncoder型のモデルを使うか、GPT系のDecoder型のモデルを使うかで分類してみました。
Encoder系
潜在表現の獲得のため自然に採用されるのは、事前学習済みのBERTやRoBERTa、ModernBERTといったEncoder系のモデルであろうかと思います。 Jevの再現実装は、これらのモデルから得られる潜在表現ベクトルを入力とする分類用のヘッドをつけ、Jevの想定するState、Questionと、回答の組でそのヘッドをファインチューニングする方式が考えられます。 元々、多肢選択問題にも利用されており、各選択肢に対応するスコアも出力することができるので、入出力の形式の観点からは、Jevらしさは高いと思えます。
この方式による再現実装としては、modernbert-ja-310m-jevが挙げられます。 この方式での再現実装は、蓄積されてきたBERTとファインチューニングのやり方が踏襲できること、モデルのパラメータ数が（近年のLLMモデルと比べると）少ないことによる、推論速度をはじめとする取り回しの良さが利点です。
しかしながら、パラメータ数の少なさに加え、チャットやエージェントを想定したモデルのような指示追従能力を前提にできないこともあり、それを補うためのタスクごとのファインチューニングが必要となり、汎用性が低下します。 また、候補ごとにState/Question/Candidateの組で推論するため、質問や候補数に応じて計算量は増加します。 もちろんバッチ推論による並列化は可能ですが、候補ごと（または工夫により質問ごと）の計算という構造自体は残ります。
この計算量の課題に対して、layaは、全ての候補を一つの系列で入力し、各候補の潜在表現を得ることで解決を図ります。
layaでは、[CLS] <type> instructions [SEP] [MASK] opt0 [MASK] opt1 ... [SEP] state [SEP]のように、候補ごとに[MASK]トークンを配置し、それらのトークンに対応する潜在表現の一覧を分類器に渡します。
なお、この配置であっても、双方向のアテンションであるので、各候補のMASKトークンには質問や候補の内容も反映されています。
分類器は、比較的複雑で、2層のTransformerが組み込まれています。
また、ベースとなるモデルはModernBERT-largeを、このためにファインチューンしているようです。
さらに、回答確率がキャリブレーションされることを目標としたRLCDによる学習も採用しています。
Decoder系
最後に潜在表現をQwenなどのDecoder系のモデルから得る方式です。
kevでは、<state> state <q> question <opt> opt0 </opt> <opt> opt1 </opt> ... <decide>のように、State、Question、各Candidateを特殊トークンで区切って1系列に配置します。
そして、各候補末尾の</opt>に対応する潜在表現と、全候補を読み終えた<decide>に対応する潜在表現を取り出し、分類器で比較します。
なお、この特殊トークンは追加導入ではなく、Qwen系モデルなどであまり使われていないとされる<|fim_prefix|>などを、別用途で利用しているようです。
Direct Logit型で重要な要素であった次トークンの語彙logitsを使わず、その手前の潜在表現から独自に分類器を構築するのはやや不思議ではありますが、以下の意図があるのではないかなあと考えています。
- 複数質問・候補との親和性: 各質問や候補に対応する特殊トークンの潜在表現を直接利用できるため、複数質問の並列処理や、A/B/Cのような回答ラベルに依存しない可変数の候補を扱いやすい。
- 分類器との親和性: 語彙logitをそのまま利用するのではなく、候補ごとの
</opt>と全候補を読んだ<decide>の潜在表現から、意思決定に適した比較方法自体を学習できる。
分類器自体は比較的単純で、<decide>と各</opt>の潜在表現をそれぞれ線形変換した後、その内積によって候補のスコアを計算します。
まとめ
本エントリでは、Jev的なDecision Modelを実現する方式について、Direct Logit型とDecision Head型として整理しました。
調査から、単純に「文章を生成せず、候補の中から選択する」だけであれば、既存のLLMの次トークンlogitを利用することで比較的簡単に実現できることが改めて分かりました。 並列回答についてもモデル側というよりは推論サーバー側の機構に移譲すれば良いと決めてしまえば、構成としてはかなり近づけられそうです。 Jevの魅力の一つは、自然言語で幅広いタスクを記述でき、ある程度の精度でそのまま利用できる汎用性にあると思います。その観点では、ある程度大きなオープンウェイトの汎用モデルを推論サーバー上で効率よく動かす方向が実用的に思えました。
一方で、Jevらしい複数質問への並列回答の計算効率や、Confidenceまで含めて考えると途端に方式が複雑になることも確認できました。 もちろん、利用量が十分に多くコストに見合うのであれば、Layaやkevのように用途に合わせた独自モデルを学習するのが最も良さそうです。一方、すべてのタスクごとにモデルやAPIを増やしていくのも運用上は大変かなと思います。その場合、モデル自体は共通化しつつ、利用側でjev-alignのように、実データや人間のフィードバックを使ってプロンプトを継続的に改善していく仕組みと組み合わせるのも面白そうです。
個人的には、Confidenceはもっと積極的に使われてもよい機能だと感じました。単に最も良い候補を選ぶだけでなく、「十分な確信がないので今回は採用しない」「人間に確認する」といった判断まで含められると、Decision Modelの使い道は広がるでしょう。このConfidenceを自前のモデルやDirect Logit型の仕組みでどう実現していくかは、今後も追跡していきたいと思います。
おまけ
今回出てきたTransformerの内部表現やAttention、潜在表現についてもう少し理解したい場合は、以前作った以下の資料も参考になるかもしれません。よければご参照ください。
本エントリは2026/09/20までに調べた内容を元に執筆しました。 読まれた時点では、各方式もさらにアップデートされたり他の方式も登場しているかもしれないことにご留意ください。
