Tác tử AI hỏng chủ yếu theo năm kiểu: một lỗi nhỏ từ đầu phình to qua nhiều bước, vòng lặp cứ làm đi làm lại một thao tác thất bại, tự tin hoàn thành nhầm việc vì mục tiêu mơ hồ, gãy khi trang web hay tệp đổi định dạng, và chi phí leo thang vì bước nào cũng gọi mô hình tính tiền. Phần lớn đoán trước được, và bắt được bằng chỉ dẫn rõ, giới hạn số bước và chi tiêu, cùng việc kiểm kết quả giữa chừng chứ không chỉ kiểm kết quả cuối.
Màn trình diễn tác tử thường chiếu lần chạy đẹp nhất của một việc đã tập dượt kỹ. Việc thật thì lộn xộn hơn: thiếu dữ liệu, trang web chậm, chỉ dẫn mâu thuẫn, đồng nghiệp đổi tên thư mục. Biết tác tử hay gãy ở đâu giúp mình đặt kỳ vọng thực tế và thiết kế việc sao cho có hỏng thì hỏng an toàn.
Vì sao lỗi nhỏ phình to trong việc nhiều bước?
Mỗi bước tác tử làm đều dựa trên cách nó đọc bước trước. Khả năng làm đúng một bước có cao tới đâu mà chưa tuyệt đối thì khả năng làm đúng liền hai mươi bước vẫn thấp hơn rõ rệt. Đó là phép tính đơn giản, và là lý do việc dài của tác tử kém tin cậy hơn việc ngắn.
Lỗi còn chồng lên nhau. Giả sử tác tử trích dữ liệu hoá đơn đọc nhầm kiểu ghi ngày của một nhà cung cấp ngay từ đầu. Nó xếp hoá đơn sai tháng, đánh dấu nhầm những cái quá hạn, rồi soạn thư nhắc nợ cho những khách đã trả tiền. Bước nào cũng hợp lý nếu xét theo bước trước; vấn đề nằm ở điểm xuất phát.
Mô hình ngôn ngữ hiếm khi tự nói rõ ở mỗi bước là mình không chắc. Tác tử có thể đoán rồi đi tiếp thay vì dừng, nhất là khi chỉ dẫn thúc nó “hoàn thành nhiệm vụ”. Vì vậy chỉ dẫn nên cho phép và khuyến khích dừng lại khi thông tin không rõ.
Cách ứng phó thực tế là chia việc dài thành các chặng ngắn, giữa các chặng có kiểm, và kiểm đầu ra đầu tiên của mỗi lần chạy trước khi tác tử xây tiếp lên đó. Bắt lỗi ở bước hai rẻ hơn nhiều so với gỡ hai mươi bước về sau.
Năm kiểu hỏng phổ biến và cách xử lý
Phần lớn sự cố rơi vào một trong các khuôn này.
| Kiểu hỏng | Biểu hiện | Cách sửa |
|---|---|---|
| Lỗi dồn | Một lần đọc nhầm từ đầu lan ra cả việc | Chia chặng ngắn, kiểm kết quả giữa chừng, kiểm đầu ra đầu tiên |
| Vòng lặp | Lặp đi lặp lại một thao tác hay một lần tìm thất bại | Giới hạn số bước, thời gian, dặn dừng sau vài lần thất bại |
| Sai mục tiêu | Tự tin làm xong một việc, nhưng không phải việc mình muốn | Bản giao việc cụ thể, kèm ví dụ kết quả mong đợi |
| Đầu vào gãy | Hỏng hoặc đoán mò khi trang web, biểu mẫu, tệp đổi định dạng | Theo dõi lỗi, ưu tiên nguồn dữ liệu ổn định, cảnh báo khi kết quả bất thường |
| Chi phí vọt | Hoá đơn tăng vì bước nào cũng gọi mô hình hay dịch vụ tính tiền | Ngân sách theo việc và theo tháng, cảnh báo, rà các lần chạy đắt |
Có sự cố thì trước hết xác định nó thuộc khuôn nào. Cách sửa đi theo khuôn, không theo cái lỗi cụ thể.
Dấu hiệu tác tử đang chệch hướng
Số bước nhiều hơn hẳn thường lệ. Việc bình thường mười thao tác mà nay năm mươi thường là đang rối hoặc kẹt vòng lặp.
Cứ quay lại cùng một trang, một tệp. Đọc đi đọc lại mà không tiến triển cho thấy nó không tìm thấy thứ nó chờ.
Báo cáo mơ hồ. “Đã hoàn thành nhiệm vụ” mà không có chi tiết thường che một thất bại nửa chừng.
Kết quả đều quá mức. Dòng nào cũng cùng một ngày, cùng một giá trị thì có thể nó đang lấp chỗ trống bằng giá trị mặc định.
Xin lỗi rồi thử lại liên tục. Vòng xin lỗi – thử lại là dấu hiệu kinh điển của vòng lặp.
Làm thứ mình không nhờ. Hành động thừa ngoài bản giao việc có thể do nó hiểu sai mục tiêu hoặc gặp nội dung dắt mũi.
Chi phí nhảy vọt mà việc không tăng. Lượng dùng tăng đột ngột với cùng khối lượng việc đáng để điều tra.
Không giải thích được lựa chọn. Hỏi “vì sao làm vậy?” mà câu trả lời không nhất quán là dấu hiệu quyết định đó chỉ là đoán.
Thiết kế việc sao cho có hỏng thì hỏng an toàn
Cứ coi như tác tử thỉnh thoảng sẽ sai, và tính trước cho chuyện đó.
- Làm mục tiêu thật cụ thể. Tả kết quả hoàn chỉnh, tốt nhất có ví dụ, để “xong” chỉ có một nghĩa.
- Chia việc dài thành chặng. Trích ra, rồi kiểm, rồi mới hành động, giữa các chặng có điểm dừng hoặc điểm kiểm.
- Dặn tác tử khi nào phải dừng. Chẳng hạn: “Thử ba lần không tìm được thông tin thì dừng và báo lại.”
- Ưu tiên đầu ra hoàn tác được. Bản nháp, đề xuất, bản ghi mới, thay vì gửi đi, xoá hay ghi đè.
- Đặt giới hạn số bước, thời gian, tiền. Để có hỏng thì hỏng nhanh và rẻ.
- Kiểm đầu ra đầu tiên của mỗi lần chạy. Năm giây kiểm lúc đầu đỡ một giờ dọn dẹp về sau.
- Giữ phương án dự phòng. Biết việc sẽ được làm tay ra sao nếu tác tử trục trặc hay kém tin cậy một thời gian.
Hai lần hỏng và bài học rút ra
Một công ty du lịch ở Đà Nẵng cài tác tử gom giá tour từ website các đối tác mỗi sáng. Ba tuần đầu êm ru. Rồi một đối tác làm lại giao diện trang, và tác tử bắt đầu đọc mức giá “chỉ từ” trên băng rôn khuyến mãi thành giá của mọi tour. Không có gì sập; chỉ là con số sai. Nhân viên chỉ phát hiện khi một khách đọc ra một mức giá rẻ tới mức khó tin. Cách sửa là cảnh báo khi giá nào nhảy quá một tỉ lệ đã định chỉ sau một đêm, cộng với mỗi tuần kiểm ngẫu nhiên một đối tác.
Một nhóm phần mềm nhỏ giao cho tác tử lập trình một việc mơ hồ: “dọn lại phần báo cáo”. Tác tử sửa hàng chục chỗ trông rất hợp lý, đổi tên hàm, xoá đoạn mã nó cho là không dùng, trong đó có đoạn mà phần khác của hệ thống đang cần. Kiểm thử bắt được một phần; phần còn lại vài ngày sau mới lộ. Giờ nhóm viết việc với phạm vi hẹp và vạch đích rõ ràng, và duyệt thay đổi trước khi gộp vào mã chính.
Ở cả hai trường hợp, tác tử không hề “nổi loạn”. Nó làm theo những gì nó hiểu, mà không có phanh ở đúng chỗ cách hiểu dễ trượt nhất. Bài học nằm ở thiết kế việc và các điểm kiểm, không nằm ở trí khôn của mô hình.
Câu hỏi thường gặp
Tác tử AI có đang tin cậy hơn không?
Nhìn chung là có, khi mô hình và công cụ tốt lên, nhất là với việc định nghĩa rõ như lập trình. Độ tin cậy với việc kinh doanh lộn xộn, mở thì còn chênh nhiều, nên cứ thiết kế việc với giả định thỉnh thoảng sẽ hỏng.
Vì sao tác tử báo xong mà thật ra chưa xong?
Mô hình có xu hướng viết ra một câu chốt gọn gàng, và tác tử có thể chưa tự kiểm kết quả. Yêu cầu báo cáo có bằng chứng cụ thể như số lượng, đường dẫn, rồi kiểm mẫu.
Làm sao để tác tử không đốt tiền?
Đặt ngân sách và cảnh báo ở phía nhà cung cấp, giới hạn số bước mỗi việc, và mỗi tuần xem lại những lần chạy đắt nhất. Chi phí bất thường thường chỉ ra vòng lặp hoặc việc bị hiểu sai.
Chỉ dẫn càng dài càng chi tiết có luôn tốt hơn không?
Rõ và cụ thể thắng dài. Chỉ dẫn quá dài dễ có chỗ mâu thuẫn hoặc vùi mất luật then chốt. Giữ bản giao việc gọn, đặt các giới hạn quan trọng nhất ở chỗ dễ thấy.
Có nên sửa lỗi tác tử bằng cách thêm luật không?
Đôi khi, nhưng trước hết kiểm xem lỗi do mục tiêu mơ hồ, đầu vào đổi hay quyền tự chủ quá rộng. Nhiều khi một chặng việc ngắn hơn hay thêm một điểm kiểm hiệu quả hơn thêm luật.
Khi nào nên bỏ ý định giao một việc cho tác tử?
Khi đã thử đàng hoàng với chỉ dẫn rõ mà thời gian kiểm và sửa vẫn ngang tự làm, hoặc lỗi cứ lọt tới tay khách. Có những việc đơn giản là chưa hợp lúc này.
