Skip to content

Fix MBPP+ grader scoring 0.0 (unconditional check(entry_point) call) - #25

Merged
ezosa merged 1 commit into
mainfrom
fix-mbpp-plus-grader
Sep 11, 2026
Merged

ezosa merged 1 commit into
mainfrom
fix-mbpp-plus-grader

Conversation

@ezosa

@ezosa ezosa commented Sep 11, 2026

Copy link
Copy Markdown

Problem

A real iter16000 run surfaced mbpp_plus = 0.0000 across all 378 problems (with sub-0.06 truncation, so generations were fine). Root cause: execution._build_program appended check(entry_point) to every problem, but the two EvalPlus benchmarks structure their test field differently:

  • HumanEval+ defines def check(candidate): ... → must be invoked as check(entry_point).
  • MBPP+ has no check wrapper; its assertions call the target function directly at module scope.

So every MBPP+ problem raised NameError: name 'check' is not defined → the whole task scored 0. HumanEval+ was unaffected (0.622 on the same run).

Fix

Only append check(entry_point) when the harness actually defines check (regex on the test string); otherwise concatenate generation + test so the module-level asserts execute directly.

Tests

The prior tests only exercised the HumanEval check() shape, which is why CI stayed green. Added:

  • MBPP-style direct-assert grading (correct → pass, wrong → fail)
  • program-shape assertions: MBPP harness does not get a check(...) call appended; HumanEval one does

Verified locally: humaneval correct/wrong pass/fail unchanged; mbpp correct now passes (was failing → 0.0).

🤖 Generated with Claude Code

…tests

MBPP+ test harnesses assert against the target function directly at module
scope and define no `check` wrapper, whereas HumanEval+ tests define
`def check(candidate)` and must be invoked as `check(entry_point)`.

`_build_program` appended `check(entry_point)` unconditionally, so every
MBPP+ problem raised `NameError: name 'check' is not defined` and the whole
task scored 0.0 (confirmed on a real iter16000 run: mbpp_plus=0.0000 with
sub-0.06 truncation). Detect the `check` definition and only emit the call
when present; otherwise the harness's module-level asserts run directly.

Add MBPP-style (direct-assert) grader tests plus program-shape assertions so
the two harness styles are both covered — the previous tests only exercised
the HumanEval `check()` shape, which is why CI stayed green.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@ezosa
ezosa merged commit f6c6081 into main Sep 11, 2026
4 of 5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant