RAG hay Tool Use? Cách tôi chọn cho một chatbot doanh nghiệp
Khi build bot tư vấn cho spa, câu hỏi kỹ thuật đầu tiên là: làm sao bot biết được giá, dịch vụ, lịch trống? Mặc định nhiều người nghĩ tới RAG — nhúng tài liệu vào vector database rồi truy hồi. Tôi đã chọn khác. Bài này giải thích cách tôi quyết định, để bạn khỏi vung dao mổ trâu.
Hai loại dữ liệu, hai cách xử lý
Tôi chia dữ liệu của doanh nghiệp làm hai loại — và đây là chìa khoá:
Dữ liệu tĩnh, nhỏ: danh mục dịch vụ, giá, mô tả, FAQ, chính sách, giọng thương hiệu. Những thứ này ít thay đổi và không lớn (một spa có vài trăm dịch vụ — chỉ vài chục nghìn token).
Dữ liệu động: lịch trống, tình trạng đặt hẹn, hồ sơ khách, khuyến mãi đang chạy. Những thứ thay đổi liên tục và phải lấy đúng thời điểm.
Dữ liệu tĩnh: nhồi vào prompt + bật caching
Với dữ liệu tĩnh nhỏ, tôi không dùng RAG. Tôi nhồi thẳng toàn bộ vào system prompt và bật prompt caching. Phần prompt lặp lại được cache, nên rẻ và nhanh. Không cần vector database, không cần hạ tầng truy hồi, không có rủi ro truy hồi nhầm đoạn.
Với quy mô một spa, prompt tĩnh chỉ khoảng 16 nghìn token — nhỏ xíu so với cửa sổ ngữ cảnh hiện đại. Tại sao phải dựng cả một pipeline RAG cho thứ nhét vừa trong prompt?
Dữ liệu động: tool use
Với dữ liệu động, tôi cho model gọi tool (function calling): check_availability, create_booking, get_customer... Model tự quyết khi nào cần gọi, lấy số liệu thật về, rồi trả lời. Lịch trống không bao giờ được đoán — luôn qua tool.
Đây cũng là quy tắc vàng của tôi:
Bot không bao giờ tự nói giá hay lịch từ trí nhớ. Mọi con số phải đến từ nguồn thật. Báo sai là thứ giết niềm tin nhanh nhất.
Vậy khi nào mới thật sự cần RAG?
RAG không sai — nó sai ngữ cảnh. Bạn cần RAG khi kho kiến thức lớn và không có cấu trúc: hàng nghìn trang tài liệu, hợp đồng, bài viết, lịch sử hỗ trợ... lớn tới mức không nhét vừa prompt. Lúc đó truy hồi theo ngữ nghĩa mới đáng công.
Còn với một doanh nghiệp nhỏ có dữ liệu gọn gàng, RAG là phức tạp hoá không cần thiết. Tôi chỉ thêm vector database khi kiến thức thật sự phình to — không phải vì nó "nghe có vẻ AI".
Khung quyết định nhanh
- Dữ liệu tĩnh + nhỏ (nhét vừa prompt)? → nhồi vào prompt + caching.
- Dữ liệu động (đổi liên tục, cần realtime)? → tool use.
- Dữ liệu lớn + phi cấu trúc (không nhét vừa)? → lúc này mới RAG.
Phần lớn dự án doanh nghiệp nhỏ chỉ cần hai cái đầu. Đừng để công nghệ thời thượng dẫn dắt quyết định kiến trúc — hãy để bài toán dẫn.
Bài này rút ra từ chính con bot tôi đang vận hành. Bạn có thể chat thử để thấy tool use hoạt động ra sao. Thích kiểu nội dung kỹ thuật thực chiến này? Đăng ký email ở cuối trang nhé.