Prompt Evaluation: How to Measure and Score Prompt Quality

"It looks better to me" is not an engineering claim. Prompt evaluation is how you tell whether a change actually improved things, kept them the same, or quietly broke them. The teams that ship reliable AI are the teams that built an evaluation habit early.

1. Introduction

Prompts are easy to write and surprisingly hard to measure. The same prompt can look perfect on the three examples you tried by hand and fail systematically on a fourth case you never thought of. Worse, the failure can be slow — a prompt that worked great in March quietly degrades by July because the kind of inputs users send has shifted. Without measurement, you discover the regression from a customer complaint.

This tutorial covers the four building blocks of prompt evaluation: the eval set, the metric, the scoring method, and the cadence at which you re-run everything. None of these are exotic. The bar for "good enough" is much lower than people expect — but having something is dramatically better than having nothing.

2. The Concept Explained

An evaluation is just running your prompt against a known set of inputs and scoring the outputs. The three big design choices are what to measure, who measures it, and what counts as good.

The four pillars

• Eval set. 30–200 representative inputs, ideally drawn from real production traffic. Each input is paired with the "right" answer or with the criteria for a right answer.
• Metric. Exact match for classification, ROUGE/BLEU for text similarity, schema-validity for structured outputs, rubric scores for open-ended work.
• Scorer. Either deterministic code (when the right answer is checkable), human graders (slow and expensive but the gold standard), or LLM-as-judge (cheap, fast, surprisingly reliable when prompted well).
• Cadence. Run on every prompt change, on every model upgrade, and on a calendar (weekly or monthly) to catch drift.

3. The Problem Without Evaluation

Without evaluation, every prompt change is an act of faith. You make a tweak that feels better on three examples, ship it, and either (a) something quietly regresses for a different class of input that you don't currently look at, or (b) it really did improve things, but you cannot prove it and the next reviewer rolls it back.

// Engineer in chat:
// "I changed the prompt to add 'be concise'. Looks better
//  in the three tickets I tried. Shipping it."

4. The Solution: A Lightweight Eval Harness

You are grading a customer-support assistant's replies.
For each (ticket, reply) pair, score on three axes:

1. Correctness (1-5)
   5 = facts and policy match the ticket exactly.
   1 = the reply contradicts the ticket or invents policy.

2. Completeness (1-5)
   5 = every customer question is addressed.
   1 = key questions are ignored.

3. Tone (1-5)
   5 = warm, professional, empathetic.
   1 = curt, dismissive, robotic.

Return JSON: {
  "correctness": int, "completeness": int, "tone": int,
  "reasoning": "one short paragraph"
}

Ticket: """{{ticket}}"""
Reply:  """{{reply}}"""

5. Step-by-Step Breakdown

1. Build the eval set from real traffic. Sample 30–200 inputs you actually saw in production. Add a handful of "evil" inputs: malformed, multilingual, ambiguous. The richer the set, the more it catches.
2. Define the metric per task. Classification → accuracy. Extraction → field-level precision and recall. Open-ended writing → rubric scores. Many tasks need 2–3 metrics in combination.
3. Pick a scorer per metric. Use deterministic code wherever possible — it is free and exactly repeatable. Use LLM-as-judge for the parts code cannot grade. Reserve humans for the highest-stakes outputs and as a periodic sanity check on your LLM judge.
4. Calibrate the LLM judge. Grade 50 outputs by hand. Then run the LLM judge on the same outputs. Adjust the judge's prompt until its scores agree with yours roughly 80% of the time. A miscalibrated judge is worse than no judge.
5. Track multiple axes. A prompt that improves accuracy but doubles latency and triples token cost is not actually better. Always look at accuracy, validity, latency, and cost together.
6. Run on every change. Wire evaluation into your prompt-library workflow. No prompt change ships without a green eval run.
7. Re-run on a calendar. Model providers update underlying models. Customer inputs evolve. Quarterly re-evaluation catches drift before users do.

Tip: Keep the eval set small enough that you actually run it. A 50-input set that runs every PR beats a 5,000-input set that runs once a quarter. You can always grow the set later; you cannot retro-actively add the months of discipline you skipped.

6. Practice Exercises

7. Key Takeaways