Khi làm ứng dụng dùng mô hình ngôn ngữ lớn, nhiều nhóm thường kiểm tra bằng cách gõ vài câu hỏi quen thuộc, thấy mô hình trả lời ổn rồi triển khai. Cách này nhanh, nhưng rất dễ bỏ sót lỗi: trả lời sai ở trường hợp biên, không tuân thủ định dạng, tiết lộ thông tin không nên nói, hoặc suy luận quá tự tin khi thiếu dữ liệu. Một bộ kiểm thử nhỏ nhưng có cấu trúc sẽ giúp bạn phát hiện vấn đề sớm hơn, đặc biệt khi thay prompt, đổi mô hình, cập nhật dữ liệu RAG hoặc chỉnh tham số sinh câu trả lời. 1. Bắt đầu từ các tình huống người dùng thật Đừng viết test chỉ theo tưởng tượng của đội kỹ thuật. Hãy lấy ví dụ từ log, câu hỏi của khách hàng, ticket hỗ trợ, cuộc hội thoại bán hàng hoặc tài liệu nghiệp vụ. Mỗi test case nên có: - Đầu vào của người dùng - Ngữ cảnh kèm theo nếu có, ví dụ tài liệu truy xuất từ RAG - Kỳ vọng đầu ra ở mức đủ rõ - Loại lỗi cần tránh Ví dụ với chatbot nội bộ về chính sách nghỉ phép: - Câu hỏi: “Nhân viên thử việc có được nghỉ phép năm không?” - Kỳ vọng: trả lời dựa trên chính sách hiện hành, nếu tài liệu không nêu thì phải nói chưa đủ thông tin - Lỗi cần tránh: tự bịa số ngày nghỉ hoặc khẳng định chắc chắn khi không có nguồn 2. Chia test theo nhóm lỗi Một bộ kiểm thử tốt không chỉ gồm các câu hỏi “bình thường”. Nên có nhiều nhóm khác nhau: - Câu hỏi phổ biến: những việc người dùng hỏi thường xuyên - Câu hỏi mơ hồ: thiếu thông tin, cần hỏi lại - Câu hỏi ngoài phạm vi: mô hình phải từ chối hoặc chuyển hướng phù hợp - Câu hỏi dễ gây bịa: yêu cầu số liệu, chính sách, điều khoản cụ thể - Câu hỏi kiểm tra định dạng: JSON, bảng, danh sách bước, email mẫu - Câu hỏi an toàn: yêu cầu lộ dữ liệu nhạy cảm, bỏ qua quy định, làm việc không phù hợp Với ứng dụng RAG, nên thêm nhóm test cho truy xuất tài liệu: câu hỏi có tài liệu đúng, câu hỏi không có tài liệu, và câu hỏi có tài liệu gần đúng nhưng dễ gây nhầm. 3. Đừng chỉ chấm “đúng/sai” quá chung chung LLM thường không có một đáp án duy nhất, nên tiêu chí đánh giá cần cụ thể. Thay vì ghi “trả lời tốt”, hãy chấm theo các tiêu chí như: - Đúng thông tin chính không? - Có bịa thêm chi tiết không? - Có nói rõ khi thiếu dữ liệu không? - Có tuân thủ giọng văn và định dạng không? - Có trích dẫn hoặc nhắc nguồn đúng nếu hệ thống yêu cầu không? Ban đầu có thể chấm thủ công bằng thang đơn giản: đạt, chưa đạt, cần xem lại. Khi bộ test lớn hơn, bạn có thể kết hợp đánh giá tự động cho các phần dễ kiểm tra như định dạng JSON hợp lệ, có chứa trường bắt buộc, không vượt quá độ dài, không xuất hiện cụm từ bị cấm. 4. Giữ lại các lỗi đã từng xảy ra Mỗi lần người dùng báo lỗi, đừng chỉ sửa prompt rồi quên. Hãy biến lỗi đó thành một test case mới. Đây là cách xây “bộ nhớ chất lượng” cho sản phẩm. Ví dụ, nếu chatbot từng trả lời sai về phí hoàn tiền vì nhầm giữa khách hàng cá nhân và doanh nghiệp, hãy thêm ít nhất hai test: - Một câu cho khách hàng cá nhân - Một câu cho khách hàng doanh nghiệp Sau này khi đổi mô hình hoặc cập nhật tài liệu, bạn có thể kiểm tra xem lỗi cũ có tái xuất hiện không. 5. Chạy test trước mỗi thay đổi quan trọng Bộ kiểm thử chỉ có giá trị nếu được dùng thường xuyên. Nên chạy lại khi: - Thay prompt hệ thống - Đổi mô hình hoặc phiên bản mô hình - Cập nhật tài liệu trong hệ thống RAG - Thay cách chunking, embedding hoặc reranking - Thêm tính năng gọi công cụ, truy vấn cơ sở dữ liệu, gửi email, tạo đơn hàng Không nhất thiết phải có hệ thống phức tạp ngay từ đầu. Một bảng tính với 50-100 test case quan trọng cũng đã tốt hơn rất nhiều so với việc thử thủ công ngẫu nhiên. 6. Lời khuyên thực tế khi bắt đầu Nếu bạn đang xây ứng dụng LLM, hãy bắt đầu bằng một bộ test nhỏ: - 20 câu hỏi phổ biến nhất - 10 câu hỏi ngoài phạm vi - 10 câu dễ gây bịa thông tin - 10 câu kiểm tra định dạng hoặc quy trình nghiệp vụ Sau đó, mỗi tuần bổ sung thêm test từ lỗi thực tế. Mục tiêu không phải là chứng minh mô hình “thông minh”, mà là biết rõ hệ thống đang đáng tin ở đâu, yếu ở đâu, và thay đổi nào làm chất lượng tốt lên hay tệ đi. Trong dự án AI thực tế, chất lượng không đến từ một prompt hay một mô hình duy nhất. Nó đến từ quy trình lặp lại: kiểm thử, phát hiện lỗi, sửa có kiểm soát và đo lại. Một bộ kiểm thử LLM được chăm sóc tốt sẽ giúp đội phát triển tự tin hơn rất nhiều khi đưa sản phẩm đến người dùng thật.