논문엔 86점, 리더보드엔 79점, 어느 게 맞는 걸까요
LLM 발표 자료를 보면 꼭 나오는 숫자가 있어요. 'MMLU 88.7%' 같은 거요. 그런데 같은 모델을 다른 곳에서 평가하면 점수가 몇 점씩 달라지는 일이 정말 흔해요. 심하면 5~10점까지 차이 나기도 하고요. 이번에 소개할 글은 바로 이 문제, 'MMLU라는 이름 하나에 사실은 서로 다른 시험이 여러 개 숨어 있다'는 이야기를 다루고 있어요.
MMLU가 뭐냐면, Massive Multitask Language Understanding의 약자로, 수학, 역사, 법률, 의학 등 57개 과목에서 뽑은 객관식 문제 약 1만 4천 개짜리 시험이에요. 2020년에 나왔고, 한동안 '이 모델이 얼마나 똑똑한가'를 재는 대표 지표였죠. 문제마다 A, B, C, D 네 개 보기가 있고, 모델이 정답 보기를 고르면 돼요. 얼핏 보면 채점이 너무 명확해서 헷갈릴 게 없어 보이는데, 실제로는 그렇지 않아요.
점수가 갈리는 지점들
첫째, '고른다'는 걸 어떻게 정의하느냐가 달라요. 방법이 크게 두 가지예요. 하나는 로그 확률(log-likelihood) 방식인데, 모델한테 문제를 보여주고 다음 토큰으로 A, B, C, D 중 어느 글자가 나올 확률이 가장 높은지 재요. 모델이 실제로 글자를 '말하는' 게 아니라 속으로 얼마나 기울어져 있는지 확률만 보는 거죠. 다른 하나는 생성(generative) 방식으로, 모델이 진짜로 답을 써내게 하고 거기서 정답 글자를 파싱해요. 이 둘은 같은 모델에 대해 다른 결과를 내요. 로그 확률 방식은 모델이 '정답:' 다음에 'B'라고 쓰는 습관이 없어도 점수를 받지만, 생성 방식은 '정답은 B입니다. 왜냐하면...'이라고 길게 말하는 모델의 답에서 글자를 잘못 뽑으면 틀린 걸로 처리되거든요.
둘째, 확률을 무엇에 대해 재느냐도 달라요. 같은 로그 확률 방식이라도, 보기 글자 A/B/C/D의 확률을 비교하는지, 아니면 보기 본문 전체('파리는 프랑스의 수도이다' 같은 문장)의 확률을 비교하는지에 따라 결과가 갈려요. 후자는 문장 길이에 따라 확률이 달라지니까 길이 보정을 할지 말지도 또 갈리고요.
셋째, 프롬프트 형식이 달라요. 원저자(Hendrycks) 구현, 스탠퍼드의 HELM, EleutherAI의 lm-evaluation-harness, OpenCompass는 각각 문제를 모델에게 보여주는 형식이 조금씩 달라요. 예시를 5개 보여주는 5-shot이냐 0-shot이냐, 예시와 문제 사이에 빈 줄이 있느냐, 'Answer:' 뒤에 공백이 있느냐 같은 사소해 보이는 차이가 작은 모델에서는 점수를 뒤흔들어요.
이게 그냥 이론적인 걱정이 아니에요. 2023년에 허깅페이스 Open LLM 리더보드에서 LLaMA 65B의 MMLU 점수가 논문 수치보다 훨씬 낮게 나와서 논란이 됐는데, 조사해보니 같은 모델을 세 가지 구현(원저자 코드, HELM, lm-eval-harness)으로 돌리면 점수가 확연히 달랐던 거예요. 리더보드 팀이 이걸 정리한 글이 아직도 이 문제를 설명하는 대표 사례로 남아 있어요. 또 다른 유명한 사례는 2023년 말 구글이 Gemini Ultra의 MMLU 90.0%를 발표하면서 GPT-4의 86.4%를 이겼다고 한 건데, Gemini는 사고 과정을 32번 샘플링해서 다수결을 낸(CoT@32) 점수였고 GPT-4는 그냥 5-shot 점수였어요. 같은 조건으로 재면 순위가 바뀔 수 있는, 사과와 오렌지를 비교한 셈이었죠.
넷째, 데이터셋 자체도 하나가 아니에요. MMLU 원본에는 정답이 틀렸거나 문제가 모호한 항목이 꽤 있어서, 이를 수정한 MMLU-Redux가 나왔고(연구진은 검토한 문제의 약 6.5%에 오류가 있다고 봤어요), 난이도를 올리고 보기를 10개로 늘린 MMLU-Pro도 있어요. 발표 자료에서 'MMLU'라고만 쓰면 이 중 어떤 걸 말하는지 알 수 없는 거죠.
벤치마크 이름이 고정해주지 않는 것들
글 제목처럼, 'MMLU'라는 이름은 문제 목록만 고정해줄 뿐이에요. 채점 방식, 프롬프트 형식, few-shot 개수, 사고 과정 허용 여부, 샘플링 온도, 답 파싱 규칙, 이 모든 게 이름 안에 들어 있지 않아요. 그래서 엄밀히 말하면 'MMLU 점수'는 없고, 'lm-eval-harness 특정 버전, 5-shot, 로그 확률 방식으로 잰 MMLU 점수'만 있는 거예요.
이건 소프트웨어 개발자라면 익숙한 문제예요. '테스트 통과했어요'라고만 하면 어떤 환경에서, 어떤 버전으로, 어떤 설정으로 돌렸는지 모르는 것과 같거든요. CI에서 재현 가능한 환경을 고정하듯이, 벤치마크도 평가 하네스 버전과 설정을 같이 적어야 비로소 비교가 가능해져요.
2026년에 이 이야기가 여전히 중요한 이유
사실 MMLU는 이제 최상위 모델들이 90% 근처에 다 몰려 있어서 변별력이 거의 없어졌어요. 그래서 요즘 발표 자료는 GPQA Diamond, MMLU-Pro, Humanity's Last Exam, SWE-bench 같은 걸 더 앞세우죠. 그런데 문제는 이 새 벤치마크들도 똑같은 함정을 갖고 있다는 거예요. SWE-bench만 해도 Verified냐 Lite냐 Full이냐, 에이전트 스캐폴드가 뭐냐, 시도 횟수가 몇 번이냐에 따라 점수가 널뛰어요. MMLU에서 배운 교훈을 그대로 적용해야 하는 거죠.
한국 개발자한테 실질적으로 남는 것
한국어 모델을 다루는 분이라면 더 와닿을 거예요. KMMLU를 비롯한 한국어 벤치마크도 같은 구조라서, 국내 모델들 발표 자료에 나오는 점수를 비교할 때 '어떤 하네스, 몇 shot, 어떤 채점 방식'을 확인하지 않으면 잘못된 결론을 내리기 쉬워요.
실무에서 모델을 고를 때 이렇게 해보세요.
- 발표 자료의 점수를 그대로 믿지 말고, 같은 하네스(예: lm-evaluation-harness 특정 버전)로 후보 모델들을 직접 돌려서 비교하세요. 오픈소스 모델 몇 개 정도면 하루면 충분해요.
- 벤치마크 점수보다 여러분 서비스의 실제 데이터로 만든 작은 평가셋이 훨씬 신뢰할 만해요. 100문제라도 직접 만들어두면 모델을 바꿀 때마다 재사용할 수 있어요.
- 팀 내부에서 평가 결과를 공유할 땐 점수 옆에 반드시 설정을 적는 습관을 들이세요. 'MMLU 78.2 (lm-eval v0.4.3, 5-shot, loglikelihood)' 이런 식으로요.
정리하면
벤치마크 이름은 시험지만 정해줄 뿐, 채점 방식과 시험 환경은 정해주지 않아요. 점수를 볼 땐 반드시 '어떻게 쟀는지'를 같이 봐야 해요.
여러분은 모델 선택할 때 어떤 벤치마크를 가장 신뢰하시나요? 공개 리더보드 점수와 직접 돌려본 결과가 달라서 당황했던 경험이 있다면 공유해주세요.
🔗 출처: Hacker News