Hướng dẫn: Xây bộ đánh giá (eval) cho ứng dụng LLM, từ 0 đến chạy tự động
Rất nhiều team đưa LLM vào sản phẩm rồi sửa prompt theo cảm tính: thử vài câu thấy ổn là deploy. Đến khi đổi model hay sửa prompt mới phát hiện chỗ khác hỏng. Bài này hướng dẫn xây bộ eval đơn giản nhưng đủ dùng, mình đã áp dụng cho 3 dự án. BƯỚC 1: THU THẬP CA KIỂM TRA - Lấy 50–100 câu hỏi thật từ log người dùng (bỏ thông tin cá nhân). Câu hỏi thật luôn khác câu mình tự nghĩ ra. - Bổ sung các ca khó: câu hỏi mơ hồ, câu hỏi ngoài phạm vi, câu cố tình lừa (prompt injection), câu có số liệu. - Lưu thành file JSON hoặc bảng, mỗi ca gồm: đầu vào, kết quả mong đợi (hoặc tiêu chí), nhãn loại. BƯỚC 2: CHỌN CÁCH CHẤM CHO TỪNG LOẠI CA 1. Kiểm tra cứng (nhanh, rẻ, nên ưu tiên): - Đầu ra đúng định dạng JSON không - Có chứa/không chứa từ khoá bắt buộc - Có từ chối khi câu hỏi ngoài phạm vi không 2. So với đáp án: với câu có đáp án rõ (số liệu, tên), so khớp sau khi chuẩn hoá. 3. Dùng LLM chấm (LLM-as-judge): với câu trả lời mở, viết tiêu chí rõ ràng và yêu cầu chấm đạt/không đạt kèm lý do. Tránh thang 1–10, kết quả rất dao động. BƯỚC 3: KIỂM TRA LẠI GIÁM KHẢO Chấm tay khoảng 30 ca, so với kết quả LLM chấm. Nếu lệch trên 15–20% thì phải sửa tiêu chí chấm trước khi tin con số. BƯỚC 4: TỰ ĐỘNG HOÁ - Viết một script chạy toàn bộ ca, xuất bảng kết quả: tỉ lệ đạt theo từng nhãn, danh sách ca trượt kèm lý do. - Chạy mỗi khi sửa prompt, đổi model, đổi cách lấy dữ liệu (RAG). - Đưa vào CI: nếu tỉ lệ đạt giảm quá 3% so với lần trước thì chặn merge. BƯỚC 5: NUÔI BỘ EVAL Mỗi lỗi người dùng báo về là một ca kiểm tra mới. Sau vài tháng, bộ eval chính là tài sản quý nhất của dự án, quý hơn cả prompt. MẸO - Chạy mỗi ca 2–3 lần với nhiệt độ thấp để phát hiện câu trả lời không ổn định. - Theo dõi cả chi phí và độ trễ trong bảng kết quả, đôi khi prompt "tốt hơn" lại đắt gấp đôi. - Đừng cố đạt 100%: hãy biết rõ mình đang trượt ở loại ca nào và chấp nhận có chủ đích. Ai cần mẫu cấu trúc file ca kiểm tra và script chạy thì bình luận, mình sẽ chia sẻ thêm.