systemdesign.academyAI EngineeringFree lessonsSign inGet the course
  1. Home
  2. AI Engineering: Evaluation, LLM Ops and Security
Previous lessonLLM-as-Judge and Its Failure ModesNext lessonEvaluating RAG and Agents: One Score Detects, Components Localize

System Design

  • Foundation
  • Intermediate
  • Advanced
  • Capstone

AI Engineering

  • Foundation
  • Data, RAG and Agents
  • Evaluation, LLM Ops and Security

systemdesign.academy

  • Home
  • Glossary
  • Interview prep
  • Reviews
  • About
  • Pricing
  • Privacy
  • Terms
  • Refunds
  • Delivery
  • Contact
  • LLM Evaluation and Error Analysis
  • Validating Your Judge: TPR, TNR, and the Human Ceiling
  • AI Engineering · Evals

    Validating Your Judge: TPR, TNR, and the Human Ceiling

    Free preview: the first part of this 11-part lesson.

    Already bought the course? Sign in to read the whole lesson.

    this lesson is part of

    AI Engineering

    Unlock this lesson and the 199 other paid lessons

    • 210 lessons in 16 chapters
    • 118 lessons built on a lab that really ran
    • An AI tutor beside every lesson that answers and draws
    • Lifetime access, every new lesson included

    $49 once, by PayPal

    See the AI Engineering course

    The rest of this lesson

    1. Validate a Judge Like Any Other Classifier
    2. Four Boxes: Where TPR and TNR Come From
    3. Why Accuracy Lies When Most Outputs Are Good
    4. Your Metric Is a Sample, So Report the Interval
    5. The Two Errors Cost Different People
    6. The Human Ceiling: Stop Chasing Perfect Agreement
    7. Narrow Binary Questions Raise the Ceiling Itself
    8. What Validation Costs, and When to Do Less of It
    9. What Serious Teams Do Before They Trust a Judge
    10. Knowledge Check

    read the rest of this lesson in

    AI Engineering

    Unlock this lesson and the 199 other paid lessons

    • 210 lessons in 16 chapters
    • 118 lessons built on a lab that really ran
    • An AI tutor beside every lesson that answers and draws
    • Lifetime access, every new lesson included

    $49 once, by PayPal

    See the AI Engineering course

    Continue this lesson

    in Evals

    This lesson is part of the AI Engineering course. Unlock the full course, a separate one-time payment, for lifetime access.

    One-time payment. Lifetime access. No subscription.
    Global
    $49/lifetime

    One-time payment via PayPal

    Get Lifetime Access
    Foundation lessons free, try before you buy
    India Special
    India
    ₹999/lifetime

    One-time payment: UPI, card or netbanking

    Get Lifetime Access
    Foundation lessons free, try before you buy
    Every ML Platform lesson, Foundation to Advanced
    Real architecture diagrams with real tool logos
    MLOps, LLMOps, and data engineering in depth
    Quizzes with instant feedback
    Built and reviewed by senior engineers
    Lifetime access, all future content included

    Foundation lessons of this course are free, no payment needed. Try them now

    The 92 Percent That Meant Nothing

    92 percent pass rate. That is the first number a new LLM judge reports for the support agent, and it is exactly the kind of number that ends a discussion. It goes in a slide, the feature ships wider, and the judge becomes the quality gate on every release. One question never gets asked: how good is the judge itself? A 92 percent pass rate from a judge nobody has checked is not a measurement. It is a guess with a decimal point.

    Two months later a customer escalation lands on an engineer's desk. The agent had confidently given a refund policy that does not exist. She pulls the trace. The judge had marked that answer pass. She pulls a hundred more of the judge's passes and reads them by hand. Roughly one in six is wrong in a way a human reviewer would have failed on the spot. The 92 percent was real arithmetic on a judge that could not tell a good answer from a bad one.

    Here is the quiet part. Nobody had ever checked whether the judge agreed with a person. They built a measuring instrument and never calibrated it, then made decisions on its readings for two months. The judge was not lying. It was just never validated, so its number had unknown accuracy, and a number with unknown accuracy is not a measurement. It is a guess wearing a percent sign.

    An unvalidated judge is a confident number with unknown accuracy. A validated judge is a measurement you can trust to run at scale.

    The reason this is worth a whole lesson is that the cost of skipping the check does not stay small. It compounds. The few hours you saved by not building a validation set turn into a shipped error. Then weeks of that error reaching users under a green light. Then an incident, and a loss of trust in the whole eval programme. Follow the price of one unchecked judge from the moment it grades to the moment it becomes an escalation.

    Cost cascade of one unvalidated judge across four stages left to right: an unvalidated judge that saved a few hours marks a wrong answer PASS, the bad output ships into the product while the eval board stays green, users hit the same class of error for weeks across thousands of sessions because the judge gates every release, and finally an engineer reads a hundred passes by hand and finds one in six wrong so trust in the whole eval program is gone, with the money cost growing at each step

    This lesson closes the loop the chapter has been building toward. You have an LLM judge. Before you let it grade thousands of outputs you cannot read yourself, you have to prove it agrees with a human expert. The good news: you already know how to do this, because it is the same thing you do to any classifier.