AI Evals for Beginners: The Playbook for Testing AI Features

Meera is a developer in Pune. Last week she added a small AI helper to her team’s support tool. It reads a customer email and writes a short, polite reply. She tried five emails, the replies looked great, and she shipped it.

On Monday her manager asked one simple question: “Is the new prompt better than the old one?” Meera froze. She had no way to answer. She had only a feeling. AI evals for beginners start right here, with that missing answer.

Last verified: 29 October 2026. AI tools change fast; check the linked sources for anything newer.

Who this is for: anyone who has built, or plans to build, a feature that calls an AI model. No maths needed. Time: about 30-45 minutes.

AI evals for beginners: what are they, in simple words

An eval is a test for an AI feature. Chrome’s developer team puts it plainly: “Evals are tests for your AI features”. You keep a list of questions, run your feature on all of them, and score the answers.

Think of a school exam. A teacher does not judge a student from one chat in the corridor. She sets a paper, marks every answer with the same rules, and gets a score she can compare next term. An eval is that exam paper for your AI.

Why not use normal tests? Because a language model can give a different answer to the same question each time (see our how LLMs work playbook for why). A normal test that expects one exact answer breaks. An eval accepts that answers vary and checks the quality instead.

You do not need special software to begin. A spreadsheet of examples, a few lines of code and one honest afternoon are enough. The tools can come later, once you know what you want to measure.

The playbook at a glance

1. Write down what “good” means for your feature.
2. Build a small test set of real examples.
3. Add simple checks that code can do.
4. Add an AI judge for the things code cannot check.
5. Run everything after every change and keep the scores.

Play 1: Write down what “good” means

Goal: turn a vague feeling into a short list of rules a stranger could use.

1. Ask: what would make a reply bad? Wrong facts, rude tone, too long, missing the question.
2. Turn each answer into a yes/no rule, such as “The reply is under 120 words.”
3. Keep it to 3-5 rules. More than that and nobody checks them.

Meera writes four rules: answers the customer’s question, polite tone, no invented refund promises, under 120 words.

You are done when: every rule can be answered with yes or no.

Play 2: Build a small test set

Goal: collect examples that look like real life, not only the easy ones.

1. Start with 20-30 real inputs. Old emails with names removed work well.
2. Include typical cases, odd edge cases (an empty email, a very long one) and tricky ones (an angry customer asking for money back).
3. Save them in a simple file, one row per example.

OpenAI’s evaluation best practices give the same advice: mix typical, edge and adversarial cases, and make the set mirror real traffic. Meera pulls 25 old emails. Six are tricky on purpose.

You are done when: you have at least 20 examples and some of them make you nervous.

Play 3: Add simple checks that code can do

Goal: catch the easy failures for free, in a fraction of a second.

1. Pick the rules a few lines of code can test: length, required words, banned words, valid JSON (see structured outputs).
2. Write one small function per rule that returns pass or fail.
3. Run it over every answer and count the passes.

def check_reply(reply):
    return {
        "short_enough": len(reply.split()) <= 120,
        "no_refund_promise": "we will refund" not in reply.lower(),
    }

results = [check_reply(ask_ai(email)) for email in test_emails]

This is only an illustration. In plain steps: ask the AI for each test email, run the two checks on the reply, and keep the results in a list. Meera’s first run shows 4 of 25 replies promising refunds. Her feeling had missed it.

You are done when: one command gives you a pass count for every code rule.

Play 4: Add an AI judge for the rest

Goal: check things like tone and “did it answer the question”, which code cannot see.

1. Write the judge a short instruction: the customer email, the reply, your rule, and “answer PASS or FAIL with one sentence of reason.”
2. Ask for pass or fail, not a score out of ten. OpenAI’s guide notes models judge pass/fail and pairwise choices more reliably than open scores.
3. Compare the judge with a human. Mark 10 answers yourself and see if the judge agrees. If not, fix the instruction.

An AI judge is like a junior colleague marking papers with your answer key. Useful, but you spot-check the marking. Meera finds her judge too kind, so she adds one example of a failing reply to its instruction.

You are done when: the judge agrees with your own marking on most of the 10 answers.

Play 5: Run it after every change

Goal: make the eval a habit, so every change gets a score.

1. Run the full set before you change anything. Save the score as your baseline.
2. Change one thing: the prompt, the model or a setting.
3. Run again and compare. Keep the change only if the score goes up and nothing important goes down.
4. When a real user finds a failure, add it to the test set.

Now Meera can answer her manager: the new prompt passes 23 of 25 on the refund rule, against 21 for the old one. A number, not a feeling.

You are done when: you can say “this change made it better by this much” and show the proof.

Which kind of check should you use?

Mistakes to avoid

• Judging by feel. “It seems to work” is not a result. Fix: write the rules and count passes.
• A test set of only easy cases. Fix: add edge and tricky examples on purpose.
• Trusting the AI judge blindly. Judges can favour longer answers or the first answer they see. Fix: compare with human marking and spot-check often.
• Waiting until launch. Fix: start with 20 examples on day one and grow the set.

How to know it is working

• You can rerun the whole eval with one command.
• Scores change when you change the prompt, so the eval is sensitive.
• The judge and a human agree on most answers.
• Real failures from users keep flowing into the test set.

Your checklist

• ☐ 3-5 yes/no rules for “good”
• ☐ 20+ real examples, including tricky ones
• ☐ Code checks for length, format and banned words
• ☐ An AI judge checked against your own marking
• ☐ A saved baseline score and a rerun after each change

Frequently asked questions

What is an eval in AI?

An eval is a repeatable test that scores the output of an AI feature against rules you wrote. It tells you whether a change helped or hurt.

How many test examples do I need?

Start with 20-30. That is enough to catch big problems. Add every real failure you meet and the set grows naturally.

What is LLM-as-a-judge?

It means using one AI model to mark another model’s answers using a written rubric. It handles qualities such as tone, but you must check it against human marking.

How are evals different from unit tests?

Unit tests expect one exact output. Evals expect answers to vary and score quality across many examples. Your testing habits still carry over.

Do evals work for agents and RAG?

Yes. For an agent, also check which tool it picked and with what inputs. For RAG, check that the answer matches the retrieved documents.

Meera’s next Monday

This story is made up, but the habit is real. Next Monday, Meera’s manager asks the same question. This time she opens her eval, shows two scores side by side and ships the better prompt. Your next step: write your 3-5 rules today. The next chapter on our roadmap covers prompt injection and AI security.

Sources: Chrome for Developers, Introducing AI Evals (updated 16 April 2026); OpenAI, Evaluation best practices. Numbers in Meera’s story are illustrative.