AlphaCodium によるコード生成：プロンプトエンジニアリングからフローエンジニアリングへ

本論文は、コード生成は一般的な自然言語タスクとは異なると論じる。解は対象言語の正確な構文に合致し、ハッピーパスとエッジケースを扱い、長い問題仕様の多くの細かな点を守らなければならない。そのため、自然言語向けに最適化されたプロンプトの工夫はそのままでは通用しないかもしれない。著者らは、単一プロンプトの最適化や Chain-of-Thought プロンプトでさえ CodeContests での正解率を意味のある形では改善しなかったと報告し、代わりに AlphaCodium を提案する。これは、テストに基づく多段階でコード指向の反復的フローであり、専用のモデルを学習させることなく、コーディング向けに事前学習された任意の LLM に適用できる。

このフローは 2 つのフェーズから成る。線形の前処理フェーズでは、問題について自然言語で推論する。問題についての箇条書きでの振り返り、各公開テストの入力がなぜその出力になるのかについての推論、2〜3 個の候補解の生成、それらのランク付け、そして公開テストがカバーしないケースを狙った 6〜8 個の追加の AI テストの生成である。続く反復的なコードフェーズでは、初期解を生成し、公開テストに対して実行・修正したうえで、AI 生成テストに対しても実行・修正の反復を続ける。その際、誤った AI テストによってコードが誤った修正へと押しやられるのを防ぐために テストアンカー を用いる。この設計の背後にある重要な観察は、有用な追加テストを生成するほうが正しい解を生成するよりも容易だということである。前者には完全なアルゴリズム的解法ではなく、主に問題の理解と基本的な総当たりや論理的な推論が必要とされるからである。

要点

• CodeContests の検証セットでは、GPT-4 の pass@5 が、よく設計された単一の直接プロンプトでの 19% から、AlphaCodium フローでの 44% に上昇した。著者らは、オープンソース（DeepSeek）とクローズドソース（GPT）の両方のモデルについて、検証セットとテストセットの両方で一貫した有意な改善を報告している。
• 同じモデル（GPT-3.5）と同じ指標（pass@5）を用いた CodeChain との比較では、著者らが比較対象とした数値によれば、AlphaCodium は両方のセットでより良い結果を示した。
• このフローは 1 つの解につき約 15〜20 回の LLM 呼び出しを使うため、pass@5 の提出には約 100 回の呼び出しが必要になる。AlphaCode の解 1 つにつき 1 回の呼び出しと仮定すると、著者らは AlphaCode の pass@10@100K には約 100 万回の呼び出し、つまり 4 桁多い呼び出しが必要になると見積もっており、それでいて AlphaCodium の最良の結果のほうが優れている。
• 著者らはコード指向の設計プラクティスを推奨している。JSON ではなく YAML による構造化出力、意味的な推論を促すための箇条書きによる分析、小さな名前付きのサブ関数に分割されたモジュール化されたコードの要求、二重検証を伴うソフトな判断（「これは正しいか」と答えさせるのではなく、モデル自身に出力を再生成・修正させる）、探索の余地を残すために不可逆な判断を先送りすること、そしてテストアンカーである。
• 公開テストだけで反復すると解は安定し改善されるものの、公開テストは網羅的ではないため、盲点が残ると報告している。
• 著者らにとって結果を改善しなかった工夫には、失敗したトレースの最後に実行された 50 行、直近 K 個の失敗した解、あるいは直近の git パッチの差分を修正用プロンプトに注入すること、そして単一段階のプロンプトや反復を伴わないプロンプトの連鎖を最適化することが含まれる。

補足

著者らは、コード生成には JSON よりも YAML の出力が適していると論じる。生成されたコードには引用符や特殊文字が含まれることが多く、それらを JSON の中に正しく配置するのは難しい一方で、YAML のブロックスカラーは正しいインデントさえあればよく、さらに YAML のほうが必要なトークンが少ないからである。著者らは、実際にはいくつかの段階を 1 回の LLM 呼び出しにまとめられること、そして図に示したフローは概念的なものであることを指摘している。著者らは再現可能な実装と評価スクリプトを公開しており、AlphaCode と CodeChain のいずれの論文も CodeContests に対するエンドツーエンドで再現可能な解法を公開していなかったと指摘している。また、CodeContests のようなより難しいベンチマークのほうが、HumanEval のようなより単純なものよりも LLM をうまく評価できると論じている。著者らは、原則の多くが一般的なコード生成タスクにも広く当てはまると考えている。著者らは CodiumAI に所属している。