Someone said, "We were expecting strawberry, but they released kale." Let's see what this "kale" is used for.
The programming capabilities of large models have always attracted much attention, and the emergence of super-powerful AI programmer Devin has pushed the topic of "Can AI replace programmers" to the forefront. Recently, Devin has also welcomed a new opponent - the autonomous AI programmer Genie launched by the startup Cosine. The company said Genie easily outperformed Devin, scoring 30% on the third-party benchmark SWE-bench, while Devin scored just 13.8%.
This SWE-Bench is a benchmark dataset used to evaluate LLM’s ability to solve real software problems on GitHub. It collects 2,294 Issue-Pull Request pairs from 12 popular Python repositories. During testing, LLM will get a code base and issue description, and then generate a patch to solve the problem described in the issue. This dataset has been widely used in the assessment of AI programming abilities. As AI programming capabilities evolve, so does this benchmark. Early this morning, the OpenAI "Strawberry" model reported online was delayed again, but OpenAI did release something new, which is an improved version of SWE-Bench - SWE-bench Verified. OpenAI pointed out that the original SWE-bench has some issues that may lead to the model’s autonomous software engineering capabilities being underestimated. Therefore, during the improvement process, they worked with the original SWE-Bench authors to perform manual screening and improvements to ensure that the scope of the unit tests was appropriate and the problem description was clear. In a new test on SWE-bench Verified, many AI programming agents scored higher than before. Among them, UIUC's Agentless solution even doubled the score. OpenAI believes that this proves that the previous benchmark does have the flaw of underestimating AI programming capabilities. But for netizens all over the world who are watching "Strawberry", this announcement is still too perfunctory. Someone said, "We were expecting strawberries, but they released kale."
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-benchの堅牢性と信頼性を向上させる3つの改善の方向性SWE-benchの堅牢性と信頼性を向上させるために。開発チームは、改善のための 3 つの主な方向性を特定しました:
- ソリューションの正しさを評価するために使用される単体テストは、多くの場合、あまりにも具体的であり、場合によっては問題に関連性さえありません。これにより、正しいソリューションが拒否される可能性があります。
- 多くのサンプルの問題の説明は十分に明確ではなく、問題が何であるか、そしてそれをどのように解決すべきかが曖昧になっています。
- エージェント用に SWE ベンチ開発環境を確実にセットアップすることが難しい場合があり、そのため、ソリューションに関係なく、単体テストが誤って失敗する可能性があります。この場合、完全に有効な解決策が不正確であると評価される可能性があります。
これらの問題に対処するために、OpenAIは、SWEベンチテストセットのすべてのサンプルに対してプロのソフトウェア開発者による人間による注釈キャンペーンを開始しました 単体テストを確実にするためにスクリーニングが行われます範囲が適切に定められており、問題の説明が明確かつ明確になっています。 SWE-bench の作成者と協力して、SWE-bench Verified をリリースしました。これは、人間のアノテーターによって検証された 500 個のサンプルを含む、SWE-bench のオリジナルのテスト セットのサブセットです。このバージョンは、オリジナルの SWE-bench および SWE-bench Lite テスト スイートを置き換えます。さらに、すべての SWE ベンチ テスト サンプルに対して人間による注釈をリリースしています。 また、彼らは SWE-bench の作成者と協力して、SWE-bench での評価をより簡単にするためにコンテナ化された Docker 環境を使用する 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 ベンチランキングで良好なパフォーマンスを示した複数のエージェントを使用しました オープンソースscaffold は GPT-4o のパフォーマンスをテストします。 最高のパフォーマンスのスキャフォールドでの GPT-4o のパフォーマンスは、検証済みの SWE ベンチで 33.2% に達したことがわかりました。これは、元の SWE ベンチのスコア 16% の 2 倍以上です。全体として、これは、元の SWE ベンチがエージェントの能力を過小評価しているという OpenAI の当初の疑惑を裏付けています。 SWE-bench Lite から SWE-bench Verified への移行はそれほど目立ちません。これは、フィルタリング後、SWE-bench Lite が完全なデータセットよりもすでに簡単であるためです。
SWEベンチ検証で評価した場合、パフォーマンスの向上は部分的には、テストサンプルの分布がより単純なサンプルに偏っていることによるものである可能性があります。 OpenAI は、難易度によって階層化されたパフォーマンスをプロットすることでこれを調査しました。新しいデータセットが単純に難易度分布を変更して、より簡単なサンプルを含めた場合、元の SWE ベンチから SWE ベンチ Lite への場合と同様、各カテゴリ内の層別パフォーマンスは変わりません。 対照的に、OpenAI は、SWE ベンチ検証済みに切り替えると、エージェントのパフォーマンスが難易度カテゴリ全体で向上することを観察しました。これは、単に難しいサンプルを削除するのではなく、すべてのカテゴリから不可能なサンプルを削除するという予想される効果と一致しています。
参考リンク:https://openai.com/index/introducing-swe-bench-verified/The above is the detailed content of The OpenAI "Strawberry" model has been delayed again. What is the SWE-bench Verified released in the early morning?. For more information, please follow other related articles on the PHP Chinese website!
Statement:The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn