GraphOmakase

25년 12월 1주차 그래프 오마카세

admin

— 9 min read

In-depth Analysis of Graph-based RAG in a Unified Framework

In-depth Analysis of Graph-based RAG in a Unified Framework
Graph-based Retrieval-Augmented Generation (RAG) has proven effective in integrating external knowledge into large language models (LLMs), improving their factual accuracy, adaptability, interpretability, and trustworthiness. A number of graph-based RAG methods have been proposed in the literature. However, these methods have not been systematically and comprehensively compared under the same experimental settings. In this paper, we first summarize a unified framework to incorporate all graph-based RAG methods from a high-level perspective. We then extensively compare representative graph-based RAG methods over a range of questing-answering (QA) datasets -- from specific questions to abstract questions -- and examine the effectiveness of all methods, providing a thorough analysis of graph-based RAG approaches. As a byproduct of our experimental analysis, we are also able to identify new variants of the graph-based RAG methods over specific QA and abstract QA tasks respectively, by combining existing techniques, which outperform the state-of-the-art methods. Finally, based on these findings, we offer promising research opportunities. We believe that a deeper understanding of the behavior of existing methods can provide new valuable insights for future research.
arXiv.orgYingli Zhou
  • RAG의 한계를 뛰어넘기 위해 수많은 기업이 GraphRAG 도입을 서두르고 있습니다. 그만큼 GraphRAG의 최근 인식은 지식 그래프를 어떻게 잘 연결하여 (마법처럼) LLM에게 더 똑똑한 지능을 부여할 수 있는 정교한 프롬프팅을 기대하게 만들고 있습니다.
  • 하지만 살짝 과장된 부분을 걷어내면, 실제 현장에서의 GraphRAG 도입 현실은 꽤 냉정한 것 같습니다. GraphRAG는 단순히 LLM에게 '여기 이런 그래프를 참고해!' 라고 지시하는 수준으로 완성되지 않습니다. 오히려 기존보다 훨씬 정교한 데이터 설계와 파이프라인 엔지니어링이 뒷받침되지 않으면, 비용만 높고 속도는 느린 시스템이 되기 십상입니다.
    • 최근 관련 연구는 실제 병목 현상은 데이터를 모델링하고 , 저장하고 , 인덱스를 생성하고, 탐색하는 방식에 있다는 치밀한 설계의 승부라는 사실을 강조했습니다. 즉, 고성능 GraphRAG 시스템을 구분지을 수 있는 것은 모델이 아니라 그 안에 숨겨진 데이터 엔지니어링입니다.
  • 위 논문에서는 GraphRAG를 둘러싼 일종의 환상을 걷어내기 위해, 엔지니어링 관점에서 복잡하게 얽힌 GraphRAG 방법론을 하나로 꿰뚫는 설계 파이프라인와, 실제 구축 시 마주하게 될 데이터 엔지니어링의 현실적 어려움들을 고려하여 성공적인 GraphRAG 시스템 도입을 위한 큰 Blueprint를 제시합니다.
    • 이번 주 오마카세에서는 해당 논문을 통해 쏟아지는 GraphRAG 방법론들 속에서 핵심을 잡고, 데이터 엔지니어가 Production level의 파이프라인을 구축하기 위해 현실적으로 어떤 부분들을 고려해야 하며, 어떤 기술적 난제들을 해결해야 하는지에 대해 정리하여 독자 여러분들께 전달해드리고자 합니다.
  • 표준화된 4단계 파이프라인을 아래와 같이 정의합니다.
    • Graph Building (구축) : "문서에서 어떻게 그래프를 만드는가?" >> 텍스트를 청크(Chunk)로 나누고 노드와 엣지를 추출하여 기초적인 그래프 구조를 형성합니다. 여기서 어떤 그래프 유형을 택하느냐가 성능을 좌우합니다.
    • Index Construction (인덱싱) : "데이터를 어떻게 저장하고 인덱싱하는가?" >> 구축된 그래프를 벡터/그래프 DB에 적재합니다. (* Rich KG 같은 복잡한 그래프는 인덱싱 단계에서 토큰 비용이 급증함을 주의)
    • Operator Configuration (연산자 설정): "어떤 검색 알고리즘을 사용하는가?" >> 질문 유형에 따라 '이웃 노드만 볼지(1-hop)', '경로를 따라갈지(Path)', '서브그래프 전체를 긁어올지' 결정합니다.
    • Retrieval & Generation (검색 및 생성): "최종적으로 어떻게 답변을 생성하는가?" >> 최적화된 경로로 지식을 추출해 LLM에 주입합니다.
  • 저자들은 그래프 구축 과정의 유형을 5가지로 분류하고 이에 따른 트레이드오프를 심도 있게 분석했습니다. 단순히 "어떤 구조가 모델의 성능을 향상시키는가?"뿐만 아니라, "토큰 비용 대비 효율이 어떤가?"에 대해서도 밝혔습니다.
    • Passage Graph / Tree: 문서 구조를 그대로 본뜬 단순 형태(저비용). 구조가 단순함에도 불구하고 비용 효율적인 성능을 보임.
    • Knowledge Graph (KG): 엔티티-관계 중심 (사실 관계 정확). 정확도는 높지만 희소성 문제가 존재합니다.
    • Textual KG / Rich KG: 텍스트 정보가 풍부하게 포함된 그래프 (고성능, 고비용). 정보량이 많아 성능은 최고(SOTA) 수준이지만, 토큰 비용(Cost)이 매우 높습니다.
      • 사용자의 예산과 요구사항에 맞는 적절한 그래프 유형 선택 기준을 마련했습니다. (구축 환경 및 예산 등이 한정적이라면 Passage Graph, 최고 성능이 필요하다면 Rich KG를 선택하는 전략)
  • 많은 데이터 엔지니어들이 오해하는 부분으로, GraphRAG를 단순히 "프롬프트를 잘 짜서 그래프를 검색하는 기술"이라는 생각을 지적합니다. 현업의 관점에서, "GraphRAG 시스템이 실패하는 이유는 모델이 아니라 하부 구조(Substrate)의 엔지니어링 부실 때문"이라고 지적하며 데이터 엔지니어링의 완성도를 강조합니다. 그리고 이에 맞는 구체적인 기술적 과제들을 제시합니다.
    • '모델보다 스키마(Schema)가 먼저!' : 어떤 LLM을 쓰느냐보다, 그래프의 노드와 엣지를 어떻게 정의할지의 스키마 설계가 훨씬 중요합니다. 스키마가 엉성하면 아무리 좋은 모델도 엉뚱한 데이터를 가져오기 때문입니다.
      • 그래프 스키마는 데이터 웨어하우스처럼 설계해야 합니다. 적용하는 환경에 맞추어, Property Graph(유연하고 성능이 좋아 엔터프라이즈 환경에 적합)를 쓸지 혹은 RDF(규정 준수나 데이터 상호운용성이 중요할 때 유리)를 쓸지 등 신중하게 정해야 합니다. 해당 선택이 이후의 인덱싱 전략과 검색 파이프라인 전체를 결정함을 강조합니다.
    • 데이터 동기화(Sync)의 지옥 : 원본 문서가 수정되었을 때, 그래프 구조와 벡터 인덱스를 실시간으로 업데이트하는 로직을 구성하는 것은 매우 복잡한 문제입니다. 하지만 이 파이프라인이 없으면 GraphRAG는 일회용 데모에 불과하기 때문에, 데이터의 신선도(Freshness)를 유지하면서 적응형 파이프라인을 구성하는 것이 핵심입니다.
    • '인덱스는 숨겨진 영웅' : 효율적인 시스템을 위해선 아래 3가지 인덱스의 조합이 필요합니다. 그렇지 않으면 매 검색마다 그래프 전체를 뒤지는 참사가 일어날 수 있습니다.
      • Vector Index: 시맨틱 검색용
      • Full-text Index: 키워드 매칭용
      • Graph Index: 인접 관계 탐색용
    • '성능은 DB에서 나온다': 답변의 질은 LLM이 결정하지만, 서비스의 속도와 효율성은 그래프 데이터베이스의 쿼리 최적화, 인덱싱 전략, 캐싱 등 순수한 엔지니어링 영역에서 결정됩니다. 다음 관점에서 GraphRAG 시스템 도입 및 구축 프로젝트의 키플레이어는 숙련된 데이터 엔지니어가 될 것입니다.
  • 저자들이 해당 논문을 통해 전달하고자 하는 메세지는 명확합니다. GraphRAG를 도입하시려면 "LLM을 어떻게 튜닝할까?"보다 "데이터 웨어하우스를 어떻게 설계할까?"라는 마인드로 접근하셔야 한다는 것입니다.
    • 우리 데이터에 맞는 그래프 유형은 무엇인가? (비용 효율적인 Tree 구조 vs 고성능 Rich KG)
    • 데이터 동기화 파이프라인과 하이브리드 인덱싱 전략이 수립되었는가?
    • (분석용 쿼리와는 다른) 검색에 최적화된 그래프 DB 쿼리를 작성하고 있는가?
  • 그리고 '구조적 이해'와 '엔지니어링 역량' 두 가지가 모두 필요할 것입니다.
    • 논문의 4단계 프레임워크를 기준으로 현재 고려 중인 솔루션의 아키텍처를 점검해보기.
    • LLM 프롬프트를 깎기 전에, 데이터 파이프라인(ETL)과 스키마 설계에 시간을 투자하기.
    • 데이터가 변경될 때 그래프를 어떻게 갱신할지 동기화 전략을 미리 세우기.
  • GraphRAG는 더 이상 단순한 마법의 기술로 바라보시면 안될 것 같습니다. 정교한 데이터 엔지니어링 기술을 기반한 튼튼한 데이터 뼈대 위에 LLM을 얹었을 때 더욱 강력한 GraphRAG의 성능을 확인해볼 수 있을 것 같습니다.
  • 실체 없는 유행만 따라가는 것이 아닌, 다음 내용들을 바탕으로 한 독자 여러분들의 성공적인 GraphRAG 도입 전략 수립에 구체적인 도움이 되었기를 바랍니다.

[Contact Info]

Gmail: jhbae1184@akane.waseda.jp

Twitter (X): @jhbae1184

LinkedIn

Read more