論文の概要: ProductWebBench: Evaluating Website Continuity Beyond Task Completion
- arxiv url: http://arxiv.org/abs/2610.31118v1
- Date: Thu, 22 Oct 2026 11:33:00 GMT
- ステータス: 翻訳完了
- システム内更新日: 2026-10-24 02:08:44.341751
- Title: ProductWebBench: Evaluating Website Continuity Beyond Task Completion
- Title（参考訳）: ProductWebBench: タスク完了以上のWebサイト継続性を評価する
- Abstract要約: ProductWebBenchは、生きたリポジトリで両方のスコアを付けるベンチマークである。
ターゲットだけでなく、着陸した生体システムに対してパッチを採点する。
- 参考スコア（独自算出の注目度）: 36.75409331518431
- License: http://creativecommons.org/licenses/by/4.0/
- Abstract: Frontend coding agents are usually graded on one question: did the requested target get built. Real engineering changes carry a second obligation, because the rest of the site has to keep working. We call that second obligation website continuity, and introduce ProductWebBench, a benchmark that scores both on living frontend repositories: 320 Change tasks over existing code and 80 long-horizon Build tasks. Every task freezes a repository snapshot, staged requirements, browser evidence and deterministic checks before evaluation, and enters only once a reference passes every check and plausible-wrong ones fail. A simulated user reveals the requirements one stage at a time, and every check cleared earlier stays armed for the rest of the run. Across 8,737 runs from 13 models the two come apart: of the Change runs passing every requested-work check, 28.2% still fail a continuity check -- a blank route, horizontal overflow, console errors -- and 10.8% push a browser state they had already passed back to failing. Because the same checks also run on the untouched repository, each regression carries exact provenance, not a post-hoc label: on the 586 runs where both readings exist, 18.3% are caught breaking a verified state. Interaction is a further blind spot, failing in 29.5% of runs whose static DOM already passes. ProductWebBench therefore scores a patch against the living system it lands in, not the target alone.
- Abstract（参考訳）: フロントエンドのコーディングエージェントは通常、1つの質問にランク付けされます。
実際のエンジニアリングの変更は、サイトの残りの部分が動作し続ける必要があるため、第2の義務を負う。
これは、生きたフロントエンドリポジトリでスコア付けするベンチマークです。 320タスクを既存のコードで変更し、80の長期ビルドタスクを実行します。
各タスクは、評価の前にリポジトリのスナップショット、ステージ化された要求、ブラウザのエビデンス、決定論的チェックを凍結し、参照がすべてのチェックをパスした時にのみ入力する。
シミュレーションされたユーザは、要件を1ステージずつ明らかにする。
8,737台が13モデルから実行され、変更は要求された作業チェックをすべてパスし、28.2%は継続性チェック -- 空白のルート、水平オーバーフロー、コンソールエラー -- を失敗し、10.8%は、すでにパスしたブラウザ状態をフェールさせる。
同じチェックが修正されていないレポジトリでも実行されるため、各レグレッションは、ポストホックラベルではなく、正確に証明される。
インタラクションはさらに盲点になり、静的DOMがすでにパスしている実行時間の29.5%で失敗する。
ですからProductWebBenchは、ターゲットだけでなく、着地したリビングシステムに対してパッチをスコアします。
関連論文リスト
- SWE-Residual: Evaluating Starting-State Robustness of Coding Agents [21.99711306523695]
SWE-Residualは、開始状態にそのタスクに関する以前の作業が含まれている場合、タスクのパフォーマンスを維持できるためのベンチマークである。
クリーンスタート評価が捉えない機能ギャップを露呈する。
論文 参考訳（メタデータ） (2026-10-19T07:00:04Z) - Long-Horizon-Terminal-Bench 2.0: Automating Diverse Task Construction and Measuring Sustained Agent Progress [59.76726249334829]
本稿では,LHTB 2.0(Long-Horizon-Terminal-Bench 2.0)について述べる。
LHTB 2.0は46のタスクを保存し、タスクと評価インフラの欠陥を修正し、31のタスクを拡張する。
拡張されたタスクは、体系的な再構築タスクパイプラインを通じて生成される。
論文 参考訳（メタデータ） (2026-10-09T15:22:53Z) - Before They Can Solve: Predicting Post-Training Coding-Agent Performance from Base Models [87.94969284553706]
エンド・ツー・エンドのpass@$K$は、成功した振る舞いがベースモデルのディストリビューションにすでに現れるかどうかをテストする。
コールドスタートからハーネスを駆動するために、ベースチェックポイントを必要としない3つのスクリーンを構築します。
3つの画面はいずれも、ポストトレーニング後のSWE-bench Verified pass@$1$と密接に一致して、コホートをランク付けする。
論文 参考訳（メタデータ） (2026-10-07T17:37:19Z) - One Success Isn't Reliability: Thinkingbox, a Sandbox and Benchmark for Agents in Stateful Business Workflows [2.281697288703173]
Thinkingboxはツールエージェントとユーザインタラクションのためのサンドボックスだ。
独立したMPP互換ツールセッション、完全な実行トレース、端末バックエンドに対する結果評価を提供する。
Thinkingboxbenchには、さまざまなシナリオにわたる507のベンチマークとステートコンディションベンチマークが含まれている。
論文 参考訳（メタデータ） (2026-08-20T07:37:57Z) - OpenHarmony Bench: Evaluating LLMs and Coding Agents on OpenHarmony App Development [32.88521369254793]
OPENHARMONY BENCHは、OpenHarmony ArkTSアプリケーション上でLLMベースのコーディングエージェントを評価するためのアプリケーションレベルのコーディングベンチマークである。
ベンチマークは、デバイスに配信されたアプリケーションをインストールして、動作が観測可能であるかどうかをチェックする。
スナップショットには32の新機能タスク、Fポイント139の仕様駆動タスク、71のバグフィックスタスクが含まれている。
論文 参考訳（メタデータ） (2026-08-17T02:27:10Z) - Tencent WorkBuddy Bench: A Multi-Domain Coding-Agent Benchmark with Contamination-Resistant Task Construction [57.138342889101345]
Tencent WorkBuddy Benchは、コーディングエージェントのためのマルチドメイン評価スイートである。
本報告では, 設計手法, スコアリングプロトコル, クロスモデルリーダーボードについて述べる。
論文 参考訳（メタデータ） (2026-07-23T04:34:06Z) - 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) - Crab: A Semantics-Aware Checkpoint/Restore Runtime for Agent Sandboxes [7.156242393967948]
75%以上のエージェントがリカバリ関連状態を発生しないため、ほとんどのチェックポイントは不要である。
Checkpoint-and-Restore for Agent SandBoxesは、エージェントやC/Rバックエンドを変更することなく、このギャップをブリッジする透過的なホストサイドランタイムである。
シェル集約型およびコード修正ワークロードでは、Crabはリカバリの正しさを8%(チャットのみ)から100%に引き上げ、チェックポイントトラフィックを最大87%削減し、フォールトフリー実行時間の1.9%以内に留まる。
論文 参考訳（メタデータ） (2026-04-30T17:20:19Z) - ClawMark: A Living-World Benchmark for Multi-Turn, Multi-Day, Multimodal Coworker Agents [77.22389710754452]
マルチターンマルチデイタスクを中心に構築された同僚エージェントのベンチマークであるベンチを紹介する。
現在のリリースには、13のプロのシナリオにわたる100のタスクが含まれており、5つのステートフルなサンドボックスサービスに対して実行される。
最強のモデルは75.8の重み付きスコアに達するが、最も厳格なタスク成功率は20.0%に過ぎず、部分的な進歩が一般的であることを示している。
論文 参考訳（メタデータ） (2026-04-26T16:05:02Z)
関連論文リストは本サイト内にある論文のタイトル・アブストラクトから自動的に作成しています。
指定された論文の情報です。
本サイトの運営者は本サイト（すべての情報・翻訳含む）の品質を保証せず、本サイト（すべての情報・翻訳含む）を使用して発生したあらゆる結果について一切の責任を負いません。