RAG đơn giản hơn bạn nghĩ: 6 công thức truy xuất thông minh từ tối giản đến phức tạp

Trong giới công nghệ hiện nay, có vẻ như hầu hết mọi người đang "làm quá" lên kiến trúc RAG (Retrieval-Augmented Generation) của mình. Họ lao thẳng vào embeddings, vector database, và các pipeline reranking phức tạp. Trong khi đó, người dùng của họ chỉ đơn giản muốn tìm được tài liệu hướng dẫn "Cách đặt lại mật khẩu".

Trong kỹ thuật, luôn có công cụ phù hợp cho từng vấn đề. Với hệ thống truy xuất AI cũng vậy. Bài viết này sẽ giúp bạn xác định đúng mức độ phức tạp cần thiết cho hệ thống của mình.

Mô tả các công thức RAG từ đơn giản đến phức tạp

Các yếu tố quyết định trước khi chọn giải pháp

Trước khi đi vào chi tiết từng công thức, hãy xác định khi nào nên dùng cách tiếp cận nào. Các yếu tố chính bao gồm:

1. Yêu cầu về độ mới của dữ liệu (Data Freshness)

• Cập nhật theo thời gian thực (tin tức, mạng xã hội) ưu tiên các cách tiếp cận dễ dàng lập chỉ mục lại
• Cập nhật hàng ngày hoặc hàng tuần phù hợp với phương pháp lai (hybrid)
• Kho dữ liệu ổn định (cập nhật hàng tháng/quý) phù hợp với việc tiền embedding

2. Đặc điểm của kho dữ liệu (Corpus)

• Dữ liệu biến động cao (hơn 10% thay đổi mỗi ngày) → tránh tiền embedding toàn phần
• Tài liệu ổn định → tiền embedding hoạt động tốt
• Phân bố đuôi dài (90% tài liệu không bao giờ được truy cập) → embedding theo yêu cầu (on-the-fly) thắng

3. Mẫu truy vấn (Query Patterns)

• Truy vấn dạng từ khóa → bắt đầu với tìm kiếm full-text
• Truy vấn ngữ nghĩa hoặc hội thoại → hưởng lợi từ embeddings
• Mẫu hỗn hợp → cần phương pháp lai

4. Quy mô và hiệu suất (Scale & Performance)

• Dưới 1000 truy vấn/ngày → giải pháp đơn giản là đủ
• 1K-10K truy vấn/ngày → tối ưu hóa có chọn lọc
• Trên 10K truy vấn/ngày → cần tối ưu hóa toàn diện

5. Năng lực đội ngũ (Team Capabilities)

• Không có chuyên gia ML → giữ full-text kết hợp với viết lại truy vấn
• Có một chút kinh nghiệm ML → có thể quản lý tìm kiếm lai
• Có đội ngũ ML → các cách tiếp cận nâng cao khả thi

Công thức 1: MVP – Chỉ Tìm Kiếm Full-Text

Nó là gì? BM25 cổ điển. Elasticsearch. Tìm kiếm full-text của Postgres. Những thứ tồn tại trước khi "embedding" trở thành một động từ.

Khi nào dùng? Bạn mới bắt đầu. Người dùng viết truy vấn dạng từ khóa (kiểu "pandas merge dataframe"). Khớp chính xác quan trọng (kiểu "hóa đơn #12345"). Bạn muốn không có độ phức tạp ML. Kho dữ liệu có thuật ngữ riêng.

Ưu điểm:

• Chi phí API bằng 0, nhanh (dưới 10ms), dễ debug
• Không cần chiến lược chia nhỏ document (chunking)
• Hoạt động tốt đến bất ngờ trong nhiều trường hợp

Nhược điểm:

• Bỏ lỡ từ đồng nghĩa ("xe hơi" vs "ô tô")
• Thất bại với truy vấn ngữ nghĩa ("Làm thế nào để...?")
• Không hiểu ý định ngoài từ khóa

Kinh nghiệm thực tế: Theo tác giả Rafael Pierre, giải pháp này xử lý một phần lớn các trường hợp sử dụng. Đừng bỏ qua bước này. Khi nhảy thẳng vào embeddings, bạn phải đối mặt với câu hỏi: Kích thước chunk bao nhiêu? (512 tokens? 1024?) Overlap bao nhiêu? (50 tokens? 100?) Với full-text search, bạn bỏ qua tất cả. Tài liệu là tài liệu. Tìm kiếm chỉ hoạt động.

Công thức 2: Viết Lại Truy Vấn bằng Agent (Agentic Query Rewriting)

Nó là gì? Sử dụng LLM để biến đổi truy vấn lộn xộn của người dùng thành tìm kiếm từ khóa sạch sẽ.

Hiểu biết cốt lõi: Hầu hết các vấn đề "tìm kiếm ngữ nghĩa" thực ra là vấn đề công thức hóa truy vấn.

Khi nào dùng: Người dùng đặt câu hỏi theo cách hội thoại. Có sự lệch từ vựng (người dùng nói "sửa lỗi", tài liệu nói "debugging"). Có thuật ngữ nội bộ (framework của bạn gọi là "Atlas").

Chi phí: Khoảng $0.001 mỗi truy vấn (dùng GPT-4o-mini cho việc viết lại truy vấn).

Điều kỳ diệu: LLM có thể loại bỏ stopwords, thêm từ đồng nghĩa, dịch thuật ngữ miền, phân rã truy vấn phức tạp thành nhiều phần, và học từ bảng thuật ngữ của bạn thông qua system prompt.

Vì sao linh hoạt hơn embeddings? Với embeddings, nếu kết quả không tốt, bạn cần điều chỉnh chiến lược chunking, re-embed toàn bộ corpus, chạy regression test... Với việc viết lại truy vấn, nếu kết quả không tốt, bạn chỉ cần điều chỉnh system prompt. Hết. Kiểm tra ngay lập tức.

Ví dụ về vấn đề thuật ngữ độc quyền: Giả sử công ty bạn có framework Python tên "Atlas". Nếu dùng embedding tổng quát, "Atlas" sẽ được vector hóa theo nghĩa thần thoại Hy Lạp/bản đồ/địa lý – điểm tương đồng cực thấp với tài liệu thật. Nhưng với viết lại truy vấn, bạn có thể dùng system prompt để giữ nguyên "Atlas" như từ khóa chính xác, và BM25 sẽ khớp hoàn hảo. Với thuật ngữ độc quyền, khớp từ khóa chính xác đánh bại hiểu ngữ nghĩa.

So sánh các phương pháp truy xuất thông tin

Công thức 3: Tìm Kiếm Lai (Hybrid Search – Sparse + Dense Reranking)

Nó là gì? Dùng BM25 để lấy ứng viên (top 50-100), sau đó rerank bằng embeddings (top 10).

Vì sao hiệu quả? BM25 nhanh và giỏi khớp từ khóa. Embeddings giỏi hiểu ngữ nghĩa. Kết hợp lại che lấp nhược điểm của nhau.

Khi nào dùng: Người dùng hỏi câu hỏi ngữ nghĩa ("tìm giải pháp thay thế cho X"). BM25 + viết lại truy vấn chưa đủ (bạn có dữ liệu chứng minh). Bạn chấp nhận độ trễ 100-500ms. Kho dữ liệu tương đối ổn định.

Cân nhắc chi phí với giá hiện tại (OpenAI text-embedding-3-small $0.02/1M tokens): Embedding 50 tài liệu mỗi truy vấn (trung bình 500 tokens mỗi tài liệu) = 25.000 tokens. Chi phí: ~$0.0005 mỗi truy vấn. Với 1.000 truy vấn/ngày × 30 ngày = ~$15/tháng. Khá hợp lý. Nhưng có một điểm trừ: độ trễ. Embedding 50 tài liệu theo yêu cầu thêm 200-500ms mỗi truy vấn. Sự đánh đổi thực sự nằm ở tốc độ, không phải chi phí.

Lưu ý: Vấn đề chunking quay lại Khi giới thiệu embeddings, bạn cần quyết định cách chia nhỏ tài liệu, kích thước chunk, overlap... Điều này thêm độ phức tạp mà full-text search tránh được.

Công thức 4: Embedding Theo Yêu Cầu (The Fresh Data Play)

Hiểu biết chính: Nếu dữ liệu của bạn thay đổi thường xuyên, tại sao phải trả chi phí để re-embed mọi thứ?

Khi nào dùng: Tài liệu biến động cao (hơn 10% cập nhật mỗi ngày). Nội dung thời gian thực (tin tức, mạng xã hội). Bạn đang thử nghiệm với các mô hình embedding khác nhau. Độ mới của dữ liệu quan trọng. K nhỏ cho reranking (20-50 tài liệu).

Tính toán: Với 1000 truy vấn/ngày, 50 tài liệu/truy vấn: Chi phí embedding ~$15/tháng, lưu trữ $0, độ trễ 200-500ms, độ mới hoàn hảo, dễ dàng đổi mô hình.

Lợi ích không ai nói đến: Vấn đề mô hình bị ngừng hỗ trợ (model deprecation) OpenAI đã ngừng hỗ trợ text-embedding-ada-002 chuyển sang text-embedding-3. Nếu bạn đã tiền embedding 10 triệu tài liệu với mô hình cũ, bạn cần re-embed toàn bộ, cập nhật vector database, chạy regression test, xác nhận chất lượng không giảm. Với on-the-fly embedding, bạn chỉ cần đổi một dòng code. Xong.

Nhược điểm: Độ trễ. Bạn đang embedding tài liệu trên mỗi truy vấn. Chỉ khả thi nếu bạn chấp nhận độ trễ 200-500ms và K nhỏ.

Công thức 5: Tiền Embedding với Phân Tầng Nóng/Lạnh (The Pragmatic Play)

Nó là gì? Tiền embedding các tài liệu thường được truy cập (tầng "nóng"), embedding theo yêu cầu cho tài liệu ít được truy cập (tầng "lạnh").

Hiểu biết chính: Mẫu truy cập tuân theo phân bố Pareto: 20% tài liệu nhận 80% lưu lượng truy cập.

Khi nào dùng: Có mẫu truy cập rõ ràng. Kho dữ liệu trung bình đến lớn (hơn 100K tài liệu). Hỗn hợp nội dung ổn định và thay đổi. Cần độ trễ tốt cho các truy vấn phổ biến.

Lợi ích: Nhanh cho 80% truy vấn (dùng cache đã embedding). Luôn mới cho tài liệu ít truy cập. Chỉ re-embed tầng nóng khi đổi mô hình (20% kho dữ liệu). Thích ứng với mẫu truy cập thay đổi. Cân bằng tốt nhất giữa độ trễ/chi phí/linh hoạt.

Chuyện đổi mô hình:

• Tiền embedding toàn phần: Re-embed 1M tài liệu × $0.01 = $10,000 + thời gian chết
• Phân tầng nóng/lạnh: Re-embed 200K tài liệu = $2,000 + thời gian chết tối thiểu
• Theo yêu cầu: Đổi một dòng code = $0 + zero downtime

Công thức 6: Tiền Embedding Toàn Phần (The Scale Play)

Nó là gì? Embed mọi thứ trước, lưu trong vector database, tìm kiếm bằng ANN (approximate nearest neighbors).

Khi nào dùng: Lưu lượng truy vấn rất cao (hơn 10K/ngày). Cần độ trễ dưới 50ms. Kho dữ liệu rất ổn định (dưới 5% thay đổi/tháng). Mẫu truy cập rộng. Có đội ngũ ML quản lý hạ tầng.

Phân tích chi phí (1M tài liệu):

• Embedding một lần: 1M × 500 tokens × $0.00002 = $10
• Lưu trữ: 1M × 1536 dims × 4 bytes = 6GB (~$10-30/tháng)
• Độ trễ tìm kiếm: dưới 50ms
• Độ mới: Chỉ mới bằng lần re-index cuối cùng

Khi nào KHÔNG nên dùng: Tài liệu thay đổi thường xuyên (hơn 10%/tuần). Đang thử nghiệm mô hình embedding. Lưu lượng truy vấn thấp (dưới 1K/ngày). Chưa thử các cách tiếp cận đơn giản hơn.

Ác mộng model deprecation: Đây là nơi tiền embedding toàn phần đau nhất. Khi cần đổi mô hình: thời gian chết, chi phí tính toán, kiểm thử toàn diện, đánh giá lại chunking, và rủi ro chất lượng.

Đây là giải pháp thừa thãi cho hầu hết hệ thống. Tác giả đã thấy các đội ngũ dành hàng tháng trời tối ưu hóa vector database trong khi viết lại truy vấn giải quyết được 90% vấn đề.

Vấn đề truy vấn đa ý định (Multi-Intent Query Problem)

Đây là nơi mọi thứ trở nên thú vị. Người dùng thực tế hỏi: "Làm thế nào để đọc file CSV, làm sạch dữ liệu thiếu, và vẽ biểu đồ kết quả?" – đó là ba ý định riêng biệt.

Cách xử lý kiểu Perplexity: Các hệ thống agentic RAG hiện đại xử lý điều này một cách thanh lịch:

1. Agent hiểu truy vấn: Phân rã "đọc CSV, làm sạch dữ liệu, vẽ biểu đồ" thành ba sub-queries riêng biệt
2. Xử lý song song thích ứng: Mỗi sub-query được định tuyến đến phương pháp tối ưu – sub-query đơn giản chỉ cần BM25 (miễn phí, 15ms), sub-query phức tạp cần LLM rewrite và multi-search ($0.001, 250ms)
3. Tổng hợp: Kết hợp kết quả thành câu trả lời mạch lạc

So sánh chi phí:

• Không phân rã: LLM viết lại toàn bộ $0.005 + embedding 50 tài liệu $0.025 = $0.03
• Có phân rã: $0.001 cho việc phân rã + $0 cho sub-queries đơn giản + $0.001 cho sub-query phức tạp = $0.002

Rẻ hơn 15 lần, chất lượng tốt hơn. Agent thông minh có thể quyết định sub-query nào cần xử lý đắt tiền (embeddings) và sub-query nào có thể xử lý rẻ (tiền xử lý đơn giản + BM25).

Cây quyết định: Khi nào dùng gì

Bắt đầu từ đây:

• Bạn có tìm kiếm chưa? Nếu chưa, hãy xây BM25 trước. Nghiêm túc. Dừng đọc và xây dựng.
• Đo lường baseline. Chạy tìm kiếm hiện tại 2-4 tuần, thu thập phản hồi người dùng. Người dùng hài lòng không? Nếu có, dừng lại. Đi ship features.

Phàn nàn chính là gì?

• "Không tìm thấy tài liệu rõ ràng tồn tại" → Thử viết lại truy vấn trước. Chạy A/B test 2 tuần.
• "Kết quả ổn nhưng chưa tuyệt" → A/B test hybrid search. Cân nhắc độ trễ. Dữ liệu thay đổi thường xuyên? Dùng on-the-fly. Có hot docs rõ ràng? Dùng hot/cold tiers. Kho dữ liệu ổn định và quy mô lớn? Dùng full pre-embedding.
• "Cần hiểu ngữ nghĩa tốt hơn" → Dùng hybrid search, chọn theo tình huống: thay đổi >10%/ngày → on-the-fly; quy mô trung bình có mẫu rõ → hot/cold; quy mô lớn dữ liệu ổn định → full pre-embedding.

Quy tắc 80/20: 60% hệ thống nên dừng ở full-text + viết lại truy vấn. 25% cần hybrid với on-the-fly hoặc hot/cold. 10% cần full pre-embedding. 5% cần giải pháp tùy chỉnh.

Bottomline: Đừng là người xây giải pháp 5% cho một vấn đề 60%. Hãy bắt đầu từ đơn giản, đo lường và chỉ thêm phức tạp khi có dữ liệu chứng minh cần thiết. Tìm kiếm full-text với viết lại truy vấn cho độ mới dữ liệu hoàn hảo, độ phức tạp thấp, độ trễ dưới 50ms – và nó hoạt động cho hầu hết mọi trường hợp sử dụng.

Nguyên tắc 80/20 trong thiết kế hệ thống RAG