[LightRAG: Simple and Fast Retrieval-Augmented Generation] 논문 정리

한눈에 보기

LightRAG는 RAG를 더 똑똑하게 만들기 위해 문서 조각 대신 엔티티와 관계를 중심에 둔 설계를 제안한다.

핵심은 두 가지다.

• 문서를 그래프 형태로 인덱싱한다.
• 질문을 구체 정보와 주제 정보로 나눠 두 층으로 검색한다.

이 조합 덕분에 답변은 덜 파편화된다.
검색 비용도 줄어든다.
새 문서가 들어와도 전체 인덱스를 다시 만들 필요가 없다.

왜 이 논문이 나왔나

기존 RAG는 보통 문서를 잘게 쪼갠 뒤, 질문과 비슷한 조각을 벡터 검색으로 찾는다.

이 방식은 빠르고 단순하다.
하지만 한계도 분명하다.

• 서로 다른 문서 조각 사이의 관계를 잘 보지 못한다.
• 여러 개념이 얽힌 질문에서 답이 따로 노는 문단 모음이 되기 쉽다.
• 데이터가 커질수록, 무엇이 핵심 연결고리인지 잡기 어렵다.

논문은 이런 문제를 “검색 단위가 너무 평평하다”는 말로 정리한다.
즉, 텍스트를 조각으로만 보면 누가 누구와 연결되는지, 어떤 주제가 어떤 세부 사실과 이어지는지를 놓치기 쉽다는 뜻이다.

LightRAG의 핵심 아이디어

LightRAG는 문서를 읽고 바로 청크를 찾는 대신, 먼저 문서에서 의미 단위의 지도를 만든다.
이 지도는 엔티티와 관계로 구성된 지식 그래프다.

그 다음 질문을 받을 때는 두 방향으로 찾는다.

• 저수준 검색: 특정 엔티티, 속성, 관계를 깊게 찾는다.
• 고수준 검색: 더 넓은 주제와 테마를 따라가며 맥락을 모은다.

이 구조 덕분에 LightRAG는 “정확한 디테일”과 “넓은 문맥”을 동시에 확보하려고 한다.

 

 

주목 포인트: 그림 가운데에서 그래프 인덱스가 만들어진 뒤 오른쪽에서 Low-level Keys와 High-level Keys가 함께 검색으로 이어지는 흐름이 이 논문의 핵심이다.

어떻게 동작하나

1) 문서를 그래프로 바꾼다

LightRAG는 먼저 문서를 작은 청크로 나눈다.
그 후 LLM을 이용해 다음을 뽑아낸다.

• 사람, 조직, 개념, 사건 같은 엔티티
• 엔티티 사이의 관계
• 검색에 바로 쓸 수 있는 짧은 키
• 응답 생성에 쓸 요약된 설명 텍스트

여기서 중요한 점은, 단순히 엔티티 이름만 모으는 것이 아니라는 점이다.
관계에도 검색 키를 붙인다.
그래서 특정 개체를 찾는 질문뿐 아니라, 더 큰 주제를 묻는 질문도 대응할 수 있다.

또한 서로 다른 청크에서 반복 등장한 엔티티와 관계를 합쳐서 그래프를 가볍게 만든다.
이 과정이 검색 효율과 유지 비용을 함께 낮춘다.

2) 질문도 두 층으로 나눈다

이 논문이 특히 흥미로운 이유는 질문 처리 방식에 있다.

LightRAG는 질문에서 두 종류의 신호를 뽑는다.

• 저수준 키워드: 특정 대상, 지표, 세부 항목
• 고수준 키워드: 넓은 개념, 주제, 상위 맥락

예를 들어 “추천 시스템을 평가할 때 어떤 지표가 중요한가?” 같은 질문이라면,
저수준에서는 정확도나 정밀도 같은 항목이 잡힌다.
고수준에서는 추천 시스템 평가라는 큰 주제가 잡힌다.

이후 LightRAG는 저수준 키워드로 정확한 관련 노드와 주변 이웃을 찾고,
고수준 키워드로 더 넓은 관계망과 주제 축을 찾는다.
그래서 답변이 세부 정보만 많거나, 반대로 말만 크고 내용이 빈약한 상태로 흐르지 않도록 설계되어 있다.

 

주목 포인트: 맨 위의 Query가 Keywords로 분해되고, 그 결과가 Retrieval Context를 거쳐 LLM Response로 이어지는 연결이 두 단계 검색의 실제 작동 모습을 보여준다.

 

3) 새 데이터가 들어와도 전체를 다시 만들지 않는다

LightRAG의 실무적 장점은 여기서 더 분명해진다.

새 문서가 들어오면, 기존 그래프를 버리고 처음부터 다시 만드는 대신
새 문서만 같은 방식으로 처리한 뒤 기존 그래프에 합친다.

이 말은 곧 다음을 의미한다.

• 업데이트 반영이 빠르다.
• 기존 연결 구조를 유지할 수 있다.
• 대규모 코퍼스에서 재색인 비용을 크게 줄일 수 있다.

그래프를 쓴다고 해서 반드시 무거워지는 것은 아니라는 점을 이 논문은 강조한다.
오히려 잘 설계하면 운영 면에서 더 유리할 수 있다는 주장이다.

실험은 어떻게 했나

실험은 UltraDomain 벤치마크의 네 개 도메인에서 진행됐다.

• Agriculture: 약 202만 토큰
• CS: 약 231만 토큰
• Legal: 약 508만 토큰
• Mix: 약 61만 토큰

질문은 각 데이터셋마다 125개씩 만들었다.
특히 단순 사실 확인보다 전체 코퍼스를 이해해야 풀 수 있는 질문에 초점을 맞췄다.

비교 대상은 다음 네 가지다.

• NaiveRAG
• RQ-RAG
• HyDE
• GraphRAG

평가는 사람 대신 LLM 판정기를 사용했다.
기준은 네 가지다.

• Comprehensiveness
• Diversity
• Empowerment
• Overall

즉, 이 논문은 “정답 하나 맞히기”보다
얼마나 넓고 깊고 유용하게 설명하느냐를 더 중요하게 본다.

핵심 결과 1: 청크 중심 RAG보다 확실히 강하다

결과는 꽤 분명하다.

NaiveRAG와 비교한 Overall 승률만 봐도 LightRAG는 다음 수치를 기록했다.

• Agriculture: 67.6%
• CS: 61.2%
• Legal: 84.8%
• Mix: 60.0%

RQ-RAG, HyDE와 비교해도 비슷한 흐름이 나온다.
특히 Legal처럼 문서 규모가 큰 데이터셋에서 격차가 크게 벌어진다.

이 결과는 논문의 핵심 메시지와 맞닿아 있다.
문서가 커지고 연결 관계가 복잡해질수록, 단순 청크 검색만으로는 전체 맥락을 붙잡기 어렵다.
반면 LightRAG는 관계 구조를 같이 보기 때문에 더 긴 호흡의 답변을 만들 수 있다.

 

 

주목 포인트: Legal 열에서 LightRAG의 승률이 특히 높게 나타나는 부분을 보면, 코퍼스가 커질수록 그래프 기반 검색의 장점이 더 뚜렷해진다.

핵심 결과 2: GraphRAG보다도 대체로 낫지만, 항상 압도적이진 않다

같은 그래프 계열인 GraphRAG와 비교하면 이야기는 조금 더 섬세해진다.

Overall 기준으로 LightRAG의 승률은 다음과 같다.

• Agriculture: 54.8%
• CS: 52.0%
• Legal: 52.8%
• Mix: 49.6%

즉, 대부분의 큰 데이터셋에서는 앞서지만
Mix에서는 사실상 비슷하거나 약간 뒤진다.

이 점은 중요하다.
논문이 강한 결과를 보여주긴 하지만, GraphRAG를 완전히 압도한다고 보기는 어렵다.
다만 Diversity 항목에서는 격차가 꽤 크다.
저수준과 고수준 검색을 함께 쓰기 때문에, 응답이 더 다양한 관점과 연결을 담는다는 해석이 가능하다.

정리하면 이 논문의 메시지는 “그래프를 썼다”보다
그래프를 어떻게 검색하느냐가 중요하다에 가깝다.

핵심 결과 3: 저수준 검색과 고수준 검색을 같이 써야 한다

저자들은 설계 요소를 하나씩 제거하는 실험도 했다.

결과는 직관적이다.

• 고수준 검색 제거(-High): 세부 엔티티는 잘 보지만, 넓은 맥락이 약해진다.
• 저수준 검색 제거(-Low): 전반적 주제는 잡지만, 디테일이 얕아진다.
• 둘 다 사용하는 전체 모델: 가장 균형이 좋다.

흥미로운 점은 원문 텍스트를 빼고 그래프 의미 정보만 써도 성능이 크게 떨어지지 않았다는 점이다.
저자들은 이를 두고, 잘 뽑힌 엔티티·관계·요약 정보만으로도 질문 응답에 필요한 핵심 맥락이 상당 부분 보존된다고 해석한다.

이 결과는 실무적으로도 시사점이 있다.
원문을 무조건 많이 넣는 것이 항상 좋은 전략은 아니다.
때로는 정제된 구조 정보가 더 적은 잡음으로 더 좋은 답변을 만들 수 있다.

 

 

주목 포인트: -High와 -Low 변형이 각각 다른 축에서 약해지는 모습을 보면, LightRAG의 성능이 한 가지 트릭이 아니라 두 단계 검색의 조합에서 나온다는 점이 드러난다.

비용과 운영 측면에서 왜 의미가 큰가

이 논문에서 가장 실용적인 장점은 성능보다도 비용 구조일 수 있다.

Legal 데이터셋 기준으로,
GraphRAG는 검색 시 다수의 커뮤니티 리포트를 훑어야 해서 토큰 사용량이 매우 크다.
논문은 이 비용을 약 61만 토큰 수준으로 설명한다.

반면 LightRAG는 검색 시 키워드 생성과 매칭 중심으로 움직인다.
그래서 검색 단계 토큰 사용량을 100 토큰 미만으로 줄였다고 보고한다.
API 호출도 사실상 한 번으로 끝난다.

업데이트 단계 차이도 크다.

• GraphRAG는 새 데이터가 들어오면 커뮤니티 구조를 다시 만들 가능성이 크다.
• LightRAG는 새 엔티티와 관계를 기존 그래프에 붙이면 된다.

즉, LightRAG의 강점은 “정답 품질이 조금 더 좋다”에만 있지 않다.
검색과 업데이트를 운영 가능한 비용으로 유지한다는 점이 훨씬 큰 장점이다.

 

 

주목 포인트: 왼쪽의 검색 단계에서 GraphRAG가 큰 토큰 비용을 쓰는 반면, LightRAG는 아주 적은 검색 비용으로 끝나는 대비가 가장 중요하다.

이 논문의 장점

1) 복합 질문에 강한 설계다

여러 문서를 가로질러 관계를 묻는 질문에 잘 맞는다.
특히 “무엇이 무엇에 어떤 영향을 주는가” 같은 질문에서 강점이 있다.

2) 검색 품질과 검색 비용을 같이 본다

많은 논문이 품질만 강조한다.
반면 이 논문은 토큰 비용과 API 호출 수를 함께 보여준다.
실제 서비스 관점에서는 꽤 중요한 시각이다.

3) 증분 업데이트가 실무적이다

지식베이스가 자주 바뀌는 환경에서는 전체 재색인이 큰 부담이다.
LightRAG는 이 지점을 정면으로 다룬다.

아쉬운 점과 한계

1) 평가는 결국 LLM 판정기에 크게 의존한다

사람 평가가 아니라 LLM 비교 평가가 중심이다.
이 방식은 빠르고 유연하지만, 판정 기준이 모델 특성에 영향을 받을 수 있다.

2) GraphRAG 대비 격차는 생각보다 크지 않다

GraphRAG보다 대체로 좋지만,
데이터셋에 따라 차이는 작고 Mix에서는 오히려 Overall에서 밀린다.
즉, “그래프 계열 최강”이라고 단정하기에는 아직 조심스러운 면이 있다.

3) 엔티티·관계 추출 품질에 많이 기대고 있다

초기 추출이 흔들리면 이후 검색도 흔들린다.
그래프 기반 RAG의 강점은 동시에 약점이기도 하다.
구조를 잘 만들면 강하지만, 구조가 틀리면 오답도 더 그럴듯하게 연결될 수 있다.

4) 벤치마크 질문이 고수준 이해 작업에 치우쳐 있다

이 논문은 전체 코퍼스 이해가 필요한 질문에 강하다.
반대로 아주 짧고 단순한 사실 검색에서는 이 구조가 과할 수도 있다.

실무에서 어떻게 봐야 하나

다음 조건이라면 LightRAG 계열 접근이 특히 유효해 보인다.

• 문서량이 많다.
• 문서 사이 연결 관계가 중요하다.
• 질문이 단순 키워드 검색을 넘어선다.
• 데이터가 자주 업데이트된다.

반대로 문서가 작고, 질문이 짧고, 정답이 한 문장으로 끝나는 환경이라면
NaiveRAG 같은 더 단순한 구조가 여전히 더 합리적일 수 있다.

결론

LightRAG의 핵심은 “그래프를 썼다”가 아니다.
질문을 두 층으로 해석하고, 그래프와 벡터 검색을 함께 써서 디테일과 맥락을 동시에 모은다는 데 있다.

이 설계는 대규모 코퍼스와 복합 질의에서 분명한 장점을 보인다.
특히 검색 비용과 업데이트 비용까지 고려하면, GraphRAG보다 더 현실적인 대안으로 읽힌다.

다만 모든 환경에서 무조건 우세한 것은 아니다.
작은 데이터셋이나 단순 질의에서는 복잡성이 이득을 압도하지 못할 수 있다.

그래도 “RAG를 더 잘 붙이는 법”이 아니라
RAG가 검색해야 할 지식 구조 자체를 다시 설계한 논문이라는 점에서, 꽤 오래 참고할 가치가 있는 작업이다.

Source

• Zirui Guo, Lianghao Xia, Yanhua Yu, Tu Ao, Chao Huang, LightRAG: Simple and Fast Retrieval-Augmented Generation, arXiv:2410.05779v3, 2025.
  https://arxiv.org/abs/2410.05779
• Project repository:
  https://github.com/HKUDS/LightRAG