SWE-QA: Can Language Models Answer Repository-level Code Questions?

以下は、論文「SWE-QA: Can Language Models Answer Repository-level Code Questions?」の詳細な技術的サマリーです。

1. 問題定義

現在の大規模言語モデル（LLM）はコード理解において有望な成果を示していますが、既存のベンチマーク（CoSQA、CodeQA など）は、主に孤立したコードスニペット、関数、または API に焦点を当てています。これらの設定は、開発者が直面する現実のソフトウェア工学の複雑さを捉えきれていません。具体的には、開発者は以下のようなタスクを遂行する必要があります。

• 複数のファイルにまたがる大規模で相互接続されたコードベースをナビゲートする。
• ソフトウェアアーキテクチャと設計の根拠を理解する。
• 長距離の依存関係を追跡し、多段推論を行う。
• 複雑な「なぜ（Why）」や「どのように（How）」という質問に答えるために、アーキテクチャ知識を統合する。

深層的な多ファイル文脈と構造的理解を必要とするリポジトリレベルの質問応答（QA）を評価する、高品質で人間による検証がなされたベンチマークは不足しています。

2. 手法：SWE-QA ベンチマークの構築

著者は、15 の多様な Python リポジトリ（SWE-Bench 由来 12、SWE-Bench-Live 由来 3）を用いた 4 段階のパイプライン（図 2）を通じて構築された、リポジトリレベルのコード QA ベンチマークであるSWE-QAを提案します。

A. シード収集と分類体系の構築

• データソース: 12 の人気リポジトリから 77,100 件の GitHub イシューをクローリングしました。
• フィルタリング: 内容が豊富な 41,955 件のイシュー（1,000 文字超）を選択し、LLM を用いて 127,415 件の明示的なコード関連質問を抽出しました。
• 分類体系: 3 年以上の経験を持つ 2 人の人間専門家が 1,000 件のサンプリングされた質問を手動で分析し、2 レベルの分類体系を作成しました。
  • レベル 1（疑問詞）: What、Why、Where、How。
  • レベル 2（意図）: 12 の詳細なカテゴリ（例：依存関係追跡、設計根拠、機能場所特定、アルゴリズム実装）。
• 分布: 「How」質問（35.2%）と「Where」質問（28.4%）が最も頻繁に見られ、手続き的および場所に関する知識の必要性を反映しています。

B. 質問の具体化

• 文脈抽出: tree-sitter を使用して、リポジトリ構造を型付きグラフ（ノード：クラス、メソッド、ファイル；エッジ：呼び出し、インポート）に解析しました。
• 生成: 焦点となる要素（例：特定のクラス）を選択し、その構造的な文脈を分類体系から導き出されたシードテンプレートと組み合わせました。
• プロセス: LLM が特定のリポジトリに特化した候補質問を生成し、多段推論を必要とし、単純な検索では回答できないことを保証しました。

C. 回答収集と検証

• RAG パイプライン: 回答は、関連するコードスニペット、ドキュメント、メタデータを検索する検索拡張生成（RAG）アプローチを用いて生成されました。
• ヒューマン・イン・ザ・ループ:
  • 専門家による修正: 2 人のシニア開発者が、Cursor などのツールを用いて、各回答の事実の正確性、完全性、明確さをレビューしました。意見の相違は、3 人目の専門家によって解決されました。
  • 品質フィルタリング: 曖昧、事実誤認、またはコードにおける十分な根拠が欠如しているペアは破棄されました。
• 最終データセット: 15 のリポジトリそれぞれ 48 件、合計 720 件の高品質な QA ペア（13,300 ファイル、340 万行以上のコードを網羅）。

3. 主な貢献

1. SWE-QA ベンチマーク: 15 の Python リポジトリにまたがる 720 件の人間検証済み QA ペアを備えたリポジトリレベルの QA ベンチマーク。これは多段推論、ファイル間依存関係、アーキテクチャ理解を独自に組み合わせています。
2. 柔軟な生成パイプライン: シードテンプレートと静的コード分析を用いて、任意の新しいオープンソースリポジトリに対して QA データセットを半自動で構築できるモジュール型フレームワーク。
3. 包括的な評価: さまざまな文脈拡張戦略（直接プロンプティング、RAG、エージェントフレームワーク）下での LLM の厳密な評価。

4. 実験結果

著者は、さまざまな戦略を用いて 6 つの高度な LLM（GPT-5.1、Gemini 2.5 Pro、GLM-4.6、Qwen3-Coder などを含む）を評価しました。

• 文脈拡張の影響:
  • 直接プロンプティング: 性能が低く（例：Kimi K2 は約 51/100）、リポジトリ文脈の必要性を浮き彫りにしました。
  • RAG（スライディングウィンドウ/関数チャンキング）: 性能を大幅に向上させました（例：+10〜14 ポイント）。
  • エージェントフレームワーク（OpenHands、SWE-agent）: 反復的な推論とツールの使用を可能にすることで、最良の結果を達成しました。GPT-5.1 を使用した OpenHandsは、70.79/100という最高スコアを記録しました。
• モデルの性能:
  • GPT-5.1とGLM-4.6（OpenHands 併用）がトップを走りました。
  • 小規模モデル（例：Qwen3-30B）はエージェントフレームワークで苦戦し、RAG と同等かそれ以下の性能を示しました。これは、長期記憶やツール計画における限界を示唆しています。
  • 商用ツール（Cursor、通義霊馬）は競争力のある性能（69〜70）を示し、エンドツーエンドのツール拡張ソリューションの有効性を検証しました。
• 分類体系分析:
  • モデルは、ドキュメント文字列に情報が明示的に含まれていることが多い**「Why」質問（設計根拠）や、API サポートに関する「How」**質問で優れていました。
  • モデルは、ファイル全体に分散したロジックを再構築する必要がある**「What」（アーキテクチャ探索）や「Where」**（機能場所特定）の質問で苦戦しました。
• リポジトリ間一般化:
  • 性能はリポジトリの複雑さによって変動しました。「Flask」が最も易しく（75.42）、"Pylint"（62.01）と"Conan"（64.51）が最も困難でした。
  • SWE-Bench-Live由来のリポジトリ（データ漏洩が少ない）は、SWE-Bench 由来のものよりも難易度が高かったです。

5. 意義と将来の方向性

• 現実的な評価: SWE-QA は、スニペットレベルのテストを超え、現実のソフトウェア工学タスクに必要な「リポジトリ全体」の理解を評価するものへと移行しました。
• エージェントフレームワーク: 結果は、RAG が役立つ一方で、複雑な多ファイルコードベースをナビゲートする現在の最も効果的なアプローチは、トークンコストが高いにもかかわらずエージェントベースのフレームワークであることを示唆しています。
• 限界: 現在のベンチマークは Python のみで、静的スナップショットに基づいています。将来の研究では、他の言語や動的に進化するリポジトリへの拡張を目指しています。
• 未解決の課題: 論文は、LLM が依然として深い依存関係の追跡や正確な場所の推論に苦戦していることを強調しており、より良いコードグラフの統合と推論能力の必要性を示しています。

論文は、エージェントによる拡張が行われた場合、特にリポジトリレベルの QA において LLM が有望な成果を示している一方で、複雑な多段依存関係やアーキテクチャ推論の処理には依然として重大な課題が残っていると結論付けています。