今週のTOPIC

[blog] Eval-Centric AI: LLM-as-a-Judge on Vertex AI

• Google Cloud Champion InnovatorsからEval-Centric AIという概念の提案

• 従来の機械学習システムの改善方法
• Model-Centric AI: データと評価を固定し、アルゴリズムを改善
• Data-Centric AI: モデルと評価を固定し、データを改善

• LLMの場合、モデルとデータを改善するのが容易ではない
• モデルのアルゴリズムを改善し、再学習は現実的ではない
• Finetuningのための高品質なデータセットを用意することも労力がかかる
• Eval-Centric AI: モデルとデータの修正は容易ではないので、評価を改善

• 継続的にLLMを改善する上で、そもそもちゃんとLLMを評価することが大事
• LLMの出力は、自然言語なので評価基準が明確ではなく、「誰もあるべき振る舞いを定義できない」
• 評価において人間のフィードバックが必要だが、継続的に行うためにどうやっているか
• 判断基準が曖昧な中で、専門家の判断が最も信頼できるが、コストが高すぎてスケールしないし、継続的に進めるのは困難なので、LLM-as-a-judgeを利用
• 継続的にLLMの改善を進める上で、人間のFBをどのように入れるか
• LLM-as-a-jedgeにおけるEval-Centricな改善アイディアとして、専門家はLLMを直接評価するのではなく、LLMを評価するLLM-as-a-judgeの評価用プロンプトを継続的に改善していく
• LLM-as-a-judgeをhuman-in-the-loop的に改善していくにあたって、Vertex AIのGen AI Evaluation Serviceを便利！

[blog] ModernBERT のブログを読んでみた感想

• ModernBERTって？
• 長いコンテキスト長、優れたダウンストリーム性能、より高速な処理など、旧世代のエンコーダーを全面的に改善した最先端のエンコーダー専用モデルファミリー

• ModernBERTは、ベース（139Mパラメータ）とラージ（395Mパラメータ）両方のモデルサイズを備え、あらゆるBERTライクモデルの代替品として利用できる。
• ModernBERTの革新性: 長いコンテキスト長(8,192トークン)や高速処理により、従来のBERTの欠点を克服。特に、コード検索や大規模な情報検索の分野で優れた性能を発揮。
• 効率性への注力: 新しいアテンション機構やシーケンスパッキングを活用し、計算コストを削減。これにより、廉価なGPUでも高効率に動作可能。
• 実用性を重視: 他の巨大モデルと異なり、現実的なハードウェア環境で動作しやすい設計。さらに、ブラウザやスマートフォン向けの軽量アプリケーションにも利用可能。

• 改善ポイント
• RoPE（Rotary Position Embedding）の利用
• Transformerアーキテクチャで、位置情報を効果的に扱うための方式。
• 位置情報を直接埋め込むのではなく、回転行列によって位置情報を埋め込む
• Attention の変更
• Flash Attention に変更。そのうえで Alternating Attention というものを導入
• これは毎回 global attention(全単語との注意を見る) をするのではなく、local attention(周辺の単語しか見ない) を時々入れるもの
• Padding をやめる
• padding をやめてバッチサイズ1で全部一つの sequence にまとめる



• その他の細かい改善
• GeLU 活性化層は gated linear unit activation function (GeGLU) に変更
• 不必要な bias 項は除去
• Normalization Layer を追加

メインTOPIC

[論文]SWE-BENCH: CAN LANGUAGE MODELS RESOLVE REAL-WORLD GITHUB ISSUES?

Summary by ChatGPT o1

1. INTRODUCTION

• 既存のベンチマークの課題
• 最先端モデルは既存ベンチマークをほぼ解決済み
• Kiela et al. (2021)、Ott et al. (2022) などが指摘しているように、既存のベンチマークは多くの最新モデルによって高得点を取得されており、差がつきにくくなっている。これにより、モデルの改良を評価する指標としての有効性が低下している。
• 実運用時のシナリオとの差
• 多くのベンチマークは、短いコードや特定の関数やクラスだけを実装すれば解が求められ、他のファイルやコード全体の文脈をほとんど考慮しなくても済む (例: HumanEval)。実際のソフトウェア開発ではリポジトリ全体を理解する必要があるにもかかわらず、従来の課題は短い関数一つで完結するなど、現場の複雑さを反映していない。
• また、リアルなプロジェクトではバグ修正や機能追加のために既存コードを変更するケースが大半であるが、既存のベンチマークは新規関数の実装に偏っており、継続的な改修やドキュメンテーションといった実運用シナリオをカバーしていない。
• 評価方法が単体テストベースではなく、生成されるコードの比較
• 多くのベンチマークでは「正答コード」か「不正解」かを静的に判定する設計が主流だが、実際には単一の正解だけでなく、複数の実装方法が存在しうる。

• SWE-benchについて
• GitHubのIssueとPull Request (PR) を基に構築
• 人気のあるGitHubリポジトリに投稿された「イシュー」(バグ報告や機能要望など) と、そのイシューを解決したPRをセットで取り込み、実際の解決プロセスを再現したタスクを作成。
• テストコードを利用した自動評価
• 生成されたパッチ（コードの修正内容）をリポジトリのテストフレームワークで実行し、実際のテストをパスするかどうかでモデルの解答を評価する。

2. SWE-BENCH

2.1 BENCHMARK CONSTRUCTION

• GitHubからベンチマークとなるコードを取得する方法



• Stage I: リポジトリ選定とデータ収集
• メンテナンス体制やコントリビューターガイドラインが整っていて、テストカバレッジも高い、人気のあるオープンソースのPythonリポジトリ12件を対象に、プルリクエスト (PR) を大規模に収集
• 合計で約9万件のPRを取得し、この際、各リポジトリのbase commitに基づくコードベースも同時に取得
• Stage II: 属性ベースのフィルタリング
• Stage Iで収集したPRのうち、GitHubのイシューを解決する形でマージされていて、かつリポジトリ内のテストファイルを変更しているものだけを抽出する。
• この条件を満たすPRであれば、実際の問題を解決し、それを検証するためにテストを追加あるいは修正している可能性が高いと考えられるため、より実践的なタスクとして利用できる。
• Stage III: 実行ベースのフィルタリング
• Stage IIで抽出された候補タスクに対して、PR適用前後でテストを実行し、その結果を比較する。具体的には、少なくとも一つのテストが「失敗から成功」に変わることを必須条件とし、さらにインストールエラーやランタイムエラーが起こるPRは除外する。
• こうすることで、実際にバグ修正や機能追加が行われ、テストによってその修正・追加の有効性が確認されたタスクのみが最終的に残ることになる。

• 結果として最終的に2,294件のタスクインスタンスを作成。SWE-benchを構成するリポジトリはいずれも数千ファイル規模の大規模なコードベースを持ち、対象となるPRの多くが複数ファイルを同時に変更している点が特長である。

2.2 TASK FORMULATION

• Model input
• モデルには、問題のテキスト説明とコードベース全体が与えられ、その問題を解決するためにコードベースを修正するよう求められる。具体的には、修正内容をパッチファイルの形式で表し、どの行をどのように変更するかを記述する。

• evaluation metrics
• 提案されたパッチは UNIX の patch コマンドを使ってコードベースに適用し、対応するユニットテストやシステムテストをすべて実行する。パッチの適用が成功し、かつすべてのテストが通った場合、その解決策は問題を解決できたと見なされる。
• 本ベンチマークの評価指標は、与えられたタスクのうちテストをクリアした提案の割合である。

2.3 FEATURES OF SWE-BENCH

• 実際のソフトウェア開発タスクに近い
• 大規模かつ複雑なコードベースと、そのコードに関連する具体的な問題をセットで与えるため、既存のコード生成ベンチマークに比べて、より高度な開発スキルや知識が必要となる。

• 継続的な拡張が容易
• GitHub 上の任意の Python リポジトリからタスクを収集でき、人手の介入が最小限で済むため、常に新しいタスクを追加可能。また、モデルの学習後に作成された課題を取り込むことで、学習データへの依存を抑える。

• 多様で長い入力
• 課題の説明文は平均で195 wordと長く、コードベースも数千ファイルに及ぶことが多い。その中から正確に修正すべき箇所を見つける能力が試される。

• 堅牢な評価手法
• それぞれのタスクには少なくとも 1 つの「失敗から成功へ導く」テストが用意されており、40% のタスクでは 2 つ以上のテストがある。さらに、中核的機能の維持を確認するため、中央値で51 個の追加テストを実行する。
• [tomo] これはなんのことだろう

• 広いコンテキストを要するコード修正
• モデルが修正箇所を限定された関数やクラスの範囲内にとどまらず、コードベースの複数ファイル・複数箇所にまたがって改変を行う必要がある。実際に、SWE-bench の参照解決策では平均して 1.7 ファイル・3.0 関数・32.8 行に対して変更が行われる。

• 解法の幅広い自由度
• リポジトリ全体を編集するタスクを通じて、情報検索型やロングコンテキスト対応モデル、あるいはエージェント型アプローチなど、多様な手法を公平に比較できる。また、参照プルリクエストにとらわれず、独自の解決策を提示することも可能である。

2.4 SWE-BENCH LITE

• SWE-bench は評価に時間やコストがかかるうえ、初期の性能は低めであることが示されているため、短期的に導入するにはハードルが高い場合がある。そこで、より手軽に利用できるように設計された SWE-bench Lite が用意されており、機能的なバグ修正の評価に焦点を当てつつ自己完結的な 300 件のタスクが選ばれている。

• オリジナルの 12 リポジトリのうち 11 をカバーしており、リポジトリごとの多様性やタスクの分布は本体とほぼ同様である。

3. SWE-LLAMA: FINE-TUNING CODELLAMA FOR SWE-BENCH

• SWE-Llama
• 概要
• オープンソースモデルの性能を比較評価するにあたって、現時点では CodeLlama 系のモデルのみが必要とされる非常に長いコンテキストに対応可能だが、既存の CodeLlama をそのまま用いる場合、リポジトリ全体にわたるコード修正を正しく出力できず、プレースホルダー的な回答や無関係なコードを返すことが多い。
• そこで、7億パラメータ版および13億パラメータ版の CodeLlama-Python モデルを、約1.9万件の issue-PR ペアを使って教師ありfine-tuningし、リポジトリ単位のコード修正に特化した「SWE-Llama」を作成した。
• 学習データ
• 37個の人気Pythonリポジトリから19,000件のissue-PRペアを新たに収集。
• 学習データの規模を確保するため、PRのテスト変更有無は条件としなかった。
• 評価用ベンチマークのリポジトリとの重複を避けることで、データ汚染を防いでいる。
• 学習手法
• GitHubのissueテキストと関連コードファイルをプロンプトとして与え、実際の修正パッチ（"gold patch"）を生成するようfine-tuningを実施した。
• LoRA (Hu et al., 2022) を使用してアテンションサブレイヤーのみを調整し、30,000トークンを超える学習例を除外することでメモリ使用量を抑制した。
• 最終的に約10,000件のデータで学習を行った。

4 EXPERIMENTAL SETUP

4.1 RETRIEVAL-BASED APPROACH

• SWE-bench のタスクでは問題説明文と大規模なコードベースが入力として与えられるが、コードベース全体は言語モデルのコンテキストウィンドウに収まらない。そこで、以下の 2 種類の手法で関連するファイルのみを抽出し、モデルに与えるベースラインを構築する。
1. Sparse retrieval (BM25)
• 自然言語で書かれた問題文をクエリとし、BM25を用いてコードファイルを検索し、得られた関連ファイルをモデルへ入力する。
• モデルのコンテキスト上限に応じてファイル数を調整し、複数の上限値で評価。

2. “Oracle” retrieval
• 実際に GitHub 上で問題を解決したパッチが編集しているファイルのみを抽出してモデルに入力する手法。
• 実エンジニアがあらかじめ修正箇所を把握しているとは限らないため現実的ではないが、BM25 などスパースリトリーバルの性能を比較・分析する上での上限性能として利用。

• Sparse retrieval と “Oracle” retrievalの結果を比較したところ、27,000 トークンのコンテキスト制限下では、約 40% の事例で Sparse retrieval が “Oracle” retrievalのファイルをすべて含む候補を取得した一方、約半数の事例では“Oracle” retrievalから取得すべきファイルをまったく取りこぼしてしまうことがわかった。

4.2 INPUT FORMAT

• 取得したファイルを用い、以下の情報を一つにまとめてモデルへ入力する。
• タスクの指示 (task instructions)
• 問題（issue）のテキスト
• 取得したファイルやドキュメント
• 例となるパッチファイルと、それを生成するためのプロンプト

• 例

4.3 MODELS

• 長いシーケンスを扱う必要があるため、SWE-bench に対応できるモデルは限られており、本研究では以下のモデルを評価対象として選定
• ChatGPT-3.5 (gpt-3.5-turbo-16k-0613)
• GPT-4 (gpt-4-32k-0613)
• Claude 2
• SWE-Llama

• “Oracle” retrievalにおいてコンテキスト長が短いモデルは以下のように不利である

5. RESULTS

• 全体として、言語モデルはまだ大規模コードベースの任意箇所を効果的に修正できるレベルにまで到達できていないことが示唆される結果となった。コンテキストを適切に絞り込み、パッチの生成タスクを効率的に進めるための工夫が今後の課題と言える。

• リポジトリ間で難易度が異なる
• モデルの性能をリポジトリごとに比較すると、おおまかな傾向は似通っているものの、同じインスタンスを解決しているとは限らない。たとえば “oracle” 設定では、Claude 2 が 110 件、SWE-Llama 13b が 91 件を解決しているが、その重複は 42% 程度にとどまる。
• 一部リポジトリには画像が多く含まれる問題があり、マルチモーダルな処理や外部ツールの活用が必要になる可能性がある（例：matplotlib、seaborn）。

• コンテキストの長さが増すほど解決が難しくなる
• 通常、チャットモデルは大規模なコードで事前学習されているが、実際の使われ方では短いスニペットの生成を求められることが多い。本タスクでは関連性の低いコードが大量に含まれることで、問題の所在を見つけ出すのに苦戦していると推測される。
• Claude 2 を例にすると、コンテキストが長くなると正解率が大幅に下がる傾向にある。これは他モデルでも同様に観察される。
• “oracle” 設定をさらに単純化した “oracle-collapsed”（実際に編集が行われた行とその前後 15 行だけを提供する）設定にすると、GPT-4 や Claude 2 などのモデルは性能が向上した。

• イシューの解決時期（リポジトリ上のプルリクエスト作成日）と難易度は相関しない
• PR 作成日が 2023 年以前か以降かで分割した場合、多くのモデルにおいて性能に大きな差は見られなかった（GPT-4を除く）。
• これはモデルの学習に該当レポジトリのコードベースが使われてたと仮定して、そのリポジトリの内容を「そのまま思い出して解答している」といった可能性が低いことを示しており、ある程度フェアな評価ができていると考えられる。

• ファインチューニングしたモデルはコンテキスト分布の変化にセンシティブ
• “oracle” のコンテキスト（実際に編集されたファイルだけを入力に含む）を使って学習した SWE-Llama 7b/13b は、BM25 で検索したコンテキストを与えた場合には性能が落ちる。
• これはトレーニング時のコンテキスト分布と推論時の分布がずれているためと考えられる。BM25 で取得されるファイル群のなかには、実際には変更不要なコードが含まれることが多いため、モデルが「不要なファイルもすべて編集しようとする」可能性がある。

• パッチ（差分）を生成するほうが、ファイル全体を再生成するより容易
• 本タスクではパッチファイル（差分）を生成するように設計しているが、全ファイルを生成させる実験を行ったところ、全ファイルを生成させるほうが性能が下がる傾向にあった。
• Claude 2 を例にとると、“oracle” 設定でパッチファイルを生成する場合の正解率は 4.8% だが、全ファイル生成では 2.2% に低下した。

• 言語モデルは比較的短く単純な修正を行いがち
• モデルが生成するパッチの平均行数はゴールドのパッチ（実際に行われた修正）よりも半分以下の傾向がある。
• また、モデル生成パッチでは複数ファイルをまたぐ修正はあまり行われず、一つのファイルのみの修正に留まることが多い。

5.1 A QUALITATIVE ANALYSIS OF SWE-LLAMA GENERATIONS

• “oracle” リトリーバル設定下で、SWE-Llama と Claude 2 が生成した 11 件の出力を分析し、なぜテストに失敗するのか・どのような修正が行われたのかを詳しく調査し、Sphinx のドキュメント生成ツールの事例（sphinx-doc sphinx-8713）では、モデルは部分的には正しい修正箇所を特定できる一方、設定やコードスタイルの一貫性などの重要な要素を考慮しきれない場合があることがわかった。
• タスクの背景: Sphinx の napoleon 拡張機能が「Other Parameters」というキーワードを正しくフォーマットせず、原因として が True のときの処理に問題があると指摘されている。Issue にはソースコードの該当箇所や再現手順、使用しているパッケージのバージョンなどの詳細な情報が含まれていた。
• モデルの生成結果とゴールドパッチ比較
• SWE-Llama は、該当する関数 （ の 684 行目）を修正しようとしていた点では合っていた。
• しかし、問題設定である の値を実際に確認せず、常に True であるかのように扱っていたため、 を設定したテストで失敗した。
• 一方、ゴールドパッチでは の値をきちんとチェックし、 関数の挙動を参考に修正しているため、テストを通過している。
• 全体的な傾向
1. 原始的な Python コードを生成しがち: モデルはサードパーティライブラリや既存コードベースをうまく活用しない。
2. 問題解決のみを最優先し、コードスタイルや論理的一貫性を軽視: たとえば相対インポートを使用しないなど、コードベースで一般的に用いられているスタイルや方針を無視しがち。
3. ゴールドパッチの方が広い範囲での構造的改善を施している: ゴールドパッチは問題の本質的な解決だけでなく、将来的な問題を未然に防ぐための修正も含んでおり、より完成度の高い変更になっている。

6. RELATED WORK

1. Evaluation of LMs（言語モデルの評価）

• 従来のLM評価手法の多くは、ドメインをまたぐ多種多様なタスクを寄せ集めたベンチマークや、ウェブ上の複数ステップを要する対話型タスクを用いることが多いが、このようなアプローチは一つひとつのタスクが特定のスキルにしか焦点を当てず、モデルの多様な能力や新たなスキルの発揮を妨げるという問題がある。結果としてモデルがどのように性能を伸ばせるかという深い示唆が得にくい。

• SWE-bench は、このような問題点を解消しつつ、現実のソフトウェア開発の複雑な課題を扱う大規模データセットであり、評価タスクを継続的にアップデートできる点が強みである。

2. Code Generation Benchmarks（コード生成ベンチマーク）

• HumanEval（Chen et al., 2021）は、言語モデルによるコード合成評価の主要ベンチマークとなっているが、これを拡張した研究（他言語対応や多彩なコード編集タスクなど）も近年盛んに行われている。ただし従来の多くのベンチマークは、問題をシンプルに保つために人工的に分割・加工しているものが多い。

• SWE-bench では、実際のリポジトリからコードを最小限の事後処理だけで取り込み、複数モジュールにまたがる依存関係や長大な文脈の処理など、より現実的かつ高度なソフトウェア開発タスクを扱うことが特徴である。

3. ML for Software Engineering（ソフトウェア工学における機械学習）

• ソフトウェア工学では、従来のプログラム解析手法のスケーラビリティや自然言語との統合の難しさを克服するため、言語モデルを含むニューラルネットワークの活用が研究されている。具体的には、コミットの自動生成、PR レビュー、バグの局所化、自動テスト、プログラム修正などの分野で多くの研究が行われている。

• SWE-bench はとりわけ自動プログラム修正（program repair）タスクに関連し、従来のデータセットが扱わない大規模コードベースや多彩な実世界のシナリオを含む点で非常に拡張性が高く、LM とソフトウェア工学ツールの統合を進める上で有用なベンチマークとなっている。

おまけ

• SWE-bench leaderboard
SWE-bench
SWE-bench: Evaluate Language Models on Open Source Software Tasks
https://www.swebench.com/

• Kaggle competition Konwinski Prize
Konwinski Prize
$1M for the AI that can close 90% of new GitHub issues
https://www.kaggle.com/competitions/konwinski-prize/leaderboard

• Devin by Congnition labs
Cognition | SWE-bench technical report
We are an applied AI lab building end-to-end software agents.
https://www.cognition.ai/blog/swe-bench-technical-report