사내 문서나 제품 매뉴얼을 LLM에게 물어보고 싶은데, "모릅니다"라고 답하거나, 그럴듯하지만 틀린 답변이 돌아온다——이러한 경험을 통해 RAG (Retrieval Augmented Generation)라는 용어를 접하는 사람이 많다.

이 기사는, 왜 LLM 단체로는 부족한지, RAG가 무엇을 해결하는지를 초보자용으로 정리한다.

RAG가 필요해지는 이유를 이해하려면, 먼저 LLM 단체의 한계를 파악해야 한다.

LLM은 사전 학습 시점까지의 공개 텍스트로 학습한다.

학습 완료 후에 출시된 제품 사양, 사내 규정, 어제의 뉴스는 모델의 가중치(Weights) 안에 존재하지 않는다.

예: 2024년에 학습을 완료한 모델
→ 2025년에 출시된 API 사양은 모름
→ "아마 이럴 것이다"라고 추측으로 답변함 (할루시네이션 (Hallucination))

사내 Wiki, 고객 데이터베이스, 미공개 설계서는 사전 학습 데이터에 포함되지 않는다.

프롬프트에 전문을 붙여넣으면 일시적으로 참조할 수 있지만, 컨텍스트 윈도우 (Context Window)의 상한이 있어 대규모 문서군은 통째로 전달할 수 없다.

LLM은 "다음에 올 것 같은 토큰 (Token)"을 예측하도록 설계되었기 때문에, 모르는 질문에 대해서도 그럴듯한 (plausible) 답변을 생성하기 쉽다.

"모릅니다"라고 대답하는 것보다, 그럴듯한 추측을 반환하는 것이 학습상 보상받는 패턴이 되어 있다.

프롬프트에 대량의 텍스트를 직접 매립하면 입력 토큰 수가 늘어나, API 비용과 응답 시간이 비례해서 증가한다.

수천 페이지의 매뉴얼을 매번 전부 보내는 것은 현실적이지 않다.

RAG (Retrieability Augmented Generation)는, 답변을 생성하기 전에 관련 문서를 검색하여 LLM에 전달하는 아키텍처다.

2020년에 Meta AI (당시 Facebook AI)의 연구자가 제창한 수법으로, 현재 엔터프라이즈용 AI 앱의 표준 패턴이 되어 있다.

기본적인 흐름은 다음 4단계다.

[1. 인덱스 구축]
문서를 분할 (청크 (Chunk)) → 임베딩 (Embedding) 벡터화 → 벡터 DB에 저장
[2. 검색 (Retrieval)]
...

원문: "RAG combines the parametric memory of a pre-trained seq2seq model with a non-parametric memory"

일본어 번역: 「RAG는 사전 학습된 모델의 파라메트릭 메모리 (Parametric Memory)와 비파라메트릭 메모리 (Non-parametric Memory)를 결합한다」 (출처: Lewis et al., 2020)

포인트는, 지식을 모델의 가중치에 구워 넣지 않고, 외부 스토어에서 동적으로 취득한다는 점이다.

문서를 업데이트하면 모델을 재학습하지 않아도 답변에 반영할 수 있다.

RAG 파이프라인을 구성하는 주요 컴포넌트는 다음과 같다.

┌─────────────────────────────────────────────────┐
│ 문서 소스 │
│ (PDF, Markdown, Web 페이지, DB 등) │
...

각 컴포넌트의 역할을 한마디로 요약한다.

• 대상 문서를 특정했는가 — 무엇을 검색 대상으로 할 것인가 (PDF, Wiki, DB 등)
• 청크 사이즈 (Chunk size)를 결정했는가 — 일반적으로 500~1000 토큰 정도부터 시도
• 임베딩 모델 (Embedding model)을 선택했는가 — OpenAI text-embedding-3-small, Cohere, 로컬 모델 등
• 벡터 DB (Vector DB)를 선택했는가 — 규모, 운용 비용, 기존 인프라와의 정합성
• 프롬프트 (Prompt)에 "컨텍스트 외의 내용은 답하지 마라"는 지시를 넣었는가 — 할루시네이션 (Hallucination) 억제
• 출처 (참조 청크)를 답변에 포함하도록 설계했는가 — 검증 가능성 확보
• 인덱스 업데이트 운용 플로우를 결정했는가 — 문서 추가/변경 시의 재인덱싱 (Re-indexing)
• 평가용 질문 세트를 준비했는가 — 정밀도 개선을 위한 베이스라인

패턴 1: RAG를 도입했는데 정밀도가 올라가지 않는다

→ 대책: 청크 사이즈, 임베딩 모델, 검색 결과 개수 (top-k)를 조정한다. 검색 결과가 질문과 무관하다면 청킹 (Chunking) 전략을 재검토한다.

패턴 2: 검색 결과를 무시하고 LLM이 추측으로 답변한다

→ 대책: 프롬프트에 "제공된 컨텍스트에 없는 정보는 '모릅니다'라고 답하라"고 명시한다. 온도 (Temperature)를 낮춘다.

패턴 3: 인덱스를 업데이트하지 않는다

→ 대책: 문서 업데이트 시의 재인덱싱 절차를 자동화한다. 오래된 정보가 남아 있으면 오답의 원인이 된다.

패턴 4: 모든 것을 RAG에 담으려고 한다

→ 대책: 검색 대상을 좁힌다. FAQ, 매뉴얼, 규정 등 "답이 문서 안에 있는" 것에 한정한다.

패턴 5: RAG의 정밀도 평가를 하지 않는다

→ 대책: 대표적인 질문 10~20건과 정답을 준비하여, 검색 정밀도와 답변 정밀도를 정기적으로 측정한다.

• LLM 단독으로는 **학습 컷오프 (Learning cutoff), 비공개 데이터, 할루시네이션 (Hallucination), 컨텍스트 상한 (Context limit)**이라는 4가지 한계가 있다.

• RAG는 답변 전 관련 문서를 검색하여 LLM에 전달함으로써 이러한 한계를 완화한다.

• "답이 특정 문서군 안에 있는" 유스케이스 (Use case)에서는 RAG가 유효하다. 일반적인 언어 처리는 LLM 단독으로도 충분한 경우가 있다.

• 구현 시에는 청킹 (Chunking), 임베딩 (Embedding), 검색 (Retrieval), 프롬프트 설계 (Prompt design), 평가 (Evaluation)의 5가지를 세트로 생각해야 한다.

• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (Lewis et al., 2020)

• What is RAG? (IBM)

• Retrieval augmented generation (AWS)

• Build a RAG agent with LangChain (LangChain Docs)

• Prompt engineering (OpenAI Docs)