Công thức
Đây là phép tính trung tâm của tư duy xác suất, và nó đơn giản hơn vẻ ngoài:
Giá trị = (tỉ lệ đúng × lợi ích mỗi lần đúng) − (tỉ lệ sai × cái giá mỗi lần sai) − chi phí vận hành
Ba điều rơi ra từ công thức này, và cả ba đều trái với trực giác của thế giới tất định.
Điều thứ nhất: 70% có thể rất giá trị
Một hệ thống đúng 70% có thể cực kỳ đáng làm, nếu cái giá của lần sai gần bằng không và lợi ích mỗi lần đúng lớn.
Gợi ý thẻ phân loại là ví dụ: đoán sai thì người dùng sửa trong hai giây. Với 70% đúng, bạn vừa tiết kiệm cho họ 70% công việc gõ tay, và 30% còn lại tốn của họ đúng hai giây mỗi lần. Không ai gọi đó là hệ thống kém.
Điều thứ hai: 99% có thể vô dụng hoặc nguy hiểm
Nếu 1% kia là chẩn đoán y khoa sai, hoặc chuyển nhầm tiền, thì con số 99% không nói lên điều gì khi đứng một mình.
Không có con số chính xác nào tốt hay xấu tự thân. Nó chỉ có nghĩa khi đặt cạnh cái giá của lần sai. Đây là lý do mọi cuộc tranh luận kiểu "mô hình của chúng ta đạt 94%" đều vô nghĩa nếu không ai hỏi tiếp: 94% trên ca nào, và 6% kia tốn gì?
Điều thứ ba — và đây là điều quan trọng nhất
Nâng độ chính xác không phải lúc nào cũng là việc đáng làm nhất. Giảm cái giá của lần sai thường rẻ hơn nhiều và hiệu quả hơn nhiều.
| Cách cải thiện giá trị | Chi phí điển hình | Ai thường nghĩ ra |
|---|---|---|
| Nâng độ chính xác từ 82% lên 90% | Nhiều tháng, không chắc đạt | Đội kỹ thuật |
| Thêm một nút hoàn tác | Một tuần | Đội sản phẩm |
| Thêm bước người duyệt cho ca rủi ro cao | Một tuần | Đội sản phẩm |
| Thu hẹp phạm vi xuống nhóm ca dễ | Vài ngày | Đội sản phẩm |
| Hiện độ tin cậy để người dùng tự cảnh giác | Vài ngày | Đội thiết kế |
Ví dụ có số: tự động duyệt hoàn tiền
Sàn thương mại điện tử muốn tự động duyệt yêu cầu hoàn tiền dưới 500.000đ. Hiện có người duyệt tay, 3.000 yêu cầu mỗi tháng, mỗi yêu cầu mất 4 phút.
| Khoản | Giá trị |
|---|---|
| Khối lượng | 3.000 yêu cầu/tháng |
| Chi phí xử lý tay hiện nay | 3.000 × 4 phút = 200 giờ/tháng |
| Sai kiểu A — duyệt nhầm yêu cầu gian lận | Trung bình 350.000đ mất trắng mỗi lần |
| Sai kiểu B — từ chối nhầm yêu cầu thật | 15 phút xử lý khiếu nại + rủi ro mất khách |
| Độ chính xác | Sai A/tháng | Mất tiền | Sai B/tháng | Giờ xử lý khiếu nại | Giờ tiết kiệm |
|---|---|---|---|---|---|
| 80% | ~300 | 105 triệu | ~300 | 75 giờ | 125 giờ |
| 90% | ~150 | 52 triệu | ~150 | 37 giờ | 163 giờ |
| 95% | ~75 | 26 triệu | ~75 | 19 giờ | 181 giờ |
Rồi áp dụng điều thứ ba
Thay vì đi nâng độ chính xác, thiết kế lại để giảm cái giá của lần sai:
- Chỉ tự động duyệt yêu cầu dưới 200.000đ — giảm thiệt hại mỗi lần sai kiểu A xuống còn khoảng 140.000đ.
- Và chỉ với tài khoản có lịch sử trên 6 tháng không tranh chấp — nhóm này chiếm 62% khối lượng và có tỉ lệ gian lận thấp hơn nhiều.
- Phần còn lại vẫn qua người duyệt.
- Rà soát mẫu ngẫu nhiên 3% các yêu cầu đã tự động duyệt, hằng tuần.
Sai lầm thường gặp với phép tính này
| Sai lầm | Vì sao xảy ra | Cách tránh |
|---|---|---|
| Chỉ nhìn tỉ lệ đúng | Đó là con số duy nhất đội kỹ thuật báo cáo | Luôn hỏi ba số: tỉ lệ, lợi ích, cái giá |
| Quên chi phí vận hành | Nó không xuất hiện trong bản demo | Cộng chi phí mỗi lần gọi và chi phí người rà soát |
| Dùng số trung bình cho cái giá | Dễ tính hơn | Vài ca rất đắt sẽ chi phối; dùng phân phối, không dùng trung bình |
| Tính một lần rồi thôi | Coi như đã xong | Khối lượng tăng thì phép tính đổi — tính lại mỗi quý |
Làm ngay
Với tính năng bạn chọn ở bài 1: ước lượng thô ba con số — tỉ lệ đúng hiện tại, lợi ích mỗi lần đúng, cái giá mỗi lần sai. Không cần chính xác, cần đúng bậc độ lớn. Rồi hỏi một câu: có cách nào làm cái giá mỗi lần sai giảm một nửa không?