VerifierBench: Benchmarking the Generation of Executable Verifiers for LLM Agents

VerifierBench. Benchmarking the Generation of Executable Verifiers for LLM Agents. By Jianing Yin and six others, from the University of Pennsylvania, the University of Illinois at Urbana-Champaign, and three other institutions. Published on the nineteenth of October. Its code repository is worked out: about five hundred source files, with a readme and a licence.

Agents need reliable ways to check their own outputs, both while completing tasks and when filtering synthetic training data. One way to get that is to have the agent write the check. The paper studies verifier generation: given the instruction and the environment available for solving a task, an agent writes an executable verifier. A good verifier must accept every valid solution and reject the invalid ones. Both halves matter, because a check that wrongly rejects good work is as unreliable as one that waves bad work through.

VerifierBench measures both halves of that requirement. Its hidden test cases include alternative valid solutions, which a verifier should accept, and attacks, which it should reject. Performance is summarised as normalized balanced accuracy.

The benchmark has two hundred and twenty-two tasks drawn from six agent benchmarks, covering tool-call, state-based and code verification. Behind them sit four thousand nine hundred and ninety-three hidden test cases. The benchmark's own source verifiers and test suites are screened by an audit called Verifier4Verifier, or V4V, which runs six checks.

Nineteen models are tested in a common agent harness. Normalized balanced accuracy ranges from ten point six to sixty-two point one. Across the board, generated verifiers reject invalid solutions more reliably than they accept valid ones. Read on its own, that would sound like good news: the verifiers are hard to fool.

The analysis shows why it is not. That apparent strength can be a symptom of verification that is too strict. In the analyzed records, most false rejections come from verifiers that accept no tested solution to their task at all. Case studies trace this to unsupported assumptions about solution formats, tool use and code changes, assumptions that rule out valid solutions. The errors survive self-testing for two reasons. Agents test against solutions that share the verifier's mistaken assumptions, or they submit verifiers without confirming that any correct solution passes.

A verifier that rejects everything looks excellent at catching bad solutions, and it is useless all the same, since nothing a correct agent produces would ever pass it. The benchmark makes that failure visible by testing acceptance as seriously as rejection, and the authors' recommendation follows from it: check both that a verifier accepts a correct solution, and that it accepts the other solutions the task permits.