[LLM] LLM Evaluation A to Z — “평가 그거 현업이 다 하나요?” Dataset부터 LLM-as-a-Judge까지

LLM 서비스를 만들다 보면 결국 이 질문을 만난다.

THE EVAL QUESTION

“그래서 이 버전이
진짜 더 좋아진 거 맞아?”

Prompt를 바꿨다. 모델을 바꿨다. RAG chunking을 바꿨다. reranker도 붙였다.

샘플 몇 개를 직접 물어보니 좋아 보인다.

그런데 Production으로 올려도 될까?

여기서 많은 팀이 갑자기 Excel을 연다.

질문 1 → 정답 O
질문 2 → 애매
질문 3 → 정답 O
...

Accuracy = 82%

그런데 이 82%는 생각보다 별 의미가 없을 수도 있다.

• 평가셋이 실제 사용자 질문을 대표하는가?
• 쉬운 질문만 몰려 있지 않은가?
• 정답 기준은 누가 만들었는가?
• RAG가 못 찾은 건지 LLM이 못 답한 건지 구분되는가?
• 82%와 85%의 차이가 진짜 개선인가, 표본 잡음인가?
• LLM Judge가 90점을 줬는데 그 Judge를 믿어도 되는가?

MY TAKE

LLM 평가는 모델을 채점하는 일이 아니라,
“우리 시스템에서 좋은 결과가 무엇인지”를 운영 가능한 형태로 정의하는 일에 가깝다.

짧은 의견 · “현업이 이걸 다 평가하나요?”

아니요. 다 하게 만들면
Eval System이 아니라 집단 과제가 됩니다.

현업은 답변 500개를 하나씩 채점하는 사람이 아니라, “우리 업무에서 무엇이 정답이고, 무엇이 위험한 오답인지” 기준을 세우는 사람에 더 가깝습니다.

AI/개발팀이 dataset 후보를 만들고, evidence와 draft answer를 준비하고, deterministic grader와 LLM Judge로 반복 평가를 자동화합니다. 현업은 Gold Set 검증, 애매한 case, 고위험 case, Judge disagreement에 집중하는 구조가 현실적입니다.

현업은 시험지를 매번 채점하는 사람이 아니라,
채점 기준을 만드는 사람에 가깝다.

01. 제일 먼저: Model Eval과 System Eval을 구분해야 한다

실제 서비스에서 사용자는 LLM weight만 경험하지 않는다.

User Input
↓
Prompt / Router
↓
Retrieval / Tools
↓
Model
↓
Guardrail / Formatter
↓
Final Response

모델이 좋아도 retrieval이 틀리면 답은 틀린다. 모델이 조금 약해도 좋은 context가 들어가면 정답을 낼 수 있다.

그래서 Production에서는 Application / System Eval이 중심이 되어야 한다.

Layer	대표 평가 질문
Model	Reasoning / instruction following / language quality가 좋은가?
Retrieval	필요한 evidence를 Top-K 안에 가져왔는가?
Generation	context를 근거로 정확하고 완전하게 답했는가?
Agent	올바른 tool과 경로를 선택해 task를 끝냈는가?
Business	실제로 업무시간 / 오류 / escalation을 줄였는가?

2026년 OpenAI도 frontier model 평가에서 이제 단순 chatbot response뿐 아니라 도구, 환경, workflow setup까지 평가 대상으로 봐야 한다고 강조한다.

02. Eval의 시작은 Metric이 아니라 “Good”의 정의다

LLM 평가에서 가장 먼저 할 일은 Judge를 고르는 게 아니다.

“좋은 답변”을 분해해야 한다.

예: 사내 정책 RAG

Correctness — 결론이 맞는가?
Groundedness — 근거 문서에서 나온 주장인가?
Completeness — 필요한 조건/예외를 빠뜨리지 않았는가?
Citation — 올바른 출처를 인용했는가?
Relevance — 질문에 직접 답했는가?
Safety — 허용되지 않은 조언을 하지 않았는가?
Format — 요구된 형식을 지켰는가?

이걸 하나의 “Quality 1~5” 점수로 뭉개면 나중에 성능이 왜 떨어졌는지 알 수 없다.

하나의 Overall Score보다
분해 가능한 Rubric이 더 유용하다.

03. 평가 방법은 크게 네 종류면 거의 정리된다

01 · DETERMINISTIC

Code-based grader

Exact match · Regex · JSON schema · Unit test · SQL execution · Citation ID validation

02 · HUMAN

SME / Annotator

Domain correctness · nuanced quality · ambiguous policy interpretation

03 · MODEL-BASED

LLM-as-a-Judge

Correctness · completeness · groundedness · conversation quality

04 · BUSINESS / OUTCOME

Real-world KPI

Resolution rate · Human escalation · Conversion · Cost · Latency · Error rate

최신 평가 시스템은 이 중 하나를 선택하는 게 아니라 여러 grader를 조합하는 쪽으로 간다.

OpenAI의 현재 grader API도 string check, similarity, model grader, Python grader와 이들을 결합한 multi-grader를 지원한다.

04. Eval Dataset은 “질문 100개”가 아니다

좋은 eval dataset에는 최소한 아래가 있어야 한다.

json · eval item

{
  "id": "policy_042",
  "input": "해외 입원도 보장되나요?",
  "reference_answer": "...",
  "evidence": [
    {"document_id": "terms_v4", "clause": "12-3"}
  ],
  "rubric": {
    "correctness": "...",
    "must_include": ["해외 의료기관 조건"],
    "must_not_claim": ["무조건 보장"]
  },
  "metadata": {
    "category": "coverage",
    "difficulty": "hard",
    "risk": "high",
    "source": "production_trace"
  }
}

특히 metadata가 중요하다.

전체 평균 하나만 보는 게 아니라 업무 유형, 난이도, risk, source별 slice를 봐야 하기 때문이다.

05. 평가 데이터는 어디서 가져올까?

좋은 순서는 보통 이렇다.

1. 실제 업무 / Production Trace

가장 가치가 높다. 실제 distribution을 반영한다.

2. 현업이 자주 받는 대표 질문

FAQ가 아니라 실제 업무 난이도를 포함.

3. 과거 Failure / Incident

한 번 발견된 버그는 regression test로 영구 편입.

4. Edge / Adversarial Case

빈도는 낮지만 실패 비용이 큰 경우.

5. Synthetic Case

coverage를 채우는 보조 수단. 현실 데이터의 대체재는 아니다.

2025년 OpenAI GDPval도 academic-style question 대신 실제 전문가 업무 산출물을 기반으로 real-world task를 설계하는 방향을 택했다.

06. 현업에게 500개 다 봐달라고 할 수 없다 — 그래서 Dataset을 계층화한다

실제 조직에서는 이 문제가 제일 현실적이다.

Domain SME에게 질문 500개와 정답 500개를 검수해달라고 하면 프로젝트가 평가 단계에서 멈춘다.

실제로 “현업에서 다 봐주시면 됩니다”라는 평가 계획은 평가 설계가 아니라 인력 투입 계획에 가깝다.

그래서 나는 eval dataset을 세 층으로 보는 게 가장 현실적이라고 생각한다.

GOLD · 50–100

SME가 직접 검증한 Core Set

reference · evidence · rubric까지 신뢰할 수 있게 만든다. Release gate와 judge calibration의 기준점.

SILVER · 200–1,000+

실제 Trace + 자동 Label + 부분 검수

LLM Judge / heuristic으로 확장하고, 랜덤·고위험·judge-disagreement sample만 사람이 점검.

ONLINE · CONTINUOUS

Production Sample

정답 reference 없이 anomaly, groundedness, safety, user feedback를 지속 측정.

핵심은 SME의 시간은 “모든 데이터를 채점”하는 데 쓰는 게 아니라 평가 기준을 만드는 데 쓴다는 것이다.

07. 그래서 평가셋은 몇 개면 충분한가?

가장 답하기 어려운 질문이다.

결론부터 말하면 “100개면 충분하다” 같은 절대 숫자는 없다.

표본 수가 의미하는 건 결국 얼마나 큰 오차를 감수하느냐다.

Binary accuracy를 예로 들자. 가장 불확실한 p=0.5 부근에서 95% 신뢰구간의 대략적인 폭은 다음과 같다.

N	95% 오차 범위 worst-case Wilson 근사	해석
25	약 ±18%p	Smoke test
50	약 ±13%p	큰 regression 탐지
100	약 ±9.6%p	방향성 판단
200	약 ±6.9%p	Release 비교가 꽤 안정
400	약 ±4.9%p	KPI 수준 비교
1,000	약 ±3.1%p	세부 lift까지 관측

즉 50개로 80%가 나왔다고 해서 실제 성능이 정확히 80%라는 뜻은 아니다.

중요

50개짜리 평가셋에서 82% → 86%가 됐다고 “4%p 개선”이라고 발표하는 건 대개 너무 자신감이 높은 해석이다.

08. 실무에서는 이렇게 생각하면 편하다

20–50 cases

개발 초반. prompt / architecture가 완전히 망가졌는지 확인하는 smoke set.

50–100 SME-verified cases

Core Gold Set. 평가 기준 정의와 Judge calibration에 현실적인 출발점.

200–500 cases

버전 비교와 regression gate를 정량적으로 운영하기 시작하기 좋은 규모.

1,000+ cases

많은 category / long-tail / 작은 성능 차이를 안정적으로 보고 싶을 때.

LangSmith의 2026 문서도 처음에는 critical component별 5~10개의 좋은 예시, 전체적으로 10~20개의 high-quality example에서 시작하라고 안내한다.

다만 이것은 eval 개발의 시작점이지, 3%p 차이를 증명하는 statistical benchmark라는 뜻은 아니다.

09. 100개의 숫자보다 100개의 구성 방식이 더 중요하다

100개가 모두 쉬운 FAQ면 500개여도 별 도움이 안 된다.

Eval은 stratified dataset이어야 한다.

예: 120-case Enterprise RAG Gold Set

50 · 실제 빈도가 높은 대표 업무
25 · 복합 / multi-condition 질문
15 · 최근 Production failure
10 · 고위험 정책 / 규제 case
10 · ambiguity / insufficient information
10 · adversarial / malformed input

이 숫자 자체가 정답은 아니다.

중요한 건 두 가지 view를 따로 보는 것이다.

TRAFFIC-WEIGHTED

현실 평균 성능

실제 사용 빈도에 비례해 평가

RISK-WEIGHTED

실패 비용

빈도는 낮아도 critical case를 별도 gate

10. 모든 질문에 “정답 문장”이 필요한 건 아니다

자유 생성 task에서는 하나의 canonical answer를 만들기가 어렵다.

그래서 reference를 세 가지로 구분하면 좋다.

Reference Type	언제?
Exact Reference	분류 · 계산 · 코드 · SQL처럼 답이 명확
Evidence Reference	RAG — 어떤 문서/근거를 사용해야 하는지
Rubric Reference	요약 · 상담 · 분석처럼 여러 좋은 답이 가능

특히 real-world knowledge work 평가인 GDPval도 단순 exact answer가 아니라 전문가가 만든 detailed rubric과 pairwise comparison을 사용한다.

11. LLM-as-a-Judge는 이제 기본 도구다 — 하지만 Ground Truth는 아니다

LLM Judge의 장점은 분명하다.

• 수백~수천 개 output을 빠르게 평가할 수 있다.
• 정확성뿐 아니라 completeness, relevance처럼 semantic metric을 다룰 수 있다.
• Production trace의 reference-free 평가에도 사용할 수 있다.

문제는 Judge도 LLM이라는 것.

Position bias, style bias, verbosity preference, language bias가 존재한다.

2026년 pairwise judge 연구에서는 언어별 평가 성능 격차와 영어 답변 선호가 관찰됐고, 다른 2026 연구에서는 style-related bias가 강하게 나타났다.

특히 한국어 서비스라면

영어 benchmark에서 Judge가 잘 맞았다는 사실만으로 한국어 금융/보험 답변 Judge로 바로 신뢰하면 안 된다.

한국어 + 내 도메인 human calibration set이 필요하다.

12. Judge도 평가받아야 한다 — Meta-Evaluation

가장 현실적인 방법은 Gold Set 일부를 사람이 먼저 채점하고 Judge와 비교하는 것이다.

SME Labels
↓
30–50+ calibration examples
↓
LLM Judge
↓
Agreement / F1 / Kappa
↓
Rubric Prompt 수정
↓
Re-test

여기서 단순 accuracy만 보지 않는 게 좋다.

예를 들어 high-risk 오류를 Judge가 계속 PASS로 분류한다면 전체 agreement가 90%여도 쓸 수 없는 Judge다.

OpenAI GDPval의 experimental automated grader도 전문가 grader를 완전히 대체하지 않는다. 공개된 gold subset에서는 automated grader의 human agreement가 약 65.7%, human 간 agreement가 약 70.8%였다.

즉 좋은 자동 grader도 결국 human behavior의 근사치다.

13. 절대점수보다 Pairwise가 유리할 때가 많다

“이 답변은 5점 만점에 몇 점?”보다

A와 B 중 어느 쪽이 더 좋은가?

가 사람에게도, LLM Judge에게도 쉬운 경우가 많다.

특히 prompt/model/RAG version 비교에는 pairwise가 강하다.

Pairwise Judge 체크리스트

✓ Model/version 이름 숨기기
✓ Output 순서 randomize
✓ 가능하면 A-B / B-A swap consistency 확인
✓ Tie 허용
✓ rubric을 명시
✓ 동일 source/context를 Judge에게 제공

LangSmith도 pairwise experiment에서 output order를 randomize하는 옵션을 제공한다.

14. Version A와 B는 “같은 질문”으로 비교해야 한다

이건 생각보다 중요하다.

Bad comparison
A → Dataset Sample A
B → Dataset Sample B

Good comparison
Same input i → Output Aᵢ, Output Bᵢ

같은 evaluation item에서 A/B를 모두 실행하면 난이도 차이가 통제되는 paired experiment가 된다.

따라서 raw average뿐 아니라 각 sample에서 누가 좋아졌는지 볼 수 있다.

A win = 47
Tie = 38
B win = 15

Pairwise win-rate tells a much clearer story

15. 평균만 보지 말고 Confidence Interval을 같이 본다

“Accuracy 84.2%”보다

“84.2%, 95% CI [79.1, 88.4]”가 훨씬 많은 정보를 준다.

A/B 비교도 단순히 B - A = +3.2%p 만 쓰지 않는다.

권장

Binary pass/fail → paired proportion CI + McNemar test
Continuous rubric score → paired bootstrap / permutation test
Pairwise preference → win/tie/loss + bootstrap CI

특히 LLM eval score는 normal distribution을 가정하기 애매한 경우가 많아서 example-level bootstrap이 실용적이다.

16. 작은 개선을 주장하려면 평가셋이 커져야 한다

이것만 기억해도 평가에서 실수를 많이 줄일 수 있다.

Detect하려는 차이가 작을수록
더 많은 Sample이 필요하다.

50% → 80%처럼 엄청난 변화는 30~50개에서도 보일 수 있다.

82% → 84% 같은 차이는 훨씬 큰 dataset 없이는 noise와 구분하기 어렵다.

그래서 “평가셋 몇 개?”라는 질문보다 먼저 “우리는 몇 %p의 성능 차이를 감지하고 싶은가?”를 물어야 한다.

17. Agent는 한 번만 돌려보고 평가하면 안 될 수도 있다

Agent는 같은 task도 실행할 때마다 tool path가 달라질 수 있다.

Anthropic은 2026년 agent eval guidance에서 task와 trial을 구분하고, 필요하면 하나의 task를 여러 번 실행해 성공 확률을 본다.

pass@k

k번 중 한 번이라도 성공할 확률. Coding / search처럼 여러 시도가 허용되는 task.

pass^k

k번 모두 성공할 확률. 고객-facing agent의 일관성을 볼 때 더 엄격한 metric.

예를 들어 per-run 성공률이 75%면 3번 모두 성공할 확률은 약 42%밖에 안 된다.

“한 번 성공했다”와 “항상 믿고 쓸 수 있다”는 다른 품질이다.

18. RAG는 Final Answer만 평가하면 원인을 못 찾는다

RAG에서 답이 틀렸다고 하자.

최소 세 가지 원인이 있다.

1. 정답 evidence가 index에 없음
2. 있었지만 retriever가 못 찾음
3. context에 들어왔지만 generator가 잘못 답함

그래서 RAG는 component-level metric을 분리한다.

Layer	Metric
Retrieval	Recall@K · Precision@K · MRR / nDCG · evidence coverage
Context	Context relevance · noise ratio
Generation	Correctness · faithfulness · completeness
Citation	Citation precision · citation completeness

RAGChecker도 retriever와 generator를 세분화해 failure mode를 진단하는 평가 프레임워크다.

ARES는 synthetic data와 lightweight judge를 활용하면서 사람 annotation을 수백 개 수준으로 줄이는 방향을 보여줬다.

19. Agent Eval은 Output보다 Trajectory를 본다

Agent가 최종 답은 맞았는데 민감한 API를 불필요하게 세 번 호출했다면?

성공이라고 할 수 있을까?

Input
↓
Tool A
↓
Tool B
↓
Retry
↓
Human Escalation
↓
Final Outcome

이 전체 기록이 trajectory / trace다.

Agent Eval

Task success
Tool selection
Tool argument correctness
Policy compliance
Unnecessary steps
Retry count
Human escalation
Latency / Cost
Final response quality

LangSmith의 최신 trajectory evaluator도 reference trajectory match와 LLM-based trajectory judge를 지원한다.

20. Offline Eval만으로는 Production 품질을 알 수 없다

아무리 좋은 test set도 Production distribution 전체를 미리 알 수 없다.

Offline Gold Eval
↓ release
Production
↓
Sample / Trace
↓
Online Evaluator
↓
Failure Mining
↓
New Gold / Regression Cases ↺

Online에서는 정답 reference가 없는 경우가 많다.

대신 다음을 본다.

• Safety / PII / policy violation
• Groundedness / citation availability
• User negative feedback
• Escalation / retry spike
• Latency / token / cost anomaly
• Judge score drift

이게 2026년 eval의 큰 변화 중 하나다. Eval이 pre-release QA에서 continuous monitoring으로 확장되고 있다.

21. 현업 검수는 Random Sampling보다 “똑똑하게” 요청한다

SME에게 시간을 받을 수 있다면 아무 sample이나 뽑아주는 건 아깝다.

사람이 볼 대상을 우선순위화한다.

Human Review Queue 우선순위

1. LLM Judge가 confidence 낮은 case
2. 서로 다른 Judge가 disagreement한 case
3. A/B 결과가 뒤집히는 case
4. high-risk category
5. user negative feedback
6. 새롭게 등장한 query cluster
7. random audit sample

이것은 사실 Active Evaluation에 가깝다.

사람의 한 시간을 이미 쉬운 case 30개 확인하는 데 쓰지 않고, 시스템이 가장 불확실한 곳에 쓴다.

22. 현업끼리 의견이 다르면? 그것도 중요한 Eval 결과다

두 SME가 같은 답변을 보고 한 명은 정답, 한 명은 오답이라고 할 수 있다.

이건 annotation 실패만은 아니다.

업무 기준 자체가 ambiguous하다는 신호일 수 있다.

Human agreement도 측정

Binary / categorical → Cohen's Kappa
여러 annotator → Fleiss' Kappa / Krippendorff's Alpha
Ordinal rubric → Weighted Kappa

Human agreement가 낮으면 LLM Judge prompt를 아무리 튜닝해도 “정답”을 안정적으로 만들기 어렵다.

23. Production Gate는 Overall Score 하나로 만들지 않는다

예를 들어 전체 평균이 92%로 좋아도 개인정보 category가 60%면 출시하면 안 될 수 있다.

Release if:

overall_quality >= baseline - tolerance
AND critical_policy_pass_rate == 100%
AND retrieval_recall@10 >= 95%
AND high_risk_regression == 0
AND latency_p95 <= target
AND cost_per_task <= budget

즉 quality, risk, operation을 동시에 gate해야 한다.

24. Eval Dataset은 한 번 만들고 끝나는 문서가 아니다

시간이 지나면 query distribution이 변한다.

제품 기능도 바뀌고 모델이 너무 많이 최적화되어 eval set 자체를 “외우는” 현상도 생긴다.

Production Failure
↓
Add Regression Case
↓
Dataset Version v17
↓
Evaluate
↓
New Failure
↓
Dataset Version v18

Eval set도 versioning해야 한다.

그리고 장기 benchmark용으로는 개발팀이 자주 보지 않는 hidden holdout set을 따로 두는 게 좋다.

25. 최신 Benchmark 연구의 골칫거리: Contamination

유명 benchmark를 모델이 training 중 이미 봤다면 그 점수는 generalization보다 memorization을 포함할 수 있다.

2026년에는 아예 benchmark dataset 자체가 contamination-resistant해야 한다는 연구까지 나왔다.

기업 내부 eval의 장점은 여기 있다.

최신 실제 업무 trace를 사용하면 공개 benchmark보다 contamination 가능성이 낮고, 무엇보다 내 서비스 distribution을 직접 측정할 수 있다.

26. 2026년 Evaluation Trend를 한 줄로 정리하면 “Benchmark → Workflow”

예전에는:

Prompt → Answer → Score

지금은:

Real Task
↓
Context / Files / Tools
↓
Multi-step Workflow
↓
Deliverable / Outcome
↓
Expert Rubric + Automated Grader

OpenAI GDPval은 44개 직업의 실제 업무에서 문서, 슬라이드, 스프레드시트 같은 deliverable까지 평가한다.

Anthropic의 2026 agent eval guidance도 code-based, model-based, human grader를 조합하고 trajectory와 outcome을 함께 평가하는 방향을 강조한다.

평가 대상이 “문장”에서 “업무”로 이동하고 있다.

27. 현실적인 Enterprise LLM Eval 구축 순서

1

Failure taxonomy 정의

무엇을 잘해야 하는지보다 무엇이 실패인지 먼저 분류.

2

Gold 50–100개

SME가 reference/evidence/rubric 검증.

3

Deterministic grader 먼저

Code로 판단 가능한 것은 LLM Judge에게 주지 않는다.

4

LLM Judge calibration

Human label과 agreement / high-risk error 확인.

5

Silver 200–500+로 확장

Production trace와 synthetic coverage를 추가.

6

Paired A/B + CI

같은 입력에서 version을 비교하고 bootstrap confidence interval 계산.

7

Risk-sliced Release Gate

Overall average보다 critical slice를 별도 gate.

8

Online Eval → Dataset 회수

Production failure가 다음 regression set이 된다.

28. 예를 들어 내가 100개짜리 Gold Set을 처음 만든다면

현실적으로 현업의 시간을 최소화한다면 이런 방식이 좋다.

Step A — AI/개발팀
실제 로그에서 후보 200개 추출 → 중복 제거 → taxonomy로 clustering

Step B — AI/개발팀
source evidence와 draft reference를 미리 작성

Step C — SME
100개를 처음부터 작성하는 게 아니라 이미 준비된 answer/evidence를 Approve / Fix / Reject

Step D — Double review
high-risk 20~30개만 2명 이상이 독립 검수

Step E — Judge calibration
이 Gold를 이용해 automated judge를 검증

현업에게 “정답을 써주세요”보다 “이 근거와 답이 맞는지만 확인해주세요”가 훨씬 빠르다.

실무 가이드 — 가장 쉽게, 그런데 꽤 그럴듯하게 시작해보자

이론적으로 완벽한 Eval System을 처음부터 만들려고 하면 평가 시스템 만들다가 서비스가 안 나온다.

그래서 처음에는 이 정도만 해도 충분하다.(..다고 저와 제 AI는 생각하는데 말이죠.. 기준은 사람이 정하기 나름! 담당자의 경험에 기반한 insight 영역이 아닐까 싶어요. 그래도 일단,)

STARTER PACK

Gold 100개
Silver 300개
Human Review 100~150 judgments
+ Deterministic Grader + LLM Judge

이 정도만 제대로 만들어도 “샘플 몇 개 물어보니 좋아 보입니다” 단계에서는 꽤 멀리 갈 수 있다.

Step 1. 우선 Gold 100개를 만든다

예를 들어 보험/금융 사내 RAG라면 100개를 랜덤으로 뽑지 않고 이렇게 나눈다.

Category	개수	왜 넣나?
자주 묻는 일반 질문	40	실제 traffic 대표
복합 조건 질문	20	난이도 확인
기존에 틀렸던 질문	15	Regression 방지
고위험 정책/약관 질문	15	Risk gate
정보 부족 / 애매한 질문	5	모르면 질문/거절하는지
오타 / 비정상 표현	5	Robustness

여기서 현업에게 “질문 100개랑 정답 100개 만들어주세요” 라고 하면 안 된다.

AI/개발팀이 먼저 실제 로그, FAQ, 과거 문의에서 후보를 만들고 정답 초안과 근거 문서까지 붙여서 준다.

현업에게 요청할 형식

질문
AI팀이 만든 예상 정답
근거 문서 / 조항

→ ① 맞음   ② 수정 필요   ③ 틀림

현업은 작가가 아니라 검수자가 되는 거다.

Step 2. 100개를 전부 여러 명이 볼 필요는 없다

Gold 100개는 1차 검수를 받고, 그중 중요한 30~40개만 2차 검수를 받는다.

Double Review 예시

일반 질문 10개
복합 질문 10개
High Risk 15개
기존 장애/오답 5개

= 40개

이 40개는 나중에 LLM Judge가 제대로 평가하는지 확인하는 Calibration Set으로도 쓸 수 있다.

Step 3. 처음부터 Metric을 너무 많이 만들지 않는다

처음에는 네 개면 충분하다.

Correctness

2 = 맞음 / 1 = 부분정답 / 0 = 틀림

Groundedness

PASS / FAIL — 근거 문서에서 나온 주장인가?

Completeness

PASS / FAIL — 필요한 조건/예외를 빠뜨리지 않았는가?

Critical Error

잘못된 금액 · 보장 · 약관 · 개인정보 · 정책 위반 등

Critical Error는 1~5점으로 평가하지 않는다.

있냐 / 없냐로 본다.

Step 4. 목표는 처음부터 95%라고 적지 않는다

먼저 현재 버전을 측정한다.

예를 들어 Baseline이 이렇다고 하자.

Metric	Baseline	다음 Release Target
Correctness	76%	≥85%
Groundedness	88%	≥95%
Completeness	73%	≥85%
Critical Error	6건	0건
Retrieval Recall@10	89%	≥95%

핵심은 모든 metric을 같은 방식으로 보지 않는다는 것이다.

QUALITY TARGET

Correctness ≥ 85%

HARD GATE

Critical Error = 0

숫자 85%가 진리라는 뜻은 아니다.

실제 목표는 Baseline + 업무 Risk + Human fallback을 보고 정한다.

내부 지식검색 90%와
보험금 자동 지급결정 90%는
전혀 같은 90%가 아니다.

Step 5. A/B는 같은 100개로 비교한다

기존 Version A와 신규 Version B를 동일 Gold Set 100개에서 동시에 실행한다.

	Version A	Version B
Correct	78	87
Partial	12	8
Wrong	10	5
Critical Error	3	0

보고할 때는 단순히 “78% → 87%”만 쓰지 않는다.

Overall Correctness: +9%p
Critical Errors: 3 → 0
Regression: 기존 정답 중 4건 신규 실패
Newly Fixed: 기존 오답 중 13건 개선
Net Improvement: +9 cases

특히 Regression 개수를 반드시 같이 본다.

Step 6. Pairwise를 한 번 더 돌리면 꽤 그럴듯해진다

A와 B의 답변을 Judge에게 동시에 주되 어떤 것이 신규 버전인지 숨긴다.

Version B Win = 46
Version A Win = 19
Tie = 35

승부가 난 case만 보면 B의 preference rate는 약 71%다.

그래서 보고 문구는 이렇게 쓸 수 있다.

Correctness: 78% → 87%
Pairwise Preference: B 71%
Critical Regression: 0
Critical Errors: 3 → 0

Step 7. LLM Judge는 Gold 40개로 먼저 시험한다

현업이 2차 검수한 40개를 Judge도 평가하게 한다.

Judge Metric	예시
Human–Judge Agreement	90%
Critical Error Recall	100%
False PASS	2
False FAIL	2

여기서 Overall Agreement보다 더 중요한 건 위험한 오답을 놓치는가다.

전체 agreement가 90%여도 Critical Error Recall이 70%라면 release gate용 Judge로 쓰기 어렵다.

Step 8. 그다음 Silver 300개는 사람이 전부 보지 않는다

Production trace에서 300개를 추가로 뽑는다.

이건 LLM Judge와 deterministic grader로 자동 평가한다.

사람은 다음 case만 본다.

Judge confidence가 낮은 case
High Risk case
A/B가 크게 갈린 case
Judge disagreement
새로운 query cluster
Random audit sample

즉 300개 중 실제 사람이 보는 것은 30~50개 정도로 제한할 수 있다.

Step 9. 가장 중요한! 최종 보고는? 1 페이지면 된다

LLM RELEASE EVALUATION · v2.3

Dataset
Gold: 100 · Silver: 300 · Human-reviewed: 140 · High-risk: 15

Quality

Metric	v2.2	v2.3	Target
Correctness	78%	87%	≥85%
Groundedness	89%	96%	≥95%
Completeness	76%	88%	≥85%
Recall@10	91%	96%	≥95%
Critical Error	3	0	0

Pairwise
v2.3 Win 46 · v2.2 Win 19 · Tie 35

Regression
4 normal regressions · 0 high-risk regressions

Operational
p95 latency: 4.1s → 4.5s · Cost/request: +7%

Decision: PASS
Quality target satisfied. No critical regression detected. Latency/cost increase accepted.

Step 10. “90%”보다 중요한 건 나머지 10%다

평가 보고서에 이런 문장은 자주 등장한다.

목표 정확도: 90%

그런데 사실 더 중요한 질문은 두 개다.

① 무엇의 90%인가?
② 나머지 10%는 무엇인가?

쉬운 FAQ 100개의 90%와 실제 Production 질문 100개의 90%는 다르다.

그리고 나머지 10%가 “표현이 약간 어색함”이라면 괜찮을 수 있지만, “보험금 지급 조건을 반대로 설명함”이라면 90%라는 평균은 아무 의미가 없다.

Average Accuracy보다
Error Taxonomy가 더 중요하다.

내가 실제로 처음 만든다면

Week 1

실제 질문 150~200개 수집 → 중복 제거 → Gold 후보 100개 선정

Week 2

AI팀 reference/evidence draft → 현업 100개 검수 → High Risk 30~40개 double review

Week 3

Baseline 측정 → LLM Judge calibration → metric / release gate 확정

Week 4

Gold 100 + Silver 300 → Paired A/B → Regression / Pairwise / Release Report

즉 첫 제대로 된 Eval에 필요한 Human Review는 약 100~150 judgments 수준으로도 시작할 수 있다.

그 이후에는 매 release마다 100개를 다시 전부 검수하는 게 아니라, 새로운 failure와 disagreement만 추가 검수하면 된다.

한 줄 요약

현업에게 500개를 채점하게 하지 말자.
현업에게 100개의 기준을 만들어달라고 하고,
나머지 400개는 그 기준을 기계가 따라가게 만들자.

29. LLM 평가에서 정말 자주 보는 실수

① Test Set을 개발 중 계속 들여다본다

결국 eval set 자체에 overfit.

② 전체 평균만 본다

중요한 rare failure가 평균에 묻힘.

③ Judge 결과를 Human Ground Truth처럼 취급한다

Judge calibration 없이 10,000개를 채점해도 틀린 metric을 정밀하게 측정할 뿐.

④ 30~50개에서 2%p 개선을 의미 있다고 해석한다

표본 오차를 성능 개선으로 착각.

⑤ RAG 최종 답만 본다

retrieval failure와 generation failure를 구분 못함.

⑥ Eval Dataset을 영원히 고정한다

Production distribution과 점점 멀어짐.

30. 결국 좋은 Eval System은 작은 “측정 플랫폼”이다

처음에는 평가 dataset 50개짜리 Excel에서 시작할 수 있다.

하지만 시스템이 커지면 평가도 결국 architecture가 된다.

Dataset Registry
↓
Versioned Experiments
↓
Deterministic + LLM Graders
↓
Statistical Comparison
↓
Release Gate
↓
Production Traces
↓
Human Review Queue
↓
Dataset Update ↺

이 구조가 만들어지면 “이번 prompt가 더 좋아 보여요”라는 감각적 대화가

“Gold set에서 +6.2%p, 95% CI는 +2.1~+10.0%p이고, high-risk slice regression은 없으며, retrieval recall@10은 93→97%로 개선됐다”

같은 engineering conversation으로 바뀐다.

MY TAKE

좋은 Eval의 목적은
모델에게 점수를 매기는 것이 아니라
팀이 더 나은 의사결정을 하게 만드는 것이다.

그래서 “몇 개면 충분해?”에 대한 내 답은 이렇다.

처음엔 50~100개의 진짜 좋은 Gold가 1,000개의 애매한 데이터보다 낫다.

하지만 작은 성능 차이를 증명하고 Production을 계속 운영하려면 결국 수백 개의 regression set + 지속적인 online eval로 가야 한다.

---

Papers & References

01. Anthropic — Demystifying Evals for AI Agents, 2026

02. OpenAI — A Shared Playbook for Trustworthy Third-Party Evaluations, 2026

03. OpenAI — How Evals Drive the Next Chapter in AI for Businesses

04. OpenAI — GDPval: Measuring Performance on Real-World Tasks

05. OpenAI Evals — GDPval Pairwise Grading

06. OpenAI — Introducing SWE-bench Verified

07. LangSmith — Evaluation Concepts

08. LangSmith — Agent Trajectory Evaluations

09. Ru et al. — RAGChecker: A Fine-Grained Framework for Diagnosing RAG

10. Saad-Falcon et al. — ARES: Automated Evaluation for RAG Systems

11. Shi et al. — Judging the Judges: Position Bias in LLM-as-a-Judge

12. Zhou et al. — Language Bias of Pairwise LLM-as-a-Judge, 2026

13. Soumik — Judging the Judges: Bias Mitigation Strategies, 2026

14. Al-Lawati et al. — LLM Benchmark Datasets Should Be Contamination-Resistant, 2026

※ 본문의 sample-size 구간은 universal rule이 아니라 실무적 guideline입니다. 필요한 표본 수는 metric 분산, category 수, 목표 confidence interval, 감지하려는 성능 차이, paired correlation 등에 따라 달라집니다. 중요한 release decision에는 실제 데이터에 기반한 power analysis 또는 bootstrap confidence interval을 권장합니다.

written by rubrub · LLM / Evaluation / AI Engineering