Measuring quality that is not captured by test code
This article summarizes the basic concepts of LLM Evals and how to apply them in practice.
General backend testing is relatively clear. If the input is the same, the output should be the same, and the DB state should change as expected. But LLM services are different. Even the same question may be worded slightly differently, the answer may be plausible but wrong, and the quality of a particular case may decrease even if the prompt is only slightly changed.
That's why LLM services require a separate evaluation system.
Analysis date: 2026-05-12 Practice standard environment: OpenAI Evals concept, Python, pytest, JSONL dataset Main reference materials: OpenAI Evals Docs, OpenAI Evaluation Best Practices
Key takeaways
- Evals are structured tests that measure whether LLM output meets expected standards.
- Golden Set is a representative question dataset for regression testing.
- LLM quality evaluation should be divided into correctness, groundedness, citation accuracy, and safety.
- Prompt changes and model changes are dangerous if deployed without eval results.
- Evals are a complement to test code, not a replacement.
1. Why does LLM require a separate assessment?
Quality issues in LLM services are not well captured by general testing.
| problem | general test | Eval |
|---|---|---|
| JSON schema error | good noise | Assistable |
| Answer Factuality | I didn't catch it well | necessary |
| Source Accuracy | limited | necessary |
| answer tone | limited | possible |
| Prompt change regression | I didn't catch it well | very important |
| Model change impact | I didn't catch it well | very important |
That is, the test code checks whether the system is broken, and eval checks whether the answer is usable.
2. Difference between Unit Test and Eval
| division | Unit Test | Eval |
|---|---|---|
| Target | code logic | Model output quality |
| result | deterministic | probabilistic |
| standard | expected value | rubric, grader, human label |
| When to run | CI | CI + Before deployment + Periodically |
| failure meaning | Possibility of code errors | Possible decline in quality |
You need both. Schema validation is considered unit/integration test, and answer quality is considered eval.
3. Creating a Golden Set
The Golden Set is a dataset that collects representative questions and expected standards.
// This is an example JSON structure.{ "id": "rag_001", "question": "When to use the Redis Cache Aside pattern?", "expected_facts": [ "Check the cache first", "In case of a miss, the original data storage is searched.", "Store search results in cache with TTL" ], "must_cite": true, "category": "cache"}
A good golden set should contain a variety of failure types.
# This is an example.[ ] Easy questions[ ] Ambiguous question[ ] Questions not in the document[ ] Questions that require up-to-dateness[ ] Questions requiring permission[ ] Citation is an important question[ ] Questions that require a safety policy
4. Define evaluation criteria
Evaluation criteria should not be lumped together.
| standard | question |
|---|---|
| Correctness | Is the answer factually correct? |
| Groundedness | Was it based on the documentary evidence provided? |
| Citation Accuracy | Is the citation connected to actual evidence? |
| Completeness | Did I leave out any necessary information? |
| Safety | Did you avoid dangerous or prohibited content? |
| Format | Did you follow the requested schema/format? |
5. Grader design
Grader can be human, rule-based, or LLM-as-a-Judge.
| Grader type | merit | disadvantage |
|---|---|---|
| Exact match | fast and clear | Weak in expression diversity |
| Rule-based | stable | Complex quality judgment difficult |
| Human review | High reliability | Cost is large |
| LLM-as-a-Judge | Good scalability | judge bias and instability |
It is safer to start with rule-based + human review initially and then use an LLM judge as an assistant.
6. Divide RAG evaluation
RAGs should be evaluated separately for retrieval and generation.
# This is an example.Retrieval Eval:Is the correct answer document in top-k? Generation Eval:Did you give the correct answer based on the retrieved document?
example:
| characteristic | explanation |
|---|---|
recall@k | Proportion of correct answer documents included in top-k |
precision@k | Percentage of relevant documents among search results |
answer_correctness | The truth of the answer |
citation_accuracy | Source Accuracy |
groundedness | evidence-based |
7. Connect to Release Gate
Eval should be a standard for distribution, not just a report that you read and end.
# This is an example.Prompt v3 deployment terms:- overall pass rate >= 90%- critical set pass rate >= 98%- citation accuracy >= 95%- regression count <= 3
Compare before and after changing prompts or models.
# This is an example.baseline: prompt.v2 + model.Acandidate: prompt.v3 + model.Acandidate: prompt.v2 + model.B
8. Operational indicators and dashboard
| characteristic | meaning |
|---|---|
eval_pass_rate | overall pass rate |
eval_regression_count | Number of cases worse than before |
eval_category_pass_rate | Quality by Category |
citation_accuracy | Source Accuracy |
human_review_required_rate | Percentage of human review required |
This metric is used to determine deployment, improve quality, and record prompt changes.
9. Practical checklist
# This is an example.[ ] Representative question Is there a golden set?[ ] Are search evaluation and answer evaluation separate?[ ] Did you distinguish between correctness and groundedness?[ ] Do you evaluate citation accuracy?[ ] Compare eval before and after changing the prompt?[ ] Are critical cases managed separately?[ ] Are eval failure cases reflected in the next improvement?[ ] Is the eval result connected to the release gate?
10. Q&A
Q1. How often should I run Eval?
It is recommended to run this whenever the prompt, model, or retrieval logic changes. During operation, drift can be checked through periodic sampling.
Q2. Can I Trust LLM-as-a-Judge?
It's useful as an aid, but dangerous if you trust it completely. Critical cases should be combined with human review or rule-based checks.
Q3. How many Golden Sets should I start with?
At first, 30 to 50 is enough. The important thing is to include a variety of failure types rather than numbers.
11. References and uncertainty
References
- OpenAI Evals:https://platform.openai.com/docs/guides/evals
- OpenAI Evaluation Best Practices:https://platform.openai.com/docs/guides/evaluation-best-practices
- OpenAI Cookbook — Evals:https://developers.openai.com/cookbook/topic/evals
uncertainty
- Eval criteria must be tailored to the service domain.
- LLM-as-a-Judge results may vary depending on the judge model, rubric, and temperature.
Practical example: starting small with a golden set
There is no need to create hundreds of assessment questions from scratch. You might start with about 20 questions that come up frequently in operations, 10 questions that would be a big problem if they fail, and 10 questions that the new feature is intended for. The important thing is to write down the question, the basis for expectations, the range of acceptable responses, and the failure conditions.
| item | yes |
|---|---|
| question | “How long is my data retained after I delete my account?” |
| basis of expectation | Privacy Policy section id |
| passing criteria | Mention both storage period and exception conditions |
| failure criteria | Assume that deletion is complete immediately. |
A failure case is using only the LLM-as-a-Judge score as the release gate. The grader is also a model, so standards can be shaky. Important policy, legal, and payment responses should incorporate rule-based checks or human review samples. Eval is not a tool that automatically guarantees the correct answer, but rather a measurement device that allows you to compare changes in quality before and after deployment using the same criteria.
Even if it is a small golden set, a version must be added. It is impossible to interpret changes in scores without knowing whether the questions changed, the expectations changed, or the grader prompt changed. It is safer to set aside “questions that must never be failed” rather than average scores at the distribution gate.

댓글
GitHub 계정으로 로그인하면 댓글을 남길 수 있습니다. 댓글은 GitHub Discussions를 통해 운영됩니다.