6,319 文字
衝撃的な新事実として、研究者たちはOpenAIが主張したベンチマークが実世界の問題において真実ではないことを発見しました。もしこの後の少し退屈な内容を見たくない場合は、私が文字通り2つのツイートを読み上げるだけなので、要点をお伝えします。
OpenAIはanweベンチマーク（swe：ソフトウェアエンジニアリングベンチマーク）において、LLMやエージェントに与えられたGitHubの課題を解決する能力を測定しました。LLMやエージェントが解決できた課題の数がベンチマークとなり、40%は100の課題のうち40のGitHub課題が解決されたことを意味します。
OpenAIは48%のベンチマークを主張しましたが、研究者たちは実世界のGitHub課題では30%しか真実ではないことを発見しました。実際、最も驚くべきことは、Claude 3.5 Sonnetが53%を達成していることです。これによって、OpenAIの主張と実生活での真実との間に大きな混乱が生じました。
このビデオでは、何が起こったのか、そしてその可能な理由について探っていきます。OpenAIは本当に露骨に嘘をついたのか、それとも他に何か理由があるのか、そしてどのようにしてベンチマークスコアを選んだのかについて見ていきましょう。
これはAlexandru Cojocanuから始まりました。彼らは最新の論文で驚くべき発見をしました。OpenAIの推論能力の高いモデルが、SWE-benchの検証済みデータセットで30%しか達成できなかったというものです。SWE-benchには2種類のデータセットがあり、1つはSWE-bench、もう1つはSWE-bench verifiedで、後者はより洗練された、クリーンアップされたバージョンです。これは元々主張されていた48.9%をはるかに下回っています。
さらに興味深いのは、Claudeが同じフレームワークで53%を達成したことです。ここで最も重要なのは、彼らがフレームワークとして主張しているものです。これらのLLMがSWE-benchで使用される時、LLMそのものとしてではなく、ある種のスキャフォールディング方式を使用しています。スキャフォールディング方式は、LLMがワークフローに従って特定のGitHub課題を解決する機会を得るようなエージェント環境の一種です。
OpenAIの強化された推論について何かがおかしいのです。Open Handsという独自のスキャフォールディング方式を持つAll Hands AIで私たちはOpenAIをテストしました。Open HandsではLLMが完全に自由に計画を立て行動することができます。現在の重要なエージェント的な振る舞いと、みんなが興奮している推論モデルは、計画を立てて行動できることです。
現在、SWE-bench課題を解決するために利用できる最良のオープンソースフレームワークがOpen Handsです。これが私が先ほどスキャフォールディング方式として言及したもので、エージェントレスとは大きく異なります。エージェントレスはOpenAIが選んだものです。
現在のSWE-bench verifiedベンチのリーダーボードを見ると、トップ3が異なっています。1位はAmazon Q developer agent（おそらくAmazonのAWSエコシステムまたはBedrock エコシステム内でのみ使用）、2位はDevo（これも非公開）、そして公開されている方式はOpen Hands + Code LLM（Claude 3.5 Sonnet 20241022搭載）です。これは新しいClaude 3.5モデルとCode LLMを組み合わせ、Open Handsと統合したもので、53%を達成しています。
しかし、OpenAIは自身のベンチマークでこれを使用せず、異なるものを使用して41%を達成したと主張しています。これは、over preview、over preview post mitigation、over preview pass oneの中で最高のものでした。
ここで何が起きているのかが、みんなが疑問に思っているところです。OpenAIは、エージェントレスがベストパフォーマンスのオープンソーススキャフォールドであるため、これを選択したと述べています。Open Handsが最良だとは言っていません。
しかし、このレポートは2024年12月5日のもので、Open HandsはSWE-benchリーダーボードで10月29日から首位を維持していました。では、なぜエージェントレスを選んだのでしょうか？
OpenAIに疑いの利益を与えるなら、彼らのチームがこのベンチマークに取り組んでいて、その後2024年12月5日にOpen Handsが首位になった可能性は十分にあります。私はデータサイエンティストですが、この種のことは私の仕事でもよく起こります。コスト見積もりなどに取り組んでいて、数週間後に誰かが間違いを指摘することがあります。それは、データセットが後で更新され、私たちがそれを知らずにグラフを更新していなかったために自然に発生した間違いかもしれません。
これは私がOpenAIを公平な立場に置いた場合の解釈です。しかし、このビデオはそれについてではありません。
では、なぜエージェントレスを選んだのか、これは研究者たちが理解しようとしているところです。エージェントレスは3つのフェーズを採用しています：ローカライゼーション、修復、パッチ検証です。これらはLLMに将来の行動を決定させることなく行われます。
これに対して、Open HandsではLLMが完全に自由に計画を立て行動することができ、これは推論モデルにとって本当の恩恵となります。エージェントレスの固定アプローチは、SWE-benchのリポジトリを記憶しているモデルを優遇している可能性があります。しかし、なぜOpenAIは推論能力があるにもかかわらず、真の自由な計画立案で苦戦しているのでしょうか？
これについてはまだ決定的な答えがありません。私たちは、エージェントとしての推論重視モデルの動作に根本的な問題があると考えています。これはテスト時の計算に関する私たちの理解を変える可能性のある課題です。
私たちはこの真実を明らかにするために懸命に取り組んでおり、スキャフォールディングのプロセスである「トレース」をオープンソース化し、コミュニティの誰もが何が問題だったのかを発見できるようにしています。データセットはHugging Faceで共有されており、YouTubeの説明欄にリンクを掲載します。
これで終わりではありません。彼らが本質的に言おうとしているのは、OpenAIが選んだフレームワークは明らかにOpenAIに有利だということです。そうでなければ、誰もそのフレームワークを選んで論文に掲載し、プレスリリースの一部にすることはないでしょう。
彼らが言っているのは、OpenAIが選んだフレームワークはLLMの能力を正当に評価していない可能性があるということです。これは私の理解では、主にそのフレームワークがリポジトリを実際に記憶しているこれらのLLMに有利に働くためかもしれません。そのため、タスクが実世界に変換された時、これらのモデルは実際に起こっていることの現実を反映していません。なぜなら、それがトレーニングデータの一部ではないため、何らかの理由でそれを記憶していなかったかもしれないからです。
先ほど言ったように、SWE-benchは基本的にGitHub課題を解決することです。LLMがすでにGitHubリポジトリをよく知っているなら、それは全く異なるゲームになるかもしれません。そのようなことがここで起こっている可能性があります。
トレースはここにあるので、より詳細を見ることができます。後でもっと深く掘り下げるかもしれませんが、同じグループの別の研究者が同じ質問に答えようとしています。
よく「なぜOpenAIはOpen Handsではそれほど良くないのに、公式レポートではSWE-benchで良好な結果を示しているのか」という質問を受けます。この特定のケースでは、OpenAIのような推論モデルは、エージェントレスのようなワークフローベースのスキャフォールドを使用した場合、SWE-benchでかなり良い成績を収めています。このケースでは、スキャフォールド自体がモデルの問題を分解しています。
彼らが言おうとしているのは、この48%の達成は単にモデルの能力だけによるものではなく、彼らが選んだ方法、つまりスキャフォールドによるものだということです。
この場合、GitHub課題を解決する課題は複数の異なるプロンプトに分解されます：
リポジトリ内のファイルのうち、GitHub課題の解決に最も関連性が高いファイルはどれか
選択されたファイルの内容から、どの関数が最も関連性が高いか
モデルは数個の関数を選択する
選択されたファイルと関数のコンテキストが与えられた場合、元の課題を修正しようとする編集を生成する
モデルはdiffコードを出力する（cursorを使用したことがある人なら、diffコードやGitHubの変更点を直接知っているでしょう）
これを複数回行って複数のパッチ候補を作成します。これは一種のテスト時のスケーリングです。その後、モデルにテストを生成させ、そのテストを実行して最終パッチの順位付けを行い、提出します。
ご覧のように、これがエージェントレスの概要です。ステップ1、ステップ2、ステップ3があり、まずトップnファイルをローカライズし、次に関数が選択され、その関数からパッチが生成され、最終的な課題が再ランク付けされてパッチが提出されます。
対照的に、Code LLMとOpen Handsには、この人間が作成したワークフローはありません。代わりに、モデルに「これがファイルエディタで、これがbashターミナルです。任意のコードを実行できます。好きなことを自由にしてください」と伝えるだけです。そしてOpenAIのような推論モデルはそれが非常に苦手で、そのために高いスコアを獲得できないのです。
詳細については、Hugging Faceデータセットにあるスレッドとリリーストラジェクトリを参照してください。
私には一つの理論があります。これら2種類のエージェントスキャフォールドでは、コンテキストで提供される情報量が大きく異なり、これがOpenAIのような推論モデルのパフォーマンスに、特にこの場合は低パフォーマンスの原因となっています。
推論モデルは、極めて難しい数学やLeetCodeの問題を解くことで、懸命に考えるように訓練されています。これらの問題に共通しているのは、通常、それらが自己完結型であることです。問題を解くために必要なすべての情報は前もって与えられています。
数学の問題やLeetCodeの問題を解くときのように、問題文全体が与えられ、あなたはそれを解決するためにプログラミングスキルを使うだけです。そして、すべての情報が利用可能なため、単に考えることによってタスクの解決が上手くなる可能性が高いのです。
しかし、実世界の問題は異なります。GitHub課題を解決するには、コンテキスト、関連するコード、ドキュメンテーションなどを収集する必要があります。なぜなら、GitHub課題の説明が自己完結型でない可能性が非常に高いからです。単に課題を提起したいだけでない限り、GitHub課題の説明が自己完結型であれば、そもそも誰もGitHub課題を提起しないでしょう。
これは、完全な情報が提供された時に問題を解決する能力だけでなく、より多くのコンテキストを積極的に収集する能力も必要とします。エージェントレスのようなスキャフォールドは、分解されたプロンプトとワークフローを使用して、これらの推論モデルのためにコンテキスト収集を修正します。そうすることで、モデルは訓練されたこと、つまり考えることに専念できます。
Open Hands Code LLMのような一般的なスキャフォールドでは、エージェントがコンテキスト収集に失敗した場合、考える能力がどれほど強くても、おそらくどこにも進めません。問題が何なのかさえ正確に知らないのに、考えることで問題を解決することはできません。
これがまさに、考えるモデルではないClaude 3.5 SonnetがOpen Handsで非常に良い成績を収める理由です。モデルには自由に計画を立て、すべてを行う自由が与えられており、誰も指示を出さず、このフレームワークを与えず、「これを先にやれ、あれを先にやれ」という人間が指示するワークフローを与えていません。一方、OpenAIはこれが可能なエージェントレスを選びました。
これはコーディング関連のタスクには適していると主張できるかもしれませんが、それは異なるドメイン、例えば化学やタンパク質モデリング、生命科学などの分野には直接的に変換できないということも意味します。
私は判断はまだ保留中だと思います。OpenAIが露骨に嘘をついたとは言いません。異なるフレームワークを選んだからですが、今では彼らが自分たちに有利なフレームワークを選んだと主張できるでしょう。そしてOpenAIは、モデルが示唆するほど、OpenAIが示唆するほど優れているわけではありません。
私はGPT-4 o3で同じ問題を抱えていました。受賞者を発表した時、多くの人が「なぜo3を選ばなかったのか」と言いました。私の個人的な意見では、o3はハイプモデルのように見えます。実際、個人的に言えば、o3がAR-AGIで獲得したスコアはかなり論争の的となっています。多くの人が、o3がAR-AGIデータで独占的に微調整されていると言っています。これは、データサイエンスでは通常行わないことで、文字通り「ベンチマークリーキング」と呼ばれるものです。しかし今や、みんながそれを受け入れているようです。
私はo3が過大評価されている可能性があると個人的に感じていますが、GPT-4 o1は良いモデルに見えます。しかし今、GPT-4 o1のベンチマーク自体に関して論争が起きています。
この長い読み上げビデオを申し訳なく思います。「あなたは文字通りツイートを読んだだけだ」と言う人が大勢いるでしょう。しかし、このツイートは2つの異なるスキャフォールディング方式、2つの異なるフレームワークを理解するのに十分なコンテキストを与えてくれたと思います。
一つはOpenAIや通常のモデルとうまく機能する公開方式のOpen Hands、もう一つは推論モデルとうまく機能するように見えますが、他の推論モデルでも機能するのか、それともOpenAIがベンチで良いスコアを出すために独占的に選んだものなのかは分かりません。
いずれにせよ、OpenAIからの回答を待って、何が起こったのかを見てみましょう。しかし、このようなスキャフォールディング方式について何か考えがある場合、またはこれらのモデル（GPT-4 o1 Pro、GPT-4 o1 Preview、GPT-4 o3）のいずれかを使用している場合は、コメント欄で教えてください。
また別の動画でお会いしましょう。ハッピープロンプティング！
コメント