LLM 평가자 (LLM-as-a-Judge)

중급

LLM 평가자 (LLM-as-a-Judge)는 자동화 문맥에서 자주 등장하는 개념입니다. 이 페이지는 중급 난이도로 LLM 평가자 (LLM-as-a-Judge)의 뜻과 쓰임을 빠르게 이해할 수 있도록 정리한 AI 용어사전 항목입니다.

LLM 평가자 (LLM-as-a-Judge)를 처음 보는 독자도 헷갈리지 않도록 정의와 맥락, 관련 용어 6개를 한 페이지에 묶었습니다. 아래 설명을 먼저 읽고, 이어서 연결된 개념과 글까지 보면 이해가 훨씬 빨라집니다.

LLM 평가자(LLM-as-a-Judge)는 모델이 만든 답변의 품질을 사람 대신 다른 언어 모델이 채점하게 하는 평가 방식입니다. 정답이 하나로 정해지지 않는 작업을 자동으로, 그리고 반복해서 평가할 수 있게 해 주기 때문에 모델 평가 실무에서 빠르게 자리를 잡았습니다.

왜 필요한가

분류나 번역처럼 정답이 명확한 과제는 정확도나 BLEU 같은 지표로 잽니다. 문제는 요약, 상담 응대, 보고서 초안처럼 정답이 여러 개인 작업입니다. 같은 질문에 대해 표현이 전혀 다른 두 답변이 모두 훌륭할 수 있고, 정답 문자열과 얼마나 겹치는지를 세는 방식으로는 품질을 잡아내지 못합니다. 사람이 직접 읽고 채점하면 가장 정확하지만 느리고 비싸서, 프롬프트를 조금 고칠 때마다 전체를 다시 돌릴 수 없습니다.

LLM 평가자는 이 지점을 메웁니다. 평가 기준을 프롬프트로 적어 두면 수백 건의 답변을 몇 분 안에 채점할 수 있어, 프롬프트나 모델을 바꿀 때마다 회귀 테스트처럼 돌릴 수 있습니다. 사람 평가를 대체한다기보다, 사람이 볼 표본을 좁혀 주는 1차 필터로 쓰는 것이 현실적인 위치입니다.

채점 방식

크게 세 가지 형태가 쓰입니다. 답변 하나에 점수를 매기는 단일 채점, 두 답변을 나란히 놓고 어느 쪽이 나은지 고르게 하는 쌍 비교, 항목별 기준표를 주고 각각 판정하게 하는 기준표 방식입니다. 쌍 비교는 절대 점수를 매길 때보다 판정이 안정적이고, 기준표 방식은 '근거 문서에 없는 내용을 지어냈는가' 같은 항목을 따로 뽑아낼 수 있어 원인 분석에 유리합니다.

채점 결과는 사람이 읽는 문장이 아니라 구조화된 출력으로 받는 편이 좋습니다. 점수와 판정 근거를 정해진 형식으로 받아야 집계와 추적이 가능하기 때문입니다. 판정 근거를 먼저 쓰게 하고 점수를 마지막에 내도록 순서를 정하면 결과가 조금 더 일관됩니다.

기준을 얼마나 구체적으로 적는지가 결과를 좌우합니다. '좋은 답변인지 평가하라'처럼 막연하게 쓰면 평가자마다, 심지어 같은 평가자도 호출마다 다른 기준으로 채점합니다. '근거 문서에 없는 수치를 제시하면 0점', '질문에 없는 조건을 임의로 가정하면 감점'처럼 실패 사례를 직접 적어 두는 편이 훨씬 안정적입니다. 결국 프롬프트 엔지니어링 문제이기도 합니다.

알려진 편향

LLM 평가자는 사람과는 다른 방향으로 치우칩니다. 먼저 제시된 답변을 더 높게 치는 위치 편향, 내용과 무관하게 긴 답변을 선호하는 길이 편향, 자기와 같은 계열 모델이 쓴 답변을 후하게 보는 자기 선호 편향이 대표적입니다. 이런 편향을 그대로 두면 평가 결과가 실제 품질이 아니라 형식을 따라가게 됩니다.

대응 방법은 정해져 있습니다. 쌍 비교는 순서를 바꿔 두 번 채점하고 결과가 뒤집히면 무승부로 처리합니다. 채점 대상과 다른 계열의 모델을 평가자로 씁니다. 그리고 무엇보다, 사람이 직접 매긴 라벨 100건 정도를 기준으로 평가자의 판정이 사람과 얼마나 일치하는지 먼저 확인해야 합니다. 이 검증을 건너뛰면 평가자가 무엇을 재고 있는지 모르는 채 숫자만 쌓게 됩니다.

쓰이는 자리

가장 흔한 용도는 RAG 시스템 평가입니다. 답변이 검색된 문서에 근거하는지를 보는 충실도, 질문에 실제로 답했는지를 보는 답변 관련성 같은 지표가 LLM 평가자로 계산됩니다. 근거 없이 지어낸 내용을 잡아내는 할루시네이션 점검에도 같은 방식이 쓰이고, 배포 전 회귀 테스트나 가드레일 위반 여부 판정에도 활용됩니다.

공개 벤치마크에서도 같은 방식이 쓰입니다. 여러 모델의 답변을 쌍으로 비교해 순위를 매기는 리더보드 상당수가 사람 투표와 LLM 평가자를 함께 씁니다. 다만 이런 순위는 평가에 쓴 질문 세트의 성격을 반영할 뿐이므로, 내 업무와 질문 유형이 다르면 순위가 그대로 옮겨 오지 않는다는 점을 기억해야 합니다.

비용과 한계도 함께 봐야 합니다. 답변 하나마다 평가자 모델을 한 번씩 돌리므로 평가 자체가 적지 않은 토큰을 씁니다. 평가자 모델을 바꾸면 점수 기준선도 함께 움직여 이전 결과와 직접 비교하기 어렵습니다. 그래서 평가자 모델과 채점 프롬프트를 버전으로 고정해 두고, 바꿀 때는 기준선을 다시 잡는 절차를 함께 두는 편이 안전합니다.