model-drift는 고정된 스위트(suite)를 대상으로 정확도 일치(exact-match) 채점기를 사용하여 매주 모델을 평가합니다. LLM judge를 사용하지 않으므로 점수 변화는 실제적인 것입니다. 하지만 이 설계에는 날카로운 단점이 있습니다. 유효한 답변을 반환하지 않는 호출이 틀린 답변과 동일한 점수를 받는다는 점입니다. 거절(refusal), max_tokens에 의한 잘림(truncation), 타임아웃(timeout), 조용히 변경된 스키마에 의한 파서(parser) 오류 등은 모두 0점으로 처리되어, 이 보드가 잡아내고자 하는 능력 붕괴(capability collapse)와 구분이 불가능합니다.

저는 잡아낼 수 있는 버전을 경험했습니다. 한 모델의 성능이 하룻밤 사이에 69%에서 3%로 급락한 것처럼 보였습니다. 실행 로그를 확인하니 35번의 호출 중 34번에서 429 오류가 발생했습니다. 즉, 속도 제한(rate limit)이 성능 퇴보(regression)로 점수화된 것입니다. 속도 제한은 상태 코드(status code)를 남기기 때문에 잡아낼 수 있지만, 거절이나 잘림 현상은 그렇지 않습니다.

이 보드는 집계된 신뢰성(aggregate reliability)을 기준으로 제외합니다. 단일 호출 실패가 아니라, 해당 실행의 신뢰성이 50% 미만으로 떨어질 때만 실행의 정확도 포인트를 낮춥니다. 이는 치명적인 인프라(catastrophic-infra) 하한선을 기준으로 하는 것이지, 단 한 번의 호출 실패를 기준으로 하는 것이 아닙니다. Bartłomiej Nawara, PhD는 왜 이러한 절제가 중요한지 다음과 같이 설명했습니다: 실패는 무작위로 누락되는 것(missing-at-random)이 아닙니다. 길고 어려운 프롬프트들이 토큰 제한(token caps)과 타임아웃에 걸리기 때문에, 모든 실패를 일괄적으로 제외하는 규칙을 적용하면 난이도와 상관관계가 있는 실패들을 제외하게 되어 변별력이 필요한 작업에서의 정확도를 부풀리게 됩니다. 그의 말에 따르면: "평가 하네스(eval harness)는 틀린 것(wrong)과 없는 것(absent)을 구분해야 하며, 이를 구분하지 못하는 하네스는 인프라 문제를 지능 문제로 보고할 것입니다."

이것은 이미 설계에 반영되어 있었으나, 그의 프레임워크 덕분에 명시적으로 기록되었습니다 — 일괄적으로 제외하는 것이 아니라 클래스별로 제외하는 것입니다. 코드: github.com/egnaro9/model-drift

방법론을 공개적으로 작성하는 것이 이처럼 면밀한 검토를 받는 방법입니다.