[AI W3] Reader(LLM) 프롬프트 설계와 Hallucination을 다루는 방법

 

 

[AI] LLM 학습 노트 공개 - Transformer부터 RAG까지, 그리고 운영 가능한 AI 시스템을 향해

 

ㅁ 들어가며

RAG를 처음 붙였을 때 가장 쉽게 드는 생각은 이거다.

“문서는 잘 검색되는데, 왜 답변은 여전히 애매할까?”

Retriever도 튜닝했고, Ranker도 붙였고, 모델도 바꿔봤다.

그런데도 답변 품질은 기대만큼 올라가지 않는다.

이 지점에서 많은 사람이 LLM 성능을 의심한다.

 

하지만 실제로 문제의 원인은 대부분 Reader 단계,
 정확히 말하면 프롬프트와 컨텍스트 구성에 있다.

 

이번 글에서는
  RAG의 마지막 단계인 Reader를 단순한 “모델 호출”이 아니라
  품질을 결정하는 최종 시스템 레이어로 바라보며,
  프롬프트 설계와 Hallucination 문제를 어떻게 다뤄야 하는지 정리해본다.

 

ㅁ Reader는 왜 중요한가

RAG 파이프라인을 한 줄로 요약하면 이렇다.

 

  Retriever → Ranker → Reader

 

앞단에서 아무리 좋은 문서를 가져와도
  Reader가 그 문서를 제대로 읽지 못하면
  RAG의 가치는 사라진다.

 

Reader의 역할은 단순하다.

  주어진 컨텍스트를 바탕으로 답변을 생성하는 것.

하지만 이 단순한 역할 때문에 오히려 가장 많은 책임을 떠안는다.

문서가 많으면 많다고 문제고,
문서가 적으면 적다고 문제고,
문서가 애매하면 Hallucination이 발생한다.

 

그래서 Reader는
  “LLM을 잘 고르는 문제”가 아니라
   LLM이 사고할 수 있는 범위를 어떻게 제한할 것인가의 문제다.

 

 

ㅁ 프롬프트 설계의 본질

RAG에서 프롬프트 설계는 말을 예쁘게 쓰는 작업이 아니다.

프롬프트는 Reader에게 다음을 명확히 정의한다.

  어떤 문서만 신뢰해야 하는지
  문서에 없을 때 어떻게 행동해야 하는지
  추론을 어디까지 허용하는지

 

즉, 프롬프트는
  지식의 경계를 설정하는 제어 장치다.

 

그래서 RAG용 프롬프트에는 반드시 포함되어야 할 메시지가 있다.

제공된 문서만 사용한다
문서에 없는 내용은 답하지 않는다
모르면 모른다고 말한다

 

이 세 가지가 빠진 프롬프트에서
Hallucination은 구조적으로 발생할 수밖에 없다.

 

 

ㅁ Hallucination은 왜 생기는가

Hallucination은 흔히
  “모델이 틀린 답을 만든다”라고 설명된다.

 

하지만 RAG 환경에서의 Hallucination은
  대부분 모델 문제가 아니다.

원인은 훨씬 단순하다.

  Reader가 참조 가능한 지식의 범위를 모른다
  답할 수 없는 상황에 대한 규칙이 없다

 

이 상태에서 LLM은 침묵하는 대신 추론을 선택한다.

그래서 Hallucination은 모델 결함이 아니라
   컨텍스트 경계가 흐릿할 때 발생하는 정상 동작에 가깝다.

 

 

ㅁ Lost in the Middle 문제

Reader를 다룰 때 반드시 고려해야 할 특성이 있다.

LLM은
컨텍스트의 처음과 끝에 있는 정보를
중간보다 더 잘 활용한다.

 

문서가 길어질수록 가장 중요한 정보가 중간에 묻히는 문제가 발생한다.

이게 바로 Lost in the Middle 현상이다.

 

그래서 RAG에서는 무조건 많은 문서를 넣는 것이 정답이 아니다.

정말 중요한 문서만 남기고

  문서 수를 Top-3~5 수준으로 제한하고

  필요하면 요약해서 전달한다

Reader에게 중요한 건
  문서의 “양”이 아니라
  집중할 수 있는 구조다.

 

 

ㅁ Context Window는 자원이 아니라 제약이다

Context Window가 커졌다고 해서
  문제를 마음대로 밀어 넣을 수 있는 건 아니다.

 

오히려 컨텍스트가 길어질수록
  토큰 비용은 증가하고
  핵심 정보 활용률은 떨어진다.

그래서 Reader 단계에서는 항상 토큰 예산을 기준으로 생각해야 한다.

시스템 프롬프트
사용자 질의
문서 컨텍스트
답변 여유

 

이 네 가지가 하나의 고정된 예산 안에서 경쟁한다.

결국 Reader 튜닝이란

  정보를 얼마나 줄일 수 있는가의 싸움이 된다.

 

 

ㅁ Reader는 생각보다 단순하다

많은 RAG 실패 사례를 보면 LLM에게 너무 많은 걸 기대하고 있다.

하지만 Reader는 의미를 “판단”하는 주체가 아니다.

판단은 Retriever와 Ranker에서 끝나야 하고
  Reader는 그 결과를 언어로 표현할 뿐이다.

컨텍스트가 정확하면
  모델은 생각보다 안정적으로 답한다.

반대로 컨텍스트가 흔들리면
  어떤 모델을 써도 결과는 흔들린다.

그래서 Hallucination을 줄이는 가장 확실한 방법은
  모델을 바꾸는 게 아니라
Reader 앞단을 정제하는 것이다.

 

ㅁ 핵심 개념 한 줄 정의

개념	정의
Reader	검색된 문서를 기반으로 답변을 생성하는 LLM
Context Window	LLM이 한 번에 처리할 수 있는 최대 토큰 수
Grounding	답변을 검색된 문서에 근거하도록 하는 기법
Citation	답변에 출처 문서를 명시하는 것
Hallucination	LLM이 문서에 없는 내용을 지어내는 현상
Lost in the Middle	긴 컨텍스트 중간에 있는 정보를 잘 활용하지 못하는 현상

 

ㅁ 마무리 – Reader를 시스템으로 바라본다는 것

Reader를 이해한다는 것은 프롬프트 템플릿을 외운다는 뜻이 아니다.

어디까지를 지식으로 인정할 것인가
언제 답변을 포기할 것인가
문서를 어떻게 배치할 것인가

 

이 결정들을 시스템 레벨에서 설계하는 것이다.

 

RAG에서 좋은 답변은 LLM이 만들어내는 게 아니다.

  좋은 답변은
  잘 정의된 컨텍스트와
  명확한 사고 경계에서 나온다.

 

Reader는 그 경계를 지키는 마지막 관문이다.