Bốn kiểu hỏng của RAG

TL;DR: RAG (bài trước) giảm hallucination bằng cách neo model vào đoạn tài liệu retrieve được, nhưng không triệt tiêu — model vẫn xử lý sai ngay cả khi có đúng đoạn trong tay. Sửa một hệ RAG hỏng, việc đầu tiên là cô lập bước hỏng: đáp án có trong kho tài liệu không, có được retrieve vào context không, rồi mới hỏi generation xử lý sao. Bốn cách generation có thể xử lý sai có tên chuẩn — noise robustness, negative rejection, information integration, counterfactual robustness — cho bạn khung tra cứu thay vì đoán mò.

Nhóm ở bài trước vừa dựng xong pipeline RAG cho chatbot tra policy nội bộ. Tuần triển khai đầu tiên, bốn ticket "bot trả lời sai" đổ về gần như cùng lúc:

• Ticket 1: Hỏi "Nghỉ phép năm áp dụng cho intern không?" — bot trộn quy định nhân viên chính thức với đoạn nói về lương thực tập, hai đối tượng bị gộp làm một.
• Ticket 2: Hỏi "Công ty có áp dụng tuần làm việc 4 ngày không?" — chính sách chưa từng tồn tại. Bot trả lời chắc nịch: "Có, áp dụng từ quý này."
• Ticket 3: Hỏi "Tổng ngày nghỉ phép cộng dồn sau ba năm?" — đáp án cần cộng số ngày cơ bản (một đoạn) với thâm niên (đoạn khác). Bot chỉ lấy số ở đoạn đầu.
• Ticket 4: Hỏi "Mức phụ cấp đi lại hiện tại?" — kho có bản nháp cũ (số lỗi thời) và bản đã duyệt (số mới), cả hai đều được retrieve đúng. Bot trích số ở bản nháp cũ.

Bốn ticket, cùng triệu chứng bề mặt ("bot trả lời sai"), nhưng đổ lỗi cho generation ngay lập tức là vội. Bài này dựng khung chẩn đoán để tách chúng ra.

1. Analogy — thủ thư và người đọc

Bạn nhờ thư viện tìm tài liệu trả lời một câu hỏi. Hai vai trò tách biệt: thủ thư đi tìm và mang về trang liên quan (retrieval), người đọc cầm đúng trang đó và trả lời (generation). Thủ thư có thể mang nhầm sách, bỏ sót cuốn đúng — lỗi xảy ra trước khi người đọc chạm vào trang nào. Nhưng giả sử thủ thư mang đúng hết: người đọc vẫn có thể hỏng theo bốn kiểu — bị phân tâm bởi trang lạc đề kẹp chung xấp giấy, không dám nói "không có câu trả lời" mà bịa đại, chỉ đọc trang đầu quên trang sau dù cả hai đều cần, hoặc tin theo một trang ghi sai/lỗi thời. Bốn failure mode trong bài này toàn bộ là lỗi của người đọc, không phải lỗi thủ thư.

Một câu để nhớ: thủ thư mang nhầm sách = retrieval hỏng (ngoài 4 mode); người đọc đọc sai dù cầm đúng sách = 4 mode, ở generation.

2. RAG trả lời sai — hỏng ở bước nào?

Trước khi gọi tên một mode, cô lập bước hỏng bằng ba câu hỏi tuần tự — thứ tự quan trọng, bỏ qua bước đầu là nguồn phổ biến nhất khiến người đọc mode sai.

Điểm mấu chốt là thứ tự: chỉ khi đã loại được "đáp án vắng mặt trong kho" (B1) và "retrieve sót" (B2) thì lỗi mới chắc chắn ở generation — lúc đó đặc điểm context cho biết mode nào trong ba mode còn lại (bảng bên dưới).

3. Bốn failure mode có tên gọi gì?

Bốn tên này không phải bài tự đặt: chúng lấy nguyên văn từ benchmark RGB (Chen et al., 2023 — xem Deep Dive §6), đo trên sáu large language model. Cả bốn đều kiểm tra cùng một thứ: generation xử lý context đã retrieve tốt tới đâu.

Lưu ý: bốn tên gọi là của RGB, nhưng khung ba bước ở mục 2 (tách "đáp án vắng mặt trong kho" khỏi "retrieve sót") là công cụ chẩn đoán thực hành bài tự xây để debug hệ RAG thật — không phải cách RGB vận hành testbed. Dùng nó như bản đồ cô lập lỗi, không phải định nghĩa formal.

1. Noise robustness. Context lẫn đoạn nhiễu — gần nghĩa nhưng không thật sự trả lời câu hỏi (vì embedding tìm theo độ gần nghĩa, không theo "có trả lời được không"). Model bỏ qua được nhiễu hay bị kéo lệch? Ticket 1 (trộn chính sách intern) là ca này.

2. Negative rejection. Không đoạn nào trong context chứa đáp án, vì đáp án thật sự không tồn tại trong kho — không phải bug. Hành vi đúng là nói "không tìm thấy thông tin này". Ticket 2 (tuần 4 ngày) là ca này: bot phải từ chối, nhưng nó bịa.

3. Information integration. Đáp án cần gộp thông tin từ nhiều đoạn — không đoạn nào một mình đủ trả lời trọn vẹn. Model có tổng hợp được, hay chỉ dùng đoạn đầu rồi dừng? Ticket 3 (tổng ngày phép cộng thâm niên) là ca này.

4. Counterfactual robustness. Một đoạn trong context chứa thông tin sai hoặc lỗi thời — không phải nhiễu vô hại mà là thông tin liên quan nhưng sai. Model có tin theo mù quáng hay phát hiện mâu thuẫn? (RGB đo khả năng này khi model được cảnh báo trước qua instruction rằng context có thể chứa thông tin sai; tự phát hiện mâu thuẫn mà không được nhắc là biến thể khó hơn.)

4. Ticket khó nhất — retrieval hỏng hay generation?

Ticket 1, 2, 3 đã gắn mode ở mục trên. Ticket 4 dễ nhầm nhất vì bề mặt trông giống retrieval hỏng — tự chẩn đoán trước khi xem đáp án.

Đáp án: cả hai bản đều được retrieve vào context — không phải lỗi fetch, đáp án đúng có mặt. Lỗi chắc chắn ở generation; "một đoạn sai/lỗi thời nằm cạnh đoạn đúng" đúng định nghĩa counterfactual robustness, không phải noise (bản cũ vẫn liên quan, chỉ sai) hay negative rejection (đáp án đúng có mặt). Đối lại, Ticket 2 (chính sách chưa từng ban hành) dừng ngay ở bước 1: không có gì để fetch, generation phải từ chối thay vì bịa — negative rejection.

5. Pitfall

❌ Thấy bot trả lời sai là đi sửa prompt/model ngay: chạy khung ba bước trước. Nếu đáp án chưa được retrieve vào context, sửa prompt hay đổi model không giải quyết gì — model không thể trả lời đúng thứ chưa từng thấy. (Và nhớ: RAG giảm bịa chứ không triệt tiêu — có đúng đoạn không đảm bảo model dùng đúng nó.)

6. 📚 Deep Dive

7. Liên hệ các bài khác

• Bài 05 — RAG pipeline — bài này giả định pipeline embed → retrieve → context → generate đã chạy đúng luồng; bốn mode ở đây chẩn đoán khi luồng đó hỏng.
• Bài 04 — Chunking — chunk sai kích cỡ hoặc mất ngữ cảnh biên là một nguồn gốc phổ biến đẩy một ca vào noise robustness hoặc information integration.
• Hallucination — cơ chế gốc: model không có khái niệm đúng/sai, chỉ có phân phối xác suất. RAG là một cách neo phân phối đó tốt hơn, không phải cách xoá bỏ cơ chế.
• Mini-challenge — chọn kiến trúc — dùng đúng khung chẩn đoán này khi cân nhắc RAG có phải lựa chọn phù hợp cho một use case hay không.

8. Tóm tắt

• Chẩn đoán theo ba bước đúng thứ tự: đáp án có trong kho không, có được retrieve vào context không, rồi mới xét generation.
• Đáp án không tồn tại trong kho → negative rejection, không phải lỗi retrieval — cần phân biệt rõ trước khi sửa.
• Bốn tên gọi chuẩn: noise robustness, negative rejection, information integration, counterfactual robustness — đều mô tả cách generation xử lý context đã có (benchmark RGB, Chen et al., AAAI 2024).
• RGB đo trên tiếng Anh/Trung, không có tiếng Việt — taxonomy chuyển giao được, con số cụ thể phải tự đo.

9. Tự kiểm tra

Bài tiếp theo: Mini-challenge — chọn kiến trúc