Your AI Product Needs Evals: khung 3 tầng đánh giá của Hamel Husain
Tóm tắt
Hamel Husain cho rằng hầu hết sản phẩm AI thất bại vì thiếu hệ thống đánh giá. Khung ba tầng: assertion rẻ cho mọi thay đổi, đánh giá bởi người và LLM judge đã hiệu chỉnh, rồi A/B test; và trên hết là thường xuyên đọc trace thật.
Nhiều sản phẩm AI kẹt ở cùng một chỗ: demo ấn tượng, nhưng mỗi lần sửa prompt lại hỏng thứ khác, và team không biết mình đang tiến hay lùi. Hamel Husain, người đã tư vấn cho nhiều công ty xây sản phẩm LLM, viết bài "Your AI Product Needs Evals" với luận điểm thẳng thắn: nguyên nhân gốc của hầu hết sản phẩm AI thất bại là không có hệ thống đánh giá. Bài này tóm tắt khung ba tầng eval và các bài học thực chiến.
Câu chuyện: Lucy, trợ lý bất động sản
Bài viết dùng ví dụ Lucy, trợ lý AI cho phần mềm bất động sản Rechat. Giai đoạn đầu tiến nhanh bằng prompt engineering, rồi chững lại: sửa một tính năng làm hỏng tính năng khác, không ai nắm được chất lượng tổng thể. Việc dựng eval một cách có hệ thống đã mở khoá tiến độ trở lại.
Ba tầng eval
| Tầng | Là gì | Chạy khi nào |
|---|---|---|
| 1. Unit test (assertion) | Kiểm tra tự động, rẻ, nhanh: output có đúng định dạng, không lộ ID nội bộ, có trường bắt buộc… | Mỗi lần đổi code hoặc prompt |
| 2. Đánh giá bởi người và model | Ghi lại trace, xem dữ liệu thật, dùng LLM judge được hiệu chỉnh khớp với người chấm | Định kỳ, theo nhịp phát triển |
| 3. A/B test | Đo tác động thật lên hành vi người dùng | Khi sản phẩm đủ trưởng thành |
Bài học đáng nhớ nhất
- Hãy nhìn dữ liệu của bạn: đọc trace thật là việc giá trị nhất mà nhiều team bỏ qua. Lỗi thật thường khác xa lỗi bạn tưởng tượng.
- Xoá ma sát khi xem dữ liệu: dựng công cụ xem trace thật dễ dùng; nếu xem dữ liệu khó, sẽ không ai xem.
- Unit test đặc thù theo lĩnh vực: viết assertion từ các lỗi đã gặp, giống regression test.
- Hiệu chỉnh giám khảo LLM: đo mức đồng thuận giữa LLM judge và người chấm, lặp lại cho tới khi đủ tin.
- Eval mở khoá mọi thứ khác: có eval rồi, việc debug, so sánh model, thậm chí fine-tune đều trở nên khả thi.
Bắt đầu từ đâu?
- Ghi log đầy đủ mọi lượt tương tác (input, output, tool call).
- Đọc 50–100 trace, ghi lại các kiểu lỗi.
- Viết assertion cho các lỗi lặp lại và đưa vào CI.
- Với lỗi khó kiểm bằng code, thêm LLM judge, hiệu chỉnh với vài chục mẫu người chấm.
Rủi ro và lưu ý
- Dùng benchmark chung chung: điểm trên bộ test công khai ít nói lên chất lượng trên tác vụ của bạn.
- Mua công cụ trước khi hiểu lỗi: công cụ eval không thay được việc tự đọc dữ liệu.
- Eval "chết": bộ test không cập nhật theo lỗi mới sẽ cho cảm giác an toàn giả.
Áp dụng thế nào?
- Dev: Mỗi bug AI tìm được, viết thành một assertion trước khi sửa prompt.
- Tech Lead: Dành thời gian cố định mỗi tuần cho cả team đọc trace; dựng trang xem trace nội bộ đơn giản.
- PM: Định nghĩa tiêu chí "tốt" bằng ví dụ cụ thể; đó là nguyên liệu cho cả assertion lẫn LLM judge.
Nguồn & tham khảo
- Your AI Product Needs Evals — Hamel Husain