Senior SWE-Bench: シニアエンジニア級エージェント評価向けのオープンソースベンチマーク

 (senior-swe-bench.snorkel.ai)
3 ポイント 投稿者 GN⁺ 4 시간 전 | 1件のコメント | WhatsAppで共有
  • Senior SWE-Bench は、コーディングエージェントを過度に整理されたジュニア向け課題ではなく、実際にシニアエンジニアが担う機能開発・バグ修正・性能問題に近い形で評価することを目指したベンチマーク
  • 機能課題では、自然言語メッセージのように読める 現実的な指示 を用い、提出された解法に合わせて行動テストを作成する検証エージェントにより評価の信頼性を高めている
  • バグ課題は、ユーザー報告から出発し、サービス実行、ログ、プロファイリングデータ、再現手順といった ランタイム調査 を要するPRから採られている
  • スコアはランタイム整合性だけでなく、コードベースの慣行に基づく品質指標を組み合わせて tasteful solve を評価し、指示に書かれていない重要な慣行も検証対象になりうる
  • リーダーボード首位のモデルである Claude Opus 4.8 ですら Mini-SWE-Agent max 設定で pass@1 24.0% にとどまり、上位モデルでもシニア水準の整合性と taste を備えた解決には 75% 以上失敗している

実際のPRに近い課題設計

  • Senior SWE-Bench は、コーディングエージェントが実際にはシニアエンジニアのように使われている一方で、評価はジュニア向け課題のように行われているというギャップを埋めるためのベンチマーク
  • 課題はライブラリから複数サービスのアプリケーションまで、さまざまなリポジトリのPRから採られており、各リポジトリで 数百件のコミット を行ったエンジニアが作成したPRを対象としている
  • 主な課題タイプは次の二系統に分かれる
    • 複数段階・複数スタックにまたがる 機能PR
    • 相当なランタイム調査を必要とした バグ・性能PR
  • 公開課題は 50件、非公開課題も50件
  • 含まれるリポジトリの例は次の通り

機能課題: 自然言語に近い指示

  • 機能課題では、過度に細分化された要件の代わりに、自然言語メッセージのように読める 現実的な指示 を使っている
  • こうした課題を安定して評価するために 検証エージェント(validation agent) を導入している
    • 専門家が設計したレシピを使用する
    • 提出された解法に合わせて行動テストを書く
  • 指示は自然なエージェント間コミュニケーションを反映しており、長さの中央値は SWE-Bench Pro の31% 水準

バグ課題: ユーザー報告からランタイム調査まで

  • バグ課題は、厄介な ユーザー報告 を反映し、単純なコード修正よりも原因調査や再現プロセスをより多く求める
  • 課題には次のような作業が含まれうる
    • サービス起動
    • 微妙なランタイム問題のデバッグ
    • ログ確認
    • プロファイリングデータの活用
    • 再現手順の追跡
  • 出典は、解決過程で 相当なランタイム調査 を必要としたPR

評価基準: 整合性と taste を同時に測る

  • Senior SWE-Bench は、ランタイム整合性テストと複数の品質指標を組み合わせて tasteful solve を採点する
  • 品質指標は、観察されたコードベースの慣行に基づいている
  • 検証器と検証エージェントは、指示に書かれていなくても、コードベースで重要な慣行をテストできる
  • リーダーボードにおける solve 条件には次の項目が含まれる
    • Verifiers pass
    • Validation pass
    • Rubric > 0.5
    • Bloat < 2×
    • Practice > 2/5
    • Rel. taste > 2/5

リーダーボード: 最上位モデルでも低い pass@1

  • リーダーボードは Tasteful solve rate(pass@1) 基準で結果を示している
  • 上位結果は次の通り
    • Claude Opus 4.8, Mini-SWE-Agent max: 24.0%
    • Claude Sonnet 5, Mini-SWE-Agent max: 19.4%
    • GPT-5.5, Mini-SWE-Agent xhigh: 16.0%
    • Claude Opus 4.7, Mini-SWE-Agent max: 14.1%
    • GPT-5.4, Mini-SWE-Agent xhigh: 14.0%
    • GLM-5.2, Mini-SWE-Agent max: 12.5%
    • Kimi K2.6, Mini-SWE-Agent default: 8.2%
    • Claude Sonnet 4.6, Mini-SWE-Agent high: 8.2%
    • Gemini 3.1 Pro, Mini-SWE-Agent high: 6.1%
    • Gemini 3.5 Flash, Mini-SWE-Agent medium: 3.0%
  • 最も強力な最前線モデルでさえ、シニア水準の整合性と taste を備えた課題の 75%以上 を完了できていない

課題範囲とベンチマークの特性

  • 課題タイプは feature、bug、perf、migrat と表記される
  • スタックには Py Svc、Elixir、Go、SQL、TS Lib、Py Lib、Rust、TS FE などが含まれる
  • 機能課題は複数サービスにまたがる場合があり、課題あたり平均 11ファイル に手を入れる
  • 長い作業フローを必要とするよう設計されており、最も強力なエージェントでも 数百ステップ が必要
  • 参照解法の SLOC とファイル数は、3つのベンチマークで同じ方法で測定される
  • 指示の長さはハーネスのボイラープレートを除外している
  • 他ベンチマークのトークン数とステップ数は、各ベンチマークの自己申告指標に基づく

関連記事

1件のコメント

 
GN⁺ 4 시간 전
Hacker Newsの意見

  • Twitterで見た話では、清華大学の機械学習の授業で、学生にできるだけ多くのLLMが失敗するクイズを作らせる試験があったらしい。
    こういう形のベンチマークを作ってELOスコアを付けるのはどうだろうと思う。モデル同士を戦わせて、質問、バグ、未完成の実装を出し合い、相手が答えたり直したり完成させたりする形だ

    • それは生成的敵対ネットワーク（GAN）と呼べそうだ :)
      https://en.wikipedia.org/wiki/Generative_adversarial_network
    • 問題は退化戦略をどう防ぐかだ。たとえばSHA256ハッシュを渡して元の入力を当てろと言えば、簡単に不可能な問題を作れてしまう。
      授業なら少なくとも1つのLLMは解けなければならないというルールを置けるだろうが、1対1の対戦ではどう解決すればいいのかわからない
    • それは清華じゃなくて復旦だった気がする

  • このベンチマークが時間の経過とともにどう関連性を保つのか気になる。
    ベンチマークがオープンソースプロジェクトの機能実装なら、LLMがその変更を学習データに含んでいて、そのまま、あるいは少し変えた答えを出せてしまうかもしれない。
    逆にモデルの知識カットオフ以降のコード変更だけをベンチマークに入れると、時点TとT+1で問題が変わってしまい、時系列での比較可能性が下がる

  • Staff SWE Benchなら、LLMはそもそもこれをやるべきなのか疑い、プロジェクト全体に異議を唱え、コードのマージは拒否するが削除は喜んでやりそうだ

    • 冗談のように聞こえるが、実際拒否は仕事の中核だと思う。単に「ダメ、帰って」ではなく、一歩引いて大きな絵を求め、組織全体がそのプロジェクトを長期的に必要とし、維持できるのかを見るのは、始める前の最低限の手続きに近い。
      LLMもこれを十分に、もしかすると私たちよりうまくできる気はするが、それに合わせて別途訓練される必要がある。ただ、そういう訓練データをどこで手に入れるのかはあまり思いつかない
    • Principal版は似ているが、唯一許されるアプローチが前の会社でやっていたやり方だとも言いそうだ

  • だから自分がずっとOpus 4.8はGPT 5.5よりはるかに先を行っていると感じていた理由が説明できる。不完全な要件を受け取って、プロジェクトに合った妥当な形で空白を埋める能力が本当に高い

    • そもそもなぜ不完全な要件を渡すのかわからない。どちらのモデルも前提やエッジケースを検討し、明確化のための質問をするのは得意だが、明示的に求めたときだけそうするように見える。たとえば「ブレインストーミング」のような技法で依頼したときだ。
      どちらの評価方法も、モデルがあらゆる前提を疑い、質問するよう十分に促していないと思う。ユーザーが面倒がるからかもしれないが、その段階はほぼ必須だと思う。
      GPT-5系はどれも非常に几帳面で、コードレビューや数学には役立った。自分の仕事では重要だが、「美しい」コードには邪魔になるように思える。たとえば可能性の低いエッジケースまで全部防ごうとするような感じだ。
      柔軟性と指示順守の間にもトレードオフがあるようだ。自分の経験ではOpusはたまに指示を無視するが空白を埋めるのがうまく、GPT-5.5は指示にはよりよく従うが、その分硬直しているように見える
    • 最高のベンチマークは自分で作ったベンチマークだ。
      自分の経験では、Opusが圧倒的に先行しているとか、より良いということはなかった。いずれにせよGPT 5.5にはInstant、Medium、High、Extra High、Proがあるのに、表ではExtra Highと比較しているように見えるので、Proと比較すべきではないかと思う
    • 自分が変なバブルの中にいるのかもしれないが、自分にとってはGPT 5.5のほうがOpus 4.8よりはるかに良い。どう評価しているのか、どんな仕事をしているのか気になるくらいだ。
      フロントエンド開発やデザインのようにOpusのほうがうまい特定の作業はあるが、それ以外では5.5がただ圧倒している
    • 常に明示度が低いバイブコーダーには向いているかもしれない。だが問題は、どの時点からモデルが「要件の明示度が低い」と判断し、実際には十分に明示された仕様を超えて実装してしまうのかということだ
    • 自分も同じ観察をした。Opus 4.8はずっと成熟していて、引っかかる依頼には問い返したり反対したりもした。一方GPT 5.5は喜んで同意して言われた通りにするが、何度かやり直させる必要があることが多かった。
      4.8も複数回のプロンプトが必要ではあるが、出力品質はずっと高く、より多くの洞察を与えてくれる。
      ただしFable 5はまた別の存在だ

  • 現在の最高解決率がOpus 4.8基準で**24%**なのだとすると、有能な人間ならどの程度のスコアを取れるのだろうか？

    • おそらく最高モデルが使えるものを人間も使えるのだから、それ以上ではないかと思う。
      逆に、モデルが人間を思いのままに使えるなら、もっと高いスコアを取れるのかも気になる
    • これらの問題はすべてすでに解決されたものだと仮定すれば100%だと思う。もちろん同じ1人が全部解いたわけではないだろうが、モデルは多様なコードベースに強くなければならない一方で、人間は1つの製品に特化して学習できる。
      製品作業に慣れた個人と比べるのは公正だと思う。
      Fableがどう出るのかのほうが気になる

  • シニア職の価値は、既知の解法と戦略を新しい問題に適用することにある。一度も変わらないベンチマークが、長く新しい挑戦であり続けられるのかはわからない。
    まともなベンチマークなら、まずTRIZ全体を使って巨大な問題の塊を作り、AIが最適解を推論できるかを見るべきだ

  • Snorkelから新しい公開ベンチマークが出たのはうれしい。あちらではかなり洗練された仕事をしている

  • Sonnet 5がOpus 4.8にかなり近いのは興味深い

  • このやり方が機能するなら、技術面接も自動化できるということではないだろうか？

  • 「You are a senior SWE-Bench reviewer, make no mistakes.」のようにLLMに主観的判断をさせるアプローチは、根本的に欠陥があるように見える。
    実現可能性を保ちながら、より良いやり方が何なのかはわからない

    • さらに重要なのは、これが実際に作業を妨げる可能性がある点だ。LLMがミスをしたとき、認めて修正するのではなく、矮小化してやり過ごすよう促されるかもしれない
    • このやり方は、実質的にLLMにどう振る舞うべきかという文脈を埋め込んでいる。「senior reviewer」は望ましい応答スタイルであり、「SWE-Bench」はLLMが動作する文脈と領域だ。
      システムプロンプトではよくあるやり方で、応答のフレームを定めてくれる。
      たとえば「プログラミングについての舟歌を書く海賊」「物理学の記事を書くニュース記者」「PostgreSQLを完璧に理解しているシニアソフトウェアエンジニア」と言えば、それぞれ違う応答が出る。
      最初のものなら、Wellerman風に「There once was a program that was set to C ...」のような答えになるかもしれない。
      ただし「make no mistakes」の部分は怪しい。その文言を入れた場合と外した場合で結果を比較し、同じ望ましい振る舞いを得る別の方法も試してみると面白そうだ
    • 「make no mistakes」という訓戒はかなり滑稽に見える。YouTubeでもすでにかなり揶揄されているが、機能しそうな形は簡単に想像できる。たとえば単に「作業をレビューせよ」と解釈されるかもしれない。
      もちろん、こうした比較測定を公に実施して妥当な結論に到達できるようにしてくれるところは、今のところなさそうだ