요약 (TL;DR) — 리더보드 점수는 샘플링된 분포의 평균값일 뿐이지만, 실제 서비스(Production)에서의 리스크는 평균이 아니라 오류가 어떻게 분포되어 있는지에 달려 있습니다. 두 모델이 동일한 벤치마크 점수를 기록하더라도 실패의 기하학적 구조(Failure geometries)는 정반대일 수 있습니다. 하나는 무작위로 실패하는 반면, 다른 하나는 당신이 중요하게 생각하는 특정 하위 집단(Subpopulation)에서 체계적으로 실패할 수 있습니다. 오류의 상관관계 구조(Error correlation structure)를 무시한 채 리더보드 점수 1.5점을 올리는 데 집착하는 것은 잘못된 통계량을 최적화하는 것입니다.

모든 모델 카드(Model card)에는 스칼라(Scalar) 값이 포함되어 배포됩니다. 어떤 추론 제품군(Reasoning suite)에서는 78.3점, 어떤 코딩 벤치마크에서는 91점과 같은 식입니다. 팀들은 스포츠 팬들이 타율을 비교하듯 이 숫자들을 비교하며, 단 1.5점의 차이를 근거로 도입 결정을 내립니다. 하지만 그 차이는 매우 빈번하게 통계적 노이즈(Statistical noise)에 불과합니다. 더 나쁜 것은, 그 차이가 실제 존재하더라도 스칼라 값 자체가 당신이 묻지 않은 질문에 답하고 있다는 점입니다.

벤치마크 점수는 하나의 분포에 대한 평균(Mean)의 추정치입니다. 이는 벤치마크 작성자들이 샘플링하기로 결정한 특정 분포에서 추출된 프롬프트(Prompts) 샘플 전체에 대한 평균적인 정확도입니다. 이를 계산하는 것 자체는 전혀 문제가 없습니다. 하지만 이를 "이 모델이 내 서비스에서 실패할 것인가?"에 대한 대리 지표(Proxy)로 취급하는 것은 잘못된 일입니다. 실제 서비스(Production)의 리스크는 평균에 대한 진술이 아닙니다. 그것은 꼬리 부분(Tail)에 대한 진술이며, 당신의 트래픽 중 어느 조각(Slice)이 그 꼬리 부분에 위치하느냐에 대한 문제입니다.

스칼라는 드러내기보다 더 많은 것을 숨긴다

만 개의 프롬프트에 걸친 모델의 성능을 하나의 숫자로 압축하면, 오류의 형태(Shape of its errors)에 관한 모든 정보를 버리는 셈이 됩니다. 두 모델은 완전히 다른 실패 기하학(Failure geometries)을 가질 수 있음에도 불구하고, 정확히 동일한 총체적 정확도(Aggregate accuracy)를 기록할 수 있습니다.

모델 A는 모든 카테고리, 모든 언어, 모든 난이도 계층에 걸쳐 대략 균등하게 분포된 5%의 프롬프트를 놓칩니다. 이 모델의 오류는 동일한 노이즈 프로세스(noise process)에서 독립적으로 추출된 값에 가깝습니다. 모델 B 역시 5%를 놓치지만, 그 실패 사례의 거의 대부분이 하나의 하위 집단(subpopulation) — 부정문이 많은 질문, 특정 언어, 다단계 산술(multi-hop arithmetic) 등 무엇이든 간에 — 에 집중되어 있습니다. 점수는 같습니다. 하지만 위험 프로필(risk profile)은 근본적으로 다릅니다.

만약 귀하의 실제 서비스 트래픽(production traffic)이 우연히 모델 B가 취약한 부분에 집중되어 있다면, 벤치마크 대시보드는 모든 것이 정상이라고 말하는 동안 귀하는 끊임없이 피해를 입게 될 것입니다. 반대로 귀하의 트래픽이 해당 하위 집단에 전혀 닿지 않는다면, 모델 B는 리더보드 상에서는 구별할 수 없더라도 귀하에게는 엄밀히 말해 더 나은, 실제로 더 안전한 선택이 될 수 있습니다. 벤치마크는 오류의 상관 구조(correlation structure)를 보고하지 않기 때문에, 귀하가 어떤 상황에 처해 있는지 알려줄 수 없습니다. 벤치마크는 평균(mean)을 보고하고 그것으로 끝내버립니다.

상관된 실패(Correlated failure)는 무작위 실패(random failure)와는 다른 종류의 위험이다

이러한 구분은 매우 중요한데, 상관된 실패는 무작위 실패가 하지 못하는 방식으로 문제를 증폭시키기 때문입니다. 만약 모델이 특정 기본율(baseline rate)로 독립적으로 실패한다면, 사용량이 늘어남에 따라 시스템 수준의 오류율은 완만하고 어느 정도 예측 가능한 방식으로 저하됩니다. 즉, 통계적으로 추론할 수 있고, 재시도(retries) 및 폴백(fallbacks)을 구축할 수 있으며, 실패가 특정 사용자, 워크플로 또는 고객 세그먼트에 집중되지 않습니다.

하위 집단에 대한 체계적 실패(Systematic failure)는 그 반대입니다. 이는 귀하의 집계 지표(aggregate metrics)가 건강해 보이는 동안, 특정 계층의 사용자가 모델을 매번 고장 난 것처럼 경험하게 된다는 것을 의미합니다. 이는 제품의 특정 영역 — 예를 들어 날짜 산술과 관련된 모든 것이나 특정 지역(locale)과 관련된 모든 것 — 이 조용히 신뢰할 수 없게 될 수 있음을 의미합니다. 벤치마크의 해당 하위 집단 샘플이 너무 적어 집계 수치가 거의 변하지 않기 때문에, 리더보드의 숫자는 릴리스가 거듭될수록 계속 상승하는 동안에도 말입니다.

이는 고전적인 머신러닝 (ML) 공정성 (fairness) 및 강건성 (robustness) 문헌에서 나타나는 것과 동일한 실패 모드이며, 단지 LLM을 위해 이름만 바뀌었을 뿐입니다. 전체적인 정확도 (accuracy)가 높은 분류기 (classifier)라 할지라도, 평가 샘플에서 특정 소수 하위 집단 (minority subgroup)이 과소 대표된다면 해당 집단에게는 재앙적인 결과를 초래할 수 있습니다. 생성 모델 (generative models)을 위한 벤치마크 역시 동일한 구조적 약점을 가지고 있습니다. 다만 이들은 이를 하위 집단 정확도 대신 추론 능력 (reasoning ability)으로 포장할 뿐이며, 이로 인해 문제가 동일하다는 사실을 잊기 더 쉽게 만듭니다.

신뢰 구간 (Confidence intervals)은 모두가 건너뛰는 부분입니다

벤치마크 점수는 샘플링 분산 (sampling variance)을 가진 점 추정치 (point estimate)이며, 그 주변의 구간을 보고하는 사람은 거의 없습니다. 만약 벤치마크 항목이 수천 개 정도이고 모델이 경쟁사와 1~2점 차이로 점수를 기록한다면, 그 격차는 테스트 세트를 재샘플링 (resampling)했을 때 얻게 될 신뢰 구간 (confidence interval) 안에 포함되는 경우가 빈번합니다. 이 격차를 의미 있는 능력 차이로 취급하는 것은 측정 노이즈 (measurement noise)를 신호 (signal)로 취급하는 것과 같습니다.

아이러니하게도 이는 이미 해결된 통계적 문제입니다. 테스트 세트를 부트스트랩 (bootstrap)하고, 구간을 보고하며, 리더보드 순위가 완전 순서 (total order)인 척하는 것을 멈추기만 하면 됩니다. 실제로는 중첩된 분포 (overlapping distributions)들의 집합에 더 가깝습니다. 공개된 리더보드 중 이를 수행하는 곳은 매우 드문데, 이는 정렬 가능한 단일 열이 오차 막대 (error bar)보다 더 나은 제품이기 때문입니다. 이는 리더보드 웹사이트 입장에서는 정당한 UX 결정입니다. 하지만 유료 사용자에게 어떤 모델을 제공할지 결정하는 엔지니어링 팀에게는 잘못된 결정입니다.

무엇이

• 평균을 내기 전에 슬라이스(Slice) 하세요. 평가 세트(Eval set)를 실제 제품의 접점과 매핑되는 하위 집단(Subpopulations) — 의도 유형(Intent types), 언어, 입력 길이, 도메인 등 — 으로 나누고, 전체적인 수치뿐만 아니라 각 슬라이스별 정확도를 보고하세요. 전체 수치는 개별적으로 살펴봐야 할 슬라이스들의 가중 평균(Weighted average)일 뿐입니다.

• 평균적인 슬라이스가 아니라, 최악의 슬라이스를 보고하세요. 모델의 평균값보다 최저점(Floor)이 실제 서비스(Production)의 리스크를 더 잘 알려줍니다. 왜냐하면 실제 서비스는 평균을 경험하는 것이 아니라, 특정 사용자의 트래픽이 우연히 도달하게 되는 바로 그 슬라이스를 경험하기 때문입니다.

• 오류율(Error rate)뿐만 아니라 오류 상관관계(Error correlation)를 살펴보세요. 오류율이 동일한 두 모델이라도 결합된 실패 패턴(Joint failure patterns)은 판이하게 다를 수 있습니다. 만약 앙상블(Ensemble), 폴백 체인(Fallback chain), 또는 라우터(Router)에 두 모델을 사용하고 있다면, 각 모델이 단독으로는 괜찮아 보일지라도 두 모델 사이의 오류가 상관되어 있다면 중복성(Redundancy)은 전혀 제공되지 않습니다.

• 평가 분포(Eval distribution)를 벤치마크 작성자의 분포가 아닌, 실제 서비스의 분포(Production distribution)에 맞추세요. 일반적인 추론 능력을 순위 매기기 위해 구축된 벤치마크는 '무엇이 중요한가'에 대한 타인의 관점에서 샘플링된 것입니다. 만약 귀하의 실제 서비스 트래픽이 해당 샘플과 전혀 다르다면, 벤치마크의 평균값은 귀하가 운영하지 않는 분포를 추정하고 있는 것입니다.

• 리더보드의 작은 차이는 증명되기 전까지 노이즈로 취급하세요. 재샘플링(Resampling)을 통해 얻을 수 있는 구간(Interval)보다 작은 차이를 근거로 모델 교체 결정을 내리기 전에, 귀하의 평가 세트에 대해 부트스트랩(Bootstrap)을 수행하세요.

불편한 부분

이 중 어느 것도 생소한 통계학이 아닙니다. 이는 고전적인 머신러닝(ML) 평가에서는 완전히 표준이었던 엄격함이지만, 분야가 더 예쁜 리더보드를 가진 생성형 벤치마크(Generative benchmarks)로 이동하면서 어찌 된 일인지 누락된 것입니다. 스칼라(Scalar) 값은 슬라이드에 넣기 쉽고 회의에서 논쟁하기 쉽기 때문에 유혹적입니다. 하지만 그 숫자는 실제 서비스에서 무엇이 고장 나는지를 측정해 온 적이 없습니다. 그것은 단지 분포에 대한 평균을 측정해 왔을 뿐입니다.