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를 제안한 동기가 정확히 이 셋이다.

지식 갱신 비용: fine-tuning으로 신규 지식을 주입하려면 초기 셋업만 $2,400~$18,000 + 문서 갱신마다 $500~$5,000이 다시 든다. 매일·매주 갱신되는 정책·FAQ·가격표는 fine-tune 사이클이 따라잡지 못한다 (pecollective, 2026 cost guide).
출처 불가: 가중치에서 합성된 답은 “어느 문서·문단의 어느 줄에 근거했는가”를 되짚을 수 없다. 의료·법률·금융은 답변마다 인용이 강제되므로 parametric만으로는 운영 불가 (Lewis et al. 2020 abstract — “providing provenance for their decisions”).
환각: 학습 분포 밖 질문에서도 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 호출 → 답변 생성

이게 가장 단순한 형태. 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	Long-context	Fine-tune
데이터 양	무제한 (검색)	모델 한도 (1M~10M)	fine-tune 데이터
갱신	즉시	prompt 교체	재학습 필요
비용 (호출당)	검색+생성	매우 높음 (1M ctx)	낮음 (적은 prompt)
출처 인용	자연	어려움	어려움
latency	검색 latency	큰 prompt prefill	보통
정확도	검색·rerank 의존	큰 prompt에서 lost	도메인 적응

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

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

깨지는 조건 (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년에 1~~2회면 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	Long-context (1M)	Fine-tune
데이터 양	무제한 (검색)	~10M tokens	1K~100K 샘플
갱신 비용	즉시 (CDC)	prompt 교체	재학습 ($K~$M)
호출당 비용	검색+생성 ($0.001)	1M ctx ($1~10)	$0.0001~$0.01
출처 인용	자연 (자동)	어려움	어려움
Latency	검색 100ms+ 생성	prefill 매우 큼	보통
정확도	retrieval 의존	lost-in-middle	도메인 적응
권장 시나리오	자주 갱신·출처	단발·전체 분석	행동·톤·포맷

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. 체크리스트

Naive RAG 파이프라인 9단계를 설명할 수 있다
Query rewriting·Multi-Query·HyDE·Decomposition 4종 query transform을 작업에 맞게 선택할 수 있다
Lost-in-the-middle 함정과 prompt 내 검색 결과 위치 권장을 설명할 수 있다
RAG vs Long-context vs Fine-tune 결정 프레임을 데이터 양·갱신·출처 인용·비용으로 적용할 수 있다
Naive, Advanced, Modular, Corrective/Self-RAG, GraphRAG, Agentic RAG의 운영 트리거를 구분할 수 있다
Ragas 4-지표(faithfulness, answer relevance, context precision, context recall)를 측정할 수 있다
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줄 요약

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

11. 출처

최종 수정: 2026-05-21