2024-12-24 機械学習勉強会
今週のTOPIC[blog] Kaggle画像コンペでやっていること[blog]AI・機械学習チームベストMR(Merge Request)決定戦 2024[blog] Eval-Centric AI: LLM-as-a-Judge on Vertex AI[blog] LLMを活用したアノテーション基準書作成支援[blog] ModernBERT のブログを読んでみた感想メインTOPIC[論文]SWE-BENCH: CAN LANGUAGE MODELS RESOLVE REAL-WORLD GITHUB ISSUES?Summary by ChatGPT o11. INTRODUCTION2. SWE-BENCH2.1 BENCHMARK CONSTRUCTION2.2 TASK FORMULATION2.3 FEATURES OF SWE-BENCH2.4 SWE-BENCH LITE3. SWE-LLAMA: FINE-TUNING CODELLAMA FOR SWE-BENCH4 EXPERIMENTAL SETUP4.1 RETRIEVAL-BASED APPROACH4.2 INPUT FORMAT4.3 MODELS5. RESULTS5.1 A QUALITATIVE ANALYSIS OF SWE-LLAMA GENERATIONS6. RELATED WORK1. Evaluation of LMs(言語モデルの評価)2. Code Generation Benchmarks(コード生成ベンチマーク)3. ML for Software Engineering(ソフトウェア工学における機械学習)おまけ
今週のTOPIC
※ [論文] [blog] など何に関するTOPICなのかパッと見で分かるようにしましょう。
出典を埋め込みURLにしましょう。
@Naoto Shimakoshi
[blog] Kaggle画像コンペでやっていること
- K_matさんの神記事。全4回あるが、コンペ関係なしに知っておくと良い話が多い。
- K_matさんでもこの部分はこれくらいの調整しかしないのか、などが分かるのがとても良い。
- 当たり前の言語化や論文などを根拠とした説明がすごい。
解像度の調整一つとっても
たとえば画像全体からめちゃくちゃ小さいものを見つけたいときは、むやみに解像度を落とせません。しかし一方で、限られた時間でコンペをやるためには実験効率も重要ですので、序盤から過度に高い解像度は避けたいところです。また、限られた推論時間で実行するコードコンペでは、実行速度もある程度意識したいところです。たとえばこの例であれば、モノが小さいしコンテクストはそれほど重要ではなさそうなので浅いモデルでさばこうかな、という選択肢がでてきます。こういったトレードオフを意識しつつ戦略を練るのもコンペの醍醐味の一つですね! 逆に対象物が大きい時には画像全体を見渡せるような解像度とモデルが必要になると思います。たとえば、1024x1024のような大きい入力画像を軽量な浅いモデルで処理する場合は、本当に画像全体が見えているのかどうかが考えどころです。解像度をさげるか、モデルを大きくする選択肢を持ちたいところです。
- 個人的に面白かった部分
- 画像(NN)の特徴量エンジニアリング
- 微小値の変化をNNに見つけてもらうのは難しい、というのは納得感があった。0.0が欠損だとして、0.001とは全然違う意味なら0.0のmaskを与えた方がいいのではなど。
- 重要な特徴量が少しの次元しかない場合、多次元の方から学習してしまいがち。強制的に重要な特徴量を見て欲しい時に、片方に強めのDropoutをかけるなど。
- (自分は重要な特徴を前段と最後のLinearの前に入れたりする)
- 特徴量の質によって混ぜ方を変える。
- 画像のchannel方向に全部入れるのではなく、色々工夫をする。
- 最初に混ぜる
- Convをかましてから混ぜる
- ランクの違うものを混ぜる時は、Attentionなどで混ぜる
- オプティカルフローの動きを踏まえて、カメラ自身の動きと撮影対象の動きを切り分ける。
- Lossの工夫
- ラベルに含まれない追加情報は積極的に活用する
- 訓練にしかない付加的な情報の利用。自分は2-stageとかで2段階目で活用したりすることが多いですが、NNのLossとして使うことも有効。
- ラベルよりリッチな情報は積極的に活用する
- 確かになあという話。
- 自分は割と補助ロス的な使い方をNNにすると上手くいかないことが多いんですが、それにも言及されてました。
- loss weightを調整して、弱くしても効かないなら諦める。
- detectionとかと同じように早めのBranchで切って遠ざける。
- Lossではなく、モデル側の出力に制約をかける。
- タスク専用モデルの話
- これはめちゃおもろいので、是非原本を読んでください。人が認識するときのお気持ちをどうモデルに組み込むかの話です。
- https://qiita.com/Kmat67916008/items/d7586a28e6ec8595d579#タスク専用モデルの例nflプレイヤ間の衝突予測
■ モデルは知らないが、自分は知っていること ⇒ 積極的に与える■ モデルにとってわかりにくい部分 ⇒ 優しく加工する
逆に、ラベルよりも情報が少ないタスクを解かせても補助ロスは効きにくいことも多いです。極端な例ですが、犬の画像のセグメンテーションをするときに、画像に犬が含まれるかどうかのサブタスクを解いてもそれほど効果はありません。
@Yuya Matsumura
[blog]AI・機械学習チームベストMR(Merge Request)決定戦 2024
昨年もピックして紹介した気がする、エムスリーさんのAI・機械学習チームの1年間のMR(ライブラリアップデート系除いても1000件以上あるらしい)の中からトップ10を選ぶ企画
- 第7位(同率) Kubernetesクラスター都合でのバッチの中断をリトライ回数にカウントしない
- GKEの仕方のない(リソース配置最適化など)バッチの中断・再実行をリトライ回数に加算しない。
- ‣
- 第7位(同率) gokartへのmypy pluginの追加
- 第5位 gokartのlinterを追加
- ‣
- みんなのベストプラクティスを集合知としてlintに反映している。ひとりいちプロダクトを担当することが多いからこそこのような動きが重要。
- 独自ルールを設定するためにruffとは別にPylintを回しているよう。
- 第2位 TaskOnKartへ型を追加
- gokart の改善を着々と行っていてすごい。どういう座組で改善に取り組んでいるのか気になる。
- 第6位 ある日突然BigQueryのdownloadが遅くなっていました。さてなぜでしょう?
- pandas-gbq で BigQuery Storage API が気づいたらデフォルトでオフになっていたという聞き覚えのある。みんなちゃんと気づいて対応できていてすばら。
- PRのタイトルこれでいいんだw
- 第1位 ロードバランサー一括監視
- 横断組織なのでたくさんプロダクトを持っていてロードバランサーの監視の設定が大変なので、ひとつの設定でうまいこといくようにした。どうやったんだろ。
- 全体を通して、このような取り組みをどのように実施しているのかが気になった。いいチームだ。
@Yuta Kamikawa
[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を便利!
@Shun Ito
[blog] LLMを活用したアノテーション基準書作成支援
- シェルパ・アンド・カンパニー株式会社
- 背景: 企業が投資家向けに公開しているESG情報のアノテーション
- ESG: Environment, Social, Governance
- 例えばEnvironmentなら、生物多様性、温室効果ガス、廃棄物などの分野がありますし、それぞれ目標はどうなのか、どの程度実現しているのかなどを記載する
- ESGの内容を分析・可視化するサービス SmartESG を開発しており、そのラベル予測のためにアノテーションしたい
- 例えば「大気汚染物質の排出削減」という項目が positive か negative か
- 前年からの削減率を記載していれば十分なのか、それとも現在の排出量も記載していなければならないのか、といった基準を決める必要がある
- 課題
- 人(専門家)がアノテーション基準を作る以上、条件の考慮漏れが発生する
- 大規模データセット作成のため非専門家がアノテーションする場合、基準を正しく理解できるとは限らない
- やったこと: アノテーション基準書のLLMによる評価
- LLMを非専門家のアノテーターと捉える
- アノテーション基準書に基づいてLLMに予測させ、その結果に基づいて基準書を修正する
- 手順
- 専門家が、ラベルの説明とその判断基準、それに該当する例と該当しない例を用意
- 判断基準に基づいて、該当例と非該当例をLLMでアノテーション(予測の理由も出力する)
- アノテーションが合っているかを確認し、結果に基づいて基準書をアップデートする
- LLMアノテーションはGitHub PRから実行できる仕組みを用意
- やってみた上での専門家のコメント
- 基準が曖昧だったり分かりにくい場合は、期待と異なる予測結果が返されるので、修正箇所の特定が容易に行える。
- 専門知識があると、説明を忘れてしまったり、説明が甘くなってしまう場合がある。また、1人で定義を作成していると、1つの流れに凝り固まってしまう場合がある。しかし、機械による客観的な判断が入ることで、1人では気付かなかった問題点に気付くことができる。
- 定義に入れるべき内容だけでなく、省くべき内容も明確になる。
@qluto (Ryosuke Fukazawa)
[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?
Carlos E. Jimenez* (1,2), John Yang* (1,2), Alexander Wettig (1,2), Shunyu Yao (1,2), Kexin Pei (3), Ofir Press (1,2), Karthik Narasimhan (1,2)
(1) Princeton University, (2)Princeton Language and Intelligence, (3)University of Chicago
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 種類の手法で関連するファイルのみを抽出し、モデルに与えるベースラインを構築する。
- Sparse retrieval (BM25)
- 自然言語で書かれた問題文をクエリとし、BM25を用いてコードファイルを検索し、得られた関連ファイルをモデルへ入力する。
- モデルのコンテキスト上限に応じてファイル数を調整し、複数の上限値で評価。
- “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 であるかのように扱っていたため、 を設定したテストで失敗した。
- 一方、ゴールドパッチでは の値をきちんとチェックし、 関数の挙動を参考に修正しているため、テストを通過している。
- 全体的な傾向
- 原始的な Python コードを生成しがち: モデルはサードパーティライブラリや既存コードベースをうまく活用しない。
- 問題解決のみを最優先し、コードスタイルや論理的一貫性を軽視: たとえば相対インポートを使用しないなど、コードベースで一般的に用いられているスタイルや方針を無視しがち。
- ゴールドパッチの方が広い範囲での構造的改善を施している: ゴールドパッチは問題の本質的な解決だけでなく、将来的な問題を未然に防ぐための修正も含んでおり、より完成度の高い変更になっている。
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
- Kaggle competition Konwinski Prize
- Devin by Congnition labs