Khi Nào Nên Dùng RAG, Khi Nào Full-Text Search Đã Đủ?
Giới Thiệu
RAG đang bị dùng như một từ khóa thần kỳ. Hễ có tài liệu, có chatbot, có tìm kiếm là nhiều người lập tức nghĩ đến vector database và prompt augmentation. Nhưng trong rất nhiều ứng dụng nhỏ và vừa, full-text search đã giải quyết đủ tốt bài toán với chi phí thấp hơn hẳn.
Điều quan trọng không phải là RAG có hiện đại hay không. Điều quan trọng là bài toán của bạn có thực sự cần nó không.
Mục lục
- Khi nào full-text search là đủ
- Khi nào nên thêm semantic retrieval
- Khi nào RAG thật sự hợp lý
- Các câu hỏi nên trả lời trước khi chọn RAG
- Chi phí ẩn và failure mode của RAG
- Cách rollout tăng dần an toàn hơn
Full-Text Search Đủ Tốt Khi Nào?
Full-text search thường là lựa chọn tốt nếu:
- nội dung có từ khóa khá rõ ràng
- người dùng quen domain vocabulary
- dữ liệu không quá mơ hồ
- bạn chỉ cần tìm đúng bài hoặc đoạn liên quan
Ví dụ: tìm bài về Laravel Octane, rate limiting, EXPLAIN query plan. Với các truy vấn như vậy, keyword search thường đủ nhanh và dễ giải thích.
Khi Nào Nên Thêm Semantic Retrieval?
Bạn nên cân nhắc embeddings khi:
- người dùng diễn đạt vấn đề theo nhiều cách khác nhau
- nội dung có nhiều khái niệm tương đương nhưng khác từ ngữ
- bạn muốn tìm các đoạn "gần nghĩa" thay vì chỉ khớp từ
Đây chưa chắc đã cần RAG. Nhiều trường hợp chỉ semantic search là đủ.
Khi Nào RAG Thật Sự Hợp Lý?
RAG đáng dùng khi hệ thống không chỉ tìm kiếm mà còn phải sinh câu trả lời dựa trên tài liệu hiện có. Ví dụ:
- chatbot hỏi đáp cho docs nội bộ
- assistant hỗ trợ support từ knowledge base
- AI trả lời câu hỏi về policy hoặc quy trình công ty
Lúc này, retrieval đóng vai trò đưa đúng context vào prompt trước khi model sinh câu trả lời.
Một Sai Lầm Phổ Biến: Dùng RAG Để Che Đi Vấn Đề Search Cơ Bản
Nhiều team gặp tình huống keyword search chưa tốt, semantic retrieval chưa được đánh giá kỹ, nhưng đã vội thêm LLM để "cải thiện trải nghiệm". Kết quả là họ chỉ che một lớp vấn đề bằng một lớp phức tạp hơn.
Nếu retrieval kém, RAG cũng sẽ trả lời kém. Nó chỉ trả lời trôi chảy hơn mà thôi.
So Sánh 3 Mức Độ Giải Pháp
Full-text search
Ưu điểm:
- rẻ
- nhanh
- dễ giải thích
- dễ debug
Nhược điểm:
- kém linh hoạt với từ đồng nghĩa hoặc diễn đạt tự nhiên
Semantic search
Ưu điểm:
- tìm được nội dung gần nghĩa
- phù hợp với cách người dùng hỏi tự nhiên
Nhược điểm:
- khó debug hơn keyword search
- phải duy trì pipeline embeddings và ranking
RAG
Ưu điểm:
- có thể tổng hợp câu trả lời từ tài liệu riêng
- trải nghiệm hỏi đáp tự nhiên hơn
Nhược điểm:
- thêm token cost
- thêm prompt engineering
- thêm failure modes mới
- dễ hallucinate nếu retrieval hoặc grounding kém
Một Cây Quyết Định Rất Thực Dụng
Nếu chỉ cần tìm tài liệu liên quan -> bắt đầu với full-text search.
Nếu tìm kiếm bằng từ đồng nghĩa hoặc diễn đạt tự nhiên chưa ổn -> thêm semantic search.
Nếu cần model tổng hợp câu trả lời từ tài liệu -> dùng RAG.
Đa số hệ thống nên đi theo đúng thứ tự đó.
Những Câu Hỏi Nên Trả Lời Trước Khi Chọn RAG
- Người dùng đang muốn tìm tài liệu hay muốn nhận câu trả lời tổng hợp?
- Nội dung có thay đổi thường xuyên không?
- Search hiện tại đang fail ở recall hay ở UX trình bày?
- Team có sẵn sàng duy trì chunking, retrieval evaluation và prompt versioning không?
- Nếu AI trả lời sai, hậu quả có nghiêm trọng không?
Nếu chưa rõ các câu này, thường là bạn chưa nên đi thẳng vào RAG.
Một Ví Dụ Rất Thực Tế Với Blog Kỹ Thuật
Giả sử bạn có 300 bài viết kỹ thuật và người dùng chủ yếu muốn:
- tìm lại bài đã đọc trước đó
- tìm bài theo chủ đề như cache, queue, search, performance
- tìm đoạn giải thích ngắn về một kỹ thuật cụ thể
Trong kịch bản này, full-text search tốt cộng với semantic search nhẹ thường đã đủ. Bạn chưa cần RAG vì người dùng vẫn muốn đọc bài gốc, không nhất thiết muốn chatbot trả lời thay.
Ngược lại, nếu bạn xây internal assistant cho team support để trả lời câu hỏi từ hàng trăm trang docs và policy, lúc đó RAG đáng cân nhắc hơn hẳn.
Chi Phí Ẩn Của RAG
RAG không chỉ thêm embeddings. Nó còn thêm:
- pipeline indexing
- kiểm soát chunking
- ranking và deduplication
- prompt engineering
- đánh giá chất lượng retrieval
- chi phí token khi chèn context
Nếu bài toán không cần sinh câu trả lời, bạn đang trả thêm complexity không cần thiết.
Một Cách Đi Tăng Dần An Toàn Hơn
Thay vì nhảy thẳng vào chatbot RAG, bạn có thể triển khai theo thứ tự:
- cải thiện full-text search
- thêm semantic search
- thêm answer suggestions từ top results
- chỉ khi cần mới chuyển sang answer generation bằng LLM
Mỗi bước đều đo được giá trị riêng và dễ rollback hơn.
Những Failure Mode Của RAG Mà Nhiều Team Bỏ Qua
- retrieval lấy nhầm đoạn gần nghĩa nhưng sai ngữ cảnh
- model trả lời rất tự tin dù context không đủ
- context quá dài làm tăng token cost nhưng không tăng chất lượng
- chunk quan trọng bị index sai nên không bao giờ được lấy ra
Các failure mode này khiến RAG nhìn rất ấn tượng trong demo nhưng lại khó tin cậy hơn khi dùng thật.
FAQ
RAG có thay thế docs search không?
Không. Ít nhất trong giai đoạn đầu, RAG nên bổ sung chứ không thay hẳn docs search. Người dùng kỹ thuật thường vẫn muốn đọc nguồn gốc thông tin.
Khi nào chỉ cần semantic search mà không cần RAG?
Khi mục tiêu chỉ là tìm đúng bài hoặc đúng đoạn liên quan, không cần model tổng hợp thành câu trả lời tự nhiên.
Key takeaways:
- Full-text search thường nên là bước khởi đầu mặc định vì rẻ, nhanh và dễ debug.
- Semantic search phù hợp khi người dùng diễn đạt theo nhiều cách khác nhau.
- RAG chỉ đáng làm khi hệ thống cần sinh câu trả lời dựa trên dữ liệu riêng.
- Nếu retrieval kém, RAG cũng sẽ kém nhưng nghe thuyết phục hơn.
- Hãy rollout theo từng tầng thay vì nhảy thẳng vào chatbot RAG.
Kết Luận
RAG rất hữu ích, nhưng không nên là bước đầu tiên mặc định. Với blog, docs hoặc knowledge base nhỏ, full-text search hoặc semantic search thường là các bước nền hợp lý hơn. Chỉ nên thêm RAG khi bạn thực sự cần một lớp answer generation dựa trên dữ liệu riêng.