우리가 기본 평가(Eval) 모델을 변경하는 이유

우리는 평가 하네스(eval harness)의 기본 솔버(solver) 모델을 Claude Sonnet 4.6에서 GLM 5.1로 변경합니다. 이는 플랫폼에서 평가를 실행하는 모든 사용자에게 제공되는 기본 설정입니다. 하네스가 수행하는 대부분의 작업에서, 프런티어 모델(frontier model)은 가능한 가장 강력한 신호(signal)를 제공합니다. 하지만 이는 작업에 필요한 것보다 과도한 신호이며, 이 차이가 평가 예산(eval budgets)을 조용히 낭비하게 만드는 지점입니다. 여러분이 얼마나 지불해야 하는지를 결정하는 질문은, 주어진 평가 실행이 모델을 측정하는 것인지 아니면 기술(skill)을 측정하는 것인지에 달려 있습니다.

그 이면에 있는 원칙은 다음과 같습니다: 모델 자체가 중요할 때만 모델을 특정하십시오. 여러분의 평가 목적이 "이 특정 모델이 잘 작동하는가?"라는 질문에 답하기 위한 것이라면, 반드시 해당 모델을 그대로 실행해야 합니다. 반면, "이 기술이 에이전트의 행동을 개선하는가, 그리고 퇴보(regression)한 부분은 없는가?"라는 질문에 답하기 위한 것이라면, 특정 모델이 필요한 것이 아니라 대표성 있는 모델이 필요합니다.

우리는 자체적인 skill-evaluation harness를 통해 이를 테스트했으며, 기존 기본 모델이었던 Sonnet 4.6과 비교하여 GLM 5.1의 유효성을 검증했습니다. 기술 저자들이 의존하는 신호는 거의 잃지 않으면서도, 평가 비용(eval bill)은 낮아졌습니다. 이 포스트는 이번 교체의 근거와 여러분의 평가 스택(eval stack)에 적용할 수 있는 프레임워크를 다룹니다.

두 가지 질문, 하나의 평가 하네스

우리의 하네스는 대규모 기술 평가 스위트(skill-evaluation suite)를 실행합니다: 약 850개의 태스크(tasks)에 걸쳐 약 500개의 기술을 실행하며, 각 태스크는 기술이 있을 때와 없을 때를 각각 두 번씩 실행합니다. 우리는 세 가지를 점수화합니다: 지시 이행(instruction following, 에이전트가 기술이 지시한 대로 수행했는가), 태스크 완료(task completion, 목표에 도달했는가), 그리고 지시 이행에 가중치를 둔 종합적인 혼합 점수입니다.

리프트(Lift)는 기술이 있을 때와 없을 때의 에이전트 행동 차이를 의미하며, 기술 저자들이 확인하는 수치입니다. 왜냐하면 리프트는 모델의 베이스라인(baseline)으로부터 기술의 효과만을 분리해내기 때문입니다.

매 실행 시마다 두 개의 모델이 작동합니다. 판사(Judge)는 궤적(trajectories)을 채점하며, 우리는 이 판사를 고정된 강력한 모델로 유지합니다. 왜냐하면 루브릭(rubric)에 따른 판사의 채점이 리프트(lift)를 결정하기 때문입니다. 해결사(Solver)는 작업을 수행하는 에이전트이며, 이는 자유 변수(free variable)입니다. 각 에이전트의 궤적은 판정 단계보다 길기 때문에, 해결사가 평가 비용(eval cost)을 지배합니다. 따라서 실질적인 질문은 리프트 신호(lift signal)를 잃지 않으면서 기본 해결사를 더 저렴한 것으로 교체할 수 있는가 하는 점입니다.

이에 답하기 위해서는 여러분의 하네스(harness)가 다음 두 질문 중 어떤 것에 답하고 있는지 알아야 합니다.

첫 번째는 "이 특정 모델이 잘 작동하는가?"입니다. 만약 어떤 모델을 프로덕션(production)에 투입할지 결정하는 상황이라면, 모델 자체가 주체이므로 그 어떤 대리 모델(proxy)도 대신할 수 없습니다. 두 번째는 "이 기술(skill)이 에이전트의 행동을 변화시키며, 퇴보(regress)하지 않는가?"입니다. 여기서 모델은 주체가 아니라 기술을 읽어내기 위한 도구(instrument)이며, 도구는 여러분이 조치할 신호를 재현할 수 있을 만큼만 충분히 정확하면 됩니다.

일상적인 기술 개발의 대부분은 두 번째 질문에 해당합니다. 여러분은 기술을 반복적으로 개선하며 리프트가 올라가는지 관찰하고, 퇴보를 방지합니다. 하위의 특정 해결사가 프런티어(frontier) 모델을 충분히 밀접하게 추적할 수만 있다면, 해결사 자체는 거의 중요하지 않습니다. 이러한 작업에 적합한 기본 설정은 리프트를 충실히 재현하는 가장 저렴한 모델입니다.

매 실행마다 프런티어 가격을 지불하지 않고 AI 에이전트를 평가하는 방법

당연한 반론이 있을 수 있습니다: 더 저렴한 모델은 성능이 떨어지기 때문에 저렴한 것이므로, 신호도 함께 저하되지 않겠느냐는 것입니다. 그것은 어떤 신호냐에 따라 다릅니다. 절대적인 수치(absolute levels)는 저하되지만, 리프트는 대부분 저하되지 않습니다.

우리는 GLM 5.1과 Sonnet 4.6 모두에서 500개의 기술에 걸쳐 약 850개의 작업을 헤드 투 헤드(head-to-head)로 실행했습니다. 동일한 작업, 동일한 판사, 동일한 '있음과 없음(with-and-without)' 프로토콜을 사용했습니다. 그런 다음 기술별 리프트 간의 상관관계를 분석했습니다.

기술 수준에서, 이 500가지 기술 전반에 걸쳐 리프트 상관관계(lift correlation)는 r = 0.72 (Spearman 0.69)였습니다. 특정 기술이 Sonnet의 성능을 높인다면, GLM 또한 비슷한 정도로 성능을 높이는 경우가 많으며, 이를 분해했을 때도 상관관계가 유지됩니다. 이는 단일 헤드라인 수치가 포화 아티팩트(saturation artifact)를 숨길 수 있기 때문에 중요합니다. 거의 모든 신호가 존재하는 지시 이행(Instruction-following) 리프트(표준 편차 26)는 r = 0.71로 나타났습니다. 작고 포화 상태에 가깝지만 드문 언락(unlocks)을 수반하는 작업 완료(Task completion) 리프트는 r = 0.74로 나타났습니다. 각 차원과 그 크기(magnitude) 측면에서 일치함을 보여줍니다.

스크리닝 도구(screening tool)로서 주목해야 할 수치는 결정 일치도(decision agreement)입니다. 모든 저자가 실제로 내리는 이진 판단인 "이 기술이 도움이 되는가?"에 대해, 두 모델은 **88.5%**의 확률로 일치했으며, 의견이 갈리는 경우에도 안전한 방향으로 갈라졌습니다. 즉, GLM은 Sonnet의 24.3에 비해 평균 리프트가 22.3이고 회귀 기울기(regression slope)가 약 0.76으로 약간 보수적입니다. 이는 회귀 가드(regression guard)로서 원하는 방식인, 특정 기술의 기여도를 과하게 책정하지 않는 방식입니다.

기술 저자들에게 주는 시사점은 간단합니다. 여러분이 실제로 조치를 취하는 대상, 즉 기술 리프트의 부호(sign)와 대략적인 크기는 어느 모델에서나 동일하게 나타나므로, 기본적으로는 저렴한 모델을 사용하십시오.

저렴한 스크리닝의 한계

두 모델은 미세하고 영향력이 낮은 플래깅(flagging)에서 차이를 보입니다. GLM은 Sonnet이 저영향(low-impact, 리프트 5점 미만)으로 평가한 기술의 약 절반 정도를 잡아내며, 드물게 나타나는 명백한 부정적(outright-negative) 기술에 대해서는 중첩도가 훨씬 더 낮습니다. 하지만 기술당 작업이 약 2개에 불과하고, 어떤 LLM 판사라도 가질 수밖에 없는 불가피한 노이즈(irreducible noise)를 고려하면, 한계 사례(marginal cases)들이 바로 두 모델이 의견을 달리하는 지점이 됩니다. 불일치는 확신이 있는 판단에 퍼져 있는 것이 아니라, 증거가 가장 희박한 곳에 집중되어 있습니다.

이는 GLM이 기술을 개발하고 회귀 (Regression)를 방지하는 동안 지속적으로 실행하는 저렴하고 빠른 스크리닝 (Screen) 역할을 한다는 것을 의미합니다. 결정이 단 하나의 경계선에 있는 기술 (Borderline skill)이나 어떤 모델을 출시할지에 달려 있을 때, 여러분은 중요하게 생각하는 모델로 단계를 격상 (Escalate)합니다. 스크리닝 단계가 범위를 좁히고, 프런티어 모델 (Frontier model)이 최종 결정을 내립니다. 이는 정확도를 비용과 맞바꾸는 것이 아니라, 결정이 필요한 곳에는 정확도를 투자하고 그 외의 모든 곳에는 처리량 (Throughput)을 투자하는 것입니다.

비용 이야기

현재 우리의 API 가격 책정 기준으로, 일반적인 작업은 GLM에서 약 1.5배 더 저렴합니다. GLM은 작업의 83%에서 더 저렴하며, 52%의 작업에서는 최소 1.5배 더 저렴합니다. 토큰당 API 리스트 가격으로 보면 그 격차는 23배로 벌어집니다. 한 줄 요약하자면: 대다수의 작업에서 더 저렴하며, 일반적으로 약 1.5배, 토큰당으로는 최대 23배까지 저렴합니다.

전체 평가 (Eval) 지출은 약 1.4배 저렴하며, 대략 28% 낮습니다. 이는 작업당 비용 격차보다는 좁은 수치입니다. 그 이유는 심각한 비용 꼬리 (Cost tail) 때문입니다. 약 17%의 작업은 루프를 돌거나 중앙값 (Median)보다 훨씬 더 많은 토큰을 소모하는 통제 불능의 수다스러운 궤적 (Chatty trajectories)이며, 단 하나의 작업만으로도 210만 개의 캐시된 토큰 (Cached tokens)을 읽기도 합니다. 전체 합계는 일반적인 작업보다는 이러한 꼬리 부분에 의해 끌려 내려갑니다.

그 꼬리 부분은 우리가 최적화할 수 있는 영역입니다. 일반적인 작업의 1.5배와 전체 합계의 1.4배 사이의 격차는 이러한 통제 불능의 궤적에서 발생합니다. 턴 (Turn) 및 루프 (Loop) 제한을 강화하고 하네스 (Harness)가 긴 궤적을 구동하는 방식을 조절하면, 꼬리 부분이 중앙값을 향해 수렴하며 격차가 줄어듭니다. 이것만으로도 전체 합계는 일반적인 작업이 이미 보여주는 1.5~2배 수준으로 이동할 수 있습니다. 이는 현재 대부분의 작업에서 더 저렴하며, 비용 곡선상에서 우리가 계속해서 낮출 수 있는 부분입니다.

이를 여러분의 스택에 적용하는 방법

이 원칙은 우리의 하네스 너머로도 잘 일반화됩니다:

• 기술 개발 및 회귀 평가 (Regression evals)의 기본값은 저렴하면서도 SOTA (State-of-the-art)와 상관관계가 높은 솔버 (Solver)로 설정하세요. 실행 횟수의 대부분이 여기서 발생합니다.
• 출시 결정 및 경계선에 있는 단일 기술 호출에 대해서만 프런티어 모델을 고정 (Pin)하세요. 여기서는 결정이 실제로 정확도에 달려 있습니다.

GLM 5.1이 이제 우리의 기본 솔버 (Default Solver)이며, 평가 러너 (Eval Runner)에서 설정이 가능합니다. 따라서 다음 평가 실행을 하기 전에, 해당 평가가 실제로 무엇에 답하고 있는지 질문해 보세요. 모델을 측정하고 있는 것인가요, 아니면 기술 (Skill)을 측정하고 있는 것인가요? 만약 기술을 측정하는 것이라면, 기술이 변화할 때 여전히 반응하는 가장 저렴한 도구는 무엇인가요?