LightRAG: RAG dựa trên Graph nhưng nhẹ và nhanh hơn GraphRAG

1. Tổng quan

RAG dựa trên vector search thuần túy có một điểm yếu quen thuộc: nó tìm các đoạn văn bản giống câu hỏi về mặt ngữ nghĩa, nhưng không thực sự hiểu được các thực thể trong dữ liệu liên hệ với nhau ra sao. Vì vậy, với những câu hỏi đòi hỏi kết nối thông tin rải rác qua nhiều tài liệu, hoặc cần một cái nhìn tổng hợp về cả một tập dữ liệu lớn, cách tiếp cận chunk-and-embed thường cho câu trả lời rời rạc, thiếu mạch lạc.

GraphRAG (Microsoft Research) giải quyết vấn đề này bằng cách dựng knowledge graph từ corpus, phân cụm thành các community bằng thuật toán Leiden, rồi tóm tắt từng cụm để phục vụ truy vấn. Cách làm này cho kết quả tốt với các câu hỏi mang tính tổng hợp, nhưng đi kèm chi phí không nhỏ: pipeline indexing nhiều bước, và ở pha truy vấn — đặc biệt là Global Search — hệ thống phải duyệt qua hàng trăm, hàng nghìn community report, kéo theo số lượng LLM call và token tiêu tốn rất lớn. (Nếu muốn tìm hiểu chi tiết, bạn có thể đọc bài GraphRAG: Từ Knowledge Graph đến RAG thế hệ mới.)

LightRAG (Guo et al., HKU & BUPT, EMNLP 2025) ra đời để giải quyết đúng vấn đề đó. Về bản chất, LightRAG vẫn là một hệ thống RAG dựa trên graph — vẫn dùng LLM để trích entity và relationship từ văn bản, dựng thành knowledge graph. Nhưng nó bỏ hẳn khái niệm "community" và "community report" của GraphRAG, thay bằng một cơ chế gọi là dual-level retrieval: truy vấn trực tiếp trên entity/relationship kết hợp vector search, không cần bước phân cụm hay Community Report.

Ba mục tiêu chính mà nhóm tác giả đặt ra khi thiết kế LightRAG:

• Comprehensive Information Retrieval — vẫn phải nắm được thông tin toàn cục, không chỉ chi tiết cục bộ.
• Enhanced Retrieval Efficiency — giảm đáng kể thời gian phản hồi so với cách duyệt community truyền thống.
• Rapid Adaptation to New Data — khi có tài liệu mới, không cần build lại toàn bộ index.

Phần tiếp theo sẽ đi sâu vào kiến trúc Indexing và cơ chế Dual-level Retrieval — hai phần tạo nên sự khác biệt cốt lõi so với GraphRAG.

2. Kiến trúc Indexing

Indexing của LightRAG gồm 3 hàm xử lý chính, áp dụng tuần tự lên từng chunk văn bản sau bước chia nhỏ (chunking) ban đầu:

2.1 R(·) — Extracting Entities and Relationships

LLM đọc từng chunk văn bản, nhận diện các entity (node) như tên người, địa điểm, sự kiện, tổ chức... và các relationship (edge) mô tả mối quan hệ giữa chúng. Ví dụ, từ một câu mô tả công việc của bác sĩ tim mạch, hàm này có thể trích ra entity "Bác sĩ tim mạch", "Bệnh tim", "Bệnh viện", cùng các relationship như "chẩn đoán", "làm việc tại" nối giữa chúng.

2.2 P(·) — LLM Profiling

Đây là bước tạo nên đặc trưng riêng của LightRAG. Với mỗi entity và relationship vừa trích ở bước trên, LLM sinh ra một cặp key-value:

• Key là tên hoặc cụm từ ngắn dùng để tra cứu nhanh — entity chỉ có đúng một key là tên của nó, còn relationship có thể có thêm các key bổ sung gọi là global keyword, rút ra từ chủ đề chung của các entity liên quan.
• Value là đoạn văn bản tóm tắt, tổng hợp lại nội dung liên quan từ dữ liệu gốc, dùng làm ngữ cảnh khi sinh câu trả lời sau này.

Cơ chế key-value này chính là nền tảng cho bước Dual-level Retrieval ở phần 3: key cấp entity phục vụ truy vấn chi tiết (low-level), còn global keyword ở relationship phục vụ truy vấn khái quát (high-level).

2.3 D(·) — Deduplication

Cùng một entity hay relationship có thể được trích ra từ nhiều chunk khác nhau trong tài liệu. Bước Deduplication gộp các bản trùng lặp đó thành một node/edge duy nhất, giúp giảm kích thước graph và tránh nhiễu khi truy vấn.

Việc gộp này có tác động trực tiếp đến cấu trúc kết nối của graph: khi hai entity trùng tên và loại được gộp lại, mọi cạnh mà từng bản ghi rời rạc từng có đều được dồn về node hợp nhất. Đây chính là cơ chế giúp LightRAG kết nối được thông tin xuyên suốt toàn bộ tài liệu — một node có thể tích lũy quan hệ từ nhiều đoạn văn bản cách xa nhau. Điểm cần lưu ý là cơ chế dedup này khớp theo tên và loại entity chứ chưa phải entity resolution theo ngữ nghĩa sâu, nên nếu tài liệu có hai thực thể khác nhau nhưng trùng tên, hệ thống có thể gộp nhầm.

2.4 Không có bước phân cụm cộng đồng

So với GraphRAG, khác biệt lớn nhất nằm ở chỗ pipeline indexing của LightRAG dừng lại ở đây — không có bước phân cụm bằng thuật toán Leiden, không có bước sinh community report. Toàn bộ tri thức được lưu trực tiếp dưới dạng entity/relationship kèm key-value, sẵn sàng cho truy vấn. Đây là lý do khiến chi phí indexing của LightRAG về cơ bản tương đương GraphRAG ở phần trích xuất (đều tỉ lệ với số lượng chunk), nhưng không phát sinh thêm chi phí cho việc dựng và tóm tắt cộng đồng.

2.5 Cập nhật dữ liệu tăng dần (Incremental Update)

Khi có tài liệu mới, LightRAG chỉ chạy đúng 3 hàm R, P, D ở trên cho riêng tài liệu đó để tạo ra một graph con, sau đó hợp (union) tập node và tập cạnh mới vào graph hiện có — không cần đụng đến các entity/relationship đã tồn tại. Đây là điểm khác biệt nền tảng so với GraphRAG, nơi việc thêm dữ liệu mới có thể kéo theo phải tính lại toàn bộ cấu trúc cộng đồng.

3. Dual-level Retrieval

Nếu Indexing là nơi LightRAG "nhẹ hơn" GraphRAG ở khâu xử lý sau khi trích xuất, thì Dual-level Retrieval là nơi tạo ra khác biệt rõ nhất ở tốc độ truy vấn.

3.1 Hai loại truy vấn mà hệ thống cần xử lý

Nhóm tác giả phân loại câu hỏi người dùng thành hai dạng:

• Specific queries — hướng đến một entity cụ thể, ví dụ "Ai viết cuốn Pride and Prejudice?".
• Abstract queries — mang tính khái niệm, chủ đề rộng, ví dụ "AI ảnh hưởng thế nào đến giáo dục hiện đại?".

Tương ứng với hai dạng câu hỏi này là hai tầng truy xuất:

• Low-level retrieval — tập trung vào entity cụ thể và thuộc tính/quan hệ trực tiếp của nó.
• High-level retrieval — tập trung vào chủ đề rộng, tổng hợp thông tin qua nhiều entity và relationship liên quan.

3.2 Quy trình truy vấn: 3 bước

Bước 1 — Query Keyword Extraction. LLM đọc câu hỏi và tách ra đồng thời hai loại từ khóa: low-level keyword (trỏ đến entity cụ thể) và high-level keyword (mang tính chủ đề, khái quát). Cả hai loại từ khóa được sinh ra cùng lúc cho mọi câu hỏi — không cần biết trước câu hỏi thuộc dạng nào.

Bước 2 — Keyword Matching. Hệ thống dùng vector database để khớp low-level keyword với các entity đã index, và khớp high-level keyword với các relationship có global keyword tương ứng. Đây là bước thay thế hoàn toàn cho việc duyệt community report của GraphRAG.

Bước 3 — Incorporating High-Order Relatedness. Từ tập entity/relationship vừa khớp được, hệ thống lấy thêm các node lân cận trực tiếp (1-hop neighbor) trong graph để làm giàu ngữ cảnh — nhờ cơ chế deduplication ở bước 2.3, một entity có thể mang theo quan hệ từ nhiều phần khác nhau của tài liệu, nên bước mở rộng này thường lấy được nhiều thông tin liên quan hơn là chỉ nhìn vào đúng entity được hỏi.

Kết quả của cả ba bước — entity, relationship, và đoạn text gốc liên quan — được gộp thành Context, đưa cùng câu hỏi vào LLM để sinh câu trả lời cuối cùng.

3.3 Vì sao cách này nhanh hơn GraphRAG

Theo phân tích chi phí trong paper (đo trên bộ dữ liệu Legal), ở pha truy vấn GraphRAG cần duyệt qua 610 community report (mỗi report khoảng 1.000 token), tổng cộng khoảng 610.000 token và hàng trăm lệnh gọi API. LightRAG chỉ cần dưới 100 token để sinh từ khóa và một lệnh gọi API duy nhất cho toàn bộ quá trình truy vấn — vì retrieval dựa trên vector search trực tiếp trên entity/relationship, không phải duyệt tuần tự qua từng community report.

3.4 Từ "dual-level" trong paper đến 5 query mode trong thực tế

Về mặt thiết kế thuật toán, dual-level retrieval là cơ chế mặc định chạy tự động cho mọi câu hỏi — không giống GraphRAG, nơi người dùng phải chủ động chọn 1 trong 4 mode (Local/Global/DRIFT/Basic) tùy loại câu hỏi. Tuy nhiên, khi triển khai thực tế, repo GitHub của LightRAG có expose thêm các lựa chọn nâng cao để tối ưu tốc độ/chi phí khi người dùng biết rõ nhu cầu:

Vì mix là mặc định, phần lớn người dùng không cần chọn gì — hệ thống đã tự làm cả hai tầng cùng lúc. Các mode còn lại tồn tại như tùy chọn tối ưu, không phải yêu cầu bắt buộc.

4. So sánh với GraphRAG

Trong đánh giá thực nghiệm trên 4 bộ dữ liệu benchmark (Agriculture, CS, Legal, Mix), LightRAG cho kết quả nhỉnh hơn GraphRAG ở phần lớn tiêu chí đánh giá (Comprehensiveness, Diversity, Empowerment), đặc biệt vượt trội ở Diversity nhờ cơ chế dual-level giúp vừa khai thác chi tiết vừa bao quát chủ đề — trong khi chi phí truy vấn thấp hơn hẳn.

Điều đó không có nghĩa GraphRAG lỗi thời: cấu trúc community đa tầng của GraphRAG vẫn có giá trị riêng khi cần một bản tóm tắt tường minh, có thể đọc được ở nhiều mức độ chi tiết khác nhau của cả một corpus — thứ mà LightRAG không tạo ra tường minh vì nó bỏ hẳn bước sinh report.

5. Kết luận

LightRAG giữ lại phần cốt lõi làm nên sức mạnh của graph-based RAG — khả năng kết nối thông tin qua entity và relationship — nhưng loại bỏ phần tốn kém nhất trong pipeline của GraphRAG: bước phân cụm cộng đồng và sinh report. Đổi lại là một hệ thống truy vấn nhanh hơn đáng kể, chi phí thấp hơn, và đặc biệt phù hợp với môi trường dữ liệu thay đổi liên tục nhờ cơ chế cập nhật tăng dần không cần build lại toàn bộ index.

Nếu GraphRAG phù hợp với bài toán cần một bản tóm tắt vĩ mô, có cấu trúc rõ ràng cho cả một tập dữ liệu lớn và tĩnh, thì LightRAG là lựa chọn hợp lý hơn khi ưu tiên tốc độ phản hồi, chi phí vận hành, và khả năng thích ứng với dữ liệu cập nhật thường xuyên — điều thường gặp trong các ứng dụng thực tế ở lĩnh vực pháp lý, y tế, hay tài chính mà chính nhóm tác giả nhắm tới.

Tài liệu tham khảo

1. Guo, Z., Xia, L., Yu, Y., Ao, T., Huang, C. "LightRAG: Simple and Fast Retrieval-Augmented Generation." arXiv:2410.05779. https://arxiv.org/pdf/2410.05779
2. HKUDS. "LightRAG" (GitHub repository). https://github.com/hkuds/lightrag
3. Edge, D. et al. "From Local to Global: A Graph RAG Approach to Query-Focused Summarization." arXiv:2404.16130. https://arxiv.org/pdf/2404.16130