Tầng 9 — Agentic retrieval

Nếu sản phẩm của bạn là AI Agent chứ không phải Q&A một lượt, thiết kế retrieval thay đổi hẳn. Tầng này nói về chỗ đó.

One-shot RAG vs agentic retrieval

	One-shot RAG	Agentic retrieval
Luồng	retrieve → generate	plan → search → đọc → search lại → tổng hợp
Số lượt tìm	1	không định trước
Multi-hop (lớp C)	yếu — phải lấy đủ mọi mảnh trong một lượt	mạnh — tìm mảnh 1, đọc, rồi biết phải tìm gì tiếp
Latency	thấp, đoán được	cao, không đoán được
Chi phí	1×	3–10×
Chế độ lỗi	thiếu context	lặp vô hạn, đi lạc, tự thuyết phục

Cái mà agentic mở ra: truy vấn “công ty tôi muốn dùng đăng nhập một lần thì phải trả bao nhiêu tiền” cần hai tài liệu — SSO chỉ có ở gói Doanh Nghiệp và giá gói Doanh Nghiệp. One-shot phải may mắn lấy được cả hai. Agent tìm “SSO” trước, đọc thấy “chỉ khả dụng trên Gói Doanh Nghiệp”, rồi mới biết phải tìm giá gói đó.

Đọc thêm

• [VI] RAG, AI Agents và Agentic RAG — chúng là gì? — Viblo — RAG vs AI Agent vs Agentic RAG — phân biệt bằng tiếng Việt
• [VI] Agentic RAG: cách hoạt động và so sánh với RAG truyền thống — Viblo — agentic RAG so với RAG một lượt
• [EN] Asai et al. — Self-RAG, 2023 — Self-RAG: để model tự quyết định có cần retrieve không
• [EN] What is Agentic RAG — Weaviate — agentic RAG dưới góc nhìn hạ tầng retrieval

Search-as-a-tool: thiết kế tool quan trọng hơn thiết kế prompt

Khi retrieval là một tool, agent tự quyết định gọi hay không. Điều đó nghĩa là mô tả tool trở thành một phần của hệ thống retrieval:

• Mô tả phải nói khi nào gọi, không chỉ nói tool làm gì.
• Nhiều tool hẹp (search_policy, search_api_docs, query_billing_db) thường tốt hơn một tool search chung — agent chọn đúng nguồn thay vì lọc sau.
• Trả về ít mà đậm: mỗi kết quả nên có id để trích dẫn, và đủ ngắn để agent còn chỗ suy luận.

Đọc thêm

• [VI] Tìm hiểu về AI Agents / LLM Agents — Viblo — vòng lặp agent, tool use
• [EN] Building effective agents — Anthropic — khi nào cần agent, khi nào một workflow cố định là đủ

Memory ≠ retrieval

Hai thứ hay bị gộp:

• Retrieval: tìm trong tri thức tĩnh, dùng chung (tài liệu sản phẩm).
• Memory: nhớ trạng thái của phiên/người dùng này (họ đang dùng gói nào, đã thử gì).

Nhồi memory vào cùng vector index với tài liệu là một lỗi kiến trúc: chúng khác nhau về vòng đời, về quyền truy cập, về cách làm mới, và về cách đánh giá.

Agentic keyword search: khi “grep thôi” là câu trả lời đúng

Đây là hệ quả ít ai nói ra của bảng trên. Nếu agent tự viết lại truy vấn và tìm nhiều lượt, thì chất lượng của một lượt tìm bớt quan trọng đi — bạn đổi nó bằng số lượt. Đẩy tới cùng: bỏ luôn vector index, để agent gọi grep.

Nghe như đùa, nhưng 2025–2026 đây là hướng đang được đo thật.

Số đo: agent chỉ có ripgrep, so với một RAG đầy đủ

Bài của Amazon tại AAAI 2026 dựng đúng phép so đó. Agent chỉ được cấp shell với rga (RipGrep-All), pdfgrep và một tool đọc metadata — không vector database, không embedding. Đối chứng là RAG chuẩn: Titan Text Embedding V2 (1024 chiều), chunk cố định 300 token overlap 20%, lấy top-5, cùng một model sinh (Claude 3 Sonnet), đo bằng RAGAS.

Điểm attainment (phần trăm agent đạt được so với RAG), trung bình 5 tập tài liệu:

Metric	Agent so với RAG
Faithfulness	94,52%
Context recall	88,05%
Answer correctness	91,48%

Phân rã theo tập mới là chỗ đáng đọc: context recall dao động từ 99,62% (BlockchainSolana) xuống 70,56% (Llama2Paper). Tức là “grep gần bằng RAG” đúng ở mức trung bình, và sai ở một số loại tài liệu — đúng tinh thần Tầng 7.

Chỗ grep thắng RAG, không phải gần bằng

Cùng bài báo, tập FinanceBench (báo cáo tài chính, đầy bảng biểu):

Cấu hình	Answer correctness
RAG truyền thống	24,24%
Agent (trung bình 3 lần chạy)	32,71%

Lý do khớp thẳng với Tầng 7 và Tầng 4: chunk hoá một bảng là phá cấu trúc của nó. Agent grep rồi đọc nguyên vùng văn bản thì bảng còn nguyên.

Một lưu ý về chính bài báo: thân bài ghi agent đạt trung bình 30,40% (σ = 1,31) trong khi Bảng 2 ghi 32,71%. Bài báo tự vênh ở chỗ này; nêu cả hai số để bạn biết mà đừng trích một mình con số đẹp hơn.

Nhưng đừng đọc thành “grep thắng RAG”

Bài “Is Grep All You Need?” (2026) đo trên 116 câu của LongMemEval và kết luận đúng hai điều, phải lấy cả hai:

1. grep thường cho độ chính xác cao hơn vector retrieval trong phép so của họ;
2. điểm tổng phụ thuộc mạnh vào harness và kiểu gọi tool (họ thử Claude Code, Codex, Gemini CLI, Chronos) — cùng dữ liệu, đổi harness là đổi kết luận.

Nghĩa là: mọi con số “grep thắng RAG” bạn đọc trên mạng là số của một harness cụ thể. Nó không chuyển sang hệ của bạn miễn phí.

Với code thì rõ hơn cả

CORE-Bench (8/2026) đo riêng chuyện này và thấy embedding rơi mạnh khi chuyển từ code-search kinh điển (docstring → hàm) sang tìm trong một repo thật theo yêu cầu người dùng. Bài báo cũng ghi nhận các harness thật (OpenHands, SWE-agent) không quy việc đó về một lượt tra embedding, mà dựa vào ls, grep, find, đọc file và thu hẹp dần.

Phía sản phẩm, Cline (5/2025) nói thẳng ba lý do không index codebase:

• chunk hoá làm rời logic — chỗ gọi hàm ở chunk này, định nghĩa ở chunk khác;
• index luôn cũ hơn code — agent tự tin gọi hàm vừa bị xoá;
• index là một bản sao IP nữa phải bảo vệ — thêm bề mặt bảo mật cho một thứ không bắt buộc.

Vì sao ripgrep mà không phải grep

Không phải chuyện làm màu. Ripgrep mặc định đệ quy, tôn trọng .gitignore, viết bằng Rust có song song hoá — tức là ba thứ một agent cần: không phải viết find | xargs, không lội vào node_modules, và đủ nhanh để gọi hàng chục lượt trong một vòng lặp.

Cái giá, nói cho đủ

Agentic keyword search không miễn phí — nó chuyển chi phí từ index sang token và latency: chính cột “3–10×” ở bảng đầu tầng này. Và nó không xoá được Tầng 0: grep vẫn mù trước vocabulary mismatch, chỉ là LLM bù lại bằng cách tự sinh nhiều biến thể từ khoá qua nhiều lượt. Với tiếng Việt, phần bù đó còn phải gánh thêm dấu, biến thể không dấu, và tách từ.

→ Nên áp dụng vào AI Agent: nếu corpus vừa (một repo, một thư mục tài liệu), có shell, và latency cho phép nhiều lượt — thử agentic grep trước khi dựng vector store. Đây là baseline rẻ nhất tồn tại, và theo số ở trên nó không tệ như trực giác nói. Ngược lại, nếu cần một lượt latency thấp, hoặc truy vấn ngữ nghĩa mơ hồ trên corpus lớn, index vẫn là thứ không thay thế được.

Đọc thêm

Chưa tìm được nguồn tiếng Việt nào đo hoặc phản biện hướng agentic keyword search, nên toàn bộ phần dưới là nguồn tiếng Anh:

• [EN] Subramanian et al. — Keyword search is all you need: Achieving RAG-Level Performance without vector databases using agentic tool use, AAAI 2026 — nguồn của mọi con số ở mục này: agent chỉ có rga/pdfgrep đạt 94,52% faithfulness của RAG, và vượt RAG trên FinanceBench (bản Amazon Science)
• [EN] Is Grep All You Need? How Agent Harnesses Reshape Agentic Search, 2026 — phản biện cần thiết: grep thắng vector retrieval trong phép so của họ, nhưng harness và kiểu gọi tool đổi kết luận
• [EN] CORE-Bench: A Comprehensive Benchmark for Code Retrieval in the Era of Agentic Coding, 8/2026 — vì sao model embedding giỏi CodeSearchNet lại kém khi agent tìm trong repo thật
• [EN] Why Cline doesn’t index your codebase, 5/2025 — ba lý do vận hành (chunk rời logic, index cũ hơn code, thêm bề mặt bảo mật) từ một sản phẩm thật
• [EN] ripgrep is faster than {grep, ag, git grep, ucg, pt, sift} — Andrew Gallant — vì sao là ripgrep: đệ quy mặc định, tôn trọng .gitignore, benchmark chi tiết

Khi nào agentic KHÔNG đáng

Truy vấn một bước, tra cứu đơn giản, và bất kỳ đường nào có ràng buộc latency chặt. Cách làm đúng: router — phân loại truy vấn, cho one-shot xử lý phần dễ, chỉ đẩy sang agentic loop khi thật cần. Đo tỷ lệ này; nó là đòn cắt chi phí lớn nhất.