Trong ứng dụng dùng mô hình ngôn ngữ lớn, chất lượng không chỉ phụ thuộc vào model. Một thay đổi nhỏ ở prompt, bộ tài liệu RAG, tham số temperature, bộ lọc nội dung hoặc cách hậu xử lý đều có thể làm hệ thống trả lời khác đi. Vấn đề là nhiều nhóm chỉ kiểm tra thủ công vài câu hỏi quen thuộc trước khi phát hành. Cách này nhanh, nhưng dễ bỏ sót lỗi hồi quy: phiên bản mới sửa được một ca, nhưng lại làm hỏng mười ca khác. Một hướng thực tế là xây dựng bộ kiểm thử hồi quy cho LLM. Hiểu đơn giản, đây là tập các tình huống đầu vào quan trọng, được chạy lại mỗi khi hệ thống thay đổi để xem chất lượng có giảm không. Nên bắt đầu từ những ca nào? - Câu hỏi phổ biến của người dùng: ví dụ trong chatbot chăm sóc khách hàng là hỏi chính sách đổi trả, phí vận chuyển, bảo hành. - Câu hỏi dễ gây hiểu nhầm: câu có nhiều điều kiện, câu thiếu ngữ cảnh, câu chứa thuật ngữ nội bộ. - Câu hỏi mà hệ thống từng trả lời sai: đây là nguồn dữ liệu rất giá trị vì nó phản ánh lỗi thực tế. - Ca biên an toàn: yêu cầu tiết lộ thông tin riêng tư, yêu cầu bịa chính sách, yêu cầu vượt quyền. - Ca không có đáp án trong tài liệu: hệ thống nên biết nói “tôi không tìm thấy thông tin phù hợp” thay vì tự suy diễn. Với mỗi ca kiểm thử, không nhất thiết phải viết một đáp án mẫu thật cứng. LLM có thể diễn đạt đúng theo nhiều cách. Thay vào đó, nên lưu các tiêu chí đánh giá rõ ràng, chẳng hạn: - Có trả lời đúng ý chính không? - Có trích đúng nguồn hoặc đúng đoạn tài liệu liên quan không? - Có tránh bịa thông tin ngoài tài liệu không? - Có giữ đúng giọng điệu thương hiệu không? - Có từ chối hợp lý khi yêu cầu không phù hợp không? Ví dụ, với câu hỏi “Sản phẩm đã bóc hộp có được đổi trả không?”, tiêu chí có thể là: phải nêu điều kiện đổi trả, không khẳng định chắc chắn nếu chính sách phụ thuộc vào thời gian mua hàng, và nên hướng người dùng cung cấp mã đơn hoặc liên hệ bộ phận hỗ trợ. Về cách chấm điểm, có thể kết hợp ba lớp. Lớp đầu là kiểm tra tự động đơn giản: câu trả lời có chứa thông tin bắt buộc, có thiếu nguồn tham chiếu, có vượt quá độ dài cho phép không. Lớp thứ hai là đánh giá bằng người cho các ca quan trọng, đặc biệt khi liên quan đến pháp lý, tài chính, y tế hoặc trải nghiệm khách hàng. Lớp thứ ba có thể dùng một mô hình khác làm “người chấm phụ”, nhưng không nên xem đây là chân lý tuyệt đối; kết quả vẫn cần được hiệu chuẩn bằng đánh giá của con người. Một mẹo hữu ích là chia bộ kiểm thử thành nhiều nhóm. Nhóm “smoke test” gồm khoảng vài chục ca quan trọng nhất, chạy nhanh trước mỗi lần triển khai. Nhóm “regression đầy đủ” lớn hơn, chạy theo lịch hoặc trước các bản phát hành lớn. Nhóm “khám phá lỗi” được bổ sung liên tục từ log người dùng, phản hồi của nhân viên hỗ trợ và các tình huống mới phát sinh. Khi lưu kết quả, đừng chỉ lưu điểm tổng. Hãy lưu phiên bản prompt, phiên bản tài liệu, model sử dụng, tham số suy luận, thời điểm chạy và câu trả lời thực tế. Những thông tin này giúp truy vết khi chất lượng giảm: lỗi đến từ prompt mới, tài liệu mới được index, hay model vừa thay đổi? Lời khuyên thực tế: đừng chờ có hệ thống đánh giá hoàn hảo mới bắt đầu. Hãy tạo trước 30 đến 50 ca kiểm thử từ lỗi thật và câu hỏi quan trọng nhất. Mỗi khi phát hiện lỗi mới, thêm nó vào bộ kiểm thử. Sau vài vòng phát hành, bạn sẽ có một “hàng rào an toàn” giúp ứng dụng LLM ổn định hơn nhiều, nhất là trong môi trường sản phẩm liên tục thay đổi.