지난달 제가 배포한 가장 값비싼 버그는 모델에 있었던 것도, 프롬프트 (Prompt)에 있었던 것도 아니었습니다. 그것은 채점 (Grading)을 수행하는 장치에 있었습니다. 저는 한 달 동안 세 번의 서로 다른 비즈니스에서 이 문제를 세 번 발견했습니다. 매번 저는 잘못된 대상을 탓하고 있었습니다.

제가 살 수 있는 최고의 모델은 0.241점을 기록했다

저는 작은 훈련 플랫폼을 운영하고 있습니다. Qwen 및 DeepSeek 제품군의 오픈 소스 (Open-source) 모델 5개, 54개의 어려운 과제로 구성된 시험, 그리고 수치가 실제 승리를 나타낼 때만 모델을 승격시키는 게이트 (Gate)가 있습니다. 몇 주 동안 그 어떤 모델도 게이트를 통과하지 못했습니다. 쉬운 설명은 가장 편안한 설명이었습니다. 모델이 작고, 시험이 어려우니, 계속 훈련시키라는 것이었습니다.

그래서 저는 기준점으로 삼기 위해 프론티어 모델 (Frontier model)인 gpt-5.5를 정확히 동일한 하네스 (Harness)에 연결했습니다. 동일한 과제, 동일한 고정 장치 (Fixtures), 동일한 채점 방식이었습니다.

그 모델은 0.241점을 기록했습니다.

이는 다섯 개의 작은 모델들과 동일한 점수입니다. 쌍체 맥니머 검정 (Paired McNemar test) 결과 모든 비교에서 p값이 0.31 이상으로 나타났는데, 이는 모델들 사이에 실질적인 차이가 없었다는 것을 신중하게 표현하는 방식입니다. 그리고 54개의 과제 중 34개는 프론티어 모델을 포함한 모든 모델이 실패했습니다.

그런 숫자를 해석하는 방법은 단 두 가지뿐입니다. 프론티어 모델이 거짓이거나, 아니면 시험이 망가졌거나. 시험이 망가져 있었습니다. 한 과제의 증거가 관련 없는 다른 과제로 유출되고 있었고, 하네스 (Harness)의 버그가 기준 모델의 답변을 조용히 잘라내고 있었습니다. 그날 제가 로그 (Log)에 남긴 내용은 간단했습니다. 우리를 가로막고 있는 것은 모델이 아니라, 과제와 고정 장치 (Fixtures)의 품질이다.

저는 학생들에게 모든 노력을 쏟았습니다. 버그는 교수에게 있었습니다.

핵심 통찰 (Key insight): 모든 모델이 동일한 질문에서 실패한다면, 문제는 모델이 아니라 시험입니다. 당신의 평가 (Eval) 또한 코드이며, 그 버그는 최악의 종류입니다. 왜냐하면 그 버그가 무엇이 "합격"인지를 결정하기 때문입니다.

결코 통과할 수 없었던 게이트

같은 달, 다른 비즈니스였습니다. 저의 지급 거절 관리 엔진(denial-management engine)은 의료 청구 거절(healthcare claim denials) 내용을 읽고 항소(appeal), 수정 후 재제출(fix and resubmit), 환자에게 청구(bill the patient), 또는 손실 처리(write it off) 중 어떤 조치를 취할지 결정합니다. 골든 세트(golden set)를 기준으로 프롬프트(prompts)를 튜닝한 결과, 매핑된 조치 정확도(mapped-action accuracy)는 36.7%에서 76.7%로, 분류(classification) 정확도는 80%에서 93.3%로 향상되었으며, 치명적인 오류(hard errors)는 0으로 줄어들었습니다. 시스템이 매우 날카로워지고 있었습니다.

하지만 배의 게이트(ship gate)는 그렇지 않았습니다. 게이트는 튜닝된 시스템이 더 약한 원시 에이전트(raw agent)와 일치할 것을 요구했고, 두 시스템이 일치하는 비율은 44.7%에 불과하다고 보고했습니다. 이는 매우 경고적인 수치로 보였습니다. 하지만 그것은 잘못된 것이었습니다.

150개의 케이스를 직접 수동으로 검토했을 때, "불일치(disagreements)" 중 27개는 1단계 항소(appeal level 1) 대 피어 투 피어(peer-to-peer) 대 소급 승인(retro authorization)과 같은 것들이었습니다. 모두 같은 종류의 조치였습니다. 인간 청구 담당자라면 모두 같은 서랍에 넣어둘 만한 것들이었죠. 그리고 그 밑바닥에 깔린 버그는 거의 창피할 정도였습니다. 평가(eval)의 한 축은 원시 라벨 문자열(raw label strings)을 비교했고, 다른 한 축은 어떤 라벨이 같은 의미를 갖는지 알고 있는 맵(map)을 사용했습니다. 하나의 평가에 두 개의 자(rulers)를 사용한 셈입니다.

양쪽 모두 동일한 방식으로 측정하고, 약한 형제 모델이 아닌 골든 정답(golden answers)과 비교했을 때, 튜닝된 시스템은 분류 92.0%, 조치 90.7%를 기록했습니다. 골든 세트와 실제로 불일치했던 케이스에서도 약 78%의 일치율을 보였습니다. 반면 에이전트는 38%에 그쳤습니다. 저는 기존의 게이트를 버리고 골든 트루스(golden truth) 대비 90%를 기준으로 하는 새로운 게이트를 설정했습니다. 로그에 남긴 제 표현을 빌리자면, 기존의 게이트는 잘못된 것을 측정하고 있었기에 결코 통과할 수 없었던 것입니다.

• 약한 에이전트 대비 일치율: 44.7%
• 골든 세트 대비 분류 정확도: 92.0%
• 골든 세트 대비 조치 정확도: 90.7%
• 불일치 발생 시 골든 세트 일치율: 78%

당신의 가장 뛰어난 평가자가 가장 형편없는 평가자와 일치하도록 만드는 것은 엄격함(rigor)이 아닙니다. 그것은 당신 스스로가 만든 천장일 뿐입니다.

채점자를 고칠 수 없다면, 스스로 채점자가 되어라

세 번째 비즈니스, 같은 교훈이 뒤집힌 형태였습니다. 저의 메디케어(Medicare) 원격 모니터링 컴플라이언스 플랫폼은 채점자를 제가 고칠 수 없는 세상에 존재합니다. 연방 계약업체들이 청구 패턴에 대해 스크리닝(screens)을 실시하며, 정부는 그 스크리닝이 정확히 무엇인지 공개합니다.

따라서 플랫폼은 감사인(auditor) 자신의 수학적 로직을 스스로에게 실행합니다. 매달 플랫폼은 자체 청구 건에 대해 해당 스크리닝 (screens)을 계산하고, 그 결과를 수정할 수 없는 스냅샷 (snapshots) 형태로 기록합니다. 수정 사항은 항상 새로운 버전으로 생성되며, 조용히 덮어쓰는 방식은 절대 허용되지 않습니다. 적용되지 않는 스크리닝이라 할지라도 이유와 함께 N/A로 기록되어, 감사인이 해당 항목이 단순히 건너뛴 것이 아니라 검토되었음을 확인할 수 있게 합니다. 전체 목표는 단 한 문장으로 요약됩니다: 외부 계약업체가 알기 전에 먼저 경보를 울리는 것입니다.

채점자 (grader)가 당신보다 상급자일 때, 채점자를 채점한다는 것은 바로 이런 모습입니다. 그들의 테스트를 직접 실행하십시오. 일찍 실행하십시오. 영수증(증거)을 보관하십시오.

교훈

1. 모든 학생이 동일한 34개 질문에서 틀린다면, 학생을 채점하는 것을 멈추십시오. 질문을 채점하십시오.
2. 절대 통과할 수 없는 문은 높은 기준이 아닙니다. 그것은 도로를 가로막고 볼트로 고정된 고장 난 장치일 뿐입니다.
3. 하나의 비교를 두 개의 서로 다른 자로 측정하지 마십시오. 평가 (eval)의 모든 부분에는 동일한 규칙이 적용되어야 합니다.
4. 동일한 유형의 움직임 내에서의 불일치는 사실상 합의입니다. 숫자를 세기 전에 무엇을 동일한 것으로 간주할지 결정하십시오.
5. 감사인의 수학적 로직이 공개되어 있다면, 먼저 자신에게 실행해 보고, 기록을 조용히 변경하는 것이 불가능하도록 만드십시오.

세 가지 비즈니스가 있었습니다. 오픈 모델 (open models)을 위한 트레이닝 루프 (training loop), 거부 엔진 (denial engine), 그리고 메디케어 (Medicare) 준수 플랫폼입니다. 이 세 가지 모두에서, 그달 제가 수행한 최고의 엔지니어링은 측정 대상이 되는 시스템에 대한 것이 아니었습니다. 그것은 바로 측정을 수행하는 대상에 대한 것이었습니다. 당신의 모델은 아마 괜찮을 것입니다. 당신의 프롬프트 (prompt)도 아마 괜찮을 것입니다. 당신의 평가 (eval) 라인을 한 줄씩 읽어보십시오. 왜냐하면 현재 당신이 가진 가장 값비싼 버그는 '합격'의 의미를 조용히 결정하고 있는 바로 그 버그이기 때문입니다.

이 중 어느 것도 이론이 아닙니다. 이것은 한 달 동안 실제로 일어난 일들의 목록입니다. 만약 당신이 자신의 채점자가 당신에게 거짓말을 하는 것을 잡아낸 적이 있다면, 그 기분을 알 것입니다.

원문은 nabbilkhan.com에 게시되었습니다.