本論文は、開発者が機能コードより先にテストを書くテスト駆動開発（TDD）を、AI 支援によるコード生成に組み込めるかどうかを問う。その仮説は、問題文に加えてテストを LLM に与えると生成されるコードが改善され、事前に書かれたテストによって開発者は生成されたコードをあらかじめ定めた期待に照らして検証できる、というものである。著者らは、AI がいつ、どのようにテストを書くべきかは意図的に問うていないと強調している。与えられるテストは人間が書いたものであり、本論文の貢献はそれを実行するためのフレームワークではなく実証研究にある。
そのフレームワークである TGen は、問題文と与えられたテストの集合を受け取る。コーダーエージェントがコードを生成し、検証器が利用可能なテストに対して PyTest でそれを実行し、失敗した場合には修正（remediation）エージェントが失敗内容を読んで修正案を提示し、コーダーエージェントが次の反復でそれを適用する。これを最大 5 回、または同じテストが 3 回失敗するまで繰り返す。各問題はまず問題文だけから試み、次にすべての公開テストを与えて試み、さらに修正ループを伴って試みる。評価には GPT-4 Turbo（v1106）を用い、結果は Llama 3 70B Instruct で検証している。ベンチマークは、MBPP（399 問）と HumanEval（164 問）の EvalPlus 版（その追加テストはモデルには一切示されず、非公開テストとして用いられる）と、ファイル全体の生成を対象とした、11 の難易度レベルそれぞれから 100 問ずつ選んだ 1,100 問の CodeChef の問題セットである。
要点
- GPT-4 Turbo では、テストを与えることで MBPP の問題の 12.0%、HumanEval の問題の 8.5% が追加で解け、修正ループによってさらに 2.8% と 3% が解けた。
- EvalPlus の非公開テストで検証すると、テストを与えることで正しさは MBPP で 12.78%、HumanEval で 9.15% 向上し、修正によってさらに 5.26% と 5.49% 向上した。
- 1,100 問の CodeChef の問題では、性能は著しく低く、難易度が上がるにつれて急激に低下した。それでも、CodeChef の非公開テストで解を判定した場合、テストと修正を合わせて正しさは 7.27% 向上した。
- 単独で解ける問題が少なかった Llama 3 では、非公開テストでの検証後のテストと修正による改善はより大きく、MBPP で 38.6%、HumanEval で 21.95% と、GPT-4 の向上幅のほぼ 2 倍であった。
- テストを増やすと一般に正しさは向上したが、場合によっては追加のテストによって、以前は解けていた問題が失敗するようになった。著者らはこれが Lost in the Middle の問題である可能性を示唆している。
- 手作業での検査からは、テストが最も役立ったのは関数シグネチャの不一致、数式、正確な文字列操作、複雑なデータ構造、エッジケースであり、失敗が続いたのはコアロジックの誤解、特定のデータ構造、入出力形式、性能上の制限に関わるものであったことが示唆された。
- 修正の助言は 3〜4 回の反復の後には繰り返しになりがちであり、5 回の修正の試みをすべて使った問題が解けたことは一度もなかった。
補足
著者らは、MBPP と HumanEval は実世界のプログラミングの複雑さを完全には捉えていないこと、難易度別の CodeChef セットはソフトウェアエンジニアリングのタスクを代表していない可能性があること、テストの実行結果を正解とみなすことは非決定的な問題（著者らはこれを除外した）には当てはまらない可能性があること、そしてシードを固定し temperature を 0 にしても LLM の出力はある程度予測不能なままであることを認めている。著者らは結論として、コード生成において LLM とともにテスト駆動の方法論を広く採用することを提唱し、与えられるテストの質が、解が暗黙の要件をどれだけよく捉えるかを左右すると指摘している。