흩어진 벤치마크 점수와 EEE의 등장 (2026년 2월)

동일한 모델인데 논문마다, 혹은 리더보드마다 벤치마크 점수가 다르게 표기되어 어떤 수치를 믿어야 할지 혼란스러웠던 경험이 있을 것이다. 실제로 LLaMA 65B 모델의 MMLU 점수는 보고 주체와 방식에 따라 63.7점과 48.8점이라는 큰 격차로 기록된 사례가 존재한다. 이러한 수치 불일치 문제를 해결하기 위해 2026년 2월 EvalEval 연합의 EEE(Every Eval Ever) 프로젝트와 허깅페이스의 커뮤니티 평가(Community Evals)가 동시에 출시됐다. 이는 평가 결과 보고 방식을 개선하기 위해 여러 기관이 협력한 첫 번째 시도이며, 허깅페이스 허브에서 벤치마크 점수가 보고되는 방식을 탈중앙화한다.

모델 성능 수치가 제각각으로 나타나는 핵심 이유는 평가 설정값이 제대로 보고되지 않기 때문이다. EEE는 보고 단계의 누락을 막기 위해 31가지의 서로 다른 보고 형식을 하나의 JSON 스키마로 통합했다. 하네스 로그나 리더보드 스크래핑 결과, 논문에 기재된 숫자까지 모두 동일한 규격으로 변환해 기록하는 방식이다. 이를 통해 어떤 소스에서 온 결과든 동일한 형태로 저장하여 데이터의 일관성을 유지하고 성능 비교의 기준점을 마련했다.

현재 EEE 데이터스토어에는 22,000개 이상의 모델과 2,200개 벤치마크에 걸친 약 229,000건의 평가 결과가 축적되어 있다. 이 정도 규모의 평가 데이터를 처음부터 다시 재현하려면 수십만 달러의 비용이 발생할 것으로 예상된다. EEE는 개별 논문이나 리더보드, 블로그 포스트 속에 흩어져 사라지는 데이터를 구조화된 레코드로 보관하여, 서로 다른 환경에서 측정된 수치를 동일 선상에서 비교 가능하게 보존하는 데 집중했다.

JSON에서 YAML로, 허깅페이스 연동 컨버터 작동 방식

허깅페이스 모델 카드에서 점수 옆에 붙은 작은 배지를 클릭하면 상세 설정 페이지로 바로 연결된다. 이 연결은 EEE JSON 데이터를 허깅페이스가 요구하는 YAML 파일로 자동 변환해 배포하는 파이프라인 덕분에 가능하다. 컨버터가 EEE 레코드를 읽어 허깅페이스 모델 저장소의 `.eval_results/*.yaml` 경로에 맞는 파일로 생성하므로, 실무자가 수동으로 두 가지 형식을 유지할 필요 없이 보고 체계를 일원화할 수 있다.

컨버터는 구체적인 데이터 매핑 규칙을 통해 정보를 옮긴다. `source_data.hf_repo`는 `dataset.id`로, `evaluation_name`은 `task_id`로, `score_details.score`는 `value`로, `evaluation_timestamp`는 `date`로 각각 변환된다. 여기에 EEE 데이터스토어의 개별 레코드 URL을 소스 링크로 추가해, 사용자가 모델 카드에서 본 수치가 어떤 생성 설정과 하네스 버전을 통해 도출되었는지 즉시 확인할 수 있게 했다. 현재 이 자동 변환을 지원하는 공식 벤치마크는 MMLU-Pro, GPQA, HLE, GSM8K 총 4종이다.

데이터의 무결성을 확인하는 검증 로직도 포함되어 있다. 컨버터는 지정된 EEE 데이터스토어 컬렉션을 다운로드하고 참조 레코드의 오브젝트 해시를 대조하여 데이터 변조 여부를 확인한다. 이후 모델의 메인 브랜치와 PR(Pull Request) 내 모든 YAML 파일을 읽어 데이터셋과 태스크 단위로 기존 점수와 비교한다. 이미 동일한 점수가 있으면 `already_present`로, 다른 점수가 기록되어 있으면 `score_conflict`로, 허깅페이스 저장소를 찾을 수 없으면 `missing_hf_model`로 분류하며, 검증을 통과한 항목만 제출 가능한 `ready` 상태가 된다.

실제 실행은 터미널에서 컬렉션 ID를 지정하는 명령어로 시작한다.

python -m ee_hf_converter --collection [COLLECTION_ID]

명령어를 입력하면 로컬에 YAML 미리보기와 리뷰 파일이 생성되며, 사용자가 내용을 확인한 뒤 `OPEN PRS`라고 입력해야 실제 저장소에 PR이 제출된다. 리뷰 단계에서는 제외된 항목들의 EEE 소스 URL이 함께 나열되어 누락 원인을 분석할 수 있으며, 재실행 시에는 `--force` 옵션을 주지 않는 한 캐시된 결과를 재사용한다. 상세한 스키마와 CLI 사용법은 evalevalai.com/every_eval_ever/hf-community-evals에서 확인할 수 있다.

가시성의 허깅페이스 vs 해석력의 EEE

허깅페이스 커뮤니티 평가(Community Evals)는 벤치마크 등록과 점수 저장 방식을 분리해 설정값 차이로 인한 점수 왜곡 문제를 해결한다. 벤치마크는 데이터셋 저장소의 `eval.yaml` 파일로 자신을 등록하고, 등록된 데이터셋 페이지가 허브 전체에서 보고된 모든 점수를 수집해 리더보드로 보여준다. 개별 모델의 점수는 모델 저장소 내 `.eval_results/*.yaml` 경로에 저장되어 모델 카드에 표시된다.

EEE 데이터스토어는 점수 뒤에 숨은 생성 설정(generation config), 하네스 버전, 재현성 노트, 인스턴스 수준의 데이터 같은 상세 구조화 레코드를 보관하는 저장소 역할을 한다. 허깅페이스 모델 카드에 표시된 점수에 부착된 'Source EvalEval' 배지를 클릭하면 해당 점수의 근거가 되는 EEE의 전체 JSON 레코드로 직접 연결된다. 사용자가 모델을 찾는 접점인 허깅페이스와 평가의 세부 근거를 확인하는 저장소인 EEE를 상호 연결해 보완하는 방식이다.

데이터 제출 과정은 탈중앙화된 방식으로 운영된다. 평가자는 적절한 YAML 파일을 포함해 모델 저장소에 PR을 보내 점수를 추가할 수 있으며, 이 결과는 자동으로 모델 카드와 벤치마크 리더보드에 집계된다. 모델 작성자는 자신의 저장소에 제출된 커뮤니티 PR을 검토한 뒤 닫거나 특정 결과를 숨길 수 있는 권한을 가져 무분별한 데이터 입력을 방지한다. 모델 작성자의 공식 허깅페이스 계정을 통해 제출된 데이터는 EvalEval에서 인증 체크마크를 부여받아 출처를 명확히 한다.

수십만 달러의 비용 절감과 실무적 신뢰 기준

새로운 모델 출시 주기가 짧아지면서 실무자가 개별 모델의 성능을 일일이 검증하는 것은 물리적으로 불가능해졌다. EEE가 31가지 보고 형식을 JSON으로 통합함으로써, 이미 누군가 막대한 컴퓨팅 자원을 투입해 생성한 데이터를 중복 투자 없이 즉시 실무 워크플로에 투입할 수 있는 기반이 마련되었다. 이는 개별 기업이 벤치마크 환경을 구축하는 데 드는 초기 설정 비용과 운영 리소스를 줄여준다.

데이터의 신뢰성은 공식 인증과 투명한 기여 과정으로 판별한다. 모델 개발사가 공식 계정으로 제출한 데이터에 부여되는 인증 체크마크는 데이터의 정통성을 보증하며, 커뮤니티의 PR을 통한 교차 검증은 특정 벤치마크 점수가 과장되었을 가능성을 낮추는 근거가 된다.

실무자는 모델 카드에서 확인한 점수와 그 수치를 도출한 상세 설정을 동시에 확보함으로써 모델 선택 리스크를 최소화한다. EEE 레코드에 기록된 생성 설정과 하네스 버전을 자신의 환경과 대조하면, 특정 프롬프트나 샘플링 설정 하나로 점수가 요동치는 LLM 평가의 특성 속에서도 모델의 실제 성능을 가늠할 수 있다. 수십만 달러의 비용을 들여 모든 후보 모델을 직접 재평가하는 대신, 표준화된 스키마를 통해 성능의 재현성을 확인하고 신뢰도를 검증하는 실무적 판단 기준을 확보하게 된다.

결국 이 시스템의 핵심은 논문에 적힌 수치와 실제 현장에서 측정되는 성능 사이의 간극을 좁히는 데 있다. 실무자는 이제 리더보드의 순위라는 단편적인 정보에 의존하지 않고, 데이터의 출처와 설정값이라는 구체적인 근거를 바탕으로 모델을 선택한다.

리더보드의 점수가 모델마다 제각각이었던 혼란은 보고 형식의 파편화에서 왔다. EEE가 31가지 형식을 JSON으로 통합하고 이를 허깅페이스 YAML로 변환해 제출하는 체계를 갖추면서, 실무자는 수십만 달러의 재평가 비용을 들이지 않고도 성능의 재현성을 즉시 확인할 수 있게 되었다.

이제는 단순한 수치 경쟁이 아니라 모델 카드의 배지를 통해 상세 설정값을 대조하는 것이 실무적인 검증의 시작이다. 표준화된 스키마로 수치의 배후를 읽어내는 능력이 모델 선택의 리스크를 결정한다.