마치며. RAG 마스터 — 전체 정리
출처: 『RAG 마스터: 랭체인으로 완성하는 LLM 서비스』(브라이스 유·조경아·박수진·김재웅, 프리렉 2025) | 공식: https://www.langchain.com/
0장 환경 설정부터 9장 임베딩 파인튜닝까지, 이 책이 다룬 RAG의 전 여정을 한눈에 되짚는다. 각 기법이 어디에서 왜 등장했는지 한 줄기로 꿰면, 실제 프로젝트에서 "지금 여기에 뭘 쓸까?"를 빠르게 판단할 수 있다.
실습 — 책 공식 repo 전체: langchain-kr/langchain-tutorial — 1~9장 모든 노트북을 다시 종합해 보며 자기 프로젝트에 맞는 RAG 조합 결정.
학습 목표
이 장을 끝내면 다음을 할 수 있다.
- RAG 전체 파이프라인(로드→분할→임베딩→저장→검색→생성)을 단계별로 요약한다.
- 기본 RAG·고도화 RAG·그래프 RAG·에이전트 RAG·파인튜닝을 상황별로 비교하고 적합한 기법을 선택한다.
- 검색 품질·생성 품질·흐름 구조·데이터 구조 네 축에서 각 기법이 어떤 문제를 해결하는지 설명한다.
- 시나리오별 의사결정 가이드를 참조해 실전 프로젝트에 적용할 RAG 기법 조합을 결정한다.
- 단계별 로드맵(Phase 1~4)에 따라 RAG 시스템의 구축·고도화 순서를 수립한다.
전체 흐름도
[문서 · 이미지 · 지식그래프]
↓
(1) 로드 — DocumentLoader (텍스트/PDF/웹) · unstructured (멀티모달) ← 2장·3장
↓
(2) 분할 — TextSplitter · SemanticChunker · 부모-자식 분할 ← 2장·4장
↓
(3) 임베딩 — OpenAIEmbeddings · HuggingFace · 파인튜닝 임베딩 ← 2장·9장
↓
(4) 저장 — Chroma · FAISS · Neo4j(그래프) ← 2장·5장
↓
(5) 검색 ─────────────────────────────────────────────────────────────
├─ 기본: as_retriever() (유사도 k개) ← 2장
├─ 고도화: 멀티쿼리 · HyDE · 앙상블(BM25+Dense) · 리랭킹 ← 4장
├─ 그래프: 로컬/글로벌 검색 · Cypher ← 5장
└─ 에이전트: ReAct가 도구로서 검색 ← 7장
↓
(6) 생성 ─────────────────────────────────────────────────────────────
├─ 기본: retriever | prompt | LLM | parser ← 1장·2장
├─ Self-RAG: 검색 필요 여부 자체 판단 + 품질 자체 평가 ← 4장
├─ LangGraph: StateGraph로 분기·루프 제어 ← 6장
└─ 파인튜닝 LLM: RAFT+LoRA로 도메인 특화 ← 8장
↓
[최종 답변]
인덱싱(1~4)은 사전 준비, 쿼리(5~6)는 실시간 처리. 고도화·그래프·에이전트는 (5)~(6) 사이에 껴들어 검색 품질과 답변 품질을 각각 높인다.
1. 단계별 핵심 요약
| 장 | 주제 | 핵심 기법 | 한 줄 takeaway |
|---|---|---|---|
| 0장 | 실습 환경 | Colab · .env · API 키 | 환경부터 잡아야 코드가 돌아간다 |
| 1장 | 랭체인 기초 | LCEL · Runnable · 프롬프트 · 출력 파서 · 메모리 | prompt \| model \| parser 조합이 RAG의 뼈대다 |
| 2장 | RAG 기초 | 로드→분할→임베딩→저장→검색→생성 파이프라인 | 6단계를 직접 조립하면 RAG가 완성된다 |
| 3장 | 멀티모달 RAG | unstructured · MultiVectorRetriever · MLLM | 이미지·표를 텍스트와 함께 검색·생성할 수 있다 |
| 4장 | RAG 고도화 | 청킹 전략 · 질의 변형 · 앙상블 · 리랭킹 · Self-RAG | 검색 품질과 생성 품질은 각 단계에서 따로 올린다 |
| 5장 | 그래프 RAG | 지식 그래프 · Neo4j · Cypher · 커뮤니티 탐지 | 관계형 데이터는 벡터 DB 대신 그래프로 다룬다 |
| 6장 | LangGraph | StateGraph · 분기 · 루프 · 체크포인트 · Human-in-the-loop | 복잡한 흐름은 상태 그래프로 선언적으로 설계한다 |
| 7장 | ReAct 에이전트 | ReAct 방법론 · ToolNode · LangGraph 에이전트 루프 | LLM이 생각→행동→관찰을 반복하며 자율적으로 문제를 푼다 |
| 8장 | LLM 파인튜닝 | RAFT · SFT · LoRA · QLoRA · RunPod | 도메인 데이터로 모델 자체를 RAG에 맞게 튜닝할 수 있다 |
| 9장 | 임베딩 파인튜닝 | sentence-transformers · MNRL · 하드 네거티브 마이닝 | 검색 품질의 뿌리인 임베딩 모델 자체를 개선할 수 있다 |
2. RAG를 키우는 4개의 축
RAG의 성능을 높이는 방향은 크게 네 가지다. 각 축에서 어떤 기법이 무엇을 해결하는지 정리한다.
축 1. 검색 품질 (무엇을 가져오는가)
문서를 얼마나 잘 찾아오느냐가 생성 품질의 상한선이다.
- 청킹: 부모-자식 분할(
ParentDocumentRetriever)로 정밀 검색 + 풍부한 컨텍스트 - 질의 변형: 멀티쿼리 생성(
MultiQueryRetriever) · HyDE로 질문과 문서 간 표현 차이 극복 - 하이브리드 검색: BM25(희소) + Dense(밀집) →
EnsembleRetriever로 각 방식의 약점 보완 - 리랭킹: Cross-Encoder로 초기 결과를 재정렬해 진짜 관련 문서만 LLM에 전달
- 임베딩 파인튜닝: 도메인 특화 쌍(질문-정답) + 하드 네거티브로 검색 임베딩 자체 개선
축 2. 생성 품질 (어떻게 답하는가)
가져온 컨텍스트로 LLM이 얼마나 좋은 답을 내는가.
- 프롬프트 최적화: 퓨샷 · 예제 선택기 · rag-prompt 허브로 지침 품질 향상
- Self-RAG: 검색 필요 여부 판단 → 관련성 평가 → 답변 품질 자가 평가 → 루프
- LLM 파인튜닝: RAFT로 RAG 형식(컨텍스트 포함 Q&A)에 맞게 모델 훈련
축 3. 흐름 구조 (어떻게 조율하는가)
단순 체인을 넘어 분기·루프·멀티스텝이 필요한 경우.
- LangGraph: StateGraph + 조건부 엣지로 "질문 분류 → 검색 경로 선택 → 생성" 같은 복잡한 흐름 선언
- ReAct 에이전트:
Thought → Action → Observation루프로 LLM이 도구를 선택·실행 - Human-in-the-loop: 중간 상태에서 사람이 개입·수정·승인하는 체크포인트
축 4. 데이터 구조 (어떻게 저장하는가)
데이터의 성격에 따라 저장소 선택이 검색 품질을 좌우한다.
- 벡터 DB(Chroma·FAISS): 의미 유사도 기반 비구조화 텍스트
- 그래프 DB(Neo4j): 개체 간 관계·다층 추론이 필요한 지식 구조
- 멀티벡터 저장소: 원본(docstore) + 요약/임베딩(vectorstore) 분리로 멀티모달·대용량 문서 처리
3. 언제 무엇을 쓰나 — 의사결정 가이드
| 상황 | 권장 접근 | 핵심 기법 |
|---|---|---|
| 처음 RAG를 만든다 | 기본 RAG (2장) | RecursiveTextSplitter + Chroma + as_retriever |
| 검색 정밀도가 부족하다 | 청킹·검색 고도화 (4장) | 부모-자식 분할 · 앙상블 · 리랭킹 |
| 질문과 문서 표현이 안 맞는다 | 질의 변형 (4장) | MultiQueryRetriever · HyDE |
| 이미지·표·차트가 섞여 있다 | 멀티모달 RAG (3장) | unstructured + MultiVectorRetriever + MLLM |
| 개체 간 관계가 중요한 데이터 | 그래프 RAG (5장) | Neo4j + Cypher + 커뮤니티 탐지 |
| 검색→판단→검색 루프가 필요하다 | LangGraph (6장) | StateGraph + 조건부 엣지 + 체크포인트 |
| LLM이 스스로 도구를 선택해야 한다 | ReAct 에이전트 (7장) | ToolNode + LangGraph create_react_agent |
| 도메인 특화 답변 품질이 낮다 | LLM 파인튜닝 (8장) | RAFT + SFT + LoRA/QLoRA |
| 검색 자체의 벡터 품질이 낮다 | 임베딩 파인튜닝 (9장) | sentence-transformers + MNRL + 하드 네거티브 |
| Self-RAG처럼 자체 검증을 원한다 | Self-RAG (4장) | 관련성 평가 토큰 + 조건 분기 |
4. 실전 적용 로드맵
단계별로 RAG를 구축·고도화하는 권장 순서다. 각 단계를 완료한 후 다음으로 넘어간다.
Phase 1 — PoC (개념 검증)
- [ ] 환경 설정:
.env, API 키, 패키지 설치 (0장) - [ ] 기본 파이프라인 동작 확인: 로드 → 분할 → 임베딩 → Chroma → 검색 → 생성 (2장)
- [ ]
prompt | model | StrOutputParser()LCEL 체인 작동 확인 (1장)
Phase 2 — 검색 품질 고도화
- [ ] 청킹 전략 실험: 고정 분할 → SemanticChunker → 부모-자식 분할 비교
- [ ] 질의 변형 적용: MultiQueryRetriever 또는 HyDE 중 선택
- [ ] 하이브리드 검색: BM25 + Dense → EnsembleRetriever
- [ ] 리랭킹 추가: Cross-Encoder로 초기 결과 재정렬
- [ ] (선택) Self-RAG로 검색 필요 여부 자동 판단
Phase 3 — 구조 고도화
- [ ] 복잡한 흐름은 LangGraph StateGraph로 전환 (6장)
- [ ] 다중 도구가 필요하면 ReAct 에이전트 도입 (7장)
- [ ] 멀티모달 데이터(이미지·표)가 있으면 3장 전략 적용
- [ ] 관계형 데이터가 있으면 Neo4j 그래프 RAG 검토 (5장)
Phase 4 — 운영 최적화
- [ ] 도메인 특화 품질이 부족하면: LLM 파인튜닝(8장) 또는 임베딩 파인튜닝(9장) 중 선택
- [ ] LangSmith로 평가·모니터링 파이프라인 구축
- [ ] 검색 성능 지표(MRR·NDCG·Precision·Recall) 정량 측정
핵심 개념 정리
| 개념 | 한 줄 요약 |
|---|---|
| RAG | 외부 문서를 검색해 LLM의 생성에 주입. 최신·도메인 정보를 반영하는 실용 기법 |
| LCEL | 러너블을 \| 로 잇는 선언적 체인. invoke·batch·stream 공통 인터페이스 |
| 임베딩 | 텍스트(또는 이미지)를 숫자 벡터로 변환. 유사도 계산의 기반 |
| 청킹 | 긴 문서를 검색·생성에 최적화된 단위로 분할. 전략에 따라 검색 품질이 달라진다 |
| 앙상블 검색 | BM25(키워드) + Dense(의미) 하이브리드로 두 방식의 장점을 결합 |
| 리랭킹 | 초기 검색 결과를 Cross-Encoder로 재정렬. 노이즈를 걸러 LLM 부담을 줄인다 |
| Self-RAG | LLM이 검색 필요 여부·관련성·품질을 스스로 평가해 결과를 개선하는 고도화 방법론 |
| 그래프 RAG | 개체-관계를 그래프로 저장(Neo4j)하고 Cypher·커뮤니티 탐지로 다층 추론 |
| LangGraph | StateGraph 기반 워크플로. 분기·루프·체크포인트·Human-in-the-loop 지원 |
| ReAct | Thought→Action→Observation 루프. LLM이 도구를 자율적으로 선택·실행 |
| RAFT | RAG 형식(컨텍스트 포함 Q&A + 산만 문서)으로 LLM을 파인튜닝해 도메인 정확도 향상 |
| LoRA | 원본 가중치를 고정하고 저랭크 행렬만 학습. GPU 메모리 효율적 파인튜닝 |
| MNRL | MultipleNegativesRankingLoss. 배치 내 다른 샘플을 네거티브로 활용하는 대조 학습 손실 함수 |
| 하드 네거티브 | 의미상 비슷하지만 정답이 아닌 어려운 부정 예시. 임베딩 모델 변별력을 높인다 |
실무 체크리스트
- [ ] 기본 RAG 6단계(로드→분할→임베딩→저장→검색→생성)를 직접 조립해 동작을 확인한다.
- [ ] 검색 품질이 부족할 때 단계별로 원인을 찾는다 — 청킹 → 질의 변형 → 검색 알고리즘 → 리랭킹 순.
- [ ] 데이터 성격에 맞는 저장소를 고른다 — 비구조화 텍스트는 벡터 DB, 관계형 지식은 그래프 DB.
- [ ] 흐름이 복잡해지면(분기·루프·Human-in-the-loop) LangGraph로 전환한다.
- [ ] 도메인 특화 품질을 높이려면 LLM 파인튜닝(RAFT+LoRA)과 임베딩 파인튜닝 중 병목이 어디인지 먼저 진단한다.
- [ ] 모든 모델명·API 가격은 빠르게 바뀐다. 공식 문서를 항상 최신 기준으로 확인한다.
- [ ] LangSmith로 각 단계를 추적·평가해 어느 기법이 실제로 성능을 높이는지 정량으로 검증한다.
연습문제
-
시나리오 설계. 사내 법무 문서 수천 건을 대상으로 RAG를 구축한다. 문서에는 계약서 이미지·표가 많고, "A 회사와 B 회사의 계약 관계"처럼 개체 간 관계를 묻는 질문이 자주 온다. 어떤 기법 조합을 선택하겠는가? 각 선택의 이유를 단계별로 논하라.
-
비교 분석. 기본 RAG와 Self-RAG의 가장 큰 차이를 설명하고, Self-RAG가 비용 측면에서 불리한 이유와 그럼에도 쓸 만한 상황을 제시하라.
-
설계 판단. 검색 정밀도를 높이기 위해 "리랭킹"과 "임베딩 파인튜닝" 중 하나를 선택해야 한다. 어느 상황에서 무엇을 먼저 시도할지, 판단 기준과 함께 설명하라.
-
구조 선택. 다음 두 요구사항을 가진 시스템을 설계한다: (a) 사용자 질문에 따라 '검색' 또는 '데이터베이스 조회' 중 경로를 자동으로 선택, (b) 답변 전 사람이 승인하는 단계가 있다. 랭체인 기본 체인 대신 LangGraph를 써야 하는 이유와 필요한 핵심 컴포넌트를 설명하라.
-
전체 진단. 구축한 RAG 시스템의 답변 품질이 낮다. 검색 단계 문제인지, 생성 단계 문제인지 어떻게 구분하겠는가? 각 단계를 진단하는 방법과 해당 고도화 기법을 매핑하라.
최신 동향 (2026-05 기준)
최신 동향 (검증 2026-05-21) — 책(2025, LangChain 0.3) 이후 변화만 보완 정리.
- LangGraph 1.0 GA 독립화. 복잡한 분기·루프·에이전트의 표준이 LangGraph로 완전히 이동. StateGraph + checkpointer persistence가 현행 메모리 관리 방식. 책의
RunnableWithMessageHistory는 LangGraph persistence로 대체 권장. (출처: https://langchain-ai.github.io/langgraph/) - ReAct 에이전트 간소화. 수동 ReAct 구성은
create_react_agent()헬퍼로 대폭 단순화. (출처: https://langchain-ai.github.io/langgraph/agents/agents/) - 임베딩 파인튜닝 표준화. sentence-transformers v3+
SentenceTransformerTrainer+ MNRL + 하드 네거티브 마이닝이 실무 표준. (출처: https://sbert.net/docs/sentence_transformer/training_overview.html) - 모델·가격은 수시 변동. 공식 모델 목록 항상 확인: OpenAI(https://platform.openai.com/docs/models) · Anthropic(https://docs.anthropic.com/en/docs/about-claude/models) · Google(https://ai.google.dev/gemini-api/docs/models)
부록 A. 용어 사전
| 한글 | 영문 | 의미 |
|---|---|---|
| 검색 증강 생성 | RAG (Retrieval-Augmented Generation) | 외부 문서를 검색해 LLM 생성에 주입하는 기법. 최신·도메인 정보를 반영한다 |
| 랭체인 표현식 언어 | LCEL (LangChain Expression Language) | 러너블을 |로 잇는 선언적 체인 구성 방식. invoke·batch·stream 공통 인터페이스 제공 |
| 청킹 | Chunking | 긴 문서를 검색·생성에 최적화된 단위로 분할하는 전처리 단계 |
| 앙상블 검색 | Ensemble Retrieval | BM25(키워드 희소)와 Dense(의미 밀집) 두 방식을 결합해 각각의 약점을 보완하는 검색 전략 |
| 리랭킹 | Reranking | 초기 검색 결과를 Cross-Encoder로 재정렬해 노이즈를 줄이는 후처리 단계 |
| 자기 참조 RAG | Self-RAG | LLM이 검색 필요 여부·관련성·답변 품질을 스스로 평가해 결과를 개선하는 방법론 |
| 그래프 RAG | Graph RAG | 개체-관계를 지식 그래프(Neo4j)로 저장하고 Cypher·커뮤니티 탐지로 다층 추론하는 기법 |
| 상태 그래프 | StateGraph | LangGraph의 핵심 컴포넌트. 상태(state)와 조건부 엣지로 복잡한 워크플로를 선언적으로 설계 |
| ReAct | ReAct (Reasoning + Acting) | Thought→Action→Observation 루프로 LLM이 도구를 자율적으로 선택·실행하는 에이전트 방법론 |
| 검색 증강 파인튜닝 | RAFT (Retrieval-Augmented Fine-Tuning) | RAG 형식(컨텍스트 포함 Q&A + 산만 문서)으로 LLM을 파인튜닝해 도메인 정확도를 높이는 기법 |
| 저랭크 적응 | LoRA (Low-Rank Adaptation) | 원본 가중치를 고정하고 저랭크 행렬만 학습하는 파라미터 효율적 파인튜닝 기법 |
| 다중 부정 랭킹 손실 | MNRL (MultipleNegativesRankingLoss) | 배치 내 다른 샘플을 네거티브로 활용하는 대조 학습 손실 함수. 임베딩 파인튜닝의 표준 |
부록 B. 핵심 비교표
RAG 유형별 종합 비교
| 구분 | 기본 RAG | 고도화 RAG | 그래프 RAG | 에이전트 RAG |
|---|---|---|---|---|
| 핵심 기법 | as_retriever + LCEL | 앙상블·리랭킹·Self-RAG | Neo4j + Cypher | ReAct + ToolNode |
| 데이터 구조 | 벡터 DB (Chroma·FAISS) | 벡터 DB + 멀티벡터 | 그래프 DB (Neo4j) | 혼합 (도구에 따라 선택) |
| 적합 질문 유형 | 단순 의미 유사도 검색 | 복잡한 질의·표현 불일치 | 개체 간 관계·다층 추론 | 다단계 계획·자율 도구 선택 |
| 흐름 제어 | 단방향 체인 | 조건 분기 (Self-RAG) | 단방향 + Cypher 질의 | Thought→Action→Obs 루프 |
| 구현 복잡도 | 낮음 | 중간 | 높음 | 높음 |
| 참고 장 | 2장 | 4장 | 5장 | 7장 |
파인튜닝 방법 비교
| 구분 | LLM 파인튜닝 (RAFT+LoRA) | 임베딩 파인튜닝 (MNRL) |
|---|---|---|
| 개선 대상 | 생성 품질 (답변 정확도) | 검색 품질 (벡터 유사도) |
| 학습 데이터 | 컨텍스트 포함 Q&A + 산만 문서 | 질문-정답 쌍 + 하드 네거티브 |
| 필요 자원 | GPU 대용량 (RunPod 등 클라우드) | GPU 중간 (로컬 가능) |
| 적합 상황 | 도메인 특화 답변 품질이 낮을 때 | 검색 임베딩 자체 변별력이 낮을 때 |
| 참고 장 | 8장 | 9장 |
부록 C. 추천 참고 자료
검증된 외부 자료 (Tier 1 공식, 생존 확인 2026-05-21)
| 자료 | 링크 |
|---|---|
| LangChain 개념 허브 | python.langchain.com/docs/concepts |
| LangGraph 공식 문서 | langchain-ai.github.io/langgraph |
| sentence-transformers 학습 가이드 | sbert.net/docs |
| OpenAI 모델 목록 | platform.openai.com/docs/models |
| Anthropic 모델 목록 | docs.anthropic.com/en/docs/about-claude/models |
| Google Gemini 모델 목록 | ai.google.dev/gemini-api/docs/models |
| Awesome-LangChain (커뮤니티) | github.com/kyrolabs/awesome-langchain |
| 책 실습 코드 | github.com/langchain-kr/langchain-tutorial |
| 연계 챕터 | 설명 |
|---|---|
| 0장 실습 환경 | API 키·패키지 설치·Colab 환경 설정 |
| 1장 랭체인 기초 | LCEL·Runnable·프롬프트·출력 파서 |
| 2장 기본 RAG | 6단계 파이프라인 전체 구현 |
| 4장 RAG 고도화 | 청킹·질의 변형·앙상블·리랭킹·Self-RAG |
| 5장 그래프 RAG | Neo4j·Cypher·커뮤니티 탐지 |
| 6장 LangGraph | StateGraph·분기·루프·체크포인트 |
| 7장 ReAct 에이전트 | ToolNode·create_react_agent |
| 8장 LLM 파인튜닝 | RAFT·SFT·LoRA·QLoRA |
| 9장 임베딩 파인튜닝 | sentence-transformers·MNRL·하드 네거티브 |
부록 D. 연습문제 풀이
-
(멀티모달 + 그래프 RAG 조합) 계약서 이미지·표는
unstructured+MultiVectorRetriever(3장)로 처리하고, "A 회사와 B 회사의 계약 관계"처럼 개체 간 관계 질문은 Neo4j 그래프 RAG(5장)로 다룬다. 즉 저장소를 벡터 DB(비구조화 텍스트)와 그래프 DB(개체-관계)로 이중화하고, 질문 유형에 따라 LangGraph StateGraph가 검색 경로를 분기 선택하는 구조가 적합하다(§3 의사결정 가이드 참조). -
(기본 RAG vs Self-RAG) 기본 RAG는 질문이 들어오면 무조건 검색 후 생성하지만, Self-RAG는 LLM이 검색 필요 여부를 먼저 판단하고, 검색 결과의 관련성과 최종 답변 품질까지 자가 평가해 루프를 반복한다(§1, 4장). 이 자가 평가 루프가 LLM 호출을 여러 번 수행하기 때문에 비용·지연이 증가하는 것이 단점이다. 그럼에도 검색 결과의 노이즈가 많거나 답변 품질의 일관성이 중요한 도메인(예: 법률·의료)에서는 정확도 향상 효과가 추가 비용을 정당화한다.
-
(리랭킹 vs 임베딩 파인튜닝 선택 기준) 리랭킹(Cross-Encoder)은 도메인 특화 학습 데이터 없이도 즉시 적용 가능하므로 초기 단계나 레이블링 비용이 부담될 때 먼저 시도한다. 임베딩 파인튜닝(MNRL + 하드 네거티브)은 질문-정답 쌍 데이터셋 구축이 선행되어야 하지만, 검색 벡터 표현 자체의 변별력이 낮은 경우(즉 리랭킹으로도 개선 한계가 있을 때) 근본 해결책이 된다(§2 축 1, 9장). 판단 순서: 리랭킹 적용 후 지표(MRR·Recall) 개선 폭이 미미하면 임베딩 파인튜닝으로 이동.
-
(LangGraph를 써야 하는 이유) 랭체인 기본 체인은 단방향 선형 실행만 지원하므로, "검색 경로 자동 선택"(조건부 분기)과 "사람 승인 단계"(Human-in-the-loop 체크포인트) 두 요구사항을 동시에 충족할 수 없다. LangGraph는
StateGraph로 조건부 엣지를 선언해 경로를 분기하고,checkpointer로 중간 상태를 저장해 사람이 승인 후 재개하는 흐름을 구현할 수 있다(§2 축 3, 6장). 필요한 핵심 컴포넌트는StateGraph, 조건부 엣지(add_conditional_edges),interrupt_before/interrupt_after체크포인트다. -
(검색 vs 생성 단계 진단) 검색 단계 문제인지 확인하려면 검색된 문서를 직접 열람해 정답 문서가 포함되어 있는지 확인하고, Precision·Recall·MRR 같은 검색 지표를 측정한다. 정답 문서가 포함되어 있음에도 최종 답변이 나쁘다면 생성 단계 문제이므로 프롬프트 최적화·Self-RAG·LLM 파인튜닝(RAFT)을 검토한다. 검색 단계 문제라면 청킹 전략 → 질의 변형 → 앙상블·리랭킹 → 임베딩 파인튜닝 순으로 고도화하며, LangSmith로 각 단계를 추적해 병목을 정량적으로 특정한다(§2 실무 체크리스트, §4 Phase 2·4 참조).
클릭하거나 Space를 눌러 뒤집기