Khoá RAG của DeepLearning.AI do Zain Hasan giảng: FDE nên học gì, lướt qua phần nào

Khoá RAG của DeepLearning.AI kéo dài khoảng 26 giờ, chia làm năm module. Module được một học viên đã lấy chứng chỉ đánh giá cao nhất lại nằm ở cuối cùng: production.

Với một FDE, cách sắp xếp đó vừa có lợi vừa là cái bẫy. Lợi vì nền retrieval được xây chắc trước khi bàn chuyện vận hành. Bẫy vì nếu học tuần tự mà không biết mình cần gì, bạn dễ bỏ dở trước khi tới phần đáng tiền nhất.

Khoá mang tên “Retrieval Augmented Generation (RAG)”, có trên trang DeepLearning.AI (ghi cập nhật ngày 23/7/2026) và trên Coursera. Mỗi module đều có bài lập trình, lần lượt dựng từng thành phần cốt lõi của một hệ thống RAG.

Nối LLM với tài liệu riêng của khách hàng là việc FDE làm hằng ngày. Chọn đúng phần để học kỹ, bạn sẽ đủ vốn để bàn quyết định thiết kế với khách hàng ngay trong buổi làm việc.

Ai giảng, và thực hành sát thực tế đến đâu?

Zain Hasan là kỹ sư developer relations mảng AI/ML ở Together AI, đồng thời giảng dạy tại Đại học Toronto. Vì vậy khoá nghiêng về xây dựng hơn là lý thuyết.

Một lab tiêu biểu là chatbot cho một cửa hàng quần áo giả định: ban đầu chạy trên LLM độc quyền, sau chuyển sang mô hình mã nguồn mở của Together AI. Khi làm bài này, hãy để ý phần nào của pipeline phải sửa lúc đổi mô hình, vì đó là tình huống FDE gặp khi khách hàng thay đổi yêu cầu giữa chừng.

Bài lập trình cuối, “Improving the ChatBot”, đụng tới những chuyện của production như giá thay đổi liên tục và ghi log tương tác để giám sát. Đây chính là loại vấn đề khiến một bản demo chạy đẹp bắt đầu trả lời sai khi gặp dữ liệu thật.

Học kỹ phần nào, lướt phần nào?

Thứ tự hợp lý tuỳ vào nền search của bạn. Nếu từng làm search hoặc đã quen vector database, hãy đi nhanh qua các module về retrieval và chỉ dừng lại ở bài tập.

Nếu chưa, đừng bỏ qua. Mô hình chỉ viết được từ những gì retrieval đưa vào, nên phần tìm kiếm yếu thì phần sinh phía sau rất khó cứu. Module 3 về vector database là phần mà học viên nói trên cho biết mình học được nhiều.

Module 4 về sinh văn bản đáng ghé lại kể cả khi bạn đã quen LLM. Theo cùng học viên, module này đi vào chi tiết các chiến lược sampling của LLM trong RAG, thứ mà người này cho rằng không nhiều người nắm.

Module 5 dành trọn cho production: giám sát, đánh giá, độ trễ, bảo mật và đánh đổi giữa chi phí với chất lượng. Đó gần như đúng danh sách câu hỏi khách hàng sẽ đặt cho bạn, nên dù thuộc nhóm nào, hãy đọc đề cương module này thật sớm.

Hybrid retrieval không phải món trang trí

Một lab của khoá so sánh ba cách truy xuất: semantic search, BM25 và Reciprocal Rank Fusion, tức trộn thứ hạng từ nhiều cách tìm. Bài này đáng làm cẩn thận vì nó trả lời câu hỏi rất thực tế: khi nào một cách tìm là không đủ.

Thử hình dung một khách hàng sản xuất có tài liệu bảo trì đầy mã linh kiện kiểu “SKU-4471”. Embedding giỏi bắt nghĩa nhưng dễ trượt với chuỗi ký tự chính xác như thế, còn BM25 thì ngược lại.

Vì thế, việc đầu tiên nên làm ở khách hàng là gom câu hỏi thật của người dùng và đếm xem bao nhiêu câu chứa mã, tên riêng hay số hiệu. Tỷ lệ đó cao thì kết hợp hai cách tìm nên là mặc định, chứ không phải tối ưu để dành về sau.

Chi phí bắt đầu từ chất lượng retrieval

Đánh đổi chi phí với chất lượng trong module 5 dễ hiểu hơn khi tính nhẩm. Giả sử mỗi câu hỏi lấy 20 đoạn, mỗi đoạn 500 token, thì context đã là 10.000 token; giảm còn 5 đoạn thì chỉ còn 2.500 token, rẻ hơn và nhanh hơn.

Điều kiện là 5 đoạn đó phải đúng là những đoạn tốt nhất. Retrieval càng chính xác, bạn càng gửi ít token mà không mất chất lượng.

Ở khách hàng, hãy đưa hai con số lên bàn ngay từ buổi thiết kế: mỗi câu hỏi tốn bao nhiêu token, và phải trả lời trong bao nhiêu giây. Khi cả hai đã rõ, cuộc bàn bạc sẽ cụ thể hơn nhiều so với tranh luận chọn mô hình nào.

Biết hệ thống hỏng ở khâu nào

Học viên đã hoàn thành chứng chỉ coi module 5 là phần giá trị nhất, chủ yếu vì nó dạy một bộ công cụ observability cụ thể. Đây là kỹ năng tách FDE khỏi người chỉ làm demo.

Nếu log cho thấy đoạn tài liệu đúng không hề được lấy về, sửa prompt là vô ích, bạn phải sửa retrieval. Nếu đoạn đúng đã nằm trong context mà câu trả lời vẫn sai, lúc đó mới đến lượt prompt, cách sampling hoặc mô hình.

Chứng chỉ chưa phải bằng chứng

Học viên kể trên cũng chỉ ra điểm yếu: notebook chấm điểm khá cứng nhắc và quiz trắc nghiệm không khó. Vì thế, đừng coi việc qua bài là dấu hiệu bạn đã nắm vững.

Bằng chứng mạnh hơn là một dự án nhỏ: RAG trên một bộ tài liệu công khai, có so sánh semantic search với cách kết hợp BM25, có log từng truy vấn, và một bảng ghi độ trễ, chi phí token cùng tỷ lệ trả lời đúng.

Khi đọc JD của một vị trí FDE, hãy dò xem có nhắc tới hybrid search, vector database hay observability không. Nếu có, dự án đó là thứ để đưa vào CV và mang ra kể trong phỏng vấn.

Người học xong năm module sẽ biết RAG là gì. Người học kỹ module cuối và tự đo hệ thống của mình sẽ biết phải sửa ở đâu khi khách hàng gọi điện báo câu trả lời sai.