Artificial Intelligence(AI)

Vài năm nay gần như hồ sơ thầu nào cũng có chữ AI ở đâu đó. Vấn đề là chữ đó che ba thứ rất khác nhau: một bảng luật if-then, một mô hình dự đoán tồn kho, và một con chatbot chạy trên mô hình ngôn ngữ. Người viết yêu cầu mà không gọi đúng tên loại thì tài liệu sẽ sai ngay từ chỗ nghiệm thu.

Câu đáng hỏi trong buổi làm rõ yêu cầu: đầu ra của nó có tất định không, và ai chịu trách nhiệm khi nó sai. Chuyện "cái này có được gọi là AI không" thì để hồ sơ thầu lo.

Ba nhóm hay bị gộp chung một chữ

• Hệ luật (rule-based). Người viết sẵn điều kiện, máy chạy theo. Cùng đầu vào luôn ra cùng kết quả. Kiểm thử được như mọi tính năng thường. Kha khá thứ được bán là AI thực chất nằm ở đây, và nằm ở đây cũng chẳng có gì xấu.
• Máy học dự đoán. Học từ dữ liệu lịch sử để chấm điểm, xếp loại, dự báo. Đầu ra là một con số kèm mức tin cậy chứ không phải câu trả lời chắc nịch. Chấm điểm rủi ro gian lận, dự báo nhu cầu hàng hoá, gợi ý sản phẩm.
• AI tạo sinh. Sinh ra nội dung mới. Hỏi cùng một câu hai lần có thể nhận hai câu trả lời khác nhau, cả hai đều nghe xuôi tai.

Ba nhóm này cần ba kiểu tài liệu khác nhau. Nhóm một viết như business rule bình thường. Nhóm hai phải chốt ngưỡng và cách xử lý vùng xám. Nhóm ba phải chốt cách nghiệm thu khi không tồn tại một đáp án duy nhất.

Ví dụ thực tế

"Cái này AI làm được mà, đưa hết vào cho nó tự chia." Anh trưởng phòng vận hành nói câu đó trong buổi kick-off, tay chỉ vào màn hình đang mở hộp thư hỗ trợ. Công ty giao vận nội địa, mỗi ngày tầm 2.170 yêu cầu đổ về qua tổng đài, Zalo OA và email, cần định tuyến về đúng đội: giao hàng chậm, sai địa chỉ, hư hỏng, đối soát tiền COD.

Bản đầu tiên chạy bằng từ khoá. Gặp chữ "COD" thì đẩy sang đội đối soát, gặp "bể", "móp" thì đẩy sang đội khiếu nại hàng hoá. Cách này định tuyến đúng chừng 58% số ticket, và cực kỳ dễ sửa: sai chỗ nào thêm từ khoá chỗ đó.

Bản thứ hai dùng mô hình phân loại huấn luyện trên 37.000 ticket đã gán nhãn sẵn từ hai năm trước. Tỉ lệ đúng lên 91%. Nhưng lúc này BA phải trả lời thêm mấy câu mà bản từ khoá không hề đặt ra:

• Ticket có độ tin cậy dưới 0,7 thì đi đâu? (chốt: vào hàng đợi chung, người phân tay)
• Ai gán nhãn lại cho ticket bị định tuyến sai, và dữ liệu đó có quay về huấn luyện lại không?
• Mô hình cũ đi rồi thì đo lại tỉ lệ đúng ở đâu, bao lâu một lần?

Đó mới là phần việc thật của BA. Chọn thuật toán là việc của team data.

Lỗi hay gặp

Viết yêu cầu kiểu "hệ thống phải phân loại chính xác". Chính xác bao nhiêu phần trăm, đo trên bộ dữ liệu nào, ai duyệt bộ đó. Không có ba thứ này thì không nghiệm thu được, và tới ngày UAT sẽ cãi nhau.

Quên nhánh sai. Mô hình nào cũng sai một tỉ lệ nào đó. Nếu tài liệu không mô tả chuyện gì xảy ra với phần sai đó, mặc định nó sẽ rơi vào mặt khách hàng.

Nhận dữ liệu như một điều hiển nhiên. Muốn có mô hình phân loại thì phải có dữ liệu đã gán nhãn. Nhiều dự án tới sprint thứ ba mới phát hiện ba năm ticket cũ chưa ai gán nhãn tử tế, và việc gán nhãn 4.200 mẫu tốn của nghiệp vụ hai tuần công.

Dùng AI cho bài toán vốn đã có luật rõ. Tính thuế TNCN có biểu thuế công khai. Ai đó vẫn sẽ đề xuất một mô hình cho chỗ đó, và câu hỏi lại nên là nó giải quyết được gì mà bảng biểu thuế không giải quyết được.

Mẹo khi đi làm

Trong buổi họp làm rõ yêu cầu, hỏi thẳng: "Nếu hệ thống này trả lời sai một lần trên mười, chuyện gì xảy ra với khách hàng, và ai xin lỗi họ." Câu trả lời sẽ quyết định luôn kiến trúc. Nếu hậu quả là mất tiền hoặc mất uy tín ở mức không chấp nhận được, phần đó phải chạy bằng luật cứng, còn AI chỉ được đứng ở vị trí gợi ý cho người quyết.

Và khi viết BRD, tách hẳn một mục "giới hạn đã biết của mô hình". Ngắn thôi, năm sáu dòng. Nó cứu bạn ở buổi nghiệm thu nhiều hơn cả chục trang mô tả tính năng.