この論文は、モデルが自分自身のコードをデバッグして修復する 自己修復 を取り上げ、それに必要な追加のモデル呼び出しを同じ予算から支払った場合に、単純にプログラムをより多くサンプリングするよりも本当に優れているのかを問う。著者らは、既存の自己修復の研究は範囲が限られていたこと、そしてその有効性はモデルがコードを書く能力だけでなく、自分のコードが仕様に照らしてどう間違っているかを特定する能力にも左右されることを指摘する。後者の段階について、著者らはこれまで詳細に研究した先行研究はないと述べている。
著者らは自己修復を 4 つの段階 ── コード生成、ユニットテストに対するコード実行、フィードバックモデルによるフィードバック生成、コード修復 ── としてモデル化し、1 つの仕様を根とするプログラム・フィードバック・修復の木を修復木（repair tree）と呼ぶ。公平に比較するため、pass@k を修正し、修復木はそこに含まれるプログラムの数だけのサンプルとして数えることとし、同じプログラム数で修復を行わない i.i.d. サンプリングと比較する。フィードバックの段階を切り離すことで、より強いモデルのフィードバックや人間のフィードバックに差し替え、その効果を単独で測定できる。実験では CodeLlama-13b-instruct、GPT-3.5、GPT-4 を用い、HumanEval と APPS の自己完結した Python 問題を対象とした。
主なポイント
- 自己修復は銀の弾丸ではない。修復のコストを勘定に入れると、修復なしの i.i.d. サンプリングが同等かそれ以上の合格率を達成する例がいくつも見つかり、とりわけ予算が小さい場合に顕著だった。
- 改善はしばしば控えめで、データセット間でもデータセット内でもばらつく。APPS では GPT-4 が修復なしのベースラインを最大 8% 上回った一方、GPT-3.5 は初期サンプル数が最も大きい場合にしかわずかな改善が見られなかった。
- 自己修復が効きやすいのは、予算を 1 つのプログラムあたり多数の修復試行に費やすよりも、多様な初期プログラムの集合に費やす場合である。APPS 上の GPT-4 では、初期サンプル 10 個にそれぞれ 1 回の修復を行うと pass@20 の 1.05 倍の合格率となったが、初期サンプル 2 個にそれぞれ 10 回の修復を行うと pass@22 を下回った（0.97 倍）。
- 著者らは、自己修復のボトルネックはモデルが自分のコードにフィードバックを与える能力にあるという仮説を立てている。弱いモデルのフィードバックを強いモデルのフィードバックに置き換えると、試したすべての構成で、すべての予算において、修復なしのベースラインと通常の自己修復の両方を上回った。
- 16 人の参加者が失敗した GPT-4 のプログラム 40 件を扱った実験では、GPT-4 自身のフィードバックを人間のフィードバックに置き換えることで、修復後のプログラムがすべてのテストに合格する割合が 1.58 倍（33.3% から 52.6%）に上昇した。
- 定性的な比較では、GPT-4 のフィードバックは参加者のものよりはるかに多く不正確であり（80 件中 32 件 対 80 件中 7 件）、参加者はときに不確かさを表明したのに対し、GPT-4 は一度もそうしなかった。
補足
著者らは限界として次の点を挙げている。実験はタスクごとに事前に生成した 1 つの大きな修復木からブートストラップしており、統計的なアーティファクトが生じるおそれがあること。実行可能なユニットテストを備えた自己完結型の Python タスクは現実のソフトウェア開発とは異なり、現実では仕様がしばしば不完全で、スニペットごとにテストが存在することはまずないこと。そして人間を対象とした実験では、参加者がデバッグにかけた時間を記録していなかったこと。この論文は ICLR 2024 の会議論文として発表された。著者らの所属は MIT CSAIL と Microsoft Research である。