Khi làm ứng dụng với mô hình ngôn ngữ lớn, nhiều nhóm thường đánh giá bằng cách nhập vài câu hỏi mẫu, thấy câu trả lời có vẻ ổn rồi chuyển sang triển khai. Cách này nhanh, nhưng rất dễ bỏ sót lỗi: mô hình trả lời sai ở tình huống biên, không tuân thủ định dạng, bịa thông tin, hoặc xử lý kém với dữ liệu tiếng Việt có cách diễn đạt khác nhau. Một bộ đánh giá nội bộ không cần quá phức tạp ngay từ đầu, nhưng nên được xây dựng có hệ thống. Mục tiêu là giúp nhóm trả lời câu hỏi: phiên bản prompt, mô hình, dữ liệu RAG hoặc pipeline mới có thật sự tốt hơn phiên bản cũ không? 1. Bắt đầu từ các ca sử dụng thật Đừng tạo bộ test chỉ từ những câu hỏi lý tưởng. Hãy lấy ví dụ từ: - Log hội thoại đã được ẩn thông tin nhạy cảm. - Câu hỏi thường gặp từ khách hàng hoặc người dùng nội bộ. - Các tình huống từng gây lỗi trong quá khứ. - Câu hỏi ngắn, sai chính tả, thiếu ngữ cảnh, hoặc diễn đạt vòng vo. Ví dụ, nếu bạn làm chatbot hỗ trợ chính sách bảo hành, bộ đánh giá nên có câu hỏi như: “Máy mua 13 tháng rồi còn bảo hành không?”, “Mất hóa đơn thì sao?”, “Sản phẩm bị rơi vỡ có được đổi không?”. Những câu này thực tế hơn nhiều so với câu hỏi quá sạch như: “Vui lòng cho biết điều kiện bảo hành của sản phẩm A”. 2. Chia nhóm lỗi cần kiểm tra Một bộ đánh giá hữu ích nên bao phủ nhiều loại rủi ro, chẳng hạn: - Độ đúng nội dung: câu trả lời có khớp tài liệu hoặc chính sách không? - Khả năng từ chối: mô hình có biết nói “không đủ thông tin” thay vì bịa không? - Tuân thủ định dạng: có trả về đúng JSON, bảng, gạch đầu dòng hoặc schema yêu cầu không? - An toàn và quyền riêng tư: có tiết lộ thông tin nhạy cảm hoặc làm theo yêu cầu không phù hợp không? - Tính nhất quán: cùng một ý hỏi bằng nhiều cách khác nhau có cho kết quả tương đương không? - Trải nghiệm người dùng: câu trả lời có rõ ràng, ngắn gọn, đúng giọng văn sản phẩm không? Việc phân nhóm giúp bạn biết phiên bản mới đang tốt lên ở đâu và tệ đi ở đâu, thay vì chỉ có một nhận xét chung chung là “có vẻ ổn”. 3. Dùng thang điểm đơn giản trước Không nhất thiết phải xây hệ thống chấm điểm phức tạp ngay. Ban đầu có thể dùng thang 0-2: - 0: Sai hoặc không dùng được. - 1: Đúng một phần nhưng thiếu, dài dòng, hoặc cần chỉnh sửa. - 2: Đúng, rõ ràng, có thể dùng được. Với các tác vụ cần định dạng máy đọc, có thể thêm kiểm tra tự động: parse được JSON hay không, có đủ trường bắt buộc không, giá trị có nằm trong danh sách cho phép không. Những kiểm tra này rẻ nhưng bắt được nhiều lỗi thực tế. 4. Luôn so sánh với phiên bản trước Điểm quan trọng không chỉ là mô hình đạt bao nhiêu điểm, mà là nó hơn hay kém phiên bản đang chạy. Mỗi lần đổi prompt, đổi mô hình embedding, cập nhật tài liệu RAG hoặc thêm bước rerank, hãy chạy lại cùng một bộ đánh giá. Một bảng so sánh đơn giản có thể gồm: - Tên phiên bản. - Tỷ lệ câu trả lời đạt yêu cầu. - Số lỗi nghiêm trọng. - Nhóm lỗi tăng hoặc giảm. - Ghi chú các ví dụ đáng chú ý. Cách này giúp tránh tình huống sửa một lỗi nhỏ nhưng làm hỏng nhiều tình huống khác. 5. Đừng để bộ đánh giá bị “học thuộc” Nếu nhóm tối ưu prompt quá lâu trên cùng một tập câu hỏi, hệ thống có thể chỉ tốt trên bộ test đó. Nên tách tối thiểu hai nhóm: - Bộ kiểm tra thường xuyên: dùng sau mỗi lần thay đổi. - Bộ kiểm tra ẩn hoặc ít dùng: dùng trước khi phát hành phiên bản quan trọng. Ngoài ra, hãy định kỳ bổ sung câu hỏi mới từ thực tế vận hành. Ứng dụng LLM thường thay đổi theo sản phẩm, tài liệu, hành vi người dùng và cả cách người dùng cố tình thử giới hạn hệ thống. 6. Kết hợp người chấm và công cụ tự động Một số tiêu chí có thể tự động hóa, như định dạng, độ dài, có trích dẫn nguồn hay không. Nhưng các tiêu chí như “câu trả lời có thật sự hữu ích không” hoặc “giọng văn có phù hợp không” vẫn cần con người đánh giá, ít nhất trong giai đoạn đầu. Nếu dùng một LLM khác để chấm, nên cẩn thận: nó có thể chấm không ổn định hoặc bỏ qua lỗi tinh vi. Cách tốt hơn là dùng LLM làm trợ lý gợi ý điểm, còn các ca quan trọng vẫn cần người duyệt mẫu. Lời khuyên thực tế để bắt đầu - Bắt đầu với 50-100 câu hỏi thật, không cần chờ bộ test hoàn hảo. - Ghi rõ đáp án mong muốn hoặc tiêu chí chấm cho từng câu. - Lưu lại output của từng phiên bản để so sánh. - Đánh dấu lỗi nghiêm trọng riêng, ví dụ bịa chính sách, lộ dữ liệu, tư vấn sai quy trình. - Chạy đánh giá như một bước bắt buộc trước khi triển khai. Kết luận Với ứng dụng LLM, cảm giác “trả lời nghe hay” không đủ để đảm bảo chất lượng. Một bộ đánh giá nội bộ, dù nhỏ, giúp nhóm ra quyết định dựa trên bằng chứng hơn là ấn tượng. Bắt đầu đơn giản, dùng câu hỏi thực tế, đo lỗi theo nhóm và so sánh qua từng phiên bản là những bước rất thực dụng để xây dựng sản phẩm AI đáng tin cậy hơn.