“RAG 시스템에서 Agentic RAG가 항상 더 좋은 선택인가?”라는 질문에 대해, Enhanced RAG와 Agentic RAG를 실험적으로 비교한 논문이다.
결론부터 말하면, Agentic RAG가 항상 우월하지는 않다. Agentic RAG는 query rewriting이나 intent 판단처럼 유연한 판단이 필요한 영역에서는 장점이 있지만, reranking처럼 명확한 전용 모듈이 강한 영역에서는 Enhanced RAG가 더 안정적이고 비용도 낮다.
문제의식
기본적인 Naive RAG는 보통 다음과 같은 구조를 가진다.
User Query
→ Retriever
→ Retrieved Context
→ Generator
→ Answer
하지만 실제 서비스에서는 단순히 검색해서 LLM에 넣는 것만으로는 부족하다. 사용자의 질문이 검색에 적합하지 않을 수도 있고, 검색된 문서에 노이즈가 많을 수도 있으며, 어떤 질문은 애초에 retrieval이 필요하지 않을 수도 있다.
이런 한계를 해결하기 위해 RAG 시스템은 크게 두 방향으로 발전했다.
Enhanced RAG
→ router, query rewriter, reranker 같은 전용 모듈을 붙인 고정 파이프라인
Agentic RAG
→ LLM이 스스로 retrieval 여부, query rewriting, 재검색 여부 등을 판단하는 방식
이 논문의 핵심 질문은 다음과 같다.
RAG 시스템을 설계할 때,
Agentic architecture를 써야 하는가?
아니면 전통적인 Enhanced pipeline이 더 나은가?
논문이 비교한 대상
논문은 Enhanced RAG와 Agentic RAG를 네 가지 관점에서 비교한다.
- User Intent Handling
→ 이 query가 retrieval이 필요한 query인지 판단하는가? - Query Rewriting
→ user query를 검색에 더 적합한 형태로 바꿀 수 있는가? - Document List Refinement
→ 검색된 문서 목록에서 더 좋은 문서를 고를 수 있는가? - Underlying LLM
→ generator 모델 크기/성능 변화가 두 방식에 어떤 영향을 주는가?
실험 데이터셋은 QA와 IR/E 태스크를 모두 포함한다. QA에는 NQ와 FIQA를 사용했고, IR/E에는 FEVER와 CQADupStack-English를 사용했다. 각각 일반 QA, 금융 QA, fact verification, grammar forum retrieval 상황을 대표하도록 구성되어 있다.
Enhanced RAG와 Agentic RAG의 차이
Enhanced RAG는 고정된 파이프라인이다.
Router
→ Query Rewriter
→ Retriever
→ Reranker
→ Generator
각 모듈이 명확한 역할을 가진다. Router는 query가 retrieval 대상인지 판단하고, query rewriter는 query를 검색하기 좋은 형태로 바꾸며, reranker는 검색된 문서 중 더 적합한 문서를 상위로 올린다.
반면 Agentic RAG는 LLM이 workflow를 조정한다.
User Query
→ Agent 판단
→ retrieval 할지 결정
→ query를 어떻게 바꿀지 결정
→ 다시 검색할지 결정
→ 충분하면 답변 생성
이 논문에서의 Agentic RAG는 비교의 공정성을 위해 multi-tool agent가 아니라 single-tool Agentic RAG로 제한된다. 즉, agent가 사용할 수 있는 도구는 retrieval 하나이고, 외부 API 호출이나 복잡한 planning은 제외된다.
실험 1: User Intent Handling
첫 번째 실험은 query가 retrieval을 해야 하는 query인지 아닌지를 판단하는 능력을 본다.
예를 들어 금융 QA 시스템이라면 금융 관련 질문은 retrieval을 해야 하지만, 요리나 여행 질문은 retrieval하지 않는 것이 맞다. 논문에서는 valid query와 invalid query를 구성하고, 각 시스템이 retrieval 여부를 잘 판단하는지 F1과 recall로 평가했다.
FIQA:
Enhanced F1 95.7
Agentic F1 98.8
CQADupStack-EN:
Enhanced F1 96.6
Agentic F1 99.8
FEVER:
Enhanced F1 87.9
Agentic F1 64.6
Agentic RAG는 금융이나 영어 문법처럼 도메인이 명확한 경우에는 Enhanced보다 잘했다. 하지만 FEVER처럼 factual verification 범위가 넓고 도메인 경계가 흐린 경우에는 크게 실패했다.
여기서 중요한 점은 Agentic RAG가 “스스로 판단한다”는 장점이 있지만, 도메인 경계가 애매하면 그 판단이 불안정해질 수 있다는 것이다.
실험 2: Query Rewriting
두 번째 실험은 query rewriting이다.
RAG에서 사용자의 질문은 보통 짧고 모호하다. 반면 knowledge base의 chunk는 길고 복잡한 문장이다. 이 차이 때문에 query와 document가 의미적으로 잘 매칭되지 않을 수 있다.
Query rewriting은 이 gap을 줄이기 위해 query를 document와 더 비슷한 형태로 바꾸는 기법이다.
논문에서는 Enhanced RAG에는 HyDE 기반 rewriting을 강제로 적용하고, Agentic RAG는 agent가 필요하다고 판단할 때 rewriting하도록 설계했다.
결과는 Agentic RAG 쪽이 평균적으로 더 좋았다.
NDCG@10 평균
Naive: 50.3
Enhanced: 52.8
Agentic: 55.6
특히 NQ에서는 Agentic이 Enhanced보다 크게 높은 성능을 보였다. 논문은 이를 Agentic RAG가 query마다 rewriting 여부와 방식을 유연하게 결정할 수 있기 때문이라고 해석한다.
Query rewriting을 항상 하는 것이 좋은 게 아니라, query 성격에 따라 할지 말지를 결정하는 adaptive rewriting이 더 효과적일 수 있다는 뜻이다.
실험 3: Document List Refinement
세 번째 실험은 검색된 문서 목록을 얼마나 잘 정제하는지 본다.
Enhanced RAG는 top-20으로 검색된 문서를 ELECTRA 기반 reranker로 재정렬한다. Agentic RAG는 검색 결과가 부족하다고 판단하면 query를 다시 쓰고 retrieval을 반복할 수 있다.
즉, Enhanced는 명시적 reranker를 쓰고, Agentic은 iterative retrieval로 문서 품질을 개선하려는 방식이다.
결과는 Enhanced RAG가 더 좋았다.
NDCG@10 평균
Naive: 45.5
Enhanced without rewriting: 48.0
Enhanced with rewriting: 49.5
Agentic: 43.9
논문은 Agentic RAG가 retrieval을 반복해도 별 이득을 얻지 못했다고 분석한다. Agent가 다시 retrieval을 수행한 경우는 약 10%였고, 그중 53%의 retrieved documents는 이전과 동일했다.
즉, agent가 한 번 결정을 내리면 잘 재고하지 않고, 반복 retrieval도 실제 문서 목록을 크게 개선하지 못했다.
이 결과에서 중요한 메시지는 다음과 같다.
Agent가 다시 검색할 수 있다 != 좋은 reranker처럼 문서를 잘 고른다
Agentic RAG가 retrieval process를 유연하게 운영할 수는 있지만, 문서 선별 자체는 전용 reranker가 더 잘할 수 있다는 것이다.
실험 4: Underlying LLM
네 번째 실험은 LLM 크기와 성능이 두 방식에 어떤 영향을 주는지 본다.
논문은 Qwen3-0.6B, Qwen3-4B, Qwen3-8B, Qwen3-32B를 사용해 Enhanced RAG와 Agentic RAG를 비교했다.
결과적으로 모델이 커질수록 성능이 좋아지는 패턴은 Enhanced와 Agentic에서 비슷하게 나타났다. 즉, Agentic RAG라고 해서 더 큰 LLM의 이득을 특별히 더 많이 받는 것은 아니었다.
이 말은 실무적으로 이렇게 해석할 수 있다.
좋은 LLM을 쓰면 둘 다 좋아진다.
하지만 Agentic 구조 자체가 모델 스케일링의 이득을 독점하지는 않는다.
비용 분석
이 논문의 장점 중 하나는 성능뿐 아니라 비용과 latency도 같이 봤다는 점이다.
논문은 Agentic RAG가 Enhanced RAG보다 평균적으로 더 비싸고 느리다고 보고한다.
Agentic RAG는 Enhanced RAG 대비
Input token: 평균 3.3배
Output token: 평균 1.9배
Latency: 평균 1.5배
이 차이는 agent의 추가 reasoning step과 반복 tool call 때문에 발생한다.
즉, RAG 시스템 최적화에서 중요한 것은 단순히 vector search 속도를 줄이는 것만이 아니라, LLM call 횟수와 token 사용량을 줄이는 것이다.
결론
Agentic RAG가 항상 좋은 것은 아니다.
Enhanced RAG가 항상 구식인 것도 아니다.
Agentic RAG는 user intent routing과 query rewriting에서 강점을 보인다. 특히 도메인이 명확하고 query rewriting을 유연하게 해야 하는 상황에서는 유용하다.
반면 document refinement에서는 Enhanced RAG의 명시적 reranker가 더 좋은 성능을 보였다. 또한 Agentic RAG는 비용과 latency 측면에서 더 부담이 크다.
논문은 최종적으로 두 방식을 결합하는 방향을 제안한다.
Agentic RAG:
- user intent 판단
- adaptive query rewriting
Enhanced RAG: - explicit reranking
- 안정적인 문서 선별
- 비용 효율적인 pipeline
Agentic으로 다 갈아엎자가 아니라, agent가 잘하는 부분과 고정 모듈이 잘하는 부분을 나눠서 조합하는 것이 더 현실적이다.
