Evals: Measure Your Task, Not the Hype

Outcome. You can build a small representative eval with explicit criteria, compare models fairly, and report uncertainty, cost, latency, and failure patterns instead of one overall vibe score.

Public benchmarks make progress comparable, but every score belongs to a task definition, dataset, prompt, grader, model version, and execution configuration. Contamination, saturation, implementation differences, and optimization toward a known test can reduce what a score predicts. No benchmark proves “general intelligence” or guarantees success on your internal workflow.

A product eval starts with production-like cases. Include common requests, high-value cases, boundaries, missing data, adversarial inputs, Khmer where relevant, and known failures from logs. Define criteria before running candidates: exact-match or executable checks where possible, clear rubrics and calibrated human review where judgment is needed. Model graders can scale review but may have position, verbosity, and self-preference biases, so calibrate them against humans.

Report multiple dimensions: task success, severe failure rate, uncertainty, p50/p95 latency, token and tool cost, and cost per successful task. Use confidence intervals or at least raw counts and sample size. Keep the set versioned, protect a holdout, and run regression evals on every meaningful prompt/model/retrieval change.

Mental model. An eval is an executable product requirement: cases + criteria + configuration + results + decision rule.

Evidence trail — reviewed 23 July 2026. HELM advocates multi-scenario, multi-metric evaluation: https://arxiv.org/abs/2211.09110. MT-Bench documents strengths and biases of model judges: https://arxiv.org/abs/2306.05685. Use vendor-neutral datasets even if a provider hosts the runs.