Bài 3 — Edge case hiếm nhưng nguy hiểm: quản trị cái đuôi dài

Trong hệ thống tự hành, 90% công sức kỹ thuật đổ vào 10% tình huống cuối cùng — cái "đuôi dài" (long tail) của những kịch bản hiếm. Chúng hiếm nên khó thu thập dữ liệu, khó test, dễ bị bỏ qua; nhưng chính chúng gây ra các tai nạn lên báo. Quản trị đuôi dài là năng lực phân biệt AS-PM giỏi với PM chỉ biết đọc dashboard.

Vì sao đuôi dài nguy hiểm

• Hiếm nên thiếu dữ liệu: mô hình học máy học kém những gì nó ít thấy. Một người mặc đồ hóa trang, một xe tải chở tấm kính phản chiếu bầu trời, một túi nilon bay ngang như vật cản rắn.
• Tổ hợp bùng nổ: sương mù + hoàng hôn + người đi xe đạp ngược chiều + biển báo bị che. Mỗi yếu tố hiếm, tổ hợp còn hiếm hơn nhưng vẫn xảy ra ở quy mô hàng triệu chuyến.
• Lỗi im lặng: hệ thống "tự tin sai" — nhận diện nhầm nhưng không biết mình sai, nên không kích hoạt degrade an toàn.

Ví dụ cụ thể đáng nhớ

• Xe tự lái nhận diện mặt trăng thấp màu vàng thành đèn giao thông vàng.
• Nhận diện hình người in trên thành xe buýt thành người đi bộ thật, phanh gấp gây va chạm phía sau.
• Robot kho coi vũng nước phản chiếu là hố sâu và đứng khựng, tắc nghẽn dây chuyền.
• Drone mất định vị khi bay qua cánh đồng tuyết trắng đồng nhất (không có đặc trưng thị giác để bám).

Khung tư duy: Phân loại và ưu tiên edge case

Dùng ma trận Tần suất × Mức nghiêm trọng:

• Hiếm + Nghiêm trọng cao (ô đỏ): ưu tiên tuyệt đối. Ví dụ trẻ em lao ra từ giữa hai xe đỗ. Ít khi gặp nhưng hậu quả chết người.
• Thường + Nghiêm trọng thấp: xử lý bằng cải tiến dần.
• Hiếm + Nghiêm trọng thấp: chấp nhận có kiểm soát, ghi log.
• Thường + Nghiêm trọng cao: đây là lỗi thiết kế nền tảng, phải chặn ra mắt ngay.

AS-PM phải chủ động săn ô đỏ, không đợi nó tự xuất hiện trên đường.

Chiến lược săn và xử lý đuôi dài

• Scenario library (kho kịch bản): xây danh mục có cấu trúc các tình huống hiểm, gắn nguồn gốc (từ báo cáo tai nạn ngành, từ disengagement thực địa, từ brainstorm chuyên gia).
• Triggered data collection (thu thập có kích hoạt): cài xe/robot tự đánh dấu và gửi về những khoảnh khắc "lạ" (hệ thống lưỡng lự, con người can thiệp, cảm biến bất đồng). Đây là mỏ vàng edge case.
• Fault injection & adversarial testing: cố tình tạo tình huống xấu trong mô phỏng (che cảm biến, tạo vật thể lạ) để xem hệ thống gãy ở đâu.
• ODD làm hàng rào: nếu một loại edge case quá khó xử lý, thu hẹp ODD để tránh nó — ví dụ cấm vận hành khi mưa lớn — thay vì cố gồng.
• Degrade an toàn khi bất định: thiết kế hệ thống biết mình không biết (uncertainty estimation) để chuyển sang Minimal Risk Condition khi gặp thứ chưa từng thấy.

Vòng lặp học từ đuôi dài

Mỗi edge case mới phát hiện → thêm vào scenario library → tái hiện trong sim → sửa → thêm vào bộ test hồi quy để không tái phát. Một edge case đã gặp mà tái phạm là thất bại quy trình, không phải xui rủi.

Checklist quản trị edge case

• [ ] Có scenario library được version-control và cập nhật liên tục không?
• [ ] Hệ thống có tự đánh dấu và gửi về các khoảnh khắc bất định không?
• [ ] Mỗi disengagement/near-miss có được phân loại vào ma trận tần suất × nghiêm trọng không?
• [ ] Ô đỏ có kế hoạch xử lý hoặc quyết định thu hẹp ODD không?
• [ ] Edge case đã sửa có nằm trong bộ test hồi quy tự động không?

Sai lầm thường gặp

• Tối ưu chỉ số trung bình, bỏ đuôi: cải thiện 99% ca dễ để dashboard đẹp, trong khi ô đỏ vẫn nguyên.
• Coi edge case là "trường hợp cá biệt" xui rủi: mỗi ca hiếm là đại diện cho một lớp tình huống — sửa gốc, đừng vá riêng.
• Không có cơ chế biết-mình-không-biết: hệ thống tự tin sai còn nguy hiểm hơn hệ thống biết dừng lại.
• Mở rộng ODD trước khi đóng đuôi: tham vọng phủ nhiều địa hình khi đuôi dài của địa hình cũ chưa xử lý xong.

Đuôi dài không bao giờ hết — mục tiêu là làm nó thu hẹp có kiểm soát và không tái phát. Bài sau: khi edge case vượt qua mọi phòng thủ và thành sự cố thật, bạn điều tra thế nào?