Bản demo Agent của bạn hoạt động tốt. Đó chính là cái bẫy.
Tôi xây dựng các AI agent cho các công ty. Tôi thường thấy cùng một kịch bản lặp đi lặp lại. Mô hình hoạt động tốt trong bản demo. Bạn tung sản phẩm ra thị trường. Sau đó, cứ ba lần chạy trong môi trường production thì có một lần thất bại. Không ai biết tại sao.
Khoảng cách giữa bản demo và production là toán học. Một khi bạn hiểu được toán học, bạn sẽ xây dựng theo cách khác.
Nếu mỗi bước trong agent của bạn có độ tin cậy 95%, nghe có vẻ rất tốt. Nhưng các agent sử dụng các chuỗi bước (chains of steps). Nếu bạn kết nối mười bước lại với nhau, tỷ lệ thành công của bạn giảm xuống còn 60%. Nếu bạn sử dụng hai mươi bước, tỷ lệ thành công giảm xuống còn 36%.
Trong công việc thực tế, các bước thường có tỷ lệ lỗi từ 10% đến 20%. Nếu một agent có tám bước với độ tin cậy 85%, nó sẽ thất bại 75% thời gian.
Vấn đề không nằm ở mô hình. Vấn đề nằm ở xác suất tích lũy (compounding probability).
Một bản demo chỉ cho thấy một luồng xử lý lý tưởng (happy path) duy nhất. Nó sử dụng đầu vào sạch và các chuỗi ngắn. Production sử dụng dữ liệu hỗn loạn từ hàng trăm người dùng. Nó sử dụng các chuỗi dài bao gồm cả các bước ẩn.
Sự thất bại ở các agent không giống như một vụ sập hệ thống (crash). Nó giống như một lỗi âm thầm.
Bước 3 đọc sai một trường dữ liệu. Đầu ra trông vẫn giống như JSON hợp lệ. Bước 4 sử dụng dữ liệu sai đó để suy luận. Từ bước 5 đến bước 8 tiếp tục dựa trên sai lầm đó. Câu trả lời cuối cùng là sai nhưng trông có vẻ hợp lý. Không có nhật ký lỗi (error log) nào để chỉ cho bạn biết nó đã sai ở đâu.
Đừng nói rằng mô hình bị ảo giác (hallucinated) nữa. Mô hình chỉ truyền tiếp dữ liệu sai mà nó nhận được. Hệ thống của bạn thiếu một điểm kiểm soát (checkpoint) để bắt lỗi tại bước 3.
Đừng coi agent như một prompt nữa. Hãy bắt đầu coi nó như một hệ thống.
Hãy tuân thủ các quy tắc sau để xây dựng các agent đáng tin cậy:
Lưu trạng thái (state) bên ngoài agent. Hãy giữ trạng thái trong cơ sở dữ liệu, không phải trong cuộc hội thoại. Nếu một quy trình thất bại ở bước 6, bạn có thể tiếp tục từ bước 6. Bạn không cần phải khởi động lại toàn bộ chuỗi.
Kiểm chứng (validate) tại các ranh giới. Kiểm tra mọi đầu vào và đầu ra dựa trên một schema. Hãy bắt lỗi ngay tại bước mà nó xảy ra. Điều này biến một bí ẩn thành một lỗi có thể phục hồi được.
Đảm bảo các tác dụng phụ (side effects) có tính lũy đẳng (idempotent). Bạn phải thử lại (retry) các bước khi chúng thất bại. Nếu một bước gửi email hoặc thanh toán thẻ, hãy sử dụng một idempotency key. Điều này ngăn chặn các hành động trùng lặp trong quá trình thử lại.
Sử dụng evals trong CI của bạn. Hành vi của agent thay đổi sau mỗi lần tinh chỉnh. Một thay đổi về prompt có thể sửa được một trường hợp này nhưng lại làm hỏng năm trường hợp khác. Hãy sử dụng một bộ kiểm thử (test set) để tự động bắt các lỗi hồi quy (regressions) này.
Chuyển từ bản demo sang một sản phẩm thực tế là câu chuyện về kỹ thuật (engineering). Đó là về xử lý lỗi, quản lý trạng thái và khả năng quan sát (observability). Nó không phải là về việc viết prompt tốt hơn.
Nếu agent của bạn hoạt động chập chờn trong production, đừng tìm kiếm một mô hình lớn hơn. Hãy tìm bước mà chuỗi xử lý bắt đầu đi chệch hướng. Hãy hỏi tại sao hệ thống của bạn đã không bắt được lỗi ở đó.
Source: https://dev.to/sagar_jain4010/your-agent-demo-works-thats-the-trap-4joc
Optional learning community: https://t.me/GyaanSetuAi