LLM에게 답변을 주고 “품질을 5점 만점으로 평가해줘”라고 하면 숫자는 쉽게 얻을 수 있다. 어려운 것은 그 숫자가 무엇을 뜻하는지 설명하는 일이다.
어떤 평가자는 문장이 자연스러우면 높은 점수를 주고, 다른 평가자는 작은 누락에도 점수를 깎을 수 있다. 기준이 모호하면 모델의 차이와 평가자의 해석 차이를 구분하기 어렵다.
앞선 글에서는 LLM-as-Judge의 역할과 한계를 살펴봤다. 이번에는 평가자가 확인해야 할 조건을 어떻게 작성할지에 집중한다. 아래 문장과 판정은 모두 설명용 가상 사례이며 실제 모델 실험 결과가 아니다.
점수를 정하기 전에 과제를 정한다
가상의 도서관 안내문을 한 문장으로 요약한다고 하자.
도서관은 월요일에 휴관한다. 화요일부터 일요일까지 오전 9시부터 오후 6시까지 운영한다. 어린이 자료실은 오후 5시에 문을 닫는다.
“잘 요약했는가?”만으로는 요구사항이 충분하지 않다. 짧은 운영 안내를 만들려는지, 모든 시설의 운영 시간을 전달하려는지에 따라 필요한 정보가 달라진다.
이 글에서는 요청을 다음처럼 고정한다.
방문자가 이용 시간을 알 수 있도록, 휴관일·일반 운영 시간·어린이 자료실의 예외 시간을 모두 포함해 한 문장으로 요약한다.
평가 기준은 이 요청에서 나온다. 나중에 특정 답변을 더 좋게 보이게 하려고 필요한 정보를 추가하거나 빼서는 안 된다.
하나의 총점을 여러 확인 항목으로 나눈다
이 예시에서는 다음 네 항목을 사용한다.
| 항목 | 통과 조건 | 실패 예시 |
|---|---|---|
| 사실 충실성 | 원문의 운영 조건과 모순되지 않는다 | 월요일에도 운영한다고 설명 |
| 핵심 정보 보존 | 휴관일·일반 운영 시간·자료실 예외를 모두 포함 | 자료실 조기 종료 누락 |
| 근거 없는 추가 | 원문에 없는 사실을 단정하지 않는다 | 예약이 필수라고 추가 |
| 형식 준수 | 한 문장으로 작성한다 | 여러 문장으로 분리 |
여기서 사실 충실성과 근거 없는 추가는 구분한다. 원문에 정면으로 어긋나는 내용은 첫 번째 항목에서, 원문에 없어서 확인할 수 없는 단정은 세 번째 항목에서 확인한다. 이 글의 기준에서 사실 충실성 통과는 모든 사실이 검증됐다는 뜻이 아니라 원문과의 명시적인 모순이 발견되지 않았다는 뜻이다.
두 항목이 같은 오류를 함께 포착할 수도 있다. 기준별 실패 횟수를 단순히 합쳐 서로 다른 오류의 개수라고 해석하면 안 된다.
경계 사례가 있어야 기준을 공유할 수 있다
기준 문장만 읽으면 이해했다고 생각하기 쉽다. 실제로는 경계 사례에서 해석이 갈린다.
| 후보 요약 | 이 기준에서의 해석 |
|---|---|
| 월요일은 휴관하며 화~일요일 9~18시에 운영하고 어린이 자료실은 17시에 닫는다. | 네 항목 통과 |
| 도서관은 매일 9~18시에 운영한다. | 휴관 조건과 모순되고 예외 정보도 누락 |
| 월요일은 휴관하며 화~일요일 9~18시에 운영한다. | 모순은 없지만 자료실 예외가 누락 |
| 월요일은 휴관하며 화~일요일 9~18시에 운영하고 어린이 자료실은 17시에 닫으며 예약이 필수다. | 필수 정보는 있지만 근거 없는 조건 추가 |
세 번째 후보처럼 틀린 말을 하지 않는 것과 필요한 말을 모두 하는 것은 다르다. 사실 충실성만 검사하면 누락을 놓친다. 반대로 핵심 정보만 검사하면 그 뒤에 덧붙인 잘못된 조건을 놓칠 수 있다.
판정 예시는 좋은 문장 하나만 두기보다, 누락·모순·추가를 각각 하나씩 바꾼 사례로 구성하면 차이가 선명해진다. 이는 평가 모델의 성능을 입증하는 실험이 아니라 기준을 설명하고 점검하기 위한 설계 방법이다.
판단 불가를 실패와 분리한다
원문의 일부가 잘려 일반 운영 시간을 확인할 수 없다면 어떻게 해야 할까? 근거가 부족한 상태에서 후보가 맞거나 틀렸다고 단정하면 새로운 오류가 생긴다.
이 예시의 판정 값은 세 가지다.
- pass: 해당 항목을 판단할 근거가 있고 조건을 충족한다.
- fail: 해당 항목을 판단할 근거가 있고 조건을 위반한다.
- unclear: 원문 누락이나 해석 불가능 등으로 판단 근거가 부족하다.
후보가 필요한 정보를 빠뜨린 것은 fail이다. 평가에 필요한 원문 자체가 손상된 경우에는 해당 항목을 unclear로 남긴다. 이 구분을 명시하지 않으면 평가자가 어려운 사례를 전부 판단 불가로 돌릴 수 있다.
API 시간 초과나 JSON 파싱 오류는 또 다른 문제다. 이는 내용에 대한 판단 불가가 아니라 평가 실행 실패이므로 별도 상태로 기록한다.
치명적인 오류를 평균 점수로 덮지 않는다
운영 시간을 잘못 안내했지만 문장이 매끄럽고 짧다는 이유로 총점이 높아지는 평가를 원할까?
이 안내문에서는 사실 충실성·핵심 정보 보존·근거 없는 추가를 필수 조건으로 두고, 형식은 별도 수정 항목으로 관리할 수 있다. 이 경우 내용 판정은 다음 규칙으로 정한다.
- 필수 항목 중 하나라도
fail이면 내용 검토에서 탈락한다. - 실패는 없지만
unclear가 있으면 사람 검토로 보낸다. - 필수 항목이 모두
pass이면 내용 검토를 통과한다. - 형식 위반은 별도 표시하고 최종 공개 전에 수정한다.
필수 조건은 과제마다 달라진다. 모든 서비스를 같은 규칙으로 채점하자는 의미는 아니다. 총점으로 합치기 전에 통과 조건부터 합의하자는 것이다.
평가 프롬프트에는 근거와 기준 버전을 남긴다
평가 요청에는 원문·후보·기준을 구분해서 넣고, 항목별 판정과 짧은 근거를 반환하도록 한다.
{
"rubric_version": "library-summary-v1",
"case_id": "missing-exception",
"checks": {
"consistency": {"verdict": "pass", "reason": "원문과 모순되는 운영 조건은 없음"},
"coverage": {"verdict": "fail", "reason": "어린이 자료실의 17시 종료가 빠짐"},
"grounding": {"verdict": "pass", "reason": "원문에 없는 조건을 추가하지 않음"}
}
}
이 JSON은 기대하는 반환 구조를 보여주는 수기 예시다. 이유가 자연스럽다고 판정까지 정확하다고 볼 수는 없다. 실제 적용에서는 근거가 원문과 일치하는지도 확인해야 한다.
형식 검사는 별도 코드나 검사기로 관리할 수 있다. 다만 문장 수처럼 약어·목록·문장부호에 따라 해석이 달라지는 항목은 무엇을 한 문장으로 셀지 먼저 정해야 한다.
기준 자체도 검증해야 한다
사람 두 명이 같은 기준을 읽고도 자주 다른 판정을 한다면, 평가 모델을 바꾸기 전에 기준을 살펴볼 이유가 있다. 필수 정보의 범위가 모호한지, 원문에 없는 단정과 모순을 혼동하는지 확인한다.
기준을 다듬는 데 쓴 사례만 계속 평가하면 그 사례에만 맞춘 기준이 될 수 있다. 개발용 사례와 최종 확인용 사례를 나누고, 기준을 수정한 뒤에는 별도 사례에서도 확인하는 편이 좋다.
Judging the Judges 연구도 평가 모델의 사람 판정 일치율만으로 충분하지 않으며 점수 차이와 평가 성향을 함께 살펴야 한다고 지적한다. 기준표를 잘 작성하는 것은 시작점이고, 그 기준이 의도대로 적용되는지 확인하는 과정이 뒤따라야 한다.
다음 글에서는 이 기준을 고정된 데이터로 저장하고, 평가 결과의 변화를 회귀 테스트로 확인하는 방법을 다룬다.