新しいモデルが発表されるたびに、「SWE-bench で◯%」という数字が並びます。
数字が上がるほど賢くなったように見える一方で、その%が何を数えた結果なのかは意外と語られません。
中身を知っておくと、発表の数字をうのみにせず、自分の用途に引き寄せて読めるようになる。
ベンチマークの数字を見て、「で、実際の仕事ではどうなの？」と感じたことはありませんか？
SWE-benchは「GitHubの本物のissue」を解かせるテスト
SWE-bench は、Carlos E. Jimenez 氏らの研究チームが発表したベンチマークで、ICLR 2024 に採択されています。
中身は、人気のある12のPythonリポジトリから集めた2,294件の問題。
1件ごとに、AI には実際の issue の文章とその時点のコードベースが渡され、issue を解決するようにコードを書き換えることが求められる。
問題の元になっているのは、issue に紐づき、テスト関連のファイルにも手が入った実際のプルリクエストです。
論文では、複数の関数やクラス、ファイルにまたがる変更を協調させる必要があることが多いと説明されています。
発表時点で最も成績のよかったモデルでも、解けたのは1.96%にとどまっていました。
元の論文は arXiv のSWE-bench: Can Language Models Resolve Real-World GitHub Issues?で読めます。
「解けた」はテストが通ったかどうかで決まる
では、どうなれば「解けた」と数えるのか。
判定に使うのは、元のプルリクエストに含まれていたテストです。
データセットには、修正で通るようになるべきテスト（FAIL_TO_PASS）と、修正の前後どちらでも通るべきテスト（PASS_TO_PASS）が記録されています。
AI が作った変更を当てたうえで両方が通れば「解決」とみなし、その割合が発表で目にする%になる。
実行環境は Docker で固定されていて、誰が測っても同じ条件になるよう作られています。
つまり SWE-bench の%は「テストという物差しで見て直せた割合」を表しているのです。
裏を返すと、物差しであるテストが甘ければ、数字も甘くなる。
VerifiedやLiteは「問題を選び直した」版
発表の数字には、SWE-bench のあとに「Verified」や「Lite」が付いていることがよくあります。
SWE-bench Verified は、元のテストセットから人が検証した500件を選んだサブセットです。
OpenAI が Python の経験を持つ93人の開発者とともに、1,699件の問題を手作業で点検して作りました。
点検の理由は、issue の説明が曖昧で何を直せばよいか決めきれない問題や、範囲の合っていないテストが含まれていたこと。
Lite のほうは、問題数を絞った小さめの版です。
同じ「SWE-bench」でも、どの版の数字かで難しさも件数も違うので、比べるときは版をそろえる必要がある。
検証済み版の中身は、Hugging Face のSWE-bench Verifiedのデータセットで確かめられます。
数字を読むときの3つの注意
仕組みが分かると、発表の数字を読むときに気をつけたい点も見えてくる。
1つめは、テストが通っても本当に直ったとは限らないこと。
UTBoost という研究では、テストが不十分なせいで、正しくない変更が「解決」と判定されていた例が345件見つかったと報告されています。
2つめは、問題の答えがすでに外に出ている可能性。
SWE-Bench+ という研究は、成功した変更の32.67%で、解決策そのものが issue の本文やコメントに書かれていたと指摘しました。
公開リポジトリの問題なので、モデルが学習の段階でその issue を見ていたかもしれない、という懸念もつきまとう。
3つめは、数字が「モデル単体」ではなく「モデルと、それを動かす仕組みの組み合わせ」の成績だということです。
リポジトリを読ませ、変更を作らせる仕組みごと測っているので、同じモデルでも組み合わせる仕組みが違えば別の結果として並ぶことになります。
同じモデルでも周りの仕組みで振る舞いが変わる話は、エージェントハーネスの記事で整理しました。
%は「AI の実力」そのものではなく、特定の問題集と判定方法での成績と読むのが安全です。
回答の良し悪しを何で測るかという考え方は、RAG の評価を扱った記事でも取り上げています。
テストの不十分さを調べたのはUTBoost の論文。
答えの漏れを指摘したのはSWE-Bench+ の論文です。
最後に
SWE-bench の%は、実在する GitHub の問題を、元のプルリクエストのテストで判定した解決率でした。
どの版で、どんな仕組みと組み合わせて測った数字なのかまで見て、はじめて比べられる指標。
私も発表の数字を追うときは、まず版とエージェントの構成を確かめるようにします。
自分の仕事に近いかどうかは、手元のリポジトリの小さな issue で実際に試すのが、いちばん確かな物差しになりそう。
以上です。
コメントを残す