「この関数を書いて」ならAIはうまくやります。ところが実際の開発現場に置くと、途端に苦戦する。
この差を測るために作られたのがSWE-benchです。何が難しいのかが、この試験の設計に表れています。
実際のGitHubの課題を集めた
Carlos E. Jimenez氏ほかによる SWE-bench: Can Language Models Resolve Real-World GitHub Issues?。2023年10月の公開です。
集めたのは、実在するGitHubの課題と、それを解決した実際のプルリクエストの組。Pythonのよく使われるリポジトリ12個から、2,294件を抜き出しています。
試験の形はこうです。課題の文章だけを渡し、リポジトリ全体を触らせて修正させる。人間の開発者が実際に書いた修正と同じことができるか。
何が難しいのか
論文が挙げている難しさは、断片を書く作業とはまったく別物でした。
複数の関数、クラス、そして複数のファイルにまたがる変更を、同時に把握して調整する必要がある。長い文脈を扱い、複雑な推論を要する作業だとしています。
現場の作業を思い返すと納得がいきます。バグを直すとき、実際に書き換える行は数行でも、そこにたどり着くまでにコードベース全体を読む。どこを直せば副作用が出ないかを判断する。
書く力ではなく、探す力と見通す力が問われる試験です。
公開当時は1.96%
論文が報告した成績が衝撃的でした。
最も成績の良かったモデルであるClaude 2は、課題のわずか1.96%しか解けなかった
2,294件のうち45件ほど。当時のモデルは、コードの断片を書くことはできても、現場の課題はほぼ解けなかったことになります。
その後の数年で、この数字は大きく動きました。いまの上位モデルは同種の試験で数十パーセント台に達しています。試験そのものが難しくなった版も作られました。
この試験が示している使い方
実務に引き寄せると、示唆が2つあります。
ひとつは、コードを書かせるより直させるほうが難しいということ。新規に書くのは白紙からの作業ですが、修正は既存の構造を壊さない配慮が要ります。「この機能を作って」より「このバグを直して」のほうが、AIにとって重い仕事です。
もうひとつが、渡す情報の量が効くこと。課題の文章だけを渡すのと、関係するファイルを絞って渡すのとでは、結果が変わります。長い入力の真ん中が弱くなる性質もあるので、リポジトリを丸ごと渡せばよいという話でもありません。
現場で効く渡し方
試験の設計から逆算すると、実務での渡し方も見えてきます。
関係するファイルを自分で絞って渡す。どこを触ればよいかの見当が付いているなら、それを先に伝える。探す作業を肩代わりしてやると、成功率が上がります。
再現の手順とエラーの全文を添えるのも効きます。課題の文章だけでは、何が起きているかが伝わりません。
そして、テストを先に用意しておく。通ったかどうかを機械で判定できる状態にしておけば、直ったかを人が読んで確かめる手間が減ります。試験がテストで判定しているのと同じ理屈です。
任せる範囲を区切る
複数ファイルにまたがる変更が難しい、という性質は今も残っています。
大きな改修を丸ごと投げるより、1ファイルずつ、あるいは1関数ずつ区切って任せるほうが安定する。区切るのは人の仕事です。
出てきた変更は必ず読む。テストが通っても、意図しない副作用が入っていることがあります。外に影響する操作に人を挟むという原則は、コードの変更にも当てはまります。
試験の成績と実務の体感がずれる理由
数十パーセント解けるという数字を見ても、実際に使うと期待外れに感じることがあります。
試験の課題はPythonの有名なリポジトリから取られています。学習データに大量に含まれている可能性が高い。社内で書かれた独自のコードとは条件が違います。
それに、試験は「テストが通ったか」で判定します。通ればよいという基準なので、読みやすさや保守しやすさは見ていません。
自分の環境でどうかは、結局は自分で測るしかないところでしょう。実際の課題を10件ほど渡して、何件通るかを数えれば分かります。
10件のうち何件が一発で通ったか、何件が手直しで済んだか、何件が使えなかったか。この3つに分けて数えると、任せてよい範囲の見当がつきます。
同じ計測を新しいモデルが出るたびに繰り返せば、自分の環境での進歩が分かります。順位表の数字より確かです。
出典
試験の構成、件数、公開当時の成績は、下記の論文に基づきます。
