Graph RAG có thực sự đáng dùng? Kết quả từ một thí nghiệm thực tế

Khi các mô hình ngôn ngữ lớn ngày càng mạnh, câu hỏi đặt ra là liệu chúng ta còn cần đến những kiến trúc truy xuất thông tin phức tạp như Graph RAG hay không. Một kỹ sư đã tự tay xây dựng bốn kiến trúc truy xuất khác nhau trên một chiếc laptop và chạy thử nghiệm trên cùng một bộ tài liệu, cùng một tập câu hỏi để tìm ra câu trả lời.

Bối cảnh: RAG, Graph RAG và cửa sổ ngữ cảnh lớn

RAG (Retrieval-Augmented Generation) là kỹ thuật kết hợp giữa việc tìm kiếm tài liệu liên quan và khả năng sinh văn bản của mô hình ngôn ngữ. Thay vì bắt mô hình "nhớ" mọi thứ, hệ thống sẽ truy xuất các đoạn văn bản liên quan rồi đưa vào ngữ cảnh để mô hình trả lời.

Graph RAG là một biến thể nâng cao, trong đó dữ liệu được tổ chức thành một đồ thị tri thức với các thực thể và mối quan hệ giữa chúng. Cách tiếp cận này được kỳ vọng sẽ giúp mô hình nắm bắt được các mối liên kết phức tạp mà phương pháp tìm kiếm vector thông thường bỏ sót.

Trong khi đó, sự phát triển của các mô hình biên (frontier models) với cửa sổ ngữ cảnh lên tới hàng trăm nghìn, thậm chí hàng triệu token đặt ra một câu hỏi ngược lại: liệu có thể chỉ cần nhét toàn bộ tài liệu vào ngữ cảnh và để mô hình tự xử lý?

Bốn kiến trúc được đem ra so sánh

Tác giả đã xây dựng và đánh giá bốn phương án:

• RAG thông thường: tìm kiếm vector dựa trên embedding, lấy ra các đoạn văn bản tương đồng nhất với câu hỏi.
• Graph RAG: xây dựng đồ thị tri thức từ tài liệu, truy xuất theo các nút và cạnh liên quan.
• Nhét toàn bộ vào ngữ cảnh: đưa tất cả tài liệu vào prompt và để mô hình xử lý trực tiếp.
• Kết hợp lai: dùng truy xuất để lọc bớt dữ liệu trước khi đưa vào ngữ cảnh lớn.

Mỗi kiến trúc đều được chạy trên cùng một bộ tài liệu và cùng một tập câu hỏi kiểm tra, giúp so sánh công bằng về độ chính xác, chi phí và thời gian phản hồi.

Những bài học rút ra về sự đánh đổi

Kết quả thí nghiệm mang lại một số nhận định đáng chú ý cho những ai đang cân nhắc triển khai RAG:

Không có kiến trúc nào thắng tuyệt đối. Mỗi phương pháp đều có điểm mạnh và điểm yếu tùy thuộc vào loại câu hỏi và cấu trúc dữ liệu.

Graph RAG thực sự tỏa sáng khi câu hỏi yêu cầu suy luận qua nhiều bước, liên kết thông tin từ nhiều nguồn rời rạc, hoặc cần hiểu mối quan hệ giữa các thực thể. Đây là những trường hợp mà tìm kiếm vector đơn thuần thường thất bại vì nó chỉ so khớp độ tương đồng ngữ nghĩa.

Tuy nhiên, chi phí xây dựng và bảo trì đồ thị tri thức là không hề nhỏ, đặc biệt khi dữ liệu thay đổi liên tục. Với những tác vụ tra cứu đơn giản, RAG thông thường vẫn là lựa chọn hiệu quả về chi phí.

Đáng chú ý, việc nhét toàn bộ tài liệu vào ngữ cảnh của mô hình biên cho kết quả rất tốt trong nhiều trường hợp, nhưng chi phí token tăng vọt và không khả thi khi dữ liệu lên đến hàng gigabyte. Đây không phải là giải pháp thay thế hoàn toàn cho RAG, mà là một lựa chọn bổ sung cho các bộ dữ liệu nhỏ.

Ý nghĩa với các đội phát triển tại Việt Nam

Với các startup và đội kỹ thuật tại Việt Nam đang xây dựng ứng dụng AI trên nền tảng RAG, bài học quan trọng là đừng mặc định chọn kiến trúc phức tạp nhất. Hãy bắt đầu từ RAG cơ bản, đo lường chất lượng trên chính dữ liệu của mình, và chỉ nâng cấp lên Graph RAG khi bài toán thực sự đòi hỏi suy luận đa bước.

Việc đo lường và benchmark trên tập câu hỏi thực tế của doanh nghiệp quan trọng hơn việc chạy theo xu hướng công nghệ. Một kiến trúc đơn giản hoạt động tốt trên dữ liệu cụ thể sẽ mang lại giá trị cao hơn một hệ thống đồ thị phức tạp nhưng không giải quyết đúng vấn đề.