classic evals moment.

the demo lied politely.

evals are the guardrail between “i tried a thing” and “users now live with this thing.”

in the AI engineering loop, production traces feed datasets, datasets feed experiments, experiments get evaluated, good changes ship, then production gives you new traces.

right. for apps, evals are behavior regression tests.

take real-ish cases, run your app on them, judge the outputs.

start manually. read outputs. mark what’s good, what’s broken, what keeps repeating.

you can, after you know what the annoying part is.

manual review is how you learn the failure modes before you build machines to detect them.

three buckets: human review, code checks, LLM-as-judge.

it can be. that’s why you calibrate it against human labels.

LLM judges are useful for meaning: relevance, tone, summary quality, following nuanced instructions.

schemas, keywords, SQL executes, length limits, forbidden fields. cheap, deterministic, boring in the best way.

exactly. code can say “5 bullets.” it can’t reliably say “not misleading.”

sometimes. reference-based evals compare against an expected answer.

reference-free evals judge the output on its own, which helps with messy production traces.

that’s the loop. trace weird behavior, turn it into dataset rows, test experiments against it before shipping.

when a failure mode repeats and you need to test it over and over.

if one prompt fix solves it, just fix the prompt. don’t build a shrine.

specific criteria. “helpfulness 1-5” is mush. “answer cites the refund window correctly: pass/fail” is useful.

binary pass/fail often beats vague graded scales.

pull 30-50 real examples. run old and new versions side by side. read them.

write failure labels in plain English: missed policy, too verbose, invented SQL column, wrong tone.

yep. code for mechanical rules, LLM judge for meaning, calibrate both against human review.

keep watching production. new failures become the next dataset.

that’s evals.