콘텐츠로 이동

모델 평가와 데이터 품질

분류: Layer 11 - AI 기초 & 머신러닝 | 선수지식: L11-20 (고전 ML), L11-30 (ML 패러다임)

모델 평가와 데이터 품질 — Metrics, Benchmarks, Bias

섹션 제목: “모델 평가와 데이터 품질 — Metrics, Benchmarks, Bias”

모델 평가는 모델이 어떤 입력에서 어떤 품질로 동작하는지를 반복 측정하는 체계이고, 데이터 품질은 그 측정에 쓰는 학습·평가 데이터가 정확하고 대표적인지 확인하는 기준이다. 둘은 분리되지 않는다. 같은 모델도 평가셋이 낡았거나 지표가 문제와 맞지 않으면 좋아 보이고, 같은 평가 지표도 데이터가 편향되면 운영 실패를 숨긴다.

이 문서는 “지표 이름 외우기”보다 측정하려는 실패가 무엇인지 먼저 정하고, 그 실패를 드러내는 지표·gold dataset·통계 판정을 고르는 방법을 목표로 한다.

  • 모델 선택 결정: “이 LLM이 다른 LLM보다 나은가”를 벤치마크 점수만이 아니라 자기 도메인 기준으로 판단한다.
  • 운영 회귀 감지: 모델 버전, prompt, retrieval 설정을 바꾼 뒤 어느 영역이 망가졌는지 찾는다.
  • silent failure 발견: 전체 accuracy(정확도)는 그대로인데 minority class, 특정 언어, 특정 업무만 망가지는 경우를 드러낸다.
  • benchmark의 함정 방지: MMLU 점수가 좋아도 실 운영 한국어 Q&A, RAG 답변, tool call은 약할 수 있다.
  • 데이터 품질 관리: 평가셋의 label noise, freshness, leakage가 모델 품질 판단을 오염시키지 않게 한다.

평가는 보통 네 질문으로 시작한다.

  1. 무엇을 맞혔다고 볼 것인가: 정답 클래스, 연속값, 자유 텍스트 품질, 검색 근거 충실도 중 무엇인가.
  2. 어떤 실패를 놓치면 위험한가: false negative, hallucination, contamination, group별 불공정, regression 중 무엇인가.
  3. 그 실패를 드러내는 데이터가 있는가: public benchmark인지, 자기 도메인 gold dataset인지, production sample인지 구분한다.
  4. 차이가 noise가 아닌가: sample 수, confidence interval, paired test로 판정한다.

3.0 선행 기술의 한계 — 평가 도구의 lineage

섹션 제목: “3.0 선행 기술의 한계 — 평가 도구의 lineage”

평가는 단일 지표가 아니라 “선행 도구의 정량적 한계 → 새 도구”의 연쇄로 확장돼 왔다. 본 토픽의 PR-AUC·LLM-as-judge·gold dataset은 각각 직전 도구가 silent하게 망가지는 지점을 메우는 메커니즘이다.

  • Accuracy(전체 맞은 비율) → PR-AUC(precision-recall curve 아래 면적) (Saito & Rehmsmeier 2015): 1:10 imbalance 시뮬레이션에서 accuracy 0.6은 균형/imbalance 양쪽에서 동일하게 측정되지만 precision은 0.6 → 0.33으로 떨어진다. ROC도 specificity 해석이 imbalance에서 직관과 어긋난다. PR-AUC는 분모에 TN을 포함하지 않아 imbalance ratio에 그대로 반응 (§3.2).
  • 정적 benchmark → LiveBench·Arena-Hard (White et al. 2024, arxiv:2406.19314): MMLU·GSM8K는 학습 데이터 contamination으로 점수가 saturate. LiveBench는 매월 문제 갱신 + 객관 ground truth로 채점, Arena-Hard는 LLM-judge 기반이어서 GPT-4가 LiveBench보다 Arena-Hard에서 상대적으로 높게 나옴 — 같은 모델이 두 벤치에서 다른 순위가 나오는 것 자체가 judge bias의 lineage 잔여물 (§3.5).
  • Auto metric (BLEU/ROUGE) → LLM-as-judge(LLM이 답변을 채점) (Zheng et al. 2023): n-gram 일치는 “의미 같지만 표현 다른” 자유 텍스트에 무력. 해당 controlled/crowdsourced 설정에서 GPT-4 judge가 사람 평가와 80%+ 일치했지만, self-enhancement로 자기 답변에 약 +10% 승률 편향도 관측됐다. 그래서 자체 사람 calibration과 swap test를 먼저 수행하고, 위험·비용에 따라 deterministic check·추가 judge·사람 검수를 조합한다 (§3.16 비용 자릿수 ↑).
  • Public benchmark → Gold dataset(검수 정답셋) + Regression eval(변경 전후 회귀 검증): MMLU·HumanEval 점수가 좋아도 “내 도메인 한국어 Q&A”는 알 수 없다 (§3.6). 자기 도메인 gold set에서 같은 케이스를 두 모델에 모두 주고 paired difference를 보는 것이 운영 회귀 판정의 핵심이다. 한 모델의 pass rate가 80%일 때 Wilson 계열 구간을 약 ±5%p 정밀도로 추정하는 표본 수는 약 246개지만, 이것은 두 모델의 5%p 차이를 검출하는 power 계산이 아니다. 모델 비교 표본 수는 두 모델이 서로 다르게 판정된 discordant pair 비율까지 가정해 따로 계획한다 (§3.15).

이 토픽이 사라지면 무엇이 깨지나: LLM 버전 교체 시 한국어 도메인만 망가져도 MMLU·HumanEval 변화 없이 production에 silent regression이 들어간다. judge·gold set 없이는 “비용 17× 싼 mini 모델로 교체해도 안전한가”라는 운영 결정을 객관적으로 부정도 인정도 못 한다.

분류 평가는 **confusion matrix(혼동 행렬)**에서 시작한다. 행렬은 예측과 실제 정답을 네 칸으로 나누고, 각 칸이 어떤 실패를 뜻하는지 먼저 보게 해준다.

실제 양성 실제 음성
예측 양성 TP FP
예측 음성 FN TN
  • TP(True Positive): 양성이라고 예측했고 실제도 양성이다.
  • FP(False Positive): 양성이라고 예측했지만 실제는 음성이다. 정상 거래를 사기로 차단하는 식의 오탐이다.
  • FN(False Negative): 음성이라고 예측했지만 실제는 양성이다. 실제 사기를 놓치는 식의 미탐이다.
  • TN(True Negative): 음성이라고 예측했고 실제도 음성이다.

작은 예시로 감을 잡자. 사기 탐지 100건 중 실제 사기 10건, 정상 90건이 있고 모델 결과가 아래와 같다고 하자.

실제 사기 실제 정상
사기라고 예측 6 4
정상이라고 예측 4 86

이때 TP=6, FP=4, FN=4, TN=86이다.

accuracy = (TP + TN) / 전체 = (6 + 86) / 100 = 92%
precision = TP / (TP + FP) = 6 / 10 = 60%
recall = TP / (TP + FN) = 6 / 10 = 60%
specificity = TN / (TN + FP) = 86 / 90 = 95.6%
F1 = 2 * P * R / (P + R) = 60%

Accuracy(정확도)는 전체 중 맞힌 비율이다. Precision(정밀도)은 “양성이라고 한 것 중 진짜 양성”이고, Recall(재현율)은 “진짜 양성 중 잡아낸 것”이다. Specificity(특이도)는 음성을 음성으로 남긴 비율이다. 여기서 어떤 지표가 중요한지는 업무 비용에 따라 달라진다. 사기 미탐 비용이 크면 recall을 올리고, 정상 거래 차단 비용이 크면 precision과 specificity도 함께 본다.

3.1 분류 평가의 기본 지표 비교

Accuracy

식: (TP+TN) / 전체 / 직관: 전체 맞은 비율

약점: imbalance에서 무력

Precision (정밀도)

식: TP / (TP+FP) / 직관: "양성이라 한 것 중 진짜 양성"

약점: recall과 trade-off

Recall (재현율)

식: TP / (TP+FN) / 직관: "진짜 양성 중 잡아낸 것"

약점: precision과 trade-off

F1

식: 2·P·R / (P+R) / 직관: precision·recall 조화 평균

약점: 둘의 가중치 같다고 가정

Specificity

식: TN / (TN+FP) / 직관: "음성을 음성이라 한 비율"

사용 맥락: 의료·보안처럼 false positive 비용이 큰 영역

Accuracy의 함정: 99% negative 데이터에서 “전부 negative”로 예측하면 accuracy는 99%다. 하지만 positive recall은 0%다. L11-20의 imbalance 예시와 같은 silent failure다. Saito & Rehmsmeier 2015 시뮬레이션(1000 positive vs 10000 negative, 1:10)에서도 같은 accuracy 0.6이 균형 데이터에서는 precision 0.6으로 보이지만 imbalance에서는 precision 0.33으로 떨어진다. 같은 점수가 다른 운영 의미를 가린다는 정량 증거다.

결정 규칙: positive:negative 비율이 1:5를 넘으면 accuracy 단독 판단을 금지한다. confusion matrix, precision, recall, F1, PR-AUC를 같이 보고 threshold를 움직였을 때 trade-off가 어떻게 변하는지 확인한다.

분류 모델은 보통 “사기 확률 0.73” 같은 점수를 낸다. 운영은 이 점수에 threshold를 놓고 action을 결정한다. threshold를 낮추면 더 많이 잡아 recall이 오르지만 FP도 늘 수 있고, threshold를 높이면 FP는 줄지만 FN이 늘 수 있다. ROC와 PR curve는 이 threshold 이동을 한 장의 곡선으로 보는 도구다.

  • ROC(Receiver Operating Characteristic) curve: TPR(True Positive Rate, recall) vs FPR(False Positive Rate, FP / (FP+TN))를 그린다.
  • AUC(Area Under the Curve): 곡선 아래 면적이다. ROC-AUC가 1에 가까울수록 임의의 positive를 임의의 negative보다 높은 점수로 둘 가능성이 크다.
  • PR curve(Precision-Recall curve): precision vs recall을 그린다.
  • PR-AUC 또는 AUC-PR: PR curve 아래 면적이다. positive가 드문 문제에서 실제 운영 부담을 더 직접적으로 보여준다.

왜 imbalance에서 PR-AUC가 더 민감한지 손으로 보자.

실제 positive 100개, negative 9,900개
어떤 threshold에서:
TP = 80, FN = 20
FP = 920, TN = 8,980
recall = 80 / 100 = 80%
FPR = 920 / 9,900 = 9.3%
precision = 80 / (80 + 920) = 8%

ROC 관점에서는 FPR 9.3%가 그렇게 나빠 보이지 않을 수 있다. 하지만 운영자는 “양성이라고 알린 1,000건 중 920건이 오탐”을 처리해야 한다. PR curve는 이 부담을 precision 8%로 바로 드러낸다. 그래서 fraud, anomaly detection, rare disease, abuse detection처럼 positive가 드문 문제에서는 ROC-AUC가 좋아도 PR-AUC를 반드시 같이 본다.

경계도 있다. PR-AUC의 기준선은 positive prevalence다. positive가 1%인 문제와 20%인 문제의 PR-AUC를 숫자만으로 직접 비교하면 안 된다. 같은 데이터 분포에서 모델·threshold 후보를 비교할 때 특히 유용하다.

회귀 평가는 연속값 예측의 오차를 잰다. 분류처럼 맞음/틀림으로 나누기 어렵기 때문에, 오차를 어떤 방식으로 벌점화할지가 지표 선택의 핵심이다.

지표직관
MSE평균 제곱 오차큰 오차에 민감
MAE평균 절대 오차outlier에 robust
설명된 분산 비율[0,1] (음수 가능)
MAPE평균 절대 백분율 오차스케일 무관. 0 근처에서 약함

작은 예시:

실제 배송 시간: [10, 10, 10, 10]
모델 A 예측: [ 9, 11, 9, 11] -> 오차 [1, 1, 1, 1]
모델 B 예측: [10, 10, 10, 18] -> 오차 [0, 0, 0, 8]
MAE(A) = 1, MSE(A) = 1
MAE(B) = 2, MSE(B) = 16

두 모델의 평균 절대 오차 차이는 1시간이지만, MSE는 큰 오차 하나를 훨씬 강하게 벌준다. 한 번 크게 틀리면 사용자 경험이 치명적인 배송 ETA·가격 예측이면 MSE나 상위 percentile 오차를 같이 본다. 반대로 센서 노이즈처럼 outlier가 불가피하면 MAE가 더 안정적일 수 있다. MAPE는 “10분 오차가 원래 100분짜리 예측에서 10%인지, 5분짜리 예측에서 200%인지”를 볼 때 유용하지만 실제값이 0에 가까우면 폭발한다.

분류·회귀는 정답과 예측을 비교하기 쉽다. LLM 출력은 자유 텍스트라 같은 의미를 여러 표현으로 쓸 수 있고, 답변의 사실성·도움됨·안전성·형식 준수도 분리해 봐야 한다. 그래서 LLM 평가는 “자동 지표로 빠르게 걸러내고, 자유 텍스트 품질은 judge·사람 검수·gold dataset으로 보강”하는 구조가 된다.

  • Perplexity: exp(평균 cross-entropy)다. 다음 토큰을 얼마나 덜 놀라워하게 예측하는지 보는 값이며 낮을수록 좋다. 단 next-token prediction 능력만 보므로 “사용자 질문에 유용하게 답하는가”와는 약한 상관만 가진다.
  • BLEU(Bilingual Evaluation Understudy): 번역에서 후보 문장과 정답 문장의 n-gram 겹침을 본다. 표현이 비슷한 번역 비교에는 빠르지만, 의미는 같은데 단어가 다르면 낮게 나온다.
  • ROUGE(Recall-Oriented Understudy for Gisting Evaluation): 요약에서 정답 요약의 n-gram을 얼마나 회수했는지 본다. 핵심 문구가 정해진 요약에는 쓸 수 있지만, 더 좋은 재표현을 벌줄 수 있다.
  • BERTScore: BERT 임베딩으로 후보와 정답의 의미 유사도를 본다. BLEU/ROUGE보다 표현 변화에 강하지만, 사실성·논리·업무 정책 준수까지 보장하지는 않는다.
  • Exact match: 코드·수학·정규화된 JSON처럼 정답이 명확한 경우에만 강하다.

경계는 분명하다. BLEU/ROUGE가 낮아도 사람이 보기에 좋은 답일 수 있고, BERTScore가 높아도 hallucination이 있을 수 있다. 자동 지표는 “명백히 나쁜 후보를 싸게 걸러내는 1차 필터”로 두고, 제품 품질 판정은 gold dataset과 judge/사람 평가로 옮겨야 한다.

LLM-as-judge는 강한 LLM이 다른 LLM의 출력을 평가하게 하는 방식이다. 자동 지표가 n-gram·임베딩 수준에서 막히는 자유 텍스트 평가를 다루기 위해 등장했다. 보통 단일 답변 점수, 두 답변 pairwise 비교, rubric 기반 다축 채점으로 쓴다.

  • 장점과 경계: 자유 텍스트도 평가할 수 있다. Zheng et al. 2023(arxiv:2306.05685)의 특정 controlled/crowdsourced 설정에서는 GPT-4 judge가 사람 평가와 80%+ 일치했지만, 이 관측을 모든 과업·언어·전문 영역의 보편 정확도로 옮길 수는 없다. 도메인 slice별 사람 일치도를 다시 calibration한다.
  • 표준 4종 bias (MT-Bench, Zheng et al. 2023):
    • Position bias: 응답 순서가 점수에 영향 → 반대 순서로 다시 평가(swap test). 허용 flip rate와 후속 조치는 과업 위험·사람 calibration·비용에 맞춰 사전 정의한다.
    • Verbosity bias: 여러 LLM judge에서 긴 답변 선호가 관측됨. GPT-4가 비교적 잘 방어한 실험에서도 차이가 남으므로 AlpacaEval LC 같은 length-controlled 정규화와 자체 calibration을 검토한다.
    • Self-enhancement bias: Zheng 2023의 해당 실험에서는 자기 모델 답변에 약 +10% 승률 편향이 관측됐다. Cross-family judge는 상관된 오류를 줄일 후보지만, same-family judge를 보편적으로 금지하지 않는다. 모델 가족보다 실제 사람 일치도·swap 안정성·rubric 준수도를 calibration해 선택한다.
    • Limited reasoning bias: 수학·논리 평가 능력의 한계 (judge 자체가 약하면 평가도 약함)
  • 2024+ 추가 bias: Familiarity bias, Authority bias (권위적 톤 선호)
  • Judge robustness 평가: JudgeBench, Prometheus 2 — judge 모델 자체를 평가하는 벤치마크
  • MT-Bench, AlpacaEval LC, Arena-Hard-Auto v2.0: LLM-as-judge 기반 표준 벤치마크
  • 비용: GPT-4 평가는 호출당 비용, 대규모 회귀 시 누적 부담

Swap test를 작은 예로 보자.

질문 Q에 대한 답변 A, B가 있다.
평가 1: [A 먼저, B 나중] -> judge가 A 승리
평가 2: [B 먼저, A 나중] -> judge가 B 승리

두 평가가 모두 “먼저 나온 답변”을 고르면 position bias가 의심된다. 예를 들어 가상 calibration set의 200개 pairwise 평가에서 18개가 swap 후 뒤집히면 flip rate는 9%다. 9%5%p는 보편적인 ensemble 발동선이 아니다. 이 가상 결과에서는 고위험 과업인지, 사람과 judge의 불일치가 어디에 몰렸는지, 추가 judge의 오류가 독립적인지 확인한 뒤 prompt 수정·deterministic checker·단일 judge 유지·다중 judge·사람 검수 중 비용 대비 적절한 조합을 고른다.

Judge 정책은 task/risk/calibration-driven이어야 한다. 정답을 실행할 수 있는 코드·수학·JSON은 deterministic checker를 우선하고, 저위험 문체 비교는 calibration된 단일 judge로 충분할 수 있다. 법무·안전처럼 오류 비용이 큰 과업은 사람 검수 비중을 높인다. Ensemble은 서로 다른 judge의 오류가 실제로 보완적일 때만 이득이며, 같은 계열인지 다른 계열인지만으로 강제하거나 금지하지 않는다.

LLM-as-judge의 경계는 “사람 평가를 완전히 대체하는 도구”가 아니라는 점이다. 빠르고 일관된 1차 판정에는 강하지만, judge 자체가 모르는 전문 영역·수학 reasoning·코드 실행 결과·법적/정책 판단에서는 사람 검수나 실행 기반 채점이 붙어야 한다.

Public benchmark는 모델을 빠르게 비교하는 공통 시험지다. 문제는 공통 시험지가 내 제품의 입력 분포와 같지 않고, 오래 공개된 문제는 학습 데이터에 들어갔을 수 있다는 점이다.

**MMLU(Massive Multitask Language Understanding)**는 여러 분야 지식 다지선다를 보고, HumanEval은 Python 함수 작성 능력을 본다. 둘 다 유용하지만, “내 도메인 한국어 상담 답변”, “사내 문서 RAG”, “tool call이 필요한 multi-turn 업무”를 직접 측정하지 않는다.

벤치마크측정함정
MMLU다영역 다지선다학습 데이터에 포함됐을 위험 (contamination)
HumanEvalPython 함수 작성, 164 문제작은 셋 → overfitting, contamination 위험
MBPPPython 기본 함수 (974)HumanEval보다 큼
GSM8K초등 수학학습 데이터 contamination 보고됨 (Schaeffer 2023)
MATH-500 / AIME 24/25수학 reasoningreasoning 모델 평가 표준
GPQA Diamond (198Q)PhD-level 과학·수학frontier 모델 변별
MMLU-ProMMLU 후속 (10지선다, reasoning)MMLU의 contamination·saturation 대응
HELM (Capabilities/Safety/Lite)종합 다축 평가metric 다양성·비용이 한계
LMSYS Arena사람 직접 비교 (Bradley-Terry)“Arena Score 100 차이 ≈ 64% 승률”
Arena-Hard / Auto v2500 hard prompt, style control judgeMT-Bench 후속
MT-BenchLLM-as-judge (1~10 score)GPT-4 ≈ 9.0, GPT-3.5 ≈ 7.9 baseline
LiveBench정기 갱신, contamination 방지운영자 신뢰 가능 ranking
SWE-Bench Verified (500)GitHub 이슈 해결에이전트 운영 표준
BFCL v3 (Berkeley)function calling 정확도tool-using LLM 평가
τ-benchtool agent multi-turn에이전트 운영 시뮬레이션

Data contamination은 벤치마크 데이터가 학습 데이터에 새어 들어가 모델이 문제를 푼 것이 아니라 외운 상태를 말한다. 점수는 올라가지만 새로운 문제 해결 능력은 그만큼 높아졌다고 볼 수 없다. Canary string 같은 검증 기법, LiveBench처럼 정기 갱신되는 벤치마크, Arena-Hard처럼 더 어려운 prompt와 style control을 쓰는 평가가 이 문제에 대응한다.

Benchmark를 읽는 결정 기준:

  • 모델 family를 넓게 고르는 초기 후보 선별에는 public benchmark가 유용하다.
  • 내 제품의 최종 채택 판단은 gold dataset과 production A/B가 맡아야 한다.
  • 정적 benchmark 하나에서 1~2점 차이가 나도, 내 domain gold set에서 유의미한 차이가 없으면 교체 근거로 약하다.
  • agentic 시스템은 MMLU보다 SWE-Bench Verified, BFCL, tau-bench처럼 tool 사용과 multi-turn을 직접 보는 벤치가 더 가깝다.

운영자에게 가장 중요한 평가 도구는 gold datasetregression eval이다.

  • Gold dataset: 도메인·작업별 정답 셋이다. 보통 100~1000개이며 사람이 검수한다. public benchmark가 공통 시험지라면 gold dataset은 내 서비스의 기준 시험지다.
  • Regression eval: 모델 변경(LLM 버전 교체, prompt 수정, fine-tune, retrieval 설정 변경)마다 같은 gold set로 점수를 비교하는 회귀 검증이다.
  • 회귀 검출: 점수가 떨어진 케이스 = silent failure 후보. 사람이 직접 검수
  • A/B 테스트와 결합: gold set는 빠른 회귀 감지, A/B는 실 운영 검증
  • 운영 표준 도구: Promptfoo, Braintrust, LangSmith, Langfuse, Ragas (RAG 특화)

작은 regression eval 예시:

Gold set 200개를 고정한다.
기존 prompt와 새 prompt를 같은 200개 질문에 적용한다.
기존 prompt pass: 164 / 200 = 82%
새 prompt pass: 158 / 200 = 79%
단순 차이: -3%p

여기서 바로 “새 prompt가 나쁘다”고 결론 내리면 안 된다. 같은 sample에서 어떤 케이스가 pass/fail로 뒤집혔는지 보고, paired bootstrap이나 McNemar test로 차이가 noise인지 판단한다. 새 prompt가 6개 덜 맞혔더라도 95% confidence interval이 0을 포함하면 “품질 차이 미확정”이다. 대신 새로 실패한 케이스가 법무·결제 같은 high-risk 카테고리에 몰리면 통계적으로 애매해도 배포를 막을 수 있다.

언제 gold dataset이 깨지는가 (Inversion):

  • 정밀도와 검정력 혼동: Wilson score interval은 한 모델의 이항 pass rate 하나를 얼마나 정밀하게 추정하는지 보는 구간이다 (Wilson 1927). pass rate를 80%로 가정하고 95% 구간의 반폭을 약 5%p로 잡는 1차 근사는 246개, 가장 불확실한 50% 근처는 약 385개다. 이 숫자는 “두 모델의 5%p 차이를 80% power로 검출”한다는 뜻이 아니다. 같은 케이스를 두 모델에 주는 비교에서는 A만 pass, B만 pass가 얼마나 나올지와 사전 비열등성 한계까지 넣어 paired power를 별도로 계산해야 한다. 250개 미만이면 무조건 실패라는 규칙도 아니며, 먼저 목표가 단일 비율 정밀도인지 모델 차이 판정인지 구분한다.
  • Freshness 붕괴: gold set이 production 입력 분포와 어긋남 (covariate shift, L11-30 §3.9). 진단: Promptfoo dashboard에서 최근 fail case 카테고리 분포 ≠ gold set 카테고리 분포면 gold set 갱신. 6개월 무갱신은 거의 항상 stale.
  • Annotator 단일화: 한 사람이 만든 200개는 그 사람의 bias가 평가 기준이 됨 (§3.10 confirmation bias). 진단의 가상 시작점으로 두 번째 annotator가 20개를 재라벨하고 Cohen’s kappa와 불일치 유형을 함께 읽는다. 20개, kappa < 0.6은 빠른 표본 점검 예이지 산업 공통 SLA나 자동 spec 재작성 규칙이 아니다. 위험도·class 분포·허용 오차에 맞춰 표본 수와 후속 조치를 정한다.
  • silent failure: 같은 정답이지만 표현만 다른 답에 LLM-judge가 일관되지 않게 점수를 줌. 진단: paraphrase 5개 변형으로 같은 정답 입력 후 분산이 1점(10점 만점) 넘으면 judge prompt rubric을 더 구체화하거나 exact-match 부분 도입.

좋은 평가는 좋은 데이터에서 출발한다. 데이터 품질은 “정답이 맞는가”만이 아니라, 평가하려는 운영 상황을 데이터가 대표하는가까지 포함한다.

  • Accuracy(레이블 정확도): 레이블이 실제 정답과 맞는가. 평가 데이터의 레이블이 틀리면 좋은 모델이 벌점을 받고 나쁜 모델이 보상받는다.
  • Coverage: 모든 카테고리·엣지 케이스가 들어 있는가. 결제, 환불, 보안, 장애처럼 risk가 다른 카테고리를 한 평균으로 묶으면 위험하다.
  • Balance: 클래스 imbalance를 관리하는가. 운영 비율을 그대로 반영할지, 드문 high-risk 케이스를 oversample할지 목적에 맞게 정한다.
  • Freshness: 시간이 지나며 distribution shift가 생기지 않았는가. L11-30의 covariate shift처럼 입력 분포가 바뀌면 예전 gold set이 더 이상 대표 샘플이 아니다.
  • Provenance: 어디서 왔는지, 라이선스가 어떤지 추적되는가. 출처가 불명확하면 재현성과 법적 검토가 어렵다.
  • Privacy: PII 제거, GDPR 준수 등 민감정보 처리가 되어 있는가.
  • Annotator agreement: 사람 두 명이 같은 기준으로 같은 답을 내는가. Cohen’s kappa는 두 annotator의 일치율에서 우연히 맞을 확률을 뺀 지표다. Landis & Koch가 제시한 <0.2 poor, 0.2~0.4 fair, 0.4~0.6 moderate, 0.6~0.8 substantial, >0.8 almost perfect는 널리 인용되는 역사적 해석 guide이지 모든 domain의 release gate가 아니다. 같은 kappa라도 class prevalence와 오류 비용이 다르면 결론이 달라지므로 raw agreement, class별 confusion, 실제 불일치 사례와 함께 기준을 사전 정의한다.

Kappa를 직관적으로 읽으면, 단순 일치율 90%도 쉬운 label이 대부분이면 과대평가일 수 있다. 두 사람이 거의 모두 “정상”이라고 찍는 데이터에서는 우연 일치도 높다. Kappa는 이 우연 일치를 보정해 label spec이 실제로 공유되는지 확인한다.

운영에서 자주 만나는 실패는 모델 구조보다 데이터 품질에서 먼저 온다.

  • Label noise: 사람 annotator의 실수다. Northcutt et al. 2021 보고에 따르면 ImageNet/MNIST 등 주요 데이터셋 평균 3.4% 라벨 오류가 있었다. 작은 gold set에서는 3% 오류도 모델 간 차이를 뒤집을 수 있다.
  • Annotator bias: 한 사람의 의견이 평가 기준이 된다. 두 번째 annotator 샘플링과 kappa로 방어한다.
  • Selection bias: 학습·평가 데이터가 운영 데이터와 분포가 다르다. L11-30의 covariate shift처럼 신규 채널, 신규 상품, 장애 상황 입력이 빠질 수 있다.
  • Data leakage: 학습 데이터에 평가 데이터 또는 평가에만 있어야 할 정보가 섞인다. L11-20의 scaler 예시처럼 split 전 preprocessing도 leakage가 될 수 있다.
  • Temporal leakage: 미래 정보를 feature로 사용한다. 예를 들어 “결제 취소 여부”를 예측하면서 취소 이후에만 생기는 support tag를 feature로 넣으면 validation은 좋아도 운영에서는 쓸 수 없다.
  • PII / 저작권: 운영 시 법적 문제가 된다. 평가셋도 학습셋만큼 provenance와 privacy를 관리해야 한다.

실패 신호는 명령어보다 패턴으로 기억하는 편이 낫다. validation 점수가 비현실적으로 높으면 leakage를, 시간이 지날수록 fail case 카테고리가 바뀌면 freshness 붕괴를, 특정 annotator가 만든 샘플에서만 모델 순위가 달라지면 annotator bias를 먼저 의심한다.

Bias와 fairness는 “평균 성능이 높다”와 “모든 사용자에게 안전하다”가 다르다는 문제에서 나온다. 전체 accuracy가 좋아도 특정 성별·지역·언어·장애 유형에서 FN이나 FP가 높으면 제품 리스크는 남는다.

  • Bias 종류:
    • Demographic bias (성별·인종·지역)
    • Recency bias (최근 데이터 과대 가중)
    • Selection bias (특정 그룹 underrepresented)
    • Confirmation bias (annotator의 선입견)
  • 측정 지표:
    • Demographic parity: 그룹별 양성 예측 비율 같음
    • Equalized odds: 그룹별 TPR·FPR 같음
    • Calibration: 예측 확률이 실제 빈도와 일치
  • LLM bias: stereotype bias, language bias (영어 우대), refusal bias
  • 표준 도구: Fairlearn, IBM AI Fairness 360, BOLD/StereoSet (LLM 전용)

Demographic parity는 그룹별 양성 예측 비율이 같은지를 본다. Equalized odds는 실제 양성/음성 안에서 오류율이 같은지를 본다. 둘은 동시에 만족하기 어렵거나 제품 목표와 충돌할 수 있다. 그래서 fairness 평가는 “어떤 그룹에서 어떤 오류 비용이 더 위험한가”를 먼저 정하고 지표를 고른다.

운영 평가는 절차 목록이 아니라 필터를 여러 겹 두는 구조로 이해하면 쉽다. 싼 자동 지표로 명백한 실패를 먼저 걸러내고, 자유 텍스트 품질은 LLM-as-judge와 사람 검수로 좁히며, 마지막에는 production A/B와 drift 모니터링으로 확인한다.

1. Gold dataset 준비 (가상 시작 예: 도메인별 100~500개, 실제 크기는 power·위험으로 결정)
2. 자동 metric 1차 통과 (BLEU, ROUGE, exact match)
3. LLM-as-judge로 자유 텍스트 품질 (calibration에 따라 단일 또는 다중 judge)
4. 사람 검수 (가상 시작 예: 10%; 실제 비율은 disagreement·위험 slice로 결정)
5. Regression dashboard (모델 변경 vs 점수 추이)
6. A/B 테스트 (실 운영 검증)
7. drift 모니터링 (입력 분포 변화 감지)

각 단계의 역할은 다르다. BLEU/ROUGE/exact match는 빠르지만 표현 다양성에 약하다. LLM-as-judge는 자유 텍스트를 잘 다루지만 bias와 비용이 있다. 사람 검수는 가장 믿을 수 있지만 비싸기 때문에 judge disagreement, high-risk 카테고리, 새로 실패한 regression case에 집중한다. A/B 테스트는 실제 사용자 행동을 보지만 느리고 rollback 비용이 있다. 그래서 gold dataset은 빠른 회귀 방지 장치이고, A/B는 최종 운영 검증이다.

3.12 Reasoning·Agentic 평가 (2024-2026 핵심)

섹션 제목: “3.12 Reasoning·Agentic 평가 (2024-2026 핵심)”

운영자가 reasoning 모델·에이전트를 도입할 때 반드시 알아야 할 평가 영역.

  • GPQA Diamond (198Q PhD-level): frontier 모델 변별, 학습 시 거의 못 푸는 문제
  • MATH-500 / AIME 2024/2025: 수학 reasoning. o1·DeepSeek-R1 평가 표준
  • ARC-AGI: 추상·일반 지능 평가
  • best-of-N / cons@k / self-consistency: 같은 문제에 N번 답하고 majority voting — test-time compute scaling 평가
  • Pass@k (코드 평가, Chen et al. 2021): 1 - C(n-c, k)/C(n, k) unbiased estimator

선택 기준은 문제의 검증 방식이다. 정답이 하나로 검증되는 수학·코드는 Pass@k와 self-consistency가 잘 맞고, 지식·과학 reasoning은 GPQA처럼 contamination이 어렵고 난도가 높은 benchmark가 낫다. 같은 문제를 여러 번 풀게 하는 best-of-N은 모델 품질과 test-time compute 비용을 함께 측정하므로, L11-60의 test-time compute scaling과 연결해서 읽는다.

Agentic 평가 (에이전트 운영자 필수)

섹션 제목: “Agentic 평가 (에이전트 운영자 필수)”
  • SWE-Bench Verified (500): GitHub 이슈 해결. Devin·Cline·Cursor 같은 에이전트 ranking 표준
  • BFCL v3 (Berkeley Function Calling Leaderboard): tool/function calling 정확도. 에이전트 핵심 능력
  • τ-bench (tau-bench): multi-turn tool agent. user simulation 포함
  • WebArena, OSWorld, GAIA: web/OS 자동화 에이전트
  • ToolBench: 16k API 호출 평가

에이전트 평가는 “답을 맞혔는가”보다 “도구를 올바른 순서로 불렀는가”가 중요하다. function calling 자체가 문제면 BFCL을 먼저 보고, 여러 턴 동안 상태를 유지하고 도구 결과를 반영해야 하면 tau-bench류를 본다. 실제 코드 변경 능력은 SWE-Bench처럼 patch가 테스트를 통과하는지로 보는 편이 더 직접적이다.

운영 reproducibility의 핵심.

  • lm-evaluation-harness (EleutherAI): 가장 널리 쓰이는 표준
  • OpenCompass: Shanghai AI Lab, 다국어·다축 평가
  • Inspect AI (UK AISI): safety 평가 표준
  • simple-evals (OpenAI): 미니멀 reference
  • 운영 통합: Promptfoo, Braintrust, LangSmith, Langfuse

**RAG(Retrieval-Augmented Generation)**는 “문서를 검색한 뒤 그 근거로 답변을 생성”하는 구조다. 그래서 일반 LLM 답변 품질만 보면 부족하다. 검색이 틀렸는지, 검색은 맞았는데 생성이 틀렸는지, 답변은 맞지만 출처가 빈약한지 분리해야 한다.

  • Retrieval 품질: recall@k, MRR, Hit@k, NDCG@k. 정답 근거 문서가 top-k 안에 들어오는지, 얼마나 위에 오는지 본다.
  • Faithfulness: 답변이 검색된 문서에 충실한가. 검색 문서에 없는 내용을 그럴듯하게 추가하면 faithfulness 실패다.
  • Answer relevance: 답변이 질문에 답하는가. 근거에는 충실하지만 질문을 비껴가면 낮다.
  • Context precision: 검색된 chunk 중 관련 있는 비율이다. 관련 없는 chunk가 많으면 답변 모델이 헷갈리고 비용도 늘어난다.
  • Context recall: 정답에 필요한 정보가 실제로 검색됐는가. 검색이 빠뜨린 사실은 생성 모델이 올바르게 답하기 어렵다.
  • 2025 추가 지표: Aspect Critic, Noise Sensitivity, Multi-turn evaluation (Ragas)
  • 표준 도구: Ragas (4-지표 표준), ARES, TruLens (RAG triad)

작은 예시:

질문: "환불 처리 기간은 며칠인가?"
정답 근거: 환불 정책 문서 chunk #12
검색 결과 top-3:
1. 배송 지연 안내
2. 환불 정책 chunk #12
3. 결제 수단 변경 FAQ
생성 답변: "보통 3~5영업일이며, 카드사에 따라 다를 수 있습니다."

이 경우 Hit@3은 성공이고, MRR은 정답 chunk가 2위라 1/2다. 답변이 chunk #12의 내용과 맞으면 faithfulness는 좋다. 하지만 top-3 중 관련 chunk가 1개뿐이면 context precision은 낮다. 만약 chunk #12에 “카드사는 35영업일, 계좌 환불은 12영업일”이 있었는데 답변이 카드만 말하면 context recall은 충분해도 answer relevance가 부분 실패일 수 있다.

3.14 선택 심화: 가상 진단 수치로 평가 도구의 경계 읽기

섹션 제목: “3.14 선택 심화: 가상 진단 수치로 평가 도구의 경계 읽기”

아래 숫자는 하나의 가상 평가 suite에서 문제를 드러내기 위한 관측 예시다. 80:20, 99:1, 100개, N=3, 62% 중 어느 것도 모든 과업에 적용하는 지표 교체선이나 release 거부 규칙이 아니다. 실제 결정은 클래스 비용, 목표 precision/recall, baseline 분산, paired disagreement, 사람 검수 일치도, 제품 위험으로 보정한다.

평가 기법가상 관측 예이 관측이 묻는 질문다음 확인
Accuracy80:20 데이터에서 다수 class 예측만으로 80%소수 class 실패를 평균이 숨기는가confusion matrix, class별 precision/recall, F1, PR curve
ROC-AUC99:1 데이터에서 ROC-AUC는 높지만 positive precision이 낮음낮은 false-positive rate도 절대 건수로는 큰가PR-AUC와 실제 operating threshold의 precision·recall
BLEU/ROUGE의미는 같은 paraphrase인데 n-gram 점수가 낮음표면 일치가 과업 성공을 대변하는가semantic·task checker와 사람 표본 검수를 함께 비교
LLM-as-judge전문 slice 100개에서 사람과 62%만 일치judge rubric·domain coverage가 부족한가disagreement 전수 검수, judge calibration, deterministic check
Gold set100개 smoke set의 모델 차이 CI(Confidence Interval, 신뢰구간)가 넓음단일 점수보다 paired 차이의 불확실성이 큰가목표 margin·power와 discordant pair로 증거량 설계
Self-consistencyN=3 반복에서 같은 case 판정이 자주 뒤집힘평균 점수보다 judge·sampling variance가 큰가seed·order·judge를 분리하고 비용 대비 반복 수를 다시 정함
Static benchmarkpublic 점수는 높지만 최근 도메인 실패가 남음contamination·saturation·domain mismatch가 있는가versioned private holdout과 시간·위험 slice를 추가

예를 들어 사람 일치도 62%는 “LLM judge는 전문 영역에서 늘 60%대”라는 사실 주장이 아니다. 이 가상 suite에서는 불일치 38건의 유형을 먼저 읽고, rubric 누락인지 judge 능력인지 사람 label 불일치인지 분리하라는 신호다. 같은 방식으로 gold 100개와 N=3도 빠른 진단 구성일 뿐, 충분한 증거량은 다음 절의 신뢰구간과 power 설계로 정한다.

Gold dataset 점수 비교에서는 먼저 무엇을 주장하려는지 분리해야 한다. “새 모델이 더 좋은가”는 우월성(superiority) 질문이고, “비용은 싸지만 허용 한계보다 나쁘지는 않은가”는 비열등성(non-inferiority) 질문이다. 차이가 유의하지 않다는 결과만으로 두 모델이 동등하거나 비열등하다고 결론 낼 수 없다.

단일 비율의 정밀도와 paired difference

섹션 제목: “단일 비율의 정밀도와 paired difference”
  • Wilson score interval: 한 모델의 pass / 전체처럼 단일 이항 비율의 신뢰구간을 만든다. 표본 수 246개·385개 같은 숫자는 목표 반폭을 위한 정밀도 anchor다. 두 모델 차이의 검정력은 말해 주지 않는다.
  • Paired difference: 같은 질문 i에서 d_i = pass_B(i) - pass_A(i)를 만들고, 평균 delta = mean(d_i) = p_B - p_A와 신뢰구간을 구한다. 샘플 자체를 단위로 복원추출하는 paired bootstrap이나 paired binary difference용 score interval을 쓸 수 있다. A와 B 결과를 따로 섞어 bootstrap하면 pairing을 잃는다.
  • McNemar’s test: binary pass/fail에서 A만 passB만 pass라는 discordant pair가 대칭인지 검정한다 (McNemar 1947). 둘 다 pass·둘 다 fail인 pair는 두 모델의 차이를 만들지 않는다. 표준 McNemar 검정은 delta = 0이라는 우월성 측의 영가설을 다루므로, 그 p-value를 비열등성 증명으로 바꾸어 읽으면 안 된다.
  • Welch’s t-test: 서로 독립인 두 연속형 표본의 평균 비교에 쓰는 방법이다. 같은 gold case를 두 모델에 준 binary 결과에는 paired 설계를 우선한다.

비열등성은 허용 가능한 열화를 먼저 정한다

섹션 제목: “비열등성은 허용 가능한 열화를 먼저 정한다”

비용·지연 이득 때문에 새 모델 B가 기존 A보다 조금 낮아도 채택할 수 있다면, 평가 전에 **비열등성 한계 Delta**를 정한다. 예를 들어 Delta = 5%p는 “B의 pass rate가 A보다 최대 5%p 낮은 것까지 허용한다”는 제품·위험 결정이지, 결과를 본 뒤 통계 담당자가 고르는 값이 아니다. FDA 비열등성 지침도 margin 선택과 검정 가설을 사전에 정하는 원칙을 강조하며, paired binary endpoint에는 paired 차이용 비열등성 방법이 필요하다 (Liu et al. 2002).

delta = p_B - p_A
H0: delta <= -Delta # 허용 한계 이상으로 열등하다
H1: delta > -Delta # 비열등하다
판정: delta의 신뢰구간 하한이 -Delta보다 커야 비열등성을 입증

정규근사에서 단측 유의수준 alpha=0.025인 비열등성 검정의 97.5% 하한은 z=1.96을 쓰며, 양측 95% 신뢰구간의 하한과 같은 값이다. 둘은 서로 다른 임계값 선택지가 아니라 같은 판정을 표현하는 두 방식이다. 유의수준을 정하는 일과 구간 구성법을 고르는 일은 분리한다. Discordant count가 작을 때 exact·paired score·paired bootstrap 중 무엇을 쓸지, bootstrap이면 pair 단위로 어떻게 재표집할지를 분석 전에 고정한다. “차이 없음”을 보이려면 양쪽 한계를 모두 넘지 않는 equivalence 설계가 필요하고, 한쪽 열화만 제한하는 non-inferiority와는 목적이 다르다.

Paired power는 discordant pair를 가정한다

섹션 제목: “Paired power는 discordant pair를 가정한다”

Paired 비교의 표본 수에는 목표 차이·Delta·유의수준·목표 power뿐 아니라 예상 discordance가 들어간다. 같은 p_A=80%, p_B=75%라도 아래 두 데이터는 필요한 표본 수가 같지 않다.

A만 pass B만 pass discordant 합
두 모델 결과가 강하게 비슷함 7.5% 2.5% 10%
두 모델이 자주 엇갈림 22.5% 17.5% 40%
두 경우 모두 p_B - p_A = -5%p

Paired difference의 설명용 분산은 대략 (discordant 비율 - delta^2) / n에 비례한다. 두 번째 설계는 같은 marginal 차이여도 엇갈리는 pair가 많아 구간이 더 넓다. 따라서 과거 regression log나 pilot set에서 A만 pass, B만 pass 비율을 추정하고, 최종 분석과 같은 McNemar·paired score·paired bootstrap 계열 방법으로 power를 시뮬레이션하거나 계산해야 한다. “5%p니까 항상 약 400개”라는 고정 규칙은 없다.

Regression eval 의사결정 예시:

Gold set 200개에서 기존 모델 A와 새 모델 B 비교
둘 다 맞음: 145
둘 다 틀림: 20
A만 맞음: 22
B만 맞음: 13

단순 pass rate는 A 167/200=83.5%, B 158/200=79%로 B가 4.5%p 낮다. 하지만 paired 관점에서 중요한 것은 A만 맞음 22 vs B만 맞음 13이다. 우월성 차이가 통계적으로 불확실하다는 이유만으로 전체 교체나 canary를 자동 승인하지 않는다. 먼저 사전 비열등성 기준을 적용하고, 미확정이면 표본을 늘리거나 high-risk 경로를 제외한 제한된 canary로 추가 증거를 모을지 별도로 결정한다. 반대로 p-value가 애매해도 B만 틀린 13개가 결제·보안·법무에 몰리면 배포를 막는다. 통계는 결정을 자동화하는 장치가 아니라, noise와 실제 회귀를 구분하는 안전장치다.

이 표의 discordant pair는 22 + 13 = 35개, 즉 35/200 = 17.5%다. 여기서 delta = -4.5%p이고, 설명용 paired 정규 근사 95% CI는 약 [-10.3%p, +1.3%p]다. Exact McNemar 양측 p-value도 약 0.18이라 delta = 0을 기각하지 못한다. 사전 Delta = 5%p였다면 구간 하한 -10.3%p-5%p를 넘지 못하므로 비열등성을 입증하지 못해 미확정이다. 실제 판정에는 작은 표본에서 coverage가 더 나은 paired score interval이나 사전 정의한 paired bootstrap을 사용한다 (Newcombe 1998).

반례 — 유의하지 않음은 동등함이 아니다: p-value가 0.47처럼 커도 데이터가 “두 모델이 같다”고 말한 것은 아니다. 검정력이 낮거나 구간이 넓어 B가 의미 있게 나쁨B가 조금 좋음을 둘 다 배제하지 못했을 수 있다. 위 예시가 바로 0을 포함해 우월성 차이는 미확정이면서, 동시에 -5%p 아래도 포함해 비열등성도 미확정인 경우다. 올바른 결론은 “동등하다”가 아니라 “현재 표본으로는 차이도 비열등성도 확정하지 못했다”다.

비용을 계산하려면 먼저 한 호출이 무엇을 입력받는지 고정해야 한다. Pairwise judge의 한 호출은 질문과 답변 A + 답변 B를 함께 받아 A 승 / B 승 / tie를 한 번 반환한다. A와 B를 각각 생성하는 후보 모델 호출은 judge 호출과 다른 계약이므로 별도 비용 항목이다.

호출 종류한 호출의 계약gold 200개 기준 호출 수
후보 A/B 생성질문 1개 → 한 모델의 답변 1개모델별 200회, 두 모델 합계 400회
Pairwise judge질문 + 답변 A + 답변 B → 한 비교기본 200회
Order swap judge같은 pair의 A/B 순서를 뒤집어 재비교기본 200회 + swap 200회 = 합계 400회
Pointwise LLM grade질문 + 답변 1개 + rubric → pass/fail모델별 200회, 두 모델 합계 400회 추가
3-judge ensemble각 order를 judge 3개가 독립 비교swap 포함 200 × 2 × 3 = 1,200
judge_calls = sample 수 N × order 수 O × judge 수 J
judge_cost = judge_calls × (입력 token × 입력 단가 + 출력 token × 출력 단가)
회귀 1회 (gold 200개, judge 비용만):
- 계산용 가정 단가: 입력 $2.5/1M tokens, 출력 $10/1M tokens
- 한 pairwise 호출 평균 입력: 2k tokens, 응답: 500 tokens
- 호출 1회: $0.005 + $0.005 = $0.01
- 기본 pairwise: 200 × 1 order × 1 judge = 200 호출 = ~$2
- swap test 포함: 200 × 2 orders × 1 judge = 400 호출 = ~$4
- swap 회귀를 일주일 5회: ~$20/주
- swap + judge 3개 ensemble: 1,200 호출/회 = ~$12, 주 5회면 ~$60/주

위 judge 비용에는 후보 A/B 답변 생성 400회, 사람의 표본 검수 비용, 재시도 비용이 들어 있지 않다. 후보 생성비는 모델마다 입출력 길이와 단가가 다르므로 C_A + C_B로 따로 계산한 뒤 judge 비용과 합친다. Binary pass/fail을 사람이 사전 검수한 gold assertion과 deterministic checker로 만들면 추가 LLM judge 호출은 0회다. 반대로 자유 텍스트라 pointwise LLM grader가 각 모델 답변을 따로 채점해야 하면 200 × 2 = 400회가 별도로 추가된다. 위와 같은 호출당 $0.01 가정이면 약 $4 추가이며, 실제 비용은 pointwise 입력·출력 길이로 다시 계산한다. Swap pairwise 400회까지 함께 쓰면 judge 호출은 총 800회, 같은 단순 가정에서는 약 $8다. 초반 탐색은 단일 order·단일 judge로 빠르게 돌리고, 배포 직전·고위험 도메인·position flip이 큰 구간에서 swap과 ensemble을 켜는 편이 비용 대비 낫다. 운영자에게 의미 있는 자릿수이므로 budget alert는 필수다.

3.17 평가의 일반 매핑 (Transferable Pattern)

섹션 제목: “3.17 평가의 일반 매핑 (Transferable Pattern)”

평가의 핵심 — “측정 + 회귀 검증 + drift 모니터링” — 은 다른 시스템에도 동일 패턴.

평가 구성요소일반 시스템 매핑
Gold datasetregression test, golden output
LLM-as-judgecode review bot, lint, automated PR check
A/B testfeature flag rollout, canary deployment
Drift detectionobservability metric anomaly, SLO violation alert
Confusion matrixerror categorization, root cause matrix
ROC/PR curveprecision-recall trade-off (검색·anti-spam·IDS)
Statistical significanceA/B 통계 (전통 웹 A/B와 같음)

일반 공식: “측정 → 비교 → 통계적 판정 → 회귀 검증”의 4단계가 ML·웹·인프라·검색 모든 시스템에 공통이다. ML 평가가 특별한 게 아니라 품질 측정 시스템의 한 사례.

운영 시나리오 — LLM 버전 교체 회귀 검증 (예시)

섹션 제목: “운영 시나리오 — LLM 버전 교체 회귀 검증 (예시)”

아래 예시는 이 문서의 지표가 실제 의사결정에서 어떻게 합쳐지는지 보여주는 가상 시나리오다. 모델명과 가격 배율은 작성 시점 기준 예시이며, 핵심은 “새 모델이 이겼는가”가 아니라 품질 차이의 불확실성·bias 방어·비용 이득·고위험 실패 여부를 함께 보는 것이다.

상황: 사내 챗봇 GPT-4o → GPT-4o-mini 교체 검토 (비용 17× ↓)
도구:
- Gold dataset: 200 한국어 Q&A (3개월 누적)
- Binary pass/fail: 사람이 사전 검수한 gold assertion + deterministic checker
- LLM-as-judge: 이 가상 실험에서는 Claude Sonnet 계열 cross-family judge를 후보로 선택하고 사람 calibration으로 적합성 확인
- Promptfoo dashboard
회귀 검증 흐름:
1. 같은 200개 query에 두 모델 응답 생성
2. gold assertion으로 모델별 pass/fail 판정 (추가 LLM 호출 0회)
3. judge로 pairwise 비교 (swap test 포함)
4. 사전 기준: 비열등성 한계 Delta=5%p, paired 95% CI
5. 사람 검수: 고위험 패배 전수 + 나머지 층별 무작위 표본 30~40개
결과 (가상):
- pairwise 선호: GPT-4o-mini 우위 38%, GPT-4o 우위 42%, tie 20%
- deterministic pass/fail: 둘 다 pass 145, 둘 다 fail 20, 기존만 pass 22, mini만 pass 13
- pass rate 차이 delta=-4.5%p, 설명용 paired 95% CI=[-10.3%p, +1.3%p]
- CI 하한이 -Delta=-5%p보다 작음 → 비열등성 미확정, 전체 교체 보류
- 비용 17× ↓ → 표본 확대·제한된 canary를 검토할 근거이지 동등성 근거는 아님
대안 비선택: 사람 검수 100% (비용 多), benchmark만 (도메인 mismatch).

판정은 다음 순서로 읽는다.

  1. 데이터 적합성과 증거량: gold dataset이 최근 3개월 한국어 Q&A에서 왔으므로 public benchmark보다 도메인 적합성이 높다. 이 예에서 증거가 부족한 직접 근거는 “200개라서”가 아니라 discordant pair가 35/200이고, 그 결과 paired CI 하한이 -10.3%p까지 열려 사전 한계 -5%p를 넘지 못했다는 점이다.
  2. Judge bias 방어: 이 가상 실험은 상관된 self-enhancement bias를 줄일 후보로 cross-family judge를 택했지만, 가족이 다르다는 사실만으로 승인하지 않는다. 사람 calibration과 rubric 준수도를 확인하고, pairwise 비교는 swap test로 position bias를 측정한다.
  3. 통계 판정: 38%·42%·tie 20%는 judge 선호의 기술 통계이고, 모델별 pass rate 비열등성을 직접 증명하지 않는다. Paired pass/fail 차이의 CI 하한이 사전 한계를 넘지 못했으므로 정확한 결론은 “비열등성 미확정”이다. “유의한 열화가 보이지 않는다”도 교체 승인 문장으로 쓰지 않는다.
  4. 고위험 실패 검토: 기존 모델 우위 42%는 mini 패배 84개다. 먼저 결제·보안·법무 같은 high-risk 패배를 전수 확인한다. 나머지는 risk category별 층을 유지한 채 각 층에서 무작위로 뽑아 합계 30~40개를 검수한다. 어떤 층에서 체계적 오류가 발견되면 그 층의 표본을 확대하고, 같은 패턴이 이어지면 해당 층을 전수 검수한다.
  5. 비용·지연 판단: 비용이 17× 줄어도 품질 증거의 빈틈을 메우지는 않는다. High-risk 경로를 제외하고 rollback 기준을 둔 제한된 canary로 추가 데이터를 모을 수는 있지만, 전체 교체는 paired CI가 비열등성 기준을 통과한 뒤 판단한다. 운영 A/B에서 재문의율·CS escalation·사용자 만족도가 나빠지면 되돌린다.

§3.5 LLM-as-judge bias + §3.7 gold dataset + §3.15 통계 유의성 + §3.16 비용 산식 모두 적용된다.

  • LLM 모델 선택·교체 결정
  • LLM 응답 품질 회귀 검증
  • A/B 테스트 통계 분석
  • 데이터 큐레이션 품질 관리
  • bias·fairness audit
  • RAG 시스템 평가 (retrieval + generation)
  • ML 모델 모니터링 dashboard

엔지니어가 LLM 운영할 때 평가 직관이 다음에 도움 된다.

  • LLM 버전 교체 의사결정: GPT-4 → GPT-4o → Claude로 교체할 때 회귀 검증. gold dataset + LLM-as-judge로 자동화
  • Prompt 변경 회귀: prompt 수정 후 점수 떨어진 케이스 자동 식별
  • 모델 선택 협상: 벤치마크 점수만이 아닌 자기 도메인 gold set 점수가 진짜 기준
  • chatbot 품질 모니터링: drift 감지 → 사람 검수 트리거 → 데이터 보강 → 재학습 루프
  • bias audit: 사용자 그룹별 답변 품질 비교, 차별 위험 감지
개념 A개념 B차이점
AccuracyF1전체 vs precision·recall 조화. imbalance에서는 F1
PrecisionRecall양성 예측 정확 vs 양성 잡아내기. trade-off 관계
ROC-AUCPR-AUCbalance 데이터 vs imbalance에서 PR이 더 정확
PerplexityDownstream tasknext-token 예측 능력 vs 실제 작업 능력
BLEUBERTScoren-gram 일치 vs 임베딩 의미 거리
LLM-as-judge사람 평가특정 benchmark에서는 높은 일치도, 자체 calibration 필요
MMLULiveBench정적 벤치 (contamination 위험) vs 매월 갱신
Demographic parityEqualized odds결과 분포 같음 vs 오류율 같음
Gold datasetProduction traffic정제된 회귀 검증 vs 실 사용자 검증

7. 체크리스트 체크

  • Accuracy의 함정과 imbalanced data에서 F1·PR-AUC가 더 정확한 이유를 설명할 수 있다
  • LLM-as-judge의 4가지 bias(position, verbosity, self-enhancement, limited reasoning)를 말할 수 있다
  • MMLU 같은 정적 벤치마크의 contamination 함정과 LiveBench·Arena가 대응책인 이유를 설명할 수 있다
  • Gold dataset + regression eval이 LLM 운영의 핵심 도구인 이유를 설명할 수 있다
  • 단일 pass rate의 Wilson CI와 paired 모델 차이의 CI·McNemar 검정을 구분하고, 비열등성 한계를 사전에 정할 수 있다
  • RAG 평가에서 retrieval quality, faithfulness, answer relevance, context precision/recall을 구분할 수 있다
  • Demographic parity와 equalized odds의 차이를 설명할 수 있다
  • Data leakage의 3종(train/test split, target leakage, temporal)을 식별할 수 있다
  • 분류 평가: confusion matrix, ROC-AUC, PR-AUC, calibration plot, Brier score
  • LLM 평가: perplexity, BLEU, ROUGE, METEOR, BERTScore, BLEURT
  • LLM-as-judge: MT-Bench, AlpacaEval, Arena-Hard, G-Eval, Prometheus
  • 벤치마크: MMLU, HumanEval, GSM8K, MATH, BBH, IFEval, LiveBench, LMSYS Arena, SWE-Bench
  • 운영 도구: Promptfoo, Braintrust, LangSmith, Langfuse, Ragas, TruLens, ARES
  • 데이터 품질: Cohen’s kappa, Fleiss’ kappa, Krippendorff’s alpha
  • Bias·Fairness: Fairlearn, AIF360, BOLD, StereoSet, BBQ
  • RAG 평가: Ragas (faithfulness/relevance), DeepEval, ARES

분류 metric 직접 계산 체크

  • sklearn `classification_report`로 imbalanced 데이터(예: 95:5) 분류 모델의 precision/recall/F1을 출력. accuracy만 보면 좋아 보이지만 minority class recall이 낮은지 확인
  • `roc_auc_score`와 `average_precision_score`(PR-AUC)를 같은 데이터에 비교. PR-AUC가 더 잘 변별하는지

LLM-as-judge 실험 체크

  • 같은 질문에 GPT-4 응답과 Claude 응답을 만들고, 또 다른 LLM(예: o4-mini)에 비교 평가시킴. 응답 순서를 뒤집어 다시 평가 — position bias 체감
  • 짧은 정답 vs 장황한 정답을 평가 — verbosity bias 체감

Gold dataset 만들기 체크

  • 자기 도메인의 질문 50개에 정답을 직접 써본다 (gold set). promptfoo로 다른 LLM들에 같은 질문을 던지고 점수 비교. promptfoo 실행 후 dashboard에서 회귀 케이스 식별
  • prompt를 살짝 수정한 뒤 같은 gold set에서 점수 변화 측정 — regression eval 흐름 체험
  • Ragas 또는 TruLens로 RAG 시스템에 faithfulness/relevance/context precision 측정 — 어느 metric이 가장 약한지 식별 → 그게 개선 우선순위
  • 자기 LLM 챗봇에 사용자 그룹별(성별·연령·언어) 같은 질문을 던지고 답변 품질 비교 — 차별 시그널 감지
  • accuracy 좋은데 minority class 망가짐 → class_weight 조정, threshold 재조정, F1·PR-AUC 사용
  • LLM-as-judge 점수가 사람 평가와 안 맞음 → 불일치 slice를 분류하고 prompt·rubric을 고친 뒤, calibration 결과에 따라 judge 변경·deterministic check·다중 judge·사람 검수를 선택
  • RAG retrieval은 좋은데 답변 품질 낮음 → faithfulness가 약함. reranker 도입 or 답변 prompt에 “출처에서만 답하라” 강조
  1. 분류는 accuracy·precision·recall·F1·ROC/PR-AUC, 회귀는 MSE·MAE·R², LLM은 perplexity·BLEU·BERTScore·LLM-as-judge가 표준이다.
  2. Accuracy의 함정·LLM-as-judge bias·benchmark contamination 등 silent failure가 평가의 흔한 함정이다.
  3. Gold dataset 회귀에서는 단일 비율 CI와 paired 차이를 분리하고, 모델 교체는 사전 비열등성 한계와 paired CI로 판정한다.
  4. RAG는 retrieval 품질·faithfulness·answer relevance·context precision을 별도 측정해야 한다 (Ragas 표준).
  5. 데이터 품질(label noise, leakage, bias)이 평가의 절반 — 좋은 평가는 좋은 데이터에서 시작.

최종 수정: 2026-07-14