AI trả lời và AI làm việc: khác nhau ở đâu?
Một mô hình trả lời tốt không tự động trở thành một hệ thống làm việc được. Khoảng cách giữa hai thứ đó nằm ở trạng thái, ranh giới và cách kiểm chứng kết quả.
Hầu hết các thử nghiệm AI trong doanh nghiệp đều bắt đầu giống nhau. Ai đó mở một cửa sổ chat, đưa vào một bài toán thật, và nhận được câu trả lời tốt hơn mong đợi. Kết luận rút ra thường là: công cụ này dùng được, giờ chỉ cần đưa nó vào quy trình.
Vài tuần sau, thứ được đưa vào quy trình lại không chạy. Không phải vì mô hình kém đi, mà vì bài toán đã đổi. Trả lời một câu hỏi và làm xong một công việc là hai bài toán khác nhau, và phần lớn công sức nằm ở chỗ không ai nhìn thấy trong buổi thử nghiệm đầu tiên.
Một lượt so với nhiều lượt
Một câu trả lời là một lượt. Bạn đưa vào ngữ cảnh, nhận ra kết quả, tự đánh giá xem có dùng được không. Nếu sai, bạn hỏi lại. Người ngồi trước màn hình chính là bộ nhớ, là người ra quyết định, và là lớp kiểm tra chất lượng của quy trình đó.
Một công việc thì hiếm khi chỉ có một lượt. Nó có nhiều bước, các bước phụ thuộc nhau, và giữa các bước có thứ phải được ghi nhớ. Một yêu cầu hỗ trợ khách hàng đi qua phân loại, tra cứu, soạn phản hồi, rồi mới đến gửi đi. Một quy trình phê duyệt dừng lại chờ người khác. Một báo cáo tháng cần dữ liệu chưa có tại thời điểm bắt đầu.
Khi đưa AI vào chỗ đó, người ngồi trước màn hình biến mất. Ba vai trò mà người đó đang gánh không biến mất theo: chúng phải trở thành một phần của hệ thống.
Ba thứ phải tự xây
Trạng thái phải nằm ngoài cuộc hội thoại
Trong một cửa sổ chat, trạng thái là lịch sử tin nhắn. Nó đủ dùng vì phiên làm việc ngắn và người dùng nhớ phần còn lại.
Một quy trình chạy trong nhiều giờ hoặc nhiều ngày không có được điều đó. Nó cần biết mình đang ở bước nào, bước nào đã hoàn tất, kết quả của từng bước là gì, và điều gì đang chờ. Thông tin này phải nằm ở nơi tồn tại lâu hơn một lần chạy: một cơ sở dữ liệu, một hàng đợi, một bản ghi công việc. Nếu trạng thái chỉ nằm trong ngữ cảnh của mô hình, thì bất kỳ sự cố nào cũng xóa sạch nó, và không ai biết công việc đã đi được đến đâu.
Đây là lý do những bản demo ấn tượng thường không sống sót qua tuần đầu tiên chạy thật. Demo không bao giờ bị ngắt giữa chừng.
Ranh giới phải rõ trước, không phải sau
Câu hỏi thực sự không phải “AI có làm được việc này không”, mà “nếu nó làm sai thì hậu quả là gì, và ai chịu”.
Có những việc mà sai thì tốn thêm vài phút: soạn nháp một email, tóm tắt một tài liệu, phân loại một yêu cầu để định tuyến. Có những việc mà sai thì mất tiền hoặc mất khách: gửi thư cho khách hàng, thay đổi dữ liệu, cam kết một mức giá.
Ranh giới hợp lý thường không nằm ở mức độ khó của công việc, mà ở mức độ khó của việc hoàn tác. Việc dễ hoàn tác thì để hệ thống tự chạy. Việc khó hoàn tác thì để hệ thống chuẩn bị và người bấm nút cuối. Ranh giới này nên được viết ra trước khi triển khai, vì nếu không, nó sẽ được viết ra sau sự cố đầu tiên, và lúc đó nó không còn là một lựa chọn thiết kế nữa.
Kiểm chứng phải là một bước, không phải một cảm giác
Trong buổi thử nghiệm, người dùng đọc kết quả và biết ngay nó đúng hay sai. Đó là một bước kiểm chứng, chỉ là nó không được ghi vào quy trình nào cả.
Khi tự động hóa, bước đó phải tồn tại một cách tường minh. Điều đáng mừng là phần lớn công việc trong doanh nghiệp có sẵn tiêu chí kiểm tra rẻ hơn nhiều so với việc tự làm lại: một con số phải khớp với hệ thống kế toán, một mã đơn hàng phải tồn tại, một tài liệu tham chiếu phải thực sự chứa câu được trích, một đoạn mã phải biên dịch được.
Ở đâu tìm được một phép kiểm tra như vậy, ở đó tự động hóa trở nên đáng tin. Ở đâu không tìm được, đầu ra nên dừng lại ở dạng bản nháp cho người xem.
Vì sao thử nghiệm thành công lại dẫn tới triển khai thất bại
Buổi thử nghiệm đo năng lực của mô hình. Việc triển khai đo năng lực của hệ thống bao quanh mô hình. Hai phép đo này không liên quan nhiều đến nhau như người ta tưởng.
Một cách nhìn thực tế hơn: khi bạn thấy AI làm tốt một việc trong lúc thử, bạn đã chứng minh được rằng phần suy luận không phải là điểm nghẽn. Đó là một thông tin có giá trị. Nhưng nó cũng có nghĩa là toàn bộ phần việc còn lại, tức là trạng thái, ranh giới, kiểm chứng, xử lý lỗi và bàn giao cho người, vẫn còn nguyên ở phía trước.
Phần còn lại đó là công việc kỹ thuật hệ thống bình thường. Nó không mới, không đặc thù cho AI, và đã có lời giải quen thuộc trong hai mươi năm qua. Điều thay đổi chỉ là giờ đây một bước trong quy trình có thể tạo ra kết quả không xác định, nên các bước xung quanh phải chặt chẽ hơn chứ không phải lỏng hơn.
Bốn câu hỏi nên trả lời trước
Trước khi đưa AI vào một quy trình cụ thể, bốn câu hỏi này lọc được phần lớn ý tưởng không khả thi mà không tốn một dòng mã nào:
- Công việc này có bao nhiêu bước, và giữa các bước cần nhớ những gì? Nếu câu trả lời là “một bước, không cần nhớ gì”, đây là bài toán trợ lý chứ không phải bài toán tự động hóa, và nên giải bằng cách đưa công cụ tới tay người dùng.
- Nếu bước này sai, hoàn tác mất bao lâu? Câu trả lời quyết định hệ thống được tự chạy tới đâu.
- Có cách nào kiểm tra kết quả rẻ hơn việc tự làm lại không? Nếu không, đầu ra chỉ nên là bản nháp.
- Khi hệ thống dừng lại, ai nhận được thông báo, và họ thấy đủ thông tin để xử lý chưa? Một quy trình tự động không có đường thoát rõ ràng sẽ tạo ra công việc mới thay vì giảm bớt.
Điều đáng nhớ
Năng lực của mô hình là điều kiện cần, không phải điều kiện đủ. Khoảng cách giữa một câu trả lời tốt và một công việc hoàn tất nằm ở những thứ rất ít liên quan đến AI: nơi lưu trạng thái, ranh giới của quyền tự quyết, và cách biết được kết quả có đúng hay không.
Tin tốt là cả ba thứ đó đều là bài toán đã được giải nhiều lần. Tin kém vui hơn là chúng vẫn phải được giải, và không có mô hình nào giải hộ.