# LLM 평가 점수가 흔들릴 때: 판정기 드리프트를 보정하는 실전 방법

> 생성 변동과 판정 변동을 분리하고, 사람 라벨·순서 반전·고정 앵커로 판정기를 보정해 실제 품질 저하와 측정기 변화를 구분하세요.

- Source: https://www.aifreeapi.com/ko/posts/llm-judge-drift-calibration
- Language: ko
- Published: 2026-08-31
- Updated: 2026-09-13
- Publisher: AI Free API (https://www.aifreeapi.com)

제품 버전은 그대로인데 평가 통과율이 내려갔다면 무엇을 롤백해야 할까요? 이 질문에 점수 그래프 하나로 답하면 위험합니다. LLM 평가 파이프라인에는 답을 만드는 모델과 그 답을 채점하는 모델이 모두 들어갑니다. 생성 결과가 달라질 수도 있고, 같은 결과에 대한 판정이 달라질 수도 있으며, 판정 모델이나 루브릭이 이전과 다른 기준을 적용할 수도 있습니다.

목표는 LLM을 완전히 결정적으로 만드는 것이 아닙니다. 점수 변화가 제품, 판정기, 통상적인 변동 중 어디서 왔는지 구분하고, 아직 구분할 수 없을 때는 릴리스 결정을 멈추는 것입니다.

## 네 종류의 변화를 먼저 분리한다

다음 네 개는 서로 다른 문제입니다.

1. **생성 변동성**: 같은 입력에서도 후보 답이 달라진다.
2. **판정 반복성 부족**: 저장된 같은 답을 같은 평가 기준과 설정으로 채점해도 결과가 달라진다.
3. **판정기 드리프트**: 시간이 지나며 판정 모델, 루브릭, 예시 또는 파서의 기준이 움직인다.
4. **실제 품질 변화**: 제품 버전이나 실제 트래픽 분포가 바뀌어 결과가 나빠진다.

전체 흐름은 단순하지만, 마지막 숫자만 보면 원인을 잃습니다.

~~~text
테스트 입력 -> 제품 모델 -> 저장한 후보 출력 -> LLM 판정기 -> 판정
~~~

질문에 맞춰 실험을 나눠야 합니다.

| 질문 | 고정할 것 | 다시 실행할 것 | 얻는 증거 |
|---|---|---|---|
| 판정기가 같은 결정을 반복하는가 | 입력, 후보 출력, 루브릭, 판정 설정 | 판정 호출만 | 점수 분포와 통과·실패 판정의 반전 |
| 전체 사용자 경험이 안정적인가 | 데이터셋과 평가 설정 버전 | 생성과 판정 | 종단 간 결과 분포 |
| 새 제품이 더 좋은가 | 같은 사례와 보정된 평가 기준 | 제품 버전 | 쌍별 차이와 불확실성 |
| 판정기가 변했는가 | 사람 라벨이 붙은 고정 출력 | 현재 판정기 | 사람과의 불일치 추이 |

![사람 라벨로 판정기를 맞추는 보정 루프와 핵심 지표, 앵커 스트림, 증거 기반 CI의 배포 판단 및 설정 버전](https://www.aifreeapi.com/posts/ko/llm-judge-drift-calibration/img/judge-calibration-loop.webp)

후보 출력을 저장하지 않으면 사후에 판정기만 다시 시험할 수 없습니다. 각 평가에는 사례 ID, 데이터셋 버전, 제품 버전, 후보 출력 ID, 생성 설정, 판정 모델, 루브릭·예시·파서 버전, 결과와 시각이 연결돼야 합니다. 민감한 데이터는 승인된 보존, 마스킹, 암호화 또는 통제된 재생 정책으로 다룹니다.

## 계산 가능한 조건은 코드에 맡긴다

JSON 파싱, 필수 필드, 도구 이름과 인자, 숫자 일치, 허용된 URL 같은 조건은 LLM에게 묻지 않습니다. 결정적 검사로 확인하면 실패 이유가 정확하고 반복 가능하며 저렴합니다.

LLM 판정기는 요약의 충실성, 사용자의 목적 해결, 정책에 맞는 거절, 상황에 맞는 어조처럼 의미 판단이 필요한 기준에만 씁니다.

OpenAI의 최신 [평가 모범 사례](https://developers.openai.com/api/docs/guides/evaluation-best-practices)는 실제 작업에 맞춘 평가, 지속 평가, 사람 피드백으로 자동 채점을 보정하는 방식, 그리고 두 답변 비교나 통과·실패처럼 선택 범위가 명확한 판정을 권합니다. [Graders 문서](https://developers.openai.com/api/docs/guides/graders)도 문자열 검사, 유사도 검사, 모델 판정기를 서로 다른 도구로 설명합니다. API 세부는 OpenAI에 한정되지만, 가장 모호하지 않은 측정기를 선택한다는 원칙은 보편적입니다.

모든 조건을 0~10 총점으로 합치면 원인을 숨깁니다. 7.1점이 중요한 사실 오류인지, 약간 긴 문장인지 알 수 없다면 동일한 릴리스 조치를 취할 수 없습니다.

## 제품보다 먼저 판정기를 평가한다

판정기 전용 보정 세트를 만드세요.

- 명백한 통과와 명백한 실패
- 팀이 정책을 결정해야 하는 경계 사례
- 실제 장애와 전문가 수정
- 품질은 같고 순서·길이·서식·후보 이름만 다른 쌍
- 자연스럽지만 핵심 오류가 있는 답과 투박하지만 맞는 답
- 실제 운영의 언어, 작업, 길이, 위험 등급
- 전문가 사이에서도 의견이 갈리는 사례

전문가는 독립적으로 라벨을 붙인 뒤 차이를 조정합니다. 사람의 불일치를 버릴 필요는 없습니다. 루브릭이 모호하거나 두 정책이 모두 타당하거나 자동 판정 대상이 아님을 보여주는 신호일 수 있습니다.

[MT-Bench와 Chatbot Arena 연구](https://arxiv.org/abs/2306.05685)는 특정 설정에서 강한 LLM 판정기와 사람 사이의 높은 일치도를 보고했지만, 위치 편향, 장황성 선호, 자기 선호, 추론 한계도 함께 기록했습니다. 그 일치율은 당시 모델·프롬프트·데이터에 속하며 다른 판정기의 정확도가 아닙니다.

[Large Language Models Are Not Fair Evaluators](https://arxiv.org/abs/2305.17926)는 후보 순서만 바꿔도 순위가 바뀔 수 있음을 보이고, 위치 균형, 복수 근거, 사람 개입을 제안했습니다. 15개 판정기, 22개 작업, 15만 건이 넘는 평가를 다룬 후속 [위치 편향 연구](https://arxiv.org/abs/2406.07791)는 편향의 크기가 판정기와 작업에 따라 다름을 확인했습니다. “더 강한 모델”은 현장 보정의 대체물이 아닙니다.

## 판정기가 쓰는 지름길을 시험한다

### 저장된 답을 반복 채점한다

후보 출력을 고정하고 같은 평가 기준과 설정으로 여러 번 실행합니다. 평균뿐 아니라 모든 판정과 기준별 결과를 보관합니다. 명백한 사례가 통과와 실패 사이를 오간다면 이 판정기를 이진 CI 게이트로 쓰기 이릅니다.

변동이 실제로 애매한 사례에 집중된다면 억지로 점수를 고정하지 말고 사람이 검토할 구간을 만드세요.

### A/B와 B/A를 모두 실행한다

쌍별 비교에서는 순서를 바꿉니다. 보수적인 정책은 두 순서가 같은 후보를 선택할 때만 승자로 인정하고, 충돌하면 동점 또는 사람 검토로 보냅니다. 대규모에서 순서를 무작위화하더라도 순서 일치율은 별도로 보고해야 합니다.

### 내용은 유지하고 표현만 바꿔 본다

내용은 유지한 채 길이, 제목, 정중함, 후보 이름, 자신감 있는 어조만 바꿉니다. 점수가 이런 표면을 따라가면 원래 평가하려던 품질보다 판정기의 표현 취향을 측정하고 있을 수 있습니다.

이 검사는 평가의 허점을 이용해 점수만 높이는 현상도 찾는 데 도움이 됩니다. 제품이 더 길고 권위적으로 쓰는 법을 배워 자동 점수만 오르고 전문가 품질은 그대로인 상황입니다.

### 근거가 있으면 근거를 함께 준다

추출, 출처 기반 Q&A, 요약 충실성, 수학, 도구 사용에는 원문, 참조 답 또는 실행 결과를 제공합니다. 판정 설명은 디버깅에 유용하지만 정답의 증명은 아닙니다. 같은 모델이 잘못된 결론을 그럴듯하게 설명할 수 있습니다.

## 보정은 평균 점수 맞추기가 아니다

판정기 평균이 사람보다 0.08 높다고 모든 결과에서 0.08을 빼면 순서 오류, 비대칭 비용, 특정 구간의 실패를 고치지 못합니다. 실제 게이트가 내릴 결정을 평가하세요.

- 명백한 실패를 얼마나 통과시키는가
- 좋은 답을 얼마나 잘못 막는가
- 언어, 작업, 길이, 위험 등급에 오류가 몰리는가
- 문턱 근처에서 결정이 얼마나 자주 뒤집히는가
- 사람도 애매해하는 사례와 판정기가 불안정한 사례가 겹치는가

실패한 답을 통과시키는 오류와 좋은 답을 탈락시키는 오류의 비용은 다릅니다. 고위험 조언의 오류를 놓치는 비용과 마케팅 문구를 한 번 더 검토하는 비용은 같은 임계값을 요구하지 않습니다. 먼저 비용과 검토 역량을 정한 뒤 샘플 크기, 반복 횟수, 불확실성 구간을 현장 데이터로 선택합니다. 모든 작업에 통하는 0.8 기준은 없습니다.

게이트 결과는 **통과**, **실패**, **사람 검토**처럼 세 가지가 더 정직할 수 있습니다. 연속 점수는 분석에 남겨도 되지만 보정 데이터보다 정밀한 척해서는 안 됩니다.

## 제품 평가와 함께 고정된 기준 답변을 다시 채점한다

사람의 판정이 확정된 기준 답변 묶음을 보존하고, 현재 판정기로 정기적으로 다시 채점합니다.

~~~text
제품 평가: 현재 제품 출력 -> 현재 판정기 -> 제품 품질 변화 확인
기준 평가: 저장된 고정 출력 -> 현재 판정기 -> 고정된 사람 라벨과 비교
~~~

제품 신호만 하락하고 앵커가 안정적이면 제품이나 트래픽 분포를 우선 조사합니다. 앵커에서도 현재 판정기가 더 엄격해졌다면 판정 모델, 루브릭, 예시, 파서, 서버 측 구현을 먼저 확인합니다. 두 스트림이 모두 불안정하면 측정 시스템이 게이트 역할을 할 상태가 아닙니다.

2026년 프리프린트 [Who Drifted: the System or the Judge?](https://arxiv.org/abs/2606.15474)는 고정된 사람 라벨 앵커에서 판정기-사람 차이를 측정하고 제품 스트림과 분리하는 방식을 형식화했습니다. 논문의 탐지율과 비용은 해당 실험 결과이지 배포 보장이 아닙니다. 제품을 바꿔도 저장해 둔 기준 답변은 달라지지 않습니다. 따라서 그 답변의 점수가 변했다면 현재 제품이 아닌 판정 과정부터 조사할 근거가 됩니다.

기준 답변 묶음을 릴리스마다 통째로 바꾸지 마세요. 새 사례는 새 데이터셋 버전에 추가하고 사람 라벨이나 정책이 바뀐 이유를 기록합니다.

![판정기 드리프트 보정 실행 플레이북으로 변화 진단, 측정 세트, 보정 지표, CI 게이트, 판정기 설정 버전과 흔한 증상을 정리](https://www.aifreeapi.com/posts/ko/llm-judge-drift-calibration/img/drift-calibration-playbook.webp)

## CI에서 확신하기 어려운 결과는 조사나 사람 검토로 보낸다

릴리스 게이트는 다음 순서로 증거를 확인할 수 있습니다.

~~~text
1. 코드로 확인 가능한 필수 조건을 모두 통과했는가
2. 판정기가 고정 앵커의 보정 범위 안에 있는가
3. 고정 출력 반복 판정이 충분히 안정적인가
4. 새 버전과 이전 버전의 차이가 통상 변동을 넘는가
5. 변화가 핵심·고위험 구간에 집중되는가
6. 사람에게 보낼 충돌 사례가 남았는가
~~~

결과는 통과, 차단, 판정기 조사, 사람 검토로 나뉩니다. “조사”는 실패가 아니라 잘못된 롤백이나 출시를 막는 정식 상태입니다.

온도 0과 seed도 완전한 결정성을 증명하지 않습니다. 모델 별칭, 추론 인프라, 프롬프트 조립, 도구 결과, 파서가 변할 수 있습니다. OpenAI의 과거 [seed와 system fingerprint 재현 예제](https://cookbook.openai.com/examples/reproducible_outputs_with_the_seed_parameter)는 당시 지원한 프리뷰 모델에서 요청 조건이 같을 때 “대체로 동일한” 출력을 목표로 했으며 결정성을 보장하지 않는다고 명시했습니다. 모든 최신 모델, API 주소와 서비스 제공자에 일반화할 수 없습니다.

판정 모델, 루브릭, 판정 예시, 출력 스키마, 파서, 집계 정책을 하나의 설정 버전으로 저장하세요. 제공되는 요청 ID, 샘플링 설정, 서버 구성 식별값도 기록합니다. 이 메타데이터는 차이를 설명할 뿐 확률적으로 달라지는 모델을 매번 같은 결과를 내는 단위 테스트로 바꿔 주지는 않습니다.

강한 판정기는 언제나 숫자를 내는 판정기가 아닙니다. 고정 출력에서 반복성이 측정되고, 사람의 평가 기준에 맞춰 보정되고, 편향 검사를 통과하고, 별도의 앵커 스트림으로 감시되는 판정기입니다. 증거가 모자랄 때 “아직 구분할 수 없다”고 말할 수 있어야 점수가 실제 릴리스 도구가 됩니다.