Evals are the hottest topic in 2026.

In 2026, companies actually expect you to build reliable AI applications. That is one major change I see in AI between 2025 and 2026.

This is bringing back questions which we already knew the answers to as software engineers. Do you have unit tests around? Do you have any tools to measure the improvement in performance?

This entire umbrella of behavioural tests, unit tests and measuring performance is termed as evals now.

Without evals, teams building AI applications face three problems:

1. Users report that the application feels worse after a change.
2. Engineers can't tell a regression from noise.
3. Nobody can measure an improvement.

In this blog we will see what evals are, how an expert evaluates an AI system, and how an LLM judges it at scale.

1. Why evals?

For example, if you have a customer support bot, is it really reducing the average time to answer questions? Is it reducing the effort on the side of customer support agents?

And what does a team do when users say the new version is worse? Without evals, guess and check.

The user made a report. The user said this is wrong. You try to take a screenshot, pick up that user query, and try to improve the system prompt.

This is a very reactionary way of dealing with things, and it's also not guaranteed to actually take you forward.

The LLM gives different answers to the same question. So is the system prompt wrong, or was that one answer a mistake? Nobody can tell.

So even though people can build agentic systems, very few of them go to prod, and even fewer actually make money for the organisation. You need an objective and subjective way to tell whether these agents are actually useful.

That way is an eval suite. A test suite checks code against its cases. An eval suite is hundreds of scenarios, and your agent's performance in those scenarios.

2. What do we evaluate?

Can you evaluate everything in an AI system? Only what you can measure and change.

Any AI system given to you has tunable components. Those components will be tuned by engineers.

For RAG, it is retrieval and answer quality. For agentic systems, it is outcomes: given a task, have you passed K times out of 100?

A one or a zero per task is too brutal on its own. So an agent is also evaluated on its process: did it call the right tools? And on safety: did it hallucinate, and were the guardrails followed?

A RAG-based system can be checked for answer relevance, but not for tool calling order. Any system you build needs evals based on that system's capabilities.

3. Human evals

Who decides whether the support bot answered well? In 2026, a person still does it best.

As software engineers, we build an agent and forward this version to a subject matter expert. If you're building a healthcare app that faces customers, you want a nurse or a doctor to look into it.

They're not going to read code. They're going to create 20 to 50 commonly asked or important user queries.

The engineer runs the queries as input to the agent and notes the response. An Excel sheet is sufficient for this.

Query	Answer	Expert's comment
How does the attention mechanism work in transformers?	It maps a query and a set of key-value pairs to an output, as a weighted sum of values	No references, no explanation of what attention is

The expert says what the problem is. The engineer then changes the tunable part of the system: the system prompt, the re-ranker or the chunking.

The system is evaluated again on the same queries, until the expert says it is good to deploy. This is an eval suite, and you keep adding scenarios to it.

Customers may then ask questions the expert didn't predict, or mark an answer down. Those come back to the expert as new queries, and the loop continues.

4. An LLM as a judge

Can a unit test check the bot's answer? No: the same correct answer can be worded a hundred ways, so a string match fails.

So what if we use an LLM, or a set of LLMs, to judge our system's response? It's the age of AI. Let's use an LLM.

Think of the judges of Indian Idol. Four judges sit in a panel. Just like that, your system's responses are judged by multiple judges.

Each judge takes one thing, like answer relevance or groundedness, and gives you a score. If all judges say you're doing well, you get a pass. Even if one judge says the answer was not grounded, there's a failure, and then we debug it.

Isn't an LLM judging an LLM a cyclic dependency? It is. The same limits of intelligence apply to both.

But the judge has a different system prompt, and so a different goal. Because of that, one LLM can judge the other, to some extent.

Each judge checks one of three things:

1. Answer relevance. Is the answer on topic and to the point?
2. Groundedness. Does the answer quote the right references? A grounded answer means fewer hallucinations.
3. Coherence. Is the flow of thought good, without a massive long response?

Why not keep the expert? Because it doesn't scale. OpenAI, Anthropic and Google have far too many query patterns for one subject matter expert, and a judge is much cheaper.

5. How to build a good judge

Judges have biases, like people do. How do you keep them fair?

Each judge does one thing, so it is scoped. Linux philosophy: do one thing, do it well. Responses are binary, in an exact JSON format.

LLMs consider long responses good. So you cap the response size, so that both responses are of similar size.

Then there is first-response bias. Tell a judge which response came first, and it tends to prefer that one. So you evaluate each pair in both orders, one then two, and two then one.

Even with both orders, a judge can prefer its own model family. A model judging an answer from its own family likes it, because the format and the language are similar. So you use a jury of models, one each from OpenAI, Anthropic and DeepSeek, and take their score out of three.

Bias	What the judge does	The fix
Length	prefers the longer answer	cap the response size
Position	prefers the answer it read first	judge each pair in both orders
Self-preference	prefers answers from its own model family	a jury of models from different companies

6. Evals in production

Does the work end at deploy? No. The answers can get worse while nobody changes the code.

So even though the eval suite did well in testing, in production the judges are not liking your answers. This is drift.

Out of every 100 requests, maybe one is given to the judges, and they tell you whether the scores are good. When the scores go below a threshold, you fire an alert and look into it.

Users notice worse answers too. When users mark answers down and the judges score them low, the bot that passed its eval suite is failing in production.

Summary

1. Evals are the umbrella of behavioural tests, unit tests and performance measurement for an AI system.
2. An eval suite is hundreds of scenarios, and your system's performance in them.
3. A system is evaluated on its tunable parts. RAG is evaluated on retrieval and answer quality, and agents on outcomes, process and safety.
4. In human evals, a subject matter expert writes 20 to 50 queries and comments on each answer.
5. An LLM judge scores one thing, such as answer relevance, groundedness or coherence, with its own system prompt.
6. A judge's length, position and self-preference biases are fixed by a capped length, both orders and a jury of models.
7. In production, a sample of requests goes to the judges, and low scores raise an alert.