論文の概要: Are Performance-Optimization Benchmarks Reliably Measuring Coding Agents?

• arxiv url: http://arxiv.org/abs/2607.01211v1
• Date: Wed, 01 Jul 2026 17:50:48 GMT
• ステータス: 翻訳完了
• システム内更新日: 2026-07-02 19:56:08.014338
• Title: Are Performance-Optimization Benchmarks Reliably Measuring Coding Agents?
• Title（参考訳）: 性能最適化ベンチマークは信頼できるコーディングエージェントの測定か?
• Abstract要約: リポジトリレベルのパフォーマンス最適化ベンチマークは、実際のリポジトリにパッチを適用することで、コーディングエージェントを評価する。 リーダボードスコアは、実行時の不安定性、ベンチマーク固有のスコアリングルール、および少なくとも1つの公開提案によってすでに解決されているタスク数を説明できることを示す。 我々は、少なくとも1つの提案が85.3%(384/450)のリプレイバリGSOとSWE-fficiencyタスクで参照パッチと一致し、99.8%(449/450)で最適化されていないベースコードを破ることを発見した。
• 参考スコア（独自算出の注目度）: 15.202813683786337
• License: http://creativecommons.org/licenses/by/4.0/
• Abstract: Repository-level performance-optimization benchmarks such as GSO, SWE-Perf and SWE-fficiency evaluate coding agents by applying patches to real repositories and comparing runtime against unoptimized baselines and official reference patches. Their leaderboard scores are increasingly used as evidence of coding-agent progress, but those scores can conflate runtime instability, benchmark-specific scoring rules, and how many tasks are already solved by at least one public submission. We audit these issues across the three benchmarks. First, we replay the official reference patches for 740 code optimization tasks across four common types of Google Cloud machines. Most benchmark tasks can be replayed, but their reference patches satisfy the original benchmark validity rules in every cross-machine replay for only 39/102 GSO tasks, 11/140 SWE-Perf tasks, and 411/498 SWE-fficiency tasks; SWE-Perf is especially fragile because many reference patches produce close-to-zero runtime changes. Second, we show that public submission rankings depend strongly on the benchmark scoring rule. Among eight public submissions shared by GSO and SWE-fficiency, the official rankings disagree on 9 of 28 pairwise submission comparisons, and SWE-fficiency's leaderboard scoring rule assigns the worst ten tasks overly high score weights of 58.5%-82.8%. Third, looking across 10 public submissions for each task, we find that at least one submission matches or beats the reference patch on 85.3% (384/450) of replay-valid GSO and SWE-fficiency tasks, and beats the unoptimized base code on 99.8% (449/450). Our study complements leaderboard scores by identifying tasks with more reliable performance signals, quantifying per-task score contributions, and exposing the remaining performance gaps that are hidden by aggregate rankings.
• Abstract（参考訳）: GSO、SWE-Perf、SWE-fficiencyといったリポジトリレベルのパフォーマンス最適化ベンチマークは、実際のリポジトリにパッチを適用し、ランタイムを最適化されていないベースラインと公式リファレンスパッチと比較することで、コーディングエージェントを評価する。 これらのスコアは、実行時の不安定性、ベンチマーク固有のスコアリングルール、そして少なくとも1つのパブリックな提出によってすでに解決されているタスクの数を詳述することができる。 3つのベンチマークでこれらの問題を監査します。 まず、Google Cloudマシンの4つの一般的なタイプにまたがる740のコード最適化タスクの公式リファレンスパッチをリプレイします。 ほとんどのベンチマークタスクはリプレイできるが、参照パッチは、39/102 GSOタスク、11/140 SWE-Perfタスク、および411/498 SWE-fficiencyタスクのすべてのマシン間リプレイにおいて、元のベンチマーク検証ルールを満たす。 第2に、公開応募ランキングはベンチマークスコアルールに強く依存していることを示す。 GSOとSWE-fficiencyが共有する公募8件のうち、公式ランキングは28件中9件に意見が一致せず、SWE-fficiencyのスコアリングルールでは58.5%-82.8%という最悪の10のタスクを割り当てている。 第3に、各タスクに対する10のパブリックサブミッションを見てみると、少なくとも1つのサブミッションが85.3%(384/450)のリプレイ無効なGSOとSWE-fficiencyタスクで参照パッチと一致し、99.8%(449/450)で最適化されていないベースコードを打ち負かす。 本研究は、タスクを信頼性の高いパフォーマンス信号で識別し、タスク毎のスコアコントリビューションを定量化し、アグリゲーションランキングによって隠された残りのパフォーマンスギャップを明らかにすることで、リーダーボードスコアを補完する。

関連論文リスト

• RobustSGPO: Search-Space Control for Agent Harness Evolution [56.722805974785125]
  我々は、要求された編集、構成、パッチのチェックを指定し、既存のスナップショットまたは保持スナップショットからの検索を継続するRobustSGPOを紹介した。 我々は,120タスク,95ラン,7350の候補を用いて,AgentXブレインストーミングワークフローにおけるパーミッションスケジューリング,累積制御,タスクファミリー転送を評価した。
  論文  参考訳（メタデータ） (2026-09-09T03:00:03Z)
• Harness-IF: Evaluating Instruction Following Across Instruction Surfaces in Coding Agents [29.96375986740068]
  Harness-IFは、実行証拠から一度に1つの運用ルールをスコアする。 AP-Accは、不正なデフォルトに対してラベル付けされたルールのみをスコアする。
  論文  参考訳（メタデータ） (2026-08-12T07:07:57Z)
• Benchmarking the Benchmarks: Testing the Predictive Validity of Commonsense Benchmarks [1.671764884922859]
  確立された4つのコモンセンスベンチマーク,4つのリワークされた変種,3つの非常識制御,8つの下流タスクの6つのファミリーから23のモデルを評価した。 我々は、モデルランキング、計算制御された相関関係を比較し、コモンセンスベンチマークの基準妥当性を評価するために、一戸一戸一戸建てのクロスバリデーションを使用する。
  論文  参考訳（メタデータ） (2026-08-04T08:49:34Z)
• DeepSWE: Measuring Frontier Coding Agents on Original, Long-Horizon Engineering Tasks [1.7623000586936592]
  DeepSWEは、コーディングエージェントを評価するための、113のオリジナルで長期のソフトウェアエンジニアリングタスクのベンチマークである。 タスクは91のアクティブなオープンソースリポジトリと5つの言語でスクラッチから書かれており、上流にコントリビュートされることはない。 SWE-Bench Proのプロンプトの約半分の長さにもかかわらず、DeepSWEのプロンプトは参照ソリューションが5.5倍のコードに触れるタスクを記述する。
  論文  参考訳（メタデータ） (2026-07-08T21:45:34Z)
• Benchmarking the Benchmarks: A Validity Audit of Tool-Calling Evaluation [3.079997053226693]
  本報告では,4つの主要なツールコール・ベンチマーク・ファミリーの体系的妥当性と評価について述べる。 496人の専門家がレビューしたベンチマークタスクのうち、92人の評価者と人間の意見の不一致が18.5%のミスアライメントレートに対応している。 ツールコール評価失敗、トレースレベルの監査成果物、修正された評価項目の統一分類を導入し、ツールの実行、タスク完了、結果検証を別々に計測する指標について議論する。
  論文  参考訳（メタデータ） (2026-06-30T21:10:42Z)
• Auditing Reward Hackability in Code RL Training Environments [0.0]
  コードRL環境が誤った解を正しく受け入れる速度を計測する。 SWE-bench Verifiedの49タクのサンプルでは、28.5%のタスクがテストスイートが弱く、Dockerで検証された不正確なパッチがそれらをパスしている。
  論文  参考訳（メタデータ） (2026-06-14T23:31:42Z)
• Welfare, Improvability, and Variance: A Principal-Agent Approach to Optimal Benchmark Item Aggregation [19.980368400366352]
  マルチタスクのプリンシパルエージェントゲームとしてベンチマークをモデル化し、ベンチマークによる福祉損失を3つのアイテムレベルプリミティブで共同で決定することを示す。 我々は、福祉用ORKBank、即効性用EvoLM 4Bスイート、分散用PolyPythias 410Mパネルを用いたOLMES項目にこの理論を適用した。
  論文  参考訳（メタデータ） (2026-05-29T07:01:38Z)
• SEAL: Can Saturated Benchmarks Be Revived by LLM-as-a-Meta-Judge? [26.684941358964704]
  SEALは飽和ベンチマークから遅延ランキング信号を抽出するための自己改善評価プロトコルである。 我々は、コード生成、数学的推論、知識集約型質問応答、ツール使用エージェントタスク完了を含む複数の飽和ベンチマーク上でSEALを評価する。
  論文  参考訳（メタデータ） (2026-05-28T15:46:54Z)
• Converted, Not Equivalent: Benchmarking Codebase Conversion via Observational Equivalence [56.25095230687242]
  コーディングエージェントは、しばしば自身のローカル検証ルーチンを過度に信頼し、表面チェックを満たすアーティファクトの成功を宣言する。 この問題は、事前評価が結果駆動である変換において特に深刻である。 ブラインド・コンバージョンは26.7-28.9%に達し、スペック・パスレートは91.1%まで上昇した。 このことは、失敗は限られた予算やバックボーンの強さよりも、契約ミスによる自己検証に起因していることを示唆している。
  論文  参考訳（メタデータ） (2026-05-27T19:57:15Z)
• Are Benchmark Tests Strong Enough? Mutation-Guided Diagnosis and Augmentation of Regression Suites [49.16055123488827]
  十分に強力なテストスイートは、報告された成功率を膨らませながら、妥当だが意味的に正しくないパッチを認めることができる。 STINGは、意味的に変化するプログラムの変種を診断ストレス要因として利用する、ターゲットテスト拡張のためのフレームワークである。 STINGは211インスタンスにまたがる1014の検証テストを生成し、パッチリージョンラインとブランチカバレッジを10.8%、9.5%向上させた。
  論文  参考訳（メタデータ） (2026-04-02T01:13:40Z)
• Fantastic Bugs and Where to Find Them in AI Benchmarks [28.604919035475188]
  本稿では, 応答パターンの統計的解析を利用して, 潜在的に無効な質問にフラグを付ける手法を提案する。 我々のアプローチは、平均スコアがモデル性能を十分に要約する、AI評価で一般的に使用されるコア仮定に基づいています。 提案手法は,9つの広く使用されているベンチマークにおいて,最大84%の精度で問題のある問題を特定するために専門家のレビューをガイドする。
  論文  参考訳（メタデータ） (2025-11-20T22:49:21Z)
• SOPBench: Evaluating Language Agents at Following Standard Operating Procedures and Constraints [59.645885492637845]
  SOPBenchは、各サービス固有のSOPコードプログラムを実行可能な関数の有向グラフに変換する評価パイプラインである。 提案手法では,各サービス固有のSOPコードプログラムを実行可能関数の有向グラフに変換し,自然言語SOP記述に基づいてこれらの関数を呼び出しなければならない。 我々は18の先行モデルを評価し、上位モデルでさえタスクが困難であることを示す。
  論文  参考訳（メタデータ） (2025-03-11T17:53:02Z)
• How Should We Build A Benchmark? Revisiting 274 Code-Related Benchmarks For LLMs [60.25940747590386]
  本稿では,コード関連ベンチマークの開発を包括的に管理するためのガイドラインとして,55の基準チェックリストからなるHow2Benchを提案する。 私たちは過去10年以内にリリースされた274のベンチマークをプロファイルし、問題を見つけました。 ベンチマークの70%近くはデータ品質保証の措置を取らず、10%以上がオープンソースでも、部分的にはオープンソースでもなかった。
  論文  参考訳（メタデータ） (2025-01-18T09:51:57Z)
• metabench -- A Sparse Benchmark of Reasoning and Knowledge in Large Language Models [5.972993094932516]
  大きな言語モデル(LLM)は、様々なタスクでその能力が異なる。 これらのベンチマークを測る共通基盤能力の小さなセットがあることが示される。 スパースベンチマークであるメタベンチを蒸留し、これらは6つのベンチマークの原サイズの3%以下である。
  論文  参考訳（メタデータ） (2024-07-04T17:57:38Z)
• LLMs as Factual Reasoners: Insights from Existing Benchmarks and Beyond [135.8013388183257]
  そこで我々は,SummEditsと呼ばれる10ドメインのベンチマークで不整合検出ベンチマークを作成し,実装する新しいプロトコルを提案する。 ほとんどのLLMはSummEditsで苦労しており、パフォーマンスはランダムに近い。 最も優れたモデルであるGPT-4は、推定された人間のパフォーマンスよりも8%低い。
  論文  参考訳（メタデータ） (2023-05-23T21:50:06Z)

関連論文リストは本サイト内にある論文のタイトル・アブストラクトから自動的に作成しています。

指定された論文の情報です。
本サイトの運営者は本サイト（すべての情報・翻訳含む）の品質を保証せず、本サイト（すべての情報・翻訳含む）を使用して発生したあらゆる結果について一切の責任を負いません。