RAG 기초

분류: Layer 12 - AI 시스템 & LLM 애플리케이션 | 선수지식: L12-10 (LLM API), L12-20 (Prompt), L12-30 (임베딩·벡터)

RAG 기초 — Retrieval, Augmentation, Generation

1. 한 줄 정의

RAG (Retrieval-Augmented Generation)는 외부 지식을 검색해 LLM context에 주입한 뒤 답변 생성하는 패턴이며, fine-tuning 없이 자주 갱신되는 지식·출처 인용·환각 감소를 동시에 해결한다.

2. 왜 중요한가

선행 기술의 한계 — RAG가 등장한 이유

L12-10 (LLM API) 단계에서 본 parametric LLM(지식이 모델 가중치에 박혀 있는 형태)에는 세 가지 구조적 한계가 있다. Lewis et al. (NeurIPS 2020)이 RAG를 제안한 동기가 정확히 이 셋이다.

1. 지식 갱신 비용: fine-tuning으로 신규 지식을 주입하려면 초기 셋업만 $2,400~$18,000 + 문서 갱신마다 $500~$5,000이 다시 든다. 매일·매주 갱신되는 정책·FAQ·가격표는 fine-tune 사이클이 따라잡지 못한다 (pecollective, 2026 cost guide).
2. 출처 불가: 가중치에서 합성된 답은 “어느 문서·문단의 어느 줄에 근거했는가”를 되짚을 수 없다. 의료·법률·금융은 답변마다 인용이 강제되므로 parametric만으로는 운영 불가 (Lewis et al. 2020 abstract — “providing provenance for their decisions”).
3. 환각: 학습 분포 밖 질문에서도 LLM은 그럴듯한 거짓을 생성한다. 단순 in-context 프롬프팅(긴 문서를 그대로 넣기)도 §3.5에서 보듯 lost-in-the-middle로 깨진다.

RAG의 해결 메커니즘: 외부 KV store(벡터+BM25)에 진실을 두고, 쿼리마다 top-K를 검색해 prompt에 주입한 뒤 “documents 밖은 모른다”고 제약한다. 그 결과 (a) 문서 1개 교체로 즉시 갱신, (b) chunk ID를 답변에 인용해 provenance 확보, (c) 적절히 구성하면 hallucination을 RAG 없는 baseline 대비 최대 71%까지 감소 (premai blog, RAG eval 2026).

이 토픽이 사라지면 무엇이 깨지는가: 자주 갱신되는 사내 지식을 LLM에 태우는 모든 흐름이 끊긴다. 대안은 매주 fine-tune을 다시 돌리는 것뿐인데 비용 자릿수가 1~3배 다르다.

RAG가 가져온 운영적 가치

• fine-tuning의 대안: 비용 자릿수가 다르고, 갱신·롤백이 쉬움 (RAG: 호출당 ~$0.003 / fine-tune: ~$0.015, pecollective)
• 출처 인용 가능: 검증·신뢰성 (의료·법률·금융 필수)
• 환각 감소: 검색된 문서에 근거를 두면 사실 오류 줄어듦 (단, faithfulness ≥0.8 강제 필요 — §3.9)
• 2025+ 표준: production 배포의 약 60%가 RAG + fine-tune 혼용 (pecollective)
• 운영 난이도: chunking·hybrid·reranker·갱신·평가 모두 신경써야

3. 핵심 개념

3.1 Naive RAG 파이프라인

[색인 단계 — offline]
1. 문서 수집 (PDF, web, DB, 코드 등)
2. Chunking (L12-30 §3.3)
3. Embedding (text-embedding-3, BGE-M3, voyage-3 등)
4. Vector store에 색인 (HNSW 등)

[검색·생성 단계 — online]
5. 사용자 query 받음
6. Query embedding
7. Vector store에서 top-K (보통 10~20) 검색
8. Prompt에 검색 결과 주입
9. LLM 호출 → 답변 생성

Naive RAG 운영 흐름

flowchart TD
A["문서 수집"] --> B["Chunking"]
B --> C["Embedding"]
C --> D["Vector store 색인"]
E["사용자 query"] --> F["Query embedding"]
F --> G["Top-K retrieval"]
D --> G
G --> H["Prompt에 context 주입"]
H --> I["LLM generation"]
I --> J{"근거와 citation 충분?"}
J -->|yes| K["답변 반환"]
J -->|no| L["재검색 또는 모른다고 답변"]

RAG는 검색과 생성 사이에 faithfulness gate를 두지 않으면, 인용 형식만 갖춘 환각으로 조용히 실패한다.

이게 가장 단순한 형태. production에서는 거의 항상 부족 — 다음 절들의 개선이 누적된다.

3.2 Query Transformation

사용자 query를 그대로 검색하지 말고 변형해서 검색.

Query Rewriting

원본: "RAG 어떻게 해?"
변형: "Retrieval-Augmented Generation 구현 방법, vector store 선택, chunking 전략"

• LLM에 query 다시 쓰기 의뢰. 키워드 보강
• chat 후속 질문은 이전 turn의 정보를 query에 합쳐야 (e.g. “그럼 비용은?” → “RAG의 비용은?”)

Multi-Query

같은 의도로 N개 변형 → 각각 검색 → 합집합.

원본: "Python에서 비동기 처리"
변형 1: "Python asyncio 사용법"
변형 2: "Python async/await 예제"
변형 3: "Python 동시성 코루틴"

HyDE (Hypothetical Document Embeddings)

LLM에 가상 답변을 먼저 생성시키고, 그 답변을 임베딩해 검색.

1. "RAG 어떻게 해?" → LLM이 가상 답변 생성
2. 가상 답변을 임베딩
3. 그 vector로 검색

query보다 답변이 문서와 의미적으로 더 가까워 검색 품질 ↑ (Gao et al. 2022).

Query Decomposition

복잡한 질문을 sub-question으로 분해.

원본: "RAG와 fine-tune의 비용 차이는?"
분해:
  1. RAG의 비용 모델
  2. fine-tune의 비용 모델
→ 각각 검색·답변 후 결합

3.3 Retrieval 전략

L12-30의 인프라 위에서.

• Semantic: dense embedding (기본)
• Hybrid: BM25 + dense + RRF (한국어·고유명사·코드)
• Multi-vector / ColBERT: token별 정확도 ↑
• Knowledge graph: 엔티티 관계 그래프 (GraphRAG)
• Parent-Child / Hierarchical: chunk를 작게 검색하되 더 큰 parent context 반환
• Auto-merging: 검색된 chunk들이 같은 parent면 합쳐서 반환

3.4 Re-ranking

검색 후 cross-encoder reranker로 top-10 정렬 (L12-30 §3.5). RAG 품질에서 가장 큰 ROI.

3.5 Augmentation — Context 주입

검색 결과를 prompt에 넣는 방식.

XML / structured 권장

<documents>
  <doc id="1" source="/manual.pdf">{content_1}</doc>
  <doc id="2" source="/faq.md">{content_2}</doc>
</documents>

<question>{user_query}</question>

<instruction>
위 documents에 근거해 답하라.
- 출처는 [doc_1] 형식으로 인용
- documents에 없는 정보는 추측하지 말고 "모릅니다"
- 한국어로
</instruction>

Prompt 위치

연구 결과 (Liu et al. 2023, “Lost in the Middle”): 앞 또는 끝 정보가 가장 잘 활용됨. 중간 정보는 무시되기 쉬움.

운영 권장: 검색 결과는 prompt 끝쪽 또는 시스템 직후 앞쪽에. 가장 중요한 doc부터.

Context length 관리

• 검색 결과 + system + user → context 한도 안에 맞춰야
• 너무 많은 doc은 lost-in-middle. K=5~10이 보통 sweet spot
• summarization으로 압축 (Long context 모델은 1M까지 들어가지만 비용·품질 trade-off)

3.6 Generation 전략

Faithfulness 강제

• prompt에 “documents에 없는 정보는 답하지 말라”
• structured output으로 citation 강제
• LLM-as-judge로 faithfulness 회귀 검증 (Ragas)

Citation

"asyncio는 Python 3.4부터 표준 라이브러리에 포함되었습니다. [doc_1]
async/await 키워드는 Python 3.5부터 사용 가능합니다. [doc_2]"

• 사용자에게 출처 링크 제공
• 답변의 신뢰성 ↑

Answer Refinement

검색 부족하다고 판단되면:

• 추가 검색 (multi-hop)
• “관련 정보를 찾을 수 없습니다” (refusal) — 환각 방지

3.7 Advanced RAG 패턴

Self-RAG

LLM이 검색 필요 여부를 스스로 판단 → 검색 → 자기 평가 → 답변.

CRAG (Corrective RAG)

검색 결과의 신뢰도를 평가, 부족하면 web search로 보완.

GraphRAG (Microsoft 2024)

문서를 entity·관계 그래프로 변환 → community detection → 글로벌 question에 강함.

"이 회사의 전체 전략은?" 같은 글로벌 질문에 single-document 검색은 부족
→ entity 그래프로 community summary 생성 → 그것을 검색

Agentic RAG

검색을 단발이 아닌 agent가 도구처럼 호출 (L12-60). 부족하면 다른 검색·tool 호출.

LightRAG / RAPTOR

document hierarchy를 미리 만들어 효율적 검색.

운영 관점의 RAG architecture variants

RAG 아키텍처 이름은 많지만, 운영자가 봐야 할 축은 검색 품질을 어디에서 올리는가, 비용을 어디까지 감수하는가, 실패 시 어떻게 멈추는가다.

변형	핵심 구조	적합한 상황	운영 리스크
Naive RAG	query embedding → top-K → prompt	PoC, 작은 FAQ, 명확한 단일 문서 질문	query mismatch, reranker 부재, stale data
Advanced RAG	rewrite·hybrid·rerank·parent-child 추가	production QA 대부분	stage 증가로 latency·trace 복잡도 증가
Modular RAG	retriever, reranker, generator를 독립 교체	팀·도메인별 검색 전략이 다른 플랫폼	인터페이스 계약 없으면 회귀 원인 추적 어려움
Corrective / Self-RAG	검색 결과를 평가하고 재검색·refusal 수행	검색 실패가 사용자 피해로 이어지는 도메인	LLM judge 비용, loop 폭주, 불안정한 latency
GraphRAG	chunk 대신 entity·relation·community 검색	”전체 전략”, “조직 간 관계” 같은 글로벌 질문	색인 비용 큼, entity 추출 품질에 강하게 의존
Agentic RAG	agent가 검색·DB·도구를 여러 번 호출	multi-hop, 업무 자동화, 조건부 action	permission, tool call budget, 재현성 관리

운영 기본값은 Advanced RAG다. naive로 시작하더라도 최소한 query rewriting → hybrid → rerank → citation/faithfulness gate 순으로 보강해야 production baseline이 된다. GraphRAG와 Self-RAG는 “멋있어서”가 아니라 아래 트리거가 있을 때만 올린다.

• GraphRAG 트리거: 정답이 단일 chunk에 없고, 여러 문서의 entity 관계·community summary를 합쳐야 할 때
• Corrective/Self-RAG 트리거: 검색 결과 신뢰도 점수가 낮을 때 refusal 또는 web/manual fallback이 필요한 도메인
• Modular RAG 트리거: 같은 서비스 안에서 HR·법무·코드검색처럼 retriever와 filter 정책이 다를 때
• Agentic RAG 트리거: 검색 후 DB 조회·ticket 생성·권한 확인 같은 tool action이 이어질 때

3.8 RAG vs Long-Context vs Fine-tune

LLM context가 1M+ 시대에 RAG가 여전히 필요한지는 “지식 갱신”, “출처 인용”, “호출당 비용”, “응답 형식 일관성”으로 나눠 판단한다.

RAG와 대안 선택 기준

RAG

외부 지식을 검색해 최신성, 출처 인용, 권한 필터를 운영 로직으로 통제한다.

문서가 자주 바뀌고 답변 근거를 사용자나 감사 로그에 남겨야 할 때

Long-context

한 번에 많은 자료를 prompt에 넣지만 prefill 비용과 lost-in-the-middle 위험이 커진다.

단발 분석이고 corpus가 context window 안에 들어갈 때

Fine-tune

지식을 매번 검색하기보다 모델 행동, 톤, 출력 형식을 가중치에 맞춘다.

지식 갱신은 느리지만 응답 형식과 도메인 행동을 일관되게 만들 때

결론: 자주 갱신·출처 필요 → RAG. 정형 도메인 행동 → fine-tune. 한 번에 넣을 수 있고 단발 작업 → long-context.

→ 셋을 결합한 hybrid 패턴이 production 표준이며 실제 2025~2026 배포의 약 60%가 RAG + fine-tune 혼용 (pecollective). RAG로 신선도·출처를, fine-tune으로 응답 형식·페르소나를 담당시킨다.

퀴즈

RAG를 붙였는데도 환각 답변이 계속 나오면 검색기부터 바꿔야 할까?

힌트: 검색 실패와 생성 실패는 복구 방법이 다르다.

정답 보기

먼저 trace에서 검색 chunk와 답변 문장을 대조해 retrieval 실패인지 generation faithfulness 실패인지 분리한다. 검색 결과가 맞는데 답변이 새 내용을 지어내면 prompt, citation, refusal, faithfulness gate를 먼저 고친다.

깨지는 조건 (RAG를 선택했을 때 손해 보는 경우)

• 갱신 빈도 < 분기 1회: 분기마다 한 번 정도만 바뀌는 정형 지식이면 fine-tune의 초기 비용이 회수된다. 매번 검색 latency 100ms+ 와 호출당 prompt 증가분이 누적 손해.
• 호출량이 매우 적음 (월 < ~10k): 호출당 비용은 RAG가 싸지만, 벡터 DB hosting·재색인 인프라 고정비($500~$2,000/월) 회수가 안 됨. 이 영역은 long-context가 유리.
• 답변이 매번 동일 톤·구조여야 함: persona·말투·JSON schema 일관성은 검색으로 못 박지 못한다. fine-tune이 본업.
• 검색 가능한 corpus가 없음: RAG는 “검색할 진실”이 전제. 코퍼스 정비 없이 도입하면 chunk 품질 0 → faithfulness 0.

코퍼스 갱신이 1년에 12회면 RAG의 갱신 우위가 사라지고, fine-tune의 호출당 단가 우위($0.0001~0.01)만 남는다는 점을 결정 표 위에 명시한다.

3.9 RAG 평가 (재방문)

L11-80 §3.13의 Ragas 4-지표를 RAG 시점으로:

• Faithfulness: 답변이 검색된 문서에 근거하는가 — production 게이트 ≥0.8, 의료·법률·금융 ≥0.9 (premai 2026). 0.6은 답변 문장의 ~40%가 검색 결과에 근거 없음.
• Answer Relevance: 답변이 질문에 답하는가
• Context Precision: 검색된 chunk 중 관련 비율
• Context Recall: 정답에 필요한 정보가 검색됐는가
• Aspect Critic, Noise Sensitivity, Multi-turn: Ragas 2025 추가

Ragas 자체의 깨지는 조건 (silent failure)

Ragas Faithfulness는 답변을 문장 단위로 분해한 뒤 검색 chunk와 대조하는데, 답변이 표·코드·짧은 어구 위주면 분해가 실패한다. FinanceBench(재무 답변 데이터셋) 평가에서 default Ragas Faithfulness는 샘플의 83.5%에서 점수를 산출하지 못함 (Data Science Collective, 2025). 답변 포맷이 표·숫자 위주인 도메인은 Ragas만 신뢰하지 말고 LLM-as-judge custom rubric 또는 cleanlab TLM 같은 독립 검출기를 병행한다.

Production Eval 흐름

1. Gold dataset (질문·정답·출처) 준비 — 100~500개
2. RAG 변경 시 자동 평가
3. 4-지표 dashboard
4. 회귀 케이스는 사람 검수
5. 사용자 피드백 (좋아요/싫어요) loop

3.10 RAG 운영 silent failure

• Stale data: 문서 갱신 후 임베딩 미갱신 (L12-30 §3.8)
• Permission leak: 권한 없는 문서가 검색에 노출 — 큰 위험
• Top-K 너무 큼: lost-in-middle, 비용↑
• Query mismatch: 사용자 질문 스타일 ≠ 문서 스타일 (HyDE·rewriting로 완화)
• Reranker 누락: 검색은 됐는데 정렬이 엉망
• Architecture overkill: 단일 FAQ에 GraphRAG·agentic loop를 붙여 색인 비용과 latency만 증가. 감지: multi-hop 질문 비율 <5%인데 평균 retrieval stage가 3개 이상
• Faithfulness 검증 누락 (가장 인지하기 어려운 silent failure): 환각 답변이 인용 형식까지 갖춰 정상 응답처럼 출력됨. 감지 절차:
  1. trace에서 최근 1000건 답변·검색 chunk 페어 추출 (langsmith export ...)
  2. ragas evaluate --metric faithfulness --dataset trace.jsonl 실행
  3. 결과 분포가 평균 0.85 → 0.6대로 떨어지면 회귀 의심
  4. drift 원인은 거의 항상 system prompt 변경 — git diff로 직전 prompt revision 비교
  5. 복구: prompt-version rollback(또는 동등) + Gold dataset에 부정 케이스 추가 + CI에 faithfulness < 0.8 fail 게이트 영구 추가
• Multi-language: 한국어 query에 영어 문서 검색 (또는 반대) — 다국어 임베딩 사용

3.11 깨지는 조건 정량 표 (운영 결정용)

기법	효과 발휘 범위	깨지는 조건
Naive RAG	prototype, 명확한 작업	production은 거의 항상 부족 — query transform 필요
HyDE	query≠문서 표현 多	query가 이미 문서와 유사 표현이면 비용↑·효과 X
Multi-Query (3~5)	recall 부족	top-K 합집합으로 noise↑ → reranker 필수
Decomposition	multi-hop·복합 질문	단순 질문엔 오버헤드
Top-K=5~7	lost-in-middle 회피	K=10+ → 중간 정보 무시 (Liu 2023)
Hybrid (BM25+dense)	일반 + 고유명사·법률·코드	순수 자연어 paraphrase는 dense만으로 충분
Reranker (top-100→10)	recall@10 +10~30%	latency budget <50ms 환경엔 부적합
Self-RAG	검색 필요 여부 동적 판단	overhead 多 → 단순 RAG로 충분한 경우
Corrective RAG	검색 실패 탐지·재검색	judge 품질 낮으면 false positive로 refusal 증가
GraphRAG	글로벌 question (전체 전략)	단일 문서 답변엔 비용 자릿수 증가
Modular RAG	retriever 교체·조합 쉬움	stage 계약·trace 없으면 장애 분석 어려움
Long-context (1M)	한 번에 모두 넣기	비용 1000× 이상 + lost-in-middle (RAG 우위)

3.12 RAG silent failure 정량 신호와 복구

증상	정량 신호	원인	복구
Permission leak	다른 tenant 답변에 정보 누출	metadata filter 누락	tenant_id 필수 filter, audit log
Stale data	검색 결과 옛 정보 (TTL >7일)	reindex 누락	CDC + 임베딩 큐, soft delete + cleanup
Hallucination 빈발	faithfulness <70%	검색 부족 또는 prompt 약함	”근거 없으면 모른다” 강제, citation 필수
Top-K 너무 큼	lost-in-middle 정확도 ↓	K>10	K=5~7로 축소, reranker 필수
Multi-language mismatch	한국어 query 영어 문서 검색 X	dense 모델이 단일 언어	다국어 임베딩(BGE-M3, voyage-3-large)
Reranker 누락	top-10 정확도 30%↓	bi-encoder만 사용	cross-encoder rerank 도입
Query mismatch	recall@10 < 50%	사용자 표현 ≠ 문서 표현	HyDE·Query rewriting

3.13 RAG vs 대안 정량 결정 신호

정량 비교는 위의 선택 카드에 운영 숫자를 붙여 확인한다. RAG는 검색+생성 호출당 대략 $0.001부터 시작하지만 검색 latency가 추가되고, 1M long-context는 $1~10 단위 prefill 비용과 lost-in-the-middle 위험이 붙는다. Fine-tune은 호출당 비용이 낮아질 수 있지만 재학습 비용과 출처 부재가 남는다.

3.14 RAG의 일반 매핑 (Transferable Pattern)

RAG = “외부 KV store + 프로세서”. 다른 시스템 패턴.

RAG 구성요소	일반 시스템 매핑
Retrieval	DB SELECT, search query, cache lookup
Augmentation (context 주입)	template rendering, dynamic config injection
Generation (답변)	response synthesis, materialized view
Faithfulness 강제	data validation, contract test
Citation	provenance tracking, audit trail
Multi-hop	DB join, dependency graph traversal
GraphRAG	knowledge graph DB, relation traversal
Self-RAG	adaptive query (cost-based optimizer)

일반 공식: “검색 + 컨텍스트 주입 + 합성”의 3단계가 데이터·코드·문서·검색 시스템 전반에 동일하게 나타난다.

운영 시나리오 — 사내 RAG 챗봇 silent failure 대응 (예시)

상황: 사내 정책 RAG 챗봇 운영 중. 사용자 부정 피드백 30%↑ 감지.
진단:
  1. Trace 분석: 검색 결과는 정확 (recall@10 0.85 유지)
  2. Faithfulness 점수 측정 (Ragas): 0.6 → 0.4 (폭락)
  3. 답변 분석: documents에 없는 정보 자주 답함
  → Faithfulness 회귀

원인 추적:
  - 시스템 prompt에서 "documents에 없으면 모른다" 문구 누락 (직전 prompt 변경 시 사고)

복구:
  1. 즉시 rollback (이전 prompt 버전)
  2. Gold dataset에 사용자 부정 피드백 케이스 50개 추가
  3. Faithfulness CI 게이트 추가 (Ragas 자동 평가)

대안 비선택:
  - LLM 변경 (회귀 원인 아니라 prompt) X
  - Top-K 변경 (검색은 정상) X

§3.5 augmentation + §3.6 faithfulness + §3.10 silent failure + §3.12 정량 신호 모두 적용.

4. 실무에서 어디에 쓰이나

• 사내 문서 챗봇 (HR, 정책, FAQ)
• 고객 지원 (제품 매뉴얼)
• 코드 어시스턴트 (사내 코드베이스 검색)
• 의료·법률 (출처 인용 필수)
• 뉴스 요약·검색
• agent의 knowledge layer

5. 현재 내 업무와 연결점

플랫폼 엔지니어가 RAG를 운영할 때 다음에 도움된다.

• 선택 결정: 자주 갱신되는 지식 = RAG, 형식·톤 = fine-tune, 단발·짧은 = long-context
• 품질 우선순위: chunking + hybrid + reranker가 가장 큰 ROI. 셋 다 적용
• 출처 인용 강제: 의료·법률·금융 도메인은 prompt에 citation 강제
• Permission 분리: 사용자별 검색 범위를 vector store metadata filter로 제한
• 회귀 검증: 문서 추가·prompt 변경마다 Ragas 4-지표 자동 평가
• 다국어: 한국어 query + 영어 문서 검색 시 query rewriting 또는 다국어 임베딩

6. 자주 헷갈리는 개념 비교

개념 A	개념 B	차이점
Naive RAG	Advanced RAG	단순 검색 vs query transform·rerank·self-RAG·multi-hop
Multi-Query	HyDE	query 변형 N개 vs 가상 답변 임베딩
Query Rewriting	Decomposition	키워드 보강 vs sub-question 분해
Semantic search	Hybrid search	dense만 vs dense + BM25
Bi-encoder	Cross-encoder rerank	빠른 1차 vs 정확한 2차
Faithfulness	Answer Relevance	문서에 근거 vs 질문에 답
Context Precision	Context Recall	검색된 것 중 관련 비율 vs 정답에 필요한 것이 검색됨
RAG	Long-context	외부 검색 vs 모두 prompt에
RAG	Fine-tune	검색 기반 지식 vs 가중치에 학습
GraphRAG	Vector RAG	entity·관계 그래프 vs 임베딩 vector

7. 체크리스트

RAG 운영 복습 체크리스트

• Naive RAG 파이프라인 9단계를 offline indexing과 online retrieval/generation으로 나눠 설명할 수 있다.
• Query rewriting, Multi-Query, HyDE, Decomposition을 query mismatch 유형에 맞게 선택할 수 있다.
• Lost-in-the-middle 함정과 prompt 내 검색 결과 위치 권장을 설명할 수 있다.
• RAG vs Long-context vs Fine-tune 결정 프레임을 데이터 양, 갱신, 출처 인용, 비용으로 적용할 수 있다.
• Naive, Advanced, Modular, Corrective/Self-RAG, GraphRAG, Agentic RAG의 운영 트리거를 구분할 수 있다.
• Ragas 4-지표를 retrieval 실패와 generation faithfulness 실패 분리에 활용할 수 있다.
• Permission leak, stale data, multi-language mismatch 같은 RAG silent failure를 식별하고 복구 순서를 정할 수 있다.

8. 추가 학습 키워드

• Query transform: HyDE, Multi-Query, Decomposition, Step-back prompting, RAG-Fusion
• Retrieval: semantic, hybrid (BM25+dense), ColBERT, parent-child, auto-merging, knowledge graph
• Architecture variants: Naive RAG, Advanced RAG, Modular RAG, Corrective RAG, Self-RAG, GraphRAG, Agentic RAG
• Advanced: FLARE, RA-DIT, RAPTOR, LightRAG, RAG-Fusion
• 운영 도구: LangChain, LlamaIndex, Haystack, RAGFlow, Verba, AnythingLLM
• 평가: Ragas, TruLens, ARES, DeepEval, RAGAS metrics (faithfulness, relevance, precision, recall)
• Long-context vs RAG: NIAH (Needle in a Haystack), RULER benchmark
• Multimodal RAG: ColPali, image embedding + visual question answering

9. 내가 직접 확인해볼 것

Naive RAG 직접 구현

• LangChain·LlamaIndex로 PDF 100개 RAG 시스템 구축. chunking 512 + recursive splitter
• 같은 데이터에 query rewriting on/off 비교 — 검색 품질·답변 품질 변화

Advanced 패턴

• HyDE 적용: query → 가상 답변 → 임베딩 검색. naive 대비 recall 개선 측정
• Multi-Query: 같은 query 3개 변형 → top-K 합집합 → rerank. 단일 검색 대비 변화
• 같은 gold dataset으로 naive → advanced(query rewriting+hybrid+rerank) → corrective(refusal 포함) 순서의 recall·precision·latency 변화 측정

Hybrid + Rerank

• BM25 + dense + RRF 결합. dense 단독 대비 recall@10 비교 (한국어 도메인이면 더 큰 차이)
• BGE-reranker-v2-m3로 top-100 → top-10 rerank. 정답 문서가 더 위로

Faithfulness

• 검색 결과를 일부러 관련 없게 주고 LLM이 환각하는지 vs prompt에 “근거 없으면 모른다”로 refuse 시키는지 비교
• Ragas로 faithfulness·answer relevance 측정. 답변 품질 점수 회귀 검증

GraphRAG

• Microsoft GraphRAG 라이브러리로 문서 100개를 entity 그래프로 변환. 글로벌 질문 (“이 회사 전체 전략”) 답변 비교

결과가 예상과 다를 때

• naive RAG가 환각 多 → faithfulness prompt 강화, structured citation, refusal 옵션
• 검색이 잘 되는데 답이 이상함 → reranker 추가, top-K 줄이기 (5~7)
• 한국어 query에 영어 답변 → output language 강제 또는 system prompt 재작성
• multi-hop 질문 실패 → query decomposition 또는 agentic RAG 도입

10. 5줄 요약

1. RAG는 외부 지식 검색 + LLM context 주입 + 답변 생성 패턴이고, fine-tuning 없이 자주 갱신·출처 인용·환각 감소를 동시 해결한다.
2. Naive RAG 9단계 위에 query transform(HyDE/Multi-Query/Decomposition)·hybrid+rerank·faithfulness 강제가 운영 품질을 좌우한다.
3. RAG vs Long-context vs Fine-tune 결정은 데이터 양·갱신 빈도·출처 필요성·비용·정확도로 분기된다.
4. Self-RAG·CRAG·GraphRAG·Agentic RAG는 검색 실패·글로벌 질문·multi-hop 업무처럼 운영 트리거가 명확할 때만 올린다.
5. Ragas 4-지표로 회귀 평가하고, permission leak·stale data·lost-in-middle이 흔한 silent failure다.

11. 출처

• Lewis et al., RAG (NeurIPS 2020)
• Gao et al., HyDE (arXiv:2212.10496)
• Liu et al., Lost in the Middle (arXiv:2307.03172)
• Asai et al., Self-RAG (arXiv:2310.11511)
• Yan et al., Corrective RAG (arXiv:2401.15884)
• Microsoft, GraphRAG (arXiv:2404.16130)
• Sarthi et al., RAPTOR (arXiv:2401.18059)
• Es et al., Ragas (arXiv:2309.15217)
• Gao et al., Retrieval-Augmented Generation Survey (arXiv:2312.10997)
• LangChain RAG docs
• LlamaIndex docs
• NVIDIA, GraphRAG vs Vector RAG comparison
• PE Collective, RAG vs Fine-Tuning Cost Comparison 2026
• PremAI Blog, RAG Evaluation Metrics & Frameworks 2026
• Data Science Collective, RAGAS Failure Modes on FinanceBench

---

최종 수정: 2026-05-21