Vibe Engines
YouTube
AI ENGINEERING

AI Evaluation

How you know an AI system actually works — LLM-as-judge, agent evals, and metrics like token-F1 — the half of AI engineering that separates demos from production.

22 pieces · 7 formats Follow this topic (RSS)

AI evaluation is how you find out whether a model-powered feature actually works, and whether a change made it better or worse. Ordinary software has exact expected outputs. A language model can phrase a correct answer a hundred ways and a wrong one convincingly, so evaluation replaces assertEquals with a measurement discipline: a fixed set of test cases, a way to score each output and a threshold that decides whether a change ships.

Core ideas and trade-offs

  • The golden set is the benchmark that matters. A modest set of realistic, versioned examples from your own domain tells you more than any public leaderboard. Freeze it, cover the cases you care about and add each production failure you find.
  • Scorers trade cost for nuance. Programmatic checks such as exact match, token-level F1 and schema validity are cheap and deterministic. An LLM judge handles open-ended answers but has known biases toward answer position, length and its own style. Human review is the most trusted and the slowest. Real pipelines combine all three.
  • Calibrate before you trust. A judge is useful only if it agrees with expert humans on a sample. Measure how often two experts agree with each other first; that rate is the realistic ceiling for any automated score.
  • Averages hide regressions. A change can raise the mean while breaking one important case, so gate on an aggregate threshold and on per-case no-regression.
  • Offline and online are two loops. Offline evals block bad changes before release; online monitoring, traces and user feedback catch drift and the inputs no fixed set anticipated.

How the formats fit together

The lab walks the whole arc in one sitting, turning “it should be accurate” into metrics, an agreement ceiling, a calibrated judge and a CI gate. The coding challenge has you implement a real metric by hand, so you know exactly what a score measures. The handbooks go deep on CI gates, agent trajectories, client-facing evals and interview-level vocabulary, and the tools generate a judge rubric or test whether an A/B result is significant. The system designs treat evaluation as infrastructure: eval and observability pipelines, labeling platforms, prompt A/B testing and model registries. The roadmaps for QA, AI safety and red-teaming show where these skills lead.

Common mistakes

  • Evaluating on ten hand-picked examples and calling it a benchmark.
  • Trusting an LLM judge without checking it against human grades.
  • Promising a quality number higher than your own experts can agree on.
  • Re-running a noisy eval until it passes instead of setting a tolerance band.

Start here, in this order

  1. Eval Builder: From Fuzzy Goal to CI Gate — Play the full arc first, from a fuzzy goal to a gate that blocks a bad change, so every later page has a place to fit.
  2. Token-Level F1 — Implement a real question-answering metric by hand and see exactly what overlap-based scoring rewards and misses.
  3. LLM-as-Judge Rubric Builder — Draft a judge rubric with the position, verbosity and tie pitfalls called out before you automate any grading.
  4. The Evals in CI Handbook — Wire a golden set into CI with an aggregate threshold, a per-case regression check and a tolerance band for noise.
  5. The Agent Evaluations Handbook — Extend the same discipline to multi-step agents, where the path matters as much as the answer.
  6. Design LLM Eval & Observability — See evaluation as infrastructure, with tracing, versioned datasets, combined scorers and production monitoring working as two connected loops.

Questions

What is an LLM eval?

An eval is a repeatable test of a model-powered system’s output quality. It pairs a fixed set of inputs, often called a golden set, with a scoring method and a pass threshold. Scoring can be programmatic, such as exact match, token overlap or schema validation; model-graded, where another LLM applies a rubric; or human. You run the eval on every meaningful change to prompts, models, retrieval or tools, compare the result with the last accepted version, and block changes that make important cases worse. It is the AI equivalent of a regression test suite.

Can I trust an LLM to grade another LLM?

Sometimes, once you have checked it. LLM judges have documented biases: they can favor the first answer shown, longer answers, and answers written in a style like their own. Before relying on one, have domain experts grade a sample, compare the judge’s scores with theirs, and report that agreement alongside any number the judge produces. Swapping the order of answers, using a specific rubric with examples, and asking for a short justification before the score all reduce bias. Keep humans reviewing a rotating sample even after the judge is calibrated.

How big should a golden set be?

Big enough to cover the cases you care about and small enough to run on every change. Many teams start with 50 to 200 examples drawn from real usage, spread across topics, difficulty levels and known failure types, then grow the set by adding each production failure they find. Coverage and stability matter more than size: freeze the set so scores stay comparable over time, version it when it changes, and hold out a slice you never tune against, so prompts do not quietly overfit the cases you test.

What is the difference between offline and online evaluation?

Offline evaluation runs a fixed dataset through the system before release, so you can compare versions on identical inputs and block regressions in CI. Online evaluation measures the live system through traces of real requests, sampled human or judge review, user signals such as thumbs-down ratings or retries, and dashboards for cost and latency. Offline tells you a change is safe to ship; online tells you what real users actually send and where quality drifts over time. Each feeds the other, because failures found online become new offline test cases.

Handbooks 5

Handbook

51 LLM Evals Interview Questions

Golden sets, LLM-as-judge, regression testing, offline vs online evals, RAG evals, agent evals, red-teaming, and observability — demystified for interviews and production.

AIEngineering
Handbook

The Agent Evaluations Handbook

A self-contained handbook on evaluating AI agents — theory, interactive widgets, and practical guidance. Trajectory evals, tool-use scoring, LLM-as-judge, observability, and reliability for PMs, engineers, and founders.

AIEngineering
Handbook

The Evals in CI Handbook

Turn LLM quality into a regression gate, like unit tests for code. A golden set scored on every change, and why the gate needs both an aggregate threshold AND per-case no-regression — because a healthy average can hide a broken case (mean stays up while one case collapses). How to wire it into the PR pipeline, handle non-determinism with a tolerance band, and avoid a flaky gate. With worked math and runnable code.

AIEngineering
Handbook

Self-Improving Agents

The long one: how an agent gets better at its own job, end to end. COVERAGE vs the accuracy you can ship (a model usually already produces a right answer somewhere in its output; the missing piece is recognising it), unbiased pass@k, why the sampling curve is straight, the SELECTION bottleneck, building a VERIFIER and the two asymmetric ways it is wrong, feedback that is not a verifier ranked by independence, the five-predicate filter that decides what becomes training data, the SIX substrates a lesson can land in (context, memory, tools, scaffold, verifier, weights) and how to choose, STaR through PPO/GRPO/DPO and reward hacking, why a loop refit on its own output COLLAPSES toward its own habits, search as self-improvement, and measuring a time HORIZON rather than a score. 14 sections, 13 runnable Python blocks, 3 interactive models, 13 diagrams, 5 checkpoints and a running build log. Every figure carries the condition it was measured under.

AIEngineering
Handbook

Evals for Client Work

The most-cited hard skill in frontier-lab FDE job descriptions and the least taught anywhere: turning “it should be accurate” into a gate. Measure inter-expert agreement before you promise a number, build a golden set that survives contact, calibrate an LLM judge against human grades, wire the CI gate (including the per-case regression check), and hand the whole thing over.

FDEEvalsAI

Roadmaps 3

System Designs 1

AI System Designs 9

AI System Design

Design LLM Eval & Observability

Build an LLM evaluation and observability pipeline. See how offline evals and online observability form two loops, how tracing every call is the foundation, how versioned golden datasets become your real benchmark, how programmatic/LLM-judge/human scorers combine, how a CI regression gate blocks regressions, how production monitoring catches drift, how failures feed back as fixtures — and why an unvalidated LLM judge silently corrupts every metric — through an interactive diagram.

EvalsLLMObservability
AI System Design

Design a Model Registry (MLOps)

Build the platform that versions, evaluates, promotes and can instantly roll back trained ML models — the governance layer between "a model finished training" and "a model is safely serving production traffic." See why an artifact alone is meaningless without lineage, staged promotion through gated environments, automated evaluation gates that fail closed, shadow/canary deployment because offline metrics aren't sufficient, instant rollback via immutable versioning, and production drift monitoring.

LLMEvals
AI System Design

Design a Data Labeling Platform

Build a human annotation platform like Scale AI or Labelbox — sourcing labels from people, not generating them programmatically. See why a single annotator's answer can't be trusted as ground truth, multi-annotator consensus, secretly-mixed gold-standard items that measure labeler accuracy in real time, skill-based task routing, active learning to prioritize which unlabeled examples matter most, and aligning labeler pay with measured quality.

EvalsRetrieval
AI System Design

Design a Prompt Management & A/B Testing Platform

Build the platform that versions, evaluates, and safely A/B tests prompts in a production LLM application — a much faster-moving artifact than model weights, often edited by non-engineers. See why hardcoded prompts force a full deploy for every tweak, externalizing prompts as versioned config, an offline eval gate before rollout, live A/B testing, guardrail metrics that must not regress, routine one-click rollback, and a review gate suited to non-engineer editors.

LLMEvals
AI System Design

Design an AI Ad Creative Platform

Build a platform that generates ad creative at scale for advertisers, built on top of generative models rather than serving them directly. See why one hand-designed creative can't be tested at scale, programmatic variant generation, a brand-safety and ad-policy compliance gate that fails closed, rights and licensing tracking, dynamic multi-armed-bandit budget allocation, a performance feedback loop, and tiered generation cost control.

DiffusionEvals
AI System Design

Design a Support Resolution Agent

Build an AI agent that triages, resolves, and escalates customer support tickets end-to-end. See why answering from general knowledge alone is dangerous when the real answer depends on account-specific state, grounding responses in real account/order data, confidence-based escalation instead of guessing, tiered auto/assisted/escalate resolution, seamless handoff context, outcome-based quality tracking, tone-aware de-escalation, and identity verification against social engineering.

AgentsEvals
AI System Design

Design a CI Test-Generation Agent

Build an agent that automatically generates tests for new and changed code in a CI pipeline. See why manual tests leave coverage gaps, coverage-gap analysis, generating tests against the real code, mutation testing to verify a test is actually meaningful, flaky-test detection before it poisons CI signal, why a human review gate is still required, and running expensive validation in a background lane.

AgentsEvals
AI System Design

Design Jev

Design a decision layer around a model like Jev, a model that never writes — 60 tokens at 20 ms is 1.2 seconds and $30,000 a day for a million tickets, against one pass at 0.1 seconds and $400. See why the input is a typed question sheet, why every answer comes out of one pass, what a calibrated probability is and how a squared penalty trains it, why a refund bar of 96% follows from a $50 mistake and a $2 review, how a cascade cuts the bill to $3,400, why state is fetched in code, and why a weekly audit of 200 labelled tickets catches a confident answer on changed traffic.

LLMAgentsEvals
AI System Design

Design Cursor

Design an AI code editor like Cursor around the edit problem — retyping 4,000 tokens to change 30 is 80 seconds. See why a planner and an apply model are split, why the apply step rewrites the whole file instead of writing a diff (six line numbers at 2% is 11.4% wrong), how speculative edits use the old file as the draft for 110 passes and 2.2 seconds, how a Merkle tree re-embeds 60 chunks instead of 50,000, why Tab breaks even at exactly 25%, how checkpoints make an agent loop undoable, and why a hash check catches a right-looking edit made against a file that has moved.

LLMAgentsEvals

Coding Challenges 1

Labs 1

Interactive Tools 2

About AI evaluation

Shipping an AI feature is easy; knowing whether it's actually good is the hard part — and the part that separates demos from production. Unlike normal code, LLM output has no compiler and no exact-match "correct", so you need a real measurement discipline: golden datasets, scoring methods, and gates that catch a regression before your users do.

This topic covers the vocabulary and the machinery — offline vs online evals, LLM-as-a-judge and its biases, concrete metrics like token-level F1, and evaluating multi-step agents rather than single calls. The recurring lesson: a metric you haven't validated against human judgement can silently mislead you, so you calibrate the judge before you trust the number.

More in AI Engineering

← Browse all topics