LLMOps & AI Platform Engineering · Module 11 of 16

Evaluation & Quality Gates

A model can be healthy, fast and cheap while still giving worse answers. Evaluation creates repeatable evidence about task success, safety and regressions before a change reaches everyone.

Engineering focus: Evaluation pipelines, regression gates and release evidence

In plain English

What problem are we solving?

A model can be healthy, fast and cheap while still giving worse answers. Evaluation creates repeatable evidence about task success, safety and regressions before a change reaches everyone.

Do not memorize product names first. Build the mental model, watch the system move, then map tools onto it.

Animated mental model

Watch an AI change move from test cases to a release decision

A release is promoted only after task, safety and operational evidence are compared with explicit thresholds.

Speed

● Loading interaction engine…

● PAUSEDIdentify the candidate

01Candidatemodel / prompt / RAGNOW

02Eval setrepresentative casesNOW

03Scorersdeterministic + judgedNOW

04Quality gatehard thresholdsNOW

05Canarylimited real trafficNOW

06Promote / rollbackevidence decisionNOW

STEP 1/6Identify the candidate

Evaluation starts with an exact version of the model, prompt, retrieval and application behavior you may release.

release=prompt-v18

Learning objectives

By the end of this module, you should be able to:

Distinguish offline evaluation from production telemetry.
Build representative scenario sets and deterministic checks before using model judges.
Define hard release gates for safety/correctness and trade-off budgets for latency/cost.
Explain why evaluation datasets, prompts, models and scoring logic must be versioned together.

🎓 Learning Coach follows this block when it is centered in your browser

Evaluation answers a different question from observability

Observability tells you what the system did in production: latency, errors, queueing and traces. Evaluation asks whether the output is acceptable for the intended task.

You need both. A release can be operationally healthy yet semantically worse, or semantically strong but too slow or expensive for its service objective.

Operational evidence: latency, errors, saturation, cost.
Quality evidence: task success, groundedness, policy compliance, completeness.
Join both to model/prompt/retrieval/application version.

Common beginner misconception

Green infrastructure dashboards are not proof of answer quality.

🎓 Learning Coach follows this block when it is centered in your browser

Representative scenarios matter more than a large random prompt pile

An evaluation set should represent the work users actually care about, including normal cases, edge cases, unsafe requests and known past failures.

Keep a small deterministic core for fast regression checks and a broader scenario set for deeper release testing. Protect the test set from accidental tuning leakage.

Include critical user journeys and known incident regressions.
Label expected properties, not only one exact wording.
Keep holdout cases for honest release comparisons.
Track dataset version and ownership.

Common beginner misconception

Thousands of easy cases can make a score look excellent while missing one critical failure mode.

🎓 Learning Coach follows this block when it is centered in your browser

Prefer deterministic checks where possible; calibrate model judges where necessary

Some properties can be checked deterministically: valid JSON, required citations, forbidden tool calls, exact calculations or policy decisions. More subjective qualities may need human review or an LLM-as-judge.

A model judge is itself a model with biases and failure modes. Compare it against human-labelled examples and monitor disagreement before trusting it as a release gate.

Deterministic checks first for objective properties.
Rubric-based human review for ambiguous/high-risk cases.
Model judge for scale, calibrated against labelled examples.
Record judge model/version and rubric.

Common beginner misconception

LLM-as-judge is not ground truth merely because it produces a numeric score.

🎓 Learning Coach follows this block when it is centered in your browser

A release gate makes acceptance criteria explicit before the result is known

Define thresholds before looking at the candidate to reduce motivated reasoning. Some constraints are hard gates, while others allow bounded trade-offs.

Use canary or staged rollout after offline evaluation because real traffic can reveal distribution shifts that test sets missed. Keep rollback criteria explicit.

Hard gates: safety/policy, critical task correctness.
Budgets: latency, cost, error rate.
Canary: limited exposure with monitored exit criteria.
Rollback: known previous version and decision trigger.

Common beginner misconception

“The demo looked better” is not a release gate.

Interactive simulator

Release gate simulator

Change candidate quality, safety, latency and cost to see why one impressive metric cannot justify promotion.

TEACHING MODEL

● Loading simulator engine…

taskScore94%safetyScore99%latency2.2 scost100%

Task gate ≥90%—

Safety gate ≥98%—

Latency budget ≤3s—

Cost budget ≤150%—

Release decision—

This simulator teaches relationships and diagnostic reasoning. Its synthetic values are not vendor benchmarks, hardware-sizing evidence or production SLO measurements.

Worked examples

A candidate that should not promote

baseline task=0.90 safety=0.99 p95=2.0s cost=1.0x
candidate task=0.94 safety=0.93 p95=1.8s cost=0.9x

Gate: safety >= 0.98
Decision: HOLD

The candidate improved several metrics.
One hard safety regression is enough to stop promotion.

Version the evidence

release_id=prompt-v17
dataset=refund-eval-v6
judge=review-model-v3
rubric=refund-rubric-v4
result=PASS

A score without versions is difficult to reproduce.
Evidence should be attributable to the exact candidate and evaluation configuration.

Try it · core lab · account-free

Build a deterministic release gate

Goal: Compare baseline and candidate evidence and refuse promotion when a hard requirement regresses.

Before you start

Python 3 only. All scores are deterministic teaching data.

STEP 1

Evaluate the good candidate

python3 public/labs/llmops/11_evaluation_quality_gate.py --candidate good

STEP 2

Evaluate the unsafe candidate

python3 public/labs/llmops/11_evaluation_quality_gate.py --candidate unsafe

STEP 3

Evaluate the slow candidate

python3 public/labs/llmops/11_evaluation_quality_gate.py --candidate slow

STEP 4

Inspect the gate reasons

Identify which constraints are hard gates and which are bounded trade-offs.

Download this Python lab Download all current labs

Verify

Good candidate reports decision=PROMOTE.
Unsafe candidate reports decision=HOLD and safety_gate=FAIL.
Slow candidate reports decision=HOLD and latency_gate=FAIL.

Expected outcome

You can explain why one aggregate quality score is insufficient.
You can write a release decision from explicit evidence.

Break / fix · diagnose

If every candidate promotes, inspect hard-gate comparisons.
If small improvements override safety failure, separate hard constraints from weighted scores.

Production view

Production AI release pipelines should persist evaluation evidence and prevent deployment when critical quality or policy gates fail.

Production Engineer checklist

Before you call this concept production-ready:

Evaluation dataset is representative, versioned and owned. Hard quality/safety gates are defined before candidate results are reviewed. Deterministic checks are used for objective requirements. Model judges are calibrated and versioned where used. Operational SLO/cost budgets are included in release evidence. Canary and rollback criteria are documented and tested.

This checklist is a study aid, not a proficiency score. Your evidence record remains based on tracked learning activity and later formal assessment.

Avoid these traps

Common mistakes

Using only one aggregate score.
Tuning repeatedly against the same test set until it stops being independent evidence.
Treating model-judge output as unquestionable truth.
Running evaluation without versioning the dataset, rubric and candidate.

Knowledge check

Reason about the system, not just the vocabulary.

Answer before opening each explanation. Opening all four answers records knowledge-check activity in My Learning.

1Why can an AI release be operationally healthy but still bad?

Latency and error metrics can be normal while semantic task quality, groundedness or safety regresses.

2What belongs in a representative evaluation set?

Critical user journeys, edge cases, unsafe requests and known past failure/regression cases.

3Why calibrate an LLM judge against human-labelled examples?

The judge can be biased or inconsistent; calibration shows whether its scores track the intended rubric.

4What is the purpose of a canary after offline evaluation passes?

Expose the change to limited real traffic to catch distribution or operational effects that offline tests missed.

My Learning

Record your progress for this module.

Progress is saved in this browser immediately. When you sign in to My Learning, it can also sync across devices.

Not started

Core lab attemptedRecord this after meaningfully completing or attempting the module's core lab.Knowledge checks attemptedThis is marked automatically after you open every answer in the module; you can also record it manually.

Attempt the core lab and knowledge checks before marking the module complete.