Begin with the central question
When accuracy says 99%, could the model still be nearly useless?
This question explains why Evaluation Metrics deserves its own lesson. Each definition, calculation, and code example below will answer a specific part of it.
predictions + ground truth → confusion counts or errors → task-appropriate metricsBefore you continue: three tools for this module
- Ground truth: the trusted answer used for comparison.
- False positive: predicted positive when the answer was negative.
- False negative: predicted negative when the answer was positive.
You do not need to memorize these yet. Return to this small map whenever a term reappears.
What You Will Understand
- Classification Metrics: Master confusion matrices, accuracy, precision, recall, F1-score, ROC curves, and AUC values for balanced and imbalanced sets.
- Regression Metrics: Understand how to evaluate regression models using Mean Absolute Error, Mean Squared Error, Root Mean Squared Error, and R² scores.
- System-Level Evaluation: Map these classical metrics to evaluate retrieval quality (RAG recall/precision) and LLM-as-judge scoring systems.
The useful metric depends on the cost of each mistake:
actual outcome + predicted outcome
↓ count error types
accuracy / precision / recall / F1 / ROC-AUC
↓ apply business cost and threshold needs
choose the metric that represents successA metric is not automatically an objective truth. Accuracy can hide failure on a rare class, and averaging can hide poor performance for one user group.
Why “How Good Is It?” Needs More Than One Number
Module 13 covered loss functions — what a model optimizes during training. Evaluation metrics are different: they’re how you (and stakeholders) judge a model’s real-world quality after training, in terms that are meaningful to humans, not just mathematically convenient for gradient descent.
A model can have excellent loss values and still be practically useless if you’re measuring the wrong thing — evaluation metrics exist to measure the right thing for your actual problem.
The Medical Test That Is Accurate but Useless
Imagine a medical test for a rare disease that simply always says “you don’t have it,” for every single patient. If only 1 in 1,000 people actually have the disease, this test is “99.9% accurate” — and yet it is completely useless, since it never actually identifies anyone who’s genuinely sick.
This is the single most important intuition in this entire module: accuracy alone can be a deeply misleading number, especially when classes are imbalanced.
4. Core Concept — Classification Metrics
The confusion matrix — the foundation everything else builds on
Predicted: Positive Predicted: Negative
Actual: Positive True Positive (TP) False Negative (FN)
Actual: Negative False Positive (FP) True Negative (TN)| Term | Meaning |
|---|---|
| True Positive (TP) | Model correctly predicted positive |
| True Negative (TN) | Model correctly predicted negative |
| False Positive (FP) | Model incorrectly predicted positive (“false alarm”) |
| False Negative (FN) | Model incorrectly predicted negative (“missed it”) |
The core metrics, defined precisely
Accuracy = (TP + TN) / (TP + TN + FP + FN)
"What fraction of ALL predictions were correct?"
Precision = TP / (TP + FP)
"Of everything the model FLAGGED as positive,
how much was actually positive?"
Recall = TP / (TP + FN)
"Of everything that was ACTUALLY positive,
how much did the model successfully catch?"
F1 Score = 2 × (Precision × Recall) / (Precision + Recall)
"A single number balancing precision and recall"
Specificity = TN / (TN + FP)
"Of everything actually NEGATIVE, how much did
the model correctly identify as negative?"🧠 Precision vs. recall, intuitively: precision asks “when the model says yes, can I trust it?” — recall asks “does the model catch everything it should?” These two often trade off against each other — you can usually increase one at the cost of the other, by adjusting the decision threshold (Module 8).
5. How It Works — Step by Step
1. Get the model's predictions on a held-out test set
2. Compare predictions to true labels, tallying TP, TN, FP, FN
into a confusion matrix
3. Compute accuracy, precision, recall, F1 from these counts
4. Consider WHICH metric matters most for your specific problem
(Section 9 makes this concrete)
5. For threshold-based classifiers: consider ROC/AUC to evaluate
performance ACROSS all possible thresholds, not just oneROC and AUC
ROC curve: plots True Positive Rate (recall) against
False Positive Rate, across every possible
decision threshold from 0 to 1
AUC: "Area Under the (ROC) Curve" — a single number
summarizing overall performance across all
thresholds (1.0 = perfect, 0.5 = no better
than random guessing)🧠 Intuition: Instead of judging a classifier at just one fixed threshold (like 0.5), ROC/AUC evaluates how well it separates classes regardless of where you eventually set the threshold — useful when you haven’t yet decided on the “right” operating point, or want to compare models independent of that choice.
Precision-Recall curve
Similar idea to ROC, but plots precision against recall across thresholds — generally more informative than ROC/AUC specifically for imbalanced datasets, where ROC/AUC can look misleadingly good even for a genuinely poor classifier (because it includes True Negative Rate in its calculation, which stays easy/high when negatives vastly outnumber positives).
6. Mathematical Intuition — Regression Metrics
Read the mathematics as a story
predictions + ground truth → confusion counts or errors → task-appropriate metricsFirst identify the input, the operation, and the output. Then read the symbols as a shorter way to describe that same journey; do not begin by memorizing the formula.
MAE = average of |prediction - true_label|
(Module 13 — average absolute error, in the original units)
MSE = average of (prediction - true_label)²
(Module 13 — penalizes large errors more heavily)
RMSE = sqrt(MSE)
("Root Mean Squared Error" — brings the units back to the
original scale, unlike raw MSE, which is in squared units)
R² = 1 - (sum of squared errors / total variance in the true labels)
(proportion of variance explained by the model, 0 to 1,
higher is better — introduced already in Module 7)🧠 Why RMSE is often reported instead of raw MSE: if you’re predicting house prices in dollars, MSE’s units are “dollars squared” — genuinely hard to interpret intuitively. RMSE takes the square root, bringing the error metric back into interpretable dollar units, while still retaining MSE’s “large errors penalized more” character.
7. Small Worked Example — Why 99% Accuracy Can Be Terrible
Walk through the example
- Identify what each input number represents.
- Follow one operation at a time and keep the units or class meanings attached.
- Translate the result back into an ordinary sentence about the original problem.
The goal is not merely to obtain the answer; it is to expose the model’s decision process.
A fraud detection dataset: 9,900 legitimate transactions, 100 fraudulent ones (1% fraud rate — realistically imbalanced).
A “model” that always predicts “not fraud”, no matter the input:
TP = 0 (never correctly identifies fraud)
TN = 9,900 (correctly identifies every legitimate transaction)
FP = 0
FN = 100 (misses EVERY SINGLE fraud case)
Accuracy = (0 + 9,900) / 10,000 = 0.99 → 99% accuracy!
Precision = 0 / (0 + 0) → undefined (never predicts positive at all)
Recall = 0 / (0 + 100) = 0.0 → 0% recall — catches ZERO fraudThis model is 99% accurate and completely useless for its actual purpose. This single example is precisely why accuracy alone is insufficient for imbalanced classification problems, and why precision and recall exist.
8. Python Example
What the code will demonstrate
The following Evaluation Metrics code turns the worked example into an experiment you can repeat. First predict the result; then prepare the small dataset, apply the technique, inspect the important intermediate values, and compare the actual output with your prediction.
Python and library symbols used below
- NumPy (
np) stores and calculates with numeric arrays. - pandas (
pd) represents table-shaped data when it is used. - scikit-learn provides tested implementations with a consistent
.fit(...)and.predict(...)workflow.
# Build a small, inspectable example of Evaluation Metrics.
# Follow the data, learned values, predictions, and evaluation in order.
import numpy as np
from sklearn.metrics import (
accuracy_score, precision_score, recall_score, f1_score,
confusion_matrix, classification_report, roc_auc_score
)
from sklearn.linear_model import LogisticRegression
from sklearn.datasets import make_classification
from sklearn.model_selection import train_test_split
# Simulate an imbalanced fraud-like dataset
X, y = make_classification(
n_samples=2000, n_features=10, weights=[0.95, 0.05], random_state=42
)
X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.3, random_state=42, stratify=y)
model = LogisticRegression()
model.fit(X_train, y_train)
predictions = model.predict(X_test)
probabilities = model.predict_proba(X_test)[:, 1]
print("Accuracy:", accuracy_score(y_test, predictions))
print("Precision:", precision_score(y_test, predictions))
print("Recall:", recall_score(y_test, predictions))
print("F1 Score:", f1_score(y_test, predictions))
print("AUC:", roc_auc_score(y_test, probabilities))
print("\nConfusion Matrix:\n", confusion_matrix(y_test, predictions))
print("\nFull report:\n", classification_report(y_test, predictions))
# Compare against a "dummy" model that always predicts the majority class
dummy_predictions = np.zeros_like(y_test)
print("\n--- Dummy model (always predicts majority class) ---")
print("Dummy Accuracy:", accuracy_score(y_test, dummy_predictions))
print("Dummy Recall:", recall_score(y_test, dummy_predictions, zero_division=0))Expected Output (approximate — exact numbers vary by environment):
Accuracy: 0.9367
Precision: 0.7333
Recall: 0.3667
F1 Score: 0.4889
AUC: 0.9016
Confusion Matrix:
[[561 4]
[ 19 16]]
Full report:
precision recall f1-score support
0 0.97 0.99 0.98 565
1 0.73 0.37 0.49 35
accuracy 0.94 600
--- Dummy model (always predicts majority class) ---
Dummy Accuracy: 0.9417
Dummy Recall: 0.0How It Works
- Notice the dummy model (always predicts “not fraud”) achieves higher accuracy (94.2%) than the real logistic regression model (93.7%) — a stark, concrete demonstration of Section 7’s point: accuracy alone doesn’t reveal that the dummy model has zero recall, catching literally none of the fraud cases, while the real model at least catches some (37% recall).
- The confusion matrix shows exactly where errors occur: 19 false negatives (missed fraud) versus only 4 false positives — the model is currently more likely to miss fraud than to falsely flag legitimate transactions, a genuine, actionable insight accuracy alone would never reveal.
9. Real-World Example
Two different applications choosing different metrics to optimize for:
- Spam email detection: false positives (legitimate email marked as spam) are often considered worse than false negatives (a spam email slipping into the inbox) — a missed spam email is a minor annoyance, but a legitimate email wrongly filtered out could mean missing something important. This system would likely prioritize precision.
- Cancer screening: false negatives (missing an actual cancer case) are far more costly than false positives (an unnecessary follow-up test for someone who doesn’t actually have cancer). This system would likely prioritize recall, even at the cost of more false alarms.
This is exactly why “which metric matters most” is a business/domain decision, not a purely technical one — the same underlying confusion matrix numbers can lead to very different conclusions about whether a model is “good enough,” depending entirely on the real-world cost of each error type.
10. How This Is Used in AI
From mechanism to product
AI systems need metrics tied to consequences. LLM and agent evaluation adds dimensions such as factuality, relevance, tool success, safety, latency, and cost.
How this connects to LLMs
request → data or context preparation → model computation → evaluated outputAn LLM may use this idea during training, or an AI application may use a separate ML component around the LLM. Those are different locations in the system, and the explanation below identifies which one applies.
🤖 How Is This Used in AI?
Direct relevance to Agentic AI: Very High.
| Evaluation concept | AI Equivalent |
|---|---|
| Precision/Recall for classifiers | Evaluating content moderation, spam/toxicity filters, routing classifiers |
| Precision/Recall for retrieval | RAG retrieval evaluation: precision = “of retrieved documents, how many are actually relevant?”; recall = “of all relevant documents, how many did retrieval actually find?” |
| F1 | A common single-number summary for both classification AND retrieval quality |
| Confusion matrix | Understanding an AI safety classifier’s specific error patterns (over-flagging vs. under-flagging) |
🧠 Why traditional ML metrics are not always sufficient for LLM applications: precision/recall/F1 work well when there’s a clear, objective “correct answer” to compare against (a document either is or isn’t relevant; a transaction either is or isn’t fraud).
Evaluating an LLM’s generated response quality, however, is often far more subjective — “is this a good summary?” doesn’t reduce neatly to a true/false comparison. This is why LLM evaluation increasingly relies on additional approaches beyond classic ML metrics:
- LLM-as-judge — using another (often more capable) LLM to score response quality against a rubric.
- Human evaluation — direct human ratings, especially for subjective quality dimensions.
- Task-specific metrics — e.g., exact-match or F1-over-tokens for question-answering, code-execution success rate for coding tasks.
- Traditional metrics still apply at the component level — e.g., evaluating a RAG system’s retrieval step with precision/recall, even if the final generated answer needs a different, more nuanced evaluation approach.
RAG system evaluation, layered:
Retrieval component: precision/recall/F1 (classic ML metrics,
genuinely well-suited here — "relevant"
vs. "not relevant" is a clear binary judgment)
↓
Generation component: LLM-as-judge, human eval, or task-specific
metrics (classic precision/recall usually
doesn't map cleanly onto "is this a good
natural-language answer?")11. How This Is Used in Agentic AI
Trace one agent step
goal + state → model proposes → runtime validates → tool or response → evaluationThe model produces a prediction or proposal. The agent runtime is ordinary software that manages tools, permissions, state, retries, and execution; it may use this ML concept directly, indirectly through an LLM, or not at all.
🤖 Evaluating an agent’s tool-selection accuracy (“did the agent pick the right tool for this request?”) is a genuinely classic classification evaluation problem — precision, recall, and confusion matrices apply directly and usefully.
Evaluating whether an agent’s overall task completion was successful is often closer to the harder, more subjective LLM-response-quality problem described above — frequently requiring task-specific success criteria (did the agent actually accomplish the concrete goal?) combined with human or LLM-based judgment, rather than a single traditional ML metric.
12. Common Beginner Mistakes
⚠️ Mistake
Incorrect idea: Reporting accuracy alone on an imbalanced dataset
Why it is incorrect: As Section 7 demonstrates concretely, this can make a completely useless model look excellent — always check precision and recall (and the confusion matrix directly) for imbalanced classification problems.
⚠️ Mistake
Incorrect idea: Optimizing F1 blindly without considering whether precision or recall actually matters more for the specific business problem
Why it is incorrect: F1 assumes precision and recall are equally important — often not true in practice (recall Section 9’s spam vs. cancer-screening examples).
⚠️ Mistake
Incorrect idea: Using ROC/AUC as the primary metric on a heavily imbalanced dataset
Why it is incorrect: As Section 5 notes, ROC/AUC can look misleadingly good on imbalanced data because it incorporates the (often very high, easy-to-achieve) true negative rate — a precision-recall curve is typically more informative in genuinely imbalanced settings.
13. Important Distinctions
| Precision | Recall |
|---|---|
| “Of what I flagged as positive, how much was correct?” | “Of everything actually positive, how much did I catch?” |
| Punished by false positives | Punished by false negatives |
| Prioritize when false positives are costly (e.g., spam filtering) | Prioritize when false negatives are costly (e.g., disease screening) |
| Accuracy | F1 Score |
|---|---|
| Can be misleading on imbalanced data | Balances precision and recall, more robust for imbalanced data |
| Simple, intuitive, but easily gamed by a naive “always predict majority class” model | A single number, but still needs context (does the problem genuinely need precision/recall balanced equally?) |
| MSE | RMSE |
|---|---|
| In squared units — hard to interpret directly | In original units — directly interpretable |
| More sensitive to large errors | Same sensitivity, more human-readable scale |
14. When Should You Use This?
- Always look beyond accuracy for imbalanced classification problems — check precision, recall, and the confusion matrix directly.
- Precision-focused: when false positives carry a high real-world cost.
- Recall-focused: when false negatives carry a high real-world cost.
- F1: as a reasonable single-number summary when precision and recall matter roughly equally, or for quick model comparison during development.
- ROC/AUC: for comparing classifiers across all possible thresholds, particularly on reasonably balanced datasets.
- Precision-recall curve: specifically for imbalanced datasets, where it’s typically more informative than ROC/AUC.
- RMSE over raw MSE: whenever you want an error metric in human-interpretable original units.
15. When Should You NOT Use This?
- Don’t rely on accuracy as your primary or only metric for any meaningfully imbalanced classification problem.
- Don’t apply classic precision/recall-style evaluation directly to open-ended, subjective LLM-generated text without adaptation — as Section 10 explains, this usually needs LLM-as-judge, human evaluation, or task-specific success criteria instead.
- Don’t default to F1 without considering whether the underlying business problem genuinely values precision and recall equally — a blind F1 optimization can produce a model poorly suited to the real-world cost structure of its errors.
16. Production Considerations
- Monitor the metric that actually matters for the business, not just whichever is easiest to compute — this should be an explicit, documented decision, not a default.
- Track metrics over time in production, not just at initial evaluation — data drift (Module 21) can shift precision/recall balance even for a model that was well-tuned at launch.
- Report confusion matrices, not just summary numbers, to stakeholders when possible — the specific pattern of errors (which class gets confused with which) is often more actionable than a single aggregate score.
- For LLM/agent systems, invest in building a genuine evaluation pipeline (potentially combining classic metrics for structured sub-components with LLM-as-judge or human evaluation for generated output) rather than relying on any single number to certify quality.
17. AI Engineer Takeaway
🎯 AI Engineer Takeaway: Accuracy alone is often the wrong metric — precision and recall exist specifically because different kinds of errors carry different real-world costs, and choosing which to prioritize is a genuine business decision baked directly into your evaluation strategy.
These classic metrics remain directly and usefully applicable to structured components of AI systems (classifiers, retrieval), but genuinely open-ended generated text (LLM responses, agent outputs) typically needs additional evaluation approaches — LLM-as-judge, human evaluation, or task-specific success criteria — layered on top of, not as a replacement for, the fundamentals covered in this module.
18. Interview Questions
Basic Questions
Q: What is the difference between precision and recall?
A: Precision measures, of everything the model predicted as positive, how much was actually positive — it’s punished by false positives. Recall measures, of everything that was actually positive, how much the model successfully identified — it’s punished by false negatives. They often trade off against each other, and which one matters more depends on the real-world cost of each type of error for the specific problem.
Q: Why can accuracy be a misleading metric?
A: On imbalanced datasets, a model can achieve very high accuracy simply by always (or almost always) predicting the majority class, while being completely useless at identifying the minority class — which is often the class that actually matters most (like fraud or disease detection). A 99% accurate model that never correctly identifies a single true positive case provides essentially no real value, despite the impressive- sounding accuracy number.
Intermediate Questions
Q: When would you prioritize precision over recall, and vice versa? Give a concrete example of each.
A: Prioritize precision when false positives are more costly than false negatives — for example, spam email filtering, where incorrectly flagging a legitimate email as spam (a false positive) can mean the user misses something important, which is often considered worse than an occasional spam email slipping through. Prioritize recall when false negatives are more costly — for example, cancer screening, where missing an actual cancer case (a false negative) has far more severe consequences than an unnecessary follow-up test triggered by a false positive.
Q: Why is the precision-recall curve often preferred over ROC/AUC for evaluating classifiers on imbalanced datasets?
A: ROC/AUC incorporates the true negative rate in its calculation, which tends to stay high (and therefore look impressive) whenever negative examples vastly outnumber positive ones — this can make a genuinely poor classifier’s ROC/AUC score look misleadingly good on imbalanced data. The precision-recall curve focuses specifically on how well the model identifies and correctly flags the positive class, which is usually the class of actual interest in imbalanced problems (like fraud or disease detection), making it a more informative and honest evaluation choice in that setting.
Scenario-Based Questions
Q: You built a fraud detection model with 99% accuracy, but the business says the model is useless. What could be wrong?
A: Thought process: This is precisely the canonical scenario this module’s core lesson is built around — high accuracy on an imbalanced problem is the first, most likely explanation to investigate.
Investigation: Check the actual class balance of the dataset — if fraud is rare (e.g., 1% of transactions), a 99% accurate model could simply be a “naive” model that predicts “not fraud” for almost everything, achieving high accuracy purely by exploiting the class imbalance while providing zero actual fraud-detection value. Directly check precision and recall, and the confusion matrix specifically — this will immediately reveal whether the model is actually catching any real fraud cases (recall) and whether its fraud flags can be trusted (precision).
Correct answer: The most likely explanation is that accuracy is masking a severe imbalanced-data problem — the model may have very low recall (missing most actual fraud) despite its high accuracy. The fix is not necessarily a different model, but a different evaluation approach: report precision, recall, F1, and the confusion matrix to the business instead of (or alongside) accuracy, and explicitly discuss which error type (missed fraud vs. false fraud alerts) matters more for the actual business, then tune the model/threshold accordingly.
Production consideration: This scenario is a strong argument for establishing the right evaluation metric before building the model, in direct conversation with business stakeholders about the real-world cost of each error type — rather than discovering after deployment that the metric used during development didn’t actually reflect what the business cared about.
Next: Module 18 — Embeddings and Representation Learning — the bridge module connecting classical ML directly to LLMs, RAG, and semantic search.
- Author
- TechByteByByte Editorial Team
- Reviewed by
- TechByteByByte Admin
- Published
- Last reviewed