에이전트 평가 2/4 — 사람과 90% 일치하는 LLM 판정자, 믿어도 될까
1편에서 평가셋이 커야 작은 차이를 잡을 수 있다고 했다. 과제가 수백, 수천 개가 되면 사람이 다 채점할 수 없으니 결국 LLM에게 채점을 맡긴다. 이른바 LLM-as-a-judge다.
그 다음 단계도 보통 비슷하다. 100개쯤 사람이 직접 라벨을 달고, 판정자와 비교해서 "사람과 90% 일치"를 확인한다. 그리고 안심한다.
그런데 90% 일치는 생각보다 아무 말도 안 해 주는 숫자일 수 있다.
판정자 세 명을 만나 보자
위젯 위쪽 버튼 세 개가 각각 다른 판정자다. 하나씩 눌러 보자.
| 답 1,000개 | 판정자: 합격 | 판정자: 불합격 |
|---|---|---|
| 사람: 좋은 답 | 900 | 0 |
| 사람: 나쁜 답 | 100 | 0 |
카파 해석 구간(0.2·0.4·0.6·0.8)은 관례적인 기준일 뿐 정답은 아니다. 보정값은 판정자의 민감도·특이도를 정확히 안다고 가정한 것이다.
무조건 합격 주는 판정자는 어떤 답이 와도 합격이라고 한다. 아무것도 판단하지 않는다. 그런데 에이전트 답의 90%가 실제로 좋은 답이면, 사람과의 일치율이 90%다. 코헨 카파는 0, 우연과 똑같다.
후한 판정자는 좋은 답은 95% 합격시키는데, 나쁜 답도 40%는 그냥 통과시킨다. 일치율은 89.75%로 거의 같다. 카파는 0.58.
균형 잡힌 판정자는 좋은 답도 나쁜 답도 90%씩 맞게 판정한다. 일치율 90%, 카파 0.67.
세 판정자 모두 "사람과 약 90% 일치"라고 보고될 수 있다. 하지만 첫 번째는 쓸모가 없고, 두 번째는 나쁜 답 열 개 중 네 개를 놓친다.
일치율 대신 무엇을 봐야 하나
일치율이 속는 이유는 단순하다. 한쪽 답이 압도적으로 많으면, 그쪽만 찍어도 일치율이 높게 나온다. 에이전트가 웬만큼 잘 돌아가는 시점에는 좋은 답이 80~90%라서, 이 함정에 딱 빠지기 좋다.
그래서 판정자 성능은 두 숫자로 나눠서 본다.
- 민감도(TPR): 사람이 좋다고 한 답을 판정자도 합격시키는 비율
- 특이도(TNR): 사람이 나쁘다고 한 답을 판정자도 불합격시키는 비율
에이전트 평가에서 보통 더 중요한 건 특이도다. 평가를 하는 이유가 나쁜 답을 찾기 위해서니까. 위젯에서 특이도를 낮추면 2×2 표의 주황색 칸, "사람은 나쁘다는데 판정자는 합격"이 늘어나는 게 보일 거다. 그 칸이 판정자가 숨겨 주는 버그다.
코헨 카파는 이 둘을 한 숫자로 묶으면서 우연히 맞을 확률을 빼 준다. 하나만 보고하라면 일치율보다는 카파가 낫다. 하지만 나라면 카파 하나보다는 민감도와 특이도를 둘 다 적겠다. 어느 쪽으로 틀리는지가 보여야 프롬프트를 고칠 수 있으니까.
판정자가 보고하는 합격률도 틀린다
위젯의 세 번째 카드를 보자. 균형 잡힌 판정자(90/90)를 고르면 실제 합격률은 85%인데 판정자는 78%라고 보고한다. 7%p를 깎아 먹는다. 후한 판정자는 반대로 86.75%로 조금 부풀린다.
이게 왜 문제냐면, 1편에서 본 "A 82% vs B 78%" 같은 비교를 판정자가 채점한 숫자로 하고 있을 가능성이 높아서다. 판정자의 편향이 두 버전에 똑같이 걸린다면 차이는 그나마 남는다. 하지만 버전 B가 답을 더 길게 쓰는 버전이라면? LLM 판정자는 긴 답을 선호하는 경향이 보고돼 있다(verbosity bias). 그러면 판정자는 품질이 아니라 길이 차이를 재고 있을 수 있다.
판정자의 민감도·특이도를 알고 있다면 보고된 합격률을 보정할 수 있다. 위젯의 "보정하면" 값이 그거다.
보정 합격률 = (보고된 합격률 + 특이도 − 1) / (민감도 + 특이도 − 1)수식은 간단한데, 함정이 하나 있다. 민감도와 특이도를 "정확히 안다"는 가정이다.
사람 라벨 100개의 함정
1편의 오차 막대가 여기서 다시 나온다. 사람 라벨 100개를 달았는데 좋은 답이 85%라면, 나쁜 답은 15개뿐이다. 특이도를 15개로 재는 거다. 15개 중 12개를 맞혔다면 특이도 80%인데, 95% 구간은 대략 55%에서 93%까지다. 이 숫자로 보정하면 보정값도 같이 흔들린다.
그래서 판정자 검증용 라벨셋은 무작위로 뽑으면 안 되고, 나쁜 답을 일부러 더 모아야 한다. 실패 로그, 사용자 불만, 일부러 망가뜨린 답 같은 걸 섞어서 좋은 답과 나쁜 답의 비율을 반반 가까이 맞추는 식이다. 판정자 성능을 재는 데이터셋과 에이전트 성능을 재는 데이터셋은 목적이 다르다. 당연한 말 같은데, 하나로 같이 쓰다가 놓치기 쉽다.
판정자를 만들 때 체크해 볼 것
- 합격/불합격 이진 판정을 먼저 쓴다. 1~10점 척도는 점수 간격이 판정자마다, 실행마다 흔들린다
- 판정 이유를 먼저 쓰게 하고 결론을 나중에 내게 한다
- 두 답을 비교시킬 때는 순서를 바꿔서 두 번 돌려 본다. 위치 편향(position bias)이 꽤 있다
- 판정자 프롬프트를 고칠 때마다 민감도·특이도를 다시 잰다. 판정자도 프롬프트이고, 프롬프트는 회귀한다
판정자를 같은 모델로 쓸 때
에이전트와 판정자가 같은 모델이면, 같은 맹점을 공유할 가능성이 있다. 에이전트가 틀리는 지점에서 판정자도 같이 틀리면 그 오류는 평가에 영영 안 잡힌다. 이건 위젯의 독립 가정이 가장 크게 깨지는 경우다.
아직 고민 중인 것
판정자를 검증할 사람 라벨은 결국 누군가 달아야 한다. 보험·금융처럼 도메인 전문가가 필요한 영역에서는 그 사람 시간이 가장 비싸다. 판정자를 완벽하게 만드는 것보다, 판정자가 애매하다고 한 것만 사람에게 보내는 구조가 현실적인 것 같다. 이게 다음 편의 검증기 문턱값 얘기와 이어진다.
참고자료
- Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (Zheng et al., 2023) — 위치·길이·자기 선호 편향을 정리한 논문
- Using LLM-as-a-Judge For Evaluation: A Complete Guide (Hamel Husain) — 도메인 전문가와 판정자를 맞춰 가는 실무 과정