LightRAG: 빠르고 가벼운 차세대 지식 그래프 RAG

기존 GraphRAG는 너무 비싸고 무거운데?라는 문제를 해결하기 위한
HKU(홍콩대학교)의 LightRAG를 정리해보겠습니다.

논문: arXiv:2410.05779 — LightRAG: Simple and Fast Retrieval-Augmented Generation
GitHub: HKUDS/LightRAG
PyPI: lightrag-hku

1. LightRAG를 도입하는 이유

LLM을 활용하는 프로젝트에서 RAG(Retrieval-Augmented Generation) 는 이제 선택이 아니라 필수입니다. 하지만 실무에 적용해본 분이라면 Naive RAG의 한계를 분명히 느끼셨을 겁니다.

문서를 잘게 쪼개 벡터로 저장하다 보니 파편화된 조각만 회수됩니다.
"A 사건이 B 사건에 미친 전반적인 영향은?" 같은 추론·요약형 질문에는 약합니다. 물론, 자체로도 성능이 좋은 LLM의 경우에는 대답은 잘 하겠지만 검색되는 문서 자체는 문제가 많겠죠.
문서 간의 관계(Relation) 를 모델이 직접 연결하지 못합니다.

이를 해결하기 위해 Microsoft가 GraphRAG를 발표했지만, 모든 문서를 LLM으로 읽어 거대한 지식 그래프와 커뮤니티 요약을 만들기 때문에 API 비용과 구축 시간이 매우 큽니다. 또한 너무 세부적인(Local) 질문에는 오히려 약한 모습을 보입니다.

LightRAG는 이 두 가지 딜레마를 해결합니다.

그래프 구조를 사용하되 엔티티(Entity)와 관계(Relation)를 두 레벨로 분리하여 검색
훨씬 적은 LLM 호출로 그래프 구축
증분 업데이트(Incremental Update) 지원
멀티모달 문서(텍스트·이미지·표·수식) 처리

1.1 세 가지 RAG 한눈에 비교

항목	Naive	GraphRAG	LightRAG
인덱싱 비용	매우 낮음	매우 높음	중간
글로벌 추론	약함	강함	강함
로컬 정밀도	보통	약함	강함
증분 업데이트	쉬움	어려움 (재구축 필요)	쉬움 (병합 가능)
멀티모달	별도 구현 필요	제한적	내장 지원

1.2 LightRAG의 장점

1. 심층적 문맥 이해 (Deep Contextual Understanding)

내용: LightRAG는 그래프 구조의 인덱싱을 통해 엔티티(Entity) 간의 복잡한 의미적 의존성을 포착합니다. 이를 통해 기존의 청크(Chunk) 기반 검색 방식에서 흔히 발생하는 파편화된 문맥의 한계를 극복합니다.
장점: 전체적인 이해나 논리적 추론이 필요한 버티컬 도메인(예: 법률, 금융 등)에서 텍스트 생성 품질과 문맥 인지 능력이 특히 압도적입니다.

2. 뛰어난 포괄성 및 다양성 (Exceptional Comprehensiveness & Diversity)

내용: LightRAG의 이중 레벨 검색 메커니즘(Dual-level retrieval mechanism)은 구체적인 사실 관계와 추상적인 개념을 동시에 통합할 수 있도록 합니다.
장점: 이 덕분에 검색 결과의 포괄성과 다양성 측면에서 탁월한 성능을 발휘하며, 여러 문서에 걸쳐 있는 복잡한 교차 문서 쿼리(Cross-document queries)를 처리하는 데 매우 효과적입니다.

3. 극대화된 검색 효율성 및 낮은 비용 (Extreme Retrieval Efficiency & Low Cost)

내용: LightRAG는 복잡한 쿼리를 처리할 때 비효율적인 커뮤니티 리포트나 멀티홉 추론(Multi-hop reasoning)에 의존하지 않습니다.
장점: 인덱싱과 쿼리 단계 모두에서 LLM 호출 횟수를 획기적으로 줄여주며, 결과적으로 응답 지연 시간(Latency)과 LLM 연산 비용을 크게 낮춥니다.

4. 동적 데이터에 대한 신속한 적응 (Rapid Adaptation to Dynamic Data)

내용: LightRAG는 끊김 없는 점진적 지식베이스 업데이트(Incremental knowledge base updates)를 지원합니다. 새로운 데이터는 표준 그래프 인덱싱 파이프라인을 거쳐 로컬 그래프를 생성한 후, 집합 병합(Set merging)을 통해 기존 그래프에 직접 통합됩니다.
장점
- 이 과정에서 기존 구조를 무너뜨리거나 글로벌 인덱스를 새로 구축할 필요가 없어, 실시간으로 데이터가 변하는 환경에서도 최신 정보를 유지합니다.
- 문서를 삭제할 때도 시스템 구축 단계의 LLM 캐싱을 활용해 영향을 받는 엔티티 관계를 빠르게 재구축하므로, 지식베이스 업데이트 효율성이 대폭 향상됩니다.

2. 핵심 아키텍처: Dual-Level Retrieval

LightRAG의 핵심은 두 레벨로 분리된 검색 메커니즘입니다.

LightRAG’s dual-level retrieval mechanism allows it to integrate detailed facts and abstract concepts concurrently.
This enables the system to achieve remarkable performance in query result comprehensiveness and diversity, making it highly effective at handling complex, cross-document queries.

2.1 인덱싱(Indexing) 파이프라인

원본 문서
   ▼
[1] Chunking — 텍스트를 청크 단위로 분할
   ▼
[2] LLM Entity & Relation Extraction
       ├─ Entity (인물·장소·개념 등)
       └─ Relation (엔티티 간의 관계)
   ▼
[3] Profile Generation — 각 엔티티/관계에 LLM 요약문(profile) 부여
   ▼
[4] 듀얼 저장
       ├─ Knowledge Graph Storage  (그래프 구조)
       └─ Vector Storage           (chunks · entities · relations 임베딩)

2.2 듀얼 레벨 검색(Retrieval) 메커니즘

질의가 들어오면 LLM이 두 종류의 키워드를 동시에 추출합니다.

레벨	키워드 종류	검색 대상	대상 질문
Low-Level	구체적 키워드 (specific)	엔티티 벡터 인덱스	"X는 누구인가?", "Y의 속성은?"
High-Level	추상적 키워드 (abstract)	관계(Relation) 벡터 인덱스	"X와 Y의 관계는?", "전체 테마는?"

검색된 엔티티·관계 노드를 시작점으로 그래프 이웃(neighbor) 까지 함께 가져와 컨텍스트를 풍부하게 구성합니다.

2.3 다섯 가지 Query Mode

LightRAG는 같은 인덱스 위에서 다섯 가지 검색 모드를 지원합니다.

Mode	동작 방식	적합한 상황
`naive`	기존 벡터 유사도 검색 (그래프 미사용)	단순 사실 조회, 베이스라인 비교
`local`	Low-Level 키워드 → 엔티티 중심 검색	특정 객체·인물·개념에 대한 정확한 Q&A
`global`	High-Level 키워드 → 관계 중심 검색	요약, 트렌드 분석, 주제 간 의존성 추론
`hybrid`	`local` + `global` 결합	종합적 추론이 필요한 질의
`mix`	`local` + `global` + `naive` 통합 (기본값)	가장 포괄적인 검색, naive와 유사한 응답속도

💡 기본값은 mix입니다. 대부분의 경우 가장 우수하고, 응답 속도도 naive와 큰 차이가 없습니다.

3. 설치 가이드

3.1 PyPI 설치 (권장)

# uv 사용
uv tool install "lightrag-hku[api]"

# 또는 pip
pip install "lightrag-hku[api]"

3.2 소스에서 설치

git clone https://github.com/HKUDS/LightRAG.git
cd LightRAG
make dev
source .venv/bin/activate

# Web UI 빌드
cd lightrag_webui && bun install --frozen-lockfile && bun run build && cd ..

# 환경 변수 초기화 후 서버 실행
make env-base
lightrag-server

3.3 Docker 배포

git clone https://github.com/HKUDS/LightRAG.git
cd LightRAG
cp env.example .env
docker compose up

4. Quick Start: OpenAI 기반 예제

공식 저장소의 examples/lightrag_openai_demo.py 를 단순화한 버전입니다.

import os
import asyncio
from lightrag import LightRAG, QueryParam
from lightrag.llm.openai import gpt_4o_mini_complete, openai_embed

WORKING_DIR = "./dickens"

if not os.path.exists(WORKING_DIR):
    os.mkdir(WORKING_DIR)


async def initialize_rag() -> LightRAG:
    rag = LightRAG(
        working_dir=WORKING_DIR,
        embedding_func=openai_embed,
        llm_model_func=gpt_4o_mini_complete,
    )
    # KV / Vector / Graph / DocStatus 스토리지 초기화
    await rag.initialize_storages()
    return rag


async def main():
    if not os.getenv("OPENAI_API_KEY"):
        raise RuntimeError("OPENAI_API_KEY 가 설정되지 않았습니다.")

    rag = await initialize_rag()
    try:
        # 1) 문서 삽입 (인덱싱)
        with open("./book.txt", "r", encoding="utf-8") as f:
            await rag.ainsert(f.read())

        # 2) 네 가지 모드로 검색
        question = "What are the top themes in this story?"

        for mode in ["naive", "local", "global", "hybrid"]:
            print(f"\n===== Query mode: {mode} =====")
            answer = await rag.aquery(question, param=QueryParam(mode=mode))
            print(answer)
    finally:
        await rag.finalize_storages()


if __name__ == "__main__":
    asyncio.run(main())

4.1 샘플 데이터로 빠르게 돌려보기

export OPENAI_API_KEY="sk-..."
curl https://raw.githubusercontent.com/gusye1234/nano-graphrag/main/tests/mock_data.txt > ./book.txt
python examples/lightrag_openai_demo.py

4.2 핵심 API

메서드	설명
`LightRAG(...)`	RAG 인스턴스 생성. `working_dir`, `embedding_func`, `llm_model_func` 지정
`await rag.initialize_storages()`	KV/Vector/Graph/DocStatus 스토리지 초기화
`await rag.ainsert(text)`	문서 삽입 (비동기). 동기 버전 `rag.insert(text)`
`await rag.aquery(q, param=...)`	질의 (비동기). 동기 버전 `rag.query(q, param=...)`
`QueryParam(mode=...)`	검색 모드 지정 (`naive`/`local`/`global`/`hybrid`/`mix`)
`await rag.finalize_storages()`	리소스 정리

5. 4종 스토리지(Storage) 아키텍처

LightRAG는 네 종류의 저장소를 필요로 합니다. 기본값은 파일 기반(in-memory + JSON/GraphML 영속화)입니다. 다만, 그래프DB의 경우에는 테스트 혹은 테이블이 하나인 경우에는 따로 필요하지 않습니다. 인메모리로 돌아간다고 하네요(용량이 작은 경우에만).

스토리지	용도	기본 구현	옵션
KV_STORAGE	LLM 캐시, 텍스트 청크, 추출 결과	JSON	PostgreSQL, MongoDB
VECTOR_STORAGE	chunks/entities/relations 임베딩	NanoVectorDB	Milvus, Qdrant, Weaviate, OpenSearch, pgvector
GRAPH_STORAGE	지식 그래프 노드/엣지	NetworkX (GraphML)	Neo4j, Memgraph
DOC_STATUS_STORAGE	문서 단위 처리 상태 추적	JSON	PostgreSQL, MongoDB

5.1 실제 생성되는 파일 (파일 기반 기본 설정 시)

./working_dir/
├── graph_chunk_entity_relation.graphml   # 지식 그래프
├── kv_store_doc_status.json              # 문서 인덱싱 상태
├── kv_store_full_docs.json               # 원본 문서
├── kv_store_text_chunks.json             # 청크
├── vdb_chunks.json                       # 청크 임베딩
├── vdb_entities.json                     # 엔티티 임베딩
└── vdb_relationships.json                # 관계 임베딩

6. LLM·임베딩 모델 구성

6.1 LLM의 역할

LightRAG는 단계마다 다른 역할의 LLM 호출이 필요합니다. 역할별로 다른 모델을 지정할 수 있어 비용·속도·품질 트레이드오프를 세밀하게 조정 가능합니다.

Role	역할	권장 모델 등급(HKU 기준)
EXTRACT	문서에서 엔티티·관계 추출	중급 이상 (gpt-4o-mini, claude-haiku 등)
QUERY	검색된 컨텍스트로 최종 답변 생성	고급 (gpt-4o, claude-sonnet 등)
KEYWORDS	질의에서 low/high-level 키워드 추출	경량
VLM	이미지·표·수식 등 시각 콘텐츠 분석	Vision 지원 모델

6.2 임베딩 모델 선택 — 매우 중요

권장: BAAI/bge-m3 같은 다국어 지원·저차원·고속 모델
로컬 배포 강력 권장: 인덱싱 단계에서 호출이 매우 많기 때문에 외부 API는 비용·속도에 큰 부담
⚠️ 임베딩 모델은 초기 인덱싱 전에 결정해야 합니다. 변경 시 전체 재임베딩이 필요합니다. 또한, 이미 구축된 데이터와 신규 데이터의 임베딩 모델이 다를 경우 오류가 생깁니다.

6.3 Reranker (선택)

질의 단계에서 품질을 크게 향상시키지만 1–2초의 지연이 추가됩니다.
로컬 배포 권장.
임베딩 모델과 달리 언제든지 교체 가능합니다.

7. 환경 변수 튜닝 치트시트

7.1 동시성(Concurrency) — 인덱싱 속도 최적화

MAX_ASYNC_LLM=8              # 동시 LLM 호출 수
MAX_PARALLEL_INSERT=3        # 동시에 인덱싱할 문서 수
EMBEDDING_FUNC_MAX_ASYNC=16  # 동시 임베딩 요청 수
EMBEDDING_BATCH_NUM=32       # 임베딩 배치 크기

7.2 문서 처리(Document Parsing)

LIGHTRAG_PARSER=*:native-iteP,*:mineru-iteP,*:legacy-R
VLM_PROCESS_ENABLE=true       # 이미지/표/수식 VLM 처리
SUMMARY_LANGUAGE=Korean       # 엔티티 프로파일 요약 언어
ENTITY_EXTRACTION_USE_JSON=true

7.3 Query 최적화

MAX_ENTITY_TOKENS=2000        # 컨텍스트에 포함될 엔티티 토큰 상한
MAX_RELATION_TOKENS=2000      # 관계 토큰 상한
ENABLE_CONTENT_HEADINGS=true  # 청크에 헤딩 정보 포함
ENABLE_LLM_CACHE=true         # LLM 응답 캐싱(중복 호출 방지)

8. 멀티모달 & 시민 콘텐츠 처리

LightRAG는 MinerU / Docling 파싱 엔진을 통해 다음을 처리합니다.

이미지: VLM으로 캡션 생성 → 텍스트 추출 파이프라인에 통합
표(Table): 구조 보존 텍스트화
수식(Equation): LaTeX 형태로 추출
PDF / Office 포맷: 레이아웃 인식 파싱

VLM_PROCESS_ENABLE=true 로 활성화하고, VLM 역할에 Vision 가능한 모델을 지정하면 됩니다.

9. 인용(Citation) 기능

각 답변에서 출처 문서·청크·엔티티까지 추적할 수 있어, 법률·의료·금융 등 추적성이 중요한 도메인에서 강력합니다.

10. REST API & Web UI

lightrag-server 실행 시 자동으로 제공됩니다.

문서 업로드 / 인덱싱
모든 모드에서의 질의
지식 그래프 시각화 UI — 엔티티·관계 탐색
인증·다중 사용자 지원
OpenAPI 스펙 자동 노출

11. 성능 벤치마크

논문에서 도메인별로 NaiveRAG와 win-rate를 비교한 결과입니다. (Comprehensiveness / Diversity / Empowerment 평균)

도메인	LightRAG	NaiveRAG
Agriculture	67.6%	32.4%
Computer Science	61.2%	38.8%
Legal	84.8%	15.2%
Mix	60.0%	40.0%

특히 장문·전문성 높은 문서가 많은 법률 도메인에서 압도적 우위를 보입니다.

11.1 GraphRAG 대비 비용·속도

인덱싱 LLM 호출 수: 수십~수백 배 감소 (커뮤니티 검출/요약 단계 제거)
증분 업데이트: GraphRAG는 사실상 재구축 필요, LightRAG는 set merging으로 즉시 반영
응답 속도: mix 모드 기준 naive와 유사한 수준

12. 생태계 (HKUDS 관련 프로젝트)

프로젝트	설명
RAG-Anything	멀티모달 RAG (텍스트·이미지·오디오·비디오 통합)
VideoRAG	초장문맥 비디오 분석 RAG
MiniRAG	소형 LLM도 활용 가능한 경량 RAG

13. 언제 LightRAG를 선택해야 할까?

✅ LightRAG 도입이 유리한 경우

전문 도메인의 대량 문서를 다뤄야 함 (법률·의료·금융·연구)
단순 사실 조회뿐 아니라 전역적 요약·관계 추론이 필요함
GraphRAG는 비용이 부담스러움
문서가 자주 추가·갱신되어 증분 업데이트가 필수
인용·추적성이 필요한 도메인

⚠️ 신중히 선택해야 하는 경우

데이터가 매우 작거나 단순한 FAQ 수준 → Naive RAG로 충분
LLM API 비용에 매우 민감하고 로컬 모델 운영 인프라가 없는 경우 → 임베딩만 로컬화 등 부분 최적화 필요
그래프 시각화·관리 운영 리소스가 전혀 없는 경우

14. 출처 및 참고 링크

LightRAG: Simple and Fast Retrieval-Augmented Generation,
저자: Zirui Guo and Lianghao Xia and Yanhua Yu and Tu Ao and Chao Huang

📄 논문: https://arxiv.org/abs/2410.05779
🐙 GitHub: https://github.com/HKUDS/LightRAG
📦 PyPI: https://pypi.org/project/lightrag-hku/
💬 Discord: https://discord.gg/yF2MmDJyGJ

15. 마무리

Knowledge Graph에 대해 많이 공부하며 아무리 봐도 진행하던 프로젝트에 도입하면 좋을 것 같았는데, 가장 큰 문제였던 비용 문제와 지속적 업데이트의 문제가 LightRAG라는 기술로 풀려서 정말 행복했던 기억이 있습니다. 다만 LightRAG 내부 청킹은 단순히 토큰 수와 오버랩을 적용하여 문서를 자르다보니 의미론적 청킹된 문서를 한번 더 잘라버리니 처음에는 왜 문서가 깨졌지? 했던 기억이 있네요. 해당 기능을 꺼버리고 파싱/청킹이 제대로 된 문서를 넣으니 압도적인 성능을 보여줬었습니다.

근데 논문에서 나왔던 것보다는 시간과 비용 측면에서 리소스 소모가 생각보다 더 많이 나와서 실제 도입 시에는 여러가지 테스트를 해보면서 조금 더 생각해봐야 할 것 같습니다. 제가 진행하던 프로젝트에서는 정말 일부 기능에서 사용할 지식그래프를 형성했기에 그럭저럭 활용이 가능했지만, 전체 서비스에 적용하기에는 아무래도 비용 측면에서 기각되었습니다.

'AI 관련 지식 > RAG' 카테고리의 다른 글

[RAG] Naive RAG, Graph RAG, OpenKB 비교 (0)	2026.05.20
[OpenKB] OpenKB란? (1)	2026.05.15
[vector DB] Weaviate 기본 정리 (0)	2025.09.10

[지식 그래프] LightRag란?