System Architecture · v2026-07

LLM-Free GraphRAG 증류 파이프라인

교사 LLM으로 합성 (문서 → 엔티티/관계) 데이터를 생성하고, 이를 경량 NLP 모델에 SFT로 증류하여, 인덱싱 시점에 LLM 호출 없이 GraphRAG 그래프를 구축하는 프레임워크.

GPURTX 3090 · 24GB · 무제한

API 예산₩20,000 · 검증 전용

일정4–6개월

최대 리스크Phase 0.5 baseline 재현

지금 상태 (2026-07-16) — 윈도우(RTX 3090) 원격 연결 끊김, 복구까지 약 1주 예상. 맥에서 sub4-mac-noGPU 브랜치로 GPU 없이 가능한 작업만 진행 중. 아래 03의 좌측 색 막대가 각 단계의 GPU 필요 여부를 나타낸다.

01 배경 — 이 프로젝트가 푸는 문제

RAG와 GraphRAG가 각각 어디서 강하고 약한지, 그 사이에서 이 프로젝트가 정확히 무엇을 해결하려는지.

RAG란

질의와 관련된 문서 조각(chunk)을 검색해 LLM 생성에 결합하는 방식. 재학습 없이 최신·외부 지식을 답변에 반영할 수 있지만, 검색 단위가 개별 chunk라 여러 사실을 엮어야 하는 멀티홉 질문이나 "코퍼스 전체를 요약해줘" 같은 전역 질문에 약하다.

GraphRAG란

문서에서 엔티티·관계를 추출해 지식 그래프로 구조화하고, 그 위에서 서브그래프 탐색·커뮤니티 요약으로 검색한다. 멀티홉·전역 질문에 강하지만, 그래프를 만드는 인덱싱 단계에서 문서·커뮤니티마다 LLM을 반복 호출해야 해 비용·지연이 크다 — 개인 연구자·소규모 서비스의 실질적 진입장벽.

접근법	전역·요약 질문	실제 정확도
Naive RAG		해당 없음
LLM 기반 GraphRAGMS GraphRAG · LightRAG · KAG
기존 LLM-Free GraphRAGNoLLMRAG · LiteSemRAG 등		표면통계 의존
이 프로젝트교사→증류	TextRank 요약 한계	검증 중 · Phase 1.4/2.4

해결하려는 문제 — GraphRAG의 멀티홉·전역 추론 이점은 유지하면서, (1) LLM 기반 GraphRAG의 인덱싱 비용·지연 문제와 (2) 기존 LLM-free 방법의 정확도 손실 문제를 동시에 해결한다. 교사 LLM → 경량 모델 증류 파이프라인으로 "인덱싱 시 LLM 호출 0회"와 "실제 정확도 유지"를 함께 달성하는 것이 이 프로젝트의 핵심 기여(C1)다.

02 한눈에 보는 4단계

기술 다이어그램이 낯설다면 — 이 파이프라인은 결국 이런 순서다.

로컬 팩토리

Qwen2.5 · 무료 · 대량 생산

Phase 1.2 · 500~1,000청크

불심 검문

GPT-4o · 소량 · 고품질 대조

Phase 1.6-e/f · ₩1,600

교통 정리

엔티티 정규화 · 텍스트 통일

Phase 3.2

지도 제작

Leiden · 그래프 완성

Phase 3.4

1→2는 서브1(데이터 생성), 3→4는 서브3(그래프 구축)의 요약이다. 둘 사이에는 경량 모델 증류(서브2)가 있고, 그렇게 증류된 학생 모델이 실제로 전체 코퍼스를 추론해 3단계의 원재료(triple)를 만든다.

03 엔드투엔드 데이터 흐름

원문 코퍼스에서 다운스트림 QA 평가까지 — 강조된 단계가 이 프레임워크의 핵심 주장(인덱싱 LLM 호출 0회)이다.

맥 가능

INPUT

원문 코퍼스

UltraDomain 외 7종 데이터셋 (428개 교재, 18개 도메인)

GPU 필수

TEACHER

로컬 교사 LLM

Qwen2.5-32B-AWQ · vLLM 서빙 · 4bit 양자화

GPU 필수

GEN

합성 데이터 생성

문서 → triple · 500~1,000청크 · self-consistency confidence

GPT-4o 검증 (₩1,600)

고정 서브셋 150~200청크 sanity-check + 골드셋 2차 라벨러(κ) — 인덱싱과 무관, 오프라인 QA 전용

GPU 필수

DISTILL

경량 모델 SFT

QLoRA/LoRA · 보조데이터 비율 실험(0/10/30/50%)

맥 가능

INDEX

그래프 구축

인덱싱 시 LLM 호출 0회 · 엔티티 정규화 · Leiden · TextRank 요약

부분 가능

RETRIEVE

검색 인터페이스

쿼리 → 1~2hop 서브그래프 탐색 · 랭킹

Baseline 5종

MS GraphRAG · LightRAG · LiteSemRAG · dep-parsing · NoLLMRAG (로컬 LLM 인덱싱으로 통일) — LLM-free 3종 완료

골격만

OUTPUT

다운스트림 QA 평가

비용(GPU-시간) · 정확도 · 환각률 · 도메인 적응 격차

원논문 앵커

GraphRAG/LightRAG의 GPT-4 보고 수치 — 삼각비교용 참고열

맥에서 GPU 없이 가능

부분 가능 (배선/골격만)

GPU 필수 (현재 블록)

검증/비교용 보조 입력 (인덱싱 경로 아님)

INPUT원문 코퍼스

설명: UltraDomain(HuggingFace TommyChien/UltraDomain, 428개 대학교재·18개 도메인) + GraphRAG-Bench + HotpotQA + MultiHop-RAG + DocRED + SciERC + WebNLG + FewRel
담당: 서브1 — graphrag_01_data_pipeline.md
현재 상태: 미착수. TODO_mac.md #6 대상 — 경로 확인·다운로드·500~1,000자 청크 분할

단계를 클릭하면 이 패널이 갱신됩니다.

04 Phase 의존관계 맵

6개 레인(공통 인프라 + 서브프로젝트 1~5)의 실행 순서와 교차 의존성. 좌측 막대색은 코어 파이프라인(teal)과 인프라·평가 확장(copper)을 구분한다.

공통 인프라

Phase 0

0.0

교사 서빙

0.5

baseline 재현 + a0 처리량체크

서브1 · 데이터

1.0 – 1.6

1.0

1.1

1.2

1.3

1.4

1.5

1.6

골드셋+GPT-4o

서브2 · 증류

2.0 – 2.6

2.0

2.1

2.2

2.3

2.4

2.5

2.6

서브3 · 그래프

3.0 – 3.7

3.0

3.1

3.2

3.3

3.35

3.4

3.5

3.6

3.7

일치율/실정확도

서브4 · 평가

4.1 – 4.5

4.1

4.2

4.3

4.4

4.5

서브5 · 도메인적응

5.0 – 5.4

5.0

5.1

5.2

5.3

5.4

4.2 하네스 필요

교차 레인 의존성 (선행 산출물 필요)

병렬 착수 가능 지점

순환논증 방지 핵심 산출물

05 알려진 병목과 대응

설계 리뷰에서 나온 4개 실행 리스크와 문서상 대응 지점.

반영됨속도 병목

MS GraphRAG/LightRAG를 로컬 32B로 인덱싱하면 GPU가 몇 주간 안 멈출 위험

Phase 0.5-a0 — 3개→10~20개 2단계 파일럿으로 소요시간 외삽, 2주 초과 시 QA 비교 코퍼스를 서브셋으로 축소

반영됨VRAM 병목

32B AWQ 가중치만 ~18~19GB 차지 → 24GB 중 KV 캐시 여유는 ~5GB, OOM 위험

Phase 0.0-e — gpu-memory-utilization 0.90 캡 + 청크 크기 500~1,000자 제한. Phase 1.2·0.5 양쪽에 적용

반영됨엔티티 오염

임베딩 유사도만 쓰면 과묶임(애플≠사과)과 과소병합(Jobs≠Steve Jobs) 둘 다 발생

Phase 3.2-b(type 사전필터, 과묶임 방지) + 3.2-b2(별칭 매칭, 과소병합 방지) 2단계 방어선

조건부파괴적 망각

학생 모델이 추출 데이터만 학습하면 일반 언어 능력을 잃을 수 있다는 우려

최종 답변 생성은 교사 LLM을 재활용(3.35-d)해 span 헤드 선택 시 무관. seq2seq 선택 시에만 Phase 2.3 비율 실험으로 완화(2.1-a 참고)

검토 중원논문 앵커 비교 방식

MS GraphRAG·LightRAG 원 논문은 EM/F1이 아니라 GPT-4(o) 심사 기반 LLM-as-judge 승률을 보고 — 우리 지표와 같은 컬럼에 두면 오해 소지

정성적 각주로 전환하거나, GraphRAG-Bench 자체 논문(arXiv:2506.05690)의 EM/F1 재평가를 앵커로 대체하는 방안 검토 중 — spec.md §9-2

06 기존 아키텍처 대비 무엇이 다른가

같은 목표(지식그래프 기반 QA)를 향해 가는 두 경로 — 인덱싱 단계에서 무거운 LLM을 계속 부르는지 아닌지가 갈림길이다.

기존 GraphRAG (MS GraphRAG · LightRAG) — 인덱싱 경로

INPUT

원문 코퍼스

Text Chunking

CHUNKS

문서 청크

LLM 반복 호출 ①

Entity & Relationship Extraction — 청크마다 프롬프팅

TRIPLES

텍스트 트리플

Sub-graph Triples

EMBED

임베딩 벡터

Graph Embedding → Vector DB 저장

LLM 반복 호출 ②

Community Summary — Leiden 클러스터링 후 커뮤니티마다 요약 생성

OUTPUT

글로벌 지식그래프

완성 — 여기까지 문서 1건 추가할 때마다 반복

병목 — 문서를 새로 넣을 때마다 지식 추출과 커뮤니티 요약 두 구간에서 무거운 LLM 호출이 문서 수만큼(O(N)) 반복된다. 인덱싱 시점 API 비용·지연 시간이 문서량에 비례해 폭발하는 구조.

이 프로젝트 — 3단계 파이프라인

1단계 · 오프라인 교사-학생 증류 (한 번만)

SUBSET

원문 코퍼스 (일부)

TEACHER

로컬 교사 LLM

Qwen2.5-32B → self-consistency 필터링

SFT

경량 학생 모델

QLoRA SFT 완료 — 이후 재사용, 이 단계는 다시 안 돔

2단계 · 실시간 LLM-free 인덱싱 (문서 추가마다 반복 — 여기가 핵심)

INPUT

새 코퍼스

Text Chunking

STUDENT

경량 학생 모델 추론

LLM 호출 0회 — CPU로도 구동 가능

NORMALIZE

엔티티 정규화

Type 사전필터 + 별칭 매칭 — 과묶임/과소병합 방지

GRAPH

글로벌 지식그래프

Leiden 커뮤니티 탐지 + TextRank 요약 — 알고리즘만, LLM 없음

3단계 · 검색 및 최종 답변 생성

QUERY

사용자 쿼리

1~2hop 서브그래프 검색 & 랭킹

CONTEXT

엔티티/관계 컨텍스트

파괴적 망각 방지 하이브리드 추론

ANSWER

최종 답변 생성

교사 LLM 재활용(인덱싱 경로가 아니라 질의당 1회)

비교 항목	기존 GraphRAG	이 프로젝트	차별화 포인트
인덱싱 시 LLM 비용	매우 높음 — O(N) API 호출 또는 heavy GPU	0원 — O(0), 로컬 학생 모델 추론	C1(핵심 기여): 인덱싱 비용 장벽을 완전히 허물어 실시간 서비스 적용 가능
인덱싱 인프라 요구량	고성능 GPU 필수 (VRAM 점유 + 장시간 구동)	맥북 / 일반 CPU로 구동 가능	원격 GPU 연결이 끊겨도 sub4-mac-noGPU에서 인덱싱 프로토타입 진행 가능했던 이유
엔티티 추출 방식	매번 거대 LLM의 원샷/퓨샷 프롬프팅	SFT로 지식이 압축 이식된 경량 모델	단순 패턴 매칭(기존 LLM-free)보다 높은 맥락 이해도·정확도 유지가 목표
엔티티 노이즈 제어	LLM 프롬프트 제어력에만 의존(유사 이름 중복 등)	2단계 정규화 방어선(Type 필터 + 별칭 매칭)	과묶임·과소병합을 알고리즘 수준에서 차단(Phase 3.2-b/3.2-b2)
평가·검증 신뢰도	자가 추출-자가 평가 순환논증 취약	교사-학생 일치율 vs 골드셋 실제 정확도 분리 평가	학술적 평가 신뢰도 확보, LLM-as-judge 편향 완화

기존 GraphRAG가 "새 문서가 올 때마다 초거대 AI에게 무거운 노동을 시키는 공장"이라면, 이 아키텍처는 "초거대 AI에게 핵심 노하우(SFT)를 속성 교육받은 정예 요원(경량 모델)들을 현장에 배치해, 저비용·고효율로 즉각적인 지식 지도를 그리게 만드는 시스템"이다.