Guide: Evaluation Frameworks

What this guide covers

This guide collects the evaluation tools and frameworks introduced across Weeks 7-8 into a single reference. Use it when designing evaluations for your final project or any professional AI workflow.

The five evaluation targets

Before evaluating, know what you’re evaluating. These are different tasks with different methods.

Building a rubric

A rubric makes evaluation systematic, defensible, and repeatable. Every rubric has dimensions, scales, and anchors.

Step 1: Choose dimensions

Select 4-6 from this menu based on your specific task:

Step 2: Define the scale

Use a 0-4 scale:

Step 3: Write anchors for your specific task

What is an anchor?

An anchor is the concrete description of what a specific score level looks like for a given dimension. It ties the abstract number to something observable so that two different raters reading the same output would arrive at a similar score.

Without anchors, “accuracy = 3” is subjective - one rater’s 3 is another’s 2. With anchors, both raters share a reference point that describes what they’d actually see in the output at that level. A common mistake is writing anchors that just restate the dimension name with an adjective:

These don’t help, as they describe how the rater feels about accuracy, not what they’d observe. You also don’t need to anchor all five levels. Define what 0, 2, and 4 look like for your specific task, with scores of 1 and 3 fall naturally between them. A good anchor describes the output itself:

Example for a customer feedback summary task:

A good thing to ask yourself: could two people who’ve never spoken to each other read these anchors and score the same output within 1 point of each other? If yes, the anchors are doing their job. If not, they need to be more specific.

Rubric template

Task: [describe the task]
Audience: [who will use the output]
Risk level: [low / medium / high]

| Dimension | 0 (unacceptable) | 2 (adequate) | 4 (excellent) | Score | Justification |
|-----------|-------------------|--------------|----------------|-------|---------------|
| [dim 1]   | [anchor]          | [anchor]     | [anchor]       |       |               |
| [dim 2]   | [anchor]          | [anchor]     | [anchor]       |       |               |
| [dim 3]   | [anchor]          | [anchor]     | [anchor]       |       |               |
| [dim 4]   | [anchor]          | [anchor]     | [anchor]       |       |               |

Total: __ / [max]
Recommendation: acceptable / acceptable with revision / unacceptable

Agreement metrics

Cohen’s kappa (κ)

Measures agreement between two raters, correcting for chance. Use when two people (or a person and an LLM) score the same outputs.

from sklearn.metrics import cohen_kappa_score

kappa = cohen_kappa_score(rater_1_labels, rater_2_labels)

Interpretation:

For most analytic tasks, aim for κ > 0.6 (substantial agreement) before trusting automated labels.

Precision, recall, and F1

Use when evaluating classification accuracy against ground truth.

from sklearn.metrics import classification_report

print(classification_report(true_labels, predicted_labels))

Subgroup analysis: Always compute precision/recall by subgroup, not just overall. A classifier with 90% overall accuracy might have 60% accuracy for a specific category.

from sklearn.metrics import precision_recall_fscore_support

p, r, f1, support = precision_recall_fscore_support(y_true, y_pred, labels=labels)

Test case design

The three test case types

Every evaluation should include at least one of each:

Typical case - a straightforward, representative input. This tests the happy path. If the system fails here, it’s not ready.

Edge case - an unusual, ambiguous, or boundary input. Tests whether the system handles uncertainty gracefully rather than guessing confidently.

Adversarial case - an input designed to make the system fail. Tests robustness and whether the system knows what it doesn’t know.

Test case template

Name: [descriptive name]
Type: typical / edge / adversarial
Input: [the specific input to send]
Expected behavior: [what a good response looks like]
Failure mode: [what a bad response looks like]
Evaluation: [how you'll score it]
Pass criteria: [what counts as acceptable]

Example test cases for a customer feedback classifier

Evaluation approaches compared

When to trust LLM-as-judge

Trust it for: format compliance, basic factual checks, consistency across outputs, preliminary scoring before human review.

Don’t trust it alone for: high-stakes decisions, fairness assessments, domain-specific accuracy, anything where being wrong causes real harm (what might this look like?).

Always validate: run LLM-as-judge on your human-scored test set first and compute κ. If agreement is below 0.6, the LLM judge isn’t reliable enough for your task.

The eval pipeline pattern

Adapted from Anthropic’s Building with the Claude API course.

Professional AI evaluation is organized as a pipeline, not a one-time scoring session:

1. Cases - a stored set of inputs with expected behavior (your test cases: typical, edge, adversarial)
2. Run - execute every case programmatically against the model or workflow
3. Grade - score each output using the cheapest reliable grader: code graders for anything rule-checkable (format, allowed values), model graders (LLM-as-judge) for quality dimensions, humans for a validation sample
4. Aggregate - pass rates, mean rubric scores, agreement metrics (κ), and a decision

The pipeline mindset changes two things. First, evaluation becomes repeatable. When you change a prompt or model, you re-run the same cases and compare. Second, it becomes affordable. Code graders are free, so you reserve expensive human judgment for what actually needs it. Your Week 7 kappa and MDD work answers the pipeline’s most important question e.g., can the grader itself be trusted?

Putting it all together

For your final project evaluation:

1. Design the rubric - 4-6 dimensions with task-specific anchors
2. Write test cases - at least 1 typical, 1 edge, 1 adversarial
3. Score with the rubric - human scores with justifications
4. Compute agreement - if you have a second rater or LLM-as-judge, compute κ
5. Analyze subgroups - check whether performance varies by input type, category, or group
6. Make a recommendation - acceptable, acceptable with revision, or unacceptable, with evidence
7. Document everything - rubric, scores, test cases, and agreement metrics in your AI use log