GÓT CHÂN ACHILLES CỦA RAG: TÌM ĐƯỢC THÔNG TIN NHƯNG CHƯA CHẮC TỔNG HỢP ĐÚNG
TÓM TẮT NHANH
RAG hoạt động tốt khi câu trả lời nằm trong một vài đoạn tài liệu cụ thể.
Tuy nhiên, khi người dùng muốn tìm xu hướng, đếm số trường hợp hoặc tổng hợp dữ liệu từ hàng nghìn tài liệu, hệ thống phải làm nhiều hơn việc tìm kiếm.
GraphRAG giúp AI nhìn thấy các thực thể và mối quan hệ giữa chúng. Nhưng việc biết “thông tin nào liên quan đến thông tin nào” không đồng nghĩa với việc tính chính xác “có bao nhiêu, tổng cộng bao nhiêu hoặc tỷ lệ là bao nhiêu”.
Đặc biệt, nếu tài liệu chưa có sẵn báo cáo tổng hợp, aggregation trở thành một bài toán xử lý dữ liệu lớn, chứ không còn là bài toán retrieval đơn thuần.
RAG THỰC SỰ NHÌN THẤY BAO NHIÊU DỮ LIỆU?
Một hệ thống RAG phổ biến thường thực hiện quy trình sau:
Tài liệu
1. Chia thành các đoạn nhỏ
2. Tìm một số đoạn liên quan nhất
3. Đưa các đoạn đó cho mô hình AI
4. Tạo câu trả lời
- Cách này hiệu quả với những câu hỏi cụ thể như: “Chính sách hoàn tiền kéo dài bao nhiêu ngày?”
- Câu trả lời có thể nằm trong một đoạn duy nhất. Hệ thống chỉ cần tìm đúng đoạn đó.
- Nhưng hãy thử một câu hỏi khác:
- “Ba vấn đề khách hàng phàn nàn nhiều nhất trong năm vừa qua là gì?”
Để trả lời chính xác, AI phải đọc đủ dữ liệu, nhóm những phản hồi có nội dung tương tự, loại bỏ trường hợp trùng lặp và so sánh tần suất giữa các nhóm. => Đây không còn là bài toán tìm một đoạn văn phù hợp.
Nghiên cứu From Local to Global: A Graph RAG Approach to Query-Focused Summarization gọi những yêu cầu như vậy là câu hỏi toàn cục — những câu hỏi cần hiểu bức tranh chung của cả tập tài liệu.
Nhóm tác giả nhận định RAG truyền thống gặp khó với dạng câu hỏi này vì chúng gần với bài toán tóm tắt có định hướng hơn là truy xuất một vài đoạn thông tin.
Nguồn: https://arxiv.org/abs/2404.16130
GRAPHRAG GIÚP NỐI CÁC MẢNH THÔNG TIN
Một hạn chế của vector search là các đoạn tài liệu thường được xử lý như những đơn vị tương đối độc lập.
Trong khi đó, thông tin thực tế thường tồn tại dưới dạng quan hệ:
Khách hàng A
- mua sản phẩm X
- gặp lỗi thanh toán
- liên hệ bộ phận hỗ trợ
- yêu cầu hoàn tiền
Các dữ kiện này có thể nằm trong nhiều email, ticket và báo cáo khác nhau.
GraphRAG cải thiện vấn đề bằng cách:
- Trích xuất thực thể và quan hệ từ tài liệu.
- Xây dựng đồ thị tri thức.
- Nhóm các thực thể liên quan thành những cộng đồng nội dung.
- Tạo bản tóm tắt cho từng cộng đồng.
Cách tổ chức này hỗ trợ tốt hơn cho các câu hỏi cần nhìn ở mức toàn cục.
Trong thử nghiệm của nghiên cứu From Local to Global, GraphRAG cải thiện tính toàn diện và đa dạng của câu trả lời so với RAG cơ bản trên một nhóm câu hỏi tổng hợp định tính.
Nói đơn giản, GraphRAG có thể giúp AI hiểu:
- Ai liên quan đến ai?
- Sự kiện nào liên quan đến sản phẩm nào?
- Những chủ đề nào thường xuất hiện cùng nhau?
- Các vấn đề trong tài liệu được kết nối như thế nào?
Đây là bước tiến lớn so với việc chỉ tìm những đoạn văn có nội dung giống câu hỏi.
HIỂU QUAN HỆ CHƯA CÓ NGHĨA LÀ TÍNH TOÁN CHÍNH XÁC
Giả sử doanh nghiệp có 20.000 ticket hỗ trợ và đặt câu hỏi:
“Có bao nhiêu khách hàng gặp lỗi thanh toán trong quý vừa qua?”
Để trả lời đúng, hệ thống phải:
- Xác định đầy đủ các ticket liên quan.
- Phân biệt lỗi thanh toán với lỗi đăng nhập hoặc lỗi hoàn tiền.
- Nhận ra nhiều ticket có thể thuộc cùng một sự cố.
- Loại bỏ dữ liệu trùng lặp.
- Lọc đúng khoảng thời gian.
- Thực hiện phép đếm trên toàn bộ kết quả.
GraphRAG có thể kết nối khách hàng, giao dịch, sản phẩm và sự cố.
Tuy nhiên, kiến trúc GraphRAG ban đầu tạo câu trả lời toàn cục bằng cách tổng hợp các community summary bằng ngôn ngữ tự nhiên.
Bài nghiên cứu không được thiết kế để chứng minh rằng hệ thống có thể thực hiện chính xác các phép như:
- COUNT
- SUM
- AVG
- Tỷ lệ phần trăm
- So sánh số liệu theo thời gian trên toàn bộ corpus.
Vì vậy, sẽ không chính xác nếu suy ra rằng:
- “GraphRAG trả lời tốt câu hỏi toàn cục, nên nó cũng sẽ tính đúng mọi con số trên toàn bộ tài liệu.”
- Tóm tắt một xu hướng và tính toán một con số chính xác là hai bài toán khác nhau.
- Nghiên cứu Structured RAG for Answering Aggregative Questions chỉ ra rằng phần lớn hệ thống RAG được tối ưu cho trường hợp chỉ một phần nhỏ của corpus chứa thông tin cần thiết.
- Chúng gặp khó với những câu hỏi phải thu thập dữ kiện từ nhiều tài liệu rồi thực hiện aggregation.
- Phương pháp S-RAG trong nghiên cứu tạo biểu diễn có cấu trúc ngay từ giai đoạn ingestion, sau đó chuyển câu hỏi của người dùng thành một truy vấn hình thức trên cấu trúc đó.
Nguồn: https://arxiv.org/abs/2511.08505
KHI TÀI LIỆU KHÔNG CÓ SẴN PHẦN TỔNG HỢP
RAG sẽ làm việc tương đối dễ nếu tài liệu đã chứa sẵn kết quả:
- “Trong quý III có 1.240 yêu cầu hỗ trợ, trong đó 28% liên quan đến thanh toán.”
Hệ thống chỉ cần tìm đúng đoạn văn này.
Nhưng trong thực tế, dữ liệu thường chỉ gồm những bản ghi rời rạc:
- Ticket 1: Không thể thanh toán bằng thẻ
- Ticket 2: Đã bị trừ tiền nhưng đơn hàng chưa được xác nhận
- Ticket 3: Tài khoản bị trừ tiền hai lần
… - Ticket 20.000
Không có tài liệu nào trực tiếp ghi rằng có bao nhiêu lỗi thanh toán.
Khi đó, để tạo ra câu trả lời, hệ thống phải tự xây dựng phần tổng hợp:
Thu thập bản ghi
- Trích xuất dữ kiện
- Chuẩn hóa cách diễn đạt
- Phân loại
- Loại bỏ trùng lặp
- Tính toán
Kiểm tra kết quả
Đây là một bài toán lớn vì retrieval phải bảo đảm recall đủ cao. Chỉ cần bỏ sót một phần tài liệu, kết quả đếm hoặc tỷ lệ đã có thể sai.
Benchmark From Chat Logs to Collective Insights: Aggregative Question Answering nghiên cứu câu hỏi aggregation trên hơn 182.000 cuộc hội thoại thực tế.
Kết quả cho thấy các phương pháp hiện tại thường rơi vào một trong hai tình huống:
- Gặp khó khi suy luận trên quy mô lớn.
- Phải trả chi phí tính toán rất cao để xử lý đủ dữ liệu.
Điều này cho thấy aggregation trên dữ liệu phi cấu trúc vẫn là một bài toán chưa được giải quyết hoàn toàn.
Nguồn: https://arxiv.org/abs/2505.23765
TĂNG SỐ LƯỢNG CHUNK CÓ GIẢI QUYẾT ĐƯỢC KHÔNG?
Một cách đơn giản là tăng số đoạn được lấy về, chẳng hạn từ 5 lên 100 chunk. Nhưng lấy thêm dữ liệu không đồng nghĩa với có được kết quả tốt hơn.
Hệ thống có thể gặp những vấn đề mới:
- Nhiều thông tin bị trùng lặp.
- Context trở nên dài và gây nhiễu.
- Chi phí xử lý tăng.
- Mô hình khó xác định đâu là dữ kiện cần tính.
- Một số nhóm ít giống câu hỏi vẫn có thể bị bỏ sót.
Nghiên cứu RAPTOR: Recursive Abstractive Processing for Tree-Organized Retrieval tiếp cận một phần vấn đề này bằng cách nhóm và tóm tắt tài liệu theo nhiều tầng.
Hệ thống có thể truy xuất cả đoạn chi tiết lẫn bản tóm tắt cấp cao, thay vì chỉ tìm trên một danh sách chunk phẳng.
Tuy nhiên, đây vẫn chủ yếu là cách cải thiện khả năng hiểu ngữ cảnh và retrieval. Nó không thay thế một công cụ tính toán xác định.
Nguồn: https://arxiv.org/abs/2401.18059
KIẾN TRÚC THỰC TẾ NÊN HOẠT ĐỘNG THẾ NÀO?
Một hệ thống đáng tin cậy cần phân biệt loại câu hỏi ngay từ đầu.
Khi người dùng muốn tìm thông tin
Ví dụ:
- “Điều kiện hoàn tiền là gì?”
Có thể sử dụng RAG truyền thống kết hợp reranking.
Khi người dùng muốn hiểu quan hệ
Ví dụ:
- “Những sản phẩm nào thường xuất hiện cùng lỗi thanh toán?”
- GraphRAG có thể phù hợp hơn vì nó tổ chức các thực thể và mối liên hệ giữa chúng.
Khi người dùng muốn aggregation bằng số
Ví dụ:
- “Tổng giá trị giao dịch lỗi trong quý này là bao nhiêu?”
Hệ thống nên để AI hiểu yêu cầu và lập kế hoạch, nhưng giao phần lọc, đếm và tính toán cho những công cụ xác định như:
- SQL hoặc cơ sở dữ liệu phân tích.
- Dataframe.
- Search engine hỗ trợ aggregation.
- Knowledge graph có schema rõ ràng.
- Công cụ thực thi mã được kiểm soát.
Một pipeline thực tế có thể hoạt động như sau:
Người dùng đặt câu hỏi
- AI phân loại loại câu hỏi
- RAG hoặc GraphRAG thu thập bằng chứng
- Công cụ có cấu trúc lọc và tính toán
- Hệ thống kiểm tra kết quả
- AI giải thích bằng ngôn ngữ tự nhiên
KẾT LUẬN
- RAG mạnh ở việc tìm thông tin.
- GraphRAG tiến thêm một bước khi giúp hệ thống hiểu các mối quan hệ và tổng hợp bức tranh định tính.
- Nhưng với những câu hỏi yêu cầu số liệu chính xác, như đếm, tính tổng, trung bình hoặc tỷ lệ trên toàn bộ kho tài liệu, retrieval và summarization vẫn chưa đủ.
- Đặc biệt, nếu dữ liệu nguồn không có sẵn báo cáo tổng hợp, hệ thống phải tự biến hàng nghìn tài liệu phi cấu trúc thành dữ liệu có thể tính toán.
- Khi đó, bài toán không còn chỉ là RAG mà đã trở thành một pipeline xử lý và phân tích dữ liệu hoàn chỉnh.
Trước khi lựa chọn kiến trúc, doanh nghiệp cần xác định người dùng đang muốn:
“Tìm một thông tin, hiểu một mối quan hệ hay tính toán trên toàn bộ dữ liệu?”
Ba câu hỏi này có thể trông giống nhau trong giao diện trò chuyện, nhưng phía sau cần ba cách xử lý rất khác nhau.
NGUỒN THAM KHẢO
- Darren Edge và cộng sự.
From Local to Global: A Graph RAG Approach to Query-Focused Summarization.
arXiv:2404.16130.
https://arxiv.org/abs/2404.16130 - Parth Sarthi và cộng sự.
RAPTOR: Recursive Abstractive Processing for Tree-Organized Retrieval.
arXiv:2401.18059.
https://arxiv.org/abs/2401.18059 - Omri Koshorek và cộng sự.
Structured RAG for Answering Aggregative Questions.
arXiv:2511.08505.
https://arxiv.org/abs/2511.08505 - Wentao Zhang, Woojeong Kim và Yuntian Deng.
From Chat Logs to Collective Insights: Aggregative Question Answering.
arXiv:2505.23765.
https://arxiv.org/abs/2505.23765