Skip to content

fix(metrics): escape decimal point in final_number_exact_match regex#4317

Open
devteamaegis wants to merge 1 commit into
stanford-crfm:mainfrom
devteamaegis:fix/final-number-regex-dot
Open

fix(metrics): escape decimal point in final_number_exact_match regex#4317
devteamaegis wants to merge 1 commit into
stanford-crfm:mainfrom
devteamaegis:fix/final-number-regex-dot

Conversation

@devteamaegis

Copy link
Copy Markdown

What's broken

final_number_exact_match mis-extracts the final number when a prediction contains a non-digit, non-dot character between digits. For example final_number_exact_match("30", "the meeting is at 7:30") returns 0, and final_number_exact_match("3", "the grid is 2x3") returns 0 — both should be 1. This silently lowers scores on any benchmark using this metric when models emit times, ratios, or dimensions before the answer.

Why it happens

The extraction regex is r"-?[\d,]+(?:.\d+)?". The . in the optional group is unescaped, so it matches any character; 7:30 and 2x3 get captured as a single token instead of extracting the trailing number.

Fix

Escape the decimal point: (?:\.\d+)?. Decimal handling is unchanged (\. still matches a literal .); only the spurious cross-character merges stop.

Test

Added two assertions to test_final_number_exact_match covering 7:30 and 2x3. They fail before and pass after; existing decimal/comma/negative cases still pass.

The number-extraction regex used an unescaped '.', which matches any
character. As a result a non-digit, non-dot character between digits
(e.g. '7:30', '2x3') was captured as a single number instead of
extracting the trailing number, producing wrong metric values.
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