Cách chẩn đoán lỗi RAG từ giai đoạn tìm kiếm

Đừng đổ lỗi cho mô hình trước khi soi lại phần tìm kiếm

RAG lỗi chẩn đoán là quy trình phân tích hệ thống tìm kiếm tăng cường để xác định giai đoạn thất bại đầu tiên, tách riêng ba bước tìm kiếm, chứng thực và sinh, rồi dùng metrics đánh giá RAG cùng một bộ câu hỏi chuẩn hóa để tìm đúng chỗ phải sửa thay vì sửa bừa cả mô hình lẫn cấu hình. Khi câu trả lời RAG sai, phản xạ phổ biến là đổi mô hình hoặc viết lại prompt. Đó là cách sửa mang tính “cầu may” hơn là chẩn đoán. Nếu đúng đoạn tài liệu không hề lọt vào top kết quả tìm kiếm thì dù bạn có dùng mô hình lớn hơn, câu trả lời cũng không có cơ hội đúng. Ngược lại, khi bằng chứng đã được tìm nhưng biến mất khỏi đầu vào cuối cùng, lỗi nằm ở bước chứng thực/augment chứ không phải tìm kiếm. Còn nếu mô hình nhận đủ bằng chứng mà vẫn suy luận sai, đó mới là lỗi sinh.

Bóc tách RAG thành ba giai đoạn và bốn metrics độc lập

Để chẩn đoán lỗi bài bản, bạn cần coi RAG là chuỗi ba giai đoạn độc lập: tìm kiếm tài liệu phù hợp, chứng thực và sắp xếp lại kết quả thành ngữ cảnh, rồi sinh câu trả lời từ ngữ cảnh đó. Sai ở giai đoạn nào thì giải pháp, đội phụ trách và rủi ro cũng khác. Việc gom tất cả vào một điểm số tổng cho câu trả lời khiến bạn mù nguyên nhân. Thay vào đó, hãy theo dõi riêng bốn metrics đánh giá RAG: (1) Tỷ lệ tìm trúng tài liệu chuẩn trong top K; (2) Mức độ câu trả lời bám vào ngữ cảnh được truyền; (3) Độ chính xác của kết luận, điều kiện và phạm vi áp dụng so với đáp án chuẩn; (4) Mức độ khớp giữa phần trích dẫn và đoạn văn bản thực sự làm bằng chứng. Một tập hợp câu trả lời có điểm tìm kiếm cao nhưng chính xác thấp là tín hiệu mạnh cho thấy lỗi nằm ở chứng thực hoặc sinh, chứ không phải hệ thống tìm kiếm.

Xây bộ 20–30 câu hỏi vàng để tìm đúng giai đoạn thất bại

Không cần trăm nghìn câu hỏi để bắt đầu chẩn đoán có hệ thống. Một bộ 20–30 câu hỏi “vàng”, đại diện cho tình huống thật trong công việc, đã đủ để kích hoạt quy trình đánh giá và tạo baseline vận hành. Mỗi câu hỏi cần được gắn kèm: loại câu hỏi (sự kiện đơn, nhiều tài liệu, điều kiện mơ hồ, không có đáp án trong kho tri thức), đáp án chuẩn và các yếu tố bắt buộc, danh sách tài liệu chuẩn với số lượng bằng chứng cần có, ghi nhận top K kết quả tìm kiếm và việc bằng chứng có xuất hiện hay không, ngữ cảnh cuối cùng truyền cho mô hình, cùng ba chỉ số: mức độ bám ngữ cảnh, độ chính xác, độ khớp trích dẫn. Quan trọng nhất là trường “giai đoạn thất bại đầu tiên” kèm ghi chú nguyên nhân. Bảng này biến mọi lỗi thành ca bệnh có thể tái hiện và so sánh trước–sau, thay vì những lời phàn nàn chung chung như “RAG trả lời sai”.

Một câu nói đáng trích dẫn ở đây là: “20–30 câu hỏi không phải để chứng minh hệ thống ổn định về mặt thống kê, mà là điểm xuất phát để vận hành quy trình chẩn đoán có thể lặp lại”. Cách nghĩ này giúp đội nhỏ không bị mắc kẹt vào tham vọng đo lường hoàn hảo mà quên mất mục tiêu là tìm ra giai đoạn thất bại rõ ràng, rồi sửa lần lượt.

Phân biệt lỗi kiến thức, lỗi hành vi và vai trò của RAG

Trong nhiều hệ thống doanh nghiệp, lỗi RAG bị trộn lẫn với lỗi hành vi của mô hình đã tinh chỉnh. Cách tách bạch là đặt cạnh nhau yêu cầu thất bại, ngữ cảnh thực sự được truyền cho mô hình và đầu ra mong đợi. Nếu điều khoản cần thiết không có trong ngữ cảnh, đó là lỗi kiến thức hoặc lỗi tìm kiếm. Nếu điều khoản có đầy đủ nhưng câu trả lời lại bỏ trường bắt buộc hoặc dùng giọng điệu sai, đó là lỗi hành vi. Một hướng dẫn của Google Cloud nhấn mạnh rằng khi ứng dụng phải luôn trích dẫn nguồn từ dữ liệu nội bộ thì RAG là lựa chọn bắt buộc. Điều này gắn trực tiếp với metrics về trích dẫn: nếu phần trích dẫn không thực sự chứa điều kiện hoặc con số mà câu trả lời khẳng định, hệ thống có thể đánh lừa người dùng bằng cảm giác “có nguồn” trong khi không thể kiểm chứng.

Kết luận: Chẩn đoán theo từng giai đoạn để sửa đúng trọng tâm

Nếu bạn chỉ nhìn vào một điểm số tổng cho câu trả lời, mọi lỗi RAG sẽ trông giống nhau và hướng sửa thường là “đổi mô hình” hoặc “viết lại prompt”. Cách tiếp cận chẩn đoán từng giai đoạn buộc bạn phải trả lời ba câu hỏi: bằng chứng chuẩn đã được tìm chưa, đã được đưa vào ngữ cảnh chưa, và mô hình đã dùng nó một cách trung thành chưa. Việc gắn bốn metrics rõ ràng, xây bộ 20–30 câu hỏi vàng và ghi nhận giai đoạn thất bại đầu tiên cho từng ca lỗi biến quá trình debug từ cảm tính thành có cấu trúc. Khi đã thấy nhiều lỗi tụ vào một giai đoạn, bạn có thể tập trung sức vào tối ưu hóa tìm kiếm, chứng thực hoặc hành vi sinh – thay vì chỉnh đồng thời mọi thứ và không biết cải thiện đến từ đâu. Trong thực tế vận hành, kỷ luật “mỗi lần chỉ đổi một yếu tố, luôn kiểm tra lại trên cùng bộ câu hỏi vàng” là điều phân biệt hệ RAG đáng tin cậy với những demo khó duy trì.