대규모 언어모델이 길게 추론하고 여러 도구를 오가며 작업하는 능력은 빠르게 좋아지고 있다.
그런데 기존 RAG는 여전히 문서를 한 번에 모아서 넣거나, 사람이 미리 짜 둔 절차를 그대로 따르게 하는 경우가 많다.
이 논문은 바로 그 지점을 문제로 본다. 모델이 더 똑똑해졌는데도, 정작 검색 단계에서는 스스로 전략을 선택할 수 없다는 것이다.
논문의 핵심 주장은 단순하다.
앞으로의 RAG는 “좋은 문서를 미리 골라 넣는 파이프라인”이 아니라, 모델이 검색 도구를 직접 다루며 필요한 정보를 점진적으로 찾아가는 상호작용 시스템이 되어야 한다.
A-RAG는 그 전환을 위해 keyword_search, semantic_search, chunk_read라는
세 가지 계층형 검색 인터페이스를 제안한다.

그림 1. 논문이 제시하는 패러다임 전환. 핵심은 상위 몇 개 청크를 미리 정해 넣는 방식에서, 모델이 도구를 들고 직접 탐색하는 방식으로 중심이 이동한다는 점이다. 원문 Figure 1.
왜 이 논문이 중요할까
논문은 기존 RAG를 크게 두 부류로 정리한다.
첫째는 한 번의 검색으로 여러 문서를 뽑아 모델 입력에 붙이는 방식이다.
그래프 구조를 쓰든, 재정렬을 하든, 결국 마지막에는 “검색 알고리즘이 정한 문서 묶음”을 모델이 받아서 답하게 된다. 이 구조에서는 모델이 검색 자체를 바꾸지 못한다.
둘째는 미리 정해 둔 워크플로를 단계별로 수행하게 하는 방식이다.
예를 들어 키워드를 뽑고, 검색하고, 다시 순위를 매기고, 마지막에 답하는 절차를 고정해 둔다.
이 방식은 검색을 여러 번 하게 만들 수는 있지만, 여전히 모델이 상황에 따라 전략을 새로 만들거나 도중에 방향을 바꾸는 데는 한계가 있다.
논문은 이 둘 모두를 “완전히 agentic한 RAG”라고 보지 않는다. 진짜 agentic RAG라면 적어도 세 가지가 필요하다고 말한다.
전략을 스스로 선택할 수 있어야 하고, 중간 결과를 보고 반복 횟수를 늘리거나 줄일 수 있어야 하며,
이전 도구 결과를 바탕으로 다음 도구를 고르는 상호작용이 가능해야 한다.

그림 2. 논문은 Agentic RAG를 판단하는 기준으로 자율적 전략 선택, 반복 실행, 도구 사용의 상호작용을 제시한다. A-RAG는 이 세 조건을 모두 만족하는 구조로 정의된다. 원문 Figure 2.
이 장면에서 논문이 던지는 메시지는 분명하다. 검색 품질을 높이기 위해 검색 알고리즘을 더 복잡하게 만드는 것보다, 모델이 검색을 직접 조직할 수 있도록 인터페이스를 설계하는 일이 더 중요해지고 있다.
A-RAG는 무엇을 바꾸는가
A-RAG의 설계는 의외로 단순하다. 복잡한 그래프를 크게 추가하지 않고, 정보 접근 단계를 세 층으로 나눈다.
- 키워드 수준: 특정 인물명, 지명, 용어처럼 정확한 표현을 찾는다.
- 문장 의미 수준: 질문과 의미가 비슷한 문장을 찾는다.
- 청크 수준: 실제로 필요한 문서 조각 전체를 읽는다.
논문은 코퍼스를 먼저 약 1,000토큰 정도의 청크로 나누고, 문장 경계를 보존한 뒤, 각 문장을 임베딩으로 표현한다.
중요한 점은 키워드 검색을 위해 무거운 사전 인덱스나 지식 그래프를 미리 만들지 않는다는 것이다.
대신 질의 시점에 텍스트를 직접 매칭한다.
즉, 정확한 문자열 탐색은 가볍게 처리하고, 의미 기반 탐색은 문장 임베딩으로 처리하고, 최종 확인은 청크 전체 읽기로 처리하는 구조다.

그림 3. A-RAG는 검색 결과를 바로 답변에 쓰지 않고, 먼저 단서를 찾고, 그다음 필요한 청크만 펼쳐 읽는 방식으로 정보를 점진적으로 공개한다. 원문 Figure 3.
이 구조가 좋은 이유는 두 가지다.
하나는 검색 비용을 단계적으로 늘릴 수 있다는 점이다.
처음부터 긴 문서를 다 읽지 않고, 짧은 단서에서 시작해 정말 필요한 경우에만 전체 문맥을 연다.
다른 하나는 모델이 어떤 질문인지에 따라 검색 전략을 바꿀 수 있다는 점이다.
이름이 중요한 질문이면 키워드 검색이 먼저 먹히고, 표현은 다르지만 의미가 비슷한 문장을 찾아야 하는 질문이면 의미 검색이 먼저 유리하다.
세 가지 도구는 어떻게 작동하나
A-RAG의 도구는 수식보다 동작 원리로 이해하는 편이 낫다.
| 도구 | 하는 일 | 핵심 포인트 |
|---|---|---|
keyword_search |
정확한 단어나 짧은 구를 포함한 청크를 찾는다 | 어떤 키워드가 많이, 또 더 구체적으로 등장한 청크를 더 중요하게 본다 |
semantic_search |
질문과 의미가 비슷한 문장을 찾는다 | 문장 단위로 가장 잘 맞는 근거를 찾고, 그 문장이 들어 있는 청크를 후보로 올린다 |
chunk_read |
선택한 청크 전체를 읽는다 | 검색 도구가 준 짧은 스니펫만으로 답하지 않고, 필요한 청크만 확실히 확인한다 |
여기서 특히 중요한 것은 검색 결과가 처음부터 전체 문서가 아니라 “짧은 스니펫”으로 주어진다는 점이다.
모델은 이 스니펫을 보고 “어떤 청크를 실제로 펼쳐 읽을지”를 다시 판단한다.
즉, 검색과 읽기가 분리되어 있다. 이 차이가 A-RAG의 효율성을 만든다.
또 하나의 장치는 context tracker다. 이미 읽은 청크를 다시 읽으려고 하면 본문을 또 보내지 않고 “이미 읽은 청크”라고 알려 준다. 이 덕분에 모델이 같은 곳을 반복해서 훑는 낭비를 줄이고, 다른 후보를 탐색하도록 유도한다.
이 논문이 실제로 잘 되나
실험은 HotpotQA, 2WikiMultiHopQA, MuSiQue, GraphRAG-Bench의 Medical/Novel 분할에서 진행된다.
비교 대상은 단순한 Naive RAG, GraphRAG 계열, Workflow RAG 계열, 그리고 도구를 하나만 쓴 단순 Agentic 버전인 A-RAG (Naive)다.
아래 표는 GPT-5-mini를 백본으로 사용했을 때의 LLM-Acc 기준 핵심 결과만 정리한 것이다.
| 방법 | MuSiQue | HotpotQA | 2Wiki | Medical | Novel |
|---|---|---|---|---|---|
| Naive RAG | 52.8 | 81.2 | 50.2 | 86.1 | 70.6 |
| HippoRAG2 | 61.7 | 84.8 | 82.0 | 78.2 | 54.3 |
| LinearRAG | 62.4 | 86.2 | 87.2 | 79.2 | 54.7 |
| A-RAG (Naive) | 66.2 | 90.8 | 70.6 | 92.7 | 80.4 |
| A-RAG (Full) | 74.1 | 94.5 | 89.7 | 93.1 | 85.3 |
여기서 먼저 눈에 들어오는 것은 A-RAG (Naive)다.
이 버전은 사실상 임베딩 검색 도구 하나와 청크 읽기만 있는 매우 단순한 구조인데도, 여러 기존 방법보다 강한 성능을 보인다.
논문은 이 결과를 두고 “agentic한 의사결정 자체가 이미 큰 이점”이라고 해석한다.
하지만 더 중요한 것은 A-RAG (Full)이다.
계층형 인터페이스를 모두 제공하면 성능이 한 단계 더 뛴다.
특히 GPT-5-mini 같은 더 강한 추론 모델로 갈수록 이 이점이 크게 드러난다.
논문은 GPT-4o-mini에서는 5개 데이터셋 중 3개에서 가장 좋았고, GPT-5-mini에서는 전 벤치마크에서 최고 성능을 기록했다고 정리한다.
이 결과가 의미하는 바는 분명하다.
모델이 강해질수록, 고정된 검색 알고리즘보다 “모델이 직접 검색을 조직하는 구조”가 더 유리해진다.
왜 세 가지 도구를 모두 써야 하나
논문은 각 도구를 하나씩 빼는 방식으로 절제 실험도 수행한다. 핵심 결과만 보면 다음과 같다.
| 변형 | MuSiQue | HotpotQA | 2Wiki |
|---|---|---|---|
| A-RAG (Full) | 74.1 | 94.5 | 89.7 |
| w/o Keyword Search | 72.6 | 93.0 | 88.9 |
| w/o Semantic Search | 69.4 | 93.9 | 89.1 |
| w/o Chunk Read | 73.6 | 93.6 | 89.0 |
이 표는 세 가지를 보여 준다.
첫째, 정확한 표현을 잡는 키워드 검색은 여전히 중요하다.
멀티홉 질문은 종종 인물명, 장소명, 작품명 같은 고정된 표면 형태에 크게 의존한다.
둘째, 의미 검색은 표현이 어긋나는 경우를 메워 준다.
특히 MuSiQue처럼 질문 구성이 복잡한 데이터셋에서 의미 검색을 빼면 하락폭이 더 크게 나타난다.
셋째, chunk_read를 없애고 검색 단계에서 바로 긴 청크를 던져 주는 방식은 손해다.
논문이 강조하는 것은 “필요한 정보만 먼저 보여 주고, 정말 유망한 청크만 전체를 펼쳐 읽게 만드는 점진적 정보 공개”다.
이 구조가 있어야 모델이 읽기 비용과 정보 밀도를 스스로 조절할 수 있다.
더 오래 생각하게 하면 실제로 더 좋아진다
이 논문의 흥미로운 대목은 테스트 타임 스케일링 분석이다.
A-RAG는 모델이 스스로 검색을 조직하기 때문에, 추론 스텝 수를 늘리거나 reasoning effort를 높였을 때 성능이 실제로 따라 올라가는지 확인해 볼 수 있다.

그림 4. MuSiQue-300에서 최대 스텝 수와 reasoning effort를 늘릴수록 성능이 올라간다. 더 강한 모델일수록 긴 탐색에서 이득을 더 크게 가져간다. 원문 Figure 4.
논문에 따르면 MuSiQue-300에서 최대 스텝 수를 5에서 20으로 늘렸을 때 GPT-5-mini는 약 8포인트, GPT-4o-mini는 약 4포인트 정도 개선된다.
reasoning effort를 minimal에서 high로 올렸을 때도 GPT-5-mini와 GPT-5 모두 약 25포인트 안팎의 큰 향상을 보인다.
이 장면은 A-RAG의 핵심을 잘 보여 준다.
기존 RAG는 검색 결과가 거의 고정되어 있기 때문에 “더 오래 생각한다”는 것이 큰 의미를 갖기 어렵다.
반면 A-RAG는 추가 계산량이 곧 추가 탐색과 재계획으로 이어질 수 있는 구조다.
다시 말해, 계산 예산이 실제 행동의 폭으로 연결된다.
성능만 오른 것이 아니라, 읽는 양도 더 효율적이다
겉으로 보면 agentic 시스템은 검색을 더 많이 할 것 같지만,
논문은 반대로 계층형 인터페이스가 있을 때 오히려 더 적은 문맥으로 더 나은 성능을 낼 수 있다고 주장한다.
핵심 수치만 뽑으면 아래와 같다.
숫자는 코퍼스에서 실제로 읽어 온 토큰 수다.
| 방법 | MuSiQue | HotpotQA | 2Wiki |
|---|---|---|---|
| Naive RAG | 5,387 | 5,358 | 5,506 |
| A-RAG (Naive) | 56,360 | 27,455 | 45,406 |
| A-RAG (Full) | 5,663 | 2,737 | 2,930 |
이 표가 말하는 바는 매우 선명하다.
Agentic하다는 이유만으로 효율적인 것은 아니다.
실제로 A-RAG (Naive)는 문맥을 과하게 읽는 경향을 보인다.
반대로 A-RAG (Full)는 키워드 검색과 의미 검색으로 먼저 단서를 좁히고, 필요한 청크만 전체를 읽기 때문에 토큰 사용량을 크게 통제한다.
특히 HotpotQA와 2Wiki에서는 Naive RAG보다도 더 적은 토큰으로 더 높은 정확도를 낸다.
즉, 이 논문의 진짜 메시지는 “Agentic RAG가 좋다”에서 끝나지 않는다.
더 정확히 말하면, 잘 설계된 계층형 인터페이스를 가진 Agentic RAG가 좋다는 것이다.
남아 있는 실패는 무엇인가
논문은 MuSiQue의 오답 100개를 직접 살펴보고 실패 유형을 분류한다.
흥미로운 점은, 실패의 중심이 단순한 검색 실패에서 추론 사슬의 오류로 이동한다는 것이다.

그림 5. MuSiQue 기준 A-RAG의 주요 실패는 문서를 못 찾는 문제가 아니라, 찾은 정보를 잘못 연결하는 문제에 가깝다. 원문 Figure 5.
MuSiQue에서 A-RAG의 오답 중 82%는 reasoning chain error로 분류된다.
그 안을 다시 보면 entity confusion이 40%, wrong strategy가 28%, question misunderstanding이 22%, budget 초과가 10%다.
이 해석은 꽤 중요하다.
기존 Naive RAG에서는 “필요한 문서를 못 찾았다”가 주된 병목이었다면, A-RAG에서는 “문서는 찾았지만 그 문서를 잘못 엮었다”가 더 큰 병목이 된다.
즉, 문서 접근 인터페이스가 좋아질수록 남는 문제는 검색보다 추론 자체가 된다.
앞으로의 개선 포인트가 어디인지도 이 분석이 보여 준다.
이 논문을 어떻게 봐야 하나
이 논문이 강하게 설득력 있는 이유는 세 가지다.
첫째, 주장이 시대 변화와 맞아 있다.
언어모델의 진짜 강점이 길게 생각하고 도구를 다루는 쪽으로 이동하고 있는데, RAG도 그 방향에 맞춰 설계가 바뀌어야 한다는 문제의식이 자연스럽다.
둘째, 방법이 복잡하지 않다.
거대한 그래프를 새로 만들기보다, 모델이 접근할 수 있는 인터페이스를 잘 나누는 데 초점을 맞춘다. 그래서 아이디어의 전달력이 좋고, 후속 연구도 붙기 쉽다.
셋째, “더 강한 모델일수록 더 이득을 본다”는 점을 실험으로 보여 준다.
단순히 작은 모델에서만 통하는 요령이 아니라, 추론형 모델의 발전과 함께 같이 커질 수 있는 방향이라는 뜻이다.
반면 한계도 분명하다.
논문은 아직 preprint 단계이고, 도구 조합을 아주 폭넓게 탐색한 것은 아니다.
더 큰 모델, 더 다양한 지식 집약형 작업, 더 긴 문서 환경에서 얼마나 안정적으로 일반화되는지는 후속 검증이 필요하다.
또 실패 분석을 보면, 인터페이스가 좋아져도 결국 마지막 승부는 정확한 추론과 개체 식별에서 난다.
검색을 잘하게 만드는 것과, 찾은 근거를 올바르게 연결하게 만드는 것은 서로 다른 문제다.
정리
A-RAG는 RAG를 “문서를 붙여 넣는 보조 장치”에서 “모델이 외부 지식을 능동적으로 탐색하는 상호작용 시스템”으로 다시 보게 만든다. 이 논문이 제안하는 새로움은 거대한 알고리즘보다 계층형 인터페이스 설계에 있다. 정확한 표현을 찾는 검색, 의미를 따라가는 검색, 필요한 문맥을 펼쳐 읽는 읽기 도구를 분리해 두면, 모델은 질문에 맞춰 전략을 바꾸고, 더 적은 문맥으로 더 높은 정확도를 낼 수 있다.
이 논문이 남기는 가장 중요한 문장은 아마 이것에 가깝다. 앞으로의 RAG 성능은 무엇을 얼마나 잘 검색하느냐뿐 아니라, 모델이 지식에 어떻게 접근하도록 허용하느냐에 의해 결정된다.
'AI 생성 글 정리 > agent' 카테고리의 다른 글
| Enhancing Retrieval-Augmented Generation: A Study of Best Practices 논문 정리 (0) | 2026.04.07 |
|---|---|
| Multi-agent Architecture Search via Agentic Supernet 정리 (0) | 2026.04.07 |
| Online SFT for LLM Reasoning - 보상 없이도 되는 Self-Tuning 정리 (0) | 2026.04.06 |
| ChatDev 논문 정리 (0) | 2026.04.06 |
| LongRAG 논문 정리 (0) | 2026.04.06 |