A reliable LLM evaluation process turns prompt engineering from guesswork into a repeatable decision. This checklist shows how to build a representative test set, score prompt quality, estimate operational cost, compare versions, and know when an evaluation needs to be updated.
Overview
A prompt can produce an impressive answer in a single demonstration and still be unsuitable for production. Prompt testing should therefore examine a set of realistic inputs rather than relying on a few successful examples. The goal is not to find one universal score. It is to understand whether a prompt and model combination meets the requirements of a particular workflow.
An effective LLM evaluation checklist covers six dimensions:
- Accuracy: Does the response contain the correct information or classification?
- Relevance: Does it address the task without unnecessary material?
- Consistency: Does it behave predictably across similar inputs and repeated runs?
- Safety and policy fit: Does it avoid unacceptable disclosures, unsupported claims, or disallowed outputs?
- Latency: Does the workflow respond quickly enough for its intended use?
- Cost: Does the expected usage fit the available budget?
These dimensions should be evaluated together. A prompt that improves accuracy but doubles response length may increase cost and latency. A concise prompt that is inexpensive may still fail if it omits required fields. For broader implementation guidance, compare this checklist with the practical LLM prompt testing framework.
How to estimate
Start by defining the decision the evaluation must support. For example, you might need to choose between two prompts, decide whether a model is ready for a workflow, or determine whether a change is safe to release. The decision determines which measurements matter most.
1. Build a test set
Create examples that reflect actual use, including ordinary cases, ambiguous requests, incomplete inputs, boundary conditions, and known failure cases. Each record should include:
- the input or conversation context;
- the expected answer, label, structure, or required behavior;
- the dimensions to score;
- any information that must not appear in the response; and
- a source or reviewer note when the expected result is not self-evident.
Keep a stable core set for regression testing and a smaller rotating set for newly observed cases. Separating these sets helps you detect both long-term regressions and emerging weaknesses.
2. Choose a scoring method
Use a simple scale that reviewers can apply consistently. A four-point rubric is often practical:
- 0: failed, unsafe, or unusable;
- 1: partially useful but requires substantial correction;
- 2: acceptable with minor correction;
- 3: meets the requirement without meaningful correction.
For binary requirements, such as valid JSON or the presence of a mandatory field, use pass or fail instead. Do not average away a critical failure. A workflow can have a high overall score and still be unsuitable if it regularly exposes confidential information or returns invalid structured output.
3. Apply weights and thresholds
Assign each dimension a weight based on the workflow. A customer-facing answer may prioritize accuracy and safety, while a batch classification task may prioritize consistency and cost. Calculate a weighted score with:
Weighted score = sum of (dimension score × dimension weight) ÷ maximum possible weighted score.
Set minimum thresholds before comparing prompts. For example, require every candidate to pass all safety checks, then compare accuracy, latency, and cost among the candidates that qualify. This prevents a low cost from compensating for a non-negotiable failure.
4. Estimate cost and operational impact
Use the pricing and usage assumptions available for the model or provider at the time of evaluation. A general estimate is:
Estimated run cost = number of test cases × runs per case × (input units × input rate + output units × output rate).
Keep input and output units separate because prompts, retrieved context, conversation history, and generated answers can contribute differently to usage. Add expected retries, failed calls, or multi-step prompt chains when they are part of the workflow. Record the assumptions beside the result rather than presenting the estimate as a permanent figure.
For production planning, estimate monthly usage separately: expected requests, average input size, average output size, retry rate, and any additional calls made by tools or retrieval steps. This is more useful than extrapolating from a single unusually short or long test.
Inputs and assumptions
Evaluation results are only as meaningful as the inputs behind them. Document the following for every comparison:
- Prompt version: Store the system instructions, user template, examples, tool definitions, and formatting rules.
- Model configuration: Record the model identifier and relevant generation settings. If a setting is not controlled, state that clearly.
- Context: Note whether the test uses retrieved documents, conversation history, metadata, or external tools.
- Test-set composition: Record the number and type of cases, including the proportion of edge cases.
- Reviewer method: Identify whether scoring was automated, human-reviewed, or based on a combination.
- Cost assumptions: Capture input and output quantities, expected retries, and the rates used for the estimate.
Automated checks work well for exact matches, required fields, schema validity, citation presence, length limits, and prohibited strings. Human review remains useful for nuanced relevance, tone, reasoning quality, and factual adequacy. An evaluator model can help with scale, but its rubric should be tested against human judgments and monitored for systematic blind spots.
Use a fixed evaluation record such as: case_id, prompt_version, model, input, output, expected_result, accuracy_score, relevance_score, safety_result, latency, input_units, output_units, reviewer_note, and timestamp. This structure makes regression tracking easier and supports later investigation.
Worked examples
Comparing two extraction prompts
Suppose a team is evaluating two prompts that extract product attributes from support messages. The test set contains 100 messages: 70 ordinary requests, 20 ambiguous messages, and 10 messages with missing information. Each prompt is run once on the same cases.
The team scores exact field accuracy, schema validity, relevance, and latency. Prompt A extracts more fields correctly but occasionally invents a value when information is missing. Prompt B extracts slightly fewer fields but consistently returns an explicit unknown value and always produces valid JSON.
If fabricated values are unacceptable, the decision should not be based on the average score alone. Make hallucinated attributes a blocking failure or assign them a severe penalty. Prompt B may be the better production choice even if Prompt A has a higher raw extraction score. This illustrates why evaluation criteria must reflect operational risk, not just apparent completeness.
Estimating a prompt-chain change
Now consider a workflow that summarizes a document, extracts action items, and formats the result. Version 1 uses two model calls; Version 2 adds a verification call. To compare them, measure total calls per request, input and output units for each call, end-to-end latency, formatting pass rate, and reviewer-approved accuracy.
Calculate the expected cost per request for each version using the current provider rates and the recorded unit averages. Then multiply by the expected monthly request volume. If Version 2 reduces manual correction enough to justify its additional call, the higher model spend may be reasonable. If its accuracy improvement is marginal and latency violates the workflow requirement, the added step may not be worthwhile. Recalculate this comparison when usage volume or provider pricing changes.
When to recalculate
Re-run the evaluation whenever an input that can change the decision changes. This includes a prompt edit, model change, generation-setting change, retrieval source change, tool or schema change, or new safety requirement. Also revisit the test set after production reveals a new failure pattern. A regression suite that never changes can give a misleading sense of stability.
Recalculate cost when provider pricing, tokenization behavior, average context size, output length, request volume, retry rates, or prompt-chain structure changes. Recheck latency after infrastructure changes or when additional retrieval and tool calls are introduced. Do not overwrite old results: retain the prompt version, assumptions, date, and decision so that performance can be compared over time.
For a practical maintenance routine, review the stable regression set before every release, sample new production cases on a regular schedule, and perform a deeper rubric review when the workflow’s purpose changes. Keep thresholds visible to reviewers and developers. If a candidate fails a critical criterion, record the failure and its disposition rather than hiding it in an aggregate score.
The most useful LLM evaluation checklist is therefore a living record: a defined test set, explicit scoring rules, documented cost inputs, and a clear release decision. Start small, make the assumptions visible, and expand coverage whenever real usage exposes a gap. That process creates a more dependable foundation for prompt optimization than repeated trial and error.
