Evals before models: the asset almost nobody builds

There is a question we ask in every technical meeting that almost never has an answer: “how will you know the change made things better?”

If the answer is “we try it and you can tell”, the team is flying blind.

The problem with public benchmarks

The 2026 AI Index from Stanford documents the phenomenon well: SWE-bench Verified went from 60% to near 100% in a year. When a benchmark saturates it stops discriminating — every model passes and the leaderboard no longer helps you choose.

Then there is the more serious problem: the benchmark does not measure your task. The same report notes that top models read an analogue clock correctly 50.1% of the time. A system can be excellent at mathematical reasoning and mediocre at parsing your main supplier’s particular invoice format.

Academic work points the same way. The LaRA benchmark, with 2,326 test cases across eleven models, concludes that the optimal choice between retrieval and long context depends on a complex interplay of model capability, context length, task type and retrieval characteristics. Translation: there is no general answer. There are only answers for your case.

What an in-house eval set is

It is not complicated, and that is the trap: it is so unsophisticated that teams skip it.

It is a file of real cases from your business with the correct answer for each. Fifty to two hundred cases is usually enough to start. For a ticket classifier: 150 real tickets with their correct category. For invoice extraction: 100 invoices with the fields that should come out.

The hard part is not technical. It is getting someone who knows the domain to sit down for two days and label cases. That is the entry price, and it is the best money you will spend on the whole project.

Why it changes everything

It turns opinions into numbers. “The new prompt works better” becomes “accuracy goes from 82% to 89%, and gets worse on cases with more than three line items”.

It makes switching models possible. With your own eval, trying a new provider is an afternoon. Without one, it is a blind migration nobody wants to approve. With six frontier models within 25 Elo points of each other, that agility is worth money.

It catches silent regressions. Providers update their models. Your system can get worse without anyone touching a line of code, and without an eval you find out through a customer complaint.

It protects you from enthusiasm. When someone proposes rewriting the system in the fashionable architecture, the eval answers whether it is worth it.

How to start this week

1. Collect 50 real cases from the process you want to improve. Real ones, with their noise and their oddities.
2. Write the correct answer for each. Have the person who knows the subject write it.
3. Include the hard cases deliberately. The badly scanned document, the odd supplier’s invoice, the customer who writes in three languages.
4. Run it on every change. Prompt, model, tool, version.
5. Keep the history. The curve over time is what tells you whether the team is making progress.

The model you use today will not be the one you use in a year. Your eval set will be, which makes it the only technical asset in the project that appreciates.

Sources

• The 2026 AI Index Report — Stanford HAI
• LaRA: Benchmarking Retrieval-Augmented Generation and Long-Context LLMs — ICML
• EnterpriseRAG-Bench: A RAG Benchmark for Company-Internal Knowledge — arXiv
• A Systematic Literature Review of Retrieval-Augmented Generation: Techniques, Metrics, and Challenges — arXiv