G-Eval은 요약, 챗봇 답변, 글쓰기 보조처럼 정답 하나로 비교하기 어려운 생성 결과를 LLM Judge로 평가하는 프레임워크다. 단순히 “1점부터 5점까지 매겨라”라고 묻는 대신, 평가 기준을 명시하고, 모델이 평가 절차를 만들게 한 뒤, 출력된 숫자보다 점수 토큰의 확률 분포를 읽어 더 세밀한 점수를 만든다.
구성 요소
G-Eval은 세 단계로 볼 수 있다.
- 루브릭 정의: coherence, relevance, factuality처럼 평가 차원을 구체적으로 정의한다.
- 평가 단계 생성: 모델이 그 루브릭을 어떻게 판정할지 단계별 절차를 만든다.
- 확률 가중 점수화: 출력된 정수 하나가 아니라 1~5 점수 토큰의 확률 질량을 이용해 기대값을 계산한다.
예를 들어 judge가 4점에 55%, 5점에 45% 확률을 두면 최종 점수는 4가 아니라 4.45에 가깝다. 이렇게 하면 후보 간 미세한 차이를 정수 점수보다 잘 보존한다.
왜 필요한가
LLM 애플리케이션 평가는 정확한 정답이 있는 문제보다 열린 생성물이 더 어렵다. 고객 지원 답변, 정책 설명, 요약문, 브랜드 톤 일치 여부는 BLEU·ROUGE 같은 문자열 겹침 지표로 잘 잡히지 않는다. G-Eval은 사람이 평가표를 보고 채점하는 절차를 LLM에게 구조화해 맡기는 방식이다.
다만 이 방식도 만능은 아니다. JSON 유효성, 개인정보 포함 여부, 금칙어 포함 여부처럼 결정론적으로 검사 가능한 항목에는 LLM Judge보다 파서, 정규식, 분류기를 쓰는 편이 낫다.
실무 주의점
LLM Judge는 중립적이지 않다. 특히 다음 문제가 자주 나온다.
- 자기 선호(self-preference): judge가 자기 계열 모델의 출력을 더 좋게 보는 경향이 있다.
- 장문 선호(verbosity bias): 더 길지만 불필요한 답변을 더 높은 품질로 오판할 수 있다.
- 루브릭 누락: “좋은 답변”처럼 흐릿한 기준은 judge를 일반적인 인상 평가로 끌고 간다.
따라서 judge 모델은 평가 대상 모델과 다른 계열로 두고, 루브릭을 구체화하며, 작은 human-labeled set으로 보정해야 한다. 평가 단계는 루브릭별로 캐시해 비용을 줄일 수 있다.
도구 생태계
DeepEval은 G-Eval 구현을 제공하고, RAGAS·Promptfoo 같은 평가 도구도 LLM-as-a-judge 방식을 다양한 형태로 쓴다. G-Eval 자체는 제품이라기보다 평가 패턴에 가깝다. 중요한 것은 어떤 프레임워크를 쓰느냐보다 judge 설계, 편향 감시, human calibration을 같이 운영하는 것이다.
관련 문서
- llm-evaluation-tips-frameworks — RAGAS·DeepEval·Promptfoo와 LLM Judge 편향
- rag-evaluation-tips-frameworks — RAG 평가 프레임워크 선택 기준
- ai-agent-evaluation-tips-roadmap — 에이전트 평가 설계 순서
참고 자료
- G-Eval, Explained — Arpit Bhayani (2026-07)