LLM 평가와 hallucination

이 장에서 배울 것

이 장에서는 LLM 앱의 답변 품질을 감이 아니라 기준으로 평가하는 법을 배운다. 특히 다음을 다룬다.

• 정확성, 관련성, 완전성, 근거 충실성, 형식 준수, 안전성, 비용·지연시간을 나누어 평가한다.

• 정답이 있는 평가와 정답이 없는 평가를 구분한다.

• golden dataset, human review, LLM-as-judge의 장단점을 이해한다.

• hallucination을 여러 유형으로 나누어 관찰한다.

• 일반 프롬프트, 출처 요구 프롬프트, RAG 기반 답변을 비교 실험한다.

여기서 hallucination은 보통 "그럴듯하지만 사실과 맞지 않거나, 주어진 근거에 없는 내용을 생성하는 현상"을 뜻한다. 연구 문헌에서는 이를 주어진 source와 어긋나는 오류, 외부 사실과 어긋나는 오류 등으로 나누어 설명한다¹.

왜 이 주제가 중요한가

LLM 답변은 문장이 자연스럽다. 그래서 틀린 답도 쉽게 믿게 된다. 이것이 가장 위험한 지점이다.

업무에서는 "답이 좋아 보인다"만으로 충분하지 않다. 사내 규정, 계약서, 고객 상담, 의료·법률·재무 문서처럼 근거가 중요한 영역에서는 한 문장의 오류가 실제 피해로 이어질 수 있다. RAG를 붙였다고 안전해지는 것도 아니다. 검색 문서를 잘못 가져오거나, 맞는 문서를 가져오고도 모델이 문서 밖 내용을 덧붙일 수 있다. Function calling을 쓰는 경우에도 도구 선택 오류, 도구 결과 오해, 실패한 도구 호출을 숨기고 답을 꾸미는 문제가 생길 수 있다.

따라서 LLM 앱은 모델 자체보다 평가 체계가 중요하다. 좋은 시스템은 한 번 멋진 답을 내는 시스템이 아니다. 같은 조건에서 반복적으로 검증 가능한 답을 내는 시스템이다.

핵심 개념 설명

1. LLM 앱 평가 기준

LLM 답변은 하나의 점수로 평가하기 어렵다. 최소한 다음 기준을 나누어 보아야 한다.

RAG 평가에서는 특히 질문, 검색된 context, 답변의 관계가 중요하다. 예를 들어 Ragas는 faithfulness, answer relevancy, context precision, context recall 같은 지표로 검색과 생성을 나누어 평가한다². 쉽게 말해, 검색기는 필요한 문서를 잘 가져와야 하고, 생성 모델은 그 문서에 근거해 질문에 맞게 답해야 한다.

2. 정답이 있는 평가와 정답이 없는 평가

정답이 있는 평가는 비교적 단순하다. 예를 들어 "우리 회사 연차 이월 한도는 며칠인가?"라는 질문에 정답 문서와 정답 문장이 있다면 모델 답변을 채점할 수 있다. 이런 데이터셋을 golden dataset이라고 부른다. 사람이 확인한 기준 질문, 정답, 근거 문서, 허용 가능한 표현을 모아 둔 평가셋이다.

정답이 없는 평가는 더 어렵다. 예를 들어 "이 계약서의 위험 조항을 요약해 줘"에는 여러 좋은 답이 가능하다. 이때는 정답 하나를 맞히는 방식보다 평가 기준표, 즉 rubric이 필요하다.

예시는 다음과 같다.

• 5점: 모든 핵심 위험을 문서 근거와 함께 제시했다.

• 3점: 중요한 위험은 말했지만 일부 근거가 약하거나 누락되었다.

• 1점: 문서에 없는 위험을 만들거나 핵심 위험을 놓쳤다.

3. human review와 LLM-as-judge

사람 평가는 가장 신뢰하기 쉽지만 비용이 많이 든다. 평가자마다 기준이 달라질 수도 있다. 그래서 실무에서는 중요한 샘플은 사람이 보고, 대량 샘플은 LLM 평가자가 1차 채점하는 방식을 자주 쓴다.

LLM-as-judge는 LLM에게 평가자 역할을 맡기는 방법이다. 장점은 빠르고 유연하다는 것이다. 단점은 평가자 역시 LLM이라는 점이다. 평가 모델도 편향될 수 있고, 같은 답을 매번 똑같이 평가하지 않을 수 있다. 실제 연구에서도 hallucination 평가 지표들이 사람 판단과 항상 잘 맞지는 않으며, 데이터셋과 작업에 따라 성능이 달라진다는 점이 보고되었다³.

따라서 LLM-as-judge는 "객관적 판사"가 아니라 "비용이 낮은 보조 평가자"로 보아야 한다.

Hallucination의 주요 유형

Hallucination을 하나로 뭉뚱그리면 개선이 어렵다. 다음처럼 나누어 기록해야 한다.

1. 사실 오류
   날짜, 인물, 기관명, 수치가 틀린다.
   예: "제품 출시일은 2024년"인데 "2023년"이라고 답한다.

2. 출처 조작
   존재하지 않는 논문, 링크, 문서명을 만든다.
   예: 실제 사내 문서에 없는 "보안정책 v7.2"를 인용한다.

3. 문서에 없는 내용 추가
   답의 일부는 맞지만, 근거 문서에 없는 해석을 덧붙인다.
   RAG 시스템에서 특히 자주 본다.

4. 계산 오류
   단가, 비율, 날짜 차이, 합계를 틀린다. LLM은 계산기처럼 동작하지 않는다. 중요한 계산은 도구로 검증해야 한다.

5. 지시 불이행
   "모르면 모른다고 답하라", "JSON만 출력하라", "출처를 붙이라" 같은 지시를 어긴다. 이는 사실 오류는 아니지만 실제 앱에서는 치명적인 품질 문제다.

이렇게 유형을 나누면 개선 방법도 달라진다. 사실 오류와 출처 조작은 RAG와 검증 단계가 필요하다. 계산 오류는 계산 도구 호출이 필요하다. 지시 불이행은 프롬프트, 출력 검증기, 재시도 로직으로 줄여야 한다.

쉬운 비유 또는 사례

LLM 평가는 신입 직원의 보고서를 검토하는 일과 비슷하다.

신입 직원이 문장을 잘 쓴다고 해서 보고서가 맞는 것은 아니다. 상사는 다음을 확인한다.

• 질문에 맞는 보고서인가?

• 근거 자료를 제대로 읽었는가?

• 없는 수치를 만들지 않았는가?

• 출처가 실제로 존재하는가?

• 정해진 양식으로 제출했는가?

• 급하게 쓰느라 중요한 내용을 빠뜨리지 않았는가?

LLM도 마찬가지다. 문장력은 평가의 한 부분일 뿐이다. 업무용 LLM은 글쓰기 능력보다 근거를 지키는 능력이 더 중요하다.

직접 해보는 실습

이번 실습의 목표는 같은 질문을 세 가지 방식으로 답하게 한 뒤 hallucination 발생률과 근거 일치율을 기록하는 것이다.

1단계: 평가셋 만들기

한국어 문서 3~5개를 준비한다. 예를 들어 회사 복지 규정, 제품 설명서, 학교 공지, 공공기관 안내문처럼 답이 문서 안에 있는 자료가 좋다.

질문은 10개 이상 만든다.

• 문서에 답이 명확히 있는 질문 6개

• 여러 문서를 함께 봐야 하는 질문 2개

• 문서에 답이 없는 질문 2개

각 질문마다 다음을 적는다.

2단계: 세 가지 방식으로 답변 생성

A. 일반 프롬프트

다음 질문에 답해 주세요.
질문: {question}

B. 출처 요구 프롬프트

다음 질문에 답해 주세요.
가능하면 출처를 함께 적어 주세요.
모르면 모른다고 말하세요.
질문: {question}

C. RAG 기반 답변

아래 문서 내용만 근거로 답하세요.
문서에 답이 없으면 "제공된 문서에서 확인할 수 없습니다"라고 답하세요.

[문서]
{retrieved_context}

[질문]
{question}

3단계: 결과 기록

각 답변을 다음 표로 기록한다.

계산은 단순하게 시작한다.

• hallucination 발생률 = hallucination이 있는 답변 수 / 전체 답변 수

• 근거 일치율 = 근거와 일치한 답변 수 / 전체 답변 수

• 답 없음 정확도 = 답이 없는 질문에서 거절한 수 / 답이 없는 질문 수

• 형식 준수율 = 형식을 지킨 답변 수 / 전체 답변 수

가능하면 같은 질문을 3회씩 반복해 보자. SelfCheckGPT 계열 접근은 같은 질문에 대한 여러 샘플이 서로 모순되면 불확실성이 높을 수 있다는 아이디어를 활용한다⁴. 실무에서도 반복 생성 결과가 크게 흔들리는 질문은 위험 신호로 볼 수 있다.

흔한 실수와 오류 분석

실수 1. 평가셋 없이 감으로 모델을 고른다

몇 개 질문만 던져 보고 "이 모델이 더 똑똑하다"고 판단하면 위험하다. 쉬운 질문에서는 차이가 안 보인다. 어려운 질문, 답이 없는 질문, 최신 문서 기반 질문을 넣어야 실제 차이가 드러난다.

실수 2. LLM 평가자를 무조건 객관적이라고 믿는다

LLM 평가자는 편리하지만 완벽하지 않다. 평가 프롬프트가 애매하면 점수도 흔들린다. 중요한 평가는 사람 검토 샘플을 섞고, 평가자 모델의 판단 이유를 함께 저장해야 한다.

실수 3. 출처 링크만 있으면 답이 맞다고 본다

링크가 있다고 답이 맞는 것은 아니다. 출처가 실제로 존재하는지, 링크 내용이 답변을 지지하는지, 답변이 출처를 과장하지 않았는지 확인해야 한다.

실수 4. 평균 점수만 본다

평균 4.3점인 시스템도 특정 질문군에서 계속 틀릴 수 있다. 예를 들어 "답 없음" 질문에서만 모두 실패한다면 고객 신뢰가 크게 떨어진다. 평균과 함께 오류 유형별 분포를 보아야 한다.

실수 5. 모델만 평가하고 전체 앱을 평가하지 않는다

사용자는 모델을 쓰는 것이 아니라 앱을 쓴다. 검색기, 프롬프트, 도구 호출, 후처리, UI 문구까지 함께 평가해야 한다.

요약

LLM 평가는 "좋은 답처럼 보이는가"가 아니라 "기준에 따라 반복 검증되는가"를 확인하는 과정이다. 정확성, 관련성, 완전성, 근거 충실성, 형식 준수, 안전성, 비용·지연시간을 나누어 보아야 한다. hallucination도 사실 오류, 출처 조작, 문서에 없는 내용 추가, 계산 오류, 지시 불이행으로 나누어 기록해야 개선할 수 있다.

RAG와 출처 요구 프롬프트는 hallucination을 줄일 수 있지만 완전히 없애지는 못한다. 그래서 golden dataset, human review, LLM-as-judge, 반복 실험, 근거 확인을 함께 사용해야 한다. 검증 질문을 따로 만들어 초안을 점검하는 Chain-of-Verification 같은 접근도 hallucination을 줄이는 방법으로 연구되어 왔다⁵.

퀴즈

1. LLM 답변 평가에서 "근거 충실성"은 무엇을 확인하는 기준인가?

2. 정답이 있는 평가와 정답이 없는 평가는 어떻게 다른가?

3. LLM-as-judge의 장점과 한계를 각각 하나씩 쓰시오.

4. 출처 링크가 포함된 답변도 hallucination일 수 있는 이유는 무엇인가?

5. RAG 시스템 평가에서 context precision과 context recall이 낮을 때 각각 어떤 문제가 생기는가?

체크리스트

• 평가 기준을 정확성, 관련성, 완전성, 근거 충실성 등으로 나누었다.

• 최소 10개 이상의 작은 golden dataset을 만들었다.

• 답이 없는 질문을 평가셋에 포함했다.

• 일반 프롬프트, 출처 요구 프롬프트, RAG 답변을 비교했다.

• hallucination 유형을 따로 기록했다.

• LLM 평가 결과 중 일부를 사람이 다시 확인했다.

• 평균 점수뿐 아니라 실패 사례를 읽었다.

• 비용과 지연시간도 함께 기록했다.

다음 장 연결

다음 장에서는 한국어 LLM 활용 과제를 다룬다. 한국어는 띄어쓰기, 조사, 한자어, 복합명사, 존댓말, 문서 양식 때문에 검색과 평가가 더 까다롭다. 이번 장에서 배운 평가 기준을 바탕으로, 다음 장에서는 한국어 문서 기반 LLM 앱을 만들 때 어떤 문제가 자주 발생하는지 살펴본다.

참고

¹Survey of Hallucination in Natural Language Generation

²Ragas Evaluation Guide

³Evaluating Evaluation Metrics — The Mirage of Hallucination Detection

⁴SelfCheckGPT: Zero-Resource Black-Box Hallucination Detection for Generative LLMs

⁵Chain-of-Verification Reduces Hallucination in Large Language Models