Ngày 8 · RAG Pipeline — Truy xuất và sinh câu trả lời

Ý chínhGiảng viên đặt câu hỏi xuyên suốt: bạn đã có vector store từ Ngày 7, nhưng agent vẫn trả lời sai — lỗi nằm ở đâu trong pipeline? Giới thiệu bốn đầu ra của ngày — tìm đúng, gộp đúng, đóng gói đúng, trả lời có căn cứ — và nhấn mạnh rằng ngày học không dạy lại embedding, chunking hay vector store, mà đi tiếp vào những gì còn thiếu để pipeline trả lời tin cậy được.

Kỹ năngHọc viên biết mình sẽ đạt được gì sau ngày học và vì sao "search rồi nhét vào prompt" chưa đủ.

Hình thứcVideo giảng viên, 3 phút, giọng dẫn dắt.

Ý chínhRAG không phải một hàm gọi một lần mà là ba khối phối hợp: indexing chạy offline để xây kho, retrieval chạy khi có câu hỏi để tìm chứng cứ, generation tổng hợp chứng cứ thành câu trả lời có trích dẫn. Hai nguyên nhân model bịa — kiến thức dừng ở thời điểm huấn luyện và bản chất xác suất "trôi chảy hơn chính xác" — đều được RAG xử lý bằng cách đưa chứng cứ vào context. Chất lượng của indexing quyết định trần của retrieval, và phần lớn lỗi khi RAG trả lời sai nằm ở khâu truy xuất, không phải ở model; vì vậy phản xạ "đổi model lớn hơn" thường là sai lầm. Pipeline cơ bản của Ngày 7 — dense search, ngưỡng điểm, top-k, nhét vào prompt — còn thiếu bốn thứ: hybrid search, re-ranking, đóng gói context, và đo lường; bốn thứ này là bốn module tiếp theo.

Kỹ năngHọc viên vẽ được ba pipeline, giải thích được vì sao lỗi thường ở retrieval, và nêu được bốn thứ pipeline cơ bản còn thiếu.

Hình thứcVideo 6 phút. Sơ đồ ba khối hiện dần; pipeline cơ bản của Ngày 7 hiện lên rồi bốn ô "còn thiếu" được đánh dấu, mỗi ô nối tới một module.

Ý chínhNgày 7 đã đặt RAG giữa in-context và fine-tuning; item này chỉ nhắc lại một câu và đi vào quyết định thực tế. Cần RAG khi dữ liệu nội bộ thay đổi liên tục, khi câu trả lời phải có nguồn kiểm chứng được, khi fine-tuning quá nặng hoặc dữ liệu quá nhạy cảm. Chưa cần RAG khi câu hỏi thuộc kiến thức chung, khi không có kho tài liệu riêng, khi tác vụ sáng tạo không cần trích dẫn — ví dụ kịch bản gọi điện dài 2 trang chỉ cần đặt thẳng vào prompt. Trường hợp thường bị bỏ qua: kho nhỏ và ổn định — như một wiki sản phẩm chừng 1.800 dòng — thì đưa thẳng vào context còn đúng hơn RAG vì không có lỗi truy xuất. Doanh nghiệp bắt buộc dùng RAG vì ba lý do: nguồn gốc câu trả lời, phân quyền truy cập, và cập nhật không cần huấn luyện lại.

Kỹ năngHọc viên quyết định được một bài toán cụ thể cần RAG, in-context hay fine-tuning, và giải thích được lý do.

Hình thứcVideo 4 phút, bảng hai cột "cần" và "chưa cần" hiện dần, kết bằng ví dụ wiki nhỏ đưa thẳng vào context.

Ý chínhHọc viên áp quyết định vừa học lên sáu bài toán: trợ lý chính sách nội bộ đổi hàng tháng; ứng dụng giải toán tiểu học; kịch bản gọi điện 2 trang; kho văn bản luật 3.000 điều; wiki sản phẩm 1.800 dòng ổn định; chatbot cần giọng văn thương hiệu riêng. Nhầm lẫn phổ biến là coi mọi bài toán có tài liệu đều cần RAG.

Kỹ năngHọc viên tự phân loại được một bài toán mới và nhận ra kho nhỏ ổn định không cần RAG.

Hình thứcTương tác kéo-thả: học viên kéo từng bài toán vào một trong ba ô; nếu sai, hệ thống hiển thị lý do. 3 phút. Phương án thay thế: quiz 6 câu.

Ý chính3 câu kiểm tra: tên và vai trò ba pipeline; khâu nào thường gây lỗi nhất; kho nhỏ ổn định nên chọn cách nào.

Kỹ năngHọc viên tự kiểm tra ba ý chính của module.

Hình thứcQuiz 3 câu, chấm ngay, có giải thích khi sai.

Ý chínhKho 10 triệu chunk mà tìm trên toàn bộ thì chậm và nhiễu; lọc trước theo metadata — phòng ban, ngày hiệu lực, loại tài liệu, quyền truy cập — thu về vài trăm nghìn rồi mới chạy vector search, vừa nhanh vừa chính xác hơn. Cặp tương phản với lọc sau: nếu search trả về 10 kết quả mà cả 10 đều không qua bộ lọc thì người dùng không nhận được gì. Quyền truy cập cũng phải lọc trước khi search, không lọc sau, để tài liệu mật không bao giờ lọt vào context; phân quyền theo vai trò là mức cơ bản, theo thuộc tính là mức cao hơn. Đây là lý do metadata ở Ngày 7 không phải phần thừa.

Kỹ năngHọc viên giải thích được vì sao lọc trước tốt hơn lọc sau và nêu được ít nhất ba trường metadata dùng để lọc.

Hình thứcVideo 4 phút. Hình phễu: toàn bộ kho, bộ lọc metadata, tập con nhỏ, search; đoạn so sánh lọc trước và lọc sau trên cùng 10 kết quả.

Ý chínhCâu hỏi thô và tài liệu cách nhau hai khoảng: từ vựng — người dùng gõ "nghỉ đẻ" trong khi văn bản viết "chế độ thai sản" hay "maternity leave" — và ngữ pháp — câu hỏi và câu trả lời có cấu trúc khác nhau nên embedding của chúng nằm xa nhau. Mở rộng câu hỏi thêm từ đồng nghĩa, sửa chính tả, dịch sang ngôn ngữ của kho. Tách câu hỏi khi thông tin nằm ở nhiều tài liệu: "so sánh chính sách hoàn tiền của hai sàn" thành hai truy vấn riêng rồi tổng hợp. Lùi một bước khi câu hỏi quá chi tiết: từ "lỗi 404 khi gọi API thanh toán" lùi về "kiến trúc tích hợp cổng thanh toán" để lấy được tài liệu tổng quan. HyDE sinh một câu trả lời giả định rồi dùng embedding của nó để tìm, vì câu trả lời — dù sai nội dung — có văn phong gần với tài liệu hơn câu hỏi; cặp "tôi rất thích sản phẩm A" và "tôi không thích sản phẩm A" có vector gần nhau minh hoạ điều này. Tất cả dùng một model nhỏ, nhanh, đặt trước retrieval.

Kỹ năngHọc viên chọn được kỹ thuật phù hợp cho một câu hỏi cụ thể và giải thích được vì sao câu trả lời giả định lại tìm tốt hơn câu hỏi thật.

Hình thứcỞ nhà: video 7 phút, mỗi kỹ thuật một cặp "trước và sau" trên cùng kho tài liệu; đoạn HyDE có hình không gian vector với ba điểm câu hỏi, câu trả lời giả định, tài liệu thật. Trên lớp: tương tác 3 phút — học viên dự đoán top-3 của câu hỏi thô "nghỉ đẻ" trên kho cấu hình sẵn, rồi bật từng kỹ thuật và quan sát top-3 thay đổi. Phương án thay thế: video so sánh hai kịch bản, 90 giây.

Ý chínhMỗi kỹ thuật là thêm một lần gọi model trước khi chạm vào kho, nên thêm độ trễ; bật cả bốn cùng lúc có thể khiến một câu hỏi mất nhiều phút. Nguyên tắc: chỉ bật khi câu hỏi thực sự mơ hồ hoặc phức tạp, dùng model nhỏ để giữ bước này dưới 1 giây, và lưu lại kết quả biến đổi của những câu hỏi phổ biến để không xử lý lại. Nhiều câu hỏi đơn giản lấy thẳng từ vector search đã đủ.

Kỹ năngHọc viên quyết định được có bật biến đổi câu hỏi hay không cho một hệ thống cụ thể, và biết cách giữ độ trễ thấp.

Hình thứcVideo 3 phút. Kèm bảng tra cứu một trang: tình huống câu hỏi, kỹ thuật nên dùng, độ trễ thêm.

Ý chính3 câu kiểm tra: lọc trước hay lọc sau; kỹ thuật nào cho câu hỏi hai vế; vì sao HyDE tìm tốt hơn câu hỏi gốc.

Kỹ năngHọc viên tự kiểm tra ba ý chính của module.

Hình thứcQuiz 3 câu, chấm ngay.

Ý chínhDense là cách Ngày 7 đã dùng: vector 768 đến 1.536 chiều, hầu như không ô nào bằng 0, hiểu đồng nghĩa, chịu được lỗi chính tả và đa ngôn ngữ; nhưng bỏ lỡ mã lỗi, tên riêng, số hiệu — hỏi mã lỗi 12345 thì trả về cả 12346, hỏi chính sách của sản phẩm A lại lấy nhầm của sản phẩm B vì cả hai "đều nói về hoàn tiền". Sparse dựa trên BM25: số chiều bằng kích thước từ điển, hầu hết ô bằng 0 — "thưa" là thưa giá trị, không phải ít chiều, và đây là nhầm lẫn phổ biến; từ hiếm được trọng số cao hơn từ phổ thông, khớp chính xác từng từ, rất nhanh và không cần GPU; nhưng không hiểu đồng nghĩa và nhạy với lỗi chính tả. Hai cách bù trừ nhau: dense bỏ lỡ từ khoá thì sparse bắt được, sparse bỏ lỡ đồng nghĩa thì dense bắt được. Sparse không phải kỹ thuật cũ — trong kho mã nguồn lớn hay văn bản luật, tìm theo từ khoá thường là cách chính.

Kỹ năngHọc viên nêu được điểm mù của từng cách và chỉ ra được với một câu hỏi cụ thể cách nào sẽ thắng.

Hình thứcVideo 6 phút. Hai vector hiện cạnh nhau — một gần như kín ô, một gần như toàn ô trắng; bảng so sánh hiện dần từng dòng theo ví dụ.

Ý chínhHọc viên chạy 3 câu hỏi trên một kho nhỏ cấu hình sẵn gồm FAQ kỹ thuật và chính sách: một câu chứa mã lỗi, một câu dùng từ đời thường, một câu bằng tiếng Anh cho kho tiếng Việt. Trước mỗi câu, học viên dự đoán cách nào trả về đúng đoạn; sau đó quan sát top-3 của dense, sparse và hybrid đặt cạnh nhau. Kết thúc bằng câu hỏi: nếu không biết trước người dùng sẽ hỏi kiểu nào, bạn chọn cách nào?

Kỹ năngHọc viên cảm nhận trực tiếp điểm mù của từng cách và lý do hybrid là lựa chọn mặc định khi không đoán được kiểu câu hỏi.

Hình thứcTương tác mô phỏng 4 phút trên dữ liệu cấu hình sẵn, ba cột kết quả hiện song song. Phương án thay thế: video minh hoạ 3 phút.

Ý chínhHybrid chạy hai cách tìm song song — hai việc độc lập, cần hai chỉ mục cho cùng dữ liệu — rồi gộp kết quả. Bài toán khó là "cam và táo": cosine nằm trong khoảng −1 đến 1, điểm BM25 không có giới hạn trên, nên cộng thô thì BM25 lấn át hoàn toàn. RRF gộp thứ hạng thay vì điểm: mỗi tài liệu nhận 1 chia cho (k cộng thứ hạng) ở từng bảng rồi cộng lại, k thường là 60; tài liệu đứng thứ 1 ở dense và thứ 5 ở sparse vẫn lên đầu bảng chung. Alpha weighting gộp điểm đã chuẩn hoá theo tỉ trọng: alpha cho dense, 1 trừ alpha cho sparse; FAQ nghiêng dense, mã lỗi và văn bản luật nghiêng sparse. Alpha không đoán mà đo: quét từ 0 đến 1 trên một test set, hai đầu chính là dense-only và sparse-only — hai baseline để biết hybrid có thật sự hơn. Mới bắt đầu thì dùng RRF vì không cần tinh chỉnh.

Kỹ năngHọc viên giải thích được vì sao không cộng thô hai điểm, tính được điểm RRF của một tài liệu, và chọn được hướng nghiêng alpha theo loại dữ liệu.

Hình thứcỞ nhà: video 6 phút, hai bảng xếp hạng hiện cạnh nhau rồi hợp nhất từng dòng theo công thức; đường cong alpha hiện dần. Trên lớp: tương tác 3 phút — học viên kéo thanh alpha từ 0 đến 1 và quan sát thứ hạng đổi; bật chế độ "cộng thô" để thấy BM25 lấn át rồi bật RRF. Phương án thay thế: video minh hoạ 2 phút.

Ý chínhRetriever quét hàng triệu tài liệu rất nhanh nhưng đánh giá liên quan "thô và rộng": hỏi "thủ tục xin visa" thì top 1 là giá làm visa, top 2 là lịch sử visa, còn các bước thủ tục nằm ở top 8. Giải pháp là hai giai đoạn: tìm rộng lấy 50 đến 100 đoạn, rồi đưa qua một model xếp lại đọc kỹ từng cặp câu hỏi và đoạn, chấm lại, giữ 3 đến 5 đoạn cho model sinh câu trả lời. Bi-encoder mã hoá câu hỏi và tài liệu riêng rồi so khoảng cách nên rất nhanh; cross-encoder ghép cả hai thành một đầu vào nên chính xác hơn nhưng chậm — vì vậy không dùng nó để tìm từ đầu, chỉ dùng trên danh sách nhỏ. Ở giai đoạn 1 chấp nhận lấy dư — thà bắt nhầm hơn bỏ sót. Không phải hệ thống nào cũng cần xếp lại: kho nhỏ mà top-5 đã đủ thì thêm bước này chỉ thêm độ trễ.

Kỹ năngHọc viên giải thích được vì sao không dùng cross-encoder ngay từ đầu và quyết định được hệ thống của mình có cần re-ranking hay không.

Hình thứcỞ nhà: video 5 phút, phễu hai giai đoạn từ 100 xuống 5 kèm thanh thời gian của từng giai đoạn; hình so sánh bi-encoder và cross-encoder. Trên lớp: tương tác 3 phút — bật và tắt re-ranker trên top-20 cấu hình sẵn, quan sát top-5 thay đổi và độ trễ tăng. Phương án thay thế: video minh hoạ 2 phút.

Ý chínhKho thật thường có nhiều đoạn gần giống nhau — bản cũ, bản mới, cùng một chính sách lưu ở nhiều nơi — nên top-5 có thể toàn bản trùng, trong khi đoạn bổ sung cần thiết rơi khỏi danh sách. MMR chọn từng đoạn vừa liên quan với câu hỏi vừa khác các đoạn đã chọn, để context đa dạng mà vẫn đúng chủ đề: cùng một truy vấn, tìm theo tương đồng cho 4 đoạn lặp lại một nội dung, MMR cho 9 đoạn khác nhau. Cross-encoder khi cần một đáp án chính xác duy nhất, như tra cứu pháp lý; MMR khi câu hỏi mở cần tổng hợp nhiều nguồn. Tốt nhất vẫn là khử trùng lặp ngay lúc index, vì đó là gốc của vấn đề. Toàn bộ chuỗi truy xuất gói lại trong một sơ đồ: câu hỏi, biến đổi, hybrid, gộp, xếp lại, top-k.

Kỹ năngHọc viên nhận ra trùng lặp trong top-k và chọn được giữa MMR và cross-encoder theo kiểu câu hỏi.

Hình thứcVideo 4 phút, hai lưới kết quả đặt cạnh nhau. Kèm sơ đồ một trang "chuỗi truy xuất hoàn chỉnh" để học viên lưu lại.

Ý chính4 câu kiểm tra: "thưa" trong sparse nghĩa là gì; vì sao không cộng thô hai điểm; vai trò của k trong RRF; vì sao không dùng cross-encoder từ đầu.

Kỹ năngHọc viên tự kiểm tra bốn ý chính của module.

Hình thứcQuiz 4 câu, chấm ngay.

Ý chínhNối thô các chunk là cách sơ khai: model không biết đoạn nào đến từ đâu, nội dung đứt quãng. Chuẩn cho sản phẩm là mỗi chunk bọc trong thẻ có mã, nguồn, ngày, phòng ban; ba khối còn lại — system, câu hỏi, ràng buộc — tách rõ bằng thẻ hoặc tiêu đề. Thứ tự bốn khối có lý do: system đặt trên cùng vì ít thay đổi nên lưu đệm được; context ở giữa; câu hỏi sau context để model đọc chứng cứ rồi mới gặp câu hỏi; ràng buộc đặt cuối vì đó là vị trí model tuân thủ tốt nhất. Mã tài liệu dài nên ánh xạ về [1], [2], [3] để trích dẫn ít sai. Ngân sách token chia ba phần: khoảng 20% cho system, 60% cho context, 20% dành cho câu hỏi và đầu ra; không nhồi đầy context window vì nhiều hơn là chậm hơn và nhiễu hơn, nếu vẫn quá dài thì nén chunk bằng model nhỏ.

Kỹ năngHọc viên viết được prompt RAG bốn khối đúng thứ tự, giải thích được lý do từng vị trí, và giữ context trong ngân sách.

Hình thứcVideo 6 phút. Prompt hiện dần từng khối với chú thích lý do; hình chiếc bánh ba phần 20, 60, 20. Kèm mẫu prompt bốn khối một trang để học viên dùng trong lab.

Ý chínhModel nhớ tốt thông tin ở đầu và cuối context, dễ bỏ sót phần giữa — hiện tượng đã gặp ở Ngày 1, nay áp vào RAG: nếu đưa nguyên top 1 đến 5 theo thứ tự thì đoạn thứ 2, rất liên quan, lại rơi đúng vào vùng bị bỏ sót. Cách sắp xếp lại: đoạn tốt nhất ở đầu, tốt thứ hai ở cuối, điểm thấp giấu vào giữa — thứ tự đưa vào prompt là 1, 3, 5, 4, 2. Model lớn ít mắc hơn nhưng model nhỏ và context dài vẫn mắc, nên đây là thói quen nên có.

Kỹ năngHọc viên sắp xếp lại được top-k trước khi đưa vào prompt và giải thích được vì sao.

Hình thứcVideo 4 phút với đường cong chú ý và năm khối đổi chỗ. Kèm tương tác 2 phút: học viên đặt chunk chứa đáp án ở giữa rồi ở cuối, dự đoán và quan sát câu trả lời trên dữ liệu cấu hình sẵn. Phương án thay thế: video minh hoạ 60 giây.

Ý chínhHai chunk cùng nói về một chính sách nhưng một bản ghi 14 ngày, một bản ghi 17 ngày; nếu chunk không mang ngày thì model không có cách nào biết bản nào mới — đây là lỗi indexing của Ngày 7 lộ ra ở augmentation. Ba chiến lược khi context mâu thuẫn: bản mới nhất thắng, hợp với chính sách và bảng giá; nguồn có thẩm quyền thắng, văn bản chính thức hơn email hơn wiki, hợp với pháp lý; hoặc nêu rõ mâu thuẫn và trả cả hai để người dùng quyết, khi sai một chiều gây hậu quả lớn. Luật ưu tiên viết thẳng trong prompt. Kiểu lỗi không thước đo nào bắt được: chính sách đổi tuần trước, chỉ mục vẫn giữ bản cũ, mọi điểm đều đẹp mà câu trả lời sai với thực tế — cần ghi đè theo mã tài liệu khi index lại, xoá thật tài liệu thu hồi, và hiện ngày tài liệu lên giao diện để người dùng tự phát hiện.

Kỹ năngHọc viên chọn được chiến lược xử lý mâu thuẫn cho một loại dữ liệu và nêu được ba việc để chỉ mục không giữ bản cũ.

Hình thứcVideo 5 phút. Hai chunk mâu thuẫn hiện cạnh nhau, ba chiến lược lần lượt áp lên; đoạn cuối là dòng thời gian tài liệu đổi mà chỉ mục chưa đổi.

Ý chính3 câu kiểm tra: vì sao ràng buộc đặt cuối prompt; thứ tự đưa top-5 vào prompt; chọn chiến lược khi hai bản chính sách mâu thuẫn.

Kỹ năngHọc viên tự kiểm tra ba ý chính của module.

Hình thứcQuiz 3 câu, chấm ngay.

Ý chínhMột prompt RAG chuẩn có bốn phần: vai trò, nhiệm vụ, context, và ràng buộc cứng — chỉ dùng context được cung cấp, không dùng kiến thức huấn luyện, mọi khẳng định phải kèm trích dẫn. Tính năng quan trọng nhất là biết từ chối: nếu context không chứa đáp án, model phải trả đúng một câu "dữ liệu hiện tại không đủ để trả lời" thay vì đoán, rồi gợi ý hướng tiếp theo — thử từ khoá khác, liên hệ bộ phận phụ trách, hoặc hỏi có muốn tìm rộng hơn. Yêu cầu model đọc kỹ và suy nghĩ từng bước trước khi trả lời giúp câu trả lời bám chứng cứ hơn; temperature thấp giảm bịa. Một hệ thống biết nói "tôi không đủ dữ liệu" đáng tin hơn hệ thống luôn có câu trả lời.

Kỹ năngHọc viên viết được prompt neo dữ kiện có trích dẫn và từ chối đúng lúc, và đã trực tiếp quan sát model bịa khi thiếu dòng từ chối.

Hình thứcỞ nhà: video 6 phút, prompt hiện từng phần, hai hộp thoại "từ chối cụt lủn" và "từ chối có gợi ý" đặt cạnh nhau. Trên lớp: thực hành 4 phút — học viên bật và tắt dòng từ chối trong prompt cấu hình sẵn, chạy một câu hỏi có trong kho và một câu hỏi không có trong kho, quan sát model bịa hay từ chối. Phương án thay thế: video ghi màn hình 3 phút.

Ý chínhNgười dùng doanh nghiệp không quan tâm thuật toán bên trong, họ chỉ thấy giao diện và quyết định có tin hay không. Bốn thứ tạo niềm tin: định dạng dựng được trên giao diện thay vì văn bản thô; trích dẫn ngay trong dòng, nhấp vào là tới đoạn gốc, cộng khối nguồn tham khảo ở cuối; điểm tự tin kèm cảnh báo khi thấp — nhưng để model tự chấm câu trả lời của mình là "vừa đá bóng vừa thổi còi", nên nếu cần tin cậy thì tách thành một module đánh giá riêng; và trạng thái đang xử lý — "đang tìm, đang đọc, đang tổng hợp" — vì thời gian tổng như nhau nhưng cảm giác chờ khác hẳn. Với RAG, chính xác được ưu tiên hơn tốc độ; người dùng chấp nhận chậm vài giây nếu câu trả lời có nguồn.

Kỹ năngHọc viên thiết kế được đầu ra có trích dẫn, cảnh báo và trạng thái xử lý, và giải thích được vì sao điểm tự tin do model tự chấm không đáng tin.

Hình thứcVideo 5 phút, bốn mô hình giao diện hiện lần lượt; đoạn streaming so sánh hai thanh thời gian có tổng bằng nhau.

Ý chínhCó những lúc retrieval mang về đúng tài liệu mà model vẫn vấp ở bước cuối. Xung đột ngữ cảnh: hai bản chính sách cùng vào context, model hoặc nói không biết hoặc bịa một con số ở giữa — sửa bằng metadata và luật ưu tiên của Module 4. Suy diễn quá đà: tài liệu ghi miễn phí giao hàng cho đơn trên 500.000 tại Hà Nội, người dùng hỏi ở thành phố khác, model trả lời "cũng được" — sửa bằng ràng buộc cấm suy diễn và một bước kiểm tra lại trước khi trả. Bỏ qua ràng buộc: đã dặn trích dẫn mà model quên — sửa bằng ràng buộc đặt cuối, temperature về 0, hoặc model mạnh hơn. Quy trình chẩn đoán chỉ có một câu hỏi: in context đã đóng gói ra và xem nó có chứa đáp án không; có mà vẫn sai là lỗi generation, không có là lỗi retrieval, và nếu đáp án không tồn tại trong kho thì là lỗi dữ liệu.

Kỹ năngHọc viên nhận diện được ba kiểu lỗi qua triệu chứng và chỉ ra được lỗi thuộc khâu nào bằng một bước kiểm tra.

Hình thứcVideo 5 phút, mỗi lỗi một hộp thoại "tình huống, câu trả lời sai, cách sửa". Kèm cây chẩn đoán một trang để học viên dùng trong lab.

Ý chínhTầng suy luận mạnh cho câu hỏi cần so sánh nhiều nguồn mâu thuẫn; tầng giữa là mặc định, đủ tốt cho đa số câu hỏi RAG; tầng nhỏ hoặc tự triển khai cho tra cứu trực tiếp hoặc dữ liệu bắt buộc ở nội bộ. Không phải mọi câu hỏi cần cùng một model: phân loại câu hỏi trước rồi điều hướng, đơn giản đi tầng nhỏ, phức tạp đi tầng cao. Ba tiêu chí — độ phức tạp câu hỏi, bảo mật, nguồn lực — được xếp ưu tiên khác nhau giữa sản phẩm đại chúng và dự án cho một doanh nghiệp. Chọn bằng đo lường, không chọn theo tên; nối với cách chọn model theo tầng của Ngày 1.

Kỹ năngHọc viên chọn được tầng model cho một hệ thống RAG cụ thể và giải thích được vì sao nên điều hướng thay vì dùng một model cho tất cả.

Hình thứcVideo 4 phút, bảng ba tầng và sơ đồ điều hướng câu hỏi.

Ý chính3 câu kiểm tra: model phải làm gì khi context không có đáp án; lỗi "suy diễn quá đà" sửa bằng gì; context có đáp án mà trả lời sai là lỗi ở khâu nào.

Kỹ năngHọc viên tự kiểm tra ba ý chính của module.

Hình thứcQuiz 3 câu, chấm ngay.

Ý chínhNhập thử 3 đến 5 câu thấy mượt rồi kết luận sẵn sàng là bẫy: một thay đổi nhỏ như giảm kích thước chunk có thể tốt cho 10 câu này mà hỏng 100 câu khác, và mỗi lần chạy lại cho kết quả khác. Độ chính xác đơn thuần cũng không đủ: hỏi số ngày phép, retrieval không tìm được tài liệu, model bịa "15 ngày" từ kiến thức chung — trùng với thực tế nên bị coi là đúng, trong khi cả hai khâu đều hỏng. Vì vậy phải đo từng khâu bằng bộ câu hỏi cố định, chạy lại được.

Kỹ năngHọc viên nêu được vì sao độ chính xác đơn thuần không đủ và vì sao cần bộ câu hỏi cố định.

Hình thứcVideo 4 phút, kể tình huống "15 ngày phép" thành câu chuyện ngắn có hình.

Ý chínhContext recall đo retrieval: chứng cứ cần có được lấy về đủ chưa — cần 3 tài liệu mà lấy được 2 là 2 phần 3. Faithfulness đo generation: từng ý trong câu trả lời có chứng cứ trong context không — 5 ý mà 4 ý có chứng cứ là 80%; bịa mà tình cờ đúng vẫn điểm thấp, vì model đã không trung thực với dữ liệu. Answer relevance đo trọng tâm: trả lời đúng ý hỏi, không lan man, không thừa thiếu. Mỗi trục thấp chỉ đúng chỗ cần sửa: recall thấp thì xem lại chunking, metadata, hybrid; faithfulness thấp thì siết prompt, ép trích dẫn, hạ temperature; relevance thấp thì sửa hướng dẫn và cách đóng gói. Ngày 14 đi sâu vào cách tính và công cụ chấm.

Kỹ năngHọc viên định nghĩa được ba trục bằng lời của mình và chỉ được mỗi trục thấp thì sửa ở khâu nào.

Hình thứcVideo 5 phút, tam giác ba trục, mỗi trục một ví dụ tính bằng số. Kèm bảng tra cứu một trang: trục, câu hỏi nó trả lời, khâu cần sửa khi thấp.

Ý chínhHọc viên nhận 5 bảng điểm cấu hình sẵn và phải chỉ ra khâu cần sửa: recall cao mà faithfulness thấp là lỗi generation; recall thấp mà faithfulness cao là hệ thống ngoan ngoãn nói "không biết" vì retrieval không tìm được; cả ba trục thấp là dữ liệu đưa vào có vấn đề từ indexing; cả ba cao là sẵn sàng. Học viên dự đoán trước rồi hệ thống giải thích.

Kỹ năngHọc viên đọc được một bảng điểm và chỉ đúng khâu cần sửa mà không cần chạy lại hệ thống.

Hình thứcTương tác 3 phút trên 5 bảng điểm cấu hình sẵn, chọn một trong bốn ô, có giải thích. Phương án thay thế: quiz 5 câu.

Ý chínhChỉ đổi một biến mỗi thử nghiệm: đổi 10 thứ cùng lúc mà 5 tốt lên 5 tệ đi thì điểm trung bình không đổi và không biết giữ cái nào. Tình huống thường gặp: từ dense sang hybrid, recall tăng từ 60% lên 90% vì bắt được mã lỗi và tên riêng — đây là thay đổi ít công sức nhất cho mức cải thiện lớn nhất, nên thử trước khi nghĩ tới re-ranking hay đổi model. Ngược lại, thêm cross-encoder tăng 5% nhưng độ trễ từ 1 giây lên 4 giây và cần thêm tài nguyên — không phải cải tiến nào cũng đáng thêm, và hybrid không hơn dense cũng là một kết quả hợp lệ. Bản chất kho dữ liệu quyết định cả alpha lẫn kiến trúc, nên không sao chép cấu hình từ dự án khác. Bộ câu hỏi cố định 15 đến 20 câu có ca khó — mã lỗi, nhiều bước, không có đáp án, hai tài liệu mâu thuẫn — là đủ để bắt suy giảm; cách xây chi tiết ở Ngày 14.

Kỹ năngHọc viên lập được một thử nghiệm đổi một biến và cân nhắc được mức cải thiện với độ trễ trước khi thêm kỹ thuật.

Hình thứcVideo 4 phút, hai cột V1 và V2 trên cùng bộ câu hỏi; bàn cân "mức tăng" và "độ trễ".

Ý chính3 câu kiểm tra: recall thấp sửa ở khâu nào; bịa mà đúng thì faithfulness ra sao; vì sao chỉ đổi một biến mỗi lần.

Kỹ năngHọc viên tự kiểm tra ba ý chính của module.

Hình thứcQuiz 3 câu, chấm ngay.

Ý chínhGiảng viên trả lời câu hỏi mở đầu bằng bốn điểm: dense đơn thuần không đủ, hybrid là cải tiến ít công sức nhất cho mức tăng recall lớn nhất; augmentation là một bước riêng — cấu trúc, thứ tự, metadata và ngân sách đều đổi kết quả với cùng bộ chunk; từ chối đúng lúc là tính năng, không phải giới hạn; không đo thì không biết đang tốt lên, và RAG không phải mặc định — kho nhỏ ổn định thì in-context còn đúng hơn. Giới thiệu Ngày 9.

Kỹ năngHọc viên tóm tắt được bốn điểm chính bằng ngôn ngữ của mình.

Hình thứcVideo giảng viên, 3 phút.

Ý chínhRAG một lượt là luồng cố định; agentic RAG để model tự quyết định: câu dễ trả lời ngay, câu khó thì tách nhỏ, chọn công cụ tìm — dense, hybrid, gọi API hệ thống nhân sự — rồi lặp cho đến khi đủ chứng cứ. Ba mẫu: tự đặt truy vấn, tự sửa khi tài liệu tìm được kém, và thích ứng chiến lược theo câu hỏi. Retriever giờ chỉ là một công cụ trong hộp công cụ của agent — RAG là "chi", agent là "não". Mở rộng cho item 1.1 và chuẩn bị cho Ngày 9.

Kỹ năngHọc viên mô tả được vòng lặp của agentic RAG và vị trí của retriever trong hệ agent.

Hình thứcVideo 7 phút, vòng lặp chạy trên một câu hỏi cần hai nguồn.

Ý chínhCùng một kho, hai kiến trúc: tìm rồi đưa, hay biên tập rồi đưa hết vào context. Ví dụ: 175 trang web sản phẩm nhiều trùng lặp được biên tập thành một wiki chừng 1.800 dòng — nhỏ và ổn định — thì đưa thẳng vào prompt, không có lỗi truy xuất, trả lời nhanh hơn. Ba loại kho cho ba kết quả: tin tức nghiêng dense và luôn cần RAG vì đổi liên tục; văn bản luật nghiêng sparse và cần RAG vì quá dài; bảng sản phẩm nhiều tên riêng thì in-context có thể thắng. Câu RAG thua là câu cần gom từ nhiều tài liệu không chunk nào chứa đủ; câu RAG thắng là câu chỉ cần một chunk trong kho quá lớn. Mở rộng cho item 1.2.

Kỹ năngHọc viên so sánh được RAG và in-context trên kho của mình và kết luận được kiến trúc nào hợp với loại dữ liệu nào.

Hình thứcVideo 6 phút, bảng ba loại kho và 2 câu hỏi đối chứng.

Ý chínhMỗi ca kiểm tra gồm ba phần: câu hỏi viết như người dùng thật, câu trả lời đúng do người chốt, và mã chunk phải được tìm thấy. Nguồn theo thứ tự ưu tiên: nhật ký câu hỏi thật, câu hỏi hay gặp từ bộ phận chăm sóc khách hàng, người có chuyên môn viết tay, LLM sinh nháp rồi người xem lại — bộ do LLM sinh toàn bộ mà không ai xem thì chỉ đo được "model có đồng ý với chính nó". Chấm 100 câu bằng tay không khả thi nên dùng một model mạnh làm giám khảo; tích hợp vào quy trình phát hành để chặn khi faithfulness tụt dưới ngưỡng. Mở rộng cho item 6.2 và 6.4; Ngày 14 đi sâu.

Kỹ năngHọc viên phác được một bộ câu hỏi kiểm tra có đủ ca khó và biết vai trò của người trong việc chốt đáp án.

Hình thứcVideo 6 phút, một ca kiểm tra mẫu hiện từng trường; sơ đồ quy trình phát hành có cổng chặn.

Ý chínhBa pha. Cá nhân: thêm BM25 chạy song song dense và gộp bằng RRF, giữ lại đường dense-only làm V1; đóng gói context có mã và ngày cho từng chunk, sắp xếp lại thứ tự, giữ context trong 60% ngân sách; viết prompt neo dữ kiện bắt buộc trích dẫn và từ chối khi thiếu chứng cứ. Nhóm: cùng viết 15 đến 20 ca kiểm tra trên kho của Ngày 7 có đủ ca khó — mã lỗi, nhiều bước, không có đáp án, hai tài liệu mâu thuẫn; chạy V1 và V2 trên cùng bộ, điền bảng điểm, với mỗi ca không đạt chỉ ra lỗi thuộc retrieval, augmentation, generation hay indexing; trình bày một ca V2 thắng rõ và một ca V2 không thắng. Về nhà: xây kho thứ ba từ dữ liệu thu thập thật, so RAG với in-context trên kho đó. V2 phải chứng minh bằng số, và V2 không hơn V1 cũng là kết quả hợp lệ.

Kỹ năngHọc viên có một RAG service chạy được với hybrid, trích dẫn và từ chối, có bảng điểm so sánh hai phiên bản, và chỉ được lỗi thuộc khâu nào cho từng ca không đạt.

Hình thứcLab 120 phút tại lớp với người hướng dẫn theo repo có sẵn, cộng phần về nhà khoảng 100 phút. Kèm mã khung ba tệp retriever, augment, generate có sẵn vị trí điền; mẫu bộ câu hỏi kiểm tra và mẫu bảng điểm.