LLM-as-judge로 자동 채점하다 만난 함정 3개와 pairwise·rubric으로 우회한 방법

평가 데이터셋 채점을 LLM에 맡겼다가 점수가 못 미덥게 나와서, 같은 길로 빠질 분들을 위해 부딪힌 함정 세 가지와 우회법을 정리한다.

1) 단일 점수는 후하게 몰린다

"1~10점으로 매겨" 식으로 시키면 점수가 거의 다 7~9점에 몰린다. 모델이 웬만하면 좋게 보려는 경향이 있어서, 못 만든 답과 잘 만든 답의 점수 차가 거의 안 벌어진다.

→ 절대 점수를 버리고 pairwise로 바꿨다. "A와 B 중 어느 쪽이 더 나은가"를 둘 중 하나로 고르게 하면 변별이 확 산다.

2) position bias

pairwise로 바꾸니 이번엔 앞에 놓인 쪽을 더 자주 골랐다. A/B의 순서만 바꿔도 승자가 뒤집히는 케이스가 꽤 나왔다.

→ 같은 쌍을 순서를 바꿔 두 번 돌리고, 두 번 다 이긴 것만 승리로 인정했다. 한 번씩 갈리면 무승부 처리.

3) 정답을 모르는 도메인에선 길고 그럴듯한 답을 편애한다

이게 제일 위험하다. 채점자 LLM이 정답을 모르는 영역에선 내용의 맞고 틀림이 아니라, 길고 자신감 있고 형식을 갖춘 답에 점수를 더 준다. 틀렸는데 그럴듯하면 이긴다.

→ 점수나 선호를 묻는 대신 rubric을 yes/no 체크리스트로 쪼갰다. "핵심 수치를 언급했는가? Y/N", "조건 X를 다뤘는가? Y/N" 식으로. 이렇게 하면 답변 길이가 점수에 새어들지 못한다.

셋 다 겪은 뒤 평가 코드를 직접 짠 것에서 promptfoo로 옮겼다. assert에 llm-rubric/pairwise가 이미 들어 있어서 손으로 짠 채점 로직을 걷어내고 그대로 갖다 썼다.

마지막으로 한 가지. LLM-judge는 사람 평가를 대체하는 도구가 아니라 사람이 직접 봐야 할 샘플 수를 줄여주는 도구로 보는 게 맞다. 의심스러운 케이스만 사람이 확인하면 된다. 전부 맡기면 위 3번에서 조용히 망가진다.