Decision Modelの課題と強化学習

1. はじめに

最近、TypeSafeのJevをはじめとするDecision Modelをよく見かけるようになりました。文章を生成せず、選択肢ごとの確率を1回の計算で返すモデルです。LLMよりかなり速く安く呼べるということで、例えば以下のようなマリオのデモなどが公開されています。

デモの動画を見ると、モデルがジャンプのタイミングを1つずつ判断してゴールまで進んでいるように見えます。一方で、実際に入力を読んでみると、機械的に選べてしまう問いを、わざわざモデルに解かせているだけ、というものが多いことに気付きました。

そこで、以下の2点を試してみました。

• Decision Modelは、こうした盤面先の予測は可能なのか

• LLMと同じようにGRPOで強化学習して身につけさせられるのではないか

現状のDecision Modelはかなり誇大に見せられているのではないか、そしてDecision Modelでも複数ステップをまとめたGRPOができる、というのが今回の趣旨になります。

2. Decision Modelの誇大広告

2.1 Decision Modelとは

Decision Modelは、状態（state）と質問、選択肢（candidates）を受け取り、各選択肢の確率を返すモデルです。トークンを生成しないので1回の呼び出しが非常に速く、エージェントの細かい判断をたくさん任せる、といった使い方が想定されています。

TypeSafeの公式ブログでは、Jevは以下のように紹介されています。

同じ記事には、既存のLLMと比べて "similar levels of intelligence on System One tasks" を "two orders of magnitude faster" で実現した、とも書かれています。Doomをプレイするデモも載っていて、"real-time intelligence" と "code + AI" でできることを示すものだと紹介されています。

一方で、Decision Modelは回答速度と引き換えに、Reasoning能力を犠牲にしています。ここが今回のポイントになります。

2.2 実際に入っているプロンプト

はじめにで紹介したマリオのデモ（jev-mario）の見出しは "TypeSafe Jev plays Super Mario Bros." です。動画を見れば、モデルがジャンプのタイミングを判断してゴールしたと受け取るのが普通だと思います。

では、実際にモデルには何が渡っているのでしょうか。jev-marioのコードをそのまま動かして、Jevに送られるリクエストを出力してみました。

同じように、T-Rex（Chromeの恐竜ゲーム）のデモもあります。

T-RexのデモについてはREADMEに例が載っていたので、それも並べます。

選んだ先の予測は、コードが計算して入力に書き込んであります。

• 「run right」には0.6秒で死ぬと書いてある

• 他の選択肢には、何タイル進むか、その先で36通りのうち何通りが生き残るかまで書いてある

• 指示文にも「各選択肢には、それを選ぶと実際に何が起きるかが書いてある」と説明がある

• T-Rexに至っては、答えに「Best.」と書いてある

正直、ここまで書いてあればもはや機械的に選べる状態だと思います。それを、わざわざモデルに選択させているということです。

2.3 公開デモの入力を読む

マリオだけの話ではなさそうだったので、公開されているゲームのデモを3つ確認してみました。それぞれの見出しと、コードが先に計算していること、モデルに渡っている文面を並べると以下のようになります。

どのデモも、「その選択肢を選ぶと何が起きるか」はコードが先に計算して、文章やフラグにして渡しています。

ちなみに、「Best.」と書かれた選択肢を選ぶだけのT-Rexでも、Jevの選択がコードの最善と一致したのは 98.7% で、それとは別にコードが割り込んで操作した回数が5コースで28回ありました。（危険な答えの差し替えと、衝突前の緊急回避。）

2.4 小さく書いてあること

注意書きがないわけではありません。ただ、動画や見出しよりずっと目立たないところに書かれています。

TypeSafeの公式ブログでは、Doomのデモの「Nuance」という項に以下のように書かれています。

jev-marioのREADMEにも以下のように書かれています。

つまり、大きく見せているのは「知能」で、小さく書いてあるのは「AIを使わない方が上手い」「残っている仕事は11個の文の並べ替えだけ」ということです。

正直なところ、これは誇大広告と言って良いのではと感じました。難しい部分はコードが解いていて、モデルに残っているのは書かれた結果を読んで選ぶ仕事です。見せ方が実力を大きく上回っていると思います。

2.5 コードが結果を書かないとどうなるか

では、コードが結果を書かなければどうなるのでしょうか。jev-marioには、結果を書かずに状態の要約だけでJevに操作させた記録（Direct control）もあります。比較対象は、同じ情報を使うif文のルールと、「右ダッシュ＋ジャンプ」を押し続けるだけのコードです。1-1でそれぞれがどこまで進んだかを並べると、以下のようになります。

コードが結果を書かないと、Jevはif文のルールにも、ボタンの押しっぱなしにも劣ります。

3. ViZDoomでの検証

3.1 検証概要

自分でも別のゲームで確認してみます。使ったのはViZDoomのPredict Positionというシナリオです。（公式のデモと同じDoom系のゲームです。）

• 壁ぎわを動く敵を、ロケット1発で倒す

• ロケットは届くまでに時間がかかるので、敵の動く先を狙う必要がある

モデルに渡すのは、直近4回分の敵の位置（画面上のbbox）と自分の向きを書いたJSONと、4つの選択肢（左を向く / 右を向く / 撃つ / 待つ）です。

Jev（`typesafe/jev-1.13`）に対して、以下の条件を比較しました。評価は試験用の128エピソードで、確率が最大の選択肢を選ばせています。

• Jev（コード補佐なし）：状態と4つの選択肢だけを渡す

• Jev（コード補佐あり）：コードが各選択肢の結果（当たるか外れるか）を先に計算して、選択肢に書き込んでから渡す

• Jev（コード補佐あり＋読み方の説明）：上記に加えて、書き込みの読み方を指示文で説明する

• コードのみ：Jevを使わず、「当たる」と書き込まれた選択肢をそのまま選ぶ

• ランダム：4つの選択肢からランダムに選ぶ

測定に使ったコードはこちらです。（🔗）

3.2 結果

まず、同じ場面（同じシード）でのJevのプレイです。左がコード補佐なし、右がコード補佐ありです。（記録した操作を再生したもので、約1.4倍速。黄色の印は敵の位置で、説明用に描き足しています。）

モデルに見えている選択肢は以下のように違います。右端の数字がJevの返した確率です。

128エピソードでの結果は以下のようになりました。

コード補佐なしでは 0/128 で、ランダム（12/128）より下でした。Jevは全判断の 99% で「撃つ」を選んでいます。このゲームは開始から撃つボタンを押し続けると発射されないので、110回は1発も撃てずに時間切れです。（発射できた18回もすべて外れ。）

コード補佐ありだと 112/128、読み方を説明すると 126/128 まで上がります。ただ、コードのみでも 126/128 で、Jevが成功したのはすべてその中のエピソードでした。つまり、モデルを挟んで増えた成功は1回もありません。

3.3 Snakeでの確認

ロケットが当たるかどうかは、ゲームの物理を知らないと分からないという見方もできます。そこで、ルールがすべて分かっているSnakeで、質問の深さを3段階に分けて聞いてみました。各200問で、正解は「はい」と「いいえ」が半々です。（🔗）

• 読めば分かる判断：そのマスはヘビの体に含まれるか

• 1手先の予測：その向きに動くとぶつからないか

• 5手先の予測：動いた後、さらに5手動けるか

例えば、以下のような盤面と質問です。（盤面は文章で渡しています。）

比較として、LLM（DeepSeek-V4-Pro）にも同じ質問をしています。ReasoningありとReasoningなしの2通りで、プロンプトは同じまま、APIのReasoningの設定だけを切り替えました。

Jevは、読めば分かる判断は全問正解ですが、1手先の予測になるだけで 63.5% に落ちます。数行のコードなら100%の質問です。

DeepSeekは、Reasoningありだと1手先で 100%、5手先で 99% と当ててきます。面白いのは、同じモデルでもReasoningなしにすると、1手先で 51%、5手先で 50.5% と、ランダム選択と変わらなくなる点です。

3.4 ここまでのまとめ

結果から言えそうなことは以下の通りです。

• Decision Modelは、入力に書いてあることを読んで選ぶのは得意

• 選んだ先に何が起きるかは、書いてもらわないと読めない（書かなければif文やボタン押しっぱなしに負ける）

• 差を作っているのは「LLMかどうか」よりReasoningの有無

2章で見たデモの中身と合わせると、やはり現状のDecision Modelの見せ方は誇大広告と言って良いと感じました。難しい部分はコードが解いていて、モデルに残っているのは書かれた結果を読んで選ぶ仕事です。それは数行のコードでもできてしまいます。

Decision Modelには考える場所がないので、選んだ先のことは「入力に書いてもらう」か「重みに覚えさせる」かのどちらかになります。デモは前者をコードでやっています。では後者はできないのか、というのを次に試します。

4. Decision ModelをGRPOで強化学習する

LLMのエージェントでは、タスクの成否から学ぶ強化学習（GRPO）が普通に使われるようになってきました。同じことがDecision Modelでもできるはず、というのがここでの考えです。

ちなみに、Jev自体も強化学習で学習したと紹介されています。（公式ブログでは Reinforcement Learning for Calibrated Decisions、RLCDと呼ばれています。）ただ、具体的なやり方は公開されていません。コミュニティでもRLCDのやり方が色々と試されていますが、これという方法はまだ定まっていない認識です。今回の内容は、こういう強化学習のやり方もできる、という1つの例として見ていただければと思います。

4.1 LLMのGRPOとの対応

やることはLLMのGRPOと同じです。置き換えは以下の2つだけです。

• 1つの行動：次のトークン → 候補からの選択（今回は4択）

• 1本の軌跡：1つの回答 → 1エピソード（20〜30回の判断）

報酬はエピソードの最後に1つ（当たれば1、外れれば0）で、それをそのエピソード中のすべての判断に配ります。複数ステップの判断をひとまとめにして、最後の成否で全部を更新するイメージです。

式で書くと以下の通りです。i は同じシードの16回のプレイ、t はその中の判断、r_i はそのプレイの成否、ε は 0.2 です。（元のモデルから離れすぎないためのKLの項は入れていません。）

$$A_i = \frac{r_i - \mathrm{mean}(r)}{\mathrm{std}(r)}, \qquad \rho_{i,t} = \frac{\pi_\theta(a_{i,t} \mid s_{i,t})}{\pi_{\mathrm{old}}(a_{i,t} \mid s_{i,t})}$$

$$L = -\frac{1}{N} \sum_{i,t} \min\left( \rho_{i,t} A_i,\ \mathrm{clip}(\rho_{i,t}, 1-\varepsilon, 1+\varepsilon), A_i \right)$$

4.2 実装

実装の中心はかなりシンプルです。（🔗）

組の中での相対評価

def group_advantages(rewards):       # 同じシードの16回分の成否（1 か 0）
    if min(rewards) == max(rewards):
        return None                  # 全部当たり・全部外れの組は学習に使えない
    mean, std = statistics.mean(rewards), statistics.pstdev(rewards)
    return [(r - mean) / (std + 1e-8) for r in rewards]

損失（PPOと同じ切り詰め）

def clipped_loss(new_logp, old_logp, advantages, clip=0.2):
    ratio = (new_logp - old_logp).exp()   # 判断ごとの確率の比
    return -torch.minimum(ratio * advantages,
                          ratio.clamp(1 - clip, 1 + clip) * advantages)

Decision Modelは選択肢ごとに「状態＋質問＋選択肢」を計算するので、そのままだと学習がかなり重いです。そこで、状態と質問は1回だけ計算し、選択肢がその前半を共有するようにしました。1判断あたり約1,950トークンが約530トークンになります。（🔗）

4.3 検証概要

JevはAPIでしか使えないので、同じ型の公開モデル NanoJev（Qwen3-0.6Bに判断用のヘッドを付けたもの）で試しました。公開の重みはPredict Positionを128回中27回しか解けません。入力は3章の「コード補佐なし」と同じです。

比較したのは以下の通りです。

• SFT：このゲームを強化学習済みの別モデルを手本にして、その操作を正解として学習（512エピソード分、6,788個の判断）

• GRPO：手本なし。同じ512個のシードで自分にプレイさせ、当たったかどうかだけで学習（1ステップは16シード×16回＝256エピソード）

• SFT → GRPO：SFTが頭打ちになった重みから、GRPOを続ける（GRPO単体とは条件が違い、別のシード1,600個を使っています）

評価は、公開されている試験用128エピソードと、学習に使っていない512シードの計640エピソードです。実行環境はA100（40GB）1枚です。

4.4 結果

学習中の成功率は以下のようになりました。（学習に使っていない512シード、確率最大の選択肢を選ぶ評価。）

まず目につくのが、SFTは400回の更新で頭打ちになる点です。そこから800回続けても伸びませんでした。

一方で、GRPOは同じ出発点・同じシードから、手本なしでSFTを越えました。640エピソードでの成功率は、学習前 19.4%、SFT 68.6%、GRPO 79.1% です。SFTだけが成功したエピソードは72、GRPOだけが成功したエピソードは139でした。（符号検定で p < 0.00001）

さらに、SFTの頭打ちからGRPOを続けると 81.4% まで伸びました。手本の真似で止まったところから、成否の学習でもう一段上がるということだと思います。

同じ場面での3つのモデルのプレイです。学習前とSFTはすぐに撃って外し、GRPOは待ってから撃って当てています。（試験用128エピソードのうち、SFTが外してGRPOが当てたのは36回、その逆は11回。ここではその36回から選んでいます。）

4.5 わかっている弱点

良い結果ばかりではなかったので、弱点もまとめておきます。

• 覚えるのは、学習した条件に合う戦い方：GRPOは「待ってから撃つ」戦い方を覚えました。1回の判断で進む時間を2倍にすると、128回中75回は1発も撃たないまま時間切れになります。（撃てた回の命中率は 64% で、SFTの 45% より高い。）別のゲーム（Basic）でも、失敗した21回はすべて時間切れでした。

• 学習が不安定：GRPOの20ステップ目あたりで、確率最大の選択肢を選ぶ評価だけが一時的に崩れました。

5. まとめ

今回は、Decision Modelに盤面先の予測は可能なのか、そしてLLMと同じようにGRPOで強化学習して身につけさせられるのではないか、という2点を試してきました。結果は以下のような感じでした。

• 公開デモは、選んだ先に何が起きるかをコードが計算して入力に書いている。モデルが選択している意味がなくかなりの誇大広告。

• ViZDoomでは、Jevはコード補佐なしだと 0/128。コード補佐ありだと 126/128 だが、コードのみでも同じ 126/128。

• Decision Modelでも、複数ステップを1エピソードにまとめたGRPOは普通に動く。手本なしで成功率は 19% → 79% となり、SFT（69%）を越えた。

• ただし、覚えるのは学習した条件に合う戦い方で、条件を変えると崩れる。

コードが計算して入力に書いているのであれば、そのデモが示しているのはコードの力です。Decision Modelが得意なのは、書いてあることを読んで速く選ぶところだと思います。

一方で、先読みが必要であればGRPOで重みに覚えさせるという道があることも確認できました。個人的には、デモのようなコードを厚くしていくよりも、こちらの方に可能性があるのではと考えています。

また、今回示したような強化学習は、今回のようなデモだけでなく、より多様な場面で有効に使えると考えています。例えばPhysical AIやComputer Use、Browser Useなど、1ステップでは正解を決められないタスクでは、こうしたアプローチは有用なはずです。少なくとも手元では、Browser UseでもGRPOが有効なことは確認しています。

議論や感想があればNoteやX(Twitter)でコメント・ご教示いただけると助かります。
X: https://twitter.com/CurveWeb

目を通していただきありがとうございました。

検証に使ったコードは以下に格納してあります。よければご参照ください。（NanoJevをもとにした非公式の拡張です。学習・評価のコマンドはREADMEにあります。）なお、実装・分析・下書きの多くにはClaude Codeを使っています。誤りを見つけた場合は教えていただければ修正します。

参照