GraphRAG 개념과 최근 트렌드

1 GraphRAG의 개념과 최근 트렌드

1.1 들어가며

• GraphRAG를 도입하려는 조직이 가장 먼저 답해야 할 질문은 “왜 GraphRAG를 하려고 하는가?”이다.
• 이 질문에 명확한 답이 없다면, 프로젝트는 높은 확률로 실패한다.
• GraphRAG는 기술적인 문제라기보다는 조직적인 문제이기 때문이다.
• GraphRAG는 단순히 “그래프를 RAG에 적용하는 것”이 아니라, “조직이 그래프를 활용하여 RAG의 검색 단계를 어떻게 개선할 것인가”에 대한 전략적 접근이다.
• GraphRAG에 들어가기 앞서 그와 연관된 선수지식인 “Ontology(온톨로지)”와 “Knowledge Graph(지식 그래프)”에 대한 개념을 먼저 이해하는 것이 중요하다.

1.1.1 Ontology(온톨로지)

• 온톨로지(Ontology)는 실존하는 사물이나 개념들 사이의 관계를 컴퓨터가 이해할 수 있는 형태로 정의한 지식 공유의 체계를 의미한다.
• GraphRAG(Graph Retrieval-Augmented Generation)에서 온톨로지는 데이터의 골격(Schema)이자 추출 가이드라인 역할을 한다.
• 단순한 벡터 검색의 한계를 극복하기 위해 비정형 데이터에서 지식 그래프(Knowledge Graph)를 추출할 때, 어떤 개체(Entity)와 관계(Relation)를 정의할지 결정하는 규범적 틀이 바로 온톨로지이다.

1.1.1.1 근거 및 메커니즘

본래 철학적 존재론에서 유래했으나, 정보과학에서는 특정 도메인 내의 지식을 정형화하기 위해 다음과 같은 구성 요소를 가진다.

• 클래스(Class): 개념의 집합 (예: ‘사람’, ‘과일’)
• 속성(Property): 개념의 특징 (예: ‘나이’, ‘색상’)
• 관계(Relation): 개념 간의 연결 (예: ‘A는 B의 하위 개념이다’)
• 개체(Instance): 구체적인 데이터 (예: ‘홍길동’, ‘사과’)

온톨로지는 단순한 분류(Taxonomy)를 넘어, 데이터 간의 시맨틱(Semantic, 의미론적) 연결성을 제공한다. 이는 \(G = (V, E)\) 형태의 그래프 구조로 정형화될 수 있으며, 여기서 \(V\) 는 개념(Nodes), \(E\) 는 관계(Edges)를 나타낸다.

GraphRAG의 핵심은 텍스트 청크 간의 단순 유사도가 아닌, 데이터 내에 숨겨진 구조적 연결성을 활용하는 것이다. 이 과정에서 온톨로지는 다음과 같은 메커니즘으로 작동한다.

1. 데이터 모델링 (Schema Definition): \(G = (V, E)\) 구조를 생성할 때, 노드(\(V\))의 타입(예: Person, Organization, Concept)과 엣지(\(E\))의 타입(예: works_at, related_to)을 사전에 정의한다.
2. 지식 추출 (Information Extraction): LLM이 비정형 텍스트에서 트리플(Triple, \(Subject-Predicate-Object\))을 추출할 때, 온톨로지는 추출해야 할 정보의 범위를 제한하여 노이즈를 줄이고 데이터의 일관성을 보장한다.
3. 추론 및 군집화 (Inference & Community Detection): 온톨로지 기반으로 구축된 그래프 위에서 Leiden 알고리즘 등을 활용해 커뮤니티를 요약(Summary)할 때, 계층적 온톨로지 구조는 상위 개념과 하위 개념 간의 논리적 요약을 가능하게 한다.

1.1.1.2 한계점

• 구축 비용: 도메인 전문가의 개입이 필수적이며, 자동화된 생성이 어렵다.
• 유연성 부족: 지식 체계가 고정되면 새로운 개념이나 변화하는 데이터 구조를 반영하기 위해 전체 스키마를 수정해야 하는 오버헤드가 발생한다.
• 불확실성: 현재 생성형 AI 기술의 발전으로 인해 정교하게 설계된 온톨로지의 필요성이 줄어들고 있다는 견해와, 환각(Hallucination) 방지를 위해 여전히 심볼릭(Symbolic)한 지식 체계가 필수적이라는 견해가 공존한다. 학계와 실무에서는 “도메인 특화된 정교한 온톨로지가 GraphRAG의 성능을 결정짓는가” 아니면 “LLM의 추론 능력만으로 충분한가”에 대한 논의가 진행 중이며, 통계적으로 유의미한 성능 차이를 입증하기 위한 벤치마크 데이터셋이 아직 부족한 상태이다.

1.1.1.3 대안

엄격한 온톨로지 대신 스키마리스(Schema-less) 접근이나 LLM의 임베딩(Embedding)을 통해 의미적 유사성을 파악하는 방식이 실무에서 더 널리 쓰인다. 특히 비정형 데이터 처리 시에는 벡터 공간에서의 거리 측정(Cosine Similarity 등)이 더 효율적일 수 있다.

최근 Microsoft의 GraphRAG 구현체처럼 ‘동적 온톨로지(Dynamic Ontology)’ 방식이 선호된다. 이는 고정된 온톨로지를 강요하기보다, LLM이 데이터의 맥락을 보고 적절한 개체와 관계를 스스로 생성(Zero-shot Extraction)하게 한 뒤 사후적으로 정제하는 방식이다.

1.1.1.4 온톨로지에서 지식 그래프로

• 온톨로지가 “무엇을 표현할 것인가”에 대한 설계도라면, 지식 그래프는 “실제로 표현된 데이터”이다.
• 이 관계는 다음과 같이 비유할 수 있다:
  • 온톨로지 = 건축 설계도 (“건물에는 방, 복도, 계단이 있어야 한다”)
  • 지식 그래프 = 실제 건물 (“3층 301호에는 회의실이 있고, 복도로 302호 사무실과 연결된다”)
• 온톨로지는 클래스(Class), 속성(Property), 관계(Relation)를 정의하지만, 구체적인 데이터는 담지 않는다.
• 지식 그래프는 온톨로지가 정의한 규칙에 따라 개체(Instance), 속성값(Attribute Value), 관계 인스턴스(Relationship Instance)를 저장한다.
• 예를 들어 의료 도메인에서:
  • 온톨로지: “환자는 질병을 가질 수 있으며, 약물로 치료된다”
  • 지식 그래프: “(환자:홍길동)-[진단받음]->(질병:당뇨병)-[치료됨]->(약물:메트포민)”
• GraphRAG에서 두 개념의 역할은 명확히 구분된다:
  • 온톨로지: LLM이 문서에서 엔티티와 관계를 추출할 때 “무엇을 찾아야 하는지”를 지시
  • 지식 그래프: 추출된 정보를 저장하고, 질의 시점에 “어떤 경로를 탐색할지”를 결정하는 실제 데이터 구조

1.1.2 Knowledge Graph란 무엇인가

• 지식 그래프(Knowledge Graph)는 엔티티(Entity)와 그들 간의 관계(Relationship)를 노드(Node)와 엣지(Edge)로 표현하는 그래프 형태의 데이터 구조이다.
  • 엔티티: 데이터베이스나 정보 시스템에서 데이터로 관리하고자 하는 현실 세계의 개체 또는 개념
    • 관계형 DB
      • 대상: Entity logical in ERD = Table physical in RDBMS
      • 속성: Attribute logical in ERD = Column physical in RDBMS
      • 개체: Instance logical in ERD = Row physical in RDBMS
    • 지식 그래프: 엔티티 = 그래프의 한 노드(Node)
      • 속성: 엔티티의 특징을 나타내는 값 (예: 이름, 나이)
  • 관계: 엔티티 간의 상호작용이나 연관성을 나타내는 연결 고리
    • 관계: 노드 간의 연결(엣지, Edge) (예: “김철수” -[근무함]-> “삼성전자”)

1.1.2.1 지식 그래프의 특징과 현황

• 많은 업무 유형에 비표준화된 형태로 적용된다. 예를 들어, 데이터 모델링에서 업무기술서를 바탕으로 conceptual data model을 설계할 때, ERD(Entity-Relationship Diagram) 대신 지식 그래프 형태로 표현하는 경우가 종종 관찰된다.
• 이 접근법의 핵심은 “데이터 간의 연결”을 1급 객체(first-class citizen)로 취급한다는 점이다.
• 지식 그래프의 장점:
  1. 유연한 스키마: 관계형 데이터베이스처럼 미리 테이블 구조를 정의할 필요 없이, 필요에 따라 새로운 엔티티 타입과 관계를 추가할 수 있다. 예를 들어 “회사” 노드에 갑자기 “설립일” 속성을 추가하더라도 전체 스키마를 재설계할 필요가 없다.
  2. 명시적 관계 표현: SQL의 JOIN 연산으로 간접적으로 표현되던 관계를 엣지로 직접 모델링한다. “(김철수)-[근무함 {since: 2020}]->(삼성전자)”처럼 관계 자체에도 속성을 부여할 수 있어, “언제부터 근무했는가”같은 컨텍스트 정보를 자연스럽게 담는다.
  3. 다단계 추론(Multi-hop Reasoning): “김철수가 근무하는 회사가 생산한 제품은?”같은 질문을 단일 쿼리로 처리할 수 있다. 그래프 구조를 따라 “(김철수)-[근무함]->(삼성전자)-[생산함]->(갤럭시S24)”처럼 경로를 탐색하면 된다.
  4. 이질적 데이터 통합: 사람, 회사, 제품, 이벤트, 개념 등 서로 다른 타입의 엔티티를 하나의 그래프에 자연스럽게 공존시킬 수 있다. 관계형 DB에서는 각각 별도 테이블로 관리되던 것들이 지식 그래프에서는 연결된 하나의 네트워크를 형성한다.
  5. 프로젝트 초기에 기획 및 설계가 용이하다: ERD 이전에 개념적 관계를 설정하기 위해 시각적으로 관계를 표현할 수 있어, 도메인 전문가와 개발자 간의 커뮤니케이션이 원활하다.
• 지식 그래프의 한계:
  • 구축과 유지 비용이 높다: 형식이 자유롭고 유연한 스키마를 그릴 수 있는 대신 프로그래밍과 같은 물리적 재현물을 구현하는데 부족함이 많다. 특히, 온톨로지(엔티티와 관계의 체계) 설계에 도메인 전문가의 깊은 개입이 필요하다. 또한 표준화가 덜 되어 있어, 조직마다 다른 방식으로 구현하는 경향이 있다. 관계형 데이터베이스의 ERD처럼 “누구나 이해하는 공통 언어”로 자리잡지는 못했다.

온톨로지와 지식 그래프의 구축 방식: * 온톨로지 없이도 지식 그래프를 만들 수 있지만, 데이터의 일관성과 재사용성이 떨어진다. * 실무에서는 다음 두 가지 접근법이 공존한다: - Top-down 방식: 도메인 전문가가 온톨로지를 먼저 설계 → 데이터를 그래프로 변환 - Bottom-up 방식: 데이터에서 패턴을 추출 → 사후적으로 온톨로지를 정리 * GraphRAG에서는 두 방식을 하이브리드로 사용하는 경우가 많다. 예를 들어 의료 도메인에서는 “환자”, “질병”, “치료법” 같은 핵심 엔티티는 온톨로지로 정의하고, 새로운 관계는 LLM이 자동으로 발견하게 한다. * 주요 표준과 구현 방식: 1. RDF/RDFS (W3C 표준): - Subject-Predicate-Object 트리플 구조 - 시맨틱 웹(Semantic Web) 커뮤니티에서 주로 사용 - 예: <삼성전자> <생산함> <갤럭시S24> 2. OWL (Web Ontology Language): - 온톨로지 정의를 위한 표준 - 학계와 바이오인포매틱스 분야에서 활용 - 추론 규칙을 명시적으로 정의 가능 3. Property Graph: - Neo4j, ArangoDB 등 상용 그래프 DB의 사실상 표준 - 노드와 엣지에 속성(key-value) 추가 가능 - 산업계에서 가장 많이 사용 4. GraphQL: - 그래프 쿼리를 위한 API 표준 (저장 방식이 아님) - Facebook(Meta)이 개발, 현재 널리 사용

1.1.2.2 지식 그래프의 실무적 가치

성공 사례: - Google Knowledge Graph: 검색 결과의 우측 정보 패널 제공 - Amazon Product Graph: 상품 추천 및 검색 개선 - Netflix Content Graph: 콘텐츠 간 관계 기반 추천 - LinkedIn Economic Graph: 직무, 기업, 인재 연결

적용이 효과적인 도메인: - 관계가 데이터의 핵심인 경우 (소셜 네트워크, 공급망) - Multi-hop 추론이 필요한 경우 (의료 진단, 금융 사기 탐지) - 데이터 스키마가 자주 변경되는 경우 (스타트업, 연구 프로젝트)

한계: - ERD처럼 “당연히 사용하는” 수준의 범용성은 없음 - 구축 비용이 높음 (온톨로지 설계, 데이터 변환) - 팀 역량에 따라 성패가 크게 갈림

1.1.2.3 GraphRAG와의 관계

┌────────────────────────────────────────┐
│     RAG (검색 증강 생성) 프레임워크       │
│                                        │
│  ┌──────────────┐    ┌──────────────┐ │
│  │  Retriever   │ →  │  Generator   │ │
│  │  (검색기)    │    │  (LLM)        │ │
│  └──────────────┘    └──────────────┘ │
│         ↓                             │
│   [검색 대상 선택]                      │
│   ├─ 벡터 DB    → Vector RAG           │
│   ├─ 지식 그래프 → GraphRAG    ← 여기 !  │
│   └─ 하이브리드  → Hybrid RAG           │
└────────────────────────────────────────┘

관계 정리: - 지식 그래프 = 데이터를 표현하고 저장하는 방식 (자료구조) - RAG = 외부 지식을 활용하는 시스템 아키텍처 (프레임워크) - GraphRAG = 지식 그래프를 RAG의 검색 단계에 활용하는 구현 방식

1.2 GraphRAG란 무엇인가

• GraphRAG는 Retrieval-Augmented Generation(RAG)에 지식 그래프(Knowledge Graph)를 결합한 접근 방식이다.
  • 전통적인 RAG 시스템이 벡터 유사도 검색만으로 관련 문서를 검색하는 반면, GraphRAG는 엔티티(Entity) 간의 관계(Relationship)를 명시적으로 모델링한 그래프 구조를 활용하여 더 정교한 검색과 다단계(Multi-hop) 추론을 수행한다.

1.2.1 벡터 RAG의 한계의 구체적 사례

사용자가 “보험 비교추천서비스를 운영하는 핀테크 기업 중 자동차보험 상품을 취급하는 곳은?”이라고 질문했다고 가정하자.

벡터 검색 방식에서는: - “보험”, “핀테크”, “자동차보험”이라는 단어들의 의미적 유사도만으로 문서를 찾는다 - 문서에 이 단어들이 많이 등장하면 관련도가 높다고 판단한다 - 하지만 “누가 무엇을 운영하는가”, “어떤 기업이 어떤 상품을 취급하는가”라는 관계 정보는 제대로 파악하지 못한다

그러나 이 질문은 실제로: - 3개의 엔티티: (1) 핀테크 기업, (2) 보험 비교추천서비스, (3) 자동차보험 상품 - 2개의 관계: (1) 기업 -(운영)→ 서비스, (2) 기업 -(취급)→ 상품 으로 구성된 구조화된 정보 요청이다.

GraphRAG는 바로 이러한 관계 정보를 명시적으로 모델링하여 정확한 답변을 제공한다.

“관계를 더 강화”보다는 “관계를 명시적으로 표현하여 활용”이라고 하는 것이 더 정확

1.2.2 RAG vs GraphRAG: 핵심 차이점

Vector RAG (전통적 RAG): - 검색 대상: 텍스트 청크(chunk)를 벡터로 변환한 임베딩 - 검색 방식: 질의를 벡터로 변환 후, 코사인 유사도 같은 거리 함수로 유사한 텍스트 찾기 - 처리 단위: 명사구, 문장, 문단 등 텍스트 조각 - 강점: 의미적 유사도 포착, 구현이 간단, 빠른 검색 - 약점: 엔티티 간 관계를 파악하지 못함, Multi-hop 추론 불가

예시:

질의: "삼성전자가 만든 스마트폰은?"
Vector RAG 동작:
1. "삼성전자", "만든", "스마트폰" 단어의 의미 벡터 생성
2. 벡터 DB에서 유사한 텍스트 검색
   → "삼성전자는 가전제품을 생산합니다" (유사도: 0.82)
   → "갤럭시S24는 최신 스마트폰입니다" (유사도: 0.79)
3. LLM에 두 문서를 제공하고 답변 생성
   → 명시적인 연결 없이 LLM이 추론해야 함

GraphRAG: - 검색 대상: 엔티티(노드)와 관계(엣지)로 구성된 지식 그래프 - 검색 방식: 질의에서 엔티티 추출 → 그래프에서 연결된 노드 탐색 - 처리 단위: 엔티티 간 관계와 경로(path) - 강점: 관계를 명시적으로 표현, Multi-hop 추론 가능, 구조적 정보 활용 - 약점: 그래프 구축 비용 높음, 엔티티 추출 정확도에 의존

예시:

질의: "삼성전자가 만든 스마트폰은?"
GraphRAG 동작:
1. 질의에서 엔티티 추출: [삼성전자], [스마트폰]
2. 그래프에서 관련 경로 탐색:
   (삼성전자:Company)-[생산함]->(갤럭시S24:Product)
   (갤럭시S24:Product)-[속함]->(스마트폰:Category)
3. 서브그래프를 LLM에 제공
   → 명시적 관계 정보로 정확한 답변 생성
   → "삼성전자가 생산하는 스마트폰은 갤럭시S24입니다"

핵심 차이 요약:

측면	Vector RAG	GraphRAG
정보 표현	텍스트 → 벡터 (암묵적)	엔티티 + 관계 (명시적)
검색 기준	의미적 유사도	구조적 연결성
관계 인식	텍스트에 암묵적으로 포함	엣지로 명시적 표현
Multi-hop	여러 번 검색 필요	한 번에 경로 탐색
구축 비용	낮음 (자동 임베딩)	높음 (온톨로지 설계)

1.2.3 GraphRAG의 동작 과정

GraphRAG는 다음과 같은 방식으로 동작한다: 1. 자연어 질의를 입력받는다 2. Knowledge Graph에서 관련 서브그래프를 검색한다 3. 검색된 노드(Node)와 엣지(Edge)의 특징(Features)을 추출한다 4. GNN Encoder를 통해 그래프 구조를 벡터로 인코딩한다 (Soft prompting) 5. 또는 그래프 구조를 텍스트로 변환한다 (Hard prompting) 6. 원본 질의를 LLM Encoder로 인코딩한 벡터와 결합한다 7. 최종적으로 LLM Decoder가 두 벡터를 종합하여 자연어 답변을 생성한다

1.2.4 Hard prompting vs Soft prompting: GraphRAG의 핵심 구현 전략

• 그래프 정보를 LLM에 전달하는 방식은 크게 두 가지로 나뉜다.
• 이 선택은 시스템의 성능, 비용, 구현 복잡도를 결정하는 가장 중요한 아키텍처 결정이다.

1.2.4.1 Hard prompting (Graph-to-text) 방식

• 동작 원리: 그래프의 노드와 엣지를 직접 텍스트로 변환하여 LLM의 컨텍스트에 포함
• 예시: “(핀테크기업A)-[운영]->(보험비교추천서비스)-[취급]->(자동차보험상품)”
• 장점:
  • 구현이 직관적이고 디버깅이 쉽다
  • LLM이 관계를 명시적으로 이해할 수 있다
  • 기존 LLM을 그대로 사용 가능 (별도 학습 불필요)
• 단점:
  • 그래프가 커지면 토큰 수가 급격히 증가 (비용 증가)
  • LLM의 컨텍스트 윈도우 제한에 걸린다 (128K 토큰 초과 시 잘림)
  • 복잡한 그래프는 텍스트로 표현하기 어렵다

1.2.4.2 Soft prompting (Graph-to-token) 방식

• 동작 원리: GNN(Graph Neural Network)으로 그래프 구조를 인코딩하여 임베딩 벡터로 변환 후 LLM 입력으로 주입
• 장점:
  • 그래프의 구조적 정보를 압축된 벡터로 표현 (토큰 효율성 높음)
  • 대규모 그래프도 고정된 크기의 벡터로 표현 가능
  • 그래프의 위상 구조(topology)를 보존
• 단점:
  • GNN 인코더를 따로 학습해야 함 (데이터와 시간 필요)
  • 구현 복잡도가 높고 디버깅이 어렵다
  • LLM이 그래프 정보를 “이해”하는지 해석하기 어렵다

실무적 선택 기준: - 그래프 규모가 작고(<1000 노드) 빠른 프로토타이핑이 필요하면 Hard prompting - 그래프 규모가 크고(>10000 노드) 운영 비용이 중요하면 Soft prompting - 많은 경우 두 방식을 하이브리드로 사용하여 장점을 결합

1.3 2024-2025년 GraphRAG 연구 트렌드

• GraphRAG는 2024년 들어 폭발적으로 연구가 진행되었다.
• 특히 Microsoft Research가 2024년 4월 GraphRAG 논문을 발표한 이후,
• 대학 연구실과 기업 연구소에서 경쟁적으로 개선 방법론을 제안하고 있다.

1.3.1 왜 이 시기에 GraphRAG가 주목받는가?

1. LLM의 컨텍스트 윈도우 확장: GPT-4의 128K 토큰, Claude의 200K (책 2~300페이지 분량) 토큰 지원으로 긴 그래프 구조를 텍스트로 전달 가능
2. 벡터 검색의 한계 인식: Multi-hop 추론, 관계 기반 질의에서 벡터 검색만으로는 정확도 한계
3. 그래프 데이터베이스 성숙: Neo4j, TigerGraph 등 그래프 DB의 성능 향상과 클라우드 서비스 보편화
4. GNN 기술 발전: Graph Transformer, Heterogeneous GNN 등 그래프 인코딩 기술 성숙

1.3.2 주요 연구 동향과 발전 과정

주요 마일스톤을 시간순으로 정리하면 다음과 같다. 각 연구는 이전 연구의 특정 문제점을 해결하는 방향으로 발전했다.

• 2024년 4월 - Microsoft GraphRAG (Hard-prompting)
  • Microsoft Research가 발표한 초기 GraphRAG는 GraphRAG의 개념을 대중화시킨 기폭제였다.
  • 핵심 아이디어:
    • 문서에서 LLM으로 엔티티(Entity)와 관계(Relationship)를 자동 추출
    • 추출된 정보로 지식 그래프를 구축
    • 질의 시점에 관련 서브그래프를 텍스트로 변환하여 LLM 컨텍스트에 제공
  • 해결한 문제: 기존 벡터 검색의 “관계 인식 부재” 문제
  • 남은 문제: 대규모 그래프에서 관련 서브그래프를 어떻게 효율적으로 찾을 것인가?
• 2024년 5월 27일 - G-Retriever (Soft & Hard prompting)
  • 해결한 문제: Microsoft GraphRAG의 “비효율적인 서브그래프 탐색” 문제
  • 핵심 기여:
    • Path Filtering: 그래프에서 무작정 모든 경로를 탐색하지 않고, 질의와 관련성이 높은 경로만 선택적으로 필터링
    • 하이브리드 아키텍처: Soft prompting(GNN 인코딩)과 Hard prompting(텍스트 변환)을 사용 사례에 따라 선택 가능
  • 실무적 의미: 작은 그래프는 Hard, 큰 그래프는 Soft로 처리하여 성능과 비용 최적화
• 2024년 8월 9일 - HybridRAG (Hard-prompting)
  • 해결한 문제: “Graph Only”의 한계 - 그래프 검색만으로는 의미적 유사도를 놓칠 수 있음
  • 핵심 아이디어:
    • 병렬 검색: 벡터 검색과 그래프 검색을 동시에 수행
    • 결과 융합: 두 검색 결과를 reranking 알고리즘으로 통합
      • 벡터 검색 → 의미적으로 유사한 문서 발굴
      • 그래프 검색 → 구조적으로 연결된 정보 발굴
      • Reranking → 두 결과의 교집합과 합집합을 고려한 최적 순위 결정
  • 실무적 의미: 현실적으로 가장 많이 사용되는 아키텍처로, “벡터 vs 그래프” 논쟁을 “벡터 + 그래프”로 해결
• 2024년 9월 9일 - GraphRAG Auto-tuning (Hard-prompting)
  • Microsoft GraphRAG의 개선 버전으로, 프롬프트와 그래프 스키마를 자동으로 튜닝하는 기능이 추가되었다.
  • 사용자가 수동으로 엔티티 타입과 관계 타입을 정의하지 않아도, 문서 샘플을 분석하여 자동으로 온톨로지를 제안한다.
• 2024년 9월 13일 - G-Retrieval Module
  • G-Retriever의 검색 모듈을 독립적으로 사용할 수 있도록 모듈화한 버전이다.
  • 다양한 RAG 파이프라인에 플러그인 형태로 통합할 수 있다.
• 2024년 11월 7일 - LightRAG (Hard-prompting)
  • 해결한 문제: 질의 유형에 따른 검색 전략 최적화
  • 핵심 기여:
    • Keyword + Entity 동시 추출: 단순히 엔티티만 추출하는 것이 아니라, 키워드 기반 검색과 결합
    • Global vs Local Search 구분:
      • Global Search: 전체 그래프의 요약 정보를 활용 (“최근 AI 트렌드는?”)
      • Local Search: 특정 엔티티 주변만 탐색 (“GPT-4의 파라미터 수는?”)
  • 왜 이것이 중요한가?
    • 모든 질의를 그래프 전체에서 검색하면 비효율적이다.
    • 질의 분류기(Query Classifier)로 질의 유형을 먼저 판단하고, 적합한 검색 전략을 선택하면 속도와 정확도가 동시에 향상된다.
• 2024년 11월 15일 - GraphRAG Dynamic Community Selection (Hard-prompting)
  • 해결한 문제: 대규모 그래프에서 관련 정보를 빠르게 찾는 방법
  • 핵심 아이디어:
    • 커뮤니티 탐지: Louvain, Label Propagation 같은 알고리즘으로 그래프를 클러스터(커뮤니티)로 분할
    • 커뮤니티 요약: 각 커뮤니티의 핵심 내용을 LLM으로 미리 요약
    • 동적 선택: 질의가 들어오면 관련 커뮤니티만 선택하여 검색
  • 예시:
    • 학술 논문 그래프에서 “딥러닝” 커뮤니티, “강화학습” 커뮤니티, “컴퓨터 비전” 커뮤니티로 분할하고,
    • “트랜스포머 모델 설명”이라는 질의가 들어오면 “딥러닝” 커뮤니티만 검색
  • 실무적 의미: 검색 범위를 줄여 응답 속도를 10배 이상 향상시킬 수 있음
• 2024년 11월 25일 - LazyGraphRAG (Hard-prompting)
  • LazyGraphRAG는 그래프 구축을 사전에 완료하는 대신, 질의 시점에 on-demand로 필요한 부분만 그래프를 확장하는 방식이다.
  • 초기 구축 비용은 낮지만, 질의 응답 지연시간(latency)이 증가하는 trade-off가 있다.
• 2025년 2월 3일 - GFM-RAG (Graph Foundation Model)
  • GFM-RAG는 그래프 자체를 사전학습한 Foundation Model을 활용한다. 텍스트 기반 LLM처럼, 대규모 그래프 데이터로 사전학습된 그래프 인코더를 사용하여 도메인 특화 그래프에도 빠르게 적응할 수 있다.
• 2025년 2월 18일 - PathRAG (Hard-prompting)
  • PathRAG는 엔티티 간의 경로(path)를 명시적으로 추출하고, 경로의 의미를 기반으로 필터링하는 방식이다.
  • 예를 들어 “(인물A)-[공저]->(논문B)-[인용]->(논문C)-[공저]->(인물D)”와 같은 경로에서, “공저-인용-공저”라는 패턴이 학술적 영향력을 나타낸다는 것을 학습한다.

1.4 GraphRAG 파이프라인의 전체 구조

• 성공적인 GraphRAG 구축을 위해서는 전략(Strategy) → 데이터 검증(Data Qualification) → 데이터 구축(Data Build) → 인프라(Infrastructure) → 처리(Processing) → 배포(Deployment)의 6개 레이어를 체계적으로 설계해야 한다.
• 각 레이어는 순차적 의존관계를 가지므로, 상위 레이어의 결정이 잘못되면 하위 레이어를 모두 다시 작성해야 한다.
• 따라서 “위에서 아래로, 천천히, 확실하게” 진행하는 것이 핵심이다.

1.4.1 레이어 1: Strategy (전략 수립) - “왜”를 명확히 하라

• 가장 상위 레이어는 Graph Strategy Planning이다.
• 강조하는 핵심 메시지: “GraphRAG를 하기 전에, 왜 하려는지부터 명확히 하라”
• 이 단계에서 반드시 답해야 할 질문들:
  1. 현재 RAG 파이프라인의 문제가 무엇인가? (What)
     • 답변 정확도가 낮은가? → 측정 가능한 지표(F1 score, BLEU 등)로 정량화
     • Multi-hop 질문에 실패하는가? → 실패 케이스 수집 및 패턴 분석
     • 특정 도메인의 질의 성능이 낮은가? → 도메인별 성능 비교
  2. 왜 GraphRAG가 그 문제를 해결할 수 있는가? (Why)
     • “벡터 검색만으로는 관계 정보를 찾을 수 없다” → 구체적 실패 사례 제시
     • “엔티티 간 연결이 중요한 도메인이다” → 그래프 구조의 필요성 입증
  3. 언제 GraphRAG를 도입할 것인가? (When)
     • 데이터 품질이 충분한가?
     • 팀에 그래프 기술 역량이 있는가?
     • 예산과 일정이 확보되었는가?

도메인 특성에 따른 그래프 설계 차이:

도메인	핵심 엔티티	핵심 관계	그래프 특징
E-commerce	상품, 사용자, 카테고리	구매함, 속함, 유사함	밀집 그래프, 추천 중심
Legal	법조항, 판례, 용어	인용함, 관련됨, 정의함	계층 그래프, 추론 중심
Manufacturing	부품, 공정, 장비	사용됨, 선행됨, 대체됨	방향 그래프, 의존성 중심
Healthcare	질병, 약물, 증상	치료함, 유발함, 금기됨	이질 그래프, 안전성 중심

실무 조언: * 이 단계에서 최소 2주 이상의 토론 시간을 확보하라. * 가장 흔한 실패요인: “빨리 구현하려다가 전략을 깊이 고민하지 않았기 때문” * 예를 들어 E-commerce 도메인이라면 (상품)-(카테고리)-(브랜드)-(구매자)와 같은 관계가 핵심이지만, Legal 도메인이라면 (법조항)-(판례)-(법률용어)-(관련조항) 같은 구조가 필요하다. 이 선택을 잘못하면 이후 모든 단계가 의미 없어진다.

1.4.2 레이어 2: Data Qualification (데이터 품질 확보) - “쓸 수 있는 데이터인가”를 검증하라

• 전략이 수립되었다면, 다음 질문은 “우리 데이터가 GraphRAG를 구축할 품질인가?”이다.
• 다른 실패 원인 중 하나는 “데이터 품질 검증 없이 바로 그래프 구축을 시작했다”는 것이었다.
• 이 단계에서는 최소한 두 가지 병렬 작업이 진행되어야 한다:
  • 작업 1: 메타데이터 및 스키마 검토
    • 기존 데이터베이스의 구조를 분석하여 “그래프로 변환 가능한 관계 정보가 이미 존재하는가”를 확인한다.
    • Data Schema 분석:
      • 관계형 DB의 Foreign Key 관계 → 그래프의 Edge로 직접 변환 가능
      • 스타 스키마(Star Schema) → Fact 테이블을 중심으로 Dimension 테이블 연결
      • 눈송이 스키마(Snowflake Schema) → 정규화된 테이블들의 계층 관계 보존
    • Golden Dataset 확인:
      • 도메인 전문가가 검증한 “정답 데이터”가 있는가?
      • Entity Resolution(동일 엔티티 통합)을 위한 기준 데이터가 있는가?
  • 작업 2: 기존 쿼리 로그 분석
    • 현재 시스템의 쿼리 로그를 분석하여 “GraphRAG가 실제로 필요한가”를 정량적으로 입증한다.
    • 분석 질문들:
      • 어떤 질문에서 답변 품질(F1 score, 사용자 만족도)이 낮은가?
      • Multi-hop 추론이 필요한 질문의 비율은? (전체 쿼리의 20% 이상이면 GraphRAG 고려)
      • 특정 엔티티 관련 질문의 실패율은?
    • LLM + Human Labeler 협업:
      • LLM으로 쿼리를 자동 분류 (단순 검색 / 관계 추론 / Multi-hop 질의)
      • Human Labeler가 샘플링하여 LLM 분류 결과를 검증
      • Schema Matching: 쿼리에 등장하는 엔티티와 DB 스키마의 매핑 관계 정의
    • 체크포인트: 이 단계를 통과하려면 최소한 다음 질문에 “예”라고 답할 수 있어야 한다:
      • 데이터에 명확한 엔티티와 관계가 존재하는가?
      • 쿼리 로그 분석 결과 GraphRAG가 필요함이 정량적으로 입증되는가?
      • 데이터 품질이 그래프 구축에 충분한가? (중복, 누락, 불일치 비율 <10%)

1.4.3 레이어 3: Data Build (그래프 구축)

• Knowledge Graph Build 단계에서는 실제 그래프를 생성한다. 두 가지 주요 방법론이 제시된다:

1. Enterprise-Ontology Construction Method * 기업 내부의 도메인 전문가와 협업하여 온톨로지를 수작업으로 설계하는 방식이다. * 엔티티 타입, 관계 타입, 속성을 명시적으로 정의한다. * 이 방식은 정확도가 높지만 시간과 비용이 많이 든다. * Self-own model(자체 구축 모델)이나 Foundation model(사전학습 모델)을 사용할 수 있다. 2. Knowledge Graph Construction Method * LLM을 활용하여 자동으로 엔티티와 관계를 추출하는 방식이다. * Entity Linking과 Relationship extraction을 동시에 수행한다.

• 그래프 구축 후에는
  • Adjacency matrix(인접 행렬), Edge list(엣지 리스트), Linked list(연결 리스트) 중 어떤 자료구조로 저장할지 결정한다.
  • 이 선택은 후속 단계의 성능에 직접적인 영향을 미친다.
  • Adjacency matrix는 CSR(Compressed Sparse Row), CSC(Compressed Sparse Column), COO(Coordinate List) 포맷으로 압축할 수 있다.

1.4.4 레이어 4: Infrastructure (인프라) - 데이터 관리

• Data Management 단계에서는 그래프 데이터를 어떻게 저장하고 관리할지 결정한다: 1. Graph Layout: 그래프를 메모리에 어떻게 배치할지 결정한다 2. Parallel: 병렬 처리 전략을 수립한다 3. Partitioning: 그래프를 여러 파티션으로 분할하는 전략을 선택한다 (Dynamic vs Static)
• 그래프의 규모와 쿼리 패턴에 따라 Hierarchical(계층적), Vertex(정점 중심), Edge(엣지 중심) 분할 방식 중 하나를 선택한다.
• 또한 Single node(단일 노드)에서 처리할지, Shared memory(공유 메모리)를 사용할지 결정한다.

1.4.5 레이어 4: Infrastructure (인프라) - 데이터베이스 백엔드

• Graph Database Backend 단계에서는 실제 GDBMS(Graph Database Management System)를 선택한다: 1. Graph-aware Hardware: GPU나 TPU를 활용한 그래프 전용 하드웨어 사용 여부 2. Graph-aware Software: Neo4j, ArangoDB, TigerGraph 등 그래프 전문 데이터베이스 선택
• 그래프 처리 방식으로는 Distributed Graph Processing(분산 처리)와 Node Communication(노드 간 통신)을 고려해야 한다.
• 또한 Native(네이티브 그래프 저장소)와 Relational-based(관계형 DB 기반) 중 하나를 선택한다.
• API 방식으로는 Open/Closed(공개/비공개), API vs SaaS(직접 API 호출 vs 관리형 서비스), Cost(비용) 등을 비교한다.

1.4.6 레이어 5: Processing (처리) - GraphRAG 구현

• GraphRAG 단계에서는 실제 검색 로직을 구현한다. 세 가지 주요 구성요소가 있다: 1. LLM 선택: GPT-4, Claude, Gemini 등 어떤 LLM을 사용할지 결정 2. Graph Prompting 방식 선택:
  • Soft Prompting: Knowledge graph embedding과 Heterogeneous graph embedding을 사용하여 그래프를 벡터로 변환
  • Hard Prompting: CoT(Chain-of-Thought)와 IFCoT(Iterative Feedback CoT) 방식을 활용하여 그래프를 텍스트로 변환하고, reranking을 수행하여 다른 RAG 파이프라인과 결합 3. Routing: 질의 유형에 따라 적절한 검색 전략을 선택

1.4.7 레이어 6: Deployment (배포 및 운영)

• Graph CI/CD 단계에서는 GraphRAG 시스템을 지속적으로 개선하고 배포하는 체계를 구축한다:
• Platform 방식: Dependency(의존성 관리) vs Independent(독립 실행)
• Evaluation & Maintenance:
  • Query Latency(쿼리 지연시간), Output Relevance(출력 관련성), Graph Coherence(그래프 일관성) 측정
  • Evaluation metric으로 Multi-hop QA, Common knowledge 등을 사용

1.5 3번의 실패와 1번의 성공

• “GraphRAG 왜 하려고 하시는지 궁금해요!”라는 질문으로 시작한다. 이 질문의 의도는 명확하다. GraphRAG는 단순히 벡터 검색에 그래프를 추가하는 기술적 개선이 아니다.
• 조직의 문제를 해결하기 위한 전략적 선택이며, 그 선택의 동기가 불분명하면 프로젝트는 높은 확률로 실패한다.
• 총 4번의 GraphRAG 구축을 시도했다:
  • 1차 시도: Public Domain: 공개 도메인 데이터(예: Wikipedia, 학술 논문)를 대상으로 GraphRAG를 구축했다. 이 단계에서 부딪힌 주요 문제는 Vector & Graph Infrastructure 선택이었다. 벡터 데이터베이스와 그래프 데이터베이스를 별도로 운영할지, 하나의 시스템에 통합할지 결정해야 했다.
  • 2차 시도: Enterprise Domain: 기업 도메인의 비정형 데이터를 그래프로 변환하는 프로젝트였다. 여기서 발생한 핵심 문제들:
    • Domain to Graph: 도메인 특화 용어와 개념을 어떻게 그래프 노드로 매핑할 것인가?
    • Prompt Engineering: 엔티티 추출 프롬프트를 어떻게 설계할 것인가?
    • Entity Resolution: 동일한 엔티티가 다른 이름으로 여러 번 등장할 때 어떻게 통합할 것인가?
    • Table-based GDBMS: 기존 관계형 데이터베이스를 그래프 데이터베이스로 마이그레이션할 것인가, 아니면 SQL로 그래프 쿼리를 시뮬레이션할 것인가?
  • 3차 시도: Enterprise Document: 기업 내부 문서(계약서, 보고서, 메뉴얼 등)를 그래프로 구조화하는 프로젝트였다. 추가된 도전과제:
    • Vector & Graph: 하이브리드 검색을 어떻게 구현할 것인가?
    • Document to Graph: 문서의 계층 구조(제목, 섹션, 단락)를 그래프로 어떻게 표현할 것인가?
    • Evaluation: GraphRAG의 성능을 어떻게 정량적으로 측정할 것인가?
    • Reranking: 벡터 검색과 그래프 검색 결과를 어떻게 통합하고 순위를 매길 것인가?
    • Ontology: 도메인 온톨로지를 누가, 어떻게 설계할 것인가?
    • Graph CI/CD: 그래프가 지속적으로 업데이트될 때 일관성을 어떻게 유지할 것인가?
  • 4차 시도: Public Domain (팀 협업): 앞선 3번의 실패를 교훈 삼아, 이번에는 다음 요소들을 강화했다:
    • Ontology: 도메인 전문가와 데이터 과학자가 함께 온톨로지를 설계
    • Evaluation: 체계적인 평가 데이터셋과 메트릭을 사전에 정의
    • Graph CI/CD: 자동화된 그래프 업데이트 파이프라인 구축
    • Team collaboration: 크로스펑셔널 팀을 구성하여 각 전문성을 결합
    • 이 4차 시도에서 비로소 성공했다. 핵심 교훈은 “GraphRAG는 기술 문제가 아니라 조직 문제”라는 점이다.