evals-design

Evals design

Prompt engineering without evaluation is guessing. Evals are how you know if a prompt change made the output better, worse, or different-but-neither.

The core idea

An eval is a fixed set of (input, expected_output_or_grader) pairs that you run every prompt/model version against. You compare aggregate scores across versions.

prompt_v2 scores 0.87 on the eval set vs prompt_v1 at 0.81 → ship v2
prompt_v3 scores 0.79 → don't ship v3

Without this, you're going on vibes.

Three types of graders

1. Exact match / structured

For tasks with a right answer: classification, extraction, routing.

• Input: "I can't log in, password reset isn't working"
• Expected: {"category": "auth", "severity": "medium"}
• Grader: exact match on the JSON.

Fast, cheap, deterministic. Use wherever possible.

2. Rule-based / programmatic

For tasks with constraints that are testable programmatically.

• Length constraint: "summary ≤ 200 words"
• Format constraint: "output is valid JSON"
• Content constraint: "output contains one of these keywords"
• Safety: "output does not contain PII"

Fast, cheap, composable with exact match.

3. LLM-as-judge

For tasks where "correctness" is subjective: summaries, explanations, creative output, rewrites.

A second LLM call evaluates the output against a rubric:

You are grading a summary. Given the original text and the summary,
rate 1-5 on:
- Faithfulness: does it accurately reflect the original?
- Completeness: does it cover the key points?
- Concision: is it free of filler?
Output JSON: {"faithfulness": N, "completeness": N, "concision": N}

Caveats:

• LLM graders are biased. They prefer verbose output, their own outputs, and outputs that match their training distribution.
• Use a different model for grading than for generating when possible.
• Validate the grader against human labels on a subset. If the grader doesn't correlate with human judgment, it's useless.
• Grading is non-deterministic. Run multiple samples.