VerifierBench: Benchmarking the Generation of Executable Verifiers for LLM Agents
Jianing Yin, Dawn Song, Daoan Zhang and colleagues (UPenn, UIUC, UC Berkeley, NYU) introduce VerifierBench, which measures whether agents can write executable verifiers that accept every valid solution and reject invalid ones.
Ask this paper
Benchmark. 222 tasks from six agent benchmarks covering tool-call, state-based and code verification, with 4,993 hidden test cases that include alternative valid solutions and attacks. A six-check audit (V4V) screens the source verifiers and test suites.
Scores. Across 19 models in a shared harness, normalized balanced accuracy ranges from 10.6 to 62.1.
Over-strict verifiers. Generated verifiers reject invalid solutions more reliably than they accept valid ones, and most false rejections come from verifiers that accept no tested solution at all.
Why self-testing misses it. Agents test their verifiers against solutions that share the same wrong assumptions about formats, tool use or code changes, or submit without checking that any correct solution passes. The authors recommend testing acceptance of correct and alternative valid solutions explicitly.
Abstract
Agents need reliable ways to validate their outputs, both when completing tasks and when filtering synthetic training data. We study verifier generation: from the instruction and environment available for solving a task, an agent writes an executable verifier that must accept every valid solution and reject invalid ones. We introduce VerifierBench, a benchmark of 222 tasks from six agent benchmarks spanning tool-call, state-based, and code verification, with 4,993 hidden test cases that include alternative valid solutions and attacks; Verifier4Verifier (V4V), a six-check audit, screens its source verifiers and test suites. Across 19 models in a common agent harness, normalized balanced accuracy ranges from 10.6 to 62.1, with generated verifiers consistently rejecting invalid solutions more reliably than they accept valid ones. This apparent strength can mask overly restrictive verification: most false rejections in the analyzed records come from verifiers that accept no tested solution to a task. Case studies reveal unsupported assumptions about solution formats, tool use, and code changes that exclude valid solutions. These errors survive self-testing because agents test solutions that share the verifier's mistaken assumptions, or submit verifiers without confirming that any correct solution passes. These findings suggest testing both whether a verifier accepts a correct solution and whether it accepts other solutions permitted by the task. The project page and dataset are publicly available.