26년 8월 2주차 그래프 오마카세

Is GraphRAG Needed? From Basic RAG to Graph-/Agentic Solutions with Context Optimization

Is GraphRAG Needed? From Basic RAG to Graph-/Agentic Solutions with Context Optimization

Long Chen, Ryan Razkenari, Yuxuan Zhou, Yuan Tian, Rahul Ghosh, Venkatesh Pappakrishnan, Disha Ahuja, Vidya Sagar Ravipati. Proceedings of the Fifth Workshop on Generation, Evaluation and Metrics (GEM). 2026.

ACL Anthology

• 이번 주 오마카세에서는 저번 주의 주제와 비슷한 GraphRAG의 필요성에 대해 의문을 던지고 그 답을 찾아나간 논문을 소개해드리고자 합니다.
• Deep GraphRAG의 어떻게 더 잘 탐색할지, EA-GraphRAG의 라우팅을 통한 언제 그래프를 사용해야 할지를 확인하셨다면, 이 논문에서는 더욱 근본적인 질문을 던졌습니다. GraphRAG가 그래서 정말 필요한 기술인지?

• 문제의식은 명확합니다. GraphRAG, Modular RAG, Agentic RAG 같은 정교한 아키텍처가 계속 등장하고 있지만, 이들이 실제로 의미 있는 성능 향상으로 이어지는지, 그리고 지금 쓰이는 평가 지표(Hit@k, MRR 같은 검색 지표)가 그 차이를 제대로 잡아내는지는 검증된 적이 별로 없습니다. 특히 정밀의료처럼 텍스트와 관계 정보가 함께 있는 반정형 지식베이스에서는 더더욱 그렇습니다.

• 저자들은 문제의식을 검증하기 위해, STaRK-Prime 벤치마크 위에서 전체적인 실험을 진행하였습니다. 다음 벤치마크는 정밀의료 분야의 약 12.9만 개 엔티티와 810만 개 관계를 포함하며, 관계 정보는 PrimeKG를 기반으로 합니다.

시나리오 : Regular RAG (S1-2) – GraphRAG (S3-5) – Agentic RAG (S6-9)

• 비교 대상은 크게 세 그룹, 총 9개 시나리오(Sec 3.2~4 참고)입니다. 그리고 모든 시나리오의 LLM은 Claude 3.7 Sonnet으로 통일했습니다. 즉 어떤 LLM이 더 좋은지를 비교하는 대신, 같은 모델을 놓고 검색 방식과 그래프, 에이전트 구조만 바꿔 성능 차이를 살펴봅니다.

• 논문의 Figure 1은 세 접근법의 차이를 가장 직관적으로 보여줍니다.
  • Regular RAG (Query – 문서 검색 – LLM)는 벡터 유사도로 검색해 LLM에 그대로 전달하며 그래프 순회 없이 텍스트 컨텍스트만으로 답을 구성합니다.
  • GraphRAG (Query → 그래프 순회 → 트리플 검색 → LLM)는 질의와 연결된 엔티티·관계를 지식그래프에서 순회해 트리플 형태로 가져온 뒤 LLM에 전달합니다.
  • Agentic RAG (Query → 도구 선택 → 반복 검색 → LLM)는 에이전트가 상황에 맞는 도구를 스스로 선택하고, 필요하면 반복적으로 검색하며 답을 구성합니다.
• 즉 어떤 형태의 지식을 검색하고 누가 검색 과정을 제어하느냐까지 세 접근의 차이가 달라집니다.

단순한 통합이 정교한 그래프를 이긴다.

• Scenario 2는 엔티티 문서 끝에 1-hop 관계만 관계 유형별로 붙여넣는, 그래프 순회조차 하지 않는 아주 단순한 방식입니다. 반면 Scenario 5는 벡터 검색과 사전 정의된 지식그래프 순회를 결합한 정식 GraphRAG입니다. 
• 결과는 Scenario 2(Hit@1 0.6972)가 Scenario 5(Hit@1 0.6514)를 앞섰습니다. 저자들은 이를 트리플 형식(subject-predicate-object)이 만드는 장황한 컨텍스트와 'lost in the middle' 문제로 설명합니다. 그래프를 쓰더라도 표현 방식과 하이퍼파라미터(홉 수, 경로 수) 설계가 성능을 크게 좌우한다는 뜻입니다.
• 텍스트 설명 없이 사전 정의된 지식그래프만으로 검색·생성하는 baseline GraphRAG(S3)는 Hit@1 0.1376으로 전 시나리오 중 최저를 기록했습니다. 구조화된 관계 정보만으로는 자연어 질의에 답하기 어렵다는, 어찌 보면 당연하지만 수치로 재확인된 결과입니다.

자율 에이전트의 강력함

• 가장 흥미로운 결과는 Scenario 8(문서 검색기 하나만 쥔 자율 에이전트)이 복잡한 전용 도구 없이도 최상위권 성능을 기록했다는 점입니다. Hit@1은 0.6881로 단순 관계 증강 RAG인 Scenario 2(0.6972)에 근소하게 뒤졌지만, MRR은 0.7549로 9개 시나리오 전체 중 가장 높았습니다. 
• 반면 도구를 더 늘리거나(Scenario 7의 쿼리 리포맷터, 문서 검색기, 리랭커), 지식그래프 검색 도구까지 얹어도(Scenario 9) 성능이 일관되게 좋아지지는 않았습니다.
• 복잡한 전용 도구를 더하는 것보다, 최소한의 검색 도구만 둔 채 자율적으로 재질의,평가,종합하도록 하는 구성이 더 높은 MRR을 보였습니다.
• 즉 이번 벤치마크에서는 단순한 relation augmentation과 최소 도구 에이전트가 매우 강한 경쟁력을 보였고, 구조를 복잡하게 만드는 것만으로 성능 향상이 보장되지는 않았습니다.

컨텍스트 최적화

• GraphRAG·Agentic RAG를 실제로 돌려보면 컨텍스트 윈도우 초과가 반복되는 현실적인 문제가 있습니다. 실제로 논문의 Agentic RAG 사례 연구에서는 반복 검색이 이어지며 context window overflow가 여러 차례 발생합니다.
• 저자들은 이를 해결하기 위해 세 가지 최적화를 제안합니다. 
  • 관계-그룹화 표현 : (Entity 1 - Relation - Entity 2) 트리플에서 Relation을 {Relation 1~3} 형태로 묶어 동일한 엔티티 이름이 반복되는 것을 줄입니다.
  • 중복 제거 : 세션 동안 검색된 서브그래프를 하나의 unified subgraph로 유지하면서 entity·relation 수준에서 중복을 제거하고, 문서도 content hash를 이용해 같은 내용이 반복적으로 memory에 들어가는 것을 막습니다.
  • 배치 에이전틱 검색 : 기존 ReAct처럼 매번 하나의 query를 만들고 tool을 호출하는 대신, 여러 complementary sub-query를 한꺼번에 만들어 하나의 retrieval call로 보냅니다. 아래의 알고리즘 1을 참고하면 좋습니다.

• 여기서 중요한 점은 ReAct를 완전히 버린 것이 아니라는 점입니다. 바깥쪽에서는 여전히 Think – Act – Observe – Sufficient 를 반복하지만, 한 번의 Act 안에서 {q1, .. qm}처럼 여러 하위 질의를 미리 계획해 하나의 batched retrieval call로 실행합니다.
• 즉 outer loop에는 ReAct의 반복적 판단을 유지하면서, inner retrieval에는 ReWOO식의 선계획 후 일괄 실행을 결합한 절충 구조라고 볼 수 있겠습니다.

배치 검색의 Trade-off

• 효율만 보면 결과적으로 꽤 좋아보입니다. Scenario 8에서 평균 tool call 수는 4.2회에서 1.8회로 줄었고, retrieval coverage는 오히려 83.8%에서 94.4%로 증가했습니다.
• 하지만 여기에서 문제가 생깁니다. 매 retrieval 이후 결과를 평가하고 다음 query를 좁혀가는 iterative ReAct와 달리, batch 방식에서는 여러 query를 한꺼번에 만들어 보내기 때문에 검색 범위가 더 넓고 추측적으로 변합니다.
• 그 결과 최종 generation 단계에 들어가는 컨텍스트가 커지고, 검색 coverage는 좋아졌는데 Hit@1은 오히려 낮아지는 현상이 나타났습니다. Table 2에서 이 trade-off가 선명하게 나타납니다.
• 여러 설정에서 컨텍스트 최적화는 19–53%의 token reduction (S5 – 49.1K to 23.0K, 53% 감소 & S9 – 466K 새 272K, 42% 감소) 을 달성합니다. 하지만 batch retrieval의 경우 coverage가 올라가더라도 최종 generation 성능이 반드시 함께 올라가지는 않았습니다.
• 즉 검색 효율과 생성 품질은 같은 축이 아니며, 이 최적화의 핵심 가치는 같은 검색을 얼마나 적은 agent round-trip과 memory overhead로 수행할 수 있는가에 있습니다.

Retrieval Generation Gap

• 이 논문에서 가장 중요한 발견 중 하나가 바로 Retrieval Generation Gap입니다.
• Scenario 5-Opt에서 graph retrieval 규모를 키우면서 ground-truth entity coverage는 54.9%에서 83.5%까지 증가했습니다. 그런데 최종 LLM answer 단계의 ground-truth recall은 45.4~48.2% 사이에서 거의 움직이지 않았습니다. 즉, 더 많이 찾아오는 것과 실제 답변에 활용하는 것은 별개의 문제였습니다.
• Appendix C의 별도 분석에서도 프롬프트 안에 존재했던 237개의 정답 엔티티 가운데 LLM이 실제로 추출한 것은 136개, 57.4%에 그쳤습니다. 따라서 retrieval coverage나 raw retrieval ranking만으로 RAG 시스템의 성능을 판단하면 실제 generation 단계에서 얻는 이득을 과대평가할 수 있습니다.

• 이 차이는 엔티티의 프롬프트 내 위치에서도 아주 선명했습니다. LLM이 실제로 선택한 정답 엔티티의 평균 token 위치는 전체 프롬프트의 10.5% 지점이었던 반면, 검색됐지만 LLM이 놓친 정답은 평균 36.8% 지점에 있었습니다. 즉 정답이 검색됐느냐뿐만이 아니라, 그 정답을 LLM에게 어디에, 어떤 형태로 보여줬느냐이기도 합니다.
• Appendix C에서는 이 retrieval-generation gap의 원인을 세 가지로 더 깊게 분석합니다.
  • 위치 편향 (positional attention decay) : 프롬프트 첫 [0–10%] 구간에 등장한 정답 엔티티는 85.5%의 extraction rate를 보였지만, 뒤쪽으로 갈수록 크게 떨어졌습니다. [70–80% , 90–100%] 구간에서는 0%였고, [80–90%] 구간은 20%였습니다.
  • 의미적 현저성 (Semantic Salience) : LLM은 세부적인 specialist subtype보다 더 익숙하고 대표적인 용어를 선택하는 경향을 보였습니다.
  • 질문의 표현 방식 (query-induced cardinality expectations) : 하나의 답을 요구하는 것처럼 보이는 문법적 framing은, 여러 정답 엔티티가 이미 검색되어 있어도 LLM이 하나만 골라 답하도록 만드는 경향을 보였습니다.
• 시나리오 별 각 접근법에 따른 모든 실험 결과를 총정리해보겠습니다.

Regular RAG (S1–S2) — 1-hop 관계만 문서에 붙여도 이번 벤치마크에서는 큰 이득. 구현 난이도 대비 효율 최고.

GraphRAG (S3–S5) — 텍스트 없이 그래프만으로는 부족. 벡터 검색과 결합해야 의미가 있지만, 표현 방식에 따라 단순 RAG에 밀릴 수 있음.

Modular RAG (S6) — 컴포넌트를 단순히 추가한다고 모든 지표가 단조롭게 좋아지지는 않음(리랭커만 추가 시 오히려 Hit@1·MRR 소폭 하락). 다만 쿼리 재구성,검색,리랭킹을 모두 결합한 전체 파이프라인은 강한 성능을 보임.

Agentic RAG (S7–S9) — 도구가 많다고 좋은 게 아님. 최소 도구 + 자율 반복 검색(S8)이 MRR 기준 가장 강력했고, 그래프 도구 추가(S9)는 오히려 여러 지표에서 역효과.

• GraphRAG가 필요한가?라는 근본적인 질문에 대한 이 논문의 답은 "맥락에 따라 다르다"라고 요약합니다.
• 복잡한 다중 관계 질의에서는 그래프가 유용할 여지가 있지만, Stark-prime 벤치마크에서는 1-hop 관계를 문서에 단순히 붙이는 방식만으로도 매우 강한 성능을 보였고, 자율적으로 반복 검색하는 가벼운 에이전트 역시 최상위권 결과를 기록했습니다.
• 즉 그래프 구조 자체보다, 검색된 정보를 LLM이 얼마나 잘 소화하느냐가 병목이라는 메시지가 이 논문의 전체적인 흐름으로 볼 수 있겠습니다.
• 한계도 분명합니다.
  • 실험은 단일 벤치마크와 단일 LLM(Claude 3.7 Sonnet)에 한정되어 있고, 모든 시나리오에 대해 하이퍼파라미터를 exhaustive하게 튜닝하지도 않았습니다. Limitation에서단일 LLM만 사용했기 때문에 다른 모델에서는 시나리오 간 상대 순위가 달라질 수 있다고 명시합니다
  • 따라서 다른 도메인이나 다른 모델에서도 같은 순위가 나올지는 이 논문만으로 확정하기 어렵다는 generalizability의 한계가 존재함을 참고해두시면 좋을 것 같습니다.
• 이전 오마카세와 이번 오마카세를 통해 GraphRAG에 대해 '그렇다면 왜 이걸 사용하는거지?' 라는 생각이 드실 수 있습니다. 이 논문에서도 결론에서 GraphRAG는 불필요하다가 아니라 맥락에 따라 다르다(context-dependent)고 정리합니다.
• 즉 GraphRAG는 안써야겠다 라는 결론으로 받아들이시는 것 보다는 내가 왜 그래프를 쓰려고 하는가를 다시 점검하는 체크리스트로 읽는 편이 더 유용합니다. 
  • 실제로 여러 홉의 관계 추론이 필요한 질의가 대부분인지, 아니면 1-hop 관계 정보만으로도 충분히 해결되는 단순 질의가 대부분인지부터 먼저 확인할 필요가 있습니다. 그다음에야 GraphRAG나 Agentic RAG를 선택하는 방향이 맞습니다.
  • 즉 지금 해결하려는 문제가 지연시간인지, 토큰 비용인지, 다중 홉 추론 실패인지 등을 정의하고, 깊게 탐구한 후에 그 문제에 맞춰 적합한 그래프 구조, 컨텍스트 표현, 에이전트 설계를 선택해야 합니다.
• 결국 중요한 건 어떤 정보를 어떤 형태로 압축해 LLM 앞에 놓을 것인지, 그리고 우리가 그래프로 풀고자 하는 문제가 무엇인지가 더 결정적일 수 있다는 점이 위 논문에서 새롭게 얻어갈 수 있는 인사이트입니다.

Reference

• Agentic RAG survey : https://arxiv.org/abs/2501.09136
• 벤치마크 데이터셋 (Stark prime) : https://github.com/snap-stanford/stark
• 컨텍스트 관리, lost in the middle : https://arxiv.org/abs/2307.03172

[Contact Info]

Gmail: jhbae1184@akane.waseda.jp

Twitter (X): @jhbae1184

LinkedIn