RAG — Tìm trước, generate sau, model biết cả điều chưa được train

Khi bạn hỏi ChatGPT về "giá Bitcoin hôm nay" hay "chính sách nghỉ phép mới của công ty", model thường từ chối hoặc... bịa ra dữ liệu. Không phải vì nó "ngu", mà vì não của nó (weights) đã đóng băng từ thời điểm training, và Internet thì thay đổi mỗi giây. RAG (Retrieval-Augmented Generation) là giải pháp: thay vì ép model nhớ mọi thứ, ta cho nó mở sách tra cứu ngay lúc suy nghĩ. Đây là kiến trúc đằng sau Perplexity AI, Bing Chat, và hầu hết hệ thống Enterprise AI hiện nay — nơi model không chỉ "tưởng tượng" mà còn "tra cứu" trước khi trả lời.

Vấn đề

Tri thức tĩnh và ảo giác. LLM là bộ nén lossy (mất mát) của toàn bộ Internet, nhưng nó bị đóng băng vào thời điểm cutoff — GPT-4 không biết sự kiện sau tháng 4/2024, và chẳng bao giờ biết nội quy công ty bạn. Khi gặp khoảng trống kiến thức, LLM không nói "tôi không biết"; nó sinh ra văn bản nghe có vẻ đúng nhưng sai sự thật (hallucination).

Chi phí cập nhật. Để bổ sung kiến thức mới, fine-tuning hoặc pre-training lại một model 70B+ parameters tốn hàng triệu đô và vài tuần thời gian. Không thực tế cho dữ liệu thay đổi hàng ngày (giá cổ phiếu, ticket support, luật mới).

Bài toán trước năm 2020. Các hệ thống cũ ép bạn chọn: hoặc là trích xuất thông tin rígido từ database (không linh hoạt), hoặc là generation tự do (không đáng tin). Không có cách nào kết hợp sự chính xác của database với khả năng diễn đạt tự nhiên của LLM.

Ý tưởng cốt lõi

The "Open Book Exam" Principle. Hãy tưởng tượng đang làm bài kiểm tra mở sách (open book). Bạn không cần nhớ tất cả công thức vật lý; bạn chỉ cần biết tra đúng chương, hiểu nội dung, và viết lại bằng ngôn ngữ của mình. RAG tách biệt hai chức năng: vector database làm "sách giáo khoa" (lưu trữ chính xác), LLM làm "sinh viên" (lý giải và diễn đạt).

Pipeline hai giai đoạn:

1. Retrieval: Khi user hỏi "Tại sao server X báo lỗi 503 hôm nay?", hệ thống dense retrieval sẽ embed query thành vector, tìm trong triệu tài liệu log bằng cosine similarity, trả về top-5 đoạn liên quan nhất (các đoạn log gần đây có từ khóa "503", "overload", "restart").

2. Generation: LLM nhận prompt dạng: "Dựa vào các đoạn log sau: [chunk 1], [chunk 2]... trả lời câu hỏi." Model chỉ việc đọc những đoạn này (giờ đã nằm trong context window) và tổng hợp câu trả lời tự nhiên, có thể kèm citation.

Đây là điểm "Aha". Bạn không cần model "biết" sẵn điều gì; bạn chỉ cần nó "đọc hiểu" nhanh. LLM là bộ lý giải xuất sắc nhưng là database tồi tệ — vậy thì đừng dùng nó làm database. Hãy để FAISS/Pinecone làm việc lưu trữ, LLM chỉ làm việc suy luận.

Why not just longer context? Nhiều người nghĩ: "Model giờ support 1M tokens, sao không dump cả database vào prompt?" Đây là lỗi cơ bản — attention không phải là lookup. Attention tính similarity với tất cả token trong O(n²), rất chậm và tốn VRAM. Hơn nữa, hiện tượng "lost in the middle" khiến model bỏ qua thông tin ở giữa dãy token dài. RAG dùng Approximate Nearest Neighbor search (O(log n)) để chọn lọc trước khi đưa vào context, vừa nhanh vừa chính xác.

Tại sao nó hoạt động

Tách biệt nén và chính xác. Trong quá trình training, LLM nén terabyte text thành gigabyte weights — đây là nén lossy, rất tốt cho "procedural knowledge" (ngữ pháp, logic suy luận) nhưng tệ cho "declarative knowledge" (số điện thoại cụ thể, giá Bitcoin hôm nay). RAG offload phần declarative sang vector database (lưu trữ exact), giữ lại khả năng reasoning của LLM.

Cập nhật tức thì. Thêm tài liệu mới vào vector DB là thao tác O(1) — chỉ cần embed và insert. Không cần retrain model. Điều này cho phép RAG hệ thống luôn "sống" với dữ liệu real-time.

Semantic search vs Keyword search. Khác với Elasticsearch (tìm từ khóa chính xác), dense retrieval dùng bi-encoder để map query và document vào cùng embedding space. "Máy bị treo" và "server unresponsive" sẽ có vector gần nhau dù khác từ vựng, nhờ đó tìm được tài liệu liên quan ngay cả khi user dùng ngôn ngữ khác với tài liệu gốc.

Reranking để lấy precision. Sau khi retrieval lấy top-100 candidates nhanh bằng vector similarity, cross-encoder reranking chạy qua từng cặp (query, doc) bằng full attention để chọn ra top-5 chính xác nhất. Đây là chiến lược "recall rẻ trước, precision đắt sau".

Ý nghĩa thực tế

So sánh với các approach khác:

Impact thực tế:

• Perplexity AI và Bing Chat hoạt động trên RAG core — mỗi câu trả lời đều kèm link nguồn vì họ tra cứu trước khi generate.
• Enterprise RAG: Các công ty dùng RAG để cho phép nhân viên chat với tài liệu nội bộ (PDF, Notion, Slack) mà không lo leak dữ liệu ra model public hay phải fine-tune model khổng lồ.

Limitations — RAG không phải thuốc trị bách bệnh:

• Garbage in, garbage out: Nếu retrieval lấy nhầm đoạn tài liệu (ví dụ: lấy policy cũ thay vì policy mới), model sẽ confidently trả lời sai. Retrieval error compound với generation error.

• Context window budget: Mỗi đoạn retrieved text chiếm token. Nếu bạn retrieve 10 đoạn dài 300 tokens mỗi đoạn, bạn đã tiêu tốn 3000 tokens — cắt giảm chỗ cho câu trả lời và làm tăng chi phí.

• Latency overhead: Round-trip đến vector database (FAISS/Pinecone/Weaviate) thêm 100-500ms. Không phù hợp cho use case yêu cầu phản hồi < 50ms.

• Boundary confusion: Model đôi khi "pha trộn" kiến thức từ retrieved text với parametric memory (weights), dẫn đến source confusion — trích dẫn sai nguồn hoặc kết hợp thông tin thành sai lệch.

Đào sâu hơn

Paper gốc: Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (Lewis et al., NeurIPS 2020) — bài báo định nghĩa RAG và chứng minh SOTA trên Natural Questions và TriviaQA mà không cần architecture task-specific.

Cùng cụm (RAG & Retrieval):

• Dense Retrieval — Bi-encoder biến query và doc thành vector, tìm bằng cosine
• Cross-Encoder & Reranking — Recall rẻ trước, precision đắt sau
• Vector Databases — FAISS, HNSW, tìm nearest neighbor trong triệu vector

Đọc tiếp:

• Word Embeddings — Nền tảng hiểu cách dense retrieval hoạt động
• Multi-Agent — Khi RAG kết hợp với agentic AI để tự động retrieve nhiều lần và tổng hợp phức tạp