Vì sao online eval quan trọng
Offline eval trả lời câu hỏi "mô hình có đạt tiêu chí trong phòng thí nghiệm không". Online eval trả lời câu hỏi quan trọng hơn: "người dùng thật có thấy nó tốt hơn không". Hai câu này khác nhau. Một bản trả lời đúng dữ kiện hơn nhưng dài dòng có thể khiến người dùng bỏ đi. Chỉ online eval, đo trên hành vi thật, mới nói lên sự thật cuối cùng.
Thiếu kỹ năng online eval, cái giá là bạn tối ưu nhầm mục tiêu. Bạn tự hào vì điểm rubric tăng, nhưng tỉ lệ khách quay lại giảm mà không hiểu vì sao. Bạn không có cơ chế thu phản hồi người dùng, nên mọi quyết định cải thiện đều dựa vào phỏng đoán nội bộ. Tệ hơn, bạn ship một bản mới cho toàn bộ người dùng cùng lúc, nó tệ hơn thật, và bạn không có nhóm đối chứng để phát hiện kịp. Doanh thu tụt và bạn không biết đổ lỗi cho đâu.
Hai công cụ chính của online eval là A/B testing để so hai phiên bản trên người dùng thật, và human feedback để thu tín hiệu trực tiếp như nút thích, sao, hay báo lỗi.
Bức tranh lớn
graph TD A[Chia nguoi dung thanh hai nhom] --> B[Nhom A dung ban cu] A --> C[Nhom B dung ban moi] B --> D[Do chi so hanh vi] C --> D D --> E[So sanh co y nghia thong ke] E --> F[Thu them phan hoi truc tiep] F --> G[Quyet dinh trien khai rong hay dung]
Ý tưởng cốt lõi là bạn không tin lời khen của chính mình mà để dữ liệu hành vi phán xử. A/B testing chia ngẫu nhiên người dùng thành nhóm đối chứng và nhóm thử nghiệm, sau đó so các chỉ số như tỉ lệ hoàn thành, độ dài phiên, hay tỉ lệ báo lỗi. Human feedback bổ sung tín hiệu chất lượng mềm mà chỉ số hành vi không bắt được. Kết hợp cả hai cho bức tranh đầy đủ.
Ví dụ chi tiết
Một nền tảng chăm sóc khách hàng ở Đà Nẵng dùng LLM để soạn nháp trả lời cho nhân viên tổng đài.
Bước 1: Đội có một bản prompt mới hứa hẹn trả lời ngắn gọn hơn. Offline eval cho điểm cao hơn. Nhưng họ không ship thẳng.
Bước 2: Họ bật A/B test. Một nửa nhân viên nhận nháp từ bản cũ, một nửa nhận từ bản mới, chia ngẫu nhiên.
Bước 3: Họ chọn chỉ số chính là tỉ lệ nhân viên chấp nhận nháp mà không sửa, và chỉ số phụ là thời gian xử lý mỗi ca.
Bước 4: Sau một tuần, bản mới có tỉ lệ chấp nhận thấp hơn 8 điểm phần trăm. Hóa ra ngắn gọn quá làm thiếu thông tin, nhân viên phải viết thêm.
Bước 5: Đội thu thêm human feedback bằng nút "nháp này có ích không". Bình luận cho thấy nhân viên muốn giữ phần hướng dẫn bước tiếp theo.
Bước 6: Họ chỉnh prompt để ngắn gọn nhưng vẫn giữ hướng dẫn, chạy A/B lần hai. Lần này bản mới thắng rõ ở cả hai chỉ số, và họ mới triển khai rộng.
Bài học: offline eval gợi ý, nhưng online eval mới quyết định. Nếu ship thẳng theo offline, họ đã làm chậm cả tổng đài.
Lộ trình từng bước để làm chủ
graph LR A[Chon chi so chinh ro rang] --> B[Thiet ke chia nhom ngau nhien] B --> C[Chay du lau de du mau] C --> D[Kiem tra y nghia thong ke] D --> E[Thu phan hoi truc tiep nguoi dung] E --> F[Ket luan va trien khai dan] F --> G[Theo doi sau khi ship]
Bắt đầu bằng chọn một chỉ số chính duy nhất phản ánh giá trị thật, tránh chọn quá nhiều. Thiết kế chia nhóm ngẫu nhiên để công bằng. Chạy đủ lâu để có đủ mẫu tin cậy. Kiểm tra ý nghĩa thống kê để không kết luận từ nhiễu. Thu thêm phản hồi trực tiếp cho sắc thái. Triển khai dần theo tỉ lệ và tiếp tục theo dõi sau khi ship.
Thói quen & kỷ luật
| Nhịp | Thói quen |
|---|---|
| Mỗi thử nghiệm | Viết trước giả thuyết và chỉ số quyết định |
| Hằng ngày trong test | Kiểm tra sức khỏe test, tránh rò rỉ nhóm |
| Cuối mỗi test | Ghi kết luận và bài học vào nhật ký thử nghiệm |
| Hằng tuần | Đọc mẫu phản hồi người dùng để cảm nhận thực tế |
Cần luyện tập gì (drills)
Drill 1: Viết một tài liệu thiết kế thử nghiệm cho một tính năng, gồm giả thuyết, chỉ số chính, chỉ số phụ, và tiêu chí thắng thua rõ ràng.
Drill 2: Thiết kế một cơ chế thu human feedback nhẹ nhàng như nút thích hoặc một câu hỏi ngắn, sao cho không làm phiền người dùng.
Drill 3: Lấy một kết quả A/B giả định và tập phân biệt khác biệt thật với dao động ngẫu nhiên bằng cách xét cỡ mẫu.
Checklist hành động tuần này
- [ ] Chọn một tính năng và viết giả thuyết cùng chỉ số chính cho A/B test
- [ ] Thiết kế cách chia nhóm ngẫu nhiên và ước lượng cỡ mẫu cần thiết
- [ ] Thêm một cơ chế thu human feedback đơn giản vào sản phẩm
- [ ] Định nghĩa trước tiêu chí thắng thua để tránh diễn giải thiên lệch
- [ ] Lập nhật ký thử nghiệm để ghi lại mọi kết luận
Chỉ số & North Star
North Star là chỉ số hành vi phản ánh giá trị thật cho người dùng, ví dụ tỉ lệ hoàn thành tác vụ hoặc tỉ lệ chấp nhận không cần sửa.
| Chỉ số | Tốt | Xấu |
|---|---|---|
| Cỡ mẫu trước khi kết luận | Đủ lớn và tính trước | Vội kết luận khi mẫu nhỏ |
| Tỉ lệ thu được human feedback | Đủ để đại diện | Quá ít nên thiên lệch |
| Sự nhất quán offline và online | Thường trùng hướng | Ngược chiều mà bỏ qua |
Dấu hiệu bạn đã thành thạo
Bạn luôn viết giả thuyết và chỉ số trước khi chạy test. Bạn không kết luận từ khác biệt nhỏ khi mẫu chưa đủ. Bạn có kênh human feedback chạy đều và đọc nó thường xuyên. Và bạn biết khi nào offline và online mâu thuẫn thì tin vào online.
Cạm bẫy thường gặp
| Cạm bẫy | Thay bằng |
|---|---|
| Ship thẳng theo điểm offline | Xác nhận bằng A/B trên người dùng thật |
| Nhìn kết quả sớm rồi dừng test | Chạy đủ mẫu đã định trước |
| Chọn quá nhiều chỉ số chính | Một chỉ số chính rõ ràng |
| Bỏ qua phản hồi định tính | Đọc bình luận để hiểu vì sao |
Chốt lại
- Online eval đo trên hành vi thật, là phán quyết cuối cùng về chất lượng.
- A/B testing so hai phiên bản công bằng, human feedback bổ sung sắc thái.
- Luôn định trước giả thuyết, chỉ số, và cỡ mẫu để tránh tự lừa mình.
- Khi offline và online mâu thuẫn, hãy tin vào tín hiệu người dùng thật.