RAGSearch: 에이전트 검색 시대에도 GraphRAG가 필요한가¶

• 논문: Do We Still Need GraphRAG? Benchmarking RAG and GraphRAG for Agentic Search Systems
• 저자: Dongzhe Fan, Zheyi Xue, Siyuan Liu, Qiaoyu Tan (NYU Shanghai, 4명)
• arXiv: 2604.09666 [cs.IR], 2026-04-01 제출, v1
• 코드: FanDongzhe123/RAGSearch
• 실험 환경: Qwen2.5 3B·7B·32B Instruct, 그래프 구축은 GPT-4o-mini, A100 80GB 2장. QA 6종 전체 테스트(또는 dev) 세트
• 읽은 날짜: 2026-09-28
• 태그: #GraphRAG #AgenticSearch #Benchmark #HippoRAG2 #MultiHopQA #GRPO

한 줄 요약¶

에이전트가 여러 번 검색하며 근거를 이어 붙이면 dense RAG가 좋아지긴 하지만, 멀티홉 질의에서는 GraphRAG와의 격차가 거의 줄지 않는다. 일반 사실형 질의는 dense RAG로 충분하다. 다만 이 결론은 Contain-EM 한 지표와, 두 백엔드가 서로 다른 코퍼스를 검색했을 가능성 위에 서 있다.

읽는 방식¶

원문 목차를 그대로 따라간다. 절 번호와 제목이 원문과 같다. 마지막 세 절만 읽는 쪽에서 덧붙인 것이다.

1. Introduction¶

RAG와 GraphRAG는 대부분 한 번 검색해서 고정된 문서 묶음을 넘기는 방식으로 설계됐다. 한편 Search-o1, Search-R1 같은 에이전트 검색은 추론 중간 상태를 보고 질의를 고쳐 가며 여러 번 검색한다.

저자들은 구조를 세 층위로 나눈다.

그래서 묻는다. 에이전트 검색이 dense RAG에 없는 그래프 구조를 대신할 수 있는가, 아니면 GraphRAG가 여전히 필요한가.

기존 비교가 답을 못 준 이유로 세 가지를 든다. 평가 프로토콜이 제각각이고, 테스트셋 일부만 쓰며, 에이전트의 검색 횟수와 토큰 예산을 맞추지 않았다. 또 GraphRAG를 끝단까지 한 덩어리 시스템으로 평가해서, 다른 추론 방식에 갈아 끼울 수 있는 검색 백엔드로 보지 않았다.

기여는 셋이다.

• 통합 벤치마크 RAGSearch: 데이터셋, 백본, 검색 예산, 평가 프로토콜을 통일
• 학습 없는 에이전트와 RL 에이전트 모두를 dense RAG 하나와 GraphRAG 다섯 종 위에서 실행
• 정확도 외 지표: 오프라인 구축 비용, 온라인 추론 효율, 안정성

2. Related Work¶

• RAG 기반 추론: 학습 없는 방식(Chain-of-Verification, ARise)과 학습 방식(Open-RAG, KBLaM, RAFT)으로 나뉜다
• GraphRAG: MS GraphRAG(커뮤니티 요약), RAPTOR(재귀 요약 트리), HippoRAG2(엔티티 그래프 + Personalized PageRank), HyperGraphRAG(하이퍼엣지로 n항 관계), LinearRAG(관계 추출 없이 엔티티와 의미 연결만으로 만든 Tri-Graph)
• 에이전트 검색: Search-o1(추론 중 필요할 때 검색, 검색 결과를 요약해 넣는 Reason-in-Documents), GraphSearch(텍스트 청크와 그래프를 함께 조회하는 다단계 검색), Search-R1(RL로 멀티턴 검색 학습), Graph-R1(Search-R1을 GraphRAG로 확장)

3. Preliminary¶

세 방식을 식으로 구분한다.

LLM 단독      y ~ M(q)
RAG          y ~ M(q, C_q),   C_q = R(q | K)        검색 1회, 문맥 고정
GraphRAG     y ~ M(q, Z_q),   Z_q ⊆ G = (V, E)      부분그래프 1회, 문맥 고정
에이전트 검색  검색이 디코딩 중에 반복된다

RAG와 GraphRAG는 검색 결과가 디코딩 전에 정해진다는 점에서 같다. 이 논문이 보는 것은 검색이 디코딩 안으로 들어왔을 때 둘의 차이가 어떻게 바뀌느냐다.

4. RAGSearch Benchmark¶

4.1 General Agentic Search Formulation¶

ReAct 형태의 루프로 추상화한다.

<think> ... </think>          검색할지, 답할지 결정
<search> q_t </search>        검색 질의
<information> I_t </information>   백엔드 B가 돌려준 청크 또는 부분그래프
... 반복 ...
<answer> ... </answer>

핵심은 두 성질이다. 검색이 추론 중에 동적으로 일어나고, 같은 에이전트 제어 로직이 다른 검색 백엔드 위에서 그대로 돈다. 그래서 에이전트와 백엔드를 떼어 조합별로 비교할 수 있다.

4.2 Training-Free Agentic Search Pipelines¶

학습 없는 파이프라인을 두 부류로 나눈다.

GraphSearch 쪽은 질의를 하위 질의로 쪼개고(Query Decomposition), 모은 근거로 추론 사슬을 만든 뒤(Logic Drafting), 근거가 충분하고 일관적인지 검증해 모자라면 하위 질의를 늘린다(Evidence Verification).

두 방법은 같은 틀의 다른 인스턴스이고, 차이는 검색 환경뿐이라는 것이 저자들의 관점이다. dense 환경은 텍스트 청크를, GraphRAG 환경은 그래프 근거를 돌려준다.

4.3 RL-Based Agentic Search Training¶

Search-R1과 Graph-R1을 따라 에이전트 검색을 RL 문제로 둔다. 정책 π_θ가 궤적을 만들고, 종료 후 궤적 전체에 스칼라 보상 하나를 준다.

• 알고리즘: GRPO. 질의마다 궤적 K개를 뽑아 그룹 안에서 보상을 정규화한 상대 이점으로 쓰고, 참조 정책과의 KL로 업데이트를 묶는다. 가치 함수를 따로 학습하지 않는다
• 보상: 정답 보상(EM 등) + 형식 보상. dense와 GraphRAG 환경에 같은 보상을 쓴다. 학습된 행동 차이가 보상 설계가 아니라 백엔드에서 온다는 것을 보장하려는 장치다

4.4 Retrieval Backends in RAGSearch¶

모든 GraphRAG 백엔드는 백엔드별 에이전트 수정 없이 같은 상호작용 프로토콜로 접근한다.

벤치마크 전체 구조를 그리면 다음과 같다. 에이전트 4종 중 하나와 백엔드 6종 중 하나를 골라 조합한다.

flowchart TB
  Q(["질의"]) --> AG

  subgraph AG["에이전트 (추론 제어)"]
    direction LR
    subgraph TF["학습 없음 · Qwen2.5 7B/32B"]
      SO1["Search-o1<br/>필요할 때 검색 + 검색 결과 요약"]
      GS["GraphSearch<br/>질의 분해 → 검색 → 검증"]
    end
    subgraph RL["GRPO 학습 · Qwen2.5 3B/7B"]
      SR1["Search-R1"]
      GR1["Graph-R1"]
    end
  end

  AG <-->|"#lt;search#gt; 질의 ⇄ #lt;information#gt; 근거<br/>top-5 · 최대 5턴(RL)"| IF["공통 검색 인터페이스"]

  subgraph BE["검색 백엔드"]
    direction LR
    D["dense RAG<br/>청크 + 유사도"]
    subgraph GR["GraphRAG · 사전 구축"]
      T1["트리: MS GraphRAG · RAPTOR"]
      T2["엔티티 그래프: HippoRAG2"]
      T3["하이퍼그래프: HyperGraphRAG"]
      T4["Tri-Graph: LinearRAG"]
    end
  end

  IF --> D
  IF --> GR
  AG --> A(["#lt;answer#gt;"])

  classDef agent fill:#eef3fb,stroke:#2a78d6,color:#0b0b0b
  classDef dense fill:#f4f3f0,stroke:#8a8984,color:#0b0b0b
  classDef gnode fill:#eef3fb,stroke:#1c5cab,color:#0b0b0b
  class SO1,GS,SR1,GR1 agent
  class D dense
  class T1,T2,T3,T4 gnode

5. Experiments¶

연구 질문은 다섯이다. RQ1 에이전트 검색이 그래프 구조 부재를 메우는가, RQ2 학습 없는 에이전트에서도 그래프가 이득인가, RQ3 RL과 백엔드는 어떻게 상호작용하는가, RQ4 안정성은 어떤가, RQ5 모듈별 영향은 어떤가.

5.1 Experimental Setup¶

RL 학습에 쓴 NQ와 HotpotQA가 도메인 내(†), 나머지 넷이 도메인 밖(★)이다.

5.2 Overall Comparison (RQ1)¶

Table 1 (Contain-EM, 7B). GraphRAG 행은 다섯 백엔드 중 각 데이터셋 최고값이다.

관찰 1. 단일 검색에서 dense RAG는 일반 QA에 이미 충분하고, GraphRAG의 이득은 멀티홉에 몰린다. 일반 QA 평균 이득 +0.47, 멀티홉 평균 이득 +27.23.

관찰 2. 학습 없는 에이전트가 dense RAG를 끌어올리는 폭은 에이전트 설계에 달렸다. Search-o1은 dense RAG를 오히려 떨어뜨린 곳이 있다(NQ 46.62 → 38.20, Musique 20.99 → 12.62). GraphSearch는 Musique를 빼고 크게 올린다. 저자들은 멀티홉 평균 격차가 27.23에서 26.59로 줄었다고 쓴다.

같은 표로 에이전트별 격차를 따로 계산하면 그림과 같다. 26.59는 Search-o1과 GraphSearch 격차의 평균이다. 가장 강한 에이전트인 GraphSearch에서는 격차가 오히려 벌어진다.

관찰 3. RL은 대응하는 학습 없는 기준선보다 낫지만, 잘 짠 학습 없는 워크플로를 넘지는 못한다. GraphSearch 계열이 Search-R1과 Graph-R1을 대부분 앞선다. 질의 분해와 구조화된 검색이라는 설계가 RL 최적화보다 크게 작용한다는 것이다.

정리하면 멀티홉에서는 GraphRAG가 가장 강하고 안정적이며, 일반 QA에서는 에이전트 검색과 GraphRAG의 이득이 모두 작다(저자 표기 +2.43 대 멀티홉 +26.25). 구축 비용을 생각하면 일반 QA는 잘 설계한 에이전트 + dense RAG가 현실적 선택이다.

5.3 Training-free Agentic Workflow (RQ2)¶

에이전트는 고정하고 백엔드만 바꾼 결과다(Table 2, Contain-EM, 7B).

아래 표는 그림과 같은 수치다.

관찰 4. 학습 없는 에이전트에서도 멀티홉은 그래프가 일관되게 이긴다. 멀티홉 평균 순위에서 dense는 두 에이전트 모두 꼴찌다. 반면 일반 QA에서는 dense가 여러 GraphRAG보다 낫다(Search-o1에서 평균 순위 2위). 엔티티 중심의 HippoRAG2가 두 에이전트, 두 과제 유형 모두에서 1위다. MS GraphRAG와 RAPTOR처럼 요약 트리 계열은 중위권이다.

5.4 RL-based Search Agent (RQ3)¶

Figure 3에 백엔드별 RL 결과를 그림으로만 싣는다(텍스트 추출본에 수치 없음).

관찰 5. RL 에이전트 성능은 백엔드에 크게 좌우되고, 그래프 백엔드가 멀티홉에서 더 큰 이득을 준다. HippoRAG2가 HotpotQA, PopQA, 2Wiki에서 가장 높다. 엔티티 수준 그래프 신호가 RL이 활용하기 좋다는 해석이다. 일반 QA에서는 dense가 비슷하거나 낫고, NQ에서는 dense가 최고다.

5.5 Sensitivity Analysis¶

견고성 (Table 3, RQ4). 검색 턴 수, 재현율(recall), Contain-EM 평균±편차다.

관찰 6. 검색 깊이는 비슷한데 GraphRAG 쪽이 재현율이 높고 편차가 작다. 멀티턴 검색에서 근거를 더 안정적으로 찾는다는 것이다. 에이전트가 평균 2턴 안팎만 검색한다는 점도 눈여겨볼 만하다.

RL 알고리즘 (Figure 4, RQ5). GRPO를 다른 RL 알고리즘과 같은 조건에서 비교한다. 관찰 7. GRPO가 dense와 GraphRAG 모두에서 가장 낫다. 비교 대상 알고리즘 이름과 수치는 그림에만 있다.

백본 크기 (Table 4·5, RQ5).

관찰 8. 백본이 클수록 GraphRAG와 dense의 격차가 줄어든다. RL은 3B → 7B에서 평균 격차 14.70 → 9.75, 학습 없는 설정은 7B → 32B에서 7.80 → 7.19. 강한 LLM이 추론으로 암묵적 구조를 더 잘 만든다는 해석이다. 다만 Musique 격차는 32B에서 오히려 커졌다(19.82 → 23.42).

6. Conclusions¶

에이전트 검색은 반복 검색과 추론으로 dense RAG에 없는 구조를 일부 메우지만, 견고한 멀티홉 추론에는 명시적 그래프 검색이 여전히 중요하다. dense RAG는 구축 비용이 낮아 일반 QA에서 실용적인 선택으로 남는다.

저자들의 더 큰 주장은 에이전트 추론이 구조를 대체하는 게 아니라 구조가 생기는 위치를 옮긴다는 것이다. 일부 구조가 오프라인 그래프 구축에서 온라인 상호작용으로 넘어간다. 둘 사이의 균형을 이해하는 것이 다음 세대 RAG 설계의 열쇠라고 맺는다.

Appendix (발췌)¶

F1 결과 (Table 7)¶

저자들은 "F1에서도 에이전트가 멀티홉 격차를 좁히고 일반 QA는 dense가 경쟁력 있다"고만 쓴다. GraphSearch의 F1이 한 자릿수라는 점은 언급하지 않는다. 이 의미는 아래 "읽을 때 감안할 것"에 정리했다.

구축 비용 (Table 8, NQ 기준)¶

비용은 GPT-4o-mini 기준이다. LinearRAG는 LLM으로 관계를 추출하지 않아 비용이 0이다. 성능 1위인 HippoRAG2가 비용으로도 두 번째로 싸고, MS GraphRAG는 가장 비싸면서 컨텍스트를 가장 많이 쓴다.

사례 (Table 9)¶

"Laleli 모스크와 Esma Sultan 저택은 같은 동네에 있는가?"(정답: 아니오)를 Qwen2.5-7B 단독, Search-o1 Dense, Search-R1, Graph-R1 HippoRAG2로 비교한 생성 과정을 싣는다.

구현 메모¶

Search-o1은 원래 Bing 웹 검색을 부르도록 되어 있다. 이 실험에서는 검색 질의를 가로채 로컬 검색 서버로 보내고, 결과를 웹 검색 결과처럼 꾸며 돌려줬다. 원래 추론 모델용인 Search-o1을 비추론 모델(Qwen2.5 Instruct)로 돌리기 위해 질문 앞에 "You should think step by step to solve it."을 붙였다.

읽을 때 감안할 것¶

• dense와 GraphRAG가 같은 코퍼스를 검색했는지 불분명하다. 5.1.2절은 dense의 지식원을 2018 위키백과 덤프라고 하고, 부록 B는 GraphRAG에 대해 "각 질문의 context를 문서로 쓴다"고 한다. HotpotQA의 질문별 context는 정답 근거 문단과 방해 문단 10개 정도다. 글자 그대로라면 GraphRAG는 정답 근거가 들어 있는 작은 묶음을, dense는 위키백과 전체를 검색한 것이 된다. 그렇다면 단일 검색 멀티홉 격차 +27은 그래프 구조가 아니라 코퍼스 차이에서 올 수 있다. 코드로는 확인하지 못했다.
• Contain-EM은 장황한 답에 유리하다. 정답 문자열이 응답 어딘가에 들어 있기만 하면 맞힌 것으로 센다. GraphSearch는 Contain-EM으로 가장 높은데(NQ 58~61) F1은 4~14다. 답을 길게 늘어놓아 정답이 우연히 포함된 것일 가능성이 크다. 단일 검색 GraphRAG도 NQ Contain-EM은 dense보다 1.7 높은데 F1은 11.4 낮다. "GraphSearch가 RL을 이긴다"는 관찰 3은 F1로 보면 뒤집힌다.
• "격차가 줄었다"는 수치가 사실상 제자리다. 26.59는 Search-o1 격차(21.6)와 GraphSearch 격차(31.6)의 평균이다. GraphSearch 하나만 보면 격차는 단일 검색의 27.23보다 오히려 커졌다. 같은 문장의 "두 번째로 좋은 GraphRAG 대비 32.3% 감소"와 5.2절의 "+2.43 대 +26.25"는 표에서 재현하지 못했다.
• 표끼리 수치가 어긋난다. 같은 7B 설정인데 Search-R1이 Table 1에서 NQ 48.72, Musique 14.42, Table 4에서 46.35, 12.35다. Graph-R1 HotpotQA도 53.42 대 51.75다. Search-o1 Dense PopQA는 Table 1이 25.57, Table 2가 25.78이다(25.57은 Table 2의 HyperGraphRAG 값). 관찰 5는 PopQA를 멀티홉 결과처럼 서술한다.
• Search-o1을 원래 조건에서 돌리지 않았다. 추론 모델용 방법을 Qwen2.5 Instruct에 CoT 한 줄 붙여 돌렸다. Search-o1 Dense가 단일 검색보다 낮게 나온 것(관찰 2)은 방법의 한계라기보다 이 설정 탓일 수 있다. 반대로 GraphSearch는 원래 GraphRAG용으로 설계된 방법이라 dense 변형은 저자들이 옮긴 것이다.
• 인용 혼선. 2절은 GraphSearch를 [22]로 인용하는데, [22]는 제1·4저자가 참여한 다른 논문(그래프 학습용 GraphSearch, arXiv:2601.08621)이다. 실험에 쓴 것은 [34] Yang et al.(arXiv:2509.22009)이다. 또 ACM 템플릿 문구("Generate the Correct Terms for Your Paper", ©2018)가 그대로 남은 초고 상태다.
• 지식원이 위키백과 하나다. 모든 데이터셋이 위키백과 기반 공개 QA다. 엔티티와 관계가 이미 정리된 도메인 그래프(사내 자산, 권한 구조 등)에서 같은 결론이 나온다는 근거는 없다. RL은 HotpotQA와 NQ로만 학습했으니 나머지 넷은 일반화 성능이 섞여 있다.
• 그림으로만 나온 결과가 있다. RQ3(Figure 3)와 GRPO 비교(Figure 4)는 수치 표가 없어 텍스트 추출본으로는 확인하지 못했다.

가져갈 지점¶

1. 질의 유형부터 가른다

이 논문에서 가장 튼튼한 결과는 "일반 QA는 dense, 멀티홉은 그래프"라는 분업이다. 지표와 에이전트를 바꿔도 이 방향은 유지된다. GraphRAG를 도입할지 따지기 전에 실제 질의 중 멀티홉 비율을 먼저 재는 편이 낫다. 단일 사실형이 대부분이면 그래프 구축비를 정당화하기 어렵다. LogicRAG 노트의 "그래프를 미리 만들 필요 없다"는 주장과는 멀티홉에서 정면으로 부딪힌다.

1. GraphRAG 중에서는 엔티티 그래프가 비용 대비 가장 낫다

HippoRAG2는 성능 1위이면서 구축비 $2.85로 두 번째로 싸다. MS GraphRAG는 $13.19에 컨텍스트 22K 토큰을 쓰고도 중위권이다. 커뮤니티 요약 방식은 전역 요약 질의(Global Search)에 강점이 있지만 이 벤치마크에는 그런 질의가 없다는 점은 감안해야 한다. Microsoft GraphRAG 해부의 인덱싱 8단계가 어디서 돈을 쓰는지 이 표와 함께 보면 된다.

1. 에이전트 설계가 RL보다 먼저다

Contain-EM 기준으로 질의 분해와 검증이 들어간 학습 없는 워크플로가 RL 에이전트를 앞선다. F1 문제를 감안하더라도, 같은 백본에서 Search-o1과 GraphSearch의 차이(dense NQ 38 대 58)가 백엔드 차이보다 크다. RL 학습을 고려하기 전에 분해 → 검색 → 검증 루프부터 갖추는 순서가 맞다.

1. 평가 지표를 두 개 이상 본다

Contain-EM과 F1이 방향까지 뒤집히는 사례다. 에이전트는 답을 길게 쓰는 경향이 있어 포함 여부만 보는 지표가 특히 부풀려진다. 에이전트 평가에는 포함 지표 + 토큰 F1 + 응답 길이를 함께 기록한다.

1. 백엔드를 갈아 끼울 수 있게 인터페이스를 고정한다

<search>로 질의를 내고 <information>으로 받는 단일 인터페이스 덕에 에이전트 4종 × 백엔드 6종을 조합할 수 있었다. 자체 시스템에서도 검색 백엔드를 이 형태로 감싸 두면 dense와 그래프를 같은 에이전트로 A/B 비교할 수 있다.

결론¶

제목의 질문에 대한 답은 "멀티홉이면 아직 필요하다"이고, 이 방향 자체는 지표를 바꿔도 유지된다. 하지만 격차의 크기(+27)는 코퍼스 비대칭 가능성과 Contain-EM의 관대함 때문에 그대로 인용하기 어렵다. "에이전트가 격차를 좁힌다"는 부제격 주장은 표로 보면 거의 성립하지 않는다.

실무에 가져갈 것은 수치보다 세 가지다. 질의 유형을 먼저 재고, 그래프를 만들 거라면 엔티티 그래프(HippoRAG2 계열)부터 보고, 비용표(Table 8)를 구축 결정의 기준선으로 쓴다. 특히 비용표는 저장소의 GraphRAG 정리들이 비워 둔 "얼마나 드는가"에 처음으로 수치를 준다.