Grab's engineering team built Grab Bench, an internal AI evaluation framework designed to catch subtle failures that public leaderboards miss. Unlike generic benchmarks, it tests models on Grab-shaped production tasks — SQL generation, tool calling, passenger-profile reasoning, and agentic coding — using synthetic but realistic data. Key design choices include deterministic scoring over LLM-judge confidence, explicit shortcut detection (e.g., cite-everything baselines, visible-test-only coding agents), and a split between teaching artifacts and hidden certification cases. The framework records row-level failure tags so engineers can debug specific failure modes rather than just comparing aggregate scores. A key lesson: more reasoning isn't universally better, and prompt/model settings must be tuned per task rather than globally.
Table of contents
IntroductionThe problem: plausible is not correctWhat Grab Bench runsDesign choice 1: make the cases safe, not genericDesign choice 2: score contracts, not confidenceDesign choice 3: make shortcuts visibleInternal reproducibility and hidden pressureWhat we learnedWhat comes nextJoin usQuestions this post answers
How do you prevent AI benchmarks from being gamed by shortcuts like citing all evidence or only passing visible tests?
Shortcut baselines must be built into the benchmark itself and made to fail. Running empty-output, cite-all-evidence, schema-only, and no-op agent baselines as explicit checks verifies the scorer penalizes those behaviors. For coding agents, hidden workspace tests, anti-gaming checks, and implausible difficulty curve detection block visible-test-only overfitting. If a shortcut baseline can pass, the benchmark is not measuring the intended contract. Teams hardening their own AI evals track patterns like these on daily.dev.
When should I use deterministic scoring vs an LLM judge for evaluating AI model outputs?
Use deterministic scoring whenever the task has a verifiable contract: ontology values, evidence IDs, canonical tool names and parameters, or test pass/fail results. Reserve LLM judges for open-ended tasks like SQL generation where correctness depends on business intent and query shape. Deterministic scoring produces an audit trail that shows exactly which constraint was violated, rather than whether an answer 'seems good'. Developers choosing between eval strategies for their AI pipelines find relevant comparisons on daily.dev.
How do you structure an internal AI benchmark so it stays reproducible without letting teams overfit to the test cases?
Split artifacts into two categories: teaching artifacts (task contracts, scorer logic, examples, baselines, canaries) that are openly inspectable, and certification artifacts (hidden splits, seeds, raw outputs) kept behind access controls. Before trusting a comparison run, gate checks verify that oracle solutions pass, weak baselines fail, and canaries catch harness regressions. Shared examples teach the method; hidden cases check generalization. Engineers building internal eval infrastructure for AI systems share approaches like this on daily.dev.
5.3K Impressions1 Comment