LLM은 학습 데이터의 지식만 안다. 2023년까지 학습된 모델은 2024년 이후 사건을 모른다. 사내 문서, 고객 데이터, 특정 도메인 지식도 없다. 그리고 알고 있는 것도 틀리게 말하는 환각(hallucination)이 있다.

RAG(Retrieval-Augmented Generation)는 이 한계를 우회한다. 모델을 재학습하지 않고, 답변 생성 시 관련 문서를 검색해 컨텍스트로 넣어준다.

기본 파이프라인

두 단계로 나뉜다.

인덱싱 (오프라인)

문서 수집
  ↓ 청킹 (077)
텍스트 조각들
  ↓ 임베딩 모델
벡터들
  ↓
벡터 DB 저장

검색 + 생성 (온라인)

사용자 쿼리
  ↓ 임베딩 모델
쿼리 벡터
  ↓ 벡터 DB 유사도 검색
관련 청크 (top-k)
  ↓ 프롬프트에 삽입
[컨텍스트] + [쿼리] → LLM → 답변

프롬프트 구성

검색된 청크를 LLM에 전달하는 프롬프트다.

다음 컨텍스트를 기반으로 질문에 답하세요.
컨텍스트에 없는 내용은 모른다고 답하세요.

컨텍스트:
---
{chunk_1}
---
{chunk_2}
---
{chunk_3}

질문: {user_query}
답변:

“컨텍스트에 없으면 모른다고 답하라"는 지시가 환각을 줄이는 핵심이다. LLM이 검색 결과 외부의 정보를 임의로 생성하지 않도록 제약한다.

Naive RAG의 실패 패턴

기본 RAG는 여러 상황에서 실패한다.

청크 경계 문제: 답이 두 청크에 걸쳐 있으면 하나의 청크만 검색돼 답이 불완전하다.

쿼리-문서 표현 불일치: 사용자는 “k8s에서 Pod을 자동으로 늘리는 방법"이라고 묻지만 문서는 “HPA를 통한 수평적 자동 확장"이라고 쓰여있다. 벡터 유사도가 낮을 수 있다.

다중 쿼리 필요: “A와 B의 차이"를 묻는 쿼리는 A에 대한 청크와 B에 대한 청크를 각각 가져와야 한다.

노이즈 청크: top-k에 관련 없는 청크가 섞이면 LLM이 혼란을 겪어 답이 나빠진다.

개선 기법

HyDE (Hypothetical Document Embedding)

쿼리로 직접 검색하지 않고, LLM이 쿼리에 대한 가상 답변을 생성하고 그 답변으로 검색한다.

쿼리: "HPA는 어떻게 작동하나?"
  ↓ LLM
가상 답변: "HPA는 메트릭 서버에서 CPU 사용률을 수집하고..."
  ↓ 임베딩
가상 답변 벡터 → 벡터 DB 검색

쿼리보다 답변 형태의 텍스트가 실제 문서와 더 유사한 벡터를 갖는 경우가 많아 검색 품질이 올라간다.

Multi-Query

하나의 쿼리를 LLM이 여러 표현으로 변환해 각각 검색하고 결과를 합친다.

원본: "k8s 오토스케일링 방법"
  ↓ LLM 변환
쿼리 1: "쿠버네티스 자동 확장 설정"
쿼리 2: "HPA ScaledObject 구성"
쿼리 3: "Pod 수 자동 조정 방법"
  ↓ 각각 검색 후 중복 제거

Contextual Compression

검색된 청크 전체를 LLM에 넣지 않고, 쿼리와 관련된 부분만 추출한다. 컨텍스트 윈도우를 효율적으로 사용한다.

RAPTOR

문서들을 요약해 계층적 트리를 만든다. 잎 노드가 원본 청크, 상위 노드가 요약이다. 세부 질문에는 원본 청크를, 전체를 아우르는 질문에는 상위 요약 노드를 검색한다.

평가

RAG의 품질을 수치로 측정하는 것이 중요하다.

RAGAS 프레임워크의 주요 지표:

  • Faithfulness: 답변이 컨텍스트에 기반하는가 (환각 측정)
  • Answer Relevancy: 답변이 질문에 관련 있는가
  • Context Precision: 검색된 청크 중 실제 관련 있는 비율
  • Context Recall: 관련 청크가 모두 검색됐는가
from ragas import evaluate
from ragas.metrics import faithfulness, answer_relevancy

results = evaluate(
    dataset=eval_dataset,
    metrics=[faithfulness, answer_relevancy],
)

파인튜닝 vs RAG

도메인 지식을 활용하는 두 가지 방법이다.

파인튜닝이 유리한 경우: 스타일, 형식, 특정 도메인 언어 패턴을 바꾸고 싶을 때. 고정된 지식을 빠르게 조회해야 할 때.

RAG가 유리한 경우: 지식이 자주 업데이트되는 경우. 답변의 출처를 추적해야 하는 경우. 수백만 건 이상의 방대한 지식베이스. 파인튜닝 비용이 없다.

실무에서는 파인튜닝으로 모델의 응답 스타일을 맞추고, RAG로 최신 지식을 주입하는 조합이 많다.

트레이드오프

RAG의 한계는 컨텍스트 윈도우다. 검색된 청크가 많아질수록 LLM 입력 토큰이 늘어나 비용과 지연이 증가한다. 또한 LLM이 긴 컨텍스트에서 중간 부분을 상대적으로 덜 활용하는 “Lost in the Middle” 문제가 있다. 중요한 정보를 컨텍스트의 앞이나 뒤에 배치하는 것이 효과적이다.

검색 실패가 생성 실패로 이어진다. 관련 청크를 찾지 못하면 LLM이 정직하게 모른다고 답하거나 환각을 생성한다. 검색 품질이 전체 시스템의 병목이다.