LLM（Large Language Model、大規模言語モデル）が推論の途中で間違えたとき、どこで、どう軌道修正させるかを扱った論文が公開されました。Inject a Turn, Not a Tokenが提案する UPTURN は、失敗した回答の途中までを残し、修正の指示を「新しいユーザー発話」として差し込んで続きを書き直させます。モデルの再学習は不要です。数学の 6 ベンチマークと 4 つの推論モデルの平均で、正答率は 37.1% から 55.3% に上がりました。同じ指示を文中に混ぜるだけでは、うまく効きませんでした。
背景と文脈
推論モデルは、答えに至るまでの思考を長く書き出してから結論を出します。この思考の途中で誤りが入ると、後半はその誤りを前提に進み、最後まで気づかないことがよくあります。自分の誤りを見つけて直す力は、今も安定していません。
従来の自己修正は、大きく 2 系統あります。1 つは、修正文やフィードバックを出せるようにモデルを追加で訓練する方法です。もう 1 つは、「もう一度確認して」といった反省用の語を、生成の途中に差し込む方法です。前者は訓練の手間がかかり、後者は効き方が安定しません。
著者らは、ここに 2 つの問いを立てました。修正の指示をどこに入れるか。そして、指示をどんな形で入れるか。この 2 点を学習で決めるのが、論文の出発点です。
設定は、固定した生成予算の中での比較です。基準になる手法は、同じ問題に 32 回答えさせて結果を比べる方式で、Base@32 と呼ばれます。
技術/ビジネス面
UPTURN の仕組みは単純です。失敗した回答から、途中までの文章を残します。そこに、あらかじめ決めた修正指示を新しいユーザー発話として挿入します。凍結したまま（重みを更新しない）のモデルが、残りを書き直します。
鍵になる発見は、指示の「入れ方」です。同じ指示でも、文中にそのまま挿入すると、モデルは自分が書いた文章の一部として吸収してしまい、思考が変わりにくいことが分かりました。ユーザーの新しい番に置くと、モデルは別の入力として受け取り、方向を変えます。
次に、どこで切るかです。候補は段落の境目（空行）に絞られます。ここは次の語の予測が揺れやすい位置だと、著者らは示しています。位置を選ぶのは、約 13 万パラメータの小さなニューラルネットです。凍結した 0.6B（6 億パラメータ）のモデルの内部状態を入力にします。
訓練は GRPO 型の強化学習です。失敗した回答ごとに 8 か所を切り、それぞれ 8 通りの続きを生成し、最終答えが正しかった割合を報酬にします。手順ごとの正解ラベルは使わず、最終的な正誤だけで学びます。訓練データは DAPO-Math の約 1.7 万問で、30 ステップです。
修正が必要かの判定には、別の小さな判定器を使います。最終答えの位置の内部状態から正誤を推定し、AUC（判定の精度を表す指標で、1 に近いほど良い）の平均は 0.962 でした。スコアが 0.4 を下回る回答だけを修正します。正解を知っている理想の判定器に替えても、平均正答率は 0.6 ポイントしか変わりません。
結果を見ます。評価は AIME24、AIME25、AIME26、AMC23、HMMT、MATH500 の 6 種類です。推論モデルは Qwen3-4B、Qwen3-8B、DeepSeek-R1 系の 8B、QwQ-32B の 4 つです。Base@32 の平均正答率が 37.1% なのに対し、UPTURN@16（16 回生成し、判定された分を 1 回修正）は 55.3% でした。モデル別では、DeepSeek-R1 系が 19.2% から 49.5% と最も大きく伸びています。
同じ修正回数での比較では、UPTURN が平均 59.8% で、Reflexion の 43.6%、AlphaOne の 32.6%、CyclicReflex の 35.7% を上回りました。さらに GPQA-Diamond（大学院レベルの科学問題集）にも、再訓練なしで +12.7 から +19.3 ポイントの改善が出ています。計算時間も、AIME24 の Qwen3-4B で 931 秒から 790 秒に減り、生成トークンは約 36% 少なくなりました。
これからどうなるか
実用で気になるのは、適用範囲です。著者ら自身が、答えを自動で採点できる推論課題に限った検証だと明記しています。コード生成やツール利用への拡張は、今後の課題です。MATH500 のように元の正答率が高い問題では、伸びも小さくなっています。
比較の条件にも注意が要ります。Base@32 は最大生成量が大きく、UPTURN は残りの部分しか生成しません。また、生成予算を 3 倍に増やすと、2 つの Qwen3 系では差が縮まります。万能の手法ではなく、予算が限られる場面で効く手法と読むのが妥当です。
開発者の視点で持ち帰れるのは、2 点です。1 つは、エージェントの再試行を実装するときに、修正指示を前の発言に追記するのではなく、新しいユーザー発話として送るという発想です。API の会話形式をそのまま使えるため、手元のコードでも試せます。もう 1 つは、小さな判定器で「やり直すか」を決める構成です。全回答を再生成せず、怪しい分だけを直せば、推論コストを抑えられます。
今後は、コードやツール呼び出しの失敗にこの考え方が移るかが焦点です。そこで効けば、エージェントの自己修復機能として実装に入ってくるでしょう。
まとめ
UPTURN は、失敗した推論の途中に修正指示を新しいユーザー発話として差し込み、再学習なしで精度を上げる手法です。数学 6 題の平均正答率は 37.1% から 55.3% に上がり、生成量も減りました。適用は答えを自動採点できる課題に限られますが、再試行の設計に使える具体的な知見です。
参考リンク
アイキャッチ画像: Photo by Google DeepMind on Unsplash
