GraphRAG: Giải pháp giúp AI tổng hợp thông tin từ nhiều tài liệu rời rạc

Việc biến các mô hình mới thành những hệ thống vận hành hiệu quả trong hoạt động thực tế của khách hàng vẫn là một thách thức.

Khoảng cách đó đang tạo ra nhu cầu về những kỹ sư có khả năng linh hoạt giữa mã nguồn, bối cảnh khách hàng và kết quả vận hành thực tế. Xin giới thiệu: kỹ sư triển khai tiền phương (forward deployed engineer - FDE).

Báo cáo "The State of FDE Jobs 2026" (Tình hình việc làm FDE năm 2026) phác thảo thị trường lao động đang nổi lên xung quanh công việc này.

Khám phá báo cáo tại đây.

Hãy tưởng tượng một hệ thống truy xuất dựa trên AI được kết nối với dữ liệu kỹ thuật của nhóm bạn trong 5 năm qua, bao gồm tài liệu thiết kế, báo cáo phân tích sự cố (postmortems) và hồ sơ quyết định kiến trúc. Khi ai đó hỏi dịch vụ nào chịu trách nhiệm cho logic thử lại thanh toán (payments retry logic), hệ thống sẽ đưa ra câu trả lời khá chính xác và có trích dẫn rõ ràng. Tuy nhiên, khi ai đó hỏi nguyên nhân lỗi nào thường xuyên lặp lại nhất trong tất cả các báo cáo sự cố, chất lượng câu trả lời lại giảm sút.

Tùy thuộc vào thiết lập, phản hồi có thể liệt kê một vài sự cố tình cờ sử dụng từ "lặp lại" (recurring), nhưng chúng ta không nắm bắt được bất kỳ mô hình cơ bản nào từ câu trả lời đó. Nói cách khác, mục đích của câu hỏi không được đáp ứng.

Nhìn từ bên ngoài, cả hai câu hỏi có vẻ tương đồng. Tuy nhiên, về mặt kiến trúc, chúng lại đối lập nhau:

Câu hỏi đầu tiên có câu trả lời nằm trong một tài liệu cụ thể, đây chính xác là mục đích mà tìm kiếm tương đồng (similarity search) được xây dựng để giải quyết.

Câu hỏi thứ hai chỉ có câu trả lời sau khi toàn bộ tập dữ liệu đã được khảo sát và thấu hiểu. Điều này đòi hỏi một cơ chế truy xuất hoàn toàn khác biệt.

GraphRAG được thiết kế để xử lý loại câu hỏi thứ hai, và chúng ta sẽ tìm hiểu sâu hơn về nó trong bài viết này. Dưới đây là những nội dung chúng ta sẽ đề cập:

Cách thức hoạt động của RAG tiêu chuẩn và giới hạn của nó.

Đồ thị tri thức (knowledge graphs) và cách xây dựng chúng từ các tài liệu thông thường.

Quy trình lập chỉ mục (indexing pipeline) của GraphRAG.

Phát hiện cộng đồng (community detection) và các bản tóm tắt phân cấp.

Tìm kiếm cục bộ (local search) và tìm kiếm toàn cục (global search).

Đánh đổi về chi phí, độ trễ và bảo trì.

Khi nào RAG tiêu chuẩn vẫn là lựa chọn tốt hơn.

Agentic RAG (RAG dựa trên tác tử).

Tuyên bố miễn trừ trách nhiệm: Bài viết này dựa trên các thông tin được chia sẻ công khai từ nhiều nguồn khác nhau. Tài liệu tham khảo ở cuối bài. Vui lòng để lại bình luận nếu bạn phát hiện bất kỳ điểm nào không chính xác.

RAG tiêu chuẩn (Retrieval Augmented Generation - Truy xuất tăng cường thế hệ) phụ thuộc vào một quy trình tinh gọn.

Chúng ta lấy một tập hợp tài liệu, chia nhỏ mỗi tài liệu thành các đoạn (chunks) từ vài trăm đến vài nghìn token, và đưa mỗi đoạn qua một mô hình nhúng (embedding model). Mô hình nhúng trả về một vector, về cơ bản là một danh sách dài các con số đại diện cho ý nghĩa của văn bản đó. Các đoạn có ý nghĩa liên quan sẽ tạo ra các vector nằm gần nhau trong cùng một không gian số. Tất cả các vector đó được đưa vào một chỉ mục vector (vector index).

Tại thời điểm truy vấn, quy trình tương tự được áp dụng cho câu hỏi. Câu hỏi cũng trở thành một vector, chỉ mục trả về một vài vector đoạn gần nhất với nó, và văn bản gốc của các đoạn đó được đưa vào prompt cùng với câu hỏi. Sau đó, mô hình ngôn ngữ sẽ tạo ra câu trả lời từ văn bản được cung cấp.

Toàn bộ thiết kế dựa trên một giả định đơn giản: văn bản trả lời cho một câu hỏi sẽ có sự tương đồng với chính câu hỏi đó. Đối với phần lớn các truy vấn, giả định này khá đúng. Ví dụ, một câu hỏi như "Dịch vụ nào sở hữu logic thử lại thanh toán" chứa cùng từ vựng với hồ sơ quyết định kiến trúc nơi quyền sở hữu đó được ghi lại. Các vector nằm gần nhau, việc truy xuất trả về đúng tài liệu và trích dẫn chỉ đến nơi mà người đọc có thể thực sự kiểm chứng.

Giả định về việc câu hỏi tương tự với câu trả lời chỉ đúng cho một nhóm câu hỏi cụ thể, nhưng không phải là quy luật phổ quát.

Tài liệu về GraphRAG của Microsoft phân biệt giữa truy vấn cục bộ (local queries) và truy vấn toàn cục (global queries). Truy vấn cục bộ có câu trả lời tương tự với truy vấn và nằm trong một số ít vùng văn bản, bao gồm hầu hết các câu hỏi ai, cái gì, khi nào và ở đâu. Truy vấn toàn cục đòi hỏi khả năng suy luận trên các phần lớn của tập dữ liệu, hoặc trên toàn bộ tập dữ liệu đó.

Hai câu hỏi ví dụ của chúng ta ở trên nằm ở hai phía đối lập của ranh giới đó. Câu hỏi "Dịch vụ nào sở hữu logic thử lại" là truy vấn cục bộ. Tuy nhiên, câu hỏi "Nguyên nhân lỗi nào lặp lại thường xuyên nhất trong tất cả các báo cáo sự cố" là truy vấn toàn cục.

Lý do chất lượng câu trả lời cho câu hỏi thứ hai bị giảm sút là vì cụm từ "lặp lại thường xuyên nhất" tạo ra một vector, và chỉ mục trả về bất cứ thứ gì xuất hiện gần nhất với nó. Trong một kho dữ liệu báo cáo sự cố, các láng giềng gần nhất sẽ là những tài liệu sử dụng các từ như "lặp lại" hoặc "thường xuyên", đây chỉ là sự trùng hợp về từ vựng. Tuy nhiên, câu trả lời thực sự cho câu hỏi tồn tại dưới dạng phân phối trên hai trăm tài liệu, trải dài khắp kho dữ liệu thay vì nằm tại một vị trí có thể truy xuất đơn lẻ.

Một phản biện hợp lý tại thời điểm này là các cửa sổ ngữ cảnh (context windows) hiện đại đã đủ lớn để bỏ qua hoàn toàn vấn đề này. Microsoft đã thử nghiệm chính xác điều đó, so sánh GraphRAG với truy xuất vector khi nạp 8.000 và sau đó là 64.000 token ngữ cảnh. Tuy nhiên, đối với các câu hỏi toàn cục, cửa sổ lớn hơn vẫn để lại khoảng trống về tính toàn diện, sự đa dạng và chất lượng của tài liệu nguồn hỗ trợ.

Kết quả này thường bị gắn mác là vấn đề ảo giác (hallucination). Điều thực sự xảy ra là quá trình truy xuất trả về tài liệu ít liên quan đến câu hỏi, và mô hình tạo ra văn bản trôi chảy từ những dữ liệu đó.

Các tác tử (agents) có thể tạo mã nguồn. Việc làm cho nó phù hợp với hệ thống, quy ước nhóm và các quyết định trong quá khứ của bạn mới là phần khó. Bạn sẽ kết thúc bằng việc lãng phí thời gian và token vào các vòng lặp sửa lỗi.

Việc bổ sung thêm nhiều MCP, quy tắc và cửa sổ ngữ cảnh lớn hơn giúp các tác tử tiếp cận thông tin, nhưng không mang lại sự thấu hiểu. Các đội ngũ đang dẫn đầu là những người xây dựng một lớp ngữ cảnh (context layer) để cung cấp cho tác tử chính xác những gì chúng cần cho nhiệm vụ hiện tại.

Hãy tham gia hội thảo trực tuyến MIỄN PHÍ của chúng tôi vào ngày 2 tháng 9 để tìm hiểu:

Nơi các đội ngũ thường bị mắc kẹt trên đường cong trưởng thành AI và tại sao các giải pháp khắc phục thông thường lại không hiệu quả.

Cách một lớp ngữ cảnh giải quyết các vấn đề về chất lượng, hiệu quả và chi phí.