Engineering/RAG

LightRAG

alchemine 2025. 8. 21. 19:59

이전 글에서 GraphRAG를 소개하면서 새로운 데이터가 업데이트될 때 많은 시간이 소요된다는 한계점을 알아보았습니다.

이번 글에서는 계층구조를 사용하지 않고 포괄적인 정보를 찾고자 했던 LightRAG에 대해 알아봅시다.

 


Image from https://github.com/HKUDS/LightRAG

LIGHTRAG: SIMPLE AND FAST RETRIEVAL-AUGMENTED GENERATION
by Beijing University of Posts and Telecommunications, University of Hong Kong

기존 연구들의 한계점
기존 RAG 시스템은 텍스트의 지역성(flat data representations)으로 인한 한계를 가지며 문맥을 제대로 이해하지 못함

제안방법
Low-level 및 high-level 지식을 기반으로 포괄적인 정보 검색을 수행하는 dual-level retrieval 시스템 제안

References
- https://arxiv.org/pdf/2410.05779
- https://github.com/HKUDS/LightRAG

 

GraphRAG와 마찬가지로 LightRAG 역시 LLM을 활용하여 knowledge graph를 생성하고, 이를 기반으로 retrieval을 수행하는 graph-based RAG입니다.

LightRAG는 GraphRAG가 arXiv에 제출된 지 반년 후인 2024년 10월에 제안된 알고리즘으로, 답변 성능과 인덱싱의 효율성 등 GraphRAG와 비교하며 우위에 있다는 것을 강하게 언급하며 주목을 받게되었습니다.

 

 

LightRAG가 집중한 것은 다음 세 가지 이슈들입니다.

 

1. 포괄적인 정보 검색 (Comprehensive Information Retrieval)

문서 전체에 퍼져있는 서로 관련된 정보들에 대한 포괄적인 정보 검색

 

2. 탐색 효율성 향상 (Enhanced Retrieval Efficiency)

답변 소요 시간을 줄이기 위해 graph-based knowledge 구조에 대한 탐색 효율성 높이기

 

3. 새로운 데이터에 대한 빠른 적응 (Rapid Adaptation to New Data)

지속적으로 변하는 환경에서 시스템이 유지되기 위한 새로운 데이터에 대한 빠른 처리

 

LightRAG는 이런 문제들을 해결하기 위해 graph-based text indexing paradigmdual-level retrieval framework를 통합했다고 합니다. 어떤 방식을 사용한걸까요?

 


Graph-based Text Indexing

LightRAG Indexing Flowchart. Image from https://github.com/HKUDS/LightRAG

1. Entity, relationship 추출

1) LLM을 이용하여 다양한 entity와 entity 간의 관계를 나타내는 relationship을 추출

  - Entity(node): 이름, 날짜, 장소, 사건 등 특정 개념

  - Relationship(relation, edge): 두 개의 entity가 어떤 관계를 맺고 있는지에 대한 설명

2) 각 entity, relationship에 대하여 key-value pair를 생성

  - Key: 검색을 위한 키워드, value: 관련된 정보에 대한 텍스트 단락

  - 중복된 entities, relations에 대한 중복처리 수행

 

2. Incremental Knowledge Base에 대한 빠른 적응

  - 새로운 데이터가 들어오는 경우, 동일하게 생성된 node set, edge set을 기존 node, edge와 합집합 하여 통합

  - 즉, 기존 그래프를 다시 처리할 필요가 없음 (Seamless Integration of New Data)

 

Dual-level Retrieval Paradigm

LightRAG Retrieval and Querying Flowchart. Image from https://github.com/HKUDS/LightRAG

 

1. Query keywords 추출

  - 사용자의 쿼리로부터 low-level keywords(local query keyword)와 high-level keywords(global query keyword)를 추출


2. 키워드 매칭

  - Entities vector database에서 local query keyword와 관련된 entities를 검색

  - Relations vector database에서 global query keyword와 관련된 relations를 검색

 

3. 고차원적 관련성 통합

  - 선택된 nodes, edges의 one-hop neighboring node 추가

 

4. 콘텍스트 통합 및 답변 생성

  - 선택된 node, edges들에 대한 (이름, 설명, 원본 문서에서 발췌한 텍스트)를 기반으로 답변을 생성

 

 

구현에 대한 이야기가 포함되어 복잡해 보이지만, 핵심 아이디어를 요약하자면 다음과 같습니다.

 

1. 문서에서 핵심 개념(entity, node)과 관계(relationship, edge)들을 추출하여 그래프를 생성

  - 추가 데이터가 입력될 시, 그래프의 node, edge를 union 시킴

2. 사용자의 쿼리로부터 키워드(low-level, high-level)를 추출

3. Low-level 키워드는 node, high-level 키워드는 edge에 대응하여 검색 수행 (+ one-hop neighbors)

4. 검색 결과를 기반으로 답변 생성

 

꽤 간단하죠?

새로운 데이터가 들어오더라도 GraphRAG처럼 community summary를 다시 생성하는 등 인덱싱을 전체적으로 다시 수행할 필요가 없고, 검색 단계에서도 계층적으로 답변을 생성하지 않기 때문에 더욱 효율적이죠.

 

더욱이 GraphRAG를 포함한 몇 가지 RAG 알고리즘들보다 더 좋은 답변 퀄리티를 보여주었다고 하니 인덱싱 효율성과 퍼포먼스까지 잡은 훌륭한 알고리즘처럼 보입니다.

 

 

근본적으로 문서 전체를 아우르는 질문에 답하기 위해선, 문서 전체를 어떤 방식으로든(map-reduce 혹은 배치) 하나의 콘텍스트로 이해해야 할 필요가 있습니다.

가령 다른 정보가 없는 상황에서 다른 chunk에서 언급된 대상을 지칭하는 경우, 대상이 무엇인지 두 개의 chunk를 동시에 보지 않는 이상 무엇인지 알 방도가 없죠.

그러나 LightRAG의 아이디어는 chunk 단위로만 정보를 분석하기 때문에 inter-chunk information 혹은 문서 내에서 정보가 변화하는 상황에서 한계점을 가지고 있습니다.

최근에 나오는 논문들에서 LightRAG의 답변 퀄리티가 GraphRAG 보다 낮게 평가되는 이유 중 일부가 이러한 부분들이 아닐까 싶습니다.

 

QA Performance table. Image from "EraRAG: Efficient and Incremental Retrieval Augmented Generation for Growing Corpora"

 

 

그럼에도 불구하고 여전히 LightRAG는 가장 인기 있는 RAG 알고리즘들 중 하나이고 활발한 오픈소스 기여와 multimodal로의 확장(RAG-Anything)으로 인해 개선과 성장이 기대되는 알고리즘입니다.

 

Star History for LightRAG, RAG-Anything

 


 

다음은 hashing 알고리즘과 계층구조 그래프를 통해 새로운 SOTA의 역사를 써 내려가고 있는 EraRAG를 살펴볼 예정입니다. 과연 EraRAG는 어떻게 문맥을 파악하고 인덱싱 문제를 해결했을까요?

다음 글에서 함께 알아보시죠!