Khi kiểm tra định tính (deterministic check) lặng lẽ chệch hướng

Cuộc hội thoại xác định phạm vi (Scoping call), trích ghi âm

Cuộc trò chuyện dưới đây là một trao đổi scoping thực tế. Hai người đã đưa ra một quyết định có vẻ hợp lý để đơn giản hóa thiết kế, và ngay tại thời điểm đó, nó trông như một cải tiến rõ rệt. Nhưng những gì họ thực sự làm là giao một quy tắc nghiệp vụ deterministic – thứ bắt buộc phải đúng 100% trong mọi trường hợp – cho model, vốn là một hệ thống xác suất (probabilistic system), chỉ đúng trong phần lớn trường hợp chứ không phải tất cả. Khoảng trống đó đã không lộ ra trong quá trình phát triển, mà nó chỉ xuất hiện 3 tháng sau, trong một kỳ audit.

Mục tiêu của phần này là chỉ ra cho bạn những gì đã đi sai hướng, giúp bạn nhận diện sớm pattern thất bại này và đưa ra quyết định khác biệt.

• Đối tác: "Chúng tôi có một quy tắc là bất kỳ hồ sơ bồi thường nào trên £5,000 đều cần một người thẩm định cấp cao (senior adjuster). Hiện tại chúng tôi đang chạy một SQL check trên claims table. Claude có thể tự xử lý việc đó thay thế được không?"

• Architect: "Chúng ta có thể prompt Claude trích xuất số tiền và tự động route tương ứng nếu con số lớn hơn £5,000. Như vậy sẽ giữ quy trình trong cùng một bước thay vì phải gọi ra một hệ thống riêng biệt để kiểm tra, đơn giản hơn rất nhiều."

• Đối tác: "Tuyệt vời, phương án đó ổn đấy."

[3 tháng sau, trên môi trường production]

Trong số 14,000 hồ sơ bồi thường được xử lý, 41 hồ sơ bị định tuyến (routed) sai.

Cả 41 trường hợp này đều gặp cùng một vấn đề: Số tiền không được viết dưới dạng một con số rõ ràng. Nó bị giấu bên trong một câu văn, kiểu như "thiệt hại ước tính khoảng 5 nghìn bảng". Model đã coi "khoảng 5 nghìn" là một con số ước tính chung chung chứ không phải một con số chính xác cần kích hoạt quy trình xem xét của cấp cao, do đó các hồ sơ này bị chuyển sang luồng xử lý thông thường. Quy tắc nghiệp vụ thì chính xác, nhưng thông tin đầu vào lại không hề rõ ràng, và model đã tuân thủ theo đúng mặt chữ của quy tắc thay vì hiểu đúng mục đích (intent).

Điều gì đã đổ vỡ: Một quy tắc deterministic được giao cho một hệ thống probabilistic

Ngưỡng quy định không hề thay đổi, nhưng thứ thực thi quy tắc đó thì có. Một quy tắc deterministic đòi hỏi phải đúng tuyệt đối 100% đã được gộp chung vào Claude – một hệ thống chỉ đúng trong phần lớn thời gian. Khoảng trống giữa hai bản chất này chính là nơi phát sinh 41 trường hợp misroute.

Team đã không bao giờ xây dựng một bộ test cases để kiểm tra việc routing, bởi vì họ xem việc định tuyến chỉ là thứ mà model sẽ "tự động xử lý được", chứ không coi đó là một quy tắc kinh doanh mà doanh nghiệp đang trông cậy vào. Sự khác biệt đó chính là mấu chốt của vấn đề:

• Một quy tắc mà doanh nghiệp trông cậy vào bắt buộc phải được kiểm thử, theo dõi và giám sát bởi con người.

• Một thứ bạn mặc định là model sẽ tự cân được sẽ bị bỏ mặc cho đến khi nó tự đổ vỡ.

Các lỗi misroute này bị phát hiện thông qua một kỳ audit, chứ không phải từ hệ thống theo dõi (monitoring) của chính nó. Kiểu logging vốn có thể bắt được một lỗi SQL check sẽ không ghi lại các lựa chọn mà một model đưa ra bên trong một request đơn lẻ, vì vậy không có cảnh báo nào được bật lên khi hệ thống bị chệch hướng (drift). Thất bại này hoàn toàn ẩn mình cho đến khi có người chủ động đi tìm nó.

Vì sao thiết kế này thất bại?

Một quy tắc cần phải đúng 100% lại được giao cho một hệ thống chỉ đúng trong hầu hết trường hợp. Sự đánh đổi này rất dễ bị bỏ qua trong giai đoạn scoping vì model xử lý các trường hợp dữ liệu sạch (clean cases) vô cùng hoàn hảo, và các trường hợp dữ liệu sạch lại là thứ duy nhất bạn nhìn thấy trong các buổi demo và thử nghiệm ban đầu. Cái giá phải trả cho cụm từ "trong hầu hết trường hợp" không lộ diện cho đến khi bạn tiến hành audit – và đến lúc đó thì đối tác đã nhấc máy lên gọi cho bạn rồi.