アーカイブ / LLM / AI Agent
実際のGitHub課題を修正できるか測るSWE-bench
SWE-bench
SWE-benchの原論文から掲載した図です。細部はクリックして拡大できます。
原論文の図の説明を読む
Figure 1: SWE-bench sources task instances from real-world Python repositories by connecting GitHub issues to merged pull request solutions that resolve related tests. Provided with the issue text and a codebase snapshot, models generate a patch that is evaluated against real tests.
概要
- 実際のGitHub課題と修正前コードを入力し、生成差分をテストで評価する枠組み。
- 12のPythonリポジトリから2294件を構築し、複数ファイルに及ぶ修正も含む。
- 著者らのBM25検索条件では、最良のClaude 2でも解決率は1.96%だった。
補足:編集した模式図で仕組みを確認する
VISUAL EXPLAINER
図でつかむ、SWE-benchの仕組み
- 01課題文と修正前コード
- 02関連ファイルを選択
- 03修正差分を生成
- 04テスト結果
原論文の説明をもとにした模式図です。処理の細部は省略しています。
研究の背景
短いコード片を作れることと、実際の不具合を直せることは異なる。現場の修正では、大きなコード群から原因を探し、関連する複数箇所を変更して既存機能も守る必要がある。
SWE-benchは、この作業を言語モデルに課す評価枠組みである。GitHubの課題と統合済みの修正を利用し、モデルが実務に近い変更を行えるかを測るため、開発支援の導入判断に役立つ。
手法
一件の入力は、GitHubの課題文と修正前のコード一式である。モデルは「パッチ」と呼ぶ変更行の記録を出力し、その差分を元のコードに適用する。例えば、設定が偽のときだけ表示が崩れる不具合なら、設定を確認する処理を修正し、真と偽の両方で動作を確かめる課題になる。
評価側は差分の適用後、課題に結び付く単体・システムテストを実行する。差分が適用でき、指定テストがすべて通った件を解決と数える。大きなコードを入力欄に収めるため、実験ではBM25検索か、正解の修正先を知っている設定でファイルを選んだ。
新規性
SWE-benchの新しさは、実際の課題文、修正前のコード、統合済みの修正に伴うテストを結び付け、リポジトリ単位の変更を採点する点にある。生成した差分が適用でき、関連テストをすべて通るかを成功条件とする。
収集時には、修正前に失敗し修正後に成功するテストが少なくとも一つある課題を残す。著者らはさらに、別のリポジトリから集めた訓練用課題でSWE-Llamaを調整した。
従来手法との違い
HumanEvalのような従来のコード生成課題は、一つの関数内で完結する短い問題が中心である。SWE-benchでは、課題の説明から変更箇所を探し、複数の関数やファイルをまたぐ修正を差分として出す必要がある。
モデル比較では、BM25という語の一致に基づく検索で関連ファイルを選ぶ条件と、正解の修正先ファイルを先に示す「オラクル」条件を使う。後者は実務では得られない手掛かりであり、両条件の成功率を同列に扱えない。
実験結果
著者らは12のPythonリポジトリから2294件を構築した。元の統合済み修正は平均1.7ファイル、3.0関数、32.8行を変更する。指標は課題を解決した割合で、差分を適用できた割合も報告している。
BM25でファイルを選ぶ条件ではClaude 2が1.96%、SWE-Llamaの70億・130億版が各0.70%を解決した。正解の修正先ファイルを与える条件ではClaude 2が4.80%、SWE-Llama 13Bが4.00%だった。GPT-4の一部の評価は予算上、課題の無作為な25%で実施された。
応用の可能性
編集上の応用案 · 論文が実証した用途とは区別しています。
編集上の応用案:社内のPython製ツールで、過去に解決済みの不具合を使い、修正案作成支援を試す。入力は当時の課題文と修正前のコード、出力は変更行を示す差分ファイルとする。
担当者は差分を確認し、関連テストを実行して採否を決める。どのファイルをモデルに見せるかも記録すれば、検索の失敗と修正内容の失敗を分けて調べられる。自動適用の可否より、どの段階で人の確認が必要かを把握する用途である。
応用先の候補からNauhに相談できます。
導入時の検証
導入時の検証案 · 対象データでの再評価が必要です。
導入時の検証案:修正前の状態と再現テストが残る社内課題を少数選ぶ。まず人が関連ファイルを指定する条件で差分を作り、次に課題文によるファイル検索から始める条件を試す。
両条件で、差分の適用率、再現テストの成功率、既存テストの成功率、担当者が採用できる割合を測る。現在の人手による修正手順を基準にし、検索段階とコード変更段階のどちらで失敗したかを課題ごとに記録する。
限界と課題
著者らの結果では、当時のモデルは現実的なファイル検索条件で大半の課題を解決できなかった。長い入力では必要な変更箇所を見つけにくくなり、生成した差分が適用できない例もあると分析している。
編集上の確認課題は、手元のリポジトリでテストが不具合を十分に捉えるか、課題文に画像や省略された前提がないか、変更後に既存機能が保たれるかである。テスト通過率だけを修正品質の全体評価にしない。
出典
元のタイトル・要旨を確認する(英語)
SWE-bench: Can Language Models Resolve Real-World GitHub Issues?
Language models have outpaced our ability to evaluate them effectively, but for their future development it is essential to study the frontier of their capabilities. We find real-world software engineering to be a rich, sustainable, and challenging testbed for evaluating the next generation of language models. To this end, we introduce SWE-bench, an evaluation framework consisting of $2,294$ software engineering problems drawn from real GitHub issues and corresponding pull requests across $12$ popular Python repositories. Given a codebase along with a description of an issue to be resolved, a language model is tasked with editing the codebase to address the issue. Resolving issues in SWE-bench frequently requires understanding and coordinating changes across multiple functions, classes, and even files simultaneously, calling for models to interact with execution environments, process extremely long contexts and perform complex reasoning that goes far beyond traditional code generation tasks. Our evaluations show that both state-of-the-art proprietary models and our fine-tuned model SWE-Llama can resolve only the simplest issues. The best-performing model, Claude 2, is able to solve a mere $1.96$% of the issues. Advances on SWE-bench represent steps towards LMs that are more practical, intelligent, and autonomous.
論文本体の取得範囲に基づく解説。AIが作成した未校閲の記事です。性能の数値は著者の評価条件に依存します。応用例と検証計画は編集上の提案です。解説更新:2026-09-29




