- SWE-benchは、公開ソフトウェアのGitHub課題を、AIがコードの修正で解決できるか測るための評価だ。
- 12のPythonリポジトリから2,294件の課題を集め、修正を適用した後に関連テストが通るか確認する。
- テスト合格は重要だが、修正の読みやすさや実務での安全な採用まで保証するものではない。
何を確かめた研究か
短い関数を書く課題で良い点を取れても、既存のソフトウェアの不具合を直せるとは限らない。実際の修正には、課題の説明を読み、関係するファイルを探し、複数箇所のつながりを理解する必要がある。SWE-benchの原論文は、AIが公開プロジェクトの課題を、コードベースへの変更として解決できるかを測る方法を提案した。
評価の材料は、GitHubに投稿された課題と、その課題に対応した取り込み済みの修正だ。課題に付随するテストで正誤を確かめられるものを選び、モデルに修正を作らせる。研究の中心は、特定の製品を推薦する順位表ではなく、「問題を最後まで解けたか」を測れる課題群を作ることにある。
どう検証したか
著者らは12のPythonリポジトリから、課題と修正の関係が確認でき、修正前後でテスト結果が変わるものなどを絞り、2,294件の課題を用意した。モデルには課題の説明と当時のコードを渡し、変更を「パッチ」として出力させる。パッチを適用して関連するテストを実行し、必要なテストを通過した場合に解決と判定する。
ただし、モデルがどのファイルを見るかも結果に関わる。論文は、文字列検索を使うBM25方式などで関連ファイルを選んで渡し、正解の修正ファイルを先に知らせる実験とも比べている。これはモデル本体だけでなく、資料の探し方と作業環境を含む評価だ。入力の長さによる差も調べている。
何が分かったか
論文第3版で評価された当時のモデルは、BM25で探したファイルを使う条件では、多くの課題を解決できなかった。正解に関係するファイルを与える条件では結果が変わり、ファイルの探し方が重要であることも示した。コードを生成したという事実だけでは、課題を解決したとは言えない。
一方、数値を読むには参照版の注意がいる。第3版の要旨と本文の一部には、同じ版の結果表と食い違うモデル名・解決率が残る。TRAILはこの記事で当時の順位や個別モデルの解決率を引用しない。課題の作り方と合否の定義を、この論文から引き継ぐ。
限界は何か
課題はすべてPythonの公開リポジトリから採られた。社内システム、非公開コード、ほかの言語での開発を代表するわけではない。論文の比較は当時のモデル、検索方法、入力長に依存し、後年の製品の順位表としては使えない。
著者らも、テストを通るだけでは修正の完全性、効率、読みやすさを保証できないと記す。実務なら、テストにない不具合や保守上の問題も確認する必要がある。
また、修正を適用できた割合と、課題を解決できた割合は異なる。形式が正しいパッチでも、必要な振る舞いを実現していなければ解決には数えられない。評価を読むときは「コードを出した」「適用できた」「テストで解決した」を区別したい。
仕事との接点
開発AIの試験では、自社の課題を選び、関連ファイルをどう渡したかを記録し、修正を実環境に近い条件で適用してテストする。その後、人が内容を読み、保守しやすさや予期しない変更を確認する。これはTRAIL編集部の提案であり、原論文が日本企業の開発チームでの生産性向上を実証した結果ではない。