RAG (Retrieval Augmented Generation)

외부 지식 검색을 통해 LLM의 환각을 줄이고 정확도를 높이는 기법. 파라메트릭 메모리(모델)와 비파라메트릭 메모리(검색 DB)를 조합.

설명

RAG의 4단계

RAG는 다음 순차 흐름으로 작동한다:

1단계: Ingestion (자료 준비)

• 문서 → 의미 있는 청크로 분할
• 각 청크 → 벡터 임베딩으로 변환
• 벡터 + 메타데이터 → 벡터 DB에 저장

청킹 전략의 선택:

• 고정크기: 256-512 토큰. 구현 간단, 의미 경계 무시 위험
• 의미기반: 문단 경계 보존. 계산 비용 높음
• 구조기반: Markdown, HTML 구조 활용. 형식 의존성 높음

⚠️ 너무 작은 청크(50토큰): 맥락 손실 → 검색 정확도 ↓ ⚠️ 너무 큰 청크(2000토큰): 노이즈 증가 → 요구 정보 매몰

2단계: Retrieval (검색)

사용자 질문 → 벡터 임베딩 → 유사도 검색 → 상위 K개 문서 반환

검색 방식:

• Semantic (의미): 벡터 유사도. 의미 포착 강함, 아크로님 약함
• Lexical (키워드): BM25. 정확한 용어 포착, 의미 이해 약함
• Hybrid (하이브리드): 의미 + 키워드 조합. 가장 권장 (도메인 특화 쿼리에 강함)

3단계: Augmentation (프롬프트 확장)

검색된 문서 + 원래 질문 → LLM 입력으로 구성

Context: [검색된 문서 1] ... [검색된 문서 K]
Question: [사용자 질문]
Instruction: "다음 컨텍스트만 사용해 답하세요. 답이 없으면 '모른다'고 하세요."

4단계: Generation (응답 생성)

LLM이 augmented prompt를 읽고 최종 답변 생성

RAG의 핵심 원리: 이중 메모리

Parametric Memory (파라메트릭)

• 모델의 가중치에 암묵적으로 저장된 지식
• 강점: 일반적·문맥적 이해, 추론 가능
• 약점: Knowledge cutoff, 최신 정보 불가

Non-parametric Memory (비파라메트릭)

• 벡터 DB의 명시적 문서 저장소
• 강점: 항상 최신, 정확한 정보, 갱신 용이
• 약점: 단순 유사도 계산, 추론 어려움

시너지: 파라메트릭(이해) + 비파라메트릭(정보) = 정확한 추론 가능

RAG의 장점

1. Factual Consistency (사실 일관성)

답변이 검색 문서 기반이므로 거짓 주장이 어렵다.

효과:

• Hallucination 30-50% 감소
• 근거 명시 가능 (“이 정보는 문서 X에서…”)
• 사용자 신뢰도 ↑

2. Knowledge Cutoff 극복

DB만 갱신하면 최신 정보 즉시 반영.

효과:

• 2024년 이후 뉴스, 정책 변경 즉시 대응
• 모델 재학습 불필요 (비용 절감)

3. Domain-Specific Knowledge

비공개·특화 문서를 DB에만 저장하면, 모델 재학습 없이 맥락화 가능.

효과:

• 회사 내부 절차, 제품 스펙 학습 가능
• 비공개 데이터 보안 유지 (검색 결과만 모델에 전달)

RAG의 한계와 개선

문제 1: 청킹 역설 (Chunking Paradox)

• 작은 청크: 의미 손실, 검색 정확도 ↓
• 큰 청크: 노이즈 증가, 마찬가지로 정확도 ↓

해결책:

• Ragas의 context_recall 메트릭으로 청크 크기 튜닝
• Semantic 청킹으로 의미 경계 보존

문제 2: Lost-in-the-Middle

• 검색 결과 K개 중 맨 처음과 끝이 모델에 더 영향력
• 중간 정보는 무시될 가능성

해결책:

• 검색 결과 재정렬 (reranking)
• 중요도 가중치 부여

문제 3: 단일 검색의 한계

복잡한 질문(다중 단계 추론)은 한 번의 검색으로 부족.

해결책: agentic-ai-patterns의 Tool Use 패턴

• 에이전트가 반복적으로 쿼리 재구성
• 다단계 검색 → 정보 통합

실전 평가

RAG의 품질을 측정하는 방법:

Ragas 메트릭

메트릭	측정 대상	계산 방식
Context Recall	검색 완전성	”필요한 정보가 모두 검색되었는가?”
Context Precision	검색 정확도	”검색된 정보가 모두 관련 있는가?”
Faithfulness	생성 정확성	”답변이 검색 문서와 일치하는가?”
Answer Relevancy	생성 관련성	”답변이 질문에 응답하는가?”

성능 벤치마크

벤치마크	성능	개선점
Natural Questions	64.2% EM	기존 모델 +15-20%
WebQuestions	72% F1	정확성·구체성↑

RAG vs Full-context Loading — 규모에 따른 선택

소규모 에이전트 운영 파일(~10개)에서는 RAG보다 Full-context Loading(파일 전체를 컨텍스트에 직접 로딩)이 더 적합할 수 있다. (출처: bbojjak-openclaw-memory-architecture-lesson08)

기준	RAG	Full-context Loading
적합 규모	수백~수천 개 문서	~10개 파일 수준
검색 누락 위험	있음 (유사도 검색 오류)	없음 (전체 포함)
구축 복잡도	벡터 DB + 임베딩 필요	없음
비용 최적화	검색 인프라 비용	Prompt Caching으로 완화

실전 적용 기준: 에이전트 정체성·규칙·도구 파일이 6~10개라면 RAG 불필요. 수천 페이지 기업 지식 베이스라면 RAG 필요.

관련 개념: agent-memory-architecture — Full-context Loading + Prompt Caching + 기억 3단계 통합 설계

관련 개념

• agent-memory-architecture — 에이전트 기억 아키텍처; Full-context Loading vs RAG 선택 기준
• agentic-ai-patterns — Tool Use 패턴으로 RAG 확장 (에이전티 RAG)
• llm-hallucination — RAG가 완화하려는 대표적 생성 오류
• knowledge-graph-ontology-engineering — 정확한 구조화 지식이 필요한 도메인
• llmops-lifecycle-and-stack — RAG의 평가·모니터링 통합

실전 적용

• langchain — LangChain으로 RAG 구현
• pinecone — 벡터 DB로 검색 엔진 구축
• ragas — RAG 평가 자동화

소스

• rag-prompt-engineering
• pinecone-rag-implementation