ProgramBench Vetted: 実行可能なバイナリからのリバースエンジニアリング

← 全ての調査 vetto 調査 ProgramBench Vetted コンピュータアンソロジーベンチマークファミリーの一部。ProgramBench Vetted Lucas Tonon · Rigel Bezerra · Lucas Smaira · Vetto Research Team 2026年8月13日 · 42分読む 共有 ProgramBench Vetted エージェントは実行可能なバイナリからプログラムを再構築できますか？それがProgramBenchの根本的な問いです。私たちは、同じ前提に基づいた50のタスクセットであるProgramBench Vettedをリリースします。タスク設計プロセスの改善により、ベンチマークはより公平で信頼性の高いものになっています。測定可能な部分的な進捗と決定論的なテストベースの採点を維持することに加えて、私たちのタスク設計プロセスは、テストの重複、環境の質、ハッキング可能性、公平性に関わる失敗モードに対するより広範な制御を追加します。 Z.AI ProgramBench Vetted モデル結果 解決済み 平均報酬 50個の保留タスクでの100%のテストをパスしたタスク、pass@1 · デフォルト ProgramBench mini-swe-agent 設定 ProgramBenchは重要です。なぜなら、プログラム再構築は、非常に長期間の作業を中心に構築された、比較的数少ないコーディングベンチマーク形式の一つだからです。エージェントは、拡張された軌跡にわたってプログラムのモデルを維持・改訂する必要があります。これにより、これらのタスクは長コンテキスト調整の研究に役立ちます。また、RLVRにも価値があります。多くの決定論的な行動チェックは、エージェントがそのフィードバックを一つの首尾一貫した実装に統合する必要がある間に、密度の高い、行動駆動型の報酬を提供できます。 これらのタスクは公開リポジトリから来ているため、一部は大規模モデルの事前学習データに登場した可能性があります。しかし、事前の露出は、モデルが観察された動作からコードに戻るように求められたときに、実装を記憶から取得または再構築できることを意味するものではありません。The Reversal Curseは、このギャップの有用なアナロジーを提供します。結果として生じる記憶のパラドックスとそのトレーニングへの影響については、付録Dで議論します。 ProgramBenchとは 2026年5月にMetaによってリリースされたProgramBenchは、エージェントに実行はできるが読み取りはできないコンパイル済みプログラムと、その使用ドキュメントを提供します。エージェントは、観察された動作を再現する新しいコードベースを書く必要があります。200の各タスクは、小さなユーティリティからFFmpeg、SQLite、PHPインタープリタに至るまで、実際のオープンソースCLIプロジェクトです。 意図されたタスクパッケージは密封されたコンテナです。バイナリは実行専用で、ドキュメントは保持され、ソースコードとgit履歴は削除されます。エージェントはインターネットなしのシェル、1000ステップ、6時間を与えられます。行動テストが結果を採点します。テスト自体は、元のリポジトリとバイナリをプローブしたエージェントによって書かれました。 元の構築プロセスは3つのステージで構成されます。 参照を構築する。コンパイル言語でリポジトリを選択し、ビルドエージェントにゴールドバイナリを生成させます。 行動テストを生成する。テスト生成エージェントは、ソースコード、既存のテスト、ドキュメントにアクセスして、リポジトリとバイナリを探索します。アップストリームテストを適応させ、ソース行カバレッジを使用してさらなる探索をガイドできます。 検証と封印する。生成された各テストは、アサーションリンターに合格し、ゴールドバイナリに対して合格し、ダミーバイナリに対して失敗する必要があります。その後、別のステップでモデルのワークスペースを実行可能ファイル、ドキュメント、および保持されたテストアセットに削減します。 評価時には、ソースコード、リポジトリテスト、git履歴は存在しません。エージェントはドキュメントを保持し、置換を構築しながら参照バイナリを実行できます。 生成された行動スイートは、パスしたテストの割合によって再構築を採点します。タスクは、すべてのテストがパスした場合にのみ解決されます。 保持されたドキュメントは仕様の一部を提供しますが、完全な行動契約ではありません。残りは、バイナリをプローブし、仮説を立て、それを実装し、結果を比較し、改訂することによって推測する必要があります。 論文で分析された4つのフロンティアエージェントは、アクションの23〜34%を参照のプローブに費やしており、経験的調査はタスクの単なるセットアップステップではなく、実質的な部分となっています。 ProgramBench Vetted が異なる理由 ProgramBench Vetted は、単に難しくするために設計されたわけではありません。各報酬ポイントが意図された動作をより忠実に表すように設計されています。私たちの目標は、調整された難易度です。タスクは意味のある部分的な進捗の余地を残すべきですが、浅いインターフェースの再現や評価の欠陥の悪用に対してほとんどのスコアを付与すべきではありません。 私たちの内部 ProgramBench 生成パイプライン 元のProgramBenchと同様に、私たちのパイプラインはリポジトリを2つの連携したアーティファクトに変換します。クリーンルーム再構築環境と、その報酬を定義する行動テストスイートです。しかし、リリースされたデータセットの監査中に発見した失敗モードに対処するために、単一の最終レビューに依存するのではなく、構築全体にわたって検証と修復を追加しました。 研究者による継続的なレビューは、専門化されたエージェント・アズ・ジャッジ（Agent as Judge）とエージェント・アズ・ドクター（Agent as Doctor）のシードを提供します。ジャッジはワークスペースを調査し、関連する動作をテストし、スコア付きレポートと証拠をレビューのために生成します。有望なタスクに修復可能な問題がある場合、ドクターはその証拠を使用して、タスクが同じチェックを再度通過する前に制約付きの変更を加えます。 これらのループは、正確に測定できるプロパティに対する決定論的なゲートや、タスクまたはその報酬を積極的に悪用しようとする敵対的なエージェントと並行して動作します。人間のレビュー担当者は曖昧なケースを処理し、最終決定を下し、繰り返し発生する失敗モードを、後のレビューのためのより強力な基準に変換します。 私たちは、ビルドの整合性、環境リーク、テスト品質、報酬の悪用はそれぞれ異なる種類の調査を必要とするため、これらの専門化されたステージにコンピューティングを分散させています。単一のスコアではそれらすべてをカバーできません。この専門化されたコンピューティングと蓄積されたレビュー知識の組み合わせが、タスクの構築方法の中心です。 以下の4つの展示は、プロセスを多くのステップを持つ接続されたステージに分割しています。 人間 エージェント 決定論的プロセス ステージ 01ソースとビルド 実行可能な参照がテスト生成の前に来る 参照プログラムのソース、ビルド、検証 人間が選択したリポジトリは、ソーシングジャッジ、ビルドエージェント、決定論的なコンパイルゲート、およびジャッジ・ドクターの修復ループを通過してから、ゴールドバイナリとクリーンルームの基盤を生成します。 人間選択 CLIソース（主にC、C++、Rust） 人間調査エージェント エージェントとして「ソーシング」ジャッジ 実行可能性をスコアリング エージェントビルドステージ ビルドエージェント戦略は複雑さに従う エージェント決定論的ゲート バイナリを検証する コンパイル、起動、動作 決定論的プロセス 受け入れられた参照 ゴールド+クリーンルーム基盤 並列ステージの準備完了 調査エージェント エージェントとして「ビルド」ジャッジ テスト、スコア、レポート エージェント ×N 修復エージェント エージェントとして「ビルド」ドクター 修復し、ジャッジに戻す エージェント ×N失敗後 人間レビュー 検査、修正、指示、拒否 人間の発見は、ソーシングジャッジ、ビルドジャッジ、ビルドドクターにフィードバックされる 人間 展示1 ソースとビルド。 研究者は適切なCLIリポジトリを選択し、その後、ソーシングジャッジ、ビルドエージェント、決定論的なゲート、およびジャッジ・ドクターの修復ループが動作する参照を確立します。繰り返しの失敗は人間のレビューにエスカレートします。合格した結果は、ゴールドバイナリとクリーンルーム環境の基盤をもたらします。 エージェントがジャッジとして評価します。エージェントがドクターとして修復します。各ジャッジはタスクを調査し、繰り返し発生する生成失敗から派生した基準を適用し、サポートアーティファクトとともにスコアを生成します。ペアになったドクターは、その証拠を使用して修復可能なタスクを修正し、同じジャッジに返します。専門化されたペアにより、パイプラインは、単一の一般的なチェックがすべてのレイヤーをカバーすることを要求するのではなく、ソーシング、ビルド、クリーンルーム、テスト、推論における失敗から個別に学習できます。繰り返しの失敗は人間のレビューにエスカレートします。自動化されたループがラウンド制限に達すると、レビュー担当者はアーティファクトと軌跡を検査し、タスクを拒否するか、修正して承認するか、関連するドクターに明示的な指示を与えることができます。それらの発見は、後の実行のためのより強力な基準と修復戦略になります。