ニュース

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

マシンハートレポート

編集者: Zhang Qian、Xiaozhou

ある人は、「イチゴを期待していたのに、ケールをリリースしました。」この「ケール」が何に使われるのか見てみましょう。

大型モデルのプログラミング能力は常に大きな注目を集めてきましたが、超強力な AI プログラマー Devin の出現により、「AI はプログラマーに取って代わることができるか」という話題が最前線に浮上しました。最近、デビンはまた、新興企業コサインが立ち上げた独立系 AI プログラマーという新たな敵を迎え入れた。ジーニー。同社によると、GenieはサードパーティのベンチマークであるSWEベンチで30％のスコアを記録し、デビンを軽々と上回ったのに対し、デビンはわずか13.8％のスコアを記録したという。

この SWE-Bench は、GitHub 上の実際のソフトウェアの問題を解決する LLM の能力を評価するために使用されるベンチマーク データ セットです。 12 の人気のある Python リポジトリから 2,294 の Issue-Pull Request ペアを収集します。テスト中に、LLM はコード ベースと問題の説明を取得し、問題に記載されている問題を解決するパッチを生成します。このデータセットは、AI プログラミング能力の評価に広く使用されています。

AI プログラミング機能が進化するにつれて、このベンチマークも進化します。今朝早く、オンラインで報告された OpenAI の「Strawberry」モデルは再び遅れましたが、OpenAI は新しいものをリリースしました。これは SWE-Bench - SWE-bench Verified の改良版です。

OpenAIは、元のSWEベンチにはモデルの自律型ソフトウェアエンジニアリング能力が過小評価される原因となった可能性のあるいくつかの問題があったと指摘した。したがって、改善プロセス中に、SWE-Bench のオリジナルの作成者と協力して手動のスクリーニングと改善を実行し、単体テストの範囲が適切であり、問​​題の説明が明確であることを確認しました。

SWE-bench Verified で実施された新しいテストでは、多くの AI プログラミング エージェントが以前よりも高いスコアを獲得しました。その中で、UIUC のエージェントレス ソリューションではスコアが 2 倍にもなりましたが、これは以前のベンチマークに AI プログラミング能力を過小評価するという欠陥があったことを証明していると OpenAI は考えています。

しかし、「ストロベリー」を見ている世界中のネチズンにとって、今回のリリースはまだおざなりすぎる。 「イチゴを期待していたのに、ケールが出てしまった」と言う人もいた。

SWE ベンチに関する背景知識

SWE ベンチ テスト セットの各サンプルは、GitHub 上の 12 のオープン ソース Python コード リポジトリで解決された GitHub の問題から作成されました。各サンプルには、ソリューション コードとコードの正しさを検証するための単体テストを含む関連するプル リクエスト (PR) が含まれています。これらの単体テストは、PR 内のソリューション コードが追加される前に失敗し、追加された後に合格するため、FAIL_TO_PASS テストと呼ばれます。各サンプルには、PR がマージされる前後に合格する PASS_TO_PASS テストも含まれており、PR が問題に関係のないコード ベースの他の機能を妨げるかどうかを確認します。

SWE-bench では、AI エージェントは GitHub の issue から問題ステートメントである元のテキストを取得し、コード ベースにアクセスします。この情報が与えられた場合、エージェントはコード ベース内のファイルを編集して問題を解決する必要があります。

AI エージェントによって与えられた編集は、FAIL_TO_PASS テストと PASS_TO_PASS テストを実行することによって評価されます。 FAIL_TO_PASS テストに合格した場合は、エディターが問題を修正したことを意味します。 PASS_TO_PASS テストに合格した場合、編集によってコード ベースの無関係な部分が破壊されなかったことを意味します。元の GitHub の問題を完全に解決するには、両方のテスト セットに合格する必要があります。

SWEベンチの堅牢性と信頼性を向上させるための3つの改善の方向性

SWEベンチの堅牢性と信頼性を向上させるため。開発チームは、改善のための 3 つの主な方向性を特定しました。

• ソリューションの正しさを評価するために使用される単体テストは、多くの場合、具体的すぎるため、問題と関連性さえありません。これにより、正しいソリューションが拒否される可能性があります。
• 多くのサンプルの問題の説明は十分に明確ではなく、問題が何であり、それをどのように解決すべきかについてあいまいさが生じていました。
• エージェント用の SWE ベンチ開発環境を確実にセットアップすることが難しい場合があり、ソリューションに関係なく、単体テストが誤って失敗する可能性があります。この場合、完全に有効な解決策が不正確であると評価される可能性があります。

SWEベンチ検証済み

これらの問題に対処するために、OpenAI はプロのソフトウェア開発者による手動のアノテーション キャンペーンを開始し、SWE ベンチ テスト セットの各サンプルをスクリーニングして、単体テストの範囲が適切に設定され、問題の説明が明確かつ明確であることを確認しました。

SWE-bench の作成者と協力して、SWE-bench Verified をリリースしました。これは、人間のアノテーターによって検証された 500 個のサンプルを含む、SWE-bench のオリジナルのテスト セットのサブセットです。このバージョンは、オリジナルの SWE-bench および SWE-bench Lite テスト セットを置き換えます。さらに、すべての SWE ベンチ テスト サンプルに対して人間による注釈をリリースしています。

また、SWE-bench の作成者と協力して、コンテナ化された Docker 環境を使用して SWE-bench での評価をより簡単かつ信頼性の高いものにする SWE-bench 用の新しい評価ツールを開発しました。

• ツールのアドレス: https://github.com/princeton-nlp/SWE-bench/tree/main/docs/20240627_docker

改善方法

OpenAI は、Python の経験を持つ 93 人のソフトウェア開発者と協力して、SWE ベンチ サンプルを手動でスクリーニングし、SWE ベンチ テスト セット内の 1699 個のランダム サンプルに注釈を付け、最終的に SWE ベンチ検証済みを取得しました。

彼らのアプローチは、SWE ベンチ テスト セット内のサンプルに注釈を付けて、テストの公平性と正確性を確保することです。具体的には、2 つの重要な点に焦点を当てています。1 つは、問題の説明が、あまりにも曖昧な説明によって不公平なテストが引き起こされるのを防ぐのに十分なほど詳細であるかどうかを評価すること、2 つ目は、FAIL_TO_PASS 単体テストが有効な解決策を誤って除外するかどうかを確認することです。

各注釈基準には、[0、1、2、3] の範囲のラベルがあり、重大度が増加します。ラベル 0 と 1 は軽度であり、ラベル 2 と 3 は重度であり、サンプルが何らかの点で不適切であり、破棄する必要があることを示します。

さらに、OpenAI は、サンプルに問題がないと仮定して、開発者がソリューションを決定して実装するまでにどれくらいの時間がかかるかをアノテーターに推定させることで、各サンプルの難易度を評価します。最後に、OpenAI は、サンプルに関する他の重大な問題にフラグを立てるための自由形式の入力オプションを提供します。

SWE ベンチ検証済みを構築するために、OpenAI は元のテスト セットから、問題ステートメントまたは FAIL_TO_PASS 単体テストの重大度が 2 以上のサンプルをフィルターで除外し、他の重大な問題がマークされたサンプルもフィルターで除外します。

結果に注釈を付ける

新しい基準によれば、元の SWE ベンチのサンプルの大部分は不適格です。図に示すように、サンプルの 38.3% には、問題の記述が十分に明確ではないという理由でフラグが付けられ、61.1% には、単体テストで有効な解決策に不当に間違ったフラグが付けられる可能性があるという理由でフラグが付けられました (重大度 2、3 2 つのレベルを合計します)。 。全体として、アノテーション プロセスの結果、不明瞭な問題記述、不公平な単体テスト、またはその他の問題により、SWE ベンチ サンプルの 68.3% が除外されました。

以下の図は、元の SWE ベンチ データセットと新しい SWE ベンチ検証済みデータセットの難易度分布を比較しています。彼らは、1699 サンプルのランダムなサブセットに基づいて SWE ベンチの難易度分布を推定しました。

図からわかるように、元の SWE ベンチ データ セットでは、ほとんど (77.8%) のサンプルの推定完了時間は、経験豊富なソフトウェア エンジニアの作業時間 1 時間未満です。 SWE-bench Lite と新しい SWE-bench Verified データセットではこの割合がさらに増加し​​、解決に 1 時間以上かかると予想される問題は 10% 未満です。ただし、この変更の背後にあるメカニズムはまったく異なります。SWE-bench Lite はベンチマークを容易にするために元のデータセットのサブサンプリングですが、SWE-bench Verified はデータセット サンプルから実行不可能な機能を削除しようとします。

SWEベンチでの各エージェントのパフォーマンスを検証済み

新しい SWE ベンチ検証済みデータセットで、開発チームは、元の SWE ベンチ リーダーボードで良好なパフォーマンスを示した複数のオープンソース スキャフォールドを使用して GPT-4o のパフォーマンスをテストしました。

最も優れたパフォーマンスのスキャフォールドでの GPT-4o のパフォーマンスは、検証済みの SWE ベンチで 33.2% に達し、元の SWE ベンチのスコア 16% の 2 倍以上であることがわかりました。全体として、これは、元の SWE ベンチがエージェントの能力を過小評価していたという OpenAI の当初の疑惑を裏付けています。

SWE-bench Lite から SWE-bench Verified への移行はそれほど明白ではないことに注意してください。これは、フィルター処理後、SWE-bench Lite の方が完全なデータセットよりも既に簡単であるためです。

難易度別に階層化されたパフォーマンス分析

SWE-bench Verified で評価した場合のパフォーマンスの向上は、テスト サンプルの分布がより単純なサンプルに偏っていることに部分的に起因している可能性があります。

OpenAI は、難易度ごとに層別のパフォーマンスをプロットすることでこれを調査しました。新しいデータセットが単純に難易度分布を変更して、より簡単なサンプルを含めた場合、元の SWE ベンチから SWE ベンチ Lite までの場合と同様、各カテゴリ内の層別パフォーマンスは変わりません。

対照的に、OpenAI は、SWE ベンチ検証済みに移行すると、エージェントのパフォーマンスが難易度カテゴリ全体で向上することを観察しました。これは、単純に「難しいサンプルを削除」に移行するのではなく、すべてのカテゴリから不可能なサンプルを削除することで予想される効果と一致しています。

参考リンク：https://openai.com/index/introducing-swe-bench-verified/