Evals before vibes

Too many LLM features get approved on vibes. Someone tries a handful of prompts in a meeting, the answers look sharp, and the feature ships. Then it fails quietly on a case nobody tried, in front of a customer, and nobody can say how often that happens.

The fix is not clever. Decide how you will measure the feature before you choose the model, and treat the measurement as part of the product.

Label before you look

Start with a golden set: a few dozen real cases from the actual workflow, labelled by hand by someone who knows the domain. Write a short labelling guide as you go and note every hard call, because the hard calls are where the model will struggle too.

Two rules matter more than the size of the set. Label each case before you see any model output, or you will end up grading the model against its own answers. And relabel a sample a week later, or ask a second person, so you know how often the humans agree. Where two experts disagree, a model’s score on those cases means very little.

Put an interval on every number

Small sets give wide answers, and that is fine as long as you say so. Say a model gets four in five cases right on a set of forty. The honest claim is that its real accuracy sits somewhere between about two in three and nine in ten. That range is the result. A single percentage hides it.

Intervals also make choosing a model pleasantly boring. My rule: take the smallest model whose interval overlaps the best model’s, then compare cost and latency. Pin the dated model version rather than the alias, date the price table, and rerun the set every quarter, because aliases and prices both move.

Keep the arithmetic out of the model

In Licita, an independent research project on public procurement, language models have one narrow job: reading tribunal rulings into a strict schema. Every quote they return is checked against the exact text they were given. A quote that does not match is flagged, never shown as evidence.

Every number the reader sees is computed by ordinary, tested code, with its source and data date beside it. When the interval around a figure includes zero, the memo shows no figure at all. A number with a coin-flip sign is worse than none. Keeping the model’s job this narrow is what makes it measurable, and what makes a small model a realistic option.

Test the cheap option, and your own pipeline

Before spending anything on API calls, I ran an open-weight model on free cloud GPUs with the same prompt and schema. Its output was valid and its quotes mostly checked out. It still failed the one judgement that mattered: what the tribunal actually decided on each ground. That run cost nothing, and it is why the evaluation harness came before any scale.

Your own pipeline needs evals too. When I cross-checked Licita’s headline figure, I found two defects of my own: some lots were measured against the budget of the whole tender they belonged to, and some award rows were counted twice across overlapping archives. Both are now hard checks that stop a bad build from going live.

If you are about to ship an LLM feature, start here:

• Collect a few dozen real cases and label them before any model sees them.
• Write down what “correct” means, including the hard calls.
• Report every metric with an interval, and nothing below a minimum sample.
• Let code compute every number a user will act on.
• Pin model versions, date your prices, and rerun the set when either changes.

Vibes are fine for a demo. Anything a customer relies on gets measured first.