Từ "chạy được" đến "đủ tốt để ra mắt"
Bài 29 đến Bài 33 đã đi qua từng phần của spec cho tính năng AI: hợp đồng đầu vào và đầu ra, tiêu chí đánh giá, phương án dự phòng, độ trễ, chống bịa. Bài này ghép chúng thành câu hỏi mà PM phải trả lời trước ngày ra mắt: đủ tốt là bao nhiêu, đo trên cái gì, và ai ký?
Với tính năng thường, QA kiểm đúng hay sai theo tiêu chí nghiệm thu. Với tính năng AI, cùng một đầu vào có thể cho kết quả khác nhau, và kết quả nào cũng có một tỉ lệ sai. Không có trạng thái "hết lỗi", chỉ có "tỉ lệ lỗi dưới ngưỡng ta chấp nhận". Nếu ngưỡng đó không được viết vào spec từ trước, nó sẽ được quyết định trong buổi họp ra mắt, bởi người nói to nhất hoặc người đang chịu áp lực tiến độ nhất.
Ngưỡng chất lượng theo mức độ nghiêm trọng
Không phải lỗi nào cũng như nhau. Chia lỗi theo hậu quả, mỗi mức một ngưỡng riêng. Một con số "độ chính xác 90%" chung chung che mất điều quan trọng: 10% còn lại sai kiểu gì.
Tiếp tục ví dụ giả định Sỉ Nhanh. Sau thí điểm ở Bài 63, đội đã thêm quy tắc cứng không món nào vượt 1,5 lần mức nhập trung bình. Quy tắc cứng chặn được trường hợp tệ nhất, nhưng không nói gì về chất lượng chung. Trước khi mở thêm 1.500 tiệm, PRD chốt các ngưỡng:
| Mức | Ví dụ lỗi | Hậu quả | Ngưỡng ra mắt |
|---|---|---|---|
| Nghiêm trọng | Số lượng gợi ý cao hơn 1,5 lần lượng tiệm thực nhập ở đơn kế tiếp | Tiệm nhập thừa, nhà phân phối nhận hàng trả lại | ≤ 2% số dòng gợi ý |
| Nặng | Gợi ý món tiệm đã ngừng nhập từ 2 tháng | Chủ tiệm mất niềm tin vào gợi ý | ≤ 3% số giỏ |
| Nhẹ | Thiếu món tiệm thường nhập | Chủ tiệm tự thêm | Độ phủ ≥ 70% số món của đơn thật kế tiếp |
| Trải nghiệm | Giỏ dài hơn 40 món | Khó rà soát trên điện thoại | ≤ 5% số giỏ |
Bộ đánh giá, đo trên cái gì
Mỗi ca trong bộ đánh giá là một đơn thật trong quá khứ: mô hình chỉ được xem lịch sử trước ngày đó, rồi gợi ý được so với đơn tiệm thực sự đặt. Bộ đánh giá phải chia theo lát cắt, vì trung bình đẹp có thể giấu một nhóm khách bị phục vụ rất tệ.
| Lát cắt | Số ca | Vì sao có lát này |
|---|---|---|
| Tiệm đặt đều, lịch sử trên 6 tháng | 200 | Trường hợp phổ biến nhất |
| Tiệm đặt thất thường | 80 | Nơi mô hình hay sai nhất |
| Cận Tết và cuối tháng | 60 | Nhu cầu đổi đột ngột |
| Món mới lên kệ hoặc vừa ngừng bán | 40 | Lịch sử đánh lừa mô hình |
| Tiệm đặt từ 2 nhà phân phối trở lên | 20 | Dễ gợi trùng món |
- Đạt trung bình nhưng trượt một lát cắt là chưa đạt.
- Bộ đánh giá được khóa trước khi chạy; không bỏ ca "khó" sau khi xem kết quả. Muốn đổi thì đổi cho vòng sau, ghi rõ lý do.
- Mỗi lỗi thật sau ra mắt được xem xét để thêm vào bộ đánh giá.
- PM sở hữu bộ đánh giá về mặt nội dung, vì nó định nghĩa "tốt" với người dùng; kỹ sư sở hữu công cụ chạy nó.
QA trước ra mắt, ba vòng
- Chạy offline trên bộ đánh giá, so với ngưỡng của từng mức và từng lát cắt.
- Rà soát thủ công: PM, một nhân viên kinh doanh hiểu tiệm, một kỹ sư cùng chấm 50 giỏ ngẫu nhiên, ghi lại những lỗi mà con số không bắt được, ví dụ giỏ đúng món nhưng sắp xếp khó đọc.
- Chạy bóng: mô hình chạy một tuần trên tiệm thật nhưng không hiện gợi ý, kết quả được so với đơn thật.
| Tiêu chí | Ngưỡng | Kết quả | Đánh giá |
|---|---|---|---|
| Lệch số lượng nghiêm trọng | ≤ 2% dòng | 1,4% | Đạt |
| Món đã ngừng nhập | ≤ 3% giỏ | 4,5% | Chưa đạt |
| Độ phủ | ≥ 70% | 74% | Đạt |
| Giỏ quá dài | ≤ 5% | 2% | Đạt |
Ký duyệt và chạy lại
Spec ghi rõ ba điều. Ai ký cho ra mắt: PM và trưởng nhóm kỹ thuật, cùng nhau. Khi nào phải chạy lại bộ đánh giá: mỗi lần đổi mô hình, đổi prompt, hoặc đổi dữ liệu đầu vào, kể cả thay đổi "nhỏ". Theo dõi gì sau ra mắt: tỉ lệ đơn có món bị giảm mạnh số lượng và tỉ lệ hàng trả lại, lấy từ tracking ở Bài 64, kèm ngưỡng tự động tắt tính năng nếu vượt.
Làm ngay
- Liệt kê các lỗi có thể có của tính năng AI bạn đang làm, xếp thành 3 đến 4 mức theo hậu quả.
- Đặt ngưỡng cho từng mức, dựa trên hậu quả và cách người dùng đang làm hôm nay.
- Thiết kế bộ đánh giá có ít nhất 4 lát cắt, ghi số ca và lý do của từng lát.
- Viết kế hoạch QA ba vòng và tên người ký, rồi đối chiếu với kỹ năng Specifying non-deterministic systems.