Bắt đầu chẩn đoán RAG từ tìm kiếm, không phải từ model
Chẩn đoán lỗi RAG (tìm kiếm tăng cường) là quá trình phân tách hệ thống thành các giai đoạn nhỏ – tìm kiếm, tăng cường và sinh – rồi dùng bộ câu hỏi chuẩn cùng các chỉ số RAG chuyên biệt để xác định chính xác điểm bắt đầu của lỗi thay vì đổ chung mọi sai sót cho mô hình ngôn ngữ lớn. Khi câu trả lời sai, phản xạ phổ biến là đổi model, sửa prompt hoặc nghĩ tới khắc phục LLM bằng fine‑tuning, nhưng đó thường là hướng đi sai thứ tự. Nếu đoạn văn chứa đáp án còn chưa xuất hiện trong top kết quả tìm kiếm thì không có mô hình nào “tự bịa” được đúng trên dữ liệu nội bộ của bạn. Nói ngắn gọn: “RAG lỗi chẩn đoán” có nghĩa là phải hỏi lại từng bước pipeline trước khi kết luận model yếu.
Điểm then chốt là tách ba giai đoạn: tìm kiếm tài liệu, tăng cường ngữ cảnh và sinh câu trả lời. Cùng một câu trả lời sai có thể đến từ ba nguyên nhân rất khác: tài liệu đúng không được tìm, tài liệu đúng bị loại ở bước tăng cường, hoặc model diễn giải sai dù đã có đủ căn cứ. Nếu bạn gom tất cả thành một điểm số tổng, bạn chỉ biết hệ thống “kém”, chứ không biết phải chỉnh ở đâu. Đó là lý do mọi chiến lược khắc phục LLM hiệu quả đều bắt đầu bằng việc phân rã pipeline RAG và đọc log chi tiết thay vì xem mỗi output cuối cùng.
Bốn chỉ số RAG để biết lỗi nằm ở đâu trong pipeline
Muốn chẩn đoán có hệ thống, bạn cần bộ chỉ số RAG tách bạch thay vì một điểm tổng hợp. Bốn trụ cột cần theo dõi song song là: (1) Tỷ lệ tìm kiếm trúng căn cứ; (2) Độ “trung thành” của câu trả lời với ngữ cảnh đã cung cấp; (3) Độ chính xác của đáp án so với “golden answer”; (4) Mức độ khớp giữa câu trích dẫn và căn cứ thật trong tài liệu. Những chỉ số này không thay thế lẫn nhau mà chỉ có ý nghĩa khi được nhìn chung trong từng câu hỏi cụ thể.
Cách đọc chỉ số cũng quan trọng không kém. Nếu tỷ lệ tìm kiếm cao nhưng độ chính xác thấp, nhiều khả năng vấn đề nằm ở cấu hình tăng cường hoặc cách bạn yêu cầu model dùng ngữ cảnh. Nếu đáp án đúng nhưng độ trung thành thấp, model đã dựa vào kiến thức ngoài ngữ cảnh, tạo ra rủi ro kiểm chứng. Nếu trích dẫn không khớp, lỗi có thể nằm ở logic nối câu trả lời với ID tài liệu chứ không phải ở chính nội dung sinh. Nói cách khác, mỗi mẫu lỗi sẽ vẽ ra một “đường mòn” sửa lỗi khác nhau, giúp bạn tránh phải chỉnh toàn bộ hệ thống.
Theo hướng dẫn đánh giá tự động như trong nghiên cứu Ragas, chất lượng RAG nên được chia thành các chiều độc lập: liên quan của ngữ cảnh, sự tập trung của ngữ cảnh, tính căn cứ của câu trả lời và chất lượng sinh. Đây là cơ sở lý thuyết vững để bạn xây ma trận chỉ số và không bị cám dỗ bởi một con số “điểm RAG” mơ hồ.
Dùng 20–30 câu hỏi vàng để mổ xẻ lỗi theo ba giai đoạn
Thay vì xây cả bộ benchmark hoành tráng rồi bị choáng ngợp, bạn có thể bắt đầu RAG lỗi chẩn đoán bằng 20–30 câu hỏi vàng sát với nghiệp vụ thật. Mỗi câu nên có: đáp án chuẩn, các đoạn tài liệu phải xuất hiện, loại câu hỏi (một sự thật, nhiều tài liệu, câu hỏi mơ hồ, câu hỏi không có đáp án trong kho tri thức) và ghi chú về số lượng căn cứ cần thiết. Nguyên tắc ở đây là đủ đa dạng để “bóc” được nhiều dạng lỗi khác nhau, nhưng đủ ít để đội ngũ có thể đọc log và chấm tay.
Với từng câu hỏi vàng, bạn lưu trữ đầy đủ: câu hỏi thô, truy vấn được chuyển đổi để tìm kiếm, top K kết quả và điểm số, kết quả sau tái xếp hạng, đoạn ngữ cảnh cuối cùng đưa vào model, câu trả lời sinh ra và phần trích dẫn. Sau đó bạn đánh dấu rõ “giai đoạn đầu tiên” mà lỗi xuất hiện: không tìm thấy căn cứ, căn cứ bị loại ở bước tăng cường, hay model giải sai. Chính danh sách này sẽ cho thấy bạn nên ưu tiên chỉnh gì: pipeline thu thập–chia nhỏ–lọc tài liệu, chiến lược tăng cường ngữ cảnh, hay khắc phục LLM bằng cách chỉnh prompt, đổi model hoặc xem xét fine‑tuning.
Phân loại lỗi: tìm kiếm, tăng cường, hay sinh – mỗi loại sửa một kiểu
Lợi ích lớn nhất của cách tiếp cận này là bạn buộc mình phải phân biệt lỗi tri thức với lỗi hành vi. Nếu tài liệu đúng không lọt vào top kết quả, bạn cần xem lại quy trình thu thập tài liệu, cách chia nhỏ, bộ lọc metadata, chiến lược truy vấn và kỹ thuật tìm kiếm hoặc tái xếp hạng. Nếu tài liệu đúng đã được tìm nhưng biến mất khỏi ngữ cảnh cuối cùng, thủ phạm thường nằm ở bước loại trùng, giới hạn dung lượng ngữ cảnh, hoặc cách bạn sắp xếp thứ tự đoạn văn. Trong các câu hỏi phức tạp, việc trùng lặp nhiều đoạn gần giống nhau có thể khiến căn cứ quan trọng ở tài liệu khác bị đẩy ra ngoài.
Khi tất cả căn cứ quan trọng đều đã có mặt trong ngữ cảnh mà câu trả lời vẫn sai, lúc đó mới hợp lý để bàn đến khắc phục LLM: chỉnh lại chỉ dẫn “phải dựa trên tài liệu”, quy tắc xử lý căn cứ mâu thuẫn, bảo toàn điều kiện và đơn vị, hoặc yêu cầu model thừa nhận thiếu căn cứ thay vì phỏng đoán. Nếu bạn dùng kết hợp RAG và fine‑tuning, lại càng cần tách riêng: RAG lo tri thức và nguồn, còn model đã fine‑tune chịu trách nhiệm về cách trình bày và hành vi. “Google Cloud khuyến nghị đánh giá riêng độ chính xác tìm kiếm và chất lượng ngữ cảnh trước khi thay đổi model sinh”, vì nếu không, bạn dễ dùng fine‑tuning để che lỗi tìm kiếm chứ không phải sửa tận gốc.
Kết luận: đo đúng để sửa đúng, đừng đốt thời gian đổi model vô ích
Nếu chỉ nhìn vào câu trả lời cuối cùng, bạn gần như chắc chắn sẽ chẩn đoán sai phần lớn lỗi RAG. Cùng một output sai nhưng có thể phải dùng ba chiến lược khắc phục khác nhau: tối ưu tìm kiếm tăng cường, tinh chỉnh chiến lược tăng cường ngữ cảnh, hoặc khắc phục LLM bằng prompt và fine‑tuning. Bộ 20–30 câu hỏi vàng với bốn chỉ số RAG tách biệt cho bạn một “bàn mổ” rõ ràng: mỗi ca lỗi đều được gắn nhãn giai đoạn đầu tiên thất bại. Từ đó, mọi thay đổi đều có thể kiểm chứng bằng cùng một bộ câu hỏi, giống như một bộ test hồi quy cho hệ hỏi đáp nội bộ.
Cách làm này không hứa hẹn một con số “độ chính xác” hào nhoáng, mà cho bạn một quy trình chẩn đoán lặp lại được. Nó buộc nhóm vận hành không trông chờ vào model thần kỳ, mà đối mặt với những chi tiết nhàm chán như log truy vấn, cấu hình chia nhỏ tài liệu và quy tắc trích dẫn. Đổi lại, bạn có một hệ thống RAG biết mình đang sai ở đâu và cho phép sửa đúng chỗ – điều kiện tiên quyết để bất kỳ cải tiến nào thực sự bền vững.
