RAG nâng cao 7 — Agentic RAG: truy hồi có suy luận & tự sửa
Giới hạn của RAG một-lượt
Các bài trước trong series RAG nâng cao đã vá nhiều lỗi cục bộ của pipeline truy hồi: chunk vụn, sót từ khoá (hybrid search), top-k nhiễu (reranking), câu hỏi mơ hồ (query transformation). Nhưng tất cả vẫn nằm trong một khung cứng: RAG một-lượt (single-shot). Luồng là embed câu hỏi → truy hồi top-k → nhồi vào prompt → LLM trả lời. Đúng một vòng. Không quay lại.
Khung một-lượt hỏng ở bốn điểm:
- Không lặp. Nếu lần truy hồi đầu mang về tài liệu lạc đề, model vẫn phải trả lời với những gì có — không có cơ hội tìm lại.
- Không kiểm. Model không tự hỏi "ngữ cảnh này có thực sự đủ để trả lời không?". Nó cứ trả lời, kể cả khi context rỗng nghĩa hoặc mâu thuẫn → nguồn gốc của bịa đặt (hallucination).
- Không đa bước. Câu hỏi cần suy luận nhiều chặng ("khách này đủ điều kiện vay gói kia không?") đòi tra lần lượt nhiều thông tin, mỗi bước phụ thuộc kết quả bước trước. Một lần embed không bung ra được chuỗi đó.
- Không đa nguồn. Truy hồi luôn nhắm vào một vector store. Nhưng câu trả lời thật có thể nằm rải ở SQL, API nội bộ, hoặc knowledge graph.
Agentic RAG đảo ngược quyền điều khiển. Thay vì pipeline cố định gọi LLM như một bước phụ, ta để LLM làm trung tâm điều phối: chính model quyết định có cần truy hồi không, truy hồi cái gì, có lặp lại không nếu chưa đủ, và dùng công cụ nào. Truy hồi trở thành một hành động model chủ động gọi, không phải một khâu đường ống chạy sẵn. Đây là nơi RAG gặp agent — nền tảng ở Harness engineering cho agent và RAG với agent.
Từ pipeline sang vòng lặp tác tử
Điểm khác biệt bản chất: RAG cổ điển là đồ thị phẳng một chiều; agentic RAG là vòng lặp có điều kiện dừng. Model chạy một chu trình quen thuộc của agent (xem agentic loop):
- Suy luận (reason): với câu hỏi và những gì đã biết, mình còn thiếu gì?
- Hành động (act): gọi một công cụ — thường là
search, nhưng có thể là SQL, API... - Quan sát (observe): đọc kết quả trả về.
- Đánh giá (evaluate): kết quả có đủ và đáng tin để trả lời chưa? Nếu chưa, quay lại bước 1 với truy vấn tinh chỉnh.
- Dừng: khi đã đủ, tổng hợp và trả lời — hoặc khi cạn ngân sách bước.
Trong khung này, retrieval là một tool của agent, không phải khâu bắt buộc. Nếu câu hỏi là "1 + 1 bằng mấy" hay "xin chào", agent có thể bỏ qua truy hồi hoàn toàn — tiết kiệm chi phí và tránh nhồi context vô ích. Ý tưởng "retrieval như một công cụ" nối thẳng với nguyên tắc thiết kế công cụ cho agent (tool design).
Vòng lặp này chính là chỗ RAG thừa hưởng kỷ luật verification của agent: đừng tin ngay output của một bước, hãy kiểm rồi mới dừng (verification & eval).
Bốn mẫu agentic RAG
Có bốn mẫu (pattern) hay gặp. Chúng không loại trừ nhau — hệ thống thực tế thường ghép nhiều mẫu.
Self-RAG — model tự phản tỉnh
Self-RAG (Asai et al., 2023) huấn luyện model sinh ra các reflection token (token phản tỉnh) xen giữa quá trình trả lời. Bốn loại quyết định chính:
- Retrieve? — Với đoạn văn sắp sinh, có cần truy hồi không, hay kiến thức nội tại đã đủ? Điều này cho phép truy hồi theo nhu cầu, ở giữa câu trả lời, không chỉ một lần đầu.
- IsRelevant — Tài liệu vừa lấy về có liên quan tới câu hỏi không?
- IsSupported — Câu (mệnh đề) mình vừa viết có được tài liệu hỗ trợ không, hay đang bịa?
- IsUseful — Câu trả lời tổng thể có thực sự hữu ích cho người hỏi không?
Điểm cốt lõi: model tự chấm mức độ liên quan và mức độ được-hỗ-trợ của chính câu trả lời, rồi dùng điểm đó để chọn nhánh sinh tốt hơn hoặc truy hồi thêm. Bản gốc Self-RAG cần fine-tune để model sinh các token này; nhưng tinh thần "tự phản tỉnh trước khi chốt" có thể mô phỏng bằng prompt với model mạnh mà không cần huấn luyện lại.
Corrective RAG (CRAG) — đánh giá rồi tự sửa
Corrective RAG (Yan et al., 2024) tập trung vào một câu hỏi: tài liệu truy hồi có đủ tốt không? Nó thêm một retrieval evaluator (bộ đánh giá truy hồi) cho điểm chất lượng của tập tài liệu lấy về, rồi rẽ nhánh:
- Correct (tốt): tài liệu liên quan → tinh lọc, giữ phần cốt lõi, trả lời như bình thường.
- Ambiguous (lưng chừng): kết hợp cả tài liệu nội bộ và mở rộng ra ngoài (ví dụ web search).
- Incorrect (kém): tài liệu nội bộ lạc đề → bỏ, chuyển sang nguồn khác: viết lại truy vấn và/hoặc tìm web.
CRAG là hiện thân trực tiếp của chữ "corrective": khi truy hồi thất bại, đừng cắm đầu trả lời — hãy sửa bằng cách đổi truy vấn hoặc đổi nguồn. Trong ngân hàng, "tìm web" thường bị chặn; ta thay bằng "tìm ở nguồn nội bộ thứ hai" (ví dụ hệ thống chính sách khác, hoặc GraphRAG).
Iterative / multi-hop retrieval — truy hồi nhiều chặng
Câu hỏi đa bước cần truy hồi nhiều vòng, mỗi vòng dùng kết quả vòng trước làm đầu vào. Ví dụ: "Chi nhánh nào có dư nợ nhóm 5 cao nhất, và cán bộ phụ trách khách hàng lớn nhất ở đó là ai?" — bước 1 tìm chi nhánh, bước 2 mới tìm được cán bộ. Đây là chỗ query decomposition (phân rã truy vấn, xem query transformation) ghép với vòng lặp: agent tách câu hỏi lớn thành chuỗi truy vấn con, giải lần lượt, tích luỹ dữ kiện cho tới khi đủ.
Khác với single-shot ở chỗ: agent không biết trước cần bao nhiêu chặng. Số vòng do nội dung câu hỏi quyết định tại thời điểm chạy — nên bắt buộc phải có cơ chế dừng (ngân sách bước) kẻo lặp vô hạn.
Router / tool-use — chọn đúng nguồn
Không phải câu hỏi nào cũng nên tra vector store. Router phân loại câu hỏi và định tuyến tới nguồn phù hợp:
| Loại câu hỏi | Nguồn phù hợp |
|---|---|
| "Chính sách vay tín chấp quy định gì về thu nhập tối thiểu?" | Vector store (tài liệu chính sách) |
"Tổng dư nợ của khách CIF X là bao nhiêu?" | SQL / kho dữ liệu |
| "Tỷ giá USD hôm nay?" | API nội bộ |
| "Khách A liên đới với công ty B qua những ai?" | GraphRAG |
Mỗi nguồn là một tool với mô tả rõ khi nào nên dùng. Model đọc mô tả, chọn công cụ, hoặc gọi lần lượt nhiều công cụ rồi hợp nhất. Chất lượng router phụ thuộc nặng vào việc viết mô tả công cụ tốt (tool design): tên rõ nghĩa, tham số tối thiểu, ranh giới sử dụng không chồng lấn.
Pseudocode: vòng lặp có ngân sách
Dưới đây là minh hoạ (không phải code chạy được) một agentic RAG tối giản: một tool search, vòng lặp truy hồi → đánh giá → (truy hồi lại / trả lời), có ngân sách bước. Dùng model claude-opus-4-8 với thinking ở chế độ adaptive (model tự điều tiết mức suy luận theo độ khó). Các hàm grade_* là chỗ model tự đánh giá — tinh thần của Self-RAG/CRAG.
# MINH HOẠ — không phải API thật, không chạy được như-là
from anthropic import Anthropic
client = Anthropic()
MODEL = "claude-opus-4-8"
MAX_STEPS = 4 # ngân sách bước: chặn lặp vô hạn & khống chế chi phí
SEARCH_TOOL = {
"name": "search",
"description": "Truy hồi đoạn tài liệu chính sách/hồ sơ liên quan. "
"Dùng khi câu hỏi cần dữ kiện từ kho tri thức nội bộ.",
"input_schema": {
"type": "object",
"properties": {"query": {"type": "string"}},
"required": ["query"],
},
}
def agentic_rag(question: str) -> str:
context, history = [], []
for step in range(MAX_STEPS):
# 1) Model suy luận: cần truy hồi gì tiếp, hay đã đủ để trả lời?
resp = client.messages.create(
model=MODEL,
thinking={"type": "adaptive"}, # thinking adaptive: model tự chỉnh độ sâu
tools=[SEARCH_TOOL],
messages=build_messages(question, context, history),
)
if resp.stop_reason != "tool_use":
return resp.text # model tự thấy đủ → chốt câu trả lời
# 2) Hành động: chạy tool search
query = get_tool_input(resp)["query"]
docs = vector_search(query, k=8)
# 3) Đánh giá (CRAG): tài liệu có liên quan không?
if grade_relevance(question, docs) == "kém":
better = rewrite_query(question, docs) # tự sửa: viết lại truy vấn
docs = vector_search(better, k=8)
context += rerank_and_trim(docs) # giữ phần cốt lõi
history.append((query, docs))
# 4) Tự kiểm (Self-RAG): ngữ cảnh đã đủ để trả lời chắc chắn chưa?
if grade_sufficiency(question, context) == "đủ":
return answer_with_context(question, context)
# Hết ngân sách mà vẫn chưa đủ → trả lời thận trọng, nêu rõ giới hạn
return answer_conservatively(question, context)
Ý chính cần nhớ từ đoạn này: (1) truy hồi là một nhánh có điều kiện, không mặc định; (2) có hai chốt đánh giá — relevance của tài liệu và sufficiency của ngữ cảnh; (3) MAX_STEPS là van an toàn bắt buộc; (4) khi cạn ngân sách, hệ thống thoái lui an toàn (trả lời thận trọng hoặc báo thiếu dữ liệu) chứ không bịa.
Đánh đổi: chất lượng đổi lấy chi phí và độ trễ
Agentic RAG cho chất lượng cao hơn hẳn ở câu hỏi khó, nhưng không miễn phí. Mỗi vòng lặp là thêm ít nhất một lời gọi LLM (đôi khi vài lời gọi cho các bước grade). So với single-shot:
| Chiều | RAG một-lượt | Agentic RAG |
|---|---|---|
| Số lời gọi LLM | 1 | 1 → nhiều (theo độ khó) |
| Độ trễ | Thấp, ổn định | Cao hơn, biến thiên |
| Chi phí token | Thấp | Cao hơn (context tích luỹ qua vòng) |
| Chất lượng câu khó | Trung bình | Cao |
| Câu dễ | Đủ dùng | Lãng phí nếu không có router |
Vì thế nguyên tắc thực chiến là đặt ngân sách bước (step budget) và định tuyến sớm:
- Ngân sách bước cứng (
MAX_STEPS): 3–5 vòng thường là hợp lý. Không có nó, một câu hỏi hóc búa có thể kéo model lặp mãi. - Router chặn đầu vào: câu dễ đi thẳng, chỉ câu khó mới vào vòng lặp đầy đủ — tránh trả giá agentic cho mọi truy vấn.
- Context tích luỹ có kiểm soát: mỗi vòng thêm tài liệu, context phình ra nhanh; cần rerank + cắt gọn mỗi vòng, kẻo vừa tốn token vừa loãng tín hiệu.
- Đo trước khi bật đại trà: không phải bài toán nào cũng đáng agentic. Nếu single-shot đã đạt ngưỡng chất lượng, thêm vòng lặp chỉ tăng chi phí. Cách đo và vận hành nằm ở đánh giá & production.
Use case thực tế
Bối cảnh NCB. Bộ phận tín dụng muốn một trợ lý trả lời câu hỏi nghiệp vụ đa bước, điển hình: "Khách hàng CIF X có đủ điều kiện vay gói tín chấp lương Y không?". Đây đúng là chỗ RAG một-lượt bó tay: đáp án không nằm gọn trong một tài liệu, mà cần tổng hợp ba nguồn khác nhau, và mỗi nguồn lại phụ thuộc kết quả nguồn trước.
Agent chạy qua các chặng (các con số dưới đây là ước lượng minh hoạ):
- Tra hồ sơ khách (SQL / kho dữ liệu): thu nhập chứng minh ~28 triệu/tháng, nhóm nợ hiện tại (CIC) nhóm 1, có 1 khoản vay đang trả dư nợ ~120 triệu.
- Tra điều kiện gói
Y(vector store — tài liệu chính sách): gói tín chấp lương yêu cầu thu nhập tối thiểu 15 triệu, không có nợ nhóm 2 trở lên, tỷ lệ DTI (nợ/thu nhập) ≤ 60%. - Đánh giá & sửa (CRAG): lần truy hồi chính sách đầu mang về bản gói vay thế chấp — bộ đánh giá chấm "lạc đề" → agent viết lại truy vấn thêm từ khoá "tín chấp lương cán bộ" → lấy đúng văn bản.
- Tra hạn mức/quy tắc bổ sung (multi-hop): phát hiện chính sách dẫn chiếu một quy định hạn mức theo chi nhánh → agent sinh truy vấn con thứ hai để lấy trần hạn mức áp dụng.
- Kiểm chứng trước khi trả lời (verification): agent tự tính DTI ≈ (nghĩa vụ trả nợ hiện tại + dự kiến) / thu nhập, đối chiếu từng điều kiện, xác nhận mọi mệnh đề đều được tài liệu hỗ trợ (tinh thần IsSupported của Self-RAG) rồi mới kết luận "đủ điều kiện, với hạn mức đề xuất ~150 triệu — cần cán bộ thẩm định xác nhận".
Ngân sách được đặt MAX_STEPS = 5. Ước lượng nội bộ: so với trợ lý single-shot, phiên bản agentic tốn ~3–4 lời gọi LLM mỗi câu và độ trễ ~2–3 lần, nhưng giảm rõ tỷ lệ trả lời sai/thiếu điều kiện trên bộ câu hỏi thẩm định — đánh đổi chấp nhận được vì hậu quả của một kết luận vay sai lớn hơn nhiều chi phí token. Quan trọng: đầu ra luôn kèm trích dẫn điều khoản và cảnh báo "cần người thẩm định xác nhận" — agent hỗ trợ quyết định, không thay quyết định phê duyệt.
Ghi nhớ
- RAG một-lượt = truy hồi 1 lần rồi trả lời: không lặp, không kiểm, không đa bước, không đa nguồn. Agentic RAG để model tự quyết định có/không truy hồi, truy hồi gì, lặp hay dừng, dùng công cụ nào.
- Retrieval trở thành một tool của agent, không phải khâu bắt buộc — câu dễ có thể bỏ qua truy hồi.
- Self-RAG: model tự sinh reflection token, tự chấm liên quan (IsRelevant) và được hỗ trợ (IsSupported) của chính câu trả lời; truy hồi theo nhu cầu.
- Corrective RAG (CRAG): đánh giá chất lượng tài liệu; kém → viết lại truy vấn / đổi nguồn / tìm web (trong ngân hàng: nguồn nội bộ thứ hai).
- Iterative / multi-hop: truy hồi nhiều vòng cho câu đa bước, ghép với query decomposition; số vòng do câu hỏi quyết định lúc chạy.
- Router / tool-use: chọn nguồn đúng (vector store / SQL / API / GraphRAG) qua mô tả công cụ rõ ràng.
- Vòng lặp: retrieve = tool → đánh giá relevance & sufficiency → verify được-hỗ-trợ → dừng khi đủ. Thừa hưởng kỷ luật verification của agent.
- Đánh đổi: chất lượng cao hơn nhưng nhiều lời gọi LLM (chi phí + độ trễ). Luôn đặt ngân sách bước (3–5 vòng), định tuyến sớm, cắt gọn context mỗi vòng, và đo trước khi bật đại trà.
- Khi cạn ngân sách hoặc thiếu dữ liệu: thoái lui an toàn (trả lời thận trọng / báo thiếu), tuyệt đối không bịa.
Nguồn tham khảo
- Anthropic — Building Effective Agents (nguyên tắc thiết kế agent, tool-use, workflow vs. agent)
- Asai et al. (2023), "Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection", arXiv:2310.11511
- Yan et al. (2024), "Corrective Retrieval Augmented Generation" (CRAG), arXiv:2401.15884
- Yao et al. (2022), "ReAct: Synergizing Reasoning and Acting in Language Models", arXiv:2210.03629
- Lewis et al. (2020), "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks", arXiv:2005.11401
- Anthropic Documentation — Tool use (function calling)
Bài viết liên quan
Đặt nền cho chuỗi AI: phân biệt ba vòng tròn lồng nhau AI ⊃ ML ⊃ DL và khác biệt bản chất giữa lập trình truyền thống với học từ dữ liệu. Giới thiệu ba kiểu học máy (supervised, unsupervised, reinforcement), phân loại descriptive/predictive/prescriptive, quy trình ML end-to-end, chia train/validation/test, overfitting/underfitting và các thuật ngữ nền tảng, gắn với ứng dụng ngân hàng NCB.
Harness — lớp scaffolding quanh model (vòng lặp, tool, context, memory, verify, sub-agent) — mới là thứ quyết định agent chạy được hay chỉ là demo. Bài này mổ xẻ giải phẫu một harness, 7 kỹ năng cốt lõi khi xây agent, single vs multi-agent (kèm số liệu hiệu quả/chi phí), các repo nên dùng, và một quickstart Python dựng-là-chạy cho bối cảnh ngân hàng.
Hiểu LLM từ gốc: bản chất dự đoán token, ba giai đoạn huấn luyện (pretraining, fine-tuning, RLHF), token, context window và các tham số sinh (temperature, top-p). Nắm hiện tượng hallucination và kỹ thuật prompt engineering (vai trò, few-shot, chain-of-thought, ràng buộc đầu ra), kèm ví dụ gọi API model Claude mới nhất với adaptive thinking.
Vì sao dữ liệu quyết định chất lượng mô hình hơn cả thuật toán. Bài này đi qua toàn bộ pipeline chuẩn bị dữ liệu: phân loại dữ liệu, làm sạch (thiếu/ngoại lai/trùng lặp), mã hoá hạng mục, scaling, feature engineering, giảm chiều, và cách phòng data leakage — soi qua bài toán chấm điểm tín dụng.
Cảm nhận của bạn
Bình luận
Chưa có bình luận. Hãy là người đầu tiên chia sẻ!