LLM (Large Language Model)을 구축하는 동안, 여러분은 수많은 개입(interventions)을 거치며 모델을 반복해서 평가하게 됩니다. 데이터, 아키텍처(architecture), 또는 하이퍼파라미터(hyperparameters)에 대한 모든 조정과 규모(scale)를 키우는 모든 단계는 여러분을 동일한 루프로 되돌려 놓습니다. 즉, 벤치마크(benchmarks)를 추가하거나 재구성하고, 각 새로운 모델 체크포인트(checkpoint)에서 이를 다시 실행하며, 결과를 기록하고, 작은 실험에서 도움이 되었던 것이 전체 학습 실행(full training run)에서도 여전히 유효한지 확인하는 과정입니다.

대부분의 평가 도구는 이를 위해 설계되지 않았습니다. 완성된 모델에 대해 기존 벤치마크를 실행하도록 구축되었거나, 샌드박스(sandbox) 내에서 모델을 다단계 도구 사용 문제(tool-using problems)로 실행하도록 만들어졌을 뿐입니다. 이러한 도구들은 끊임없이 변화하는 모델의 속도를 따라가지 못하며, 특정 실제 환경 조건에서 모델이 어떻게 행동할지를 반영하지도 못합니다.

이러한 평가 과제를 해결하기 위한 우리의 지난 프로젝트는 OLMES(Open Language Model Evaluation Standard)였습니다. 2024년에 도입된 OLMES는 릴리스 간에 LLM 벤치마크 점수를 더 쉽게 비교할 수 있도록 고안되었습니다. 동일한 모델이라도 프롬프트 포맷팅(prompt formatting)이나 작업 구성(task formulation)과 같은 측면이 논문마다 다른 경우가 많아, 동일한 벤치마크를 서로 다른 방식으로 점수화했기 때문에 어떤 모델이 가장 성능이 좋은지에 대한 주장이 재현되지 않는 경우가 많았습니다. OLMES는 벤치마킹 선택 사항을 개방적이고 문서화된 표준으로 고정했으며, 이는 Olmo에서 Tulu에 이르기까지 우리의 오픈 모델을 평가하는 기초가 되었습니다.

하지만 모델의 최종 점수는 평가 프로세스의 일부일 뿐입니다. 이것이 바로 우리가 OLMES를 기반으로 구축하고 LLM 개발의 나머지 전 과정으로 확장한 새로운 워크벤치인 olmo-eval을 출시하는 이유입니다. OLMES와 비교했을 때, olmo-eval은 새로운 평가를 구현하는 작업을 줄여주고, 평가가 실행되는 위치와 방식을 정의하는 데 더 많은 유연성을 제공하며, 개별 구성 요소를 더 큰 워크플로(workflows)로 구성하는 것을 더 쉽게 만들어 줍니다. 에이전틱(Agentic) 및 멀티턴(multi-turn) 평가가 일급 사례(first-class use case)로 지원되며, 더 강력한 분석 도구는 특정 개입이 실제로 베이스라인(baseline)보다 개선되었는지, 아니면 그 차이가 노이즈(noise)에 불과한지를 판단하는 데 도움을 줍니다.

2.4pp의 성능 변화가 결론을 내리기에 충분한가요?

olmo-eval은 컨테이너화된 샌드박스 (sandboxed) 환경 내에서 AI 에이전트를 평가하기 위한 오픈 프레임워크인 Harbor와 몇 가지 면에서 겹치는 부분이 있습니다. 하지만 두 도구는 그 범위(scope)가 다릅니다. Harbor는 주로 에이전트 벤치마크 (benchmark)를 실행하고 게시하는 것을 목표로 합니다. 반면 olmo-eval은 모델 개발의 일상적인 작업—벤치마크를 추가 및 구성하고, 체크포인트 (checkpoint) 전반에 걸쳐 이를 실행하며, 단일 종합 점수가 아닌 프롬프트 (prompt)별로 결과를 분석하는 작업—을 위해 구축되었습니다.

Harbor는 모든 것을 밀봉된 재현 가능한 컨테이너 (container) 내부에서 동일한 방식으로 실행합니다. 컨테이너는 리소스 집약적 (resource-intensive)일 수 있기 때문에, olmo-eval은 대신 각 벤치마크가 어떻게 실행될지를 선택할 수 있게 해줍니다. 단순히 모델이 질문에 답하기만 하면 되는 벤치마크는 직접 실행할 수 있어 더 빠르고 저렴합니다. 반면 모델이 작성한 코드를 실행하는 것과 같이 격리된 환경이 필요한 벤치마크는 격리된 컨테이너 설정을 사용합니다. 가벼운 경로 (lightweight path)가 기본값이며, olmo-eval은 벤치마크가 실제로 필요로 할 때만 무거운 설정을 선택합니다.

Harbor의 벤치마크 추가 프로세스는 공개적으로 게시하고 공유할 계획인 평가 (eval)를 위해 구축되었으며, 그에 따른 추가적인 검증 단계를 포함합니다. olmo-eval은 개발 중에 빠르게 움직일 수 있도록 구축되었으며, 벤치마크를 추가하는 방식은 해당 벤치마크가 무엇을 필요로 하느냐에 따라 달라집니다. 기본적인 평가를 위한 짧은 정의, 모델이 벤치마크를 수행하는 동안 도구 (tool)를 사용할 수 있도록 하는 옵션, 또는 이미 자체 코드와 절차를 가진 벤치마크의 경우 olmo-eval이 이를 그대로 실행하고 다른 벤치마크 점수와 동일한 형식으로 결과를 보고할 수 있도록 하는 얇은 래퍼 (thin wrapper)가 있습니다.

Harbor와 olmo-eval 모두 런타임 정책(모델이 답변을 생성하기 위해 실행되는 방식)과 벤치마크를 분리하여 유지하므로, 하나를 다시 작성하지 않고도 다른 하나를 변경할 수 있습니다. 하지만 olmo-eval은 더 높은 모듈성 (modularity)을 위해 설계되었습니다. olmo-eval에서는 평가 대상 모델, 모델이 사용할 수 있는 도구, 컨테이너화된 환경, 그리고 LLM-as-a-judge와 같은 모든 보조 모델이 모두 교체 가능한 구성 요소입니다. 하나의 도구를 여러 하네스 (harness)에서 재사용하거나, 다른 벤치마크에 영향을 주지 않고 하나의 벤치마크에 채점 모델을 연결할 수 있으며, 적은 노력으로도 작은 설정(예: 프롬프트의 정확한 문구)을 조정할 수 있습니다.

Harbor는 각 모델에 대한 전체 점수를 보고합니다. olmo-eval 역시 해당 점수들을 보고하지만, 각 점수에는 표준 오차 (standard error)와 최소 탐지 가능 효과 (minimum detectable effect, 노이즈와 확실히 구별될 수 있는 가장 작은 차이)가 포함됩니다. 하지만 더 유용한 관점은 두 모델 체크포인트 간에 동일한 질문들을 나란히 배치하고, 다른 모든 조건은 고정된 상태에서 하나씩 비교하는 방식입니다. 이는 전체 평균의 미세한 변화가 실제 개선을 나타내는지, 아니면 단순히 노이즈인지 확인하는 데 도움을 줍니다.

olmo-eval은 각각 독립적으로도 유용하지만, LLM 개발 실험 루프를 더욱 긴밀하게 만들기 위해 함께 작동하도록 설계된 네 가지 구성 요소로 이루어져 있습니다:

벤치마크 로직을 런타임 정책(runtime policy)으로부터 분리하는 태스크/스위트/하네스(task/suite/harness) 추상화. 태스크(task)는 olmo-eval에서 벤치마크를 정의하는 방식, 즉 무엇을 평가할지를 의미합니다. 스위트(suite)는 태스크들을 함께 실행할 하나의 세트로 그룹화하며, 하네스(harness)는 각 태스크가 실행되는 방식을 제어합니다. 이러한 분리를 통해 측정 대상(what it measures)을 변경하지 않고도 동일한 태스크를 표준 베이스라인(baseline)으로 실행하거나, 도구(tools) 및 스캐폴딩(scaffolding)과 함께 실행할 수 있습니다.

비동기 샌드박스 플래너(asynchronous sandbox planner)를 포함한 샌드박스 및 역량 라우팅(capability-routing) 레이어. 이는 모델의 응답이 코드 작성 및 실행 또는 웹 브라우징과 같이 도구를 사용하여 수행하는 작업에 따라 달라지는 평가를 지원합니다. 핵심은 모델의 실제 도구 사용 능력을 평가하는 것입니다. 벤치마크가 도구를 요구할 때, olmo-eval은 해당 도구들을 실행하고 그 결과를 모델에 다시 전달합니다.

모든 실행, 구성(configuration), 결과를 동일한 구조화된 형식으로 기록하는 정규화된 실험 스키마(normalized experiment schema). 이를 통해 관련 실험들을 그룹화하고, 시간에 따른 체크포인트(checkpoint)를 비교하며, 장기적인 모델 개발 워크플로우에서 흔히 발생하는 불일치 문제를 방지할 수 있습니다.

쌍별(pairwise) 모델 비교를 위한 결과 뷰어: 두 모델 또는 체크포인트를 질문별로 나란히 배치하면, 전체 평균값에서는 숨겨질 수 있는 작지만 실질적인 성능 변화를 드러낼 수 있습니다.

대부분의 모델 평가 설정에서 벤치마크를 추가하는 것은 상당한 규모의 통합 프로젝트입니다. olmo-eval에서는 태스크(task)만 있으면 됩니다. 태스크는 벤치마크 데이터셋, 평가 요청이 구축되는 방식, 그리고 모델의 답변이 점수화되는 방식(모두 Python 코드로 작성됨)을 정의합니다:

from olmo_eval.common.formatters import ChatFormatter
from olmo_eval.common.metrics import AccuracyMetric
from olmo_eval.common.scorers import ExactMatchScorer
...

변형(Variants)은 벤치마크를 중복 생성하지 않고도 평가 정책의 변경 사항을 표현합니다:

register_variant("internal_freshqa", "3shot", num_fewshot=3, fewshot_seed=1234)
register_variant("internal_freshqa", "zero", num_fewshot=0)

스위트(Suites)는 벤치마크를 함께 실행하는 표준 세트로 그룹화합니다:

from olmo_eval.evals.suites import Suite, register
register(Suite(
name="base_qa_few_shot",
...

그리고 런타임 정책 (runtime policy)이 태스크 정의 (task definition)가 아닌 하네스 (harness)에 존재하기 때문에, 생성된 포인트 트랙 (point track)이 단순히 그럴듯해 보이는지에 의존하는 대신, 동일한 벤치마크를 서로 다른 실행 환경에서 쉽게 재실행할 수 있습니다.

# 베이스라인 (Baseline)
olmo-eval run -m my-instruct-checkpoint -t internal_freshqa:zero
# 동일한 태스크, 동일한 스코어링, search/tool 런타임 활성화
...

평가가 일회성 실행이 아닌 지속적인 모델 개발의 일부인 경우, 즉 재현 가능한 조건 하에서 체크포인트 (checkpoint) 전반에 걸쳐 동일한 벤치마크를 반복적으로 실행하고 집계 수준 및 질문별 수준 모두에서 개입 (intervention) 결과를 비교해야 할 때 olmo-eval을 사용하십시오.

만약 여러분의 반복되는 질문이 "이 체크포인트가 지난번 것과 어떻게 다르며, 정확히 어느 부분에서 개선되거나 퇴보했는가?"라면, 그것이 바로 olmo-eval이 구축된 워크플로우 (workflow)입니다.

재현 가능한 평가 (Reproducible evaluation)는 모델이 완성된 후 점수를 매기는 방식뿐만 아니라, 모델이 구축되는 방식과 발맞추어 나아가야 합니다. olmo-eval은 OLMES 표준을 활발한 모델 개발 단계로 가져오며, 커뮤니티가 이를 기반으로 발전할 수 있도록 공개적으로 출시합니다.