Evals for Humans - From Axial to Recall a humans guide to AI evaluation jargon

Evals for Humans - From Axial to Recall a humans guide to AI evaluation jargon

AI evals sound complex. They’re not.

Even though the sound of it is something quite atrocious,
if you say it loud enough you’ll always sound precocious.

Axial and TPR, toxicity and recall.
Evaluation, ground truth set, transition failure matrix.

Criteria drift and RAG, hallucination scoring.
Regression test and LLMs and multi-turn conversation.

AI jargon can feel like a spell book written in a secret tongue.

---

What’s underneath it

It dazzles.
It intimidates.
It makes the rest of us feel like outsiders nodding along.

But strip away the incantations, and what are we left with?

Simple human practice: notice what broke, fix it, and try not to break it again.

---

Why this matters

Hamel Husain and Shreya Shankar, along with others, have done something important.

They’ve taken this fuzzy business of testing AI and given it structure.

That’s valuable.

Their approach is rigorous.
And it works.

But the way it gets talked about can make the rest of us feel like we’re missing a class in a language we didn’t even know existed.

So here’s a plain-English guide to what they’re saying, what it means, and how to use it.

---

1. Start with what breaks

What they say

Do an error analysis with “open coding” and “axial coding”.

What that means

• Watch your AI in action with ~100 real examples
• Ask a domain expert to mark each one: pass or fail
• For failures, write down why
• For passes, note what worked (and what could improve)
• Group failures into a small set of categories (≤10)

That becomes your taxonomy of failure modes.

Everyday metaphor

Like cooking for friends.

• It either worked, or it didn’t
• Then you group the issues:
  • too salty
  • overcooked
  • recipe unclear

---

2. Test the right things the right way

What they say

Build a reliable evaluation suite using:

• code-based evaluators
• LLM-as-a-judge

What that means

• For simple checks → use code tests

  • e.g. “Does this include a date in the right format?”

• For subjective quality → use an AI judge

  • trained on examples from your domain expert
  • aligned to your quality bar

Keep it simple:

• code for objective checks
• AI for judgement

Everyday metaphor

Parenting.

• “Did the lunchbox go in the bag?” → rule-based
• “Was that message kind?” → judgement

---

3. Build a ground truth

What they say

Create a ground truth dataset, split into train/dev/test, and measure TPR and TNR.

What that means

• Label examples as pass/fail with explanations
• Use some to train your judge
• Use some to refine it
• Keep some hidden to test it properly

Then measure:

• TPR (true positive rate) → how often it says “yes” correctly
• TNR (true negative rate) → how often it says “no” correctly

Everyday metaphor

Driving.

• Do you stop when you should? (TNR)
• Do you go when it’s safe? (TPR)

Always stopping or always going are both failures.

---

4. Make it continuous

What they say

Operationalise your evals for continuous improvement.

What that means

• Bake tests into your release process
• Rerun them every time you ship
• Catch regressions early

Over time, it becomes a loop:

• find the biggest problems
• fix them
• test again
• repeat

Everyday metaphor

Home maintenance.

You don’t fix the leak once and forget it.

You keep checking so small issues don’t become big ones.

---

Where systems break differently

Different AI systems fail in different ways.

Multi-turn conversations

Check if the whole interaction achieved the goal.

If not:

• did it lose context?
• or never understand the problem?

Metaphor: a story that loses its thread halfway through.

---

RAG (retrieval-augmented generation)

Separate:

• did it find the right information?
• did it use it properly?

Metaphor: research and writing are not the same skill.

---

Agents (multi-step systems)

Map where things break.

This is often called a “transition failure matrix”.

In plain terms:

• which step fails most often?

Metaphor: baking a cake.

Did you:

• forget an ingredient?
• burn it?
• drop it at the end?

---

Why the language exists

Inside large organisations, shared language matters.

“Error analysis” means the same thing to everyone.

That helps coordination.

But if you’re a product team, or just trying to understand what’s going on, you don’t need the jargon to get the value.

---

What this actually is

At its core, evals are just this:

• Group the mistakes into buckets
• Make sure fixes don’t break something else
• Use human-labelled examples of good and bad
• Teach, refine, and test on fresh data
• Use another AI to check the first AI’s work

And measure things like:

• how often it says “yes” correctly
• how often it says “no” correctly
• how often it makes things up
• how harmful or unsafe outputs are

---

The simple version

Evals = tests that matter.

---

One final note

This post uses levity to untangle complexity.

But it builds on the work of Hamel Husain and Shreya Shankar, who have trained thousands of PMs and engineers in these methods.

Their course, AI Evals for Engineers & PMs, is worth exploring if you want the full system.

And Lenny’s Newsletter remains a strong source of insight, and where I first came across their work. :contentReference[oaicite:0]{index=0}