Benchmark 100 câu hỏi: RAG 48%, GraphRAG 69%, agentic 99%

Bạn hỏi hệ RAG "có bao nhiêu nội dung vượt ngưỡng X" và nó trả về một con số rất tự tin. Con số đó sai, vì câu trả lời nằm rải trong hàng chục tài liệu còn top-8 vector search chỉ nhìn thấy tám. Hai benchmark công bố tuần này cho bạn đủ số liệu để quyết định: khi nào trả tiền cho agentic retrieval, khi nào RAG thường là đủ, và vì sao thiếu nguồn mới là nguyên nhân thật của "hallucination".

Hai benchmark, hai câu hỏi khác nhau

Benchmark thứ nhất đến từ vòng 1 Agentic GraphRAG Hackathon của TigerGraph. Tác giả dựng ba pipeline trên cùng một corpus và cùng một model, rồi đo chênh lệch. Theo bài viết, corpus gồm 2.951 bài Wikipedia tiếng Anh về các kỳ Olympic từ 1987 đến 2023, cộng thêm trang nhiễu. Cả ba pipeline dùng chung một LLM (claude-sonnet-5), chung embedding và chung một instance TigerGraph Savanna — nên khác biệt đo được đến từ kiến trúc retrieval, không phải từ model.

Benchmark thứ hai do một tác giả khác chạy trên agent nghiên cứu đối thủ: đưa URL công ty, agent tìm và xác minh đối thủ. Tác giả thay backend retrieval từ Tavily sang Firecrawl sau một provider switch rồi đo lại, trên 10 công ty, 20 trang gồm site JS-heavy, trang docs, trang pricing và site startup sơ khai.

Số liệu: agent tốn 1,24x token nhưng đúng gấp 2,06x

Kết quả trên 100 câu hỏi công khai của benchmark TigerGraph:

Pipeline	Accuracy	Token trung bình	Latency (s)	Token / câu đúng
RAG (vector top-8)	48%	6.466	7,1	13.471
GraphRAG (top-6 + mở rộng cố định)	69%	3.815	5,7	5.529
Agentic GraphRAG	99%	8.001	8,1	8.082

Tác giả tóm tắt: agent dùng 1,24x token của RAG để đổi lấy 2,06x accuracy, và tính trên mỗi câu trả lời đúng thì agent rẻ hơn RAG khoảng 40%. Đây là chỗ nhiều team đọc nhầm hóa đơn. Bạn so token trên mỗi request thì agent đắt hơn; bạn so token trên mỗi câu đúng thì RAG mới là bên đắt, vì hơn một nửa số request của nó phải làm lại.

GraphRAG là pipeline rẻ nhất trên mỗi câu đúng (5.529 token) nhưng trần accuracy dừng ở 69%. Nếu workload của bạn chấp nhận sai 3/10 câu, đó vẫn là lựa chọn kinh tế nhất trong bảng.

Loại câu hỏi mới là thứ quyết định kiến trúc

Bảng chia theo loại câu hỏi là phần đáng dán lên tường:

Loại câu hỏi	RAG	GraphRAG	Agentic
lookup (19 câu)	100%	100%	100%
aggregation (21 câu)	0%	67%	100%
superlative (10 câu)	40%	80%	90%
temporal (22 câu)	36%	86%	100%
multi_hop (28 câu)	57%	21%	100%

Ba kết luận rút ra được ngay. Thứ nhất, lookup một tài liệu thì cả ba pipeline đều đạt 100% — trả tiền cho agent ở đây là đốt tiền. Thứ hai, aggregation là chỗ RAG vỡ hoàn toàn: 0 trên 21 câu. Bằng chứng trải quá nhiều tài liệu so với k=8 chunk, và theo tác giả thì không prompt nào sửa được. Thứ ba, GraphRAG có thể tệ hơn cả RAG: ở multi_hop nó đạt 21% so với 57% của RAG, vì phần mở rộng đồ thị cố định bám vào sai entity gốc rồi mọi fact thêm vào đều tự tin về sai chủ thể.

Nói cách khác, nếu bạn định chọn một kiến trúc cho toàn bộ hệ thống, bạn đang chọn sai câu hỏi. Hãy phân loại truy vấn thật của người dùng trước, rồi định tuyến: lookup đi RAG, đếm và so sánh đi graph, còn truy vấn mà bước retrieval sau phụ thuộc vào kết quả bước trước thì mới cần agent.

Thiếu nguồn thì agent bịa — đó là lỗi retrieval, không phải lỗi model

Benchmark thứ hai đo phần ít người đo: độ rộng nguồn. Ở lớp retrieval thuần, tác giả báo cáo Firecrawl đạt fact recall 97% (66/68) so với 82% (56/68) của Tavily basic, nội dung trung vị 16.257 ký tự so với 11.735, nhưng p50 latency 1.391 ms so với 250 ms — chậm khoảng 5,6 lần và theo bảng giá công bố thì tốn khoảng 5 lần credit mỗi trang. Tác giả cũng ghi nhận tier advanced extract của Tavily trả nội dung giống hệt từng byte so với basic trên 19/20 trang, nên nâng tier không phải là cách mua thêm recall.

Phần quan trọng hơn nằm ở chạy end-to-end. Gộp các lần chạy theo số nguồn agent thực sự đọc: nhóm tham khảo từ 10 nguồn trở xuống có 9 lần chạy với 48 citation bị từ chối, tức 5,3 citation hỏng mỗi lần; nhóm trên 10 nguồn có 42 lần chạy nhưng chỉ 12 citation bị từ chối, tức 0,3 mỗi lần. Kết luận của tác giả đáng chép lại: bỏ đói nguồn thì agent sẽ trích dẫn những trang nó chưa từng đọc — trông như lỗi hallucination nhưng thực chất là lỗi retrieval.

Tác giả tự nêu giới hạn và bạn nên giữ nguyên mức tin cậy đó: cả 9 lần chạy ít nguồn đều dùng chung một cấu hình giới hạn 3 kết quả mỗi lần search, nên không tách được ảnh hưởng của độ rộng khỏi ảnh hưởng của cấu hình. Đây là tương quan, không phải quan hệ nhân quả đã cô lập, và mẫu chỉ có 10 công ty với 20 trang.

Khung quyết định cho team đang dựng agent

Gộp hai benchmark lại thành bốn bước bạn chạy được trong một buổi chiều.

1. Phân loại 100 truy vấn thật gần nhất theo năm nhóm: lookup, aggregation, superlative, temporal, multi-hop. Tỉ lệ nhóm aggregation và multi-hop chính là phần ngân sách agent của bạn.
2. Đo lại chi phí theo câu đúng, không theo request. Chia tổng token cho số câu trả lời đạt, như cột cuối của bảng trên. Con số này mới so sánh được giữa các kiến trúc.
3. Nới số nguồn mỗi lần search trước khi đổi model. Nếu agent của bạn đang bị cắt xuống 3 kết quả cho tiết kiệm, đó là biến rẻ nhất để thử lại.
4. Gắn evaluator bắt buộc trích dẫn. Trong benchmark TigerGraph, evaluator từ chối câu trả lời không có citation hoặc trích dẫn tài liệu mà không tool nào trả về; vòng lặp bị chặn ở 8 bước và circuit breaker dừng sau 2 lỗi tool liên tiếp để một sự cố backend không đốt token.

Hai chốt chặn cuối cùng này là phần dễ bê nguyên vào hệ của bạn nhất, và cũng là phần duy nhất trong cả hai bài không phụ thuộc vào việc bạn chọn vendor nào.

Cần theo dõi tiếp

Cả hai benchmark đều là mẫu nhỏ do một tác giả tự chạy, trên domain hẹp: một bộ Wikipedia Olympic và 20 trang web công ty. Trước khi đổi kiến trúc production theo các con số này, hãy chạy lại đúng khung đo trên corpus của bạn — repo của cả hai đều công khai, riêng bài đo retrieval còn kèm answer key và change log. Thứ đáng kiểm chứng nhất không phải con số 99%, mà là câu hỏi liệu tỉ lệ aggregation và multi-hop trong traffic thật của bạn có đủ lớn để trả tiền cho agent hay không.