AI支援プログラミングで最も直感的な考え方の一つは、モデルが自身の失敗から学ぶべきだというものだ。失敗したコードのテスト出力を見せれば、次の試行でより良い修正を生成するだろう。しかし新たな研究によれば、小型モデルに関してはこの直感は誤りであり、解決策は失敗がなかったかのように振る舞うことだという。
ソウル市立大学（University of Seoul）のユブラジ・ヴェルマ（Yuvraj Verma）氏による論文が今週arXivに公開され、コード生成モデル向けのさまざまな再試行戦略を体系的に比較している。その結果は衝撃的だ。70億パラメータ未満のモデルでは、ブラインド・リサンプリング（前回の試行を見ずに単純に新しい解を生成すること）が、あらゆる形態のフィードバックベースの自己修復を上回り、しかも消費するトークン数は2.5～5.5倍少ない。
根本原因はアンカリングだ。モデルが自身の以前の出力と失敗シグナルを一緒に与えられると、ほぼ同じコードを生成しがちになる。再試行の33～68％が、最初の試行と見分けがつかないプログラムを生み出す。そのフィードバックがないブラインド・リサンプリングでは、反復率は2～14％にまで下がる。モデルは最初の解に固着し、テスト出力だけではそれを揺り動かすのに不十分なのだ。
実験では、MBPP+ベンチマークを使って予算を揃えた4つの再試行条件をテストした。ブラインド・リサンプリング、中身のないプラセボの失敗通知、失敗したテスト実行からの実際の実行フィードバック、そして再試行の前にモデルが自身の誤りを言語で分析する完全なリフレクションである。全条件に同じ総試行回数が与えられ、追加の試行ではなくフィードバックの種類の効果を切り分けている。
70億パラメータ未満では、ブラインド・リサンプリングが最も強い条件だった。実行フィードバックはプラセボと比べて測定可能な追加効果を何ももたらさなかった。70億パラメータでは、ブラインド・リサンプリングは最も優れたフィードバックベースの条件と統計的に同等のままであった。アンカリングによるペナルティは非常に予測しやすく、その大きさは6つの構成（2つのモデルファミリーと2つの精度レベルにまたがる）にわたって、ベースラインの品質だけから予測でき、相関係数は0.96だった。
この発見は、AIコーディングエージェントの設計に実用的な示唆を与える。自己修復はコードエージェントのパイプラインの標準的な構成要素として広く扱われており、ほとんどの場合、まったく再試行しないベースラインと比較して評価されている。論文は、これがフィードバックの価値と追加試行の価値を混同させていると論じる。試行回数を統制すると、フィードバック自体は小型モデルにとって何の貢献もない。
リフレクション（モデルに自身の誤りを分析させること）は、アンカーを測定可能な形で弱めた唯一の介入だったが、トークンコストは高かった。API呼び出しの1回1回が重要になるコスト重視のアプリケーションでは、最も単純な戦略が最善のようだ。もう一度試すこと、そして振り返らないことだ。
雅子 訳