저는 매일 35개 태스크로 구성된 고정된(frozen) 테스트 스위트에서 16개의 LLM을 테스트하는 공개 게시판을 운영하며 모든 점수를 기록합니다. 모델이 이전 실행 대비 성능이 떨어질 경우, 이 게시판은 스스로 GitHub 이슈를 열고 초안 게시물을 작성합니다.

7월 21일과 24일 사이에 네 번이나 이런 일이 발생했습니다:

23 Jul Gemini 3.5 Flash -11.4 pts
24 Jul Gemini 3.1 Pro -2.9 pts
21 Jul Grok 4.3 -5.7 pts
...

사흘 만에 세 개의 연구소(lab)에서 네 번의 성능 저하가 감지된 것입니다. 이는 스스로 작성하는 게시물이며, 빠르고 읽기 쉬웠지만 틀렸습니다.

실제로는 어떤 모델도 성능이 나빠지지 않았습니다. 제가 어떻게 아는지 알려드리겠습니다. 왜냐하면 그 '어떻게' 부분이 읽을 가치가 있는 유일한 부분이기 때문입니다.

두 가지는 모델 문제가 아니었다

게시판의 모든 점수에는 정확도(accuracy) 옆에 두 번째 숫자가 있습니다: 신뢰성(reliability), 즉 실제로 응답이 돌아온 테스트 호출 비율입니다. 이 열을 보여주는 두 개의 Google 알림을 살펴보세요:

gemini-3.5-flash 22 Jul acc 1.000 reliability 1.000
                23 Jul acc 0.886 reliability 0.914 <- "-11.4 pts"
...

정확도와 신뢰성이 함께 떨어졌습니다. 이는 성능이 나빠진 답변의 특징이 아니라, 응답 자체가 돌아오지 않은 호출의 특징입니다. 실패한 호출은 채점할 답변이 없기 때문에, 채점이 안 된 태스크는 틀린 것과 같은 점수를 받게 됩니다.

저는 이 패턴을 잘 알고 있습니다. 왜냐하면 이 게시판에서 이미 그 교훈을 발표했기 때문입니다. 7월 20일, Llama 3.3 70B가 하룻밤 사이에 66점이나 떨어진 것처럼 보였습니다:

api.groq.com -> 429: Rate limit reached for model `llama-3.3-70b-versatile`
service tier `on_demand` ... requests per minute (RPM): Limit 30, Used 30

35개 호출 중 34개가 속도 제한(rate-limited)에 걸렸습니다. 모델이 더 바보가 된 것이 아닙니다. 429 에러는 0점으로 기록되었습니다. 속도 제한으로 인해 0% 점수를 받는 것은 드리프트 트래커가 할 수 있는 가장 오해를 불러일으키는 일입니다. 왜냐하면 그것은 바로 그 트래커가 잡아내기 위해 존재하는 것과 똑같이 보이기 때문입니다.

Gemini 3.1 Pro는 스스로 사건을 해결했습니다. 다음 정상적인 실행에서는 '성능 저하' 이전보다 높은 97.1%로 돌아왔습니다.

나머지 두 가지는 하나의 질문 때문이었다

나머지 두 가지 경고는 더 흥미롭습니다. 신뢰도(reliability)가 내내 1.000을 유지했기 때문입니다. 이 수치들은 실제 데이터입니다:

grok-4.3        0.800 -> 0.743   = -5.7 pts
lama-3.3-70b   0.800 -> 0.771   = -2.9 pts

전체 테스트 세트(suite)는 35개의 태스크(task)로 구성되어 있습니다. 태스크 하나는 100/35 = 2.86 포인트입니다.

따라서 -2.9 포인트는 질문 하나가 답을 바꾼 것입니다. -5.7 포인트는 두 개이고, 세트에서 가장 무서운 숫자인 -11.4 포인트는 네 개입니다.

35개 태스크로 구성된 세트는 약 3포인트보다 더 미세한 차이는 해결할 수 없습니다. 이번 주 제 대시보드가 표시한 모든 "회귀 (regression)"는 질문의 정수 배수였습니다. 이것이 결정적인 증거(tell)입니다. 저는 드리프트 (drift)를 측정하고 있었던 것이 아니라, 제가 사용하는 측정 도구의 입도 (granularity)를 측정하고 있었던 것입니다. 질문 하나가 뒤집힌 것을 모델의 회귀로 보고하는 것은 노이즈 (noise)를 신호 (signal)로 읽는 것이며, 심지어 특정 기업의 모델에 대해 이를 공개적으로 수행하는 것입니다.

경고가 여전히 요란하게 울려야 하는 이유

명백한 해결책은 트래커를 더 조용하게 만드는 것입니다. 예를 들어 10포인트 이상일 때만 작동하게 하는 식이죠. 하지만 저는 그것이 옳다고 생각하지 않습니다. 재앙적인 상황에서만 작동하는 트래커는 실제로 포착하고자 하는 드리프트 (drift)를 놓치게 됩니다. 그리고 호출 실패로 밝혀진 -11.4 포인트는 정확히 실제 회귀 (regression)가 나타나는 형태와 일치합니다. 민감도 (sensitivity)가 바로 핵심 기능 (feature)입니다.

하지만 민감도가 "안전"하려면, 다운스트림 (downstream)에서 거부할 의사가 있어야 합니다. 그래서 이 경고는 아무것도 게시하지 않습니다. 대신 자체 텍스트로 다음과 같이 적힌 스텁 (stub)을 작성합니다:

예정된 프로브 (probe)가 실행 간 회귀 (run-over-run regression)를 감지하여 자동으로 기록되었습니다. 이것이 게시물이 되기 전에, 실행 로그와 신뢰도 (Reliability) 지표를 확인하십시오. 속도 제한 (rate limit)이나 제공업체 중단 (provider outage)은 회귀와 똑같이 보일 수 있습니다.

자동화의 역할은 알아차리는 것입니다. 저의 역할은 확인하는 것입니다. 이번 주에 이 분업은 실질적인 효과를 발휘했습니다. 네 번의 알림이 있었지만, 게시물은 0건이었습니다.

제가 실제로 신경 쓰는 숫자

평가 (evals) 시스템을 구축한다면, 이미 모델의 점수를 추적하고 있을 것입니다. 제가 주장하고 싶은, 여러분이 놓치고 있는 지표는 바로 자체 경고 중 확인 과정을 통과하여 살아남는 비율입니다.

저의 이번 주 수치는 0이었습니다. 이는 공개하기에 그리 편안한 숫자는 아니지만, 제가 가진 가장 유용한 수치이기도 합니다. 이 수치는 현재의 테스트 스위트(suite)가 단일 작업의 노이즈(noise)를 해결하기에는 너무 작다는 것과, 모든 차트에서 신뢰도(reliability)가 정확도(accuracy)와 나란히 놓이지 않는다면 그 차트는 거짓을 말하고 있다는 사실을 저에게 알려줍니다.

이 두 가지 문제 모두 해결 가능합니다. 만약 제가 드리프트 트래커(drift tracker)가 작성해 준 포스트를 그대로 발행했더라면, 그 어느 것도 발견하지 못했을 것입니다.

드리프트 트래커의 어려운 점은 드리프트(drift)를 감지하는 것이 아닙니다. 드리프트를 만들어내지 않는 것입니다.

대시보드: egnaro9.github.io/model-drift — 16개의 모델, 5개의 지표(metrics), 매일 실행되며 모든 실행 기록이 보관됩니다. 현장 노트(field notes)는 페이지에 기재되어 있으며, 이번 기록은 "4건의 회귀 경고, 0건의 회귀"입니다.

코드: github.com/egnaro9/model-drift. 어디에도 LLM-as-judge(판사로서의 LLM) 방식은 사용되지 않았습니다. 모든 작업은 고정된 결정론적 체크(deterministic check)에 의해 채점되므로, 점수 변화는 테스트가 아닌 모델이 변했음을 의미합니다.