Product Management
Đăng nhập
ESC

Nhập từ khóa để tìm kiếm

↑↓ Di chuyển
Enter Mở
ESC Đóng

Ngưỡng chất lượng và chi phí của sai

AI

Trả lời "bao nhiêu phần trăm là đủ" bằng phép tính thay vì cảm giác — và biết khi nào nên giảm giá của lần sai thay vì nâng độ chính xác.

Bạn đang ở đâu với kỹ năng này?

Làm bài Đánh giá Kỹ năng PM cho Sản phẩm AI — Một lần làm chấm điểm cho tất cả kỹ năng trong nhóm AI, không chỉ kỹ năng này.

Làm bài đánh giá

Kỹ năng này cho bạn điều gì

Bắt đầu từ đây

Hiểu "bao nhiêu là đủ" không phải câu hỏi kỹ thuật mà là phép tính kinh doanh, và hai loại sai — dương tính giả và âm tính giả — gần như không bao giờ ngang giá.

Khi đã làm được

Định giá được hai loại sai, lập bảng thiệt hại ở nhiều mức chính xác với khối lượng thật, đặt cạnh chi phí đạt từng mức, luôn kiểm phương án giảm cái giá của lần sai trước khi chốt, và đặt ngưỡng thành một bảng theo nhóm ca / loại sai / phân khúc / thời gian thay vì một con số duy nhất.

Roadmap — Cách học và đạt kỹ năng

Đã đọc 0/8 mục · còn khoảng 6 phút
Cách chúng tôi ghi nhận

Một mục được tính là đã đọc khi nó nằm giữa màn hình đủ lâu so với độ dài của nó (bảng và sơ đồ tính một nửa), bạn vẫn đang cuộn hoặc bấm phím, và bạn đã thấy tới cuối mục. Lướt nhanh hoặc để tab mở không được tính. Chúng tôi chỉ lưu thời gian đọc từng mục — không lưu gì khác.

Câu hỏi "bao nhiêu là đủ" 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. Nó là một phép tính kinh doanh: đủ 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 một 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.

Kỹ năng này biến câu hỏi cảm tính đó thành một phép tính có thể làm được, và đặt quyết định vào đúng tay người chịu trách nhiệm.

Hai loại sai không bao giờ ngang giá

Đây là ý tưởng nền tảng, và nó bị bỏ qua trong phần lớn dự án.

Loại saiNghĩa làVí dụ trong lọc thư rác
Dương tính giảHệ thống báo có, thực tế khôngThư quan trọng bị đẩy vào hòm thư rác — rất đắt
Âm tính giảHệ thống báo không, thực tế cóThư rác lọt vào hòm thư chính — khó chịu, nhưng rẻ

Trong ví dụ này hai loại sai lệch nhau rất xa về giá trị. Đó là lý do bộ lọc thư rác được chỉnh nghiêng hẳn về một phía: thà để lọt vài thư rác còn hơn giấu mất một hợp đồng.

Và chiều lệch đảo ngược hoàn toàn tuỳ bài toán:

Bài toánLoại sai đắt hơnNên chỉnh nghiêng về
Sàng lọc bệnhBỏ sót người bệnhBáo động thừa, rồi cho người kiểm lại
Phát hiện gian lận thanh toánChặn nhầm giao dịch thậtCho qua, rồi rà soát sau
Kiểm duyệt nội dungTuỳ: gỡ nhầm bài sạch hay để lọt bài độcPhải chọn, và chọn công khai
Gợi ý sản phẩmGần như không có loại nào đắtTối ưu cho tổng thể, không cần lệch

Không chọn cũng là một lựa chọn — nó chỉ có nghĩa là ai đó trong đội kỹ thuật đã chọn thay bạn, theo mặc định của công cụ, và không ai biết.

Cách tính ngưỡng — từng bước, có số

  • 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 cấp ≈ 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ý".
  • Bước 2 — Ước lượng khối lượng. Bao nhiêu lần mỗi thá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.
  • Bước 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.
  • Bước 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? Thường phi tuyến — mỗi điểm phần trăm sau đắt hơn nhiều điểm trước.
  • Bướ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.
  • Bước 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? Thường điều này rẻ hơn nhiều so với việc nâng độ chính xác, và làm ngưỡng cần thiết tụt xuống đáng kể.

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.

Ví dụ tính thật — tự động duyệt hoàn tiền

Bối cảnh: 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ảnGiá trị
Khối lượng3.000 yêu cầu/tháng
Chi phí xử lý tay hiện nay3.000 × 4 phút = 200 giờ/tháng
Sai kiểu A — duyệt nhầm yêu cầu gian lậnTrung 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ậtKhách khiếu nại: 15 phút xử lý + rủi ro mất khách

Bảng tính ở các mức:

Độ chính xácSai A/thángMất tiềnSai B/thángGiờ xử lýGiờ tiết kiệm
80%~300105 triệu~30075 giờ125 giờ
90%~15052 triệu~15037 giờ163 giờ
95%~7526 triệu~7519 giờ181 giờ

Đọc ra: ngay cả ở 95%, khoản mất do gian lận (26 triệu/tháng) vẫn lớn hơn giá trị 181 giờ tiết kiệm được. Tự động hoá hoàn toàn là lựa chọn sai ở mọi mức chính xác khả thi.

Rồi áp dụng bước 6 — 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 có tranh chấp — nhóm này chiếm 62% khối lượng và 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.

Kết quả: ở cùng mức chính xác 88%, thiệt hại còn khoảng 8 triệu/tháng và vẫn tiết kiệm được khoảng 100 giờ. Phép tính chuyển từ âm sang dương mà không cần cải thiện mô hình một chút nào — chỉ cần thu hẹp phạm vi và giảm cái giá của lần sai.

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 theoVí dụVì sao cần tách
Nhóm caPhiế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 saiBỏ sót ca khẩn ≤0,5% · báo thừa ≤15%Hai loại sai không ngang giá thì không được gộp ngưỡng
Phân khúc người dùngKhách doanh nghiệp ≥90% · khách lẻ ≥80%Hậu quả khác nhau theo người chịu
Theo thời gianKhông tụt quá 5 điểm so với tháng trướcMô hình xuống cấp âm thầm khi dữ liệu thật đổi

Hiccups thường gặp và cách xử lý

HiccupVì sao xảy raXử lý
Đội kỹ thuật tự chọn ngưỡngKhông ai khác trả lời câu hỏi đóNgưỡng là quyết định kinh doanh; đưa bảng tính cho người chịu trách nhiệm ký
Gộp hai loại sai vào một con sốĐơn giản hơn khi báo cáoLuôn tách; chúng gần như không bao giờ ngang giá
Đuổi theo độ chính xác mà bỏ qua thiết kếĐó là thứ đội kỹ thuật biết làmLuôn chạy bước 6 trước khi duyệt một dự án cải thiện mô hình
Một ngưỡng cho cả tính năngChưa nghĩ tới việc chia nhómNgưỡng theo nhóm ca, loại sai, phân khúc và theo thời gian
Đạt ngưỡng rồi thôi không đo nữaCoi như đã xongNgưỡng theo thời gian là bắt buộc; mô hình xuống cấp không báo trước
Tự động hoá 100% vì nghe hayKhông ai làm phép tínhRất nhiều bài toán có lời giải đúng là tự động một PHẦN — thu hẹp phạm vi thường thắng

Vì sao vai trò của bạn cần cái này

Vai tròBạn dùng nó để
Product Owner / PMBạn lập bảng tính và đưa nó cho người quyết — đây là việc của bạn, không phải của đội kỹ thuật
Người chịu trách nhiệm kinh doanhBạn ký vào ngưỡng vì bạn gánh rủi ro; bảng tính cho bạn cơ sở để ký
Business AnalystBạn định giá hai loại sai — việc này cần hiểu nghiệp vụ, không cần hiểu mô hình
EngineerBạn cung cấp chi phí đi từ mức này lên mức kia, và đề xuất phương án thu hẹp phạm vi
Tài chính / rủi roBạn kiểm phép tính và chỉ ra chi phí bị bỏ sót

Definition of done

  • Hai loại sai được định nghĩa và định giá riêng bằng tiền hoặc thời gian.
  • Có bảng tổng thiệt hại ở ít nhất ba mức chính xác, kèm khối lượng thật.
  • Đã hỏi đội kỹ thuật chi phí đi từ mức này lên mức kia.
  • Đã chạy bước "giảm cái giá của lần sai" trước khi chốt ngưỡng.
  • Ngưỡng được chia theo nhóm ca, loại sai và phân khúc — không phải một con số.
  • Có ngưỡng theo thời gian và lịch đo lại.
  • Người chịu trách nhiệm kinh doanh đã ký vào ngưỡng.

Tự kiểm 3 câu

Đọc xong rồi thì thử xem — đúng cả ba là đạt.
1. Trong buổi họp có người hỏi “85% đã đủ chưa?”. Ai và dựa vào đâu để trả lời?
2. Tính năng tự động duyệt cần 95% để an toàn; mô hình đang ở 82%. Đội đề xuất sáu tháng cải thiện. PM nên hỏi gì trước?
3. Báo cáo ghi tính năng phân loại phiếu đạt 88% chung. Vì sao một con số này chưa đủ để nghiệm thu?

Khóa học liên quan (8)

Sử dụng trong vai trò

Thảo luận & tài liệu thêm 0

Chia sẻ kinh nghiệm, đặt câu hỏi, hoặc đính kèm tài liệu/YouTube giúp người khác học kỹ năng này.

Hãy là người đầu tiên chia sẻ kinh nghiệm cho kỹ năng này.

Kiểm tra kỹ năng này

Bài kiểm tra của các khóa dạy kỹ năng này
1 Quiz

Bài thi tổng kết: Từ Pilot đến Production: Scale Agent An toàn

Bài kiểm tra của một khóa dạy kỹ năng này.

chưa ai làm
Làm bài này
2 Quiz

Bài thi tổng kết: Đánh giá & Debug AI Agent

Bài kiểm tra của một khóa dạy kỹ năng này.

chưa ai làm
Làm bài này
3 Quiz

Bài thi tổng kết: Autonomous Systems Product Manager: Hệ thống tự hành

Bài kiểm tra của một khóa dạy kỹ năng này.

chưa ai làm
Làm bài này
4 Quiz

Bài thi tổng kết: Human-in-the-loop & Cổng phê duyệt

Bài kiểm tra của một khóa dạy kỹ năng này.

chưa ai làm
Làm bài này

Học kỹ năng này ở đâu?

Có 8 khóa dạy đúng phần này, miễn phí và bằng tiếng Việt.

Bắt đầu học