Writing Evals That Predict Production

A green eval score feels good and can lie to you. If the test set does not look like real usage, a high score just means you are good at your own test.

Build evals from real failures

The best test cases come from things that already went wrong. Every time the system gives a bad answer in the wild, that example goes into the eval set. Over time the suite starts to look like your actual traffic, which is the only thing worth measuring against.

What we keep in the suite

• Real questions users asked, including the awkward ones.
• Cases that broke before, so they never break again quietly.
• A few adversarial inputs to check the guardrails hold.

Run it every change

An eval is only useful if it runs on every change and blocks a release when it drops. Treat it like a test suite, not a one-time report. That is what turns "it seemed fine" into something you can actually trust.