Câu hỏi không có câu trả lời kỹ thuật
Mọi dự án AI đều đến lúc có người hỏi: "85% đã đủ chưa?" Và thường thì cả phòng im lặng, hoặc tệ hơn, có người trả lời bằng cảm giác.
Câu hỏi này không thuộc về kỹ thuật. Đủ hay chưa phụ thuộc vào việc một lần sai tốn bao nhiêu, và ai gánh cái giá đó. Cùng con số 85% có thể là quá thừa cho tính năng này và hoàn toàn không chấp nhận được cho tính năng kia.
Để đội kỹ thuật tự quyết là đặt gánh nặng sai chỗ: họ không có thông tin về mức rủi ro doanh nghiệp chấp nhận, và họ không phải người chịu hậu quả khi sai.
Cách tính ngưỡng — sáu bước
1. Định giá mỗi loại sai bằng tiền hoặc thời gian. Không cần chính xác, cần đúng bậc độ lớn. "Một lần gán nhầm phiếu khẩn ≈ 4 giờ trễ ≈ một khách hàng giận" so với "một lần gán nhầm phiếu thường ≈ 3 phút người xử lý".
2. Ước lượng khối lượng. Sai 1% trên 100 ca/tháng là một ca; trên 100.000 ca/tháng là một nghìn ca. Cùng tỉ lệ, hai thế giới khác nhau.
3. Nhân ra tổng thiệt hại ở vài mức chính xác. Lập bảng: ở 80%, 85%, 90%, 95% thì tổng thiệt hại mỗi tháng là bao nhiêu.
4. Đặt cạnh chi phí đạt được mức đó. Hỏi đội kỹ thuật: đi từ 85% lên 90% tốn bao lâu? Câu trả lời thường phi tuyến — mỗi điểm phần trăm sau đắt hơn nhiều điểm trước.
5. Tìm điểm mà chi phí thêm vượt lợi ích thêm. Đó là ngưỡng của bạn.
6. Hỏi câu rẻ tiền trước khi chốt: nếu thêm một đường hoàn tác hoặc một bước người duyệt, cái giá mỗi lần sai giảm bao nhiêu?
Bước 6 thường thay đổi cả dự án. Một tính năng cần 95% để an toàn có thể chỉ cần 82% nếu có người duyệt ở giữa — và việc thêm bước duyệt mất một tuần, còn đi từ 82% lên 95% có thể mất sáu tháng và vẫn không tới.
Ngưỡng không phải một con số — nó là một bảng
Đặt một ngưỡng duy nhất cho cả tính năng là sai lầm phổ biến, vì nó che giấu việc hệ thống có thể rất tệ ở đúng nhóm ca quan trọng nhất.
| Chia theo | Ví dụ | Vì sao cần tách |
|---|---|---|
| Nhóm ca | Phiếu rõ ràng ≥92% · phiếu mơ hồ ≥70% | Trung bình chung che giấu điểm yếu ở nhóm khó |
| Loại sai | Bỏ sót ca khẩn ≤0,5% · báo thừa ≤15% | Hai loại sai không ngang giá thì không gộp ngưỡng |
| Phân khúc người dùng | Khách doanh nghiệp ≥90% · khách lẻ ≥80% | Hậu quả khác nhau theo người chịu |
| Theo thời gian | Không tụt quá 5 điểm so với tháng trước | Mô hình xuống cấp âm thầm khi dữ liệu đổi |
Ai ký vào ngưỡng
| Câu hỏi nghiệm thu | Thế giới tất định | Hệ thống xác suất |
|---|---|---|
| Ai quyết đạt hay không? | QA, theo tiêu chí | Người chịu trách nhiệm kinh doanh |
| Kiểm bằng gì? | Bộ ca kiểm thử, đúng hoặc sai | Bộ ca chuẩn, so với ngưỡng đã thoả thuận |
| Có được phép sai không? | Không | Có, trong giới hạn đã viết ra |
| Xong là xong chưa? | Gần như xong | Chưa — phải đo lại định kỳ |
Cái bẫy: ngưỡng đặt sau khi đã nhìn số
Nếu bạn chốt ngưỡng sau khi biết mô hình đạt bao nhiêu, bạn sẽ vô thức chọn một con số vừa vặn với kết quả. Điều này xảy ra ở gần như mọi đội, và không ai làm nó một cách cố ý.
Cách chống: chốt ngưỡng trước khi chạy đánh giá đầu tiên, và ghi lại ngày chốt. Nếu sau đó thấy ngưỡng sai, được phép đổi — nhưng phải ghi rõ vì sao đổi, và lý do phải là một lập luận kinh doanh, không phải "vì mô hình chỉ đạt được tới đó".
Sai lầm thường gặp
| Sai lầm | Hậu quả | Cách tránh |
|---|---|---|
| Đội kỹ thuật tự chọn ngưỡng | Không ai khác trả lời câu hỏi đó | Đưa bảng tính cho người chịu trách nhiệm kinh doanh ký |
| Một ngưỡng cho cả tính năng | Che giấu điểm yếu ở nhóm ca quan trọng | Ngưỡng theo nhóm ca, loại sai, phân khúc, thời gian |
| Chốt ngưỡng sau khi nhìn số | Ngưỡng được uốn cho vừa kết quả | Chốt trước, ghi ngày, đổi thì phải giải trình |
| Đạt ngưỡng rồi ngừng đo | Mô hình xuống cấp không ai biết | Ngưỡng theo thời gian là bắt buộc |
Làm ngay
Lập bảng thiệt hại cho tính năng của bạn ở ba mức chính xác, với khối lượng thật. Rồi mang nó cho người chịu trách nhiệm kinh doanh và xin họ chốt ngưỡng. Đừng chốt hộ họ — việc chuyển quyết định này về đúng người là một nửa giá trị của cả bài học.