Khi xây dựng ứng dụng dùng mô hình ngôn ngữ lớn, nhiều nhóm thường thử vài câu hỏi bằng tay rồi kết luận mô hình “ổn”. Cách làm này nhanh, nhưng rất dễ bỏ sót lỗi: trả lời sai trong trường hợp biên, không tuân thủ định dạng, bịa thông tin, hoặc phản hồi khác nhau sau mỗi lần cập nhật prompt. Một hướng thực tế hơn là xây dựng một bộ kiểm thử nhỏ, có thể chạy lặp lại, phản ánh đúng nhu cầu của sản phẩm. Điểm quan trọng là không cần bắt đầu bằng một hệ thống đánh giá quá phức tạp. Với nhiều dự án nội bộ, 50 đến 200 ca kiểm thử được chọn kỹ đã hữu ích hơn rất nhiều so với việc chỉ thử cảm tính. 1. Bắt đầu từ tình huống sử dụng thật Thay vì viết câu hỏi ngẫu nhiên, hãy lấy ví dụ từ hành vi người dùng hoặc quy trình nghiệp vụ. Nếu bạn làm chatbot hỗ trợ nhân sự, bộ kiểm thử nên có các nhóm như: - Hỏi chính sách nghỉ phép. - Hỏi về quy trình thanh toán công tác phí. - Hỏi câu mơ hồ cần yêu cầu làm rõ. - Hỏi ngoài phạm vi, ví dụ xin tư vấn pháp lý cá nhân. - Hỏi bằng ngôn ngữ không chuẩn, viết tắt, sai chính tả. Mỗi ca kiểm thử nên gồm: đầu vào của người dùng, ngữ cảnh nếu có, kết quả mong muốn, và tiêu chí chấm. Không nhất thiết phải có một câu trả lời mẫu duy nhất, vì với LLM có thể có nhiều cách diễn đạt đúng. Quan trọng là xác định rõ điều gì bắt buộc phải có và điều gì không được xuất hiện. 2. Tách tiêu chí đánh giá thành các nhóm dễ kiểm tra Một sai lầm phổ biến là chấm câu trả lời bằng cảm giác chung chung: “hay” hoặc “không hay”. Nên tách thành các tiêu chí cụ thể hơn: - Đúng nội dung: có trả lời dựa trên tài liệu hoặc yêu cầu không? - Không bịa: có thêm thông tin không có trong nguồn không? - Đủ ý: có bỏ sót điều kiện, ngoại lệ, bước quan trọng không? - Đúng định dạng: có trả JSON, bảng, danh sách, hoặc giọng văn theo yêu cầu không? - An toàn: có từ chối hợp lý với câu hỏi ngoài phạm vi hoặc yêu cầu nhạy cảm không? - Hữu ích: có hướng dẫn bước tiếp theo cho người dùng không? Với mỗi tiêu chí, có thể chấm đơn giản theo thang 0/1 hoặc 0/2. Chấm đơn giản nhưng nhất quán thường tốt hơn chấm phức tạp nhưng không ai duy trì được. 3. Kết hợp kiểm tra tự động và kiểm tra thủ công Một số lỗi có thể kiểm tra bằng code: câu trả lời có phải JSON hợp lệ không, có chứa trường bắt buộc không, có vượt quá độ dài không, có trích dẫn ID tài liệu không. Những kiểm tra này nên tự động hóa ngay vì rẻ và ổn định. Tuy nhiên, các tiêu chí như “có bịa không” hoặc “giải thích có dễ hiểu không” thường vẫn cần con người xem xét, đặc biệt ở giai đoạn đầu. Bạn có thể tạo bảng kết quả, mỗi dòng là một ca kiểm thử, mỗi cột là một tiêu chí. Sau vài vòng đánh giá, nhóm sẽ nhìn ra prompt nào hay gây lỗi và loại câu hỏi nào cần bổ sung dữ liệu. 4. Lưu lại phiên bản prompt, mô hình và dữ liệu Khi một câu trả lời thay đổi, bạn cần biết do đâu: đổi prompt, đổi model, đổi tài liệu truy xuất, hay đổi tham số như temperature. Vì vậy, mỗi lần chạy kiểm thử nên lưu ít nhất các thông tin: - Tên và phiên bản mô hình. - Prompt hệ thống và prompt người dùng sau khi render. - Tham số gọi mô hình. - Phiên bản dữ liệu hoặc tài liệu liên quan. - Câu trả lời thô của mô hình. - Điểm đánh giá và ghi chú lỗi. Việc này nghe có vẻ mất công, nhưng sẽ tiết kiệm rất nhiều thời gian khi cần điều tra vì sao chất lượng giảm sau một lần cập nhật. 5. Đừng chỉ kiểm tra câu hỏi “đẹp” Người dùng thật không luôn đặt câu hỏi rõ ràng. Bộ kiểm thử nên có cả các ca khó chịu nhưng thực tế: câu hỏi thiếu thông tin, câu hỏi chứa nhiều ý cùng lúc, câu hỏi yêu cầu làm trái quy định, câu hỏi dùng thuật ngữ nội bộ sai, hoặc câu hỏi mà tài liệu không có đáp án. Một mô hình tốt không chỉ trả lời đúng khi có thông tin, mà còn phải biết nói “tôi chưa có đủ dữ liệu” khi cần. 6. Biến kiểm thử thành thói quen trước mỗi lần phát hành Bộ kiểm thử LLM nên được chạy mỗi khi bạn thay prompt, đổi mô hình, cập nhật tài liệu, hoặc chỉnh logic truy xuất. Nếu chưa có hạ tầng CI/CD, chỉ cần một script đơn giản đọc file CSV hoặc JSONL, gọi mô hình, lưu kết quả và xuất báo cáo là đã đủ để bắt đầu. Lời khuyên thực tế: hãy bắt đầu nhỏ. Chọn 30 câu hỏi quan trọng nhất, viết tiêu chí chấm rõ ràng, chạy thử với prompt hiện tại, ghi lại lỗi. Sau đó cải thiện dần. Một bộ kiểm thử tốt không chỉ giúp chọn mô hình tốt hơn, mà còn giúp cả nhóm hiểu rõ sản phẩm AI đang làm được gì, chưa làm được gì, và rủi ro nằm ở đâu.