A reliable LLM evaluation process turns vague impressions such as “the prompt seems better” into repeatable evidence. This checklist shows how to build a test set, define expected behavior, score prompt quality, estimate operational cost, and detect regressions before they reach users.
Overview
Prompt testing is more than checking whether a few sample answers look good. A prompt can produce polished output while still failing on factuality, format compliance, edge cases, latency, or cost. An effective LLM evaluation combines several measures so that improvements in one area do not hide damage in another.
Use this LLM evaluation checklist whenever you change a system prompt, model, retrieval configuration, temperature setting, output schema, or surrounding workflow. The process is especially useful for production features such as classification, extraction, summarization, customer support, and content automation with AI.
A practical evaluation has five layers:
- Task success: Did the response complete the requested job?
- Instruction following: Did it obey required constraints, such as tone, length, language, and output format?
- Factuality and grounding: Are claims supported by the supplied context or source material?
- Operational performance: How much time, token volume, and money did the request require?
- Robustness: Does the prompt behave acceptably on ambiguous, incomplete, adversarial, and unusual inputs?
Keep a separate record for each prompt version. The guide to prompt versioning best practices can help teams connect evaluation results to specific changes.
How to estimate prompt quality
Start with a representative evaluation dataset rather than a handful of convenient examples. Each test case should include the input, relevant context, expected behavior, and any acceptable variations. For structured tasks, include a reference output or validation rule. For creative tasks, define a rubric instead of requiring exact wording.
A simple quality estimate can use weighted component scores:
Overall score = (task success × weight) + (instruction following × weight) + (factuality × weight) + (format compliance × weight) − penalty points
Score each component on a consistent scale, such as 0 to 1 or 0 to 100. Set the weights according to the risk of the use case. For example, a data extraction workflow may give format compliance and field accuracy more weight than style. A user-facing assistant may place more emphasis on helpfulness, groundedness, and refusal behavior.
Do not rely on one aggregate number. Record the component scores and the failure count as well. A prompt with an acceptable average can still be unsuitable if it fails one high-risk category, such as exposing unsupported claims or returning invalid JSON.
For each test case, capture:
- The prompt and model configuration used.
- The raw output, including errors or truncated responses.
- Automated checks, such as schema validation, exact-match fields, or citation presence.
- Human or reviewer judgments where automated scoring is insufficient.
- Latency, input and output token counts, and estimated request cost.
Evaluation datasets deserve their own design process. See How to Write Better Evaluation Datasets for Prompt Testing for guidance on coverage, labels, and difficult examples.
Inputs and assumptions
Before calculating results, define the inputs that can change the conclusion. Treat them as assumptions, not permanent facts.
Dataset inputs
- Test count: The number of cases in the evaluation run.
- Category mix: The proportion of normal, ambiguous, incomplete, and edge-case requests.
- Reference standard: Exact answers, approved answer ranges, labels, schemas, or reviewer rubrics.
- Pass threshold: The minimum score required for release.
Quality inputs
- Accuracy rate: The percentage of cases judged correct.
- Format validity: The percentage of outputs that pass structural checks.
- Grounding rate: The share of factual claims supported by the provided context, where applicable.
- Critical failure count: Failures that should block deployment regardless of the average score.
Operational inputs
- Requests per period: Use an observed or deliberately conservative estimate.
- Average input and output size: Measure both separately because prompts and responses may have different pricing or performance effects.
- Retry rate: Include automatic retries, repair calls, and fallback model calls.
- Current pricing assumptions: Enter the applicable provider and model rates at the time of calculation rather than copying old values.
A basic monthly usage estimate is:
Total tokens = requests × (average input tokens + average output tokens) × (1 + retry rate)
If input and output rates differ, calculate them separately. The same approach applies to latency: record the median and a high percentile or worst acceptable range instead of relying only on the average. A prompt that is inexpensive but frequently times out may not be operationally successful.
Worked examples
Example 1: Comparing two prompt versions
Assume a team tests two versions on 100 fictional support-ticket cases. Version A passes 86 cases for task success, 92 for format compliance, and 88 for groundedness. Version B passes 90, 96, and 84 respectively.
If the team assigns weights of 50% to task success, 20% to format compliance, and 30% to groundedness, the illustrative scores are:
- Version A: 0.86 × 0.50 + 0.92 × 0.20 + 0.88 × 0.30 = 0.876, or 87.6%.
- Version B: 0.90 × 0.50 + 0.96 × 0.20 + 0.84 × 0.30 = 0.888, or 88.8%.
Version B has the higher weighted score, but the lower groundedness rate deserves review. If unsupported answers are a critical risk, the team may reject B despite its better aggregate result. This is why a release decision should include category thresholds and critical-failure rules.
Example 2: Estimating usage and cost
Assume a workflow handles 10,000 requests per month. Each request averages 700 input tokens and 300 output tokens, and 5% of requests trigger a retry. The estimated token volume is:
10,000 × (700 + 300) × 1.05 = 10,500,000 total tokens
To estimate cost, multiply the input and output token totals by the applicable rates from the selected provider, then add any retry or fallback usage. Do not present the result as a fixed budget: model pricing, traffic, prompt length, and retry behavior can change. Recalculate using measured production data after launch.
Example 3: Testing a RAG workflow
For a retrieval-augmented generation workflow, evaluate retrieval and generation separately. Mark whether the correct source was retrieved, whether the answer stayed within that source, and whether the response correctly acknowledged missing information. The RAG Workflow Guide provides a useful structure for reviewing retrieval, prompt design, and evaluation together.
When to recalculate
Run prompt regression testing whenever a change could affect output behavior. At minimum, rerun the evaluation after modifying the system prompt, few-shot examples, model, model parameters, retrieval settings, tool definitions, output schema, or post-processing code.
Recalculate operational estimates when request volume, average context length, output length, retry rate, provider pricing, or fallback behavior changes. A small prompt edit can increase every request's token count, so track input and output sizes over time rather than checking them only during development.
Use a practical release routine:
- Freeze the current prompt and configuration as a baseline.
- Run the same dataset against the candidate version.
- Compare overall scores, category scores, critical failures, latency, and token usage.
- Inspect every newly failed case and a sample of apparent improvements.
- Record the decision, assumptions, and follow-up work.
Review the dataset itself periodically. Real user inputs may reveal categories that were missing from the original test set. Add representative failures, label them consistently, and retain a stable regression set so improvements remain comparable. For content teams, evaluation can be paired with AI SEO prompts for planning and refreshing articles; for automation workflows, use the guidance in Content Automation with AI to identify where human review remains appropriate.
The most useful LLM evaluation checklist is a living record: clear inputs, explicit assumptions, measurable outcomes, and a repeatable decision rule. Keep it close to your prompt code, update it when the workflow changes, and use it to optimize prompts without losing sight of reliability or operating cost.
