A-RAG: Khi để AI tự điều khiển tìm kiếm, độ chính xác tăng vọt 79%

Hầu hết các quy trình tìm kiếm RAG (Retrieval-Augmented Generation - Lấy dẫn xuất và Tăng cường) hiện nay đều được xây dựng theo một mô hình cố định:

Query (Truy vấn) → Vector search (Tìm kiếm vector) → Top-K retrieval (Truy xuất K kết quả) → Dump tất cả vào LLM.

Chính quy trình cố định này là nguyên nhân gốc rễ hạn chế độ chính xác của RAG.

Một bài báo khoa học trên arXiv vào tháng 2 năm 2026 (mã số: arXiv:2602.03442) đã đề xuất A-RAG (Agentic RAG), thay thế quy trình tìm kiếm cố định bằng một AI agent (tác nhân AI). Kết quả đạt được rất ấn tượng: độ chính xác khi trả lời các câu hỏi đa bước (multi-hop QA) đã cải thiện 79% (từ 50,2% lên 89,7%). Thậm chí, lượng token cần truy xuất còn giảm đi một nửa.

Độ chính xác cao hơn lại đi kèm với việc truy xuất ít dữ liệu hơn. Hãy cùng xem cơ chế ngược đời này hoạt động như thế nào.

Ba giới hạn của RAG quy trình cố định

Giới hạn 1: Yếu kém với các câu hỏi đa bước (Multi-Hop)

Ví dụ câu hỏi: "Người phát minh ra X đã học đại học ở đâu?"

Các bước tìm kiếm cần thiết:

• Vòng 1: "Ai là người phát minh ra X" → xác định danh tính.
• Vòng 2: "Trường đại học của người đó" → có câu trả lời.

Quy trình cố định:

• Chỉ thực hiện một lần vector search cho từ khóa "người phát minh X + đại học".
• Không có đoạn văn (chunk) nào chứa trực tiếp câu trả lời.
• Hệ thống truy xuất nhiều đoạn văn ít liên quan.
• LLM phải đoán mò → kết quả không chính xác.

Các câu hỏi đa bước chiếm tỷ trọng lớn trong các truy vấn thực tế. Quy trình cố định về mặt cấu trúc rất yếu thế trước những câu hỏi cần nhiều lần tìm kiếm mới ra kết quả.

Giới hạn 2: Độ hạt truy xuất cố định

Với việc cố định số lượng kết quả Top-K=5:

• Câu hỏi đơn giản → truy xuất 5 đoạn văn → lãng phí token.
• Câu hỏi phức tạp → chỉ truy xuất 5 đoạn văn → thiếu thông tin.

Độ hạt cần thiết thực tế varies tùy theo câu hỏi:

• "GPT-4 có bao nhiêu tham số?" → 1 đoạn là đủ.
• "GPT-4 khác Claude 3.5 như thế nào về ngữ cảnh dài?" → Cần khoảng 10 đoạn.

Giới hạn 3: Chiến lược tìm kiếm cố định

Chỉ dùng Vector search:

• Chỉ lấy các đoạn văn tương đồng về ngữ nghĩa.
• Yếu về khớp chính xác (mã linh kiện, tên riêng).

Chỉ dùng Keyword search:

• Chỉ lấy các khớp chính xác/bán chính xác.
• Yếu về từ đồng nghĩa và diễn giải.

Hybrid search (tỷ lệ cố định):

• 70% vector + 30% từ khóa (hoặc tỷ lệ cố định khác).
• Không thể điều chỉnh linh hoạt dựa trên loại câu hỏi.

Kiến trúc A-RAG: Để Agent tự tìm kiếm

Trọng tâm của A-RAG là thay thế quy trình tìm kiếm cứng nhắc bằng khả năng ra quyết định của agent.

RAG truyền thống: Query → [quy trình cố định] → các đoạn văn → LLM → câu trả lời. Phương pháp tìm kiếm, độ hạt và số lượng đều được xác định trước.

A-RAG: Query → [agent] → câu trả lời. Agent tự chủ quyết định:

• Dùng công cụ tìm kiếm nào.
• Tìm kiếm bao nhiêu lần.
• Độ hạt truy xuất là bao nhiêu.
• Khi nào dừng tìm kiếm.

Ba giao diện tìm kiếm

A-RAG cung cấp cho agent 3 công cụ:

1. keyword_search: Tìm kiếm dựa trên từ khóa. Dùng cho tên riêng, mã số, thuật ngữ chính xác.
2. semantic_search: Tìm kiếm tương đồng vector. Dùng cho sự tương đồng về khái niệm, xử lý câu diễn đạt khác nhau.
3. chunk_read: Đọc sâu các đoạn cụ thể. Dùng khi cần khoan sâu vào kết quả tìm kiếm, lấy ngữ cảnh xung quanh.

Agent tự do kết hợp các công cụ này dựa trên câu hỏi.

Ví dụ về câu hỏi đa bước

Câu hỏi: "Nơi công tác hiện tại của tác giả đầu tiên của bài báo đề xuất mô hình Transformer là đâu?"

Hành vi của Agent:

1. Bước 1: keyword_search("tác giả gốc bài báo Transformer") → Kết quả: "Attention Is All You Need", Vaswani et al., 2017.
2. Bước 2: semantic_search("nơi công tác Ashish Vaswani 2026") → Truy xuất được 3 đoạn văn.
3. Bước 3: chunk_read(doc_id="result_2", range="full") → Đọc sâu thông tin chi tiết.
4. Bước 4: Tạo câu trả lời → "Essential AI (startup thành lập 2023)".

Quy trình cố định sẽ làm gì:

• Thực hiện vector_search("tác giả đầu tiên nơi công tác Transformer paper").
• Khó có được câu trả lời trực tiếp trong một lần tìm.
• Chủ yếu truy xuất nội dung về "Attention Is All You Need".
• Nguy cơ trả lời sai với thông tin năm 2017 (khi tác giả còn ở Google).

Kết quả Benchmark: Con số biết nói của A-RAG

Dưới đây là các kết quả chính từ bài báo (Bảng 1).

Backend GPT-4o-mini

Benchmark	Naive RAG	A-RAG	Cải thiện
MuSiQue	38,6%	46,1%	+19%
HotpotQA	74,5%	77,1%	+3,5%
2WikiMultiHopQA	42,6%	60,2%	+41%

Backend GPT-5-mini

Benchmark	Naive RAG	A-RAG	Cải thiện
MuSiQue	52,8%	74,1%	+40%
HotpotQA	81,2%	94,5%	+16%
2WikiMultiHopQA	50,2%	89,7%	+79%

Phân tích mẫu số liệu

Ba điểm chính rút ra:

1. Cải thiện mạnh mẽ ở đa bước: +79% trên bộ dữ liệu 2WikiMultiHopQA. A-RAG mạnh nhất ở điểm yếu nhất của quy trình cố định.
2. Tăng trưởng theo khả năng mô hình: GPT-5-mini cải thiện nhiều hơn GPT-4o-mini. Chất lượng tìm kiếm của agent phụ thuộc vào trí thông minh của mô hình.
3. GraphRAG phụ thuộc nhiều vào mô hình: Với GPT-4o-mini, HotpotQA tụt xuống 33,2% (ít hơn một nửa so với Naive RAG). Nhưng với GPT-5-mini, GraphRAG đạt 82,5%. GraphRAG với mô hình yếu là rất rủi ro.

Hiệu quả Token

Trên bộ dữ liệu HotpotQA (sử dụng GPT-5-mini):

• Naive RAG: 5.358 token được truy xuất → Độ chính xác 81,2%.
• A-RAG: 2.737 token được truy xuất → Độ chính xác 94,5%.

Kết quả: Token truy xuất giảm 49%, độ chính xác tăng 16%.

Agent chỉ chọn lọc những gì thực sự cần thiết, giảm nhiễu và cải thiện chất lượng câu trả lời của LLM. Điều này tác động trực tiếp đến chi phí API.

A-RAG có chạy được trên Local LLM không?

Bài báo sử dụng GPT-4o-mini và GPT-5-mini. Vậy còn các mô hình cục bộ (local) thì sao?

Thách thức về cấu trúc

Để chạy được Agentic RAG, mô hình cần các khả năng:

• Sử dụng công cụ (Function calling).
• Lập kế hoạch đa bước (Multi-step planning).
• Phản tư (Reflection): Đánh giá kết quả tìm kiếm, quyết định hành động tiếp theo.
• Quản lý ngữ cảnh.

Với các mô hình local như Qwen2.5-32B hay Qwen3.5-9B:

• Qwen2.5-32B: Hỗ trợ tốt tool_use, lập kế hoạch ở mức vừa đủ. Agentic RAG đơn giản hoạt động được, nhưng đa bước phức tạp thì khó.
• Qwen3.5-9B: Nhanh nhưng kiến thức hạn chế, chất lượng phán xét tìm kiếm có thể giảm.

Kỳ vọng thực tế

Đừng mong đợi con số +79% như bài báo khi chạy local. Khả năng sử dụng công cụ (tool_use) của Local LLM là yếu tố hạn chế.

• Mô hình 32B: Cải thiện khoảng +15-25% cho câu hỏi đa bước (khoảng 1/3 kết quả bài báo).
• Mô hình 9B: Cải thiện +5-10% cho đa bước.
• Khuyến nghị: Cần mô hình 32B trở lên để có lợi ích ý nghĩa từ Agentic RAG.

Khi nào nên thử Agentic RAG?

A-RAG rất hấp dẫn nhưng không phải lúc nào cũng cần thiết.

Nên dùng Agentic RAG khi:

• Câu hỏi đa bước (multi-hop) xuất hiện thường xuyên (nghiên cứu, điều tra).
• Cơ sở kiến thức lớn (1000+ đoạn văn).
• Độ phức tạp câu hỏi biến thiên.
• Độ chính xác là ưu tiên hàng đầu (y tế, pháp lý).

Naive RAG là đủ khi:

• Câu hỏi đơn bước chiếm ưu thế (FAQ, tra cứu thủ công).
• Cơ sở kiến thức nhỏ (< 100 đoạn).
• Mẫu câu hỏi đồng nhất.
• Độ trễ (latency) là ưu tiên hàng đầu.

Cấu trúc chi phí

Giá của việc tăng 79% độ chính xác là độ trễ tăng gấp 3-4 lần. Agentic RAG cần 2-4 lượt gọi LLM và 2-5 lượt tìm kiếm so với 1 lượt của Naive RAG. Nếu các truy vấn đa bước chiếm hơn 30% lưu lượng truy cập, thì Agentic RAG đáng để xem xét.

Tương lai của RAG là hướng tới Agentic

Tóm tắt lại:

1. RAG quy trình cố định bị giới hạn bởi thiết kế tìm kiếm: Yếu về đa bước, độ hạt và chiến lược cố định.
2. A-RAG để agent quyết định cách tìm kiếm: 3 công cụ (từ khóa/ngữ nghĩa/đọc sâu) được chọn tự chủ.
3. Cải thiện 79% trên đa bước: Lợi ích lớn nhất nơi quy trình cố định yếu nhất.
4. Truy xuất ít hơn, chính xác hơn: Giảm 49% token nhưng tăng 16% độ chính xác.
5. Mô hình càng mạnh lợi ích càng cao: Local LLM mang lại lợi ích ít hơn.

RAG đang tiến hóa từ việc tối ưu hóa tìm kiếm do con người thiết kế sang các quyết định tìm kiếm do mô hình điều khiển. Quy trình cố định ổn định và dễ đoán trước, nhưng không thể thích ứng với sự đa dạng của câu hỏi. Agent thì khó đoán hơn nhưng thích ứng cao.

Nếu hệ thống RAG của bạn đang dùng quy trình cố định, hãy đo lường tỷ lệ câu hỏi đa bước trước. Nếu nó vượt quá 30%, Agentic RAG là hướng đi đáng để nghiên cứu.