Sự cố AI đầu tiên của bạn: Mẫu phân tích sau sự cố

AI của bạn chắc chắn sẽ gặp sự cố. Đó không phải là câu hỏi "có hay không". Câu hỏi duy nhất là sự cố đó dạy bạn điều gì đó, hay chỉ khiến bạn tốn kém.

Sự cố AI trông khác với sự cố ngừng hoạt động kinh điển. Hệ thống không sập. Nó hoạt động suốt, phản hồi, sinh ra — nhưng sai. Có thể kéo dài hàng giờ, hàng ngày, trước khi ai đó nhận ra. Sự cố cơ sở dữ liệu thì ồn ào. Sự cố AI thì lặng lẽ, và sự cố lặng lẽ mới là thứ đắt đỏ, vì chúng chạy lâu hơn trước khi bị ai đó nhìn thấy.

Phân tích sau sự cố là cách bạn biến sự cố lặng lẽ thành bài học. Mẫu dưới đây là mẫu tôi dùng, và nó được xây cho hình thái đặc thù của sự cố AI: không phải "cái gì hỏng" mà là "cái gì sai, trong bao lâu, và vì sao chúng ta không phát hiện sớm hơn".

Năm phần

Phần một: nó đáng lẽ phải làm gì. Một đoạn văn, không khoa trương. Nhiệm vụ, hành vi kỳ vọng, chuẩn chất lượng mà nó được xây để đạt. Phần này tồn tại để việc phân tích bắt đầu từ sự đồng thuận — hệ thống để làm gì — thay vì lao thẳng vào đổ lỗi.

Phần hai: nó thực sự đã làm gì. Hành vi, thời lượng, phạm vi. Bao nhiêu đầu ra, trong khoảng thời gian nào, ảnh hưởng đến cái gì. Đây là nơi tính chất lặng lẽ của sự cố AI lộ ra — phần này thường bắt đầu bằng "chúng tôi không biết chính xác nó bắt đầu khi nào" và cách khắc phục khoảng trống đó trở thành một phần của các mục hành động.

Phần ba: chúng ta phát hiện ra bằng cách nào. Câu chuyện phát hiện. Là khiếu nại của khách hàng? Một người đánh giá nhận ra điều gì đó bất ổn? Một chỉ số cuối cùng vượt ngưỡng? Phần này hữu ích nhất, vì nó cho bạn biết khả năng phát hiện của bạn đã hỏng thế nào. Sự cố kéo dài ba ngày không phải lỗi mô hình, mà là lỗi phát hiện, và phần này nêu rõ nó.

Phần bốn: vì sao nó xảy ra. Nguyên nhân gốc, được viết không kèm đổ lỗi. Mô hình đã thay đổi. Dữ liệu trôi dạt. Prompt trôi dạt. Ngưỡng được đặt sai. Bộ eval đã bỏ sót ca này. Nêu rõ nguyên nhân, và nêu các yếu tố góp phần — tín hiệu bị thiếu, chỉ số không được giám sát, hàng đợi đánh giá quá chậm để nhận ra.

Phần năm: điều gì sẽ được triển khai tiếp theo. Các mục hành động, mỗi mục cụ thể, có người sở hữu và có hạn. Không phải "cải thiện giám sát", mà là "thêm tín hiệu tỷ lệ ghi đè vào dashboard trước thứ Sáu, do người vận hành sở hữu". Công việc duy nhất của phân tích sau sự cố là tạo ra phần này, và phần này chỉ thực sự có giá trị nếu các mục đủ cụ thể.

Công việc của phân tích sau sự cố không phải là giải thích sự cố, mà là khiến sự cố tiếp theo rẻ hơn — ngắn hơn, nhỏ hơn và được phát hiện sớm hơn. Năm phần, không đổ lỗi, và các mục hành động thực sự được triển khai.

Nhịp đánh giá giúp nó bám rễ

Một bản phân tích viết xong rồi cất đi chỉ là tài liệu. Một bản phân tích được đánh giá lại là một hệ thống. Khác biệt nằm ở nhịp độ.

Đánh giá ngay lập tức diễn ra khi sự cố còn mới — đội đi qua năm phần, tranh luận về nguyên nhân và phân công các mục. Rồi theo dõi, ba mươi ngày sau: các mục đã triển khai chưa? Khả năng phát hiện có cải thiện không? Sự cố tương tự có thể xảy ra ngày mai không? Bước kiểm tra ba mươi ngày thường là nơi các bản phân tích chết yểu — năng lượng đã cạn, sự cố thành tin cũ, các mục thì quá hạn. Bước kiểm tra tồn tại để giữ cho vòng lặp trung thực.

Và đánh giá theo mô hình, hằng quý: vài sự cố gần nhất được xem xét cùng nhau. Các sự cố AI tụ lại thành cụm. Cùng một khoảng trống phát hiện, cùng một tín hiệu không được giám sát, cùng một điểm mù eval — từng sự cố được giải thích riêng lẻ, gộp lại chúng là một mô hình có tên và có cách khắc phục. Đánh giá hằng quý là nơi các bài học riêng lẻ trở thành cải tiến hệ thống.

Quy tắc không đổ lỗi, được hiện thực hóa

Phân tích sự cố AI sẽ chết nếu thiếu quy tắc không đổ lỗi, và quy tắc đó phải được nêu rõ vì bản năng tự nhiên là đi tìm người chịu trách nhiệm. Người vận hành không nhận ra. Kỹ sư đã ship mô hình. Người đánh giá đã phê duyệt đầu ra sai. Đổ lỗi có cảm giác hiệu quả. Nhưng không phải vậy. Nó chỉ đảm bảo sự cố tiếp theo bị giấu đi thay vì được báo cáo.

Cách định khung hiệu quả: hệ thống đã hỏng, và hệ thống là của chúng ta. Mô hình, giám sát, ngưỡng, quy trình đánh giá, huấn luyện — tất cả đều do đội thiết kế, và sự cố là một phát hiện về thiết kế đó. Người báo cáo sự cố đầu tiên là anh hùng, không phải kẻ xấu. Đội thấm nhuần điều này sẽ nhận được báo cáo sớm và bài học nhanh. Đội không làm được sẽ nhận sự im lặng và những sự cố lặp lại.

Câu hỏi khép lại mọi bản phân tích

Kết thúc mọi bản phân tích bằng cùng một câu hỏi: nếu đúng sự cố này xảy ra lại vào ngày mai, chúng ta sẽ phát hiện nó nhanh hơn bằng cách nào?

Câu trả lời chính là bản tóm tắt các mục hành động. Nếu câu trả lời là "cùng cách chúng ta phát hiện lần này" — một khiếu nại khách hàng hay linh cảm của người đánh giá, thì bản phân tích đã thất bại, vì việc phát hiện vẫn mang tính phản ứng. Nếu câu trả lời là "tín hiệu tỷ lệ ghi đè đã bắt được nó ngay ngày đầu tiên", thì bản phân tích đã thành công, vì sự cố tiếp theo rẻ hơn ngay cả trước khi nó xảy ra.

Nghĩ rằng lập luận này phù hợp với sự kiện của bạn? Hãy kể cho tôi về khán phòng — lịch trình có chọn lọc.