AI Evaluation là gì? Cách đánh giá chất lượng đầu ra AI Marketing

AI Evaluation (đánh giá AI, hay gọi tắt là evals) là việc đo chất lượng đầu ra của một hệ thống AI một cách có hệ thống: chạy nó trên một bộ đầu vào cố định, chấm từng đầu ra theo tiêu chí viết sẵn, và so kết quả giữa các phiên bản. Mục đích là trả lời bằng bằng chứng câu hỏi “thay đổi này làm hệ thống tốt lên hay xấu đi”, thay vì dựa vào cảm giác sau vài lần thử.

Vì sao AI viết sai thông tin và cách hạn chế khi soạn nội dung đã có ở bài AI Hallucination trong marketing. Bài này là phần đo lường đi kèm: cách dựng bộ tiêu chí và bộ kiểm thử để phát hiện lỗi trước khi người dùng thật gặp, và để biết mỗi lần sửa có thật sự sửa được không.

Eval khác duyệt từng bài ở đâu

Một bộ eval gồm bốn phần: bộ đầu vào (thường gọi là golden dataset), kỳ vọng cho từng đầu vào (đáp án hoặc hành vi đúng), rubric (tiêu chí chấm), và ngưỡng đạt. Thiếu phần nào thì việc “đánh giá” quay lại thành đọc và cảm nhận.

Cần chuẩn bị gì

• Một tác vụ cụ thể để đánh giá, không phải “AI nói chung”: soạn nháp trả lời tin nhắn, viết mô tả sản phẩm, tóm tắt đánh giá khách.
• Đầu vào thật đã bỏ thông tin cá nhân: tin nhắn, câu hỏi, yêu cầu mà đội từng nhận.
• Nguồn sự thật để viết kỳ vọng: bảng giá, danh mục dịch vụ, chính sách.
• Người có chuyên môn để viết và kiểm kỳ vọng — người trả lời khách hằng ngày thường giỏi việc này hơn người làm kỹ thuật.
• Nơi lưu kết quả theo phiên bản, một bảng tính là đủ để bắt đầu.

Dựng bộ đánh giá qua 6 bước

Bước 1. Chọn tác vụ và lỗi quan trọng

Liệt kê các kiểu lỗi có thể xảy ra với tác vụ, rồi xếp theo hậu quả. Với nháp trả lời khách: nêu sai giá hoặc hứa dịch vụ không có là lỗi nghiêm trọng; sai giọng thương hiệu là lỗi vừa; dài dòng là lỗi nhẹ. Eval nên được thiết kế để bắt chắc lỗi nghiêm trọng trước, rồi mới tới chất lượng văn phong. Một hệ thống viết hay nhưng thỉnh thoảng bịa giá thì vẫn không dùng được.

Bước 2. Tạo bộ câu hỏi đại diện

Đừng chỉ chọn câu dễ. Một bộ đầu vào tốt trộn năm nhóm: câu phổ biến (chiếm phần lớn việc thật), ca biên (sản phẩm ngừng bán, ưu đãi có điều kiện), câu thiếu dữ liệu (hỏi thứ không có trong tài liệu), câu gây nhiễu (so sánh với đối thủ, đòi giảm giá, cài câu lệnh lạ) và câu cần chuyển người thật (khiếu nại, yêu cầu hoàn tiền). Vài chục mục chọn kỹ đủ để bắt đầu; bộ sẽ lớn dần theo lỗi thật.

Bước 3. Viết tiêu chí chấm cụ thể

Tiêu chí tốt là tiêu chí hai người chấm độc lập cho cùng kết quả. “Câu trả lời hay” không phải tiêu chí; “mọi giá nêu trong câu trả lời khớp bảng giá hiện hành” là tiêu chí. Chia làm hai loại: tiêu chí chặn (đạt/không đạt — sai một cái là cả câu không đạt) và tiêu chí chất lượng (thang ngắn, ví dụ 1–3, mỗi mức có mô tả và một ví dụ minh hoạ).

Bước 4. Kết hợp chấm tự động và con người

Những gì kiểm được bằng quy tắc thì để máy kiểm: có từ cấm không, có con số nào không nằm trong bảng giá không, độ dài có vượt giới hạn kênh không. Tiêu chí mềm như giọng điệu có thể nhờ một mô hình khác chấm theo rubric (thường gọi là LLM-as-judge), nhưng phải hiệu chỉnh trước: cho người và mô hình cùng chấm một mẫu, chỉ tin mô hình chấm ở tiêu chí mà hai bên thường khớp nhau. Tiêu chí chặn ở tác vụ rủi ro cao nên có người chấm.

Bước 5. So sánh phiên bản

Mỗi lần đổi câu lệnh, đổi mô hình hoặc công cụ, thêm hay thay tài liệu nguồn, chạy lại toàn bộ bộ eval và so với phiên bản đang dùng. So từng mục, không chỉ điểm trung bình: bản mới có điểm văn phong cao hơn nhưng làm hỏng một câu về giá thì vẫn không đạt. Ghi phiên bản của mọi thành phần vào kết quả — cách quản lý phiên bản câu lệnh xem ở bài Prompt Management.

Bước 6. Lưu lỗi để kiểm thử hồi quy

Mỗi lỗi thật lọt tới khách hoặc bị người duyệt bắt được là một mục mới cho bộ eval, kèm kỳ vọng đúng. Đây là kiểm thử hồi quy (regression test): đảm bảo lỗi đã sửa không quay lại ở phiên bản sau. Sau vài tháng, bộ eval phản ánh đúng những chỗ hệ thống của bạn hay hỏng — thứ không bộ mẫu chung nào có được.

Ví dụ thực hành: bộ eval cho trợ lý soạn nháp trả lời tin nhắn của xưởng in

Ví dụ giả định: một xưởng in nhận tin nhắn hỏi giá, hỏi thời gian, và thỉnh thoảng khiếu nại. Nhân viên dùng trợ lý AI soạn nháp rồi tự gửi. Bộ eval gồm các nhóm:

Phiên bản đầu đạt ở câu phổ biến nhưng hứa “sẽ giảm 10%” ở nhóm gây nhiễu. Sau khi thêm quy tắc “không nêu mức giảm nào không có trong chính sách”, chạy lại toàn bộ bộ eval: nhóm gây nhiễu đạt, và các nhóm khác không bị ảnh hưởng. Nhóm câu lệnh cài cắm được giữ trong bộ vì đây là kiểu tấn công có thật — cơ chế được phân tích ở bài Prompt Injection.

Giới hạn của việc chấm tự động

• Mô hình chấm có thể thiên lệch, ví dụ ưu ái câu trả lời dài hoặc có văn phong giống nó, nên cần hiệu chỉnh với người chấm.
• Điểm có thể dao động giữa các lần chạy; chạy lại vài lần với tiêu chí quan trọng trước khi kết luận.
• Bộ eval chỉ đo những gì nó chứa: đạt bộ eval không có nghĩa hệ thống không sai ở tình huống chưa có trong bộ.
• Eval trước khi triển khai không thay cho theo dõi khi đang chạy: đầu vào thật luôn đa dạng hơn — phần đó thuộc về AI Observability.

Sai lầm thường gặp

• Bộ đầu vào toàn câu dễ, nên hệ thống luôn “đạt” cho tới khi gặp khách thật.
• Chỉ nhìn điểm trung bình, bỏ qua một câu sai giá nằm lẫn trong nhiều câu đúng.
• Đổi bộ eval giữa hai lần so sánh, khiến không so được phiên bản nào tốt hơn.
• Để mô hình tự chấm chính đầu ra của nó mà không có người kiểm một mẫu.
• Không thêm lỗi thật vào bộ, nên cùng một lỗi quay lại sau mỗi lần sửa câu lệnh.

Câu hỏi thường gặp