GraphRAG: Từ Knowledge Graph đến RAG thế hệ mới

1. Tổng quan

RAG truyền thống và giới hạn của nó

Retrieval-Augmented Generation (RAG) là kỹ thuật giúp LLM trả lời chính xác hơn bằng cách bổ sung thông tin thực tế lấy từ nguồn dữ liệu ngoài, thường là dữ liệu riêng tư mà mô hình chưa từng được huấn luyện (tài liệu nội bộ doanh nghiệp, hồ sơ nghiên cứu...). Cách phổ biến nhất — gọi là Baseline RAG — dùng vector similarity search: văn bản được chia nhỏ, embed thành vector, rồi tìm các đoạn gần nhất với câu hỏi.

Cách làm này hoạt động tốt với các câu hỏi tra cứu sự kiện đơn lẻ, nhưng bộc lộ hai điểm yếu rõ rệt:

• Không kết nối được các mẩu thông tin rời rạc. Khi câu trả lời đòi hỏi phải nối nhiều đoạn dữ liệu khác nhau qua các thuộc tính chung để tạo ra một insight tổng hợp, vector search từng đoạn riêng lẻ không đủ để "nhìn thấy" mối liên hệ đó.
• Yếu ở các câu hỏi mang tính tổng hợp toàn cục. Ví dụ "chủ đề chính của toàn bộ tập dữ liệu này là gì?" — loại câu hỏi này cần hiểu khái quát cả một tập văn bản lớn, chứ không phải chỉ vài đoạn trích gần nhất về mặt ngữ nghĩa.

GraphRAG giải quyết vấn đề như thế nào

GraphRAG (Microsoft Research) tiếp cận theo hướng khác: thay vì chỉ lưu các đoạn văn bản dưới dạng vector, nó dựng lên một knowledge graph từ corpus đầu vào, sau đó phân cụm graph đó thành các community (cộng đồng thực thể có liên quan chặt với nhau) và tạo summary cho từng cộng đồng theo kiểu bottom-up. Khi truy vấn, hệ thống dùng chính cấu trúc graph + summary này để cung cấp ngữ cảnh cho LLM, thay vì chỉ dựa vào độ tương đồng ngữ nghĩa của từng đoạn text rời rạc.

Nhờ vậy, GraphRAG thể hiện tốt hơn hẳn baseline RAG ở đúng hai lớp câu hỏi mà baseline RAG yếu: câu hỏi cần "nối các điểm dữ liệu" và câu hỏi cần hiểu tổng thể một tập văn bản lớn.

Về tổng thể, quy trình GraphRAG gồm hai giai đoạn lớn:

• Indexing — xây dựng knowledge graph, phân cụm cộng đồng, sinh summary cho từng cộng đồng.
• Query — dùng các cấu trúc đã index để trả lời câu hỏi, với nhiều chế độ tìm kiếm khác nhau tùy loại câu hỏi.

Hai phần này sẽ được đi sâu ở mục 2 và mục 3.

2. Indexing: Kiến trúc và 6 phase

2.1 Kiến trúc tổng thể

Sơ đồ pipeline indexing cơ bản của GraphRAG (nguồn: microsoft.github.io/graphrag/index/architecture)

Indexing pipeline của GraphRAG được thiết kế như một chuỗi workflow module hóa, mỗi workflow đọc dữ liệu do bước trước sinh ra và ghi ra artifact riêng (Parquet). Toàn bộ đầu ra được chuẩn hóa theo một Knowledge Model chung — một lớp trừu tượng để tách biệt logic xử lý khỏi công nghệ lưu trữ bên dưới (file, blob, CosmosDB...). Knowledge Model định nghĩa các đối tượng cốt lõi:

Đối tượng	Ý nghĩa
Document	Tài liệu đầu vào (một dòng CSV hoặc một file .txt)
TextUnit	Đoạn văn bản nhỏ dùng để phân tích
Entity	Thực thể được trích xuất từ TextUnit (người, địa điểm, tổ chức...)
Relationship	Quan hệ giữa hai entity
Covariate	Claim (phát biểu) được trích xuất, có thể gắn mốc thời gian
Community	Cụm entity/relationship sau khi phân cụm phân cấp
Community Report	Bản tóm tắt nội dung của một community

Vì dùng LLM ở nhiều bước, pipeline có sẵn một lớp cache cho các lời gọi LLM: nếu cùng một input (prompt + tham số) đã được gọi trước đó, kết quả cache sẽ được tái sử dụng — giúp pipeline chịu lỗi mạng tốt hơn, chạy idempotent, và tiết kiệm chi phí khi phải chạy lại. Ngoài ra, các thành phần như language model, input reader, cache, storage, vector store, logger đều được xây theo factory pattern, cho phép tự implement provider riêng nếu cần.

2.2 Sáu phase của pipeline

Pipeline mặc định biến tài liệu thô thành Knowledge Model qua 6 phase tuần tự:

Phase 1 — Compose TextUnits (chia nhỏ văn bản) Tài liệu đầu vào được cắt thành các TextUnit — đơn vị văn bản nhỏ dùng cho các bước trích xuất graph phía sau, đồng thời đóng vai trò tham chiếu nguồn gốc (provenance) cho các kết quả sau này. Kích thước chunk (tính theo token) có thể cấu hình, mặc định 1200 token. Chunk lớn hơn giúp xử lý nhanh hơn nhưng làm giảm độ chính xác của kết quả trích xuất và độ hữu ích của đoạn tham chiếu.

Phase 2 — Document Processing (xử lý tài liệu) Mỗi Document được liên kết ngược lại với các TextUnit thuộc về nó, để biết tài liệu nào sinh ra text-unit nào. Kết quả của bước này là bảng Documents — phục vụ mục đích truy vết nguồn, bản thân bảng này không được dùng trực tiếp trong quá trình truy vấn.

Phase 3 — Graph Extraction (trích xuất graph) Đây là phase trích xuất tri thức cốt lõi: từ mỗi TextUnit, LLM trích ra Entity (có title, type, description) và Relationship (có source, target, description). Các entity trùng title/type từ nhiều TextUnit khác nhau sẽ được gộp lại (mô tả gộp thành mảng), tương tự với relationship trùng source/target. Sau đó một bước tóm tắt (Entity & Relationship Summarization) dùng LLM để nén danh sách mô tả thành một mô tả duy nhất, súc tích cho mỗi entity/relationship. Song song đó có bước Claim Extraction (tùy chọn, mặc định tắt) để trích các phát biểu thực tế có gắn trạng thái đánh giá và mốc thời gian — kết quả xuất ra dưới dạng Covariates.

Phase 4 — Graph Augmentation (phân cụm cộng đồng) Từ graph entity-relationship đã có, GraphRAG áp dụng thuật toán Hierarchical Leiden (tìm hiểu chi tiết về thuật toán Leiden) để phân cụm phân cấp (recursive clustering đến khi đạt ngưỡng kích thước cụm). Kết quả là một cấu trúc community đa tầng: tầng cao là các cụm lớn bao trùm nhiều entity, tầng thấp là các cụm nhỏ, gắn kết chặt hơn. Cấu trúc này giúp điều hướng và tóm tắt graph ở nhiều mức độ chi tiết khác nhau. Sau bước này, các bảng Entities, Relationships, Communities chính thức được xuất ra.

Phase 5 — Community Summarization (tóm tắt cộng đồng) Với mỗi community ở mỗi tầng, LLM sinh ra một Community Report — gồm phần tóm tắt tổng quan (executive overview) cùng các entity, relationship, claim then chốt trong cụm đó. Report ở tầng cao cho cái nhìn khái quát toàn graph; report ở tầng thấp cho cái nhìn chi tiết về một cụm cục bộ. Sau khi sinh report, một bước tóm tắt bổ sung (Summarize Community Reports) tạo bản rút gọn hơn nữa để dùng nhanh trong quá trình truy vấn. Kết quả cuối là bảng Community Reports.

Phase 6 — Text Embedding (nhúng vector) Ở bước cuối, các nội dung cần phục vụ vector search — text của TextUnit, mô tả entity/relationship, nội dung community report — được embed thành vector và ghi vào vector store đã cấu hình. Đây chính là phần "vector" bổ trợ cho phần "graph", giúp GraphRAG vẫn tận dụng được sức mạnh của semantic search khi cần.

Lưu ý chi phí: quá trình indexing gọi LLM rất nhiều lần (trích entity, tóm tắt, sinh report...) nên có thể tốn kém đáng kể, đặc biệt với corpus lớn. Tài liệu chính thức khuyến cáo nên bắt đầu với tập dữ liệu nhỏ và đọc kỹ phần cấu hình trước khi chạy index trên corpus lớn.

3. Query: 4 cách search

Sau khi index xong, GraphRAG cung cấp Query Engine với 4 chế độ tìm kiếm, mỗi chế độ phù hợp với một dạng câu hỏi khác nhau.

3.1 Local Search

Local Search kết hợp dữ liệu từ knowledge graph (entity, relationship liên quan) với các đoạn văn bản gốc để trả lời. Phù hợp với câu hỏi xoay quanh một thực thể cụ thể được nhắc đến trong tài liệu — ví dụ "công dụng chữa bệnh của hoa cúc là gì?". Cơ chế "fan-out": xuất phát từ entity liên quan trực tiếp đến câu hỏi, rồi mở rộng ra các entity/relationship lân cận để lấy đủ ngữ cảnh.

Có thể thấy Local Search không chỉ dừng ở entity liên quan trực tiếp: từ tập entity đó, nó mở rộng song song ra text unit gốc, community report, relationship, covariate (claim) và cả lịch sử hội thoại — gộp tất cả lại thành một context duy nhất trước khi đưa vào LLM để sinh câu trả lời.

3.2 Global Search

Global Search tìm kiếm trên toàn bộ các community report đã sinh ở phase 5, theo cơ chế map-reduce: chia nhỏ câu hỏi ra để đối chiếu với từng report, rồi tổng hợp (reduce) các câu trả lời cục bộ thành câu trả lời cuối. Đây là chế độ tốn tài nguyên nhất trong 4 chế độ, nhưng cho kết quả tốt với các câu hỏi đòi hỏi hiểu biết tổng thể về toàn bộ dataset — ví dụ "những giá trị quan trọng nhất của các loại thảo mộc được nhắc đến trong tài liệu này là gì?".

Ý tưởng cốt lõi là map-reduce: toàn bộ community report được xáo trộn (shuffle) và chia thành nhiều batch nhỏ để xử lý song song — mỗi batch được LLM tóm tắt thành một RIR (Rated Intermediate Response, câu trả lời trung gian có chấm điểm mức độ liên quan). Các RIR này sau đó được xếp hạng, lọc lấy những phần tốt nhất, rồi tổng hợp (aggregation) thành câu trả lời cuối cùng. Việc chia batch và xử lý song song là lý do khiến Global Search vừa tốn tài nguyên vừa có khả năng bao quát toàn bộ dataset.

Chất lượng của Global Search phụ thuộc trực tiếp vào chất lượng các community report — mà community report lại phụ thuộc vào thuật toán Leiden ở Phase 4 (xem mục 2.3).

3.3 DRIFT Search

DRIFT (Dynamic Reasoning and Inference with Flexible Traversal) là kỹ thuật kết hợp cả Global Search lẫn Local Search, chứ không đơn thuần là mở rộng của một trong hai. Ý tưởng là tận dụng độ phủ rộng của Global Search (thông qua community report) để xác định điểm khởi đầu, sau đó dùng độ chính xác của Local Search để đào sâu chi tiết — nhờ vậy DRIFT đạt được cả bề rộng lẫn chiều sâu mà không phải trả chi phí tính toán như khi chạy toàn bộ Global Search trên mọi community report.

DRIFT bắt đầu bằng bước PRIMER: đối chiếu câu hỏi với các community report để tìm ra điểm khởi đầu phù hợp, đồng thời sinh ra một câu trả lời sơ bộ (initial answer) kèm theo các câu hỏi follow-up chi tiết hơn. Mỗi follow-up question sau đó được đưa qua Local Search riêng để lấy câu trả lời cụ thể, và bản thân các câu trả lời này lại có thể tiếp tục sinh ra follow-up question mới — tạo thành một quá trình lặp nhiều vòng. Toàn bộ các câu trả lời và câu hỏi phụ được tổ chức thành một output hierarchy, sau đó tổng hợp lại thành câu trả lời cuối cùng. Cơ chế lặp này chính là lý do DRIFT vừa giữ được độ sâu như Local Search, vừa có độ phủ rộng gần với Global Search.

3.4 Basic Search

Basic Search là cài đặt RAG vector thuần túy (top-k text chunk) được tích hợp sẵn trong GraphRAG, chủ yếu để làm baseline đối chiếu kết quả với 3 chế độ graph-based ở trên. Người dùng có thể cấu hình số lượng chunk k đưa vào ngữ cảnh tóm tắt. Đây là lựa chọn phù hợp khi câu hỏi đơn giản, không cần đến cấu trúc graph hay community.

Chọn chế độ nào?

Chế độ	Phù hợp khi
Local Search	Hỏi về một entity/chủ đề cụ thể trong tài liệu
Global Search	Hỏi mang tính tổng hợp, khái quát toàn bộ corpus
DRIFT Search	Cần độ sâu của local search nhưng vẫn muốn phạm vi rộng như global
Basic Search	Câu hỏi đơn giản, dùng làm baseline so sánh

GraphRAG cũng có thêm tính năng Question Generation — sinh câu hỏi tiếp theo dựa trên danh sách câu hỏi trước đó, hữu ích khi muốn gợi ý câu hỏi follow-up trong hội thoại hoặc khi khám phá sâu một tập dữ liệu.

4. Ưu điểm và hạn chế

Ưu điểm

• Trả lời tốt câu hỏi tổng hợp/toàn cục — nhờ community report theo cấu trúc phân tầng, GraphRAG hiểu được "bức tranh lớn" của cả tập dữ liệu, điều mà vector search từng đoạn nhỏ khó làm được.
• Kết nối thông tin rời rạc — nhờ đi qua entity/relationship trong graph, hệ thống có thể nối các dữ kiện nằm ở nhiều tài liệu/đoạn văn khác nhau để tạo insight mới.
• Nhiều chế độ truy vấn linh hoạt — Local/Global/DRIFT/Basic cho phép chọn đúng chiến lược theo từng loại câu hỏi, thay vì chỉ có một cách tìm kiếm duy nhất.
• Có khả năng truy vết nguồn (provenance) — mọi entity, relationship đều giữ liên kết ngược về TextUnit/Document gốc.

Hạn chế

• Chi phí LLM khi index rất cao. Gần như mọi bước trong 6 phase (trích entity/relationship, tóm tắt, sinh community report...) đều gọi LLM, nên với corpus lớn, số lượng token và chi phí có thể tăng nhanh. Tài liệu chính thức cảnh báo rõ đây là "phép toán tốn kém" và khuyến nghị bắt đầu với dữ liệu nhỏ.
• Độ trễ khi index lớn hơn nhiều so với RAG thường. Xây dựng graph, phân cụm Leiden, sinh report cho từng community ở nhiều tầng là quá trình nhiều bước tuần tự, không thể có kết quả tức thời như việc chỉ embed văn bản.
• Cần re-index khi dữ liệu thay đổi. Với RAG vector thường, thêm tài liệu mới chỉ cần embed thêm; với GraphRAG, thêm dữ liệu có thể kéo theo phải trích lại entity, gộp lại graph, và tính lại community — phức tạp hơn đáng kể.
• Global Search tốn tài nguyên tại thời điểm truy vấn — vì phải quét map-reduce qua nhiều community report, nên chậm và tốn hơn Local/Basic Search.
• Cần prompt tuning để đạt chất lượng tốt. Theo tài liệu chính thức, dùng GraphRAG "out of the box" trên dữ liệu của bạn chưa chắc cho kết quả tốt nhất — cần tinh chỉnh prompt trích xuất theo domain cụ thể.

Khi nào nên dùng GraphRAG, khi nào nên dùng RAG thường

Tình huống	Nên dùng
Corpus nhỏ/vừa, ngân sách LLM hạn chế, cần trả lời nhanh	RAG thường (vector search)
Câu hỏi chủ yếu là tra cứu sự kiện đơn lẻ, rõ ràng	RAG thường
Cần hiểu tổng quan/xu hướng trên toàn bộ tập dữ liệu lớn	GraphRAG (Global/DRIFT Search)
Câu hỏi đòi hỏi nối nhiều dữ kiện rải rác thành insight mới	GraphRAG
Dữ liệu thay đổi liên tục, cần cập nhật realtime	RAG thường (hoặc cân nhắc kỹ chi phí re-index nếu dùng GraphRAG)
Có ngân sách và thời gian đầu tư cho indexing một lần, dùng lại nhiều lần	GraphRAG

5. Kết luận

GraphRAG thay đổi cách tiếp cận RAG truyền thống bằng cách bổ sung một lớp cấu trúc — knowledge graph và community hierarchy — bên cạnh vector search thuần túy. Cách làm này giải quyết đúng hai điểm yếu cố hữu của baseline RAG: khả năng kết nối thông tin rời rạc và khả năng hiểu tổng thể một tập dữ liệu lớn.

Đổi lại, GraphRAG đòi hỏi một pipeline indexing phức tạp và tốn kém hơn nhiều so với việc chỉ embed và lưu vector — vì gần như mọi bước (trích entity, tóm tắt, sinh report) đều cần gọi LLM. Vì vậy, GraphRAG phù hợp nhất với các bài toán cần suy luận sâu trên dữ liệu riêng tư, có ngân sách tính toán cho phép, hơn là thay thế hoàn toàn cho RAG truyền thống trong mọi tình huống. Việc lựa chọn giữa 4 chế độ query (Local, Global, DRIFT, Basic) cũng cần cân nhắc theo đúng loại câu hỏi mà hệ thống thực tế sẽ phải trả lời, để tránh dùng Global Search — chế độ tốn tài nguyên nhất — cho những câu hỏi vốn chỉ cần Local hoặc Basic Search.

Tài liệu tham khảo

1. 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
2. Microsoft. "GraphRAG Documentation." https://microsoft.github.io/graphrag/
3. Microsoft. "graphrag" (GitHub repository). https://github.com/microsoft/graphrag
4. Traag, V.A., Waltman, L., van Eck, N.J. "From Louvain to Leiden: guaranteeing well-connected communities." arXiv:1810.08473. https://arxiv.org/abs/1810.08473
5. Đỗ Thảo Giang. "Thuật toán Leiden: Phát hiện cộng đồng trong GraphRAG Global Search." Viblo. https://viblo.asia/p/thuat-toan-leiden-phat-hien-cong-dong-trong-graphrag-global-search-yZJZlzW8Vjm