- 自然言語から作ったコードを、見た目の類似度ではなく実行テストで評価した。
- Codex第2版は164問のHumanEvalを提示し、論文の設定では単発生成と多数の候補生成で達成率が変わった。
- 短いPython関数の課題であり、既存システムの改修や安全性を測った結果ではない。
何を確かめた研究か
CodexとHumanEvalの原論文は、自然言語の説明から作るコードを何で評価するかを問う。正解例と文字が違っていても、同じ動作をするプログラムはある。BLEUのような文字列の近さだけでは、実際に動くかを判断しにくい。著者らはGitHubの公開コードで追加学習したCodexを調べるため、手書きのPython関数課題HumanEvalを作り、用意したテストに合格するかを測った。
この研究の主題は、製品としてのGitHub Copilotの品質ではない。論文は、Copilotを支えるのは別の製品版だと明記する。研究用モデルが限定された課題で機能的に正しいコードを生成できるかを扱っている。
どう検証したか
HumanEvalには164問がある。各問に関数の定義と説明、参照解、複数の単体テストを用意する。平均のテスト数は7.7と記す。著者らが問題を手書きにしたのは、公開コードで学習したモデルが、既存の問題と答えを丸ごと見ている可能性を減らすためだ。生成コードは隔離した環境で実行し、テストに通るかを確認する。
論文は一回の候補で解ける割合に加え、複数の候補を出したとき少なくとも一つが正しい割合をpass@kで示す。これは選んだ候補を自動で識別できるという意味ではない。候補を増やす条件では実行回数や選別方法が変わる。単発の得点と100候補を試した得点は、同じ費用・同じ運用手順での比較ではない。
何が分かったか
要旨は、論文のCodex設定でHumanEvalの28.8%を一回の候補で解き、100候補では70.2%を解いたと報告する。比較したGPT-3とGPT-Jの単発結果も示すが、モデルの学習条件や生成条件をそろえて読みたい。70.2%は、100候補のうち正しいものが一つ以上あった問題の割合であり、最初に提示したコードの成功率ではない。
著者らは、候補を多く出すほど多様性が重要になり、生成時の設定も最適値が変わると分析する。モデルのサイズだけでなく、評価の仕方が結果を大きく変える。この点は開発AIの比較で今も重要な教訓になる。
限界は何か
論文のLimitations節は、長い操作の連鎖を説明する文や、変数の結び付けなどに弱さがあると述べる。HumanEvalは短い関数を中心とし、複数ファイルの変更、依存関係、既存コードの読解、レビューを含む作業ではない。通過した単体テストにない不具合が残る可能性もある。
著者らは過信、セキュリティ、偏り、労働への影響も論じる。機能テストを通ったことと、安全で保守しやすいコードであることは別だ。論文の得点を現在の製品や社内リポジトリへそのまま移すことはできない。
特にHumanEvalのテストは各関数の仕様を確かめるもので、システム全体の性能や運用中の異常時の振る舞いまで保証しない。テストの範囲を明記して結果を読む必要がある。
仕事との接点
開発AIを試すなら、テストを通るかに加えて、差分の意図、セキュリティ、保守性を人が確認する。候補を多数生成する場合は、テスト実行と選別にかかる費用も記録する。これはHumanEvalの評価思想から導いたTRAIL編集部の提案であり、論文が企業の開発効率を測ったものではない。