Evaluating LLM Outputs: Testing the Untestable

You cannot ship what you cannot measure, and a non-deterministic system resists the deterministic tests engineers are used to. The same prompt can produce two valid answers, or one valid and one wrong, run to run. Evaluating LLM outputs is the discipline that turns "it seemed to work" into "it passes," and it is what separates a demo from a product.

You can't ship what you can't measure

Without evals, every prompt change is a gamble — you fix one case and silently break three others, and you find out from users. A test suite for AI is not optional polish; it is the only way to change a prompt or swap a model with any confidence that you did not regress the behavior that mattered.

Three layers of evaluation

Start cheap and deterministic: schema and assertion checks that catch malformed or out-of-range outputs instantly. Add a golden set — a curated bank of inputs with known-good expectations you run on every change. And for subjective quality, use a stronger model as a judge, scoring outputs against a rubric. Each layer catches what the cheaper one cannot.

// cheapest layer: deterministic assertions on every output
const out = Verdict.safeParse(await run(input));
expect(out.success).toBe(true);            // valid shape
expect(out.data.citations.length).toBeGreaterThan(0); // grounded
expect(out.data.confidence).toBeLessThanOrEqual(1);    // in range

Make evals part of the loop

Evals only help if they run automatically — on every prompt edit, every model bump, every retrieval change. Wire them into CI so a regression fails the build instead of reaching production. The moment evaluating an AI feature feels as routine as running unit tests, you have crossed from experimenting to engineering.

A model you cannot evaluate is a model you cannot improve — you can only change it and hope. Evals turn hope into a passing build.

Evaluation pairs with validation; the Type-Safe LLMs post covers enforcing the contracts your evals assert against.