MMLU에서 95점을 받았다고 해서 당신의 모델이 올바른 페이지네이션(pagination) 쿼리를 작성할 수 있다는 뜻은 아닙니다. 저는 새벽 3시까지 평가(eval)를 반복하며, 저를 속이는 초록색 불빛들을 지켜보며 이 사실을 뼈아프게 배웠습니다.

코딩 작업, 에이전트 파이프라인(agentic pipelines), RAG 파이프라인 등 프로덕션 환경에서 1년 동안 LLM을 벤치마킹한 끝에, 저는 나름의 견해를 갖게 되었습니다. 그중 일부는 통념에 반하는 것이기도 합니다. 하지만 이 모든 견해는 어떤 리더보드(leaderboard)도 예측하지 못한 방식으로 모델이 실패하는 과정을 지켜보며 얻은 결과입니다.

벤치마크의 문제점

모든 진지한 AI 엔지니어링 팀은 결국 동일한 벽에 부딪힙니다. 벽에 붙은 숫자(벤치마크 점수)가 프로덕션에서의 숫자와 일치하지 않는다는 사실입니다.

MMLU, HumanEval, GSM8K — 이들은 최소한의 성능 확인(sanity checks) 용도로는 괜찮습니다. 만약 모델이 HumanEval에서 60% 미만의 점수를 받는다면, 무언가 심각하게 잘못된 것입니다. 하지만 그 반대는 성립하지 않습니다. HumanEval에서 92%를 기록했다고 해서, 그 모델이 당신의 47가지 특정 비즈니스 로직을 올바르게 처리할 수 있을지에 대해서는 거의 아무것도 알려주지 않습니다.

이유는 말로 내뱉으면 명확합니다. 이러한 벤치마크들은 특정 작업의 성능(task-specific performance)이 아니라 일반적인 능력(general capability)을 측정하기 위해 설계되었기 때문입니다. 당신의 프로덕션 유스케이스(use case)는 학습 데이터셋(training set)에 포함되어 있지 않습니다. 사용자들이 중요하게 생각하는 분포(distribution)는 벤치마크가 샘플링하는 분포와 다릅니다.

# 당신을 속이게 될 단순한 평가 설정
def naive_eval(model, test_cases):
    score = sum(
...

== 비교 연산자는 첫 번째 위험 신호입니다. 실제 출력값은 정확히 일치하는 경우가 거의 없습니다. 그리고 만약 당신의 테스트 케이스가 합성 데이터(synthetic data)라면(대부분이 그러하듯), 당신은 모델이 실제 사용자 입력을 처리하는 능력이 아니라, 합성 데이터의 패턴을 따르는 능력을 측정하고 있는 것입니다.

거짓말을 하지 않는 평가 하네스(Eval Harness) 구축하기

몇 달간 잘못된 신호들을 겪은 후, 저는 작은 평가 하네스(eval harness)를 구축했습니다. 연구 상을 받을 수준은 아니지만, 효과는 있습니다.

import json
from collections import defaultdict
from typing import Callable
...

여기서 얻은 핵심 통찰은 다음과 같습니다: 서로 다른 평가 케이스에는 서로 다른 판정관(judge)이 필요하다는 것입니다. 코드 출력에는 유닛 테스트(unit tests)가 필요합니다. 추론(reasoning) 출력에는 정교하게 설계된 프롬프트를 사용하는 LLM-as-judge 방식이 필요할 수 있습니다. 텍스트 분류(text classification)는 단순히 정확한 일치(exact match)만으로도 충분할 수 있습니다.

단 하나의 점수, 단 하나의 체크 유형, 단 하나의 데이터셋 — 이는 매번 당신을 잘못된 길로 인도할 것입니다.

아무도 말하지 않는 프로덕션의 함정 (The Production Trap)

저를 가장 힘들게 했던 문제는 바로 이것입니다: 평가 분포 드리프트 (eval distribution drift).

평가 프레임워크(harness)를 구축합니다. 테스트 케이스를 선정합니다. 훌륭한 점수를 얻습니다. 그리고 배포합니다. 3개월 후, 사용자들은 약간 다른 것을 요구하기 시작하고, 모델의 가중치(weights)는 업데이트되었으며, 평가 점수는 여전히 94%를 유지하고 있지만 프로덕션(production)의 에러율은 세 배로 급증합니다.

이런 일이 발생하는 이유는 평가 케이스가 부패하기 때문입니다. 현실 세계는 움직이지만, 당신의 테스트 케이스는 움직이지 않습니다.

# 평가 신선도 추적
def check_eval_freshness(dataset: list[dict], drift_threshold_days: int = 14) -> bool:
    from datetime datetime, timedelta
...

저는 이제 어떤 수치도 신뢰하기 전에 모든 평가 데이터셋에 대해 이 체크를 실행합니다. 오래된(stale) 평가는 평가가 없는 것보다 더 나쁩니다. 그것은 당신에게 잘못된 확신을 주기 때문입니다.

1,000번의 실행을 통해 배운 것들

다섯 가지 서로 다른 모델 제품군(model families)에 걸쳐 약 1,000번의 평가를 수행한 후, 변하지 않는 사실들은 다음과 같습니다:

1. 작업 특화 평가(Task-specific evals)가 일반 벤치마크보다 압도적으로 뛰어납니다. MMLU에서 200개의 실제 사용자 쿼리로 구성된 커스텀 데이터셋으로 전환했을 때, 프로덕션 성능과의 상관관계(correlation)가 ~0.3에서 ~0.7로 급증했습니다. 초기 비용을 들일 가치가 있습니다.

2. LLM-as-judge는 진정으로 유용하지만 가드레일(guardrails)이 필요합니다. 더 약한 모델의 출력을 판단하기 위해 GPT-4o를 사용하는 것은 놀라울 정도로 잘 작동합니다. 하지만 기술적으로는 틀렸지만 자신감 있게 들리는 출력에 대해 관대해지기 시작할 때 문제가 발생합니다. 20~30개의 사람이 라벨링한 골든 세트(golden set)로 보정(calibrate)하십시오.

3. 절대적인 점수보다 실행 간의 차이(delta)가 더 중요합니다. 모델 A가 85%를 기록하고 모델 B가 87%를 기록한다면, 저는 신경 쓰지 않습니다. 하지만 모델 A가 오늘 85%를 기록했다가 변경 후 내일 91%를 기록한다면, 그것은 유의미한 신호(signal)입니다. 절대값이 아닌 차이(deltas)를 추적하십시오.

4. 평가 누수(Eval leakage)는 실제로 존재하며 놓치기 쉽습니다. 모델이 학습 과정에서 보았을 가능성이 있는 데이터에서 테스트 케이스를 샘플링하고 있다면, 당신은 추론(reasoning)이 아니라 암기(memorization)를 측정하고 있는 것입니다. 홀드아웃 세트(held-out sets)를 사용하십시오. 무엇인가를 신뢰하기 전에 데이터 파이프라인을 점검하십시오.

5. 빠른 피드백 루프(Fast feedback loops)가 포괄적인 평가보다 낫습니다. 6시간 동안 똑같은 결과를 알려주는 500번의 포괄적인 평가보다, 10분 만에 "무언가 잘못되었다"라고 알려주는 50번의 빠른 평가를 수행하는 편이 훨씬 낫습니다. 초기 단계부터 반복 속도(iteration speed)를 위해 구축하십시오.

내가 배운 것들

최고의 평가(eval)는 모델을 좋아 보이게 만드는 것이 아니라, 사용자가 무엇을 경험할지를 예측하는 것입니다.

일반적인 벤치마크(Generic benchmarks)는 필요한 시작점이지만, 이는 바닥일 뿐 천장이 아닙니다. 만약 여러분이 실제 사용자에게 LLM 기반 기능을 출시하면서 오직 MMLU나 HumanEval에만 기반하여 의사결정을 내리고 있다면, 눈을 가리고 비행하는 것과 같습니다.

태스크 특화형 평가 데이터셋(task-specific eval datasets)에 투자하십시오. 다양한 판단 방법(judgment methods)을 지원하는 하네스(harness)를 구축하십시오. 최신성(freshness)을 추적하십시오. 그리고 훌륭한 엔지니어링을 위해서라도: 실제 사용자가 보게 될 대상이 아닌, 그것과 느슨하게 상관관계가 있는 대리 지표(proxy)가 아니라 실제 대상에 대해 평가를 수행하십시오.

여러분의 벤치마크에서 모델이 기록한 95% 점수는 아마 여러분이 생각하는 의미와 다를 가능성이 높습니다. 실제 운영 환경에서의 에러율(production error rate)만이 실제로 의미 있는 유일한 점수입니다.