"RAG 핵심 학습 (24/26) — Agentic RAG: Planning, Tool-use, Verification"
질문이 복잡해질수록 RAG는 검색기가 아니라 작은 문제 해결 루프로 변한다.
Agentic RAG는 질문을 한 번 검색하고 한 번 답하는 구조를 넘어서, 질문 분해, 다단계 검색, 도구 호출, 근거 검증을 포함하는 구조다. 핵심은 "더 똑똑한 LLM"이 아니라 검색 과정을 여러 단계로 계획하는 것에 있다.
0. Prerequisites
- 23편 graph RAG
- 22편 corrective RAG
- 19편 query routing
1. 학습 목표
- agentic RAG가 왜 등장했는지 설명한다.
- planning, tool-use, verification의 역할을 구분한다.
- 일반 RAG와 agentic RAG의 차이를 이해한다.
- 언제 agentic RAG가 과도한 선택인지 안다.
2. 핵심 요약
Agentic RAG는 복잡한 질문을 작은 하위 질문으로 나누고, 필요한 도구와 검색 경로를 선택한 뒤, 최종 답을 검증하는 구조다. 예를 들어 비교형, 다단계 절차형, 관계형 질문에서는 단일 retrieval보다 agentic 흐름이 더 자연스럽다. 하지만 구조가 복잡해지고 latency와 비용이 커진다. 따라서 모든 질문에 agentic RAG를 쓰기보다, 높은 난이도 질문에만 제한적으로 적용하는 편이 보통 낫다.
3. 직관 — 한 번의 검색으로는 답하기 어려운 질문
질문: "외부 공유 예외 절차를 최근 개정한 이유와, 그 변경이 법무 검토 단계에 준 영향은?"
이 질문은: 1. 최근 개정 문서를 찾고 2. 개정 이유 문서를 찾고 3. 법무 검토 단계와 연결하고 4. 두 결과를 종합해야 한다
즉 retrieval이 단일 단계가 아니라 작은 계획 문제가 된다.
4. 정의 — agentic RAG의 핵심 용어
| 용어 | 정의 |
|---|---|
| Planning | 질문을 하위 단계로 나누는 과정 |
| Tool-use | 검색기, 데이터베이스, 웹, 계산기 등 외부 도구 호출 |
| Verification | 최종 답이 근거와 맞는지 다시 점검 |
| Reflection | 중간 결과를 보고 다음 행동을 수정하는 단계 |
5. 구조 — agentic RAG는 무엇이 추가되었는가
기본 RAG:
질문 → 검색 → 생성
Agentic RAG:
질문 → 계획 → 검색/도구 호출 → 중간 검토 → 추가 검색 → 최종 검증 → 생성
즉 검색 과정이 닫힌 함수가 아니라 상태를 가진 루프가 된다.
6. 원리 워크스루 — 간단한 agentic loop
6.1 질문 분해
subtasks = [
"최근 개정 문서 찾기",
"개정 이유 찾기",
"법무 검토 단계 영향 찾기",
]
6.2 단계별 도구 호출
for task in subtasks:
route = choose_route(task)
docs = retrieve(task, route)
state.append(docs)
6.3 검증 단계
if not evidence_is_consistent(state):
state.append(retrieve("추가 근거", fallback_route))
자기 설명: agentic RAG가 일반 RAG보다 강한 질문 유형을 한 문장으로 요약해 보라.
7. 변형과 사례
7.1 Planner-Retriever Pattern
planner가 질문을 쪼개고, retriever가 각 단계별 근거를 회수하는 구조다. 가장 기본적인 agentic 형태다.
7.2 Self-RAG / Reflection Pattern
생성 중간에 "근거가 충분한가"를 스스로 묻고 추가 검색을 유도한다.
7.3 Tool-augmented RAG
문서 검색뿐 아니라 SQL, graph query, 웹 검색 같은 도구를 함께 호출한다. 질문 성격에 따라 정보 출처를 바꾼다.
8. 한계와 실패 양상
8.1 계획이 틀리면 전체 흐름이 틀린다
질문 분해 단계가 잘못되면 이후 검색이 모두 엉뚱한 방향으로 간다.
8.2 비용과 latency가 크다
다단계 검색과 검증은 단일 RAG보다 훨씬 무겁다.
8.3 observability 없이는 디버깅이 어렵다
어느 단계에서 잘못됐는지 보려면 16편의 trace와 실험 기록이 필수다.
8.4 다음 단계 — 복잡한 RAG일수록 운영과 보안이 중요해진다
여러 단계, 여러 도구를 쓰는 구조일수록 권한과 재색인 관리가 중요해진다. 25편은 운영과 보안이다.
8.5 입문자가 자주 빠지는 함정 5선
| # | 함정 | 증상 | 빠른 점검 |
|---|---|---|---|
| 1 | 모든 질문에 agentic 적용 | 비용 과다 | 난이도 기준 적용 |
| 2 | planner 품질 미검증 | 엉뚱한 하위 질문 | 분해 결과 샘플 검토 |
| 3 | 단계별 trace 없음 | 디버깅 불가 | 상태 기록 필수 |
| 4 | 검증 단계 생략 | 잘못된 결론 유지 | evidence check 추가 |
| 5 | 도구 권한 관리 부재 | 보안 리스크 | tool scope 제한 |
9. 정리된 결론 — 보지 않고 답해 보라
Q1. agentic RAG가 일반 RAG와 다른 점은?
정답 검색을 한 번에 끝내지 않고 계획, 도구 호출, 검증을 포함한 다단계 흐름으로 만든다는 점이다.
왜 복잡한 질문은 단일 retrieval로 풀기 어렵기 때문이다.
Q2. agentic RAG가 특히 유리한 질문은?
정답 비교형, 관계형, 다단계 절차형 질문이다.
왜 여러 근거를 순차적으로 모아 종합해야 하기 때문이다.
Q3. agentic RAG의 대표적 비용은?
정답 latency, 비용, 디버깅 복잡도다.
왜 단계 수와 외부 도구 호출이 늘어나기 때문이다.
Cheat Sheet — 이 편의 식·정의 1페이지
정의 - Planning: 질문 분해 - Tool-use: 외부 검색/DB/웹 호출 - Verification: 최종 근거 점검
최소 코드
for task in subtasks:
docs = retrieve(task, choose_route(task))
언제 무엇을 | 상황 | 선택 | |---|---| | 단순 FAQ | 일반 RAG | | 관계형 / 다단계 | agentic RAG | | 고위험 답변 | verification 강화 |
참고 자료
1차 자료
- Asai, A. et al. Self-RAG. 2023.
보조 자료
- 사용자 노트 21장 agentic rag
다음 편으로 이어지는 흐름
검색 흐름이 복잡해질수록 운영 면의 책임도 커진다. 다음 25편에서는 권한, 보안, 재색인 운영을 다룬다.
댓글
댓글 쓰기