한 줄 정의
LightRAG는 문서에서 사람, 조직, 제품, 사건 같은 이름을 뽑고 그 사이의 관계를 저장한 뒤, 일반 벡터 검색과 함께 답변 근거를 찾는 RAG 도구야. 예를 들어 “지난 장애가 어떤 고객, 어떤 제품, 어떤 패치와 이어졌나”처럼 여러 문서의 연결을 묻는 질문에서 일반 벡터 RAG와 갈려.
2026.03에는 OpenSearch 연동이 추가됐고, 2025.11에는 RAGAS 평가와 Langfuse 추적 흐름이 붙었어. 그래서 LightRAG는 검색 정확도만 볼 게 아니라 저장소, 평가, 추적까지 같이 운영할 수 있는지 보는 항목이야.
실제로 무엇을 하나
- 문서를 넣으면 embedding으로 검색용 벡터를 만들고, 이름과 관계도 따로 뽑아 저장해.
- 질문이 들어오면 vector DB 검색 결과와 관계 정보를 함께 보고 답변에 쓸 문맥을 고른다.
- 품질 확인은 benchmark처럼 고정 질문 묶음을 만들고, RAGAS로 문맥 적합도를 재고, Langfuse로 어떤 문맥이 답변에 쓰였는지 따라가는 방식으로 시작하면 돼.
왜 중요한가
벡터 검색은 비슷한 문장을 잘 찾지만, 여러 문서에 흩어진 관계를 따라가야 할 때 약해질 수 있어. LightRAG는 이 관계 추적을 앞단에서 만들어 두려는 선택지야.
다만 문서 100개 정도의 작은 묶음으로 먼저 시험하는 게 좋아. 관계 추출, 저장소 운영, 문서 삭제 후 재색인까지 비용이 늘어나기 때문이야.
언제 쓰고 언제 넘기나
- 쓸 때: 장애 보고서, 고객 이력, 제품 문서처럼 이름과 관계를 따라가야 하는 질문이 많다면 시험해 볼 만해.
- 쓸 때: RAG 답변이 왜 나왔는지 추적하고 평가 로그를 남겨야 하는 서비스라면 평가·추적 흐름이 도움이 돼.
- 넘길 때: FAQ나 짧은 매뉴얼처럼 키워드 검색으로 충분하면 관계 추출 비용이 과해질 수 있어.
주의해서 볼 점
그래프 RAG는 모델 호출 비용을 줄이는 마법이 아니야. 문서가 커질수록 이름·관계 추출, 관계 저장소 갱신, 삭제 후 재생성, 저장소 운영이 비용의 중심이 돼.
한국어 사내 약어, 제품 코드, 고객명처럼 표준화되지 않은 말이 많으면 관계 추출 품질이 흔들릴 수 있어. 작은 검증에서는 답변 품질뿐 아니라 색인 시간과 업데이트 지연도 같이 재야 해.