Originally published on NextFuture
Bạn hỏi chatbot RAG "thư viện nào được dùng nhiều nhất" và nhận về một câu trả lời nghe rất thuyết phục — nhưng sai. Đó không phải lỗi của model, mà là bạn đang bắt retrieval làm việc của một database.
Một dev đã gặp đúng vấn đề này khi xây chatbot tra cứu hơn 300 bài capstone của cohort LLM Zoomcamp 2026 — mỗi bài là một repo GitHub thật, có README, dependency manifest và điểm leaderboard riêng.
Hai loại câu hỏi cần hai cách retrieval khác nhau
Câu hỏi về nội dung — "project X làm gì, implement reranking thế nào" — chỉ cần tìm đúng đoạn README rồi ground câu trả lời vào đó. Nhưng câu hỏi tổng hợp — "thư viện nào phổ biến nhất, project nào điểm cao nhất" — là một bài toán truy vấn trên metadata có cấu trúc: điểm số, vote, pass/fail, theme, dependency khai báo.
Bắt một LLM "đếm" hay "xếp hạng" trên một đống chunk văn bản lấy về, nó sẽ trả lời rất tự tin nhưng rất dễ sai — không phải vì model kém, mà vì đếm không phải bài toán retrieval. Có một bẫy tinh vi hơn: "project điểm cao nhất" và "người đứng đầu leaderboard" nghe giống nhau nhưng là hai con số khác nhau — điểm riêng của project và tổng điểm khóa học của tác giả (bài tập + project + learning-in-public). Nhầm lẫn hai con số này là lỗi thật, tác giả đã gặp và phải sửa.
Kiến trúc: một router, hai cách "biết"
Thay vì chọn một chiến lược retrieval duy nhất, hệ thống đặt một agentic router đứng trước hai tool hoàn toàn khác nhau. Tool thứ nhất là search_docs: hybrid keyword+vector search, fuse bằng RRF, rerank bằng cross-encoder, và query được LLM viết lại trước khi tìm. Tool thứ hai là 11 hàm SQL viết tay, tham số hoá — không bao giờ để LLM tự sinh SQL. Câu hỏi "thư viện nào phổ biến nhất" không bao giờ chạm vào khả năng đếm của model — nó chạy thẳng COUNT(*) ... GROUP BY.
Ở phía ingestion, việc phân loại theme và tech-stack chạy qua OpenAI Batch API theo lô, offline — rẻ hơn khoảng 50% so với gọi API đồng bộ từng project một.
Vòng lặp tool-calling không có gì lạ
Bản thân vòng lặp gọi tool rất quen thuộc với ai đã làm agent: đưa cho model câu hỏi cùng danh sách tool schema, để nó chọn 0 hoặc nhiều tool, đưa kết quả ngược lại, lặp lại tới khi model trả lời cuối cùng thay vì gọi thêm tool. Cái khác biệt không nằm ở vòng lặp — mà ở việc router biết khi nào nên nhường quyền "đếm" cho SQL, thay vì để model tự đoán.
Áp dụng cho RAG nội bộ của bạn
Nếu team bạn có một corpus nội bộ vừa cần tra cứu nội dung vừa cần thống kê — số lượng ticket theo loại, top reviewer, tổng thời gian xử lý — đừng ép một pipeline RAG duy nhất gánh cả hai. Tách câu hỏi tổng hợp ra một lớp SQL tham số hoá riêng, và chỉ dùng vector search cho câu hỏi nội dung thật sự cần ngữ nghĩa.
This article was originally published on NextFuture. Follow us for more fullstack & AI engineering content.
Top comments (0)