Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn thuê một chuyên gia tư vấn cực kỳ thông minh, đọc gần hết tri thức của nhân loại tính đến một thời điểm nào đó — rồi nhốt họ trong một căn phòng kín không có Internet, không có tài liệu công ty, không có bất kỳ file khách hàng nào. Bạn hỏi gì họ cũng trả lời rất trôi chảy, nhưng khi bạn hỏi "Quý trước công ty mình bán được bao nhiêu?" hoặc "Chính sách đổi trả hàng của bên mình quy định thế nào?" thì họ… bịa. Đó chính xác là chân dung của một LLM (Large Language Model — mô hình ngôn ngữ lớn) khi đứng một mình.
Trong các bài trước, bạn đã học cách "hỏi cho khéo": zero-shot, few-shot, Chain-of-Thought, structured output. Tất cả đều xoay quanh việc tối ưu câu hỏi. Nhưng có một loại vấn đề mà dù bạn viết prompt hay đến mấy cũng không giải quyết được: khi kiến thức cần thiết không nằm trong đầu mô hình. Model không biết doanh thu tháng trước của bạn, không biết tin tức tuần này, không biết nội dung 3.000 trang tài liệu nội bộ của phòng ban.
RAG — Retrieval Augmented Generation (tạm dịch: "sinh nội dung có tăng cường truy xuất") — là lời giải cho đúng nhóm bài toán này. Đây là bước ngoặt biến LLM từ "một cái miệng biết nói" thành "một trợ lý biết tra cứu tài liệu của chính bạn rồi mới trả lời". Với người làm business, RAG là chiếc chìa khóa để xây chatbot chăm sóc khách hàng dựa trên tài liệu công ty, trợ lý tra cứu quy trình nội bộ, hệ thống hỏi-đáp trên hợp đồng — những thứ tạo ra giá trị thật sự chứ không chỉ để "chơi cho vui". Hiểu RAG ở mức khái niệm là điều bắt buộc trước khi bạn bước sang các bài về tool use, agent hay triển khai thực tế.
Khái niệm cốt lõi
Vấn đề gốc: knowledge của LLM bị đóng băng tại "training cutoff"
Mọi LLM đều được huấn luyện trên một khối dữ liệu tại một thời điểm nhất định, gọi là training cutoff (thời điểm cắt dữ liệu huấn luyện). Sau mốc đó, model không tự cập nhật thêm gì. Điều này dẫn tới ba khoảng trống kiến thức mà không prompt nào lấp được:
- Dữ liệu nội bộ công ty: tài liệu, quy trình, giá nội bộ, lịch sử đơn hàng — model chưa bao giờ được "đọc" chúng.
- Thông tin mới: tin tức tuần trước, quy định vừa ban hành, sản phẩm vừa ra mắt.
- Dữ liệu riêng của từng khách hàng: hồ sơ, lịch sử giao dịch, ngữ cảnh cụ thể của một người dùng cụ thể.
RAG là gì — giải thích bằng hình ảnh "mở sách trước khi trả lời"
Ý tưởng của RAG cực kỳ trực giác. Thay vì bắt model trả lời "từ trí nhớ", ta làm một bước trung gian: trước khi model trả lời, hệ thống đi tìm những đoạn tài liệu liên quan nhất tới câu hỏi, rồi nhét chúng vào prompt như phần "tài liệu tham khảo". Model đọc tài liệu đó ngay tại chỗ và trả lời dựa trên nó.
Nói cách khác, RAG biến bài thi từ "đóng sách" (closed-book) thành "mở sách" (open-book). Model vẫn dùng khả năng ngôn ngữ và suy luận của mình, nhưng phần dữ kiện thì lấy từ nguồn bạn cung cấp, không phải từ trí nhớ dễ sai của nó.
Cụm từ trong tên gọi phản ánh đúng ba việc:
- Retrieval (truy xuất): tìm đúng mẩu tài liệu liên quan.
- Augmented (tăng cường): bổ sung các mẩu đó vào prompt.
- Generation (sinh nội dung): model đọc rồi tạo câu trả lời.
Cơ chế hoạt động: embedding và vector search
Làm sao máy tính "tìm tài liệu liên quan" khi câu hỏi và tài liệu dùng từ ngữ khác nhau? Ví dụ khách hỏi "trả hàng có mất phí không?" trong khi tài liệu ghi "chính sách hoàn trả sản phẩm" — không trùng một từ nào. Đây là lúc embedding vào cuộc.
Embedding là kỹ thuật biến một đoạn văn bản thành một dãy số (vector) đại diện cho ý nghĩa của nó. Hai đoạn văn có ý nghĩa gần nhau sẽ có vector gần nhau trong không gian toán học, kể cả khi dùng từ khác nhau. Quy trình RAG cơ bản gồm hai giai đoạn:
Giai đoạn chuẩn bị (làm một lần, offline):
- Cắt nhỏ toàn bộ tài liệu thành các đoạn (chunking), ví dụ mỗi đoạn 300–500 từ.
- Chuyển từng đoạn thành vector bằng model embedding.
- Lưu các vector vào một vector database (cơ sở dữ liệu vector) như Pinecone, Weaviate, Qdrant, hoặc pgvector.
- Chuyển câu hỏi của người dùng thành vector.
- Tìm trong vector database những đoạn có vector gần nhất (semantic search — tìm theo ngữ nghĩa).
- Lấy top 3–5 đoạn liên quan nhất, ghép vào prompt cùng câu hỏi.
- Gửi prompt "đã tăng cường" đó cho LLM để sinh câu trả lời.
RAG khác gì với fine-tune và với việc nhét cả file vào prompt?
Ba hướng dễ bị nhầm:
- Nhét toàn bộ tài liệu vào prompt: chỉ khả thi khi tài liệu nhỏ. Với 3.000 trang thì không context window nào chứa nổi, và chi phí token sẽ khổng lồ (bạn sẽ học kỹ ở bài về context window và cost optimization).
- Fine-tune (huấn luyện lại model trên dữ liệu của bạn): tốn kém, chậm, và khó cập nhật — mỗi lần tài liệu thay đổi lại phải train lại. Fine-tune hợp để dạy model phong cách/hành vi, không hợp để nhồi dữ kiện hay thay đổi. (Bài 35 sẽ so sánh sâu few-shot vs fine-tune.)
- RAG: cập nhật tức thì (chỉ cần thêm/sửa tài liệu trong vector DB), truy vết được nguồn, chi phí hợp lý. Đây là lựa chọn mặc định khi bài toán là "trả lời dựa trên một kho kiến thức thay đổi theo thời gian".
Tình huống thực tế
Ví dụ 1 — Chatbot chăm sóc khách hàng của một sàn TMĐT Việt Nam
Một công ty thương mại điện tử tại TP.HCM (giả định tên "ShopViet") có đội chăm sóc khách hàng 25 người, mỗi ngày trả lời khoảng 4.000 tin nhắn, trong đó ~60% là câu lặp đi lặp lại: phí ship, thời gian giao, chính sách đổi trả, cách theo dõi đơn. Họ thử dùng ChatGPT thẳng để tự động trả lời, nhưng model bịa ra "chính sách hoàn tiền trong 30 ngày" trong khi ShopViet chỉ cho 7 ngày — gây khiếu nại thật.
Đội kỹ thuật chuyển sang RAG: họ đưa toàn bộ trang chính sách, FAQ, và bảng phí vận chuyển (khoảng 120 trang) vào vector database. Giờ khi khách hỏi "đổi hàng ở Đà Nẵng mất bao lâu", hệ thống truy xuất đúng đoạn chính sách vùng miền + bảng thời gian giao, rồi model trả lời dựa trên đó. Kết quả sau 2 tháng: ~55% tin nhắn được bot xử lý trọn vẹn, thời gian phản hồi trung bình giảm từ 6 phút xuống dưới 20 giây, và quan trọng nhất là tỷ lệ trả lời sai về chính sách gần như bằng 0 vì mọi câu trả lời đều dựa trên tài liệu thật.
Bài học: RAG không chỉ giúp tự động hóa, mà còn khóa câu trả lời vào nguồn đáng tin cậy — điều sống còn khi thông tin sai có thể gây thiệt hại tài chính.
Ví dụ 2 — Trợ lý tra cứu quy trình nội bộ cho một ngân hàng
Một ngân hàng cỡ vừa có hơn 2.000 trang quy trình nghiệp vụ (mở thẻ, xử lý khiếu nại, quy định KYC…) nằm rải rác trong hàng chục file Word và PDF. Nhân viên mới mất trung bình 3 tuần để "quen việc", và bộ phận hỗ trợ nội bộ nhận khoảng 300 câu hỏi quy trình mỗi tuần.
Họ xây một trợ lý nội bộ dựa trên RAG: index toàn bộ tài liệu quy trình vào vector DB, mỗi câu trả lời của trợ lý đều kèm trích dẫn số trang và tên tài liệu gốc để nhân viên tự kiểm chứng. Một điểm hay: khi quy trình KYC được cập nhật, họ chỉ cần thay file mới trong hệ thống — không cần train lại gì cả, trợ lý lập tức trả lời theo phiên bản mới. Số câu hỏi gửi lên bộ phận hỗ trợ giảm khoảng 40% trong quý đầu.
Bài học: Với dữ liệu thay đổi thường xuyên và yêu cầu truy vết nguồn cao (ngành tài chính, pháp lý), RAG vượt trội hơn hẳn fine-tune nhờ khả năng cập nhật tức thì và trích dẫn.
Ví dụ 3 — Solo founder xây trợ lý hỏi-đáp trên tài liệu sản phẩm
Một nhà sáng lập độc lập làm phần mềm SaaS B2B nhận quá nhiều email hỏi cách dùng sản phẩm. Anh không có ngân sách thuê đội support, cũng không đủ kiến thức để fine-tune. Anh dùng một công cụ RAG có sẵn: tải toàn bộ tài liệu hướng dẫn (khoảng 80 trang) lên, gắn widget chat vào website. Chi phí hạ tầng chỉ vài chục USD/tháng.
Kết quả: khoảng 70% câu hỏi kỹ thuật được widget giải đáp tự động, và vì câu trả lời trích từ chính tài liệu của anh nên độ chính xác cao. Anh tiết kiệm ước tính 10–12 giờ mỗi tuần.
Bài học: RAG không phải đặc quyền của công ty lớn. Với công cụ sẵn có, một cá nhân cũng triển khai được một hệ thống hỏi-đáp trên tài liệu riêng chỉ trong vài giờ.
Hướng dẫn từng bước
Đây là lộ trình khái niệm để bạn hình dung cách dựng một hệ thống RAG đơn giản — chưa đi vào code, mà tập trung vào tư duy và các quyết định quan trọng.
- Xác định kho tri thức (knowledge base). Gom đúng những tài liệu chứa câu trả lời: FAQ, chính sách, quy trình, tài liệu sản phẩm. Nguyên tắc "rác vào, rác ra" — tài liệu lỗi thời hoặc mâu thuẫn sẽ khiến câu trả lời sai.
- Làm sạch và chuẩn hóa. Bỏ header/footer thừa, chuyển bảng phức tạp về dạng dễ đọc, gộp các file trùng lặp. Bước tẻ nhạt này quyết định 50% chất lượng cuối.
- Chunking — cắt tài liệu thành đoạn. Cắt quá lớn thì mỗi đoạn lẫn nhiều thông tin nhiễu; cắt quá nhỏ thì mất ngữ cảnh. Điểm khởi đầu hợp lý là 300–500 từ mỗi đoạn, có phần "chồng lấn" (overlap) nhẹ giữa các đoạn để không cắt đứt ý.
- Tạo embedding và lưu vào vector database. Chọn một model embedding, chuyển từng đoạn thành vector, nạp vào vector DB (pgvector, Qdrant, Pinecone…). Đây là bước "index" làm một lần và cập nhật khi tài liệu đổi.
- Xây bước retrieval. Khi có câu hỏi, chuyển nó thành vector, tìm top 3–5 đoạn gần nhất. Cân nhắc thêm ngưỡng độ liên quan: nếu không đoạn nào đủ gần, hệ thống nên trả lời "tôi không tìm thấy thông tin này" thay vì cố bịa.
- Thiết kế prompt tăng cường. Đây là phần "prompt engineering" cốt lõi của RAG. Một mẫu prompt tốt thường có dạng:
Chỉ dẫn "chỉ dựa trên tài liệu" và "được phép nói không biết" là hai câu chống hallucination hiệu quả nhất.
- Sinh câu trả lời và trích dẫn nguồn. Yêu cầu model kèm nguồn (tên tài liệu, số trang) để người dùng kiểm chứng — đặc biệt quan trọng trong tài chính, pháp lý, y tế.
- Đánh giá và lặp lại. Chuẩn bị một bộ 20–50 câu hỏi thật kèm đáp án đúng, kiểm tra định kỳ. Nếu sai, xác định lỗi ở đâu: retrieval lấy sai đoạn, hay model đọc đúng đoạn nhưng trả lời sai? Hai lỗi này cần cách sửa khác nhau.
Lỗi thường gặp & mẹo
- Nghĩ RAG là "phép màu tự động đúng". RAG chỉ tốt bằng tài liệu bạn đưa vào và bằng chất lượng bước retrieval. Nếu tìm sai đoạn thì model dù giỏi mấy cũng trả lời sai.
- Chunking cẩu thả. Cắt đoạn tùy tiện làm đứt ý giữa chừng là nguyên nhân số một khiến retrieval kém. Hãy thử vài cỡ chunk và đo kết quả thực tế, đừng đoán.
- Quên chống hallucination trong prompt. Nếu không nói rõ "chỉ dựa trên tài liệu, không biết thì nói không biết", model vẫn có thể trộn kiến thức nền của nó vào và bịa. Luôn ràng buộc phạm vi.
- Bỏ qua trường hợp "không tìm thấy". Một hệ thống production tốt phải biết trả lời "tôi không có thông tin" một cách lịch sự, thay vì cố nặn ra câu trả lời từ những đoạn không liên quan.
- Nhầm RAG với fine-tune. Nhớ nguyên tắc: dữ kiện hay thay đổi → RAG; phong cách/hành vi cố định → fine-tune. Chọn sai công cụ sẽ tốn tiền vô ích.
- Đưa quá nhiều đoạn vào prompt. Nhồi 20 đoạn vào không những tốn token mà còn làm loãng, khiến model khó tập trung. Thường 3–5 đoạn chất lượng là đủ.
- Mẹo — luôn hiển thị nguồn. Việc trích dẫn tài liệu gốc vừa tăng độ tin cậy với người dùng, vừa giúp bạn debug: khi câu trả lời sai, nhìn nguồn là biết ngay lỗi nằm ở retrieval hay ở generation.
Bài tập thực hành
- Nhận diện bài toán. Liệt kê 3 tình huống trong công việc hiện tại của bạn mà LLM đứng một mình sẽ trả lời sai vì thiếu dữ liệu (nội bộ / mới / riêng của khách hàng). Với mỗi tình huống, ghi rõ nguồn tài liệu nào cần đưa vào RAG.
- Phác thảo kho tri thức. Chọn một trong ba tình huống trên. Liệt kê cụ thể các tài liệu cần index và ước lượng tổng số trang. Ghi chú tài liệu nào hay thay đổi (để hiểu vì sao RAG hợp hơn fine-tune ở đây).
- Viết prompt tăng cường. Soạn một mẫu prompt RAG hoàn chỉnh cho tình huống đó, bao gồm: vai trò trợ lý, chỉ dẫn "chỉ dựa trên tài liệu", cho phép nói "không biết", chỗ chèn tài liệu tham khảo, và yêu cầu trích dẫn nguồn.
- Thử nghiệm mini không cần code. Copy 2–3 trang tài liệu thật vào một prompt trong ChatGPT/Claude, thêm chỉ dẫn "chỉ trả lời dựa trên tài liệu trên", rồi đặt vài câu hỏi — kể cả một câu mà tài liệu KHÔNG có đáp án. Quan sát: model có thành thật nói "không biết" không? Đây chính là phần "generation" của RAG được mô phỏng thủ công.
- Thiết kế bộ đánh giá. Viết 10 câu hỏi thật kèm đáp án đúng cho kho tri thức của bạn. Đây sẽ là "thước đo" để sau này kiểm tra hệ thống RAG có hoạt động tốt không.
Tóm tắt
- LLM có kiến thức bị "đóng băng" tại training cutoff nên không biết dữ liệu nội bộ, thông tin mới, hay dữ liệu riêng của từng khách hàng — và có xu hướng bịa khi gặp khoảng trống đó.
- RAG (Retrieval Augmented Generation) giải quyết bằng cách truy xuất tài liệu liên quan rồi nhét vào prompt trước khi model trả lời — biến bài thi từ "đóng sách" thành "mở sách".
- Cơ chế dựa trên embedding và vector search: biến văn bản thành vector ngữ nghĩa, tìm đoạn gần nhất với câu hỏi, đưa top 3–5 đoạn vào prompt.
- So với nhét cả file (không đủ context, tốn kém) hay fine-tune (chậm, khó cập nhật), RAG là lựa chọn mặc định cho bài toán "trả lời dựa trên kho kiến thức hay thay đổi".
- Chất lượng RAG quyết định bởi tài liệu sạch, chunking hợp lý, retrieval chính xác, và một prompt tăng cường ràng buộc "chỉ dựa trên tài liệu, không biết thì nói không biết".
- RAG mở ra vô số ứng dụng business: chatbot CSKH, trợ lý quy trình nội bộ, hỏi-đáp trên tài liệu sản phẩm — và không hề là đặc quyền của riêng công ty lớn.