배경 및 맥락
AI 모델 경쟁이 빨라질수록 벤치마크 점수는 의사결정의 핵심 근거가 되지만, 실제로는 평가 조건과 출처가 제각각인 경우가 많다. 같은 이름의 benchmark라도 prompt template, sampling 설정, 모델 버전, evaluator 관계가 다르면 점수 해석이 달라진다.
Every Eval Ever는 이 문제를 평가 결과의 데이터 모델 문제로 다룬다. 다양한 리더보드, 연구 논문, 로컬 평가 결과를 하나의 schema와 공개 dataset으로 모아 비교 가능성과 재현성을 높이려는 프로젝트다.
핵심 내용
EvalEval 프로젝트 페이지는 Every Eval Ever를 unified open data format과 public dataset으로 설명한다. 스키마는 단순 점수만 저장하지 않고 source metadata, generation config, metric config, score details 같은 맥락을 함께 담는다. 예를 들어 temperature, top_p, max_tokens 같은 설정이 결과 해석에 영향을 주기 때문에 구조화된 필드로 남긴다.
GitHub 저장소는 evaluation data를 Hugging Face datastore의 data/{benchmark}/{developer}/{model} 구조로 배치하고, aggregate 결과는 {uuid}.json, optional instance-level 데이터는 {uuid}_samples.jsonl로 저장하는 방식을 설명한다. Hugging Face Hub 문서도 .eval_results/*.yaml 파일을 통해 모델 repo의 평가 점수가 모델 페이지와 benchmark leaderboard에 자동 표시될 수 있음을 보여준다.
경쟁 구도 / 비교
기존 모델 평가는 개별 leaderboard와 논문 표 중심이었다. 이 방식은 빠르게 공유되지만, 설정 차이와 출처 차이를 나중에 추적하기 어렵다. Every Eval Ever는 HELM, EleutherAI, Inspect, LiveCodeBench Pro, HF Open LLM Leaderboard v2 같은 여러 출처를 같은 메타데이터 구조로 다루려 한다.
이는 새로운 benchmark 자체라기보다 benchmark 결과를 다루는 공통 데이터 레이어에 가깝다. 모델 provider가 제시하는 최고 점수와 third-party evaluator가 재현한 점수를 같은 스키마 안에서 비교할 수 있으면, 평가 신뢰성과 감사 가능성이 올라간다.
의미
AI 도입 조직은 모델 점수를 그대로 신뢰하기보다 평가 데이터의 provenance와 실행 조건을 요구해야 한다. 특히 코드 생성, 보안, 에이전트, 도메인 특화 작업에서는 점수 하나보다 평가 환경과 실패 사례가 더 중요하다.
사내 ML 플랫폼은 모델 카드와 eval report를 문서가 아니라 queryable data로 관리하는 방향으로 가야 한다. Every Eval Ever 같은 스키마를 직접 쓰지 않더라도, 최소한 benchmark id, model version, prompt template, inference parameters, evaluator relationship, metric direction, sample-level trace를 표준 필드로 남기는 것이 필요하다.