Tổng quan: Embedding, tìm kiếm & RAG

TL;DR: Module này trả lời một câu hỏi rất cụ thể: làm sao để AI trả lời dựa trên tài liệu của bạn, thay vì chỉ dựa trên thứ nó đã học sẵn. Đường đi qua bốn cơ chế nối tiếp nhau — embedding biến văn bản thành vector nghĩa, cosine similarity đo "gần" bằng góc giữa hai vector, chunking cắt tài liệu dài thành đoạn vừa đủ trước khi tìm, và RAG ghép việc tìm (retrieve) với việc sinh câu trả lời (generate). Nhưng "gần nghĩa" không phải lúc nào cũng là thứ cần — có loại truy vấn nó thua trắng, và có đúng đoạn tài liệu vẫn không đảm bảo model dùng đúng nó. Module kết bằng một quyết định kiến trúc thật, không phải bài tập lý thuyết.

Vì sao module này tồn tại

Sếp bạn thấy demo chatbot LLM trả lời trôi chảy, rồi hỏi một câu tưởng đơn giản: "cho nó trả lời dựa trên tài liệu công ty mình được không?" Câu hỏi đó vỡ thành ba câu hỏi nhỏ hơn ngay lập tức. Làm sao để hệ thống "hiểu" một đoạn tài liệu đủ để so nó với câu hỏi của người dùng — hai câu có thể diễn đạt hoàn toàn khác nhau mà cùng một ý? Với hàng nghìn trang tài liệu, làm sao tìm đúng vài đoạn liên quan nhất, thay vì nhét cả kho vào mỗi câu hỏi? Và tìm được đoạn rồi, làm sao ghép nó với model sinh văn bản để ra một câu trả lời mạch lạc, có nguồn, chứ không phải model tự bịa?

Ba câu hỏi đó chính là ba tầng của module: embedding trả lời câu đầu, chunking + tìm kiếm trả lời câu hai, RAG trả lời câu ba. Nhưng module không dừng ở "dựng được RAG là xong". Thực tế phổ biến hơn nhiều: RAG chọn nhầm đoạn, hoặc chọn đúng đoạn mà vẫn sinh sai — và có những bài toán nghe y hệt "chatbot hỏi đáp trên tài liệu" mà đáp án đúng lại là không cần RAG chút nào. Học xong module này là học được cả lúc dùng lẫn lúc không nên dùng — thứ một kỹ sư ra quyết định kiến trúc cần hơn nhiều so với việc biết mỗi cách dựng.

Sau module này bạn sẽ

• Explain embedding ánh xạ văn bản thành vector trong không gian nghĩa, và vì sao chất lượng phụ thuộc task chứ không phụ thuộc kích thước
• Predict các truy vấn mà semantic search thua keyword search và khi nào cần hybrid
• Trace pipeline RAG từ query tới câu trả lời qua embed, retrieve, context, generate
• Diagnose một hệ RAG hỏng ở retrieval hay generation theo taxonomy bốn failure mode
• Justify lựa chọn prompt-only, RAG hay fine-tune cho một use case cụ thể, kèm rủi ro và chi phí

Lộ trình module

Tám bài đi theo một chuỗi phụ thuộc chặt — mỗi bài dùng lại khái niệm của bài ngay trước, nên thứ tự không phải ngẫu nhiên. Bài 01 dựng nền: embedding là gì, và vì sao "model nào tốt nhất" là câu hỏi đặt sai. Bài 02 định nghĩa chính xác chữ "gần" mà bài 01 dùng — cosine similarity, cùng lý do điểm cao không đồng nghĩa đúng ý người dùng. Bài 03 lật ngược thế mạnh đó: có loại truy vấn — mã lỗi, tên endpoint, số phiên bản — mà "gần nghĩa" thua trắng trước khớp từ khoá, và hybrid ăn được cả hai. Bài 04 giải quyết một giới hạn khác của embedding: tài liệu dài phải cắt thành chunk trước khi tìm, cắt sai theo cả hai hướng đều hỏng.

Bốn bài đầu là nguyên liệu; bài 05 lắp chúng thành một pipeline hoàn chỉnh — RAG — và trace đủ năm bước từ câu hỏi tới câu trả lời. Bài 06 đối diện thực tế: pipeline chạy đúng không đảm bảo kết quả đúng, và bốn failure mode có tên gọi chuẩn cho bạn khung chẩn đoán thay vì đoán mò. Bài 07 là capstone: ba bài toán nghe giống hệt nhau, bạn tự chọn kiến trúc — có ca đáp án đúng là bỏ RAG hẳn. Bài 08 gom lại thành cheat sheet và tự đánh giá theo đúng năm outcome ở trên.

Yêu cầu trước khi bắt đầu

• Module Cỗ máy LLM — đặc biệt bài Tokenization (dùng lại ở bài 01, 03, 07) và bài Context window (dùng lại ở bài 04).
• Không cần công cụ hay môi trường cài đặt gì thêm — cả module chỉ dùng pseudocode để minh hoạ cơ chế, không có bài lab code chạy được.

Time budget

Tổng khoảng 1h40 — 1h20 đọc (bài 01–06, 08) + 20 phút lab (bài 07).

Cách học module này hiệu quả

• Đừng nhảy cóc: bài 03 dựa vào cơ chế đã dựng ở bài 01, bài 06 dựa vào pipeline trace ở bài 05 — đọc lệch thứ tự thì phần lớn "vì sao" trong bài sẽ trống.
• Gặp callout "Thử đoán" thì viết ra dự đoán trước khi đọc tiếp — các bài trong module dùng mẫu này thường xuyên, và phần giải thích ngay sau chỉ có tác dụng khi bạn đã tự đoán trước.
• Đến bài 06, tự phân loại bốn ticket trước khi đọc đáp án — khung ba bước "đáp án có trong kho không, có được retrieve không, rồi mới hỏi generation" chỉ nhớ được nếu bạn tự chạy qua nó một lần.
• Ở bài 07, thật sự viết câu trả lời ra cho cả ba ticket trước khi cuộn xuống lời giải — mini-challenge này chấm bằng lập luận, không có một đáp án đúng tuyệt đối.
• Nếu một khái niệm nghe quen tay (context window, subword tokenization), mở lại Recall gắn trong bài thay vì đoán — vài dòng ôn ngắn thường quyết định bạn hiểu đúng hay hiểu lệch phần còn lại của bài.