모델 벤치마크를 신뢰하는 대신 나만의 평가 세트(Eval Set)를 운영하기 시작하며 변화된 점
요약
공개 벤치마크의 한계를 지적하며, 실제 운영 트래픽을 기반으로 한 자체 평가 세트(Eval Set) 구축의 중요성을 강조합니다. 모델의 성능을 객관적으로 비교하기 위해 데이터 분포를 고정하고 실행 환경의 변수를 통제하는 방법론을 제시합니다.
핵심 포인트
- 벤더 자체 벤치마크는 실제 워크로드 성능을 보장하지 않음
- 실제 운영 트래픽 기반의 고정된 평가 세트 구축 필요
- 비교의 공정성을 위해 프롬프트 순서 및 실행 환경 통제 필수
- 공개 리더보드 순위와 실제 서비스 적합성은 다를 수 있음
최근 출판된 벤치마크(Benchmarks)에 대한 제 신뢰를 깨뜨린 세 가지 이유가 있습니다.
첫째, Kimi K2.7 Code는 Kimi Code Bench v2에서 21.8%, Program Bench에서 11%, MLS Bench Lite에서 31.5%의 성능 향상을 기록하며 출시되었습니다. 이 세 가지 모두 Moonshot 자체의 벤치마크입니다. 모델 간에 실제로 의미 있는 차이를 만들어내는 유일한 독립적인 코딩 벤치마크인 DeepSWE에는 아무것도 제출되지 않았습니다. 벤더(Vendor)가 직접 설계하고 제어하는 벤치마크에서 성능 향상을 보고할 때, 그 향상은 실제적이긴 하지만 그들이 답하는 질문은 "우리가 우리 자신의 테스트에 더 뛰어난가"이지, "우리가 당신의 워크로드(Workload)에 더 뛰어난가"가 아닙니다.
둘째, GLM-5.2는 제3자 기관인 Artificial Analysis Intelligence Index에서 51점을 기록했지만, 모델 파라미터(Parameters)는 자체 보고된 것입니다. 이 인덱스는 Artificial Analysis 방법론 내에서의 상대적 순위를 매기는 데는 유용합니다. 하지만 제 제품이 보내는 특정 입력 분포(Distribution of inputs)에서 모델이 어떻게 작동할지를 예측해주지는 않습니다.
셋째, Seed 2.1이 막 출시되었으나 공식 정보가 빈약합니다. 아직 명확한 공개 평가(Eval)도 없고, 제가 찾을 수 있는 제3자 리더보드(Leaderboard) 항목도 없습니다. 따라서 현재로서는 "Seed 2.1은 좋다"라는 말이 제가 어느 쪽으로든 검증할 수 없는 주장일 뿐입니다.
제가 한 일은 실제 운영 트래픽(Production traffic)으로부터 작은 평가 세트(Eval set)를 구축하는 것이었습니다. 실제 사용 분포 전반에 걸쳐 샘플링된 약 240개의 태스크(Tasks)로 구성되었으며, 데이터가 변하지 않도록 고정(Frozen)했습니다. 제가 고려하는 모든 모델은 이 240개를 모두 실행해야 하며, 저는 통과율(Pass rate), 지연 시간(Latency), 토큰 비용(Token cost), 그리고 해당 태스크 영역을 담당하는 담당자의 주관적 품질 점수를 기록합니다. 이는 공개된 벤치마크만큼 엄격하지 않고 확실히 규모도 작지만, 공개된 벤치마크에는 없는 한 가지 속성, 즉 '나의 분포(My distribution)'라는 점을 가지고 있습니다.
제가 예상했던 것보다 더 중요했던 구현 세부 사항은 실행 자체에서 제공자 편차(Provider variance)를 제거하는 것이었습니다. 저는 모든 후보 모델을 GPTProto를 통해 라우팅하여, 각 모델이 정확히 동일한 240개의 프롬프트(Prompts)를 동일한 순서로 받도록 합니다. 이를 통해 비용과 지연 시간이 다섯 개의 대시보드가 아닌 하나의 로그 스키마(Log schema)로 돌아오게 됩니다.
자체 제작한 심(Shim)도 동일한 역할을 수행할 수 있습니다. 핵심은 제품 자체가 아니라, 모델을 제외한 모든 조건이 일정하게 유지될 때만 공정한 비교가 가능하다는 점입니다.
그 결과는 겸허해지는 경험을 선사했습니다. 우리의 평가 세트(Eval set)에서 승리하는 모델이 항상 공개 리더보드(Public leaderboard)의 최상단에 있는 것은 아니었으며, 우리 세트에서의 1위와 2위 사이의 격차는 보도 자료가 암시하는 격차보다 훨씬 작았습니다. 또한, 벤치마크 성능은 훌륭했지만 우리의 롱테일(Long tail) 엣지 케이스(Edge case) 프롬프트들에서 심각한 실패 모드(Failure mode)를 보인 모델을 하나 발견하기도 했습니다. 만약 이를 그대로 출시했다면 운영 사고(Production incident)로 이어졌을 것입니다.
공개 벤치마크가 쓸모없다는 뜻은 아닙니다. 후보군을 좁히는 데에는 유용합니다. 하지만 실제로 어떤 모델을 사용자 앞에 내놓을지에 대한 결정은 여러분만의 데이터로 내려야 합니다. 그리고 평가 세트(Eval set)는 반드시 동결(Frozen)되고 버전 관리(Versioned)되어야 합니다. 그렇지 않으면 평가 세트는 조용히 "현재 모델이 잘하는 것들"로 변질되어, 더 이상 아무것도 측정하지 못하게 될 것입니다.
submitted by /u/Additional-Engine402 to r/MachineLearning
[link] [comments]
AI 자동 생성 콘텐츠
본 콘텐츠는 r/OpenAI Codex (search)의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기