피드로 돌아가기
Why We're Changing Our Default Eval Model
Dev.toDev.to
AI/ML

GLM 5.1 도입을 통한 Eval 비용 28% 절감 및 신호 유지

Why We're Changing Our Default Eval Model

Tessl2026년 6월 8일6intermediate

Context

Claude Sonnet 4.6 기반의 Eval Harness 운영 중 과도한 API 비용 발생. 모델 자체의 성능 측정보다 Skill 개선 여부를 판단하는 반복적 평가 작업에 Frontier Model의 고비용 구조가 병목으로 작용함.

Technical Solution

  • Solver와 Judge의 역할을 분리하여 Judge는 고정하고 Solver만 교체 가능한 구조 설계
  • '모델 측정'과 'Skill 측정'의 목적을 구분하여 Skill 측정 시에는 Representative Model을 사용하는 전략 채택
  • GLM 5.1을 Default Solver로 설정하여 Frontier Model과의 Lift 상관관계 검증
  • 결정 합의도(Decision Agreement) 분석을 통해 임계치 이하의 저영향 Skill은 저비용 모델로 스크리닝
  • 판단이 모호한 Borderline Case에 한해 Frontier Model로 에스컬레이션하는 계층적 평가 파이프라인 구축

Impact

  • 전체 Eval 비용 약 28% 감소 및 일반 Task 기준 1.5x 비용 절감
  • Per-token API 리스트 가격 기준 2~3x 비용 효율 달성
  • Skill 수준의 Lift 상관관계 r = 0.72 확보 및 의사결정 합의도 88.5% 기록
  • Instruction-following lift(r=0.71)와 Task completion lift(r=0.74) 모두 유의미한 신호 유지

Key Takeaway

측정 대상(Subject)이 모델인지 기능(Skill)인지에 따라 도구(Instrument)의 정밀도를 차등 적용하는 것이 효율적임. 모든 단계에 최상위 모델을 투입하기보다, 저비용 모델로 candidate를 필터링하고 최종 결정 단계에서만 고정밀 모델을 사용하는 계층적 검증 구조가 비용과 정확도의 최적 Trade-off를 제공함.


- Eval 목적이 '특정 모델의 배포 결정'인지 '기능적 개선 확인'인지 구분할 것 - 최저 비용이면서 Frontier Model과 상관관계가 높은 Representative Model을 발굴하여 Default로 설정할 것 - 결정 합의도가 낮은 구간의 데이터 분포를 분석하여 에스컬레이션 트리거 조건 설정할 것 - API 비용의 꼬리 부분(Heavy Tail)을 유발하는 Runaway Trajectory의 루프 제한 및 토큰 최적화 방안 검토할 것

원문 읽기