RAG (Retrieval-Augmented Generation) là kỹ thuật cho phép agent truy xuất tài liệu liên quan trước khi trả lời, thay vì chỉ dựa vào kiến thức đã học trong trọng số của mô hình. Với agent, RAG chính là "bộ nhớ ngoài" giúp nó trả lời dựa trên dữ liệu thật của bạn: tài liệu nội bộ, chính sách công ty, lịch sử ticket, hồ sơ sản phẩm.
Vì sao agent cần RAG
Một LLM thuần có 3 điểm yếu chí mạng khi làm việc thật:
- Kiến thức đóng băng tại thời điểm training — không biết chính sách mới sửa hôm qua.
- Ảo giác (hallucination) — bịa số liệu, bịa điều khoản khi không chắc.
- Không có ngữ cảnh riêng của tổ chức bạn.
Kiến trúc pipeline RAG cho agent
Pipeline gồm 2 pha:
Pha offline (indexing):
Tài liệu → Chunking → Embedding → Lưu vào Vector Index
Pha online (khi agent nhận câu hỏi):
Câu hỏi → Embedding → Retrieval (top-k) → Rerank → Đưa context vào LLM → Trả lời
Điểm khác biệt của RAG cho agent so với chatbot RAG đơn giản: agent có thể quyết định có nên retrieval hay không, viết lại truy vấn, và gọi retrieval nhiều vòng trong một tác vụ.
Ví dụ cụ thể
Giả sử bạn xây agent hỗ trợ nhân viên tra cứu quy chế. Nhân viên hỏi: "Nghỉ phép năm chưa dùng hết có được quy đổi thành tiền không?"
- Agent embed câu hỏi.
- Retrieval trả về 5 đoạn từ tài liệu "Quy chế lao động 2026".
- Rerank đẩy đoạn nói đúng về "quy đổi phép năm" lên đầu.
- LLM tổng hợp và trả lời: "Theo mục 4.2 Quy chế 2026, phép năm chưa dùng được quy đổi tối đa 5 ngày..." kèm trích dẫn.
Các bước thiết lập tư duy trước khi code
- Xác định nguồn tri thức: tài liệu nào agent được phép đọc?
- Xác định câu hỏi thật người dùng sẽ hỏi (thu thập 30–50 câu mẫu).
- Chọn ngưỡng chất lượng: agent cần recall bao nhiêu % mới chấp nhận được?
- Quyết định khi nào retrieval: luôn luôn, hay chỉ khi câu hỏi cần dữ kiện?
- Thiết kế trích dẫn: mỗi câu trả lời phải chỉ ra nguồn.
Khung tư duy: RAG có phải giải pháp đúng không?
Dùng checklist sau trước khi đầu tư:
- [ ] Câu trả lời phụ thuộc dữ liệu riêng hoặc thay đổi thường xuyên? → RAG hợp lý.
- [ ] Dữ liệu vừa đủ nhỏ để nhét hết vào context? → Có thể không cần vector index, chỉ cần đưa thẳng.
- [ ] Cần suy luận nhiều bước hơn là tra cứu? → RAG chỉ là một phần, cần thêm tool/planning.
- [ ] Dữ liệu là bảng số/quan hệ chặt? → Cân nhắc text-to-SQL thay vì RAG thuần.
Sai lầm thường gặp
- Dùng RAG cho mọi thứ: nếu câu hỏi là "2+2 bằng mấy" thì retrieval chỉ làm chậm và nhiễu.
- Nghĩ RAG là xong khi đã có vector DB: chất lượng nằm ở chunking và reranking, không phải ở việc chọn database.
- Không đo lường: triển khai RAG mà không có tập câu hỏi đánh giá thì bạn đang bay mù.
- Quên trích dẫn: agent trả lời đúng nhưng không chỉ nguồn thì người dùng không tin và không kiểm chứng được.