R³-Bench、6問で推論予算を共有すると71／72のテスト条件でモデル性能が自身のオフライン上限を下回る

R³-Benchは、数学、競技プログラミング、抽象推論の各分野について、6問からなる50セットのコンテストを構成する。各セットには、必要リソースが少ない問題3問、中程度の問題2問、多い問題1問が固定で含まれる。ツールなしモードでは出力token数を共有予算として計測し、エージェントモードではshell、テスト、その他のツール操作を計測する。このためモデルは問題を解くだけでなく、推論を続けるタイミング、検証するタイミング、別の問題へ移るタイミング、作業を打ち切るタイミングも判断しなければならない。

研究ではまず、同一モデルに6段階の予算で各問題へ個別に回答させ、条件ごとに5回実行して、「どれだけのリソースを投入した時点で成功したか」を示す経験的な応答曲線を構築した。続いて著者らは、多肢選択ナップサック問題としてオフラインoracleを構築した。これは総予算の範囲内で、モデルが過去に実証した成功構成を事後的に選ぶものだ。6つのモデルに対する72の主要テストセルでは、oracleはすべて実際のコンテスト成績以上となり、そのうち71セルで厳密に上回った。より単純な均等配分でさえ、中程度の予算圧力下では、一部のモデルによる自主的な計画を上回った。

軌跡分析から、問題は単にモデルが全問に取り組んでいないことだけではないと分かった。5つのモデルは半数を超える問題に実質的な作業を投入していたが、新たな証拠と残り予算に応じて過半数のケースで戦略を調整したモデルは1つだけだった。予算圧力が強い場合、他の問題で先に割り当てを使い果たすことが典型的な失敗となる。圧力が比較的弱い場合には、進展が得られているにもかかわらず早すぎる段階で中止することが多い。固定スケジュールの指示を追加すると、9つのモデル／分野の組み合わせのうち6つで改善したが、分野をまたいで安定して優位に立つ戦略はなかった。

これは、複数のタスクを同時に実行するコーディングエージェントに直接的な示唆を与える。単一問題のbenchmarkスコアから、並行ワークロード下での実効的な処理能力を推測することはできず、schedulerには残りコスト、成功確率、機会費用を明示的に推定する仕組みが必要になる可能性がある。制約として、oracleは事後的な成功記録を利用しており、デプロイ可能な戦略ではない。また、問題の難易度は参照モデルの出力長に基づいて階層化されている。オープンソースの評価器には、プログラミング問題のhidden testsや一部の検証用アセットも含まれていないため、完全な再現にはそれらを独自に補完する必要がある。