지난 글에서 증류한 모델은 원본과 나란히 정답률로 재야 한다고 했는데, 그 "재는" 일이 생각보다 까다롭다. 모델 발표마다 따라붙는 벤치마크 표는 읽기 쉬워 보이지만, 그 숫자 하나에는 문항 선택, 채점 방식, 시도 횟수, 그리고 그 문항이 학습 데이터에 얼마나 새어 들어갔는지가 전부 뭉쳐 있다. 표를 그대로 믿고 모델을 고르면 실제 트래픽에서 예상과 다른 결과를 만난다.
점수가 무엇을 재는지부터
추론 벤치마크는 크게 네 갈래다. 각각이 재는 능력이 다르므로 우리 작업과 가까운 것을 봐야 한다.
| 갈래 | 재는 것 | 채점 | 실무 대응 작업 |
|---|---|---|---|
| 수학 경시 유형 | 다단계 기호 조작 | 최종 답 일치 | 수치 계산, 규칙 적용 |
| 코드 생성 | 명세를 코드로 옮기기 | 테스트 통과 | 스크립트 작성, 리팩터링 |
| 과학·전문 지식 | 지식 + 추론 결합 | 객관식 정답 | 도메인 질의 응답 |
| 에이전트 과제 | 도구 사용 + 장기 계획 | 목표 달성 여부 | 다단계 자동화 |
여기서 자주 벌어지는 일이 갈래를 넘겨 해석하는 것이다. 수학 벤치마크에서 앞선 모델이 우리 고객 문의 분류에서도 앞설 거라는 추론에는 근거가 없다. 실제로는 서로 다른 갈래 간 순위가 자주 뒤집힌다.
같은 숫자가 아니다 — 채점 조건
표에 적힌 숫자를 비교하기 전에 조건을 맞춰야 한다. 자주 어긋나는 것이 넷이다.
시도 횟수. pass@1은 한 번 뽑아서 맞은 비율이고, pass@k는 k번 중 하나라도 맞으면 정답으로 친다. 후자가 당연히 높다. 어떤 발표는 cons@64, 즉 64번 뽑아 다수결한 값을 싣는다. 이건 테스트 타임 컴퓨트를 64배 쓴 결과이므로 실무 단가와 전혀 다른 세계다.
$n$번 시도해 $c$번 맞은 문항에서 $k$번 안에 한 번이라도 맞을 확률의 불편 추정량이다. $k$가 커지면 이 값은 단조 증가한다. 즉 pass@k 비교는 같은 $k$끼리만 의미가 있다.
사고 예산. 추론 모델의 벤치마크 점수는 예산에 따라 달라진다. 예산 32K로 낸 점수와 우리 서비스가 감당할 4K에서의 점수는 다른 숫자다. 발표에 예산이 안 적혀 있으면 최대치로 냈다고 보는 편이 안전하다.
답 추출 방식. 최종 답을 어떻게 뽑아냈는지가 점수를 몇 퍼센트포인트 움직인다. 정규식으로 마지막 숫자를 뽑는 것과 별도 모델로 답을 추출하는 것은 다르다. 특히 오답 처리에서 차이가 난다.
프롬프트. 같은 벤치마크라도 시스템 프롬프트와 예시 개수가 다르면 결과가 달라진다. 자체 재현이 잘 안 되는 첫 번째 이유가 이것이다.
이 넷이 다르면 두 숫자는 비교 대상이 아니다. 표를 만들 때 조건 열을 같이 적어 두면 나중에 자신을 구한다.
벤치마크에는 수명이 있다
조건을 다 맞춰도 남는 문제가 있다. 공개된 벤치마크는 시간이 지나면 능력이 아니라 노출량을 재게 된다.
경로는 대체로 같다. 벤치마크가 공개되고, 풀이 해설이 블로그와 리포지터리에 올라오고, 그것이 다음 세대 모델의 학습 데이터에 포함된다. 의도적인 부정이 아니어도 웹을 크롤링하면 자연히 들어간다. 이걸 **오염(contamination)**이라고 부른다.
오염이 진행되면 점수는 오르는데 실제 능력은 그만큼 오르지 않는다. 그리고 상위권 모델들이 90%대에 몰리면 벤치마크는 변별력을 잃는다. 이 지점을 포화라고 한다. 포화된 벤치마크에서 1.2%포인트 차이는 노이즈와 구별되지 않는다.
오염을 의심할 신호
발표 자료만 보고도 알아챌 수 있는 것들이 있다.
- 비슷한 난도의 비공개 문항에서 점수가 뚝 떨어진다. 같은 유형인데 공개본에서 92%, 새로 만든 문항에서 61%면 차이의 상당 부분이 노출량이다.
- 문항을 살짝 바꾸면 무너진다. 숫자만 바꾸거나 변수명만 바꿨는데 정답률이 크게 떨어지면 풀이가 아니라 답을 기억한 것이다.
- 사고 과정이 답으로 바로 점프한다. 어려운 문항인데 검토 없이 답이 나온다.
- 연도별 문항 성능이 갈린다. 학습 컷오프 이전 연도 문항은 잘 풀고 이후 문항은 못 푸는 패턴.
두 번째 항목은 직접 해 볼 수 있다. 공개 문항 30개를 골라 숫자와 이름만 바꾸고 다시 돌려 본다. 10분이면 되고, 정보량이 크다.
그래서 어떻게 고르나
공개 점수는 후보를 줄이는 용도로만 쓴다. 최종 판단은 우리 문항으로 한다.
자체 평가 셋을 만드는 원칙은 세 가지다.
첫째, 실제 트래픽에서 뽑는다. 만들어 낸 문항이 아니라 로그에서 가져온 실제 요청이어야 한다. 어렵고 흔한 것부터 100~300건이면 시작할 수 있다.
둘째, 공개하지 않는다. 공개하는 순간 우리 벤치마크도 같은 수명 곡선을 탄다. 사내 저장소에 두고 외부 공유를 막는다. 모델 제공자에게 데이터 학습 사용 옵션이 있으면 꺼 둔다.
셋째, 정답을 사람이 확정한다. 정답을 모델로 만들면 그 모델의 편향이 그대로 기준이 된다. 초안을 모델로 만들고 사람이 검수하는 것까지가 한계다.
import json
import statistics
def evaluate(model_fn, items: list[dict], repeats: int = 5) -> dict:
"""같은 문항을 여러 번 돌려 분산까지 본다."""
per_run = []
for _ in range(repeats):
hit = sum(1 for it in items if model_fn(it["input"]) == it["gold"])
per_run.append(hit / len(items))
return {
"mean": statistics.mean(per_run),
"stdev": statistics.stdev(per_run) if repeats > 1 else 0.0,
"n": len(items),
}repeats가 중요하다. 한 번만 돌린 점수 두 개를 비교하면 표본 오차와 실제 차이를 구별할 수 없다. 문항 100개, 5회 반복이면 대개 1~3%포인트의 표준편차가 나온다. 그보다 작은 차이는 차이가 아니다.
표를 만들 때 같이 적을 것
모델 후보를 비교하는 표에는 정확도 옆에 최소 세 개를 더 둔다.
| 모델 | 자체 정답률 | 요청당 비용 | p95 지연 | 형식 준수율 |
|---|---|---|---|---|
| A (추론, 예산 4K) | 0.83 ± 0.02 | 기준 대비 6.1배 | 8.2초 | 0.97 |
| B (추론, 예산 1K) | 0.79 ± 0.02 | 기준 대비 2.4배 | 3.1초 | 0.98 |
| C (일반, CoT) | 0.71 ± 0.03 | 1.0배 | 1.4초 | 0.99 |
이 표가 있으면 결정이 논쟁이 아니라 계산이 된다. 위 예시에서 A와 B의 차이는 4%포인트인데 비용은 2.5배 차이다. 그 4%포인트가 무엇을 사 주는지 — 오답 한 건의 처리 비용이 얼마인지 — 를 곱해 보면 답이 나온다. 오답을 사람이 3분 만에 고칠 수 있는 작업이면 B가 맞고, 오답이 그대로 고객에게 나가는 작업이면 A가 맞다.
마지막으로
공개 벤치마크가 쓸모없다는 말은 아니다. 새 모델이 어느 갈래에서 크게 움직였는지 알려 주는 신호로는 여전히 유용하고, 열 개 후보를 셋으로 줄이는 데 충분하다. 다만 그 셋 중 하나를 고르는 일은 우리 데이터로만 할 수 있다.
그리고 자체 평가 셋은 한 번 만들고 끝나는 물건이 아니다. 실패 사례가 나올 때마다 그 문항을 추가한다. 반년쯤 지나면 이 셋이 우리 서비스에 대해 어떤 공개 벤치마크보다 많은 것을 말해 주게 된다.
지난 글: 추론 증류: 큰 모델의 사고를 작은 모델에 옮긴다
다음 글: 추론 모델의 비용과 지연을 다루는 법
읽어주셔서 감사합니다. 😊