제품 버전은 그대로인데 평가 통과율이 내려갔다면 무엇을 롤백해야 할까요? 이 질문에 점수 그래프 하나로 답하면 위험합니다. LLM 평가 파이프라인에는 답을 만드는 모델과 그 답을 채점하는 모델이 모두 들어갑니다. 생성 결과가 달라질 수도 있고, 같은 결과에 대한 판정이 달라질 수도 있으며, 판정 모델이나 루브릭이 이전과 다른 기준을 적용할 수도 있습니다.
목표는 LLM을 완전히 결정적으로 만드는 것이 아닙니다. 점수 변화가 제품, 판정기, 통상적인 변동 중 어디서 왔는지 구분하고, 아직 구분할 수 없을 때는 릴리스 결정을 멈추는 것입니다.
네 종류의 변화를 먼저 분리한다
다음 네 개는 서로 다른 문제입니다.
- 생성 변동성: 같은 입력에서도 후보 답이 달라진다.
- 판정 반복성 부족: 저장된 같은 답을 같은 계약으로 채점해도 결과가 달라진다.
- 판정기 드리프트: 시간이 지나며 판정 모델, 루브릭, 예시 또는 파서의 기준이 움직인다.
- 실제 품질 변화: 제품 버전이나 실제 트래픽 분포가 바뀌어 결과가 나빠진다.
전체 흐름은 단순하지만, 마지막 숫자만 보면 원인을 잃습니다.
text테스트 입력 -> 제품 모델 -> 저장한 후보 출력 -> LLM 판정기 -> 판정
질문에 맞춰 실험을 나눠야 합니다.
| 질문 | 고정할 것 | 다시 실행할 것 | 얻는 증거 |
|---|---|---|---|
| 판정기가 같은 결정을 반복하는가 | 입력, 후보 출력, 루브릭, 판정 설정 | 판정 호출만 | 점수 분포와 pass/fail 반전 |
| 전체 사용자 경험이 안정적인가 | 데이터셋과 계약 버전 | 생성과 판정 | 종단 간 결과 분포 |
| 새 제품이 더 좋은가 | 같은 사례와 보정된 판정 계약 | 제품 버전 | 쌍별 차이와 불확실성 |
| 판정기가 변했는가 | 사람 라벨이 붙은 고정 출력 | 현재 판정기 | 사람과의 불일치 추이 |
후보 출력을 저장하지 않으면 사후에 판정기만 다시 시험할 수 없습니다. 각 평가에는 case ID, 데이터셋 버전, 제품 버전, 후보 출력 ID, 생성 설정, 판정 모델, 루브릭·예시·파서 버전, 결과와 시각이 연결돼야 합니다. 민감한 데이터는 승인된 보존, 마스킹, 암호화 또는 통제된 재생 정책으로 다룹니다.
계산 가능한 조건은 코드에 맡긴다
JSON 파싱, 필수 필드, 도구 이름과 인자, 숫자 일치, 허용된 URL 같은 조건은 LLM에게 묻지 않습니다. 결정적 검사로 확인하면 실패 이유가 정확하고 반복 가능하며 저렴합니다.
LLM 판정기는 요약의 충실성, 사용자의 목적 해결, 정책에 맞는 거절, 상황에 맞는 어조처럼 의미 판단이 필요한 기준에만 씁니다.
OpenAI의 최신 evaluation best practices는 실제 작업에 맞춘 평가, 지속 평가, 사람 피드백으로 자동 채점을 보정하는 방식, 그리고 pairwise·pass/fail처럼 제한된 판정을 권합니다. Graders 문서도 문자열 검사, 유사도 검사, 모델 판정기를 서로 다른 도구로 설명합니다. API 세부는 OpenAI에 한정되지만, 가장 모호하지 않은 측정기를 선택한다는 원칙은 보편적입니다.
모든 조건을 0~10 총점으로 합치면 원인을 숨깁니다. 7.1점이 중요한 사실 오류인지, 약간 긴 문장인지 알 수 없다면 동일한 릴리스 조치를 취할 수 없습니다.
제품보다 먼저 판정기를 평가한다
판정기 전용 보정 세트를 만드세요.
- 명백한 통과와 명백한 실패
- 팀이 정책을 결정해야 하는 경계 사례
- 실제 장애와 전문가 수정
- 품질은 같고 순서·길이·서식·후보 이름만 다른 쌍
- 자연스럽지만 핵심 오류가 있는 답과 투박하지만 맞는 답
- 실제 운영의 언어, 작업, 길이, 위험 등급
- 전문가 사이에서도 의견이 갈리는 사례
전문가는 독립적으로 라벨을 붙인 뒤 차이를 조정합니다. 사람의 불일치를 버릴 필요는 없습니다. 루브릭이 모호하거나 두 정책이 모두 타당하거나 자동 판정 대상이 아님을 보여주는 신호일 수 있습니다.
MT-Bench와 Chatbot Arena 연구는 특정 설정에서 강한 LLM 판정기와 사람 사이의 높은 일치도를 보고했지만, 위치 편향, 장황성 선호, 자기 선호, 추론 한계도 함께 기록했습니다. 그 일치율은 당시 모델·프롬프트·데이터에 속하며 다른 판정기의 정확도가 아닙니다.
Large Language Models Are Not Fair Evaluators는 후보 순서만 바꿔도 순위가 바뀔 수 있음을 보이고, 위치 균형, 복수 근거, 사람 개입을 제안했습니다. 12개 판정기, 22개 작업, 10만 건이 넘는 평가를 다룬 후속 위치 편향 연구는 편향의 크기가 판정기와 작업에 따라 다름을 확인했습니다. “더 강한 모델”은 현장 보정의 대체물이 아닙니다.
판정기가 쓰는 지름길을 시험한다
저장된 답을 반복 채점한다
후보 출력을 고정하고 같은 판정 계약으로 여러 번 실행합니다. 평균뿐 아니라 모든 판정과 기준별 결과를 보관합니다. 명백한 사례가 pass와 fail 사이를 오간다면 이 판정기를 이진 CI 게이트로 쓰기 이릅니다.
변동이 실제로 애매한 사례에 집중된다면 억지로 점수를 고정하지 말고 review 구간을 만드세요.
A/B와 B/A를 모두 실행한다
쌍별 비교에서는 순서를 바꿉니다. 보수적인 정책은 두 순서가 같은 후보를 선택할 때만 승자로 인정하고, 충돌하면 tie 또는 사람 검토로 보냅니다. 대규모에서 순서를 무작위화하더라도 순서 일치율은 별도로 보고해야 합니다.
표면만 바꾸는 반사실 검사를 한다
내용은 유지한 채 길이, 제목, 정중함, 후보 이름, 자신감 있는 어조만 바꿉니다. 점수가 이런 표면을 따라가면 목적 품질 대신 판정기 취향을 측정하는 것입니다.
이 검사는 grader hacking도 드러냅니다. 제품이 더 길고 권위적으로 쓰는 법을 배워 자동 점수만 오르고 전문가 품질은 그대로인 상황입니다.
근거가 있으면 근거를 함께 준다
추출, 출처 기반 Q&A, 요약 충실성, 수학, 도구 사용에는 원문, 참조 답 또는 실행 결과를 제공합니다. 판정 설명은 디버깅에 유용하지만 정답의 증명은 아닙니다. 같은 모델이 잘못된 결론을 그럴듯하게 설명할 수 있습니다.
보정은 평균 점수 맞추기가 아니다
판정기 평균이 사람보다 0.08 높다고 모든 결과에서 0.08을 빼면 순서 오류, 비대칭 비용, 특정 구간의 실패를 고치지 못합니다. 실제 게이트가 내릴 결정을 평가하세요.
- 명백한 실패를 얼마나 통과시키는가
- 좋은 답을 얼마나 잘못 막는가
- 언어, 작업, 길이, 위험 등급에 오류가 몰리는가
- 문턱 근처에서 결정이 얼마나 자주 뒤집히는가
- 사람도 애매해하는 사례와 판정기가 불안정한 사례가 겹치는가
false accept와 false reject의 비용은 다릅니다. 고위험 조언의 오류를 놓치는 비용과 마케팅 문구를 한 번 더 검토하는 비용은 같은 임계값을 요구하지 않습니다. 먼저 비용과 검토 역량을 정한 뒤 샘플 크기, 반복 횟수, 불확실성 구간을 현장 데이터로 선택합니다. 모든 작업에 통하는 0.8 기준은 없습니다.
게이트 결과는 통과, 실패, 사람 검토처럼 세 가지가 더 정직할 수 있습니다. 연속 점수는 분석에 남겨도 되지만 보정 데이터보다 정밀한 척해서는 안 됩니다.
제품 스트림 옆에 고정 앵커를 둔다
사람 라벨이 확정된 출력의 안정적인 핵심 세트를 보존하고, 현재 판정기로 정기적으로 다시 채점합니다.
text제품 스트림: 현재 제품 출력 -> 현재 판정기 -> 제품 품질 신호 앵커 스트림: 고정 사람 라벨 -> 현재 판정기 -> 판정기 안정성 신호
제품 신호만 하락하고 앵커가 안정적이면 제품이나 트래픽 분포를 우선 조사합니다. 앵커에서도 현재 판정기가 더 엄격해졌다면 판정 모델, 루브릭, 예시, 파서, backend를 먼저 확인합니다. 두 스트림이 모두 불안정하면 측정 시스템이 게이트 역할을 할 상태가 아닙니다.
2026년 프리프린트 Who Drifted: the System or the Judge?는 고정된 사람 라벨 앵커에서 판정기-사람 차이를 측정하고 제품 스트림과 분리하는 방식을 형식화했습니다. 논문의 탐지율과 비용은 해당 실험 결과이지 배포 보장이 아닙니다. 일반화할 수 있는 핵심은 제품 변경은 이미 저장된 앵커 내용을 바꿀 수 없지만 판정기 변경은 그 앵커의 점수를 바꿀 수 있다는 식별입니다.
앵커 핵심을 릴리스마다 갈아엎지 마세요. 새 사례는 새 데이터셋 버전에 추가하고 사람 라벨이나 정책이 바뀐 이유를 기록합니다.
CI는 불확실성을 라우팅해야 한다
릴리스 게이트는 다음 순서로 증거를 확인할 수 있습니다.
text1. 결정적 계약이 모두 통과했는가 2. 판정기가 고정 앵커의 보정 범위 안에 있는가 3. 고정 출력 반복 판정이 충분히 안정적인가 4. 새 버전과 이전 버전의 차이가 통상 변동을 넘는가 5. 변화가 핵심·고위험 구간에 집중되는가 6. 사람에게 보낼 충돌 사례가 남았는가
결과는 통과, 차단, 판정기 조사, 사람 검토로 나뉩니다. “조사”는 실패가 아니라 잘못된 롤백이나 출시를 막는 정식 상태입니다.
온도 0과 seed도 완전한 결정성을 증명하지 않습니다. 모델 alias, 추론 인프라, 프롬프트 조립, 도구 결과, 파서가 변할 수 있습니다. OpenAI의 과거 seed와 system fingerprint 재현 예제는 당시 지원한 preview 모델에서 요청 조건이 같을 때 “대체로 동일한” 출력을 목표로 했으며 결정성을 보장하지 않는다고 명시했습니다. 모든 최신 모델, endpoint, provider에 일반화할 수 없습니다.
판정 모델, 루브릭, few-shot 예시, 출력 schema, 파서, 집계 정책을 하나의 버전 계약으로 저장하세요. 제공되는 request ID, sampling 설정, backend fingerprint도 기록합니다. 이 메타데이터는 차이를 설명할 뿐 확률 시스템을 unit test로 바꾸지 않습니다.
강한 판정기는 언제나 숫자를 내는 판정기가 아닙니다. 고정 출력에서 반복성이 측정되고, 사람 정책과 보정되고, 편향 검사를 통과하고, 별도의 앵커 스트림으로 감시되는 판정기입니다. 증거가 모자랄 때 “아직 구분할 수 없다”고 말할 수 있어야 점수가 실제 릴리스 도구가 됩니다.
