02-평가-세트-설계

02. 평가 세트 설계

최소 구성

평가 세트는 다음을 갖춰야 한다.

요소	설명	최소 권장
입력 케이스	실제 사용에서 나올 입력	30개
정답(label)	사람이 검증한 기대 출력 또는 채점 기준	입력별 1개
슬라이스 태그	카테고리·길이·난이도	케이스별 1~3개
메트릭 정의	무엇을 어떻게 셀지	2~4개
회귀 기준	어떤 변화가 “회귀”인가	임계값 명시

30이 마법의 숫자는 아니다. 일반적인 분류 작업에서 의미 있는 차이를 잡을 수 있는 최소 규모다. 비싼 작업(법률·의료)은 더 적게, 캐주얼 작업은 더 많이.

입력은 어디서 오는가

• 운영 로그 (가장 좋음) — 실제 사용자 입력
• 고객지원 티켓 — 도메인 적합도 높음
• 합성 데이터 — 에지 케이스 보강용. 전체 평가의 절반을 넘기지 마라.
• 적대적 입력 — 인젝션, 악성, 다국어

메트릭의 4축

운영 평가는 단일 점수로 환원하지 않는다.

1. 정확도(Accuracy / F1) — 정답률
2. 형식 적합률(Parse rate) — 출력이 스키마를 통과하는 비율
3. 비용(Cost) — 평균 토큰 / 호출당 원가
4. 지연(Latency) — p50, p95

프롬프트 변경이 (1)을 1% 올렸지만 (3)을 2배로 늘렸다면 진짜 개선이 아닐 수 있다. 4축 표를 항상 함께 본다.

슬라이스 분리 — “평균의 함정” 회피

전체 평균은 자주 거짓말을 한다. 다음 슬라이스로 분리해 보라.

• 카테고리별 (billing / bug / abuse…)
• 길이별 (짧음 / 중간 / 긺)
• 언어별 (한국어 / 영어 / 혼합)
• 난이도별 (사람이 라벨링)

흔한 패턴: 평균 정확도는 +2%인데, abuse 슬라이스만 -8%. 이는 운영 사고로 이어진다. CrossCodeEval 같은 학술 벤치마크가 가르치는 교훈이다.

라벨링 — LLM-as-a-judge

사람이 모든 출력을 채점하기 어렵다. LLM-as-a-judge(다른 호출이 채점)는 보조 수단으로 쓸 수 있지만 다음 조건을 지켜야 한다.

• 사람 라벨의 부분집합으로 judge의 신뢰도(agreement)를 미리 측정하라
• judge의 프롬프트도 별도로 버전 관리하라 — judge가 바뀌면 평가 결과가 흔들린다
• 같은 모델 패밀리로 채점하면 자기 편향이 생긴다 — 가능하면 다른 모델이 채점

Anti-pattern: 평가 대상 프롬프트와 judge 프롬프트가 같은 sub-agent. 자기 검증으로 published 처리 금지(CLAUDE.md §10, §6).

회귀 기준

변경 전후의 어떤 차이가 “회귀”인가? 예시 기준:

• 정확도 절대 -2% 이상 → 차단
• 어느 슬라이스든 -5% 이상 → 차단
• 형식 적합률 -1% 이상 → 차단
• 비용 +30% 이상 → 차단(승인 필요)
• 지연 p95 +50% 이상 → 차단

이 임계값은 팀과 도메인에 따라 다르다. 중요한 것은 명시되어 있다는 것 자체다.