CI của bạn đã đạt. Nhưng Agent của bạn chưa sẵn sàng để vận hành.
Quý trước, chúng tôi đã bàn giao một document agent cho một khách hàng doanh nghiệp.
Bộ kiểm thử của chúng tôi cho thấy tỷ lệ vượt qua là 94%.
Sau ba tuần triển khai thử nghiệm (pilot), agent bắt đầu thực hiện hoàn tiền cho các hóa đơn mà nó không thể đọc được. Nó thực hiện việc này một cách âm thầm. Không hề có lỗi hay nhật ký (log) nào được ghi lại. Agent chỉ đưa ra những câu trả lời sai nhưng trông có vẻ chính xác.
CI của chúng tôi vẫn hiển thị trạng thái "xanh" trong suốt thời gian đó.
Vấn đề không nằm ở model hay prompt. Vấn đề nằm ở 6% dữ liệu mà chúng tôi chưa kiểm thử. 6% đó chính là những dữ liệu thực tế đầu tiên từ người vận hành (operator).
Đó không phải là một trường hợp ngoại lệ (edge case). Đó chính là định nghĩa của việc "sẵn sàng để vận hành" (operator-ready).
"Production-ready" (sẵn sàng để triển khai thực tế) là về cơ sở hạ tầng. Nó có nghĩa là dịch vụ của bạn hoạt động ổn định và chịu được tải.
"Operator-ready" thì khác. Nó có nghĩa là agent của bạn hoạt động được cho một người không phải là người xây dựng ra nó. Nó hoạt động trên dữ liệu mà bạn không thiết kế. Nó đưa ra các quyết định có hệ quả thực tế.
Hầu hết các pipeline kiểm thử đều đo lường tỷ lệ vượt qua dựa trên một tập dữ liệu do bạn tạo ra. Chúng không đo lường những gì xảy ra khi dữ liệu thực tế khác biệt so với tập kiểm thử của bạn.
Một model có tỷ lệ thành công khi kiểm định (validation) là 97% nghe có vẻ tốt. Nhưng hãy nhìn vào 3% thất bại.
Nếu agent của bạn tự động điền các trường còn thiếu bằng các giá trị mặc định trong quá trình thử lại (retry), bạn đã xây dựng một "cỗ máy lỗi âm thầm". Schema thì vượt qua, nhưng dữ liệu thì sai.
Để khắc phục điều này, hãy tách biệt tính hợp lệ của schema khỏi độ tin cậy của nội dung (content confidence).
Chúng tôi đã thêm một điểm số tin cậy (confidence score) vào mỗi phản hồi. Độ tin cậy thấp giờ đây sẽ kích hoạt việc kiểm tra bởi con người thay vì thực hiện retry. Thay đổi này đã giúp phát hiện 14 trong số 18 sự cố đầu tiên của chúng tôi.
Tập kiểm thử của bạn bao quát những gì bạn đã nghĩ tới. Dữ liệu của người vận hành bao quát những gì bạn đã bỏ lỡ.
Trong trường hợp của chúng tôi, chúng tôi đã kiểm thử các hóa đơn đơn trang. Người vận hành lại sử dụng các hóa đơn nhiều trang dưới dạng PDF quét (scanned PDFs). Agent đã thất bại với định dạng mới này.
Đừng chỉ sửa bộ phân tích (parser). Hãy kiểm thử với dữ liệu thực tế của người vận hành trước khi bạn chính thức triển khai (go live).
Trước bất kỳ quá trình bàn giao nào, hiện tại chúng tôi yêu cầu 50 tài liệu từ chính dữ liệu của người vận hành. Chúng tôi không sử dụng dữ liệu tổng hợp (synthetic data). Chúng tôi sử dụng dữ liệu của họ.
Bạn cũng cần một nhật ký kiểm tra (audit trail) đầy đủ. Đừng chỉ ghi lại những gì model trả về. Hãy ghi lại cả những gì model đã quyết định không làm.
Một audit trail tối thiểu cần có:
- Đầu ra kèm theo điểm số tin cậy ở cấp độ trường (field-level)
- Một chỉ báo fallback cho biết liệu agent có thực hiện retry hay không
- Một mã hash đầu vào để có thể chạy lại chính xác tài liệu đó
- Phiên bản model và prompt cụ thể đã được sử dụng
Trước khi bàn giao agent cho người vận hành, hãy kiểm tra năm điều sau:
- Chạy hơn 50 mẫu từ dữ liệu thực tế của người vận hành.
- Tìm kiếm trong nhật ký các đầu ra đã vượt qua kiểm tra schema nhưng gây ra lỗi ở các bước sau (downstream errors).
- Đưa vào các đầu vào sai định dạng (malformed inputs) để đảm bảo agent thất bại một cách an toàn.
- Đảm bảo bạn có thể giải trình chuyện gì đã xảy ra với một tài liệu cụ thể trong vòng chưa đầy 5 phút.
- Kiểm tra xem agent có quyền hạn ở mức thấp nhất có thể hay không.
Tỷ lệ vượt qua kiểm thử của chúng tôi là 94%. Tỷ lệ lỗi trong tháng đầu tiên là 8%.
Sau khi chúng tôi thêm điểm số tin cậy, kiểm thử thực tế và nhật ký tốt hơn, tỷ lệ lỗi đã giảm xuống còn 1,4%.
Điểm kiểm thử không phải là vấn đề. Phạm vi kiểm thử (test scope) mới là vấn đề.
Source: https://dev.to/ethanwritesai/our-ci-passed-your-agent-isnt-operator-ready-2mfn
Optional learning community: https://t.me/GyaanSetuAi