How do you evaluate an LLM prompt?

Collect a set of representative inputs with known-good expectations, then define automatic pass/fail checks — is-valid-json, schema-match, contains, regex, length — and run them every time you change the prompt or the model. For qualities that aren't machine-checkable, use a rubric or an LLM-as-judge on a sample, but anchor everything to the deterministic checks first.

What is LLM-as-judge?

LLM-as-judge uses a second model to grade another model's output against a rubric — useful for subjective qualities like helpfulness or tone that regex can't capture. It's convenient but noisier and biased, so use it as a supplement to deterministic checks, on a sample, with a clear rubric, not as your only signal.

Evaluating prompts

6 min read · Updated 2026-08-10

“It looks better” is not an evaluation. Without a repeatable way to score outputs, every prompt tweak is a gamble, and a fix for one case silently breaks another. Evals turn prompt engineering into engineering.

1. Build a test set

Start small and real. Gather 10–50 representative inputs — including the awkward ones: empty input, very long input, ambiguous cases, and adversarial input. For each, record what a good output looks like (or the property it must satisfy). This set is your regression suite; grow it every time you find a failure in production.

2. Prefer machine-checkable checks

Deterministic checks are cheap, fast, and unambiguous. Lean on them:

is-valid-json — the output parses.
schema-match — it matches your output contract.
contains / not-contains — a required phrase is present, a forbidden one absent.
regex — it matches a pattern (a date, an id, a format).
length — within bounds.
equals / one-of — for classification, the label is correct.

Convert fuzzy goals into concrete proxies where you can: “is it concise?” → length <= 40 words; “does it give steps?” → regex for a numbered list of 3–5 items.

You can generate a starter rubric for any prompt with the free Eval Rubric Generator.

3. Use LLM-as-judge sparingly

Some qualities — helpfulness, tone, faithfulness — resist regex. For those, a second model can grade outputs against a rubric (“Rate 1–5 whether the answer is supported by the sources”). It’s useful but noisy and biased, so:

Give the judge a specific rubric, not “is this good?”
Run it on a sample, not everything.
Anchor to deterministic checks first; use the judge as a supplement.
Watch for known biases (length, position, self-preference).

4. Score, don’t eyeball

Run the whole set and report pass rates per check, not a gut feeling. A prompt that goes from 82% → 91% on your schema check is progress you can defend; “seems better” is not.

5. Run evals on every change — prompt and model

The two things that silently change output quality are a prompt edit and a model change (including a provider updating a model behind the same name, or deprecating it). Re-run your evals on both. A prompt tuned on one model can score very differently on another — which is exactly why you test across the models you target rather than assume portability. See Model-agnostic prompts.

6. Close the loop

When something slips through to production, add it to the test set. Over time your suite becomes a precise map of what your prompt must handle, and regressions get caught before customers see them.

Checklist

A test set of real inputs, including edge and adversarial cases.
Deterministic pass/fail checks for format and content.
LLM-as-judge only where needed, with a rubric and on a sample.
Pass rates reported per check, not judged by eye.
Evals re-run on every prompt and model change.
Production failures fed back into the test set.

Ship these practices, don't just read them

VernaOne turns prompts into versioned, model-agnostic endpoints with structured output, evals, and automatic fallback — so the best practices here become defaults, not discipline.

Try VernaOne free →