제4부 평가(Evaluation)

4.1 벤치마크와 그 함정

어느 모델 출시 글이든 리더보드 표가 한 장 붙어 있고, 그 표의 맨 윗줄에는 방금 나온 모델이 있다. 굵은 숫자, 화살표, "state of the art". 이 표를 읽는 거의 모든 사람이 곧장 하나의 추론으로 건너뛴다 — "이 모델이 1등이니 최고 모델이다." 이 분야에서 이보다 흔하고, 이보다 자주 틀리는 추론은 없다.

틀리는 이유는 하나가 아니다. 그 1등은 특정 채점 규칙, 특정 프롬프트, 특정 가중치 아래의 1등이고, 2등과의 차이는 대개 측정 잡음 안이며, 그 벤치마크의 문항은 이미 누군가의 학습 데이터에 유입됐을 수 있고, 애초에 그 벤치마크가 재는 능력이 당신이 원하는 능력과 다르다. 이 장은 벤치마크를 버리라고 말하지 않는다. 벤치마크는 후보를 좁히는 값싼 1차 필터로서 대체 불가능하다. 이 장이 하려는 것은 그 표를 읽는 법과 의심하는 법을 손에 쥐여 주는 것이다 — "점수 하나"가 실은 몇 개의 숨은 결정에서 나오는지, 그 결정을 바꾸면 숫자가 어떻게 변동하는지, 그리고 어느 대목에서 벤치마크가 조용히 거짓말을 하는지를 산식과 수계산으로 본다. 언어모델의 출력은 열린 자연어라 "정답 하나"로 채점하기가 애초에 어렵고, 우리가 재고 싶은 것("똑똑하다", "쓸모 있다", "안전하다")은 단일 숫자로 환원되지 않는다. 그 두 어려움이 이 장의 모든 함정을 낳는다.

이 장에 나오는 벤치마크 이름·점수는 전부 예시다. 어떤 벤치마크가 지금 표준인지는 몇 달 단위로 바뀌고, 어제의 어려운 벤치마크가 오늘 포화해 폐기된다. 무게는 "지금 1등은 무엇인가"가 아니라 "벤치마크라는 도구가 어떻게 작동하고 어디서 무너지는가"에 있다.

4.1.1 한 숫자 뒤에 숨은 세 부품

"MMLU 78점"이라고 말할 때 사람들은 대개 데이터셋 하나를 떠올린다. 실제로는 그 한 숫자 뒤에 세 개의 독립된 부품이 서 있고, 셋 다 점수를 바꾼다.

첫째는 데이터셋이다 — 문항(질문·입력)과 정답(gold)의 고정된 집합. 무엇을 묻는가. 둘째는 채점 규칙(metric)이다 — 모델 출력을 정답과 대조해 맞고 틀림을 정하는 방식. 정확도·정확일치·F1·pass@k·보기별 로그확률 비교 등이 여기 속한다. 어떻게 채점하는가. 셋째는 프롬프트 프로토콜이다 — 문항을 모델에 어떻게 제시하는가. few-shot 예시 몇 개를 붙이는지, 지시문·포맷·정지 토큰이 무엇인지. 어떻게 묻는가.

같은 데이터셋이라도 채점 규칙을 바꾸면 다른 숫자가 나오고, 프롬프트 프로토콜을 바꿔도 다른 숫자가 나온다. 이 장의 절반은 이 문장을 증명하는 데 쓴다. 실무적 결론을 미리 명시하면, 벤치마크 점수를 인용할 때는 반드시 "어떤 하네스(harness)로, 몇 shot으로, 어떻게 채점했는가"가 따라붙어야 한다. 이 조건이 빠진 점수는 절반만 말한 것이고, 조건이 서로 다른 두 점수는 같은 표에 나란히 있어도 비교 대상이 아니다.

"하네스"라는 말이 자주 나올 텐데, 이것은 벤치마크를 실제로 실행하는 평가 소프트웨어를 가리킨다. 하네스가 프롬프트를 조립하고, 모델을 호출하고, 출력을 파싱해 채점한다. 같은 데이터셋을 두 개의 다른 하네스로 실행하면 위 세 부품의 구현 세부가 조금씩 달라 최종 숫자가 어긋난다 — 그래서 "MMLU 몇 점"은 하네스를 밝히지 않으면 재현조차 안 된다.

4.1.2 무엇을 재나 — 능력 범주와 정적 벤치마크의 숙명

벤치마크는 저마다 좁은 능력 조각을 잰다. "종합 지능"을 재는 벤치마크는 없다 — 있는 것은 특정 슬라이스를 재는 도구들의 집합이고, 종합 리더보드조차 선택된 슬라이스들의 가중 평균일 뿐이다. 아래는 대표 범주와 각 범주에서 흔히 쓰이는 벤치마크 예시다(이름·버전은 시점에 따라 바뀌므로 예시로만 읽어라).

이 표에서 세 가지를 읽어야 한다. 하나, 어떤 벤치마크도 "얼마나 똑똑한가"를 재지 않는다. 지식 QA 만점 모델이 당신 제품의 실제 대화에서 형편없을 수 있다 — "무엇을 재는 벤치마크인가"와 "내가 원하는 능력이 무엇인가"는 겹쳐 봐야 하고, 대개 완전히 겹치지 않는다.

둘, 정적 벤치마크에는 유통기한이 있다. 데이터셋이 고정되고 공개되는 순간부터 두 힘이 신뢰도를 잠식하기 시작한다. 하나는 오염 — 공개된 문항이 이후 학습 데이터로 흘러든다. 다른 하나는 과적합 — 모두가 그 벤치마크를 겨냥해 최적화한다. 표의 "장문" 범주가 좋은 예다. 초기의 needle-in-haystack 테스트는 긴 문맥 어딘가에 심은 한 문장("바늘")을 찾아내는지를 봤는데, 상위 모델들이 이내 이것을 거의 완벽히 통과했다. 그러나 "긴 문맥에서 한 문장을 찾기"와 "긴 문맥의 여러 조각을 종합해 추론하기"는 전혀 다른 난이도다 — 검색 벤치마크에서 만점인 모델이 종합 추론에서 붕괴하는 일이 흔하다. 벤치마크가 재는 것을 정확히 몰아세우지 않으면, 만점은 능력이 아니라 그 벤치마크의 쉬움을 뜻한다.

셋, 범주마다 채점 방식이 다르고, 채점 방식이 곧 그 점수의 성격을 정한다. 객관식 로그확률로 재는 지식 QA와 단위테스트로 재는 코드는 같은 "정확도"라도 완전히 다른 물건이다. 다음 절부터 이 두 채점 갈래를 해부한다.

4.1.3 객관식 채점 — 보기의 로그확률을 겨룬다

MMLU 같은 다지선다에서 가장 흔한 채점은 모델을 생성시키지 않는다. 대신 각 보기에 대해 모델이 부여하는 로그확률을 계산해 가장 높은 보기를 고른다. 정답 후보 집합을 $\mathcal{C}$(예: {A, B, C, D})라 하면

$$\hat{y} = \arg\max_{c \in \mathcal{C}} \ \log p_\theta(c \mid \text{prompt})$$

이다. 여기서 $\log p_\theta(c \mid \text{prompt})$ 는 프롬프트가 주어졌을 때 보기 $c$ 를 이루는 토큰들의 로그확률 합이다(1.1의 다음 토큰 확률을 보기 토큰마다 곱해 로그로 더한 것). 생성이 없으니 온도·표집의 영향을 받지 않고 결정적이며, GPU 한 번의 순전파로 모든 보기를 채점할 수 있어 저렴하다. 문제는 이 명료함 아래 두 개의 갈림길이 숨어 있고, 둘 다 점수를 바꾼다는 것이다.

첫째 갈림길은 무엇의 확률을 채점하느냐다. 보기 기호 토큰 자체의 확률 — "정답은 (B)"에서 토큰 "B"의 확률 $p_\theta(\text{"B"}\mid\cdot)$ — 을 볼 수도 있고, 보기 본문 전체 — "파리는 프랑스의 수도이다" 전체 — 의 확률 $p_\theta(\text{본문}\mid\cdot)$ 를 볼 수도 있다. 전자는 글자 편향에 취약하다. 많은 모델이 내용과 무관하게 특정 글자(관찰상 흔히 "A"나 "C")를 근거 없이 선호하는 경향을 보인다. 프롬프트에 보기를 나열하는 순서만 바꿔도, 즉 정답을 A에 두느냐 D에 두느냐만 바꿔도 점수가 몇 포인트 움직인다. 그래서 진지한 평가는 보기 순서를 순환시켜(정답을 A, B, C, D에 번갈아 놓아) 여러 번 재고 평균한다 — 이것을 하지 않은 객관식 점수는 글자 편향을 능력으로 착각하고 있을 수 있다.

둘째 갈림길은 길이 정규화다. 보기 본문 전체의 확률을 채점하기로 했다면, 보기마다 토큰 수가 다르다는 새 문제가 생긴다. 로그확률은 토큰마다 음수를 더해 가므로, 긴 보기는 내용이 더 옳든 아니든 토큰이 많다는 이유만으로 로그확률 합이 낮아진다. 이를 보정하려고 합을 토큰 수(또는 바이트 길이)로 나눈 길이 정규화 점수를 쓴다.

$$\hat{y}_{\text{norm}} = \arg\max_{c \in \mathcal{C}} \ \frac{1}{|c|}\log p_\theta(c \mid \text{prompt})$$

정규화 없는 점수를 흔히 acc, 정규화한 점수를 acc_norm이라 부른다. 널리 쓰이는 평가 하네스가 이 둘을 둘 다 보고하는 이유가 있다 — 어느 쪽이 "옳은" 채점인지 원리적으로 정해지지 않기 때문이다. 정규화를 하면 길이 편향은 교정하지만, 짧고 흔한 오답(모델이 습관적으로 높은 확률을 주는 짧은 표현)에 유리해진다. 정규화를 안 하면 길이 편향이 그대로 남는다. 둘은 다른 숫자이고, 어느 쪽을 인용하느냐로 순위가 바뀔 수 있다. 다음 절에서 이것을 직접 뒤집어 본다.

이 파이프라인에서 최종 숫자를 교란하는 마디는 세 곳이다 — 프롬프트 구성, 채점 방식 분기, 그리고 마지막의 파싱·정규화. 하나만 바꿔도 점수가 변동한다. 지금은 채점 분기의 오른쪽 절반, 정규화부터 직접 따라간다.

4.1.4 수계산 — 길이 정규화가 정답을 뒤집는다

MMLU식 4지선다 한 문항을 두고, 정답(gold)이 C라 하자. C는 정확하지만 서술이 길고, B는 틀렸지만 짧고 흔한 표현이다. 모델이 각 보기 본문에 매긴 로그확률(자연로그, 설명용 개략값)과 토큰 수는 다음과 같다.

정규화 없는 acc는 로그확률 합을 비교한다. 값들은 $-1.5,\,-1.2,\,-4.5,\,-3.0$ 이고, 가장 큰(0에 가장 가까운) 것은 $-1.2$ 인 B다. 그래서 acc는 B를 고르고 — 오답이다. 여기서 C가 진 유일한 이유는 토큰이 다섯 개라 음수를 다섯 번 더했다는 것뿐이다. 모델은 사실 C의 각 토큰에 가장 높은 확신($-0.90$)을 줬는데도 길이에 파묻혔다.

길이 정규화한 acc_norm은 토큰당 평균을 비교한다. 값들은 $-1.50,\,-1.20,\,-0.90,\,-1.00$ 이고, 가장 큰 것은 $-0.90$ 인 C다. 그래서 acc_norm은 C를 고르고 — 정답이다.

같은 모델, 같은 문항, 같은 순전파인데 채점 규칙 한 줄로 정답과 오답이 뒤집혔다. 이 문항 하나에서는 재미있는 우연처럼 보이지만, 벤치마크 전체로 집계하면 이 뒤집힘이 쌓인다. 정답 보기가 오답 보기보다 서술이 긴 경향이 있는 데이터셋(해설형 정답이 흔한 시험에서 자주 그렇다)에서는 acc가 체계적으로 정답을 불리하게 채점하고, acc_norm이 몇 포인트 더 높게 나온다. 반대로 정답이 짧은 데이터셋에서는 방향이 뒤집힌다. 두 지표의 차이가 문항 수백 개에 걸쳐 3~5 포인트씩 벌어지는 일이 드물지 않다.

그래서 "이 모델 MMLU 78점"이라는 말은 어떤 정규화로 쟀는지를 빼면 불완전하다. 78이 acc인지 acc_norm인지 모르면, 다른 곳에서 본 76점과 이 78점을 비교하는 것은 서로 다른 두 실험을 뺄셈하는 것이다. 그리고 이것은 정규화 하나의 이야기일 뿐이다 — 글자 편향 보정 여부, 보기 순서 순환 여부까지 겹치면 같은 데이터셋에서 나올 수 있는 "정당한" 점수의 폭이 꽤 넓어진다.

4.1.5 생성형 채점 — 자유 생성 후 파싱·매칭

수학·코드·열린 QA에서는 로그확률 비교가 안 통한다. 정답 후보 집합이 없기 때문이다 — 모델이 실제로 생성해야 하고, 그 출력에서 답을 추출해 대조해야 한다. 이 채점은 능력을 재는 것 같지만, 자주 능력이 아니라 형식을 재게 된다.

가장 단순한 것이 정확일치(exact match)와 그 완화형 F1이다. 모델 출력을 정답 문자열과 비교한다. 이 방식은 형식이 조금만 어긋나도 정답을 오답으로 처리한다. gold가 42인데 모델이 42.0이나 약 42, The answer is 42를 냈다면, 순진한 정확일치는 전부 틀렸다고 센다. 그래서 실무 하네스는 소문자화·공백 제거·관사 제거·숫자 정규화 같은 전처리를 겹겹이 쌓는데, 이 전처리 규칙 자체가 또 하나의 숨은 채점 부품이 된다 — 규칙이 관대하면 우연히 맞은 것도 맞다고 세고, 엄격하면 맞았는데 형식만 다른 것을 틀렸다고 센다.

수학에서는 최종 답 파싱이 표준이다. 모델이 사고사슬(CoT)로 길게 풀게 두고, 그 끝에서 최종 숫자를 정규식으로 뽑아 gold와 비교한다. 여기서 두 방향의 오류가 동시에 난다. 모델이 "따라서 답은 42입니다"가 아니라 "그러므로 42가 된다"라고 쓰면 정규식이 놓쳐 정답을 오답으로 셀 수 있고(과소평가), 반대로 풀이 과정이 완전히 틀렸는데 최종 숫자만 우연히 맞으면 오답을 정답으로 셀 수 있다(과대평가). 정렬이 덜 된 베이스 모델은 답 형식을 안 지켜 전자로 손실을 보고, 특정 답 형식에 튜닝된 모델은 형식 점수를 추가 비용 없이 얻는다.

코드에서는 단위테스트 통과율을 쓰고, 이것이 pass@k라는 지표를 낳는다. 생성한 코드를 테스트 스위트로 실행해 통과하면 정답인데, 한 번만 생성하는 대신 $k$ 번 표집해 적어도 하나 통과하면 맞다고 본다. $n$ 개를 표집해 그중 $c$ 개가 통과했을 때, $k$ 개를 뽑아 하나라도 통과할 확률의 불편추정은

$$\text{pass@}k = \mathbb{E}_{\text{문항}}\!\left[\,1 - \frac{\binom{n-c}{k}}{\binom{n}{k}}\,\right]$$

이다. $\binom{n-c}{k}/\binom{n}{k}$ 는 $k$ 개를 모두 실패 $n-c$ 개 중에서만 뽑을 확률, 즉 하나도 통과 못 할 확률이고, 그 여집합이 pass@k다. 여기서 $k$ 가 이 지표의 전부를 좌우한다 — $k$ 를 키우면 같은 모델의 점수가 오른다. 그런데 단위테스트로 채점하는 데도 함정이 둘 있다. 테스트가 불완전하면 틀린 코드가 통과해 과대평가가 나고(현실의 테스트 스위트는 거의 항상 불완전하다), 채점이 코드를 실제로 실행하는 환경에 의존해 라이브러리 버전·타임아웃·샌드박스 설정에 따라 같은 코드가 통과하기도 실패하기도 한다. 다음 절에서 pass@k의 $k$ 민감도를 직접 재 본다.

4.1.6 수계산 — pass@k는 같은 모델을 몇 배 좋게 보이게 하나

한 코딩 문항에서, 모델이 한 번 생성할 때 그 코드가 테스트를 통과할 확률을 $p=0.15$ 라 하자(꽤 어려운 문항이다). 표집이 독립이라고 근사하면, $k$ 번 뽑아 적어도 하나 통과할 확률은 $\text{pass@}k = 1-(1-p)^k$ 다. 세 값을 계산한다.

$$\text{pass@}1 = 0.15, \qquad \text{pass@}5 = 1-0.85^5 = 1-0.444 = 0.556, \qquad \text{pass@}10 = 1-0.85^{10} = 1-0.197 = 0.803$$

같은 모델, 같은 문항인데 pass@1로 재면 15점, pass@10으로 재면 80점이다. 다섯 배 넘게 벌어졌다. 능력은 한 톨도 변하지 않았고 바뀐 것은 "몇 번 뽑아 그중 최선을 보나"라는 채점 규칙뿐이다.

앞 절의 불편추정으로도 확인해 보자. 실제로 $n=20$ 번 표집해 $c=3$ 개가 통과했다고 하자(경험적으로 $p=3/20=0.15$). pass@1의 불편추정은 $c/n=0.15$ 로 같고, pass@10은

$$\text{pass@}10 = 1 - \frac{\binom{20-3}{10}}{\binom{20}{10}} = 1 - \frac{\binom{17}{10}}{\binom{20}{10}} = 1 - \frac{19{,}448}{184{,}756} = 1 - 0.105 = 0.895$$

독립 근사의 0.803과 조금 다르지만(표본 수 유한, 비복원 추출의 차이), 결론은 같다 — $k$ 를 키우면 점수가 폭발적으로 오른다.

그래서 pass@1 숫자와 pass@100 숫자를 나란히 비교하는 것은 무의미하다. 리더보드에서 "모델 A는 88점, 모델 B는 67점"을 보고 A가 낫다고 결론짓기 전에, 두 점수가 같은 $k$ 로 쟀는지부터 확인해야 한다 — B의 67이 pass@1이고 A의 88이 pass@10이라면, 오히려 B가 더 강할 수 있다. 그리고 pass@k에는 실무적 함의가 하나 더 있다. 높은 $k$ 는 "정답을 뽑을 능력"이 아니라 "여러 번 시도할 여유"를 재는 것이다. 실제 제품에서 사용자에게 100번 표집해 그중 통과하는 것을 골라 줄 수 있으려면 통과 여부를 판정할 오라클(테스트 스위트)이 있어야 하는데, 벤치마크에는 그 오라클이 있고 당신 제품에는 대개 없다. pass@100이 높다는 것과 사용자가 첫 응답에서 맞는 코드를 받는다는 것은 전혀 다른 주장이다.

4.1.7 두 채점 방식은 나란히 놓을 수 없다

객관식 로그확률과 생성형 파싱은 성격이 정반대다. 이 차이를 알면 리더보드가 왜 종종 사과와 오렌지를 같은 열에 놓는지 보인다.

마지막 두 행이 실무에서 크게 영향을 준다. 폐쇄형 API 모델은 보기별 로그확률을 안 주는 경우가 많다 — 그러면 객관식 채점을 그대로 못 쓰고, "생성시켜 답 글자를 뽑는" 방식으로 우회할 수밖에 없다. 그런데 이렇게 우회하면 오픈 모델의 로그확률 채점과 채점 경로 자체가 달라진다. 같은 MMLU라도 오픈 모델은 네 보기의 확률을 비교해 결정적으로 채점되고, API 모델은 실제로 "정답은 (C)"를 생성하게 한 뒤 그 글자를 파싱해 채점된다. 후자는 형식 준수 여부·표집 잡음이 섞이고, 지시를 안 따라 "제 생각엔 C가 맞는 것 같은데요"라고 답하면 파서가 놓칠 수도 있다. 두 숫자는 같은 벤치마크의 이름을 달고 있어도 다른 실험이다. 리더보드가 이 둘을 한 표에 나란히 놓았다고 같은 조건으로 잰 것이 아니다.

추론 모델은 채점을 한 겹 더 복잡하게 만든다. o1·R1 계열(3.7)은 답을 내기 전에 긴 사고를 생성하고, 그 사고에 추론 시간 연산(test-time compute)을 더 투입할수록 점수가 오른다. 그래서 "모델 A 대 B"를 비교할 때 각자 얼마나 많은 추론 토큰·연산을 허용받았는가를 맞추지 않으면 공정하지 않다 — A가 문항당 사고 토큰을 열 배 더 쓰도록 허락받았다면, A의 높은 점수는 더 나은 모델이 아니라 더 많은 연산의 결과일 수 있다. 벤치마크 표의 한 줄은 이 조건을 거의 항상 숨긴다. 비용·연산을 맞춰 비교하는 문제는 4.1.13에서 다시 든다.

4.1.8 같은 모델, 다른 점수 — 프롬프트 민감도와 재현성 위기

벤치마크의 불편한 진실 하나 — 같은 모델, 같은 데이터셋인데도 점수가 논문마다 다르다. 원논문, 종합 리더보드, 어느 회사의 기술보고서가 같은 모델에 서로 다른 숫자를 적는 일이 흔하다. 부정직해서가 아니라, 앞서 본 파이프라인의 변동하는 마디들이 사람마다 다르게 고정됐기 때문이다.

한 축만 심층 분석하자. few-shot 수를 0에서 5로 높이면 지식 QA 점수가 몇에서 십몇 포인트 오르곤 한다. 예시가 모델에게 "이런 형식으로 이런 종류의 답을 내라"는 신호를 주기 때문이다. 그런데 이 효과의 방향이 모델 종류에 따라 갈린다. 정렬된 채팅 모델은 0-shot 지시를 잘 따르도록 튜닝돼 있어 few-shot의 이득이 작거나 오히려 예시 포맷이 채팅 템플릿과 충돌해 손실을 볼 수 있고, 사전학습 베이스 모델은 지시를 못 알아들어 few-shot 예시에서 과제를 유추하는 데 크게 의존한다. 그래서 "5-shot으로 재자"는 결정 하나가 특정 종류의 모델에 체계적으로 유리해진다 — 이것은 능력 차이가 아니라 프로토콜 차이다. 두 모델을 0-shot으로 비교한 표와 5-shot으로 비교한 표가 서로 다른 승자를 낼 수 있고, 둘 다 "MMLU 점수"라는 같은 이름을 달고 있다.

예시 순서 편향도 실재한다. few-shot 예시들의 순서만 바꿔도(내용은 그대로) 점수가 눈에 띄게 움직이는 것이 반복 관찰됐다. 모델이 마지막 예시나 특정 위치의 예시에 과도하게 끌리는 순서 민감성 때문인데, 이 때문에 진지한 평가는 여러 순서로 재 평균한다. 프롬프트 포맷 — "Question:"이냐 "Q:"냐, 콜론 뒤 공백이 하나냐 둘이냐, 줄바꿈이 어디 있느냐 — 조차 토큰 경계를 바꿔(1.2) 분포를 교란한다. 사소해 보이는 이 차이들이 하네스 구현마다 조금씩 다르게 굳어 있고, 그래서 두 하네스의 같은 벤치마크 점수가 어긋난다.

이 모든 변동의 실무적 결론은 하나다. 벤치마크 점수를 인용하거나 받아들일 때 하네스·버전, few-shot 수, 프롬프트 포맷, 채점 규칙과 정규화, 오염 통제 여부가 함께 오지 않으면 그 숫자는 다른 어떤 숫자와도 비교할 수 없다. "같은 표에 있으니 비교 가능하다"는 착시다. 그런데 프로토콜을 완벽히 고정한다 해도 아직 끝이 아니다 — 벤치마크는 유한한 표본이라, 점수 자체에 통계적 잡음이 있다.

4.1.9 수계산 — 신뢰구간과 "1점 차는 잡음"

벤치마크는 문항 $N$ 개의 유한 표본이다. 이 표본이 우연히 어떤 모델에 조금 유리하거나 불리하게 뽑혔을 수 있으므로, 관측된 정확도 $\hat p$ 는 참 능력을 표집 잡음과 함께 잰 것이다. 문항이 독립이고 각 문항의 정답 확률이 $p$ 라고 근사하면, 정확도는 이항분포를 문항 수로 나눈 것이고 그 표준오차(SE)는

$$\text{SE} \approx \sqrt{\frac{p(1-p)}{N}}, \qquad 95\%\ \text{신뢰구간} \approx \hat{p} \pm 1.96\,\text{SE}$$

이다. $p=0.75$, $N=1000$ 을 넣으면

$$\text{SE} = \sqrt{\frac{0.75\times0.25}{1000}} = \sqrt{0.0001875} \approx 0.0137 \ \Rightarrow\ 95\%\ \text{CI} \approx \pm 2.7\ \text{포인트}$$

즉 이 벤치마크에서 75.0점 모델의 참 능력은 대략 72.3에서 77.7 사이에 있다. 그렇다면 75.0점 모델과 74.0점 모델의 1점 차이는 두 구간이 크게 겹치는 안쪽이다 — 이 데이터로는 두 모델을 구별할 수 없다. 과목별로 분할해 $N=200$ 만 되면 SE가 $\sqrt{0.75\times0.25/200}\approx0.031$ 로 커져 CI가 $\pm6$ 포인트까지 벌어진다. 많은 벤치마크가 과목당 수백 문항뿐이라, 세부 항목의 순위 다툼은 통계적으로 무의미한 경우가 흔하다.

이 근사에는 정직하게 밝힐 이상화가 들어 있다. 문항이 독립이고 난이도가 같다는 가정인데, 실제 벤치마크는 문항 난이도가 제각각이고 서로 상관도 있어 실제 불확실성은 이보다 클 수 있다. 그래도 방향은 확고하다 — CI를 밝히지 않은 "몇 점 차 1등"은 신뢰하지 말라.

그런데 여기서 한 걸음 더 나가면, 두 모델을 제대로 비교하는 방법이 총점 빼기가 아님을 알 수 있다. 두 모델을 같은 문항 집합에서 쟀다면, 총점 두 개를 독립인 것처럼 빼는 것은 정보를 버리는 것이다. 정직한 비교는 문항별로 짝지어 보는 쌍체 검정(paired test)이다. 두 방식이 얼마나 다른지 숫자로 보자. 두 모델을 같은 1000문항에서 쟀더니, 둘 다 맞힌 문항 700개, 둘 다 틀린 문항 210개, A만 맞힌 문항 55개, B만 맞힌 문항 35개였다고 하자. 그러면 A의 정확도는 $(700+55)/1000=75.5\%$, B는 $(700+35)/1000=73.5\%$, 차이는 2 포인트다.

두 모델을 독립 표본처럼 취급하면 차이의 표준오차는 $\text{SE}_{\text{diff}}=\sqrt{\text{SE}_A^2+\text{SE}_B^2}$ 이고,

$$\text{SE}_{\text{diff, 독립}} = \sqrt{\frac{0.755\times0.245}{1000}+\frac{0.735\times0.265}{1000}} = \sqrt{0.000185+0.000195} \approx 0.0195$$

이라 $z = 0.02/0.0195 \approx 1.03$ 으로, 통계적으로 유의하지 않다(2점 차인데도 구별 못 한다). 그런데 같은 문항에서 쟀으니 쌍체로 볼 수 있고, 이때는 둘의 답이 갈린 문항(불일치 쌍)만 정보를 준다 — 둘 다 맞히거나 둘 다 틀린 910개 문항은 두 모델을 구별하지 못하므로 잡음에서 빠진다. 불일치 쌍은 A만 맞힌 55개와 B만 맞힌 35개, 합 90개다. 쌍체 차이의 표준오차는 대략

$$\text{SE}_{\text{diff, 쌍체}} \approx \frac{\sqrt{(b+c)-(b-c)^2/N}}{N} = \frac{\sqrt{90-(20)^2/1000}}{1000} = \frac{\sqrt{89.6}}{1000} \approx 0.0095$$

이라 $z = 0.02/0.0095 \approx 2.1$ 로, 이번엔 (아슬아슬하게) 유의하다. 같은 데이터인데 총점 빼기는 "차이 없음"이라 하고 쌍체 검정은 "차이 있음"이라 한다 — 쌍체가 문항 난이도라는 공통 잡음을 상쇄해 더 예민하기 때문이다. 그래서 두 모델을 진지하게 비교하려는 사람은 총점 두 개가 아니라 문항별 정오답 로그를 요구한다. 리더보드는 총점만 주므로, 리더보드로는 이 판정을 애초에 할 수 없다.

4.1.10 오염·누출 — 점수가 부풀려지는 근본 원인

지금까지는 정직하게 채점해도 점수가 변동한다는 이야기였다. 이제 점수가 조직적으로 부풀려지는 원인을 본다. 오염(contamination) 또는 데이터 누출(data leakage)은 평가셋의 문항·정답·풀이가 모델의 학습 데이터에 섞여 든 것을 말한다. 이러면 모델은 문제를 풀어서 맞히는 것이 아니라 외운 것을 재생해 맞힌다. 점수는 오르지만 그 능력은 허상이다 — 처음 보는 문제에는 그만큼 못한다. 1.1에서 퍼플렉서티의 한계로, 2.1에서 데이터 정제의 오염 제거로 예고된 문제를, 여기서는 평가의 관점으로 정면에서 본다.

오염이 왜 그렇게 파괴적인지는 그것이 절대 점수만 부풀리는 것이 아니라 비교를 왜곡하기 때문이다. 숫자로 보자. 어떤 능력 범주에서 모델의 참 능력(처음 보는 문항 정답률)이 60%라 하자. 그런데 평가셋의 10%가 학습에 누출돼 모델이 그 부분을 거의 100% 재생한다면, 관측 점수는

$$0.10\times 1.00 + 0.90\times 0.60 = 0.64$$

로 4 포인트 부풀려진다. 누출이 20%면 $0.20\times1.00+0.80\times0.60=0.68$ 로 8 포인트다. 이제 결정적인 대목 — 참 능력이 똑같이 60%인 경쟁 모델이 정직하게 오염을 제거하고 60%를 보고하면, 그 모델은 오염된 64점·68점 모델보다 못한 것처럼 보인다. 오염은 실력을 부풀리는 데서 그치지 않고, 정직한 평가를 처벌한다. 이 인센티브 구조가 오염을 근절하기 어렵게 만드는 근원이다.

오염이 들어오는 경로는 하나가 아니라서 완전 차단이 어렵다.

직접 오염(verbatim)은 가장 흔하다 — 벤치마크 문항이 문제 사이트·깃허브·토론 포럼에 그대로 올라오고, 그 웹이 사전학습 코퍼스로 들어간다. 문항과 학습 데이터가 글자 그대로 겹치므로 탐지하기도 상대적으로 쉽다. 간접 오염은 더 교묘하다 — 정답·풀이·해설이 문항과 별도로 유포되거나("문제는 못 봤지만 풀이는 봤다"도 오염이다), 문항을 변형·번역한 판본이 유통되어 원문 n-gram 대조를 피한다. 사후학습 오염은 SFT나 합성데이터(3.9)를 만들 때 벤치마크와 유사한 문항이 섞이는 것으로, 심하면 벤치마크의 train 스플릿으로 대놓고 학습해 test에서 이득을 보기도 한다(train/test 경계가 명확하지 않은 데이터셋에서 특히 흐릿하다). 마지막으로 피드백 루프 오염은 명시적 학습 없이도 일어난다 — 리더보드에 등재하려 벤치마크를 자꾸 들여다보며 체크포인트·프롬프트를 고르면, 그 선택을 통해 벤치마크의 정보가 모델로 유입된다. 이것은 다음 절의 굿하트와 이어진다.

4.1.11 오염을 어떻게 탐지하고, 왜 막기 어려운가

탐지 방법은 학습 데이터를 볼 수 있는가에 따라 갈린다.

학습 코퍼스에 접근할 수 있으면(화이트박스) 정공법이 있다 — 평가셋과 학습 코퍼스의 n-gram·부분문자열 중복을 대조해 겹치는 문항을 걸러낸다. 2.1에서 본 데이터 정제의 오염 제거와 같은 기법이고, 표준 절차다. 여기에 더해 일부 벤치마크는 데이터셋에 고유 식별 문자열, 이른바 카나리(canary) GUID를 심어 둔다. 모델이 그 문자열을 재생하면 "이 데이터를 봤다"는 직접 증거가 되고, 동시에 데이터 제작자가 학습자에게 "이 파일은 학습에서 빼라"고 보내는 신호이기도 하다. 카나리는 성실한 학습자에게는 유용하지만, 성실하지 않은 학습자를 강제하지는 못한다.

상용 모델 대부분은 학습 데이터를 공개하지 않으므로(블랙박스) 행동으로 추정할 수밖에 없다. 문항 완성 검사는 문항의 앞부분만 주고 뒷부분이나 정답을 글자 그대로 이어 쓰는지 본다 — 외웠다면 원문을 복원한다. 변형 민감도 검사는 보기 순서를 섞거나 표현을 바꾼 판본에서 점수가 급락하는지 본다. 원본을 외운 모델은 원본에서만 높고 변형에서 붕괴한다. 같은 논리로 원본 대 변형 성능 격차 — 새로 만든 동일 난이도 변형 문제에서 훨씬 못하면 — 를 오염의 정황으로 삼는다. 멤버십 추론은 문항에 대한 비정상적으로 낮은 손실(과도한 확신)을 신호로 쓰는데, 이것은 불완전하고 논쟁적이다.

블랙박스 탐지는 정황 증거이지 증명이 아니라는 점을 분명히 해야 한다. 변형 문제에서 점수가 낮은 것은 오염 때문일 수도 있지만, 단순히 모델의 강건성이 낮아서일 수도 있다 — 둘을 구별하기 어렵다. 그래서 "저 모델은 오염됐다"는 단정은 신중해야 하고, 거꾸로 "우리 모델은 오염이 없다"는 주장도 검증 가능한 절차(제거 로그 공개·카나리 준수) 없이는 믿을 근거가 없다.

완화가 근본적으로 어려운 이유는 두 가지다. 하나는 웹 스케일 코퍼스에서 모든 벤치마크의 판본·번역·변형을 다 제거하기가 사실상 불가능하다는 것 — n-gram 제거는 글자 그대로의 직접 오염은 검출해도 변형된 간접 오염을 놓친다. 다른 하나는 4.1.10에서 본 인센티브 충돌 — 높은 점수는 마케팅·투자·채택에 직결되므로 오염을 적극적으로 찾을 유인이 약하다. 이 두 장벽 앞에서 가장 확실한 방어는 오염을 탐지하는 것이 아니라 오염이 원천적으로 불가능한 평가를 쓰는 것이다. 모델 학습 시점 이후에 만들어진 신선한(held-out) 벤치마크는 학습 데이터에 있을 수 없다. 비공개(private) 테스트셋, 주기적으로 문항을 교체하는 동적(dynamic) 벤치마크, 실시간 인간 평가도 같은 취지다. 다만 신선한 벤치마크조차 공개되고 시간이 지나면 유출·포화된다 — 유통기한을 늦출 뿐 없애지는 못한다. 그 포화가 다음 절의 주제다.

4.1.12 굿하트 법칙 — 측정이 목표가 되면

경제학자 굿하트의 관찰을 이 분야에 옮기면 이렇게 된다 — 어떤 측정치가 목표가 되는 순간, 그것은 좋은 측정치이기를 멈춘다. 벤치마크는 원래 능력의 대리 지표(proxy)다. 그런데 벤치마크 점수 자체가 목표(순위·마케팅·보상)가 되면, 사람들은 능력이 아니라 점수를 높이는 방향으로 최적화한다. 그 순간부터 점수와 실제 능력의 상관이 붕괴한다.

점수에 과적합하는 통로는 여럿이고, 대부분 노골적 부정행위가 아니라 미묘한 선택으로 스며든다. 가장 극단은 벤치마크 문항을 학습에 직접 넣는 것 — 명백한 오염이다. 그다음이 분포로 학습(teaching to the test)이다. 문항 자체는 안 넣지만 벤치마크와 똑같은 형식·유형의 데이터를 대량 합성해 학습시킨다 — 오염 제거는 통과하지만 "이 시험 유형에 맞춰 벼락치기"한 셈이라, 그 벤치마크 점수는 오르고 일반 능력은 안 오른다. 더 미묘한 것이 선택에 의한 과적합이다. 여러 프롬프트·체크포인트·하이퍼파라미터를 만들어 그중 벤치마크 점수가 가장 높은 것을 고르면, 다중 비교 때문에 잡음에 과적합된다 — 그 벤치마크에선 높지만 다른 데선 재현되지 않는다. 그리고 벤치마크 전용 프롬프트 — 그 벤치마크에서만 잘 되는 특수 시스템 프롬프트·포맷을 붙여 점수를 높이는 것. 이 통로들의 공통점은 평가셋을 직접 안 넣고도 점수를 부풀린다는 것이다. 그래서 "우리는 오염 제거를 했다"를 보여도 과적합은 남을 수 있다.

과적합의 종착역이 포화(saturation)다. 상위 모델들이 다 95%+를 받으면 그 벤치마크는 더 이상 누가 더 나은지를 못 가린다 — 상한에 근접해 변별력을 잃는다. 여기에 라벨 잡음이 겹친다. 많은 벤치마크에 잘못된 정답이나 모호한 문항이 몇 퍼센트 섞여 있어, 완벽한 모델도 100%를 못 받는다. 상위권은 이미 이 라벨 잡음 수준에서 다투는 중일 수 있고, 그 구간의 차이는 능력이 아니라 데이터 오류일 공산이 크다 — 4.1.9의 신뢰구간 잡음에 더해, 데이터셋 자체의 정답 오류가 또 하나의 상한을 만든다. 벤치마크의 수명 주기는 이렇게 흐른다. 새 벤치마크 등장 → 초기엔 변별력 좋음 → 모두가 최적화 → 오염·포화 → 폐기, 새 벤치마크로 교체. 그리고 이 주기가 점점 빨라진다.

방어책은 4.1.11의 오염 방어와 크게 겹친다 — 신선한·비공개 테스트셋과 동적 벤치마크, 그리고 개발 중 참고한 벤치마크와 최종 보고하는 벤치마크를 분리하는 것(개발셋으로 튜닝하고 홀드아웃으로 보고). 여기에 더해, 여러 독립 벤치마크의 프로파일을 함께 보는 것이 강력한 진단이 된다. 한 벤치마크에서만 유난히 두드러지고 다른 축에서는 평범한 모델은 그 벤치마크에 과적합됐을 정황이다. "이 모델은 벤치마크 X에서 SOTA다"라는 문장은 "X에 최적화됐을 가능성"과 원리적으로 분리되지 않는다 — 특히 X에서만 두드러진다면, 과적합을 의심하는 것이 기본자세다.

4.1.13 단일 점수의 함정 — 총체적 평가와 비용·지연

"모델 X는 82점"처럼 하나의 숫자로 모델을 요약하려는 충동은 강하지만, 우리가 신경 쓰는 것은 여러 축이고 그 축들은 서로 상충한다. 정확도는 높지만 틀릴 때 과신하는(보정이 나쁜) 모델이 있고, 평균 성능은 좋지만 입력을 약간 바꾸면 붕괴하는(강건성이 낮은) 모델이 있고, 능력은 좋지만 특정 집단에 편향되거나 유해 출력이 잦은 모델이 있고, 점수는 1점 높지만 비용·지연이 몇 배인 모델이 있다. 이 축들을 하나로 합치면 정작 결정에 필요한 정보가 사라진다. 그래서 여러 시나리오 곱하기 여러 지표의 프로파일로 보는 총체적 평가가 필요하다.

단일 리더보드 순위는 이 프로파일을 하나의 가중 평균으로 압축해 담은 것이다. 그러니 순위는 누가 가중치를 정했는가에 따라 바뀐다 — 가중치는 가치 판단이지 객관이 아니고, "종합 1등"은 그 가중치 아래에서의 1등일 뿐이다. 수학을 두 배로 가중해 매긴 순위와 대화 품질을 두 배로 가중해 매긴 순위는 다른 승자를 낸다.

실무에서 특히 자주 빠지는 축이 비용과 지연이다. 벤치마크 표는 능력만 싣고 비용을 숨기지만, 제품에서는 1점 더 높은 대형 모델이 토큰당 다섯 배 비용이 크고 두 배 느리면 대다수 제품에서 더 나쁜 선택이다(7.5의 유닛 이코노믹스). 추론 모델(3.7)은 이 문제를 극대화한다 — 추론 시간 연산을 더 투입해 점수를 사는데, 그 연산이 곧 비용이자 지연이다. "점수만" 비교하면 이 모델은 무조건 좋아 보이지만, "점수 대비 비용" 곡선으로 보면 이야기가 달라진다.

파레토 프런티어 위의 모든 모델은 "그 비용에서 최선"이라는 뜻에서 정당한 선택지다. 프런티어 아래로 뒤처진(회색) 모델은 같은 비용에 더 나은 모델이 있으니 고를 이유가 없다. 그리고 프런티어 위에서 어느 점을 고를지는 능력만으로 정해지지 않는다 — 내 예산과 지연 예산이 정한다. 실무의 질문은 "가장 똑똑한 모델이 무엇인가"가 아니라 "내 예산·지연 안에서 가장 나은 모델이 무엇인가"이고, 그 답은 리더보드 맨 윗줄이 아니라 이 곡선 어딘가의 중간 점인 경우가 대부분이다.

4.1.14 능력이 높다고 안전한 것이 아니다

지금까지의 벤치마크는 대부분 능력 평가 — "이걸 할 수 있나"를 잰다(지식·추론·코드). 안전 평가는 정반대 질문을 한다 — "이걸 하면 안 되는데 하는가, 공격에 견디는가"(유해 요청 거부, 탈옥 저항, 편향·유해성, 위험 능력). 이 둘은 다른 축이고, 자주 상충한다.

능력이 높다고 안전한 것이 아니다 — 오히려 더 유능한 모델이 더 위험할 수 있다. 유해한 요청에 대해 더 그럴듯하고 실행 가능한 답을 낼 수 있기 때문이다. 반대로 안전을 위해 과하게 거부하면(over-refusal) 유용성이 떨어진다. "폭탄"이라는 단어가 들어갔다고 요리 질문까지 거부하는 모델은 안전 점수는 높아도 쓸모가 없다. 안전과 유용성의 이 균형이 정렬(3.1)과 가드레일(7.3)의 핵심 긴장이다. 특히 사이버·생화학 같은 위험 도메인에서는 능력 평가가 그 자체로 위험 능력 평가가 된다(이중 용도) — 능력 평가와 안전 평가가 겹치는 지점이고, 이 방법론 전체는 4.3에서 정면으로 다룬다.

이 장에서 명시할 것은 하나다 — 능력 벤치마크 점수가 높다고 배포해도 되는 것이 아니다. 능력과 안전은 따로 평가하고 둘 다 통과해야 한다. 능력 리더보드 1등이라는 사실은 그 모델이 안전하게 배포 가능한지에 대해 아무것도 말해 주지 않는다.

4.1.15 벤치마크는 제품 품질이 아니다 — 내 분포에서 재라

이 장에서 가장 큰 함정을 마지막에 둔다 — 공개 벤치마크에서 잘한다고 당신 제품에서 잘하는 것이 아니다. 벤치마크의 문항 분포는 당신 사용자의 실제 입력과 다르다. MMLU가 재는 학술 시험 문항과, 당신 고객지원 봇에 들어오는 반말·오타·중의적 질문은 다른 세계다. 그래서 실무 평가는 벤치마크 바깥으로 나가야 한다.

가장 중요한 도구가 자체 골든셋이다 — 당신 과제·도메인의 실제 입력으로 만든 비공개 평가셋. 이것이 공개 벤치마크보다 당신 제품에 대해 훨씬 많은 것을 말해 준다. 게다가 당신만 가진 데이터이므로 오염 걱정이 원천적으로 없다 — 4.1.10의 문제가 애초에 성립하지 않는다. 다만 열린 응답(요약·대화·글쓰기)은 정답 매칭이 안 되니 채점을 어떻게 하느냐가 새 문제로 남는데, 모델로 모델을 채점하는 LLM-as-judge와 그 편향·보정이 다음 장 4.2의 주제다. 그리고 오프라인 평가가 아무리 좋아도 실제 트래픽에서는 다를 수 있으니, 최종 판단은 온라인 지표·사용자 피드백·A/B로 내려야 한다 — 관측성은 7.6, 실험·릴리스는 8.2이다.

벤치마크는 이 파이프라인의 첫 칸, 후보를 값싸게 좁히는 1차 필터일 뿐이다. 여기서 걸러진 모델을 내 골든셋에 실행하고, 열린 응답은 판정 모델로 채점하고, 그렇게 좁힌 후보를 온라인에서 A/B로 확인해야 최종 판단이 선다. 안전 평가는 이 흐름과 별도로 통과해야 하는 관문이다. 벤치마크 순위 하나로 이 전체를 건너뛰는 것이 "SOTA니 우리 제품에도 최고"라는 오류의 정체다.

4.1.16 인간 선호 아레나, 그리고 점수 앞에서 던질 질문

정적 벤치마크의 오염·포화를 피하려는 유력한 대안이 인간 선호 아레나다 — 익명의 두 모델이 같은 프롬프트에 답하고, 사람이 둘 중 나은 쪽을 고르고, 그 페어와이즈 투표를 Elo류로 랭킹한다. 장점이 뚜렷하다. 프롬프트가 사용자에게서 실시간으로 오니 신선해 오염이 어렵고, 정답이 없는 열린 대화 품질을 직접 잰다. 정적 벤치마크가 못 재는 것을 재는, 실제 보완재다.

그러나 무결하지 않다. 사람은 길고 자신감 있고 포맷이 보기 좋은 답을 선호하는 경향이 있어, 내용이 더 정확한 짧은 답이 더 길고 화려한 오답에 지는 일이 관찰된다 — 길이·스타일 편향이다. 길이를 보정하려는 시도가 있지만 완전하지 않다. 아레나에 들어오는 질문의 분포도 당신 사용자의 분포와 다르므로, 아레나 상위가 당신 도메인 상위를 보장하지 않는다. 특정 스타일로 튜닝해 선호를 얻거나 자사 모델 식별 단서를 노출하는 게이밍의 여지도 제기되고, 투표자가 대표 표본이 아니라는 자기선택 문제도 있다. 요컨대 아레나는 정적 벤치마크의 좋은 보완이지 최종 진리가 아니다 — 재는 축이 다를 뿐, 그 축에도 편향은 있다.

이 장 전체를 하나의 습관으로 압축하면 이렇다. 누가 "우리 모델이 X에서 1등"이라고 할 때, 곧장 최고라고 믿는 대신 다음을 묻는다. 하네스·버전·shot·프롬프트·채점 규칙·정규화 같은 조건이 공개됐는가. 오염 제거·카나리 준수·신선한 셋 여부, 변형 문제에서도 점수가 유지되는가 하는 오염 통제를 했는가. 신뢰구간과 문항 수는 얼마이고, 2등과의 차이가 그 잡음 밖인가. 한 벤치마크에서만 두드러지는가 아니면 여러 독립 축에서 고르게 좋은가. 그 벤치마크가 내 과제와 얼마나 닮았고, 결국 내 골든셋에서 재 봤는가. 비용·지연 대비 점수는 파레토상 어디인가. 능력만 봤는가, 안전도 별도로 통과했는가. 이 질문들에 답이 없으면 "1등"은 마케팅 문장이지 공학적 주장이 아니다.

이 장이 미뤄 둔 가장 큰 숙제는 "열린 응답은 정답 매칭이 안 되니 모델로 채점한다"는 대목이었다. 모델로 모델을 채점하면 채점자 자신이 편향과 오류의 원천이 된다 — 위치·길이·자기선호 편향, 보정, 그리고 오프라인 평가셋을 어떻게 설계하는가가 4.2의 주제다. 그 뒤 4.3에서, 이 장이 "능력과 다른 축"이라 못 박은 안전성 평가와 레드팀으로 넘어간다.