서론 (Introduction)

"Graph RAG는 일반적으로 오프라인에서 글로벌 그래프를 미리 구축한 다음, 쿼리 시점에 PageRank를 사용하여 점수를 매기고 확장합니다. 하지만 PageRank에는 감쇠(decay) 현상이 있습니다. 체인이 길어질수록 점수가 낮아집니다. SAG는 대신 쿼리 시점에 SQL JOIN을 사용하여 확장합니다. 감쇠도 없고, 미리 구축된 글로벌 그래프도 필요 없습니다."

이 글은 Open Source Project of the Day 시리즈의 #116번째 기사입니다. 오늘의 프로젝트는 SAG (Structured Agentic Graph)로, arXiv 논문(2606.15971)을 기반으로 하는 Zleap-AI의 차세대 오픈 소스 멀티홉 (Multi-hop) RAG 프레임워크입니다.

멀티홉 (Multi-hop) 검색의 핵심 과제는 일부 질문이 여러 개의 분리된 문서 구절로부터 정보를 체인처럼 연결해야 한다는 점입니다. 표준 벡터 검색 (Vector retrieval)은 의미적으로 유사한 청크 (Chunk)를 찾아내지만, "의미적으로 유사하다"는 것이 "다단계 추론 (Multi-step reasoning)이 필요한 질문에 답할 수 있다"는 것을 의미하지는 않습니다. GraphRAG와 HippoRAG는 지식 그래프 (Knowledge graphs)를 통해 이를 해결하지만, 두 가지 비용이 발생합니다: 비용이 많이 드는 오프라인 글로벌 그래프 구축, 그리고 긴 체인에서 발생하는 PageRank 점수 감쇠 (Decay)입니다.

SAG는 다른 경로를 택합니다: 미리 구축된 글로벌 그래프 없이, 쿼리 시점에 그래프 구조 확장을 위해 SQL JOIN을 사용합니다. 각 청크 (Chunk)는 하나의 "이벤트 (Event)"(의미적 요약)와 엔티티 (Entities) 세트를 생성합니다. 이벤트와 엔티티 간의 관계는 관계형 데이터베이스 (Relational database)의 외래 키 (Foreign keys)를 통해 표현됩니다. 멀티홉 (Multi-hop) 확장은 단순한 JOIN 연산일 뿐입니다. 즉, 결정론적이며(deterministic), 추적 가능하고, 감쇠가 없습니다.

학습 내용

• SAG의 핵심 데이터 모델: 청크 (Chunk) → 이벤트 (Event) + 엔티티 (Entities)의 설계 로직
• 3단계 쿼리 프로세스: 시드 검색 (Seed retrieval) → SQL 확장 (SQL expansion) → 이중 경로 최종 선택 (Dual-path final selection)
• 왜 SQL JOIN이 긴 체인의 멀티홉 (Multi-hop)에서 PageRank보다 성능이 우수한지
• HippoRAG 2 및 GraphRAG와의 비교: 강점과 약점
• MCP 통합: 각 SAG 프로젝트를 에이전트 호출 가능한 도구 (Tool)로 노출하기
• 풀스택 구현: TypeScript + PostgreSQL + pgvector + React

선수 학습 요구사항 (Prerequisites)

• RAG 및 멀티홉 (Multi-hop) 검색 기초에 대한 익숙함
• 지식 그래프 (Knowledge graphs) (노드, 엣지, 멀티홉 추론)에 대한 기본 이해
• SQL JOIN 개념에 대한 익숙함

프로젝트 배경 (Project Background)

SAG란 무엇인가?

SAG (Structured Agentic Graph)는 지식을 이벤트-엔티티 그래프 (event-entity graph) 구조로 조직화하고, SQL JOIN을 통해 멀티홉 검색 (multi-hop retrieval)을 수행하며, 특히 에이전트 워크플로우 (agent workflows)를 위해 설계된 문서 검색 시스템입니다.

"Structured (구조화된)"는 비정형 문서를 구조화된 이벤트 + 엔티티 (event + entity) 표현으로 변환함을 의미합니다. "Agentic (에이전트 중심의)"는 각 SAG 프로젝트가 에이전트 도구 엔드포인트 (agent tool endpoint)로 노출될 수 있는 내장형 MCP 서버를 갖추고 있음을 의미합니다. "Graph (그래프)"는 SQL JOIN을 통한 쿼리 시점의 그래프 탐색 (graph traversal)을 의미합니다.

저자 / 팀

• 조직 (Organization): Zleap-AI
• 웹사이트 (Website): zleap.com
• arXiv: 2606.15971
• 라이선스 (License): MIT
• 벤치마크 리포지토리 (Benchmark repo): Zleap-AI/SAG-Benchmark

프로젝트 통계

• ⭐ GitHub Stars: 1,900+
• 🍴 Forks: 87+
• 📄 License: MIT

핵심 설계: 청크 (chunk) → 이벤트 + 엔티티 (event + entities)

SAG의 기본 데이터 모델은 세 가지 요소를 가집니다:

하나의 문서 청크 (One document chunk)
    ↓
 하나의 이벤트 (One Event) (의미론적 이벤트)
...

이벤트 (Event): 청크의 의미론적 요약 (semantic summary)입니다. 각 청크는 정확히 하나의 이벤트에 매핑됩니다. 이벤트는 완전한 의미론 (semantics)을 보존합니다.

엔티티 (Entity): 청크에서 추출된 개체명 (Named entities)으로, 그래프 탐색을 위한 앵커 (anchors) 역할을 합니다. 11가지 유형: 시간 (time), 위치 (location), 인물 (person), 조직 (organization), 그룹 (group), 주제 (topic), 저작물 (work), 제품 (product), 행동 (action), 지표 (metric), 라벨 (label). 엔티티는 독립적인 의미론을 갖지 않으며, 오직 "서로 다른 이벤트를 연결하기 위한 인덱스 및 확장 지점"으로서만 존재합니다.

암시적 하이퍼엣지 (Implicit hyperedge): 하나의 이벤트와 그에 속한 모든 엔티티는 하나의 암시적 하이퍼엣지를 형성합니다. 이는 개념적으로 HyperGraphRAG와 유사하지만, SAG는 명시적으로 하이퍼그래프를 구축하지 않고 관계형 데이터베이스의 외래 키 (foreign key) 연관 관계를 통해 동일한 효과를 달성합니다.

왜 트리플 (triples) 대신 이벤트인가?

트리플 접근 방식:
...

논문의 어블레이션 (ablation) 연구 결과에 따르면, MuSiQue 데이터셋에서 하이퍼엣지 (이벤트) 방식은 Recall@5 = 80.0%를 기록한 반면, 트리플 방식은 77.1%를 기록했습니다.

2단계 아키텍처 (Two-Phase Architecture)

오프라인 단계 (문서 인제스션 (Document Ingestion))

Document (Markdown / TXT)
    ↓
Text chunking (텍스트 청킹)
...

핵심 속성: 추가 전용 쓰기 (append-only writes), 전역 그래프 재구축 없음 (no global graph rebuild). 새로운 문서 인제스션 (ingestion)이 기존 데이터에 영향을 주지 않으므로, PageRank를 다시 실행하거나 그래프 구조를 재구축할 필요가 없습니다.

온라인 단계 (Online Phase) (3단계 검색 (Three-Step Retrieval))

1단계: 시드 검색 (Seed Retrieval) (이중 경로 병렬 처리 (dual-path parallel))

경로 A: 엔티티 가이드 구조적 회상 (Entity-guided structured recall)
  1. LLM이 쿼리에서 엔티티 추출 → 시드 엔티티 집합 U_q
  2. 엔티티 인덱스에 대한 벡터 유사도 검색 (임계값 0.9) → 확장된 집합 Û_q
...

2단계: 쿼리 시점 확장 (Query-Time Expansion) (SQL 멀티홉 (SQL multi-hop))

이것이 SAG의 핵심 메커니즘입니다:

시드 이벤트 집합 ℰR에서 시작:
    ↓
역조인 (Reverse JOIN): 시드 이벤트에서 모든 엔티티 추출 (엔티티 프런티어 (entity frontier))
...

이것이 "멀티홉 (multi-hop)" 구현 방식입니다. 만약 문서 A가 엔티티 X를 언급하고 문서 B 또한 엔티티 X를 언급한다면, 문서 A의 이벤트로부터 단 한 번의 JOIN을 통해 문서 B의 관련 이벤트를 찾아낼 수 있습니다. 이는 두 문서가 벡터 공간상에서 멀리 떨어져 있더라도 가능합니다.

3단계: 최종 선택 (Final Selection) (이중 경로 융합 (dual-path fusion))

후보 집합 ℰ_cand (상위 100개 후보)
    ↓
구조적 경로 (Structural path): LLM이 체인 후보들을 재순위화 (rerank) → 상위 5개 이벤트 → 청크(chunk)로 매핑
...

SQL JOIN vs. PageRank: 왜 SAG가 긴 체인의 멀티홉 (Long-Chain Multi-Hop)에서 더 우수한가

HippoRAG 2의 접근 방식: 오프라인에서 전역 지식 그래프 (knowledge graph)를 구축한 다음, 쿼리 시점에 개인화된 페이지랭크 (Personalized PageRank, PPR)를 사용하여 그래프 에지 (edge)를 따라 시드 노드로부터 점수를 전파합니다.

문제는 PPR의 감쇠 계수 (damping factor)입니다. 각 홉 (hop)마다 점수는 (1-d) (d는 통상 0.85)를 곱하게 되어, 오직 15%의 확률만 유지됩니다. 2홉 후에는 노드의 점수가 0.15² = 0.0225가 곱해지며, 3홉 후에는 거의 0에 수렴합니다.

HippoRAG 2의 긴 체인 멀티홉 문제:
답변에 필요한 경로: A → B → C → D → E (4홉)
PPR 적용 후: E의 점수 ≈ seed_score × 0.15⁴ ≈ 0.0005 × seed_score
...

SAG의 SQL JOIN은 점수를 전파하는 것이 아니라 **도달 가능성 (reachability)**을 전파합니다. JOIN을 통해 엔티티 X와 연결된 모든 이벤트는 시드로부터 몇 홉 떨어져 있는지에 관계없이 동일하게 취급됩니다.

MuSiQue는 이러한 차이점에 집중합니다. 이 데이터셋은 구체적으로 4단계 추론 체인(reasoning chain) 질문을 구성합니다. HippoRAG 2는 이 데이터셋에서 SAG에 비해 성능이 현저히 떨어집니다 (65.1% vs 80.0%).

SAG의 약점은 2WikiMultiHop 데이터셋에 있습니다. SAG는 고정된 엔티티 프런티어 가지치기 예산(entity frontier pruning budget, 50개 엔티티)을 가집니다. 출현 빈도가 낮은 브릿징 엔티티(bridging entities)는 가지치기 과정에서 잘려 나갈 수 있으며, 이로 인해 해당 데이터셋에서 SAG는 HippoRAG 2보다 약간 낮은 성능을 보입니다 (88.0% vs 90.4%).

벤치마크 결과 (Benchmark Results)

bge-large-en-v1.5 임베딩(embeddings)과 qwen3.6-flash를 LLM으로 사용했을 때:

Recall@5 비교:

데이터셋	SAG	HippoRAG 2	차이
MuSiQue	80.0%	65.1%	+14.9pp
...

더 강력한 NV-Embed-v2 임베딩으로 전환하면 MuSiQue Recall@5가 **81.71%**로 상승하며, 이는 성능 향상이 단순히 임베딩 품질이 아닌 구조적 설계에서 비롯됨을 확인시켜 줍니다.

어블레이션 결과 (Ablation results):

설정 (Configuration)	MuSiQue R@5
Full SAG	80.0%
...

멀티홉 확장(Multi-hop expansion)은 약 10.6pp의 성능 향상에 기여합니다. LLM 재순위화(reranking)는 생략할 수 없는 필수 요소입니다 (17.8pp 차이).

빠른 시작 (Quick Start)

git clone https://github.com/Zleap-AI/SAG.git
cd SAG

...

주요 .env 설정:

# LLM (OpenAI 호환 API)
LLM_BASE_URL=https://api.openai.com/v1
LLM_API_KEY=your_key
...

두 가지 검색 모드 (Two Search Modes)

빠른 모드 (Fast mode) (LLM 쿼리 파싱 없음):

쿼리(Query) → BM25 전문 엔티티 매칭 → SQL 멀티홉 확장 → 재순위화(reranking)
장점: 낮은 지연 시간(low latency), LLM 쿼리 파싱 비용 없음
적합한 경우: 명시적인 엔티티 이름이 포함된 쿼리

표준 모드 (Standard mode) (LLM 엔티티 추출):

쿼리(Query) → LLM이 엔티티 추출 → 벡터 + SQL 멀티홉 확장 → LLM 재순위화(reranking)
장점: 모호하거나 자연어 형태의 질문에 대해 더 견고함
적합한 경우: 복잡한 추론이 필요한 쿼리

MCP 통합 (MCP Integration)

각 SAG 프로젝트는 자동으로 MCP 서버 엔드포인트를 노출하며, Claude Code 및 기타 에이전트에서 직접 사용할 수 있습니다:

{
  "mcpServers": {
    "sag": {
...

사용 가능한 MCP 도구 (Available MCP tools):

도구 (Tool)	기능 (Function)
sag_search	프로젝트 지식 베이스 (knowledge base) 검색
...

Web UI 기능 (Web UI Features)

• 지식 그래프 탐색기 (Knowledge graph explorer): 드래그, 확대/축소, 확장 기능을 통해 이벤트-엔티티 (event-entity) 노드를 시각화
• 검색 추적 시각화 (Search trace visualization): 각 검색 단계와 단계별 지연 시간 (latency)을 실시간으로 표시
• 원시 모델 로그 (Raw model logs): 전체 LLM / 임베딩 (Embedding) / 재순위화 (Rerank) 요청 및 응답을 검사
• 프로젝트 격리 (Project isolation): 각 프로젝트는 독립적인 문서 라이브러리, 대화 기록, 그래프 및 MCP 설정을 가짐

링크 및 리소스 (Links and Resources)

• 🌟 GitHub: Zleap-AI/SAG
• 📄 arXiv: 2606.15971
• 🔬 벤치마크 (Benchmarks): Zleap-AI/SAG-Benchmark
• 🌐 웹사이트 (Website): zleap.com

결론 (Conclusion)

SAG의 핵심 기여는 경량화된 멀티홉 검색 (multi-hop retrieval) 구현에 있습니다. 사전에 구축된 전역 지식 그래프 (global knowledge graph)나 PageRank 점수 산정 방식 없이, 관계형 데이터베이스 (relational database)의 JOIN을 통해 쿼리 시점에 동적으로 그래프 구조를 확장합니다. 이러한 선택에는 두 가지 결과가 따릅니다. 첫째, 문서 업데이트는 추가 전용 (append-only) 방식이며 재구축이 필요하지 않습니다. 둘째, SQL JOIN을 통한 도달 가능성 (reachability)은 홉 수 (hop count)에 영향을 받지 않으며 감쇠 (decay) 현상이 없습니다.

(트리플 (triples) 대신) "의미 단위로서의 이벤트 (event as semantic unit)" 설계 또한 주목할 만합니다. 각 청크 (chunk)의 완전한 의미론적 정보가 하나의 이벤트 노드에 보존되며, 엔티티 (entities)는 오직 연결 지점 역할만 수행합니다. 이는 MuSiQue 벤치마크에서 트리플 방식보다 약 3%포인트 높은 성능을 보이며 설계 결정의 타당성을 입증했습니다.

약점 또한 명확합니다. 고정된 가지치기 예산 (pruning budget)으로 인해 2WikiMultiHop에서 HippoRAG 2보다 약간 낮은 성능을 보이며, 엔티티를 연결하는 브릿지가 저빈도일 경우 일부 중요한 경로를 놓치기도 합니다. 이러한 약점을 파악함으로써 자신의 시나리오에 적합한지 판단할 수 있습니다.

_ PrimeSkills를 탐색해 보세요 — 엄선된 AI 에이전트 (AI Agents)와 기술 (skills)을 위한 마켓플레이스입니다. 각 기술은 실제 기업 워크플로우에서 검증되었으며, 과장된 광고를 걷어내고 진정으로 작동하는 것만을 제공합니다._

더 유용한 통찰력과 흥미로운 제품들을 확인하시려면 저의 홈페이지를 방문해 주세요.