Accuracy
식: (TP+TN) / 전체 / 직관: 전체 맞은 비율
약점: imbalance에서 무력분류: Layer 11 - AI 기초 & 머신러닝 | 선수지식: L11-20 (고전 ML), L11-30 (ML 패러다임)
모델 평가는 모델이 어떤 입력에서 어떤 품질로 동작하는지를 반복 측정하는 체계이고, 데이터 품질은 그 측정에 쓰는 학습·평가 데이터가 정확하고 대표적인지 확인하는 기준이다. 둘은 분리되지 않는다. 같은 모델도 평가셋이 낡았거나 지표가 문제와 맞지 않으면 좋아 보이고, 같은 평가 지표도 데이터가 편향되면 운영 실패를 숨긴다.
이 문서는 “지표 이름 외우기”보다 측정하려는 실패가 무엇인지 먼저 정하고, 그 실패를 드러내는 지표·gold dataset·통계 판정을 고르는 방법을 목표로 한다.
평가는 보통 네 질문으로 시작한다.
평가는 단일 지표가 아니라 “선행 도구의 정량적 한계 → 새 도구”의 연쇄로 확장돼 왔다. 본 토픽의 PR-AUC·LLM-as-judge·gold dataset은 각각 직전 도구가 silent하게 망가지는 지점을 메우는 메커니즘이다.
이 토픽이 사라지면 무엇이 깨지나: LLM 버전 교체 시 한국어 도메인만 망가져도 MMLU·HumanEval 변화 없이 production에 silent regression이 들어간다. judge·gold set 없이는 “비용 17× 싼 mini 모델로 교체해도 안전한가”라는 운영 결정을 객관적으로 부정도 인정도 못 한다.
분류 평가는 **confusion matrix(혼동 행렬)**에서 시작한다. 행렬은 예측과 실제 정답을 네 칸으로 나누고, 각 칸이 어떤 실패를 뜻하는지 먼저 보게 해준다.
실제 양성 실제 음성예측 양성 TP FP예측 음성 FN TN작은 예시로 감을 잡자. 사기 탐지 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도 함께 본다.
식: (TP+TN) / 전체 / 직관: 전체 맞은 비율
약점: imbalance에서 무력식: TP / (TP+FP) / 직관: "양성이라 한 것 중 진짜 양성"
약점: recall과 trade-off식: TP / (TP+FN) / 직관: "진짜 양성 중 잡아낸 것"
약점: precision과 trade-off식: 2·P·R / (P+R) / 직관: precision·recall 조화 평균
약점: 둘의 가중치 같다고 가정식: 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 이동을 한 장의 곡선으로 보는 도구다.
FP / (FP+TN))를 그린다.왜 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 |
| R² | 설명된 분산 비율 | [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) = 1MAE(B) = 2, MSE(B) = 16두 모델의 평균 절대 오차 차이는 1시간이지만, MSE는 큰 오차 하나를 훨씬 강하게 벌준다. 한 번 크게 틀리면 사용자 경험이 치명적인 배송 ETA·가격 예측이면 MSE나 상위 percentile 오차를 같이 본다. 반대로 센서 노이즈처럼 outlier가 불가피하면 MAE가 더 안정적일 수 있다. MAPE는 “10분 오차가 원래 100분짜리 예측에서 10%인지, 5분짜리 예측에서 200%인지”를 볼 때 유용하지만 실제값이 0에 가까우면 폭발한다.
분류·회귀는 정답과 예측을 비교하기 쉽다. LLM 출력은 자유 텍스트라 같은 의미를 여러 표현으로 쓸 수 있고, 답변의 사실성·도움됨·안전성·형식 준수도 분리해 봐야 한다. 그래서 LLM 평가는 “자동 지표로 빠르게 걸러내고, 자유 텍스트 품질은 judge·사람 검수·gold dataset으로 보강”하는 구조가 된다.
exp(평균 cross-entropy)다. 다음 토큰을 얼마나 덜 놀라워하게 예측하는지 보는 값이며 낮을수록 좋다. 단 next-token prediction 능력만 보므로 “사용자 질문에 유용하게 답하는가”와는 약한 상관만 가진다.경계는 분명하다. BLEU/ROUGE가 낮아도 사람이 보기에 좋은 답일 수 있고, BERTScore가 높아도 hallucination이 있을 수 있다. 자동 지표는 “명백히 나쁜 후보를 싸게 걸러내는 1차 필터”로 두고, 제품 품질 판정은 gold dataset과 judge/사람 평가로 옮겨야 한다.
LLM-as-judge는 강한 LLM이 다른 LLM의 출력을 평가하게 하는 방식이다. 자동 지표가 n-gram·임베딩 수준에서 막히는 자유 텍스트 평가를 다루기 위해 등장했다. 보통 단일 답변 점수, 두 답변 pairwise 비교, rubric 기반 다축 채점으로 쓴다.
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) |
| HumanEval | Python 함수 작성, 164 문제 | 작은 셋 → overfitting, contamination 위험 |
| MBPP | Python 기본 함수 (974) | HumanEval보다 큼 |
| GSM8K | 초등 수학 | 학습 데이터 contamination 보고됨 (Schaeffer 2023) |
| MATH-500 / AIME 24/25 | 수학 reasoning | reasoning 모델 평가 표준 |
| GPQA Diamond (198Q) | PhD-level 과학·수학 | frontier 모델 변별 |
| MMLU-Pro | MMLU 후속 (10지선다, reasoning) | MMLU의 contamination·saturation 대응 |
| HELM (Capabilities/Safety/Lite) | 종합 다축 평가 | metric 다양성·비용이 한계 |
| LMSYS Arena | 사람 직접 비교 (Bradley-Terry) | “Arena Score 100 차이 ≈ 64% 승률” |
| Arena-Hard / Auto v2 | 500 hard prompt, style control judge | MT-Bench 후속 |
| MT-Bench | LLM-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 평가 |
| τ-bench | tool agent multi-turn | 에이전트 운영 시뮬레이션 |
Data contamination은 벤치마크 데이터가 학습 데이터에 새어 들어가 모델이 문제를 푼 것이 아니라 외운 상태를 말한다. 점수는 올라가지만 새로운 문제 해결 능력은 그만큼 높아졌다고 볼 수 없다. Canary string 같은 검증 기법, LiveBench처럼 정기 갱신되는 벤치마크, Arena-Hard처럼 더 어려운 prompt와 style control을 쓰는 평가가 이 문제에 대응한다.
Benchmark를 읽는 결정 기준:
운영자에게 가장 중요한 평가 도구는 gold dataset과 regression eval이다.
작은 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):
A만 pass, B만 pass가 얼마나 나올지와 사전 비열등성 한계까지 넣어 paired power를 별도로 계산해야 한다. 250개 미만이면 무조건 실패라는 규칙도 아니며, 먼저 목표가 단일 비율 정밀도인지 모델 차이 판정인지 구분한다.20개, kappa < 0.6은 빠른 표본 점검 예이지 산업 공통 SLA나 자동 spec 재작성 규칙이 아니다. 위험도·class 분포·허용 오차에 맞춰 표본 수와 후속 조치를 정한다.좋은 평가는 좋은 데이터에서 출발한다. 데이터 품질은 “정답이 맞는가”만이 아니라, 평가하려는 운영 상황을 데이터가 대표하는가까지 포함한다.
<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이 실제로 공유되는지 확인한다.
운영에서 자주 만나는 실패는 모델 구조보다 데이터 품질에서 먼저 온다.
실패 신호는 명령어보다 패턴으로 기억하는 편이 낫다. validation 점수가 비현실적으로 높으면 leakage를, 시간이 지날수록 fail case 카테고리가 바뀌면 freshness 붕괴를, 특정 annotator가 만든 샘플에서만 모델 순위가 달라지면 annotator bias를 먼저 의심한다.
Bias와 fairness는 “평균 성능이 높다”와 “모든 사용자에게 안전하다”가 다르다는 문제에서 나온다. 전체 accuracy가 좋아도 특정 성별·지역·언어·장애 유형에서 FN이나 FP가 높으면 제품 리스크는 남는다.
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는 최종 운영 검증이다.
운영자가 reasoning 모델·에이전트를 도입할 때 반드시 알아야 할 평가 영역.
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과 연결해서 읽는다.
에이전트 평가는 “답을 맞혔는가”보다 “도구를 올바른 순서로 불렀는가”가 중요하다. function calling 자체가 문제면 BFCL을 먼저 보고, 여러 턴 동안 상태를 유지하고 도구 결과를 반영해야 하면 tau-bench류를 본다. 실제 코드 변경 능력은 SWE-Bench처럼 patch가 테스트를 통과하는지로 보는 편이 더 직접적이다.
운영 reproducibility의 핵심.
**RAG(Retrieval-Augmented Generation)**는 “문서를 검색한 뒤 그 근거로 답변을 생성”하는 구조다. 그래서 일반 LLM 답변 품질만 보면 부족하다. 검색이 틀렸는지, 검색은 맞았는데 생성이 틀렸는지, 답변은 맞지만 출처가 빈약한지 분리해야 한다.
작은 예시:
질문: "환불 처리 기간은 며칠인가?"정답 근거: 환불 정책 문서 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가 부분 실패일 수 있다.
아래 숫자는 하나의 가상 평가 suite에서 문제를 드러내기 위한 관측 예시다. 80:20, 99:1, 100개, N=3, 62% 중 어느 것도 모든 과업에 적용하는 지표 교체선이나 release 거부 규칙이 아니다. 실제 결정은 클래스 비용, 목표 precision/recall, baseline 분산, paired disagreement, 사람 검수 일치도, 제품 위험으로 보정한다.
| 평가 기법 | 가상 관측 예 | 이 관측이 묻는 질문 | 다음 확인 |
|---|---|---|---|
| Accuracy | 80:20 데이터에서 다수 class 예측만으로 80% | 소수 class 실패를 평균이 숨기는가 | confusion matrix, class별 precision/recall, F1, PR curve |
| ROC-AUC | 99: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 set | 100개 smoke set의 모델 차이 CI(Confidence Interval, 신뢰구간)가 넓음 | 단일 점수보다 paired 차이의 불확실성이 큰가 | 목표 margin·power와 discordant pair로 증거량 설계 |
| Self-consistency | N=3 반복에서 같은 case 판정이 자주 뒤집힘 | 평균 점수보다 judge·sampling variance가 큰가 | seed·order·judge를 분리하고 비용 대비 반복 수를 다시 정함 |
| Static benchmark | public 점수는 높지만 최근 도메인 실패가 남음 | 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) 질문이다. 차이가 유의하지 않다는 결과만으로 두 모델이 동등하거나 비열등하다고 결론 낼 수 없다.
pass / 전체처럼 단일 이항 비율의 신뢰구간을 만든다. 표본 수 246개·385개 같은 숫자는 목표 반폭을 위한 정밀도 anchor다. 두 모델 차이의 검정력은 말해 주지 않는다.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을 잃는다.A만 pass와 B만 pass라는 discordant pair가 대칭인지 검정한다 (McNemar 1947). 둘 다 pass·둘 다 fail인 pair는 두 모델의 차이를 만들지 않는다. 표준 McNemar 검정은 delta = 0이라는 우월성 측의 영가설을 다루므로, 그 p-value를 비열등성 증명으로 바꾸어 읽으면 안 된다.비용·지연 이득 때문에 새 모델 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_AH0: 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 비교의 표본 수에는 목표 차이·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%pPaired 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둘 다 틀림: 20A만 맞음: 22B만 맞음: 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 수 Jjudge_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는 필수다.
평가의 핵심 — “측정 + 회귀 검증 + drift 모니터링” — 은 다른 시스템에도 동일 패턴.
| 평가 구성요소 | 일반 시스템 매핑 |
|---|---|
| Gold dataset | regression test, golden output |
| LLM-as-judge | code review bot, lint, automated PR check |
| A/B test | feature flag rollout, canary deployment |
| Drift detection | observability metric anomaly, SLO violation alert |
| Confusion matrix | error categorization, root cause matrix |
| ROC/PR curve | precision-recall trade-off (검색·anti-spam·IDS) |
| Statistical significance | A/B 통계 (전통 웹 A/B와 같음) |
일반 공식: “측정 → 비교 → 통계적 판정 → 회귀 검증”의 4단계가 ML·웹·인프라·검색 모든 시스템에 공통이다. ML 평가가 특별한 게 아니라 품질 측정 시스템의 한 사례.
아래 예시는 이 문서의 지표가 실제 의사결정에서 어떻게 합쳐지는지 보여주는 가상 시나리오다. 모델명과 가격 배율은 작성 시점 기준 예시이며, 핵심은 “새 모델이 이겼는가”가 아니라 품질 차이의 불확실성·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).판정은 다음 순서로 읽는다.
35/200이고, 그 결과 paired CI 하한이 -10.3%p까지 열려 사전 한계 -5%p를 넘지 못했다는 점이다.§3.5 LLM-as-judge bias + §3.7 gold dataset + §3.15 통계 유의성 + §3.16 비용 산식 모두 적용된다.
엔지니어가 LLM 운영할 때 평가 직관이 다음에 도움 된다.
| 개념 A | 개념 B | 차이점 |
|---|---|---|
| Accuracy | F1 | 전체 vs precision·recall 조화. imbalance에서는 F1 |
| Precision | Recall | 양성 예측 정확 vs 양성 잡아내기. trade-off 관계 |
| ROC-AUC | PR-AUC | balance 데이터 vs imbalance에서 PR이 더 정확 |
| Perplexity | Downstream task | next-token 예측 능력 vs 실제 작업 능력 |
| BLEU | BERTScore | n-gram 일치 vs 임베딩 의미 거리 |
| LLM-as-judge | 사람 평가 | 특정 benchmark에서는 높은 일치도, 자체 calibration 필요 |
| MMLU | LiveBench | 정적 벤치 (contamination 위험) vs 매월 갱신 |
| Demographic parity | Equalized odds | 결과 분포 같음 vs 오류율 같음 |
| Gold dataset | Production traffic | 정제된 회귀 검증 vs 실 사용자 검증 |
최종 수정: 2026-07-14