Đo hallucination cho RAG: cùng tên faithfulness chưa chắc cùng cách chấm

Để biết câu trả lời RAG có tạo thông tin thiếu bằng chứng hay không, hãy giữ nguyên câu hỏi, câu trả lời thực tế và những đoạn tài liệu đã truy xuất, rồi xét từng mệnh đề của câu trả lời dựa trên các đoạn ấy. Một chi tiết nghe hợp lý vẫn cần được ghi nhận nếu ngữ cảnh không hỗ trợ nó.

Faithfulness giúp lượng hóa phép kiểm tra này, nhưng điểm của Ragas và DeepEval không tự động tương đương. Hai bộ chấm có thể nhận cùng dữ liệu mà áp dụng tiêu chí khác nhau cho một mệnh đề thiếu bằng chứng. Vì vậy, hãy cố định bộ dữ liệu trước khi chọn metric, đồng thời lưu cả quy tắc và cấu hình chấm bên cạnh điểm số.

Tạo một fixture giữ nguyên đầu vào RAG

Một trường hợp kiểm thử cần có câu hỏi của người dùng, câu trả lời mà hệ thống đã sinh và danh sách các đoạn truy xuất được đưa vào lần sinh câu trả lời đó. Lưu nguyên văn từng đoạn cùng thứ tự, mã tài liệu và phiên bản kho dữ liệu. Nếu chạy lại bộ truy xuất để chấm một câu trả lời cũ, ngữ cảnh có thể đã đổi và kết quả không còn phản ánh cùng một trường hợp.

Fixture giả định sau dùng chính sách đổi hàng làm dữ liệu kiểm thử; các điều kiện nêu trong đó không mô tả một cửa hàng có thật:

• Câu hỏi: “Tôi cần gì để đổi sản phẩm và có thể liên hệ qua điện thoại không?”
• Câu trả lời thực tế: “Bạn có thể đổi sản phẩm trong 7 ngày kể từ khi nhận hàng, cần có hóa đơn và được hỗ trợ qua điện thoại.”
• Ngữ cảnh truy xuất: “Khách hàng có thể đổi sản phẩm trong 7 ngày kể từ ngày nhận hàng. Việc đổi sản phẩm cần có hóa đơn.”

Nếu tách câu trả lời thành ba mệnh đề, điều kiện về thời hạn và hóa đơn đều được đoạn truy xuất hỗ trợ. Chi tiết hỗ trợ qua điện thoại không có bằng chứng trong đoạn này, dù đoạn văn cũng không phủ định nó. Cách phân biệt giữa “có thể suy ra từ ngữ cảnh” và “không mâu thuẫn với ngữ cảnh” sẽ quyết định cách đọc kết quả.

Có thể bổ sung vào bộ kiểm thử một câu trả lời trái trực tiếp với tài liệu, một câu chỉ trả lời được một phần câu hỏi và một câu từ chối khi tài liệu không đủ dữ kiện. Mỗi trường hợp nên giữ đầu ra thực tế thay vì viết lại cho gọn: sửa một từ phủ định hoặc một điều kiện thời gian cũng có thể đổi mệnh đề cần chấm.

Ragas chấm mệnh đề được ngữ cảnh hỗ trợ

Tài liệu Faithfulness của Ragas định nghĩa điểm bằng số mệnh đề trong câu trả lời được ngữ cảnh truy xuất hỗ trợ chia cho tổng số mệnh đề; từng mệnh đề được xét xem có thể suy ra từ ngữ cảnh hay không. Ví dụ API collections truyền user_input, response và retrieved_contexts cho phương thức ascore hoặc score, rồi đọc điểm từ result.value.

Với fixture trên, ánh xạ câu hỏi vào user_input, câu trả lời vào response và danh sách đoạn truy xuất vào retrieved_contexts. Giữ các đoạn ở dạng danh sách như dữ liệu đã lưu; việc ghép hoặc viết lại chúng trước khi chấm sẽ thay đổi bằng chứng mà hệ thống đánh giá nhận được. Mô hình dùng để tách và xét mệnh đề cũng là một phần cấu hình của phép đo.

Theo cách tách thủ công đã nêu, hai trong ba mệnh đề có bằng chứng, còn mệnh đề về điện thoại thì không. Tỷ lệ thủ công ấy chỉ giúp nhận ra điều cần xem trong kết quả: bộ chấm có thể tách câu trả lời thành các mệnh đề khác và đưa ra điểm khác. Khi điểm gây ngạc nhiên, số mệnh đề được trích ra quan trọng không kém con số cuối cùng.

DeepEval nhận cùng fixture nhưng dùng tiêu chí khác

Tài liệu Faithfulness của DeepEval yêu cầu input, actual_output và retrieval_context trong LLMTestCase. Ở chế độ llm, bộ chấm trích các mệnh đề từ actual_output và tính tỷ lệ mệnh đề được phân loại là đúng; tài liệu mô tả một mệnh đề là đúng nếu nó không mâu thuẫn với các dữ kiện trong retrieval_context. Metric còn có các chế độ hybrid và system_one; chế độ system_one tổng hợp các đánh giá theo trọng số thay cho phép đếm mệnh đề của chế độ llm.

Đưa câu hỏi của fixture vào input, câu trả lời đã lưu vào actual_output và cùng danh sách đoạn truy xuất vào retrieval_context. Sau khi tạo FaithfulnessMetric và gọi measure với test case, lưu metric.score cùng metric.reason nếu đã bật lời giải thích. Ghi rõ eval_mode: đổi chế độ có thể đổi cả người ra phán đoán lẫn cách tạo điểm, dù tên metric và đầu vào vẫn giữ nguyên.

Chi tiết “được hỗ trợ qua điện thoại” là phép thử hữu ích vì nó thiếu bằng chứng nhưng không trái trực tiếp với đoạn ngữ cảnh. Theo tiêu chí mô tả cho chế độ llm, trường hợp này có thể được xử lý khác với tiêu chí đòi hỏi suy ra được từ ngữ cảnh. Đó là khác biệt về định nghĩa cần lưu ý, không phải dự đoán rằng một lần chạy cụ thể chắc chắn cho điểm nào: việc trích mệnh đề và phán đoán còn phụ thuộc mô hình đánh giá.

DeepEval cho phép đặt threshold khi tạo metric hoặc dùng threshold=None nếu chỉ cần điểm. Bật strict_mode sẽ biến điểm thành kết quả tuyệt đối và đặt ngưỡng đạt ở mức tuyệt đối. Các tùy chọn như mô hình chấm, eval_mode, giới hạn trích dữ kiện từ ngữ cảnh và mẫu đánh giá tùy chỉnh cần được giữ cố định khi đối chiếu những lần chạy của chính metric đó.

Đặt ngưỡng và tách trường hợp không thể chấm

Ngưỡng đạt nên xuất phát từ mức sai sót ứng dụng chấp nhận. Trước khi chọn ngưỡng, hãy đối chiếu một tập câu trả lời với nhãn do người đánh giá gán từ chính các đoạn truy xuất, rồi xem riêng mệnh đề thiếu bằng chứng và mệnh đề mâu thuẫn. Với Ragas, có thể áp dụng ngưỡng của bộ kiểm thử lên result.value; khi báo cáo tỷ lệ đạt, ghi kèm ngưỡng thay vì chỉ công bố tỷ lệ.

Chỉ so tỷ lệ đạt giữa những lần chạy có cùng fixture, cùng ngưỡng và cùng cấu hình evaluator. Ngay cả khi đặt một ngưỡng có cùng giá trị cho hai framework, điều đó không khiến hai tiêu chí chấm trở thành một. Nếu cần đối chiếu chúng, hãy xem những trường hợp bị phân loại khác nhau và mệnh đề nào tạo ra chênh lệch.

Câu trả lời rỗng hoặc không có mệnh đề kiểm chứng được khiến phép chia theo tổng số mệnh đề không có mẫu số hữu ích. Nên gắn trạng thái “không có mệnh đề để chấm” ở tầng kiểm thử trước khi diễn giải điểm do thư viện trả về; không tự xem việc thiếu phát biểu sai là bằng chứng cho một câu trả lời tốt. Tương tự, ngữ cảnh truy xuất rỗng cần có trạng thái riêng để phân biệt lỗi thiếu đầu vào với phán đoán về câu trả lời.

Lưu phiên bản để lần ra nguyên nhân điểm đổi

Mỗi bản ghi nên chứa mã fixture, nguyên văn ba phần đầu vào, mã và thứ tự các đoạn truy xuất, phiên bản kho tài liệu, phiên bản framework, tên metric, chế độ chấm, mô hình đánh giá, ngưỡng, điểm và lời giải thích nếu có. Nếu dùng prompt hoặc mẫu đánh giá tùy chỉnh, lưu phiên bản của chúng. Khi một điểm thay đổi, bản ghi này cho phép xác định liệu câu trả lời, bằng chứng hay evaluator đã đổi.

Faithfulness đo sự bám sát ngữ cảnh được đưa vào phép chấm. Một câu trả lời có thể nhất quán với những đoạn đã truy xuất mà vẫn bỏ sót phần cần thiết để đáp ứng câu hỏi. Khi phân tích một trường hợp thất bại, hãy đặt mệnh đề của câu trả lời cạnh từng đoạn bằng chứng đã lưu: điểm tổng hợp không tự chỉ ra vấn đề nằm ở truy xuất hay ở khâu tạo câu trả lời.

Đọc thêm:

• RAG hay fine-tuning: dữ liệu đổi nhanh khiến lựa chọn lệch hẳn
• GitHub sắp siết SSH: khóa RSA cũ chưa chắc phải tạo lại
• Mistral Agentic Search: khi RAG một lượt không đủ bằng chứng