Chọn model AI cho tự động hóa: đừng chỉ nhìn demo và giá
AutomationBench cho thấy model dẫn đầu chỉ hoàn thành đúng toàn bộ quy trình ở khoảng một nửa số tác vụ. Với BA/PO, bài học là kiểm thử bằng trạng thái dữ liệu thực tế, nhất là khi AI đọc nhiều nguồn và thực hiện hành động.
Một yêu cầu tự động hóa tưởng như đơn giản có thể chứa nhiều bẫy: tìm đúng khách hàng giữa các tên gần giống nhau trong CRM, đọc email để biết quy tắc xử lý, đối chiếu bảng tính có dữ liệu cũ và mới, rồi cập nhật đúng bản ghi và thông báo đúng người.
Agent có thể báo “đã hoàn tất” dù đã sửa nhầm dữ liệu hoặc gửi email sai đối tượng. Đây là khoảng cách giữa một bản demo trả lời tốt và một quy trình có thể vận hành trong doanh nghiệp.
Với BA và PO, bài học không chỉ là chọn model nào. Quan trọng hơn là xác định: AI phải tạo ra thay đổi gì trong hệ thống, và thay đổi đó được kiểm tra ra sao.
AutomationBench đo khả năng hoàn thành quy trình, không chỉ trả lời
Zapier đã đưa AutomationBench vào Specialized Intelligence Index (SII) của Fireworks. Benchmark này đánh giá liệu AI agent có thể hoàn thành một quy trình nghiệp vụ từ đầu đến cuối trong các mảng như bán hàng, marketing, vận hành, hỗ trợ khách hàng, tài chính và nhân sự.
Mỗi tác vụ mô phỏng một công ty nhỏ, gồm CRM, hộp thư, bảng tính và hệ thống hỗ trợ khách hàng, trải trên 47 ứng dụng mô phỏng. Agent nhận một yêu cầu theo kiểu giao việc nội bộ và phải tự tìm dữ liệu, suy luận quy tắc rồi thực hiện hành động mà không hỏi thêm để làm rõ.
Điểm khác biệt là AutomationBench không chấm theo phần giải thích của AI. Benchmark kiểm tra trạng thái thực tế sau khi chạy:
Bản ghi nào đã được cập nhật?
Email nào đã được gửi?
Ai đã nhận thông báo?
Có thay đổi nào lẽ ra không được thực hiện hay không?
Một tác vụ chỉ được tính là hoàn thành khi mọi điều kiện đều đúng.
AutomationBench có 657 tác vụ riêng tư. Zapier cho biết các tác vụ này được xây dựng từ những mẫu công việc quan sát được trong hơn 2 tỷ tác vụ hằng tháng của 3,7 triệu công ty sử dụng Zapier.
Model dẫn đầu vẫn thất bại ở khoảng một nửa quy trình
Theo kết quả được Zapier công bố, Gemini 4 Argon dẫn đầu với tỷ lệ hoàn thành 51,3%. Claude Sonnet 5.5 đứng thứ hai với 44,7%.
Nói cách khác, ngay cả model dẫn đầu cũng không hoàn thành đúng toàn bộ yêu cầu ở gần một nửa số tác vụ trong benchmark.
Zapier nhấn mạnh một dạng lỗi đáng chú ý: agent thể hiện sự tự tin và báo đã xử lý xong, nhưng dữ liệu thực tế cho thấy kết quả không đúng. Với các luồng có nhiều nguồn dữ liệu và nhiều hành động liên tiếp, lỗi không nhất thiết làm quy trình dừng ngay. Nó có thể chỉ lộ ra khi khách hàng hoặc đồng nghiệp phát hiện hậu quả.
BA/PO nên chuyển yêu cầu AI thành tiêu chí kiểm tra được
Khi AI chỉ hỗ trợ soạn nội dung hoặc tóm tắt email, việc đánh giá có thể linh hoạt hơn. Nhưng khi AI được phép tìm bản ghi, cập nhật CRM, gửi email hoặc chuyển xử lý giữa các hệ thống, acceptance criteria cần cụ thể hơn.
Thay vì chỉ viết:
> AI xử lý yêu cầu thành công.
Hãy xác định rõ những điều cần kiểm tra:
AI phải chọn đúng bản ghi nào.
AI cần dựa vào nguồn dữ liệu nào.
Khi có dữ liệu cũ và mới, tiêu chí xác định thông tin phù hợp là gì.
AI được phép cập nhật trường nào hoặc gửi thông báo cho ai.
Kết quả sau cùng trong hệ thống phải ở trạng thái nào.
Những thay đổi nào không được phép xảy ra.
Đây là cách chuyển yêu cầu “AI thông minh” thành điều kiện quan sát được trong kiểm thử.
Đừng chỉ thử prompt đẹp, hãy thử tình huống nghiệp vụ thật
AutomationBench cho thấy một model có thể làm tốt bài kiểm tra tổng quát nhưng vẫn gặp khó khăn khi phải liên kết nhiều nguồn thông tin và hành động qua nhiều ứng dụng.
BA/PO có thể áp dụng tinh thần này bằng một bộ test nghiệp vụ nhỏ cho các luồng dự kiến đưa AI vào. Không nhất thiết phải xây dựng benchmark phức tạp. Hãy bắt đầu từ các user story có rủi ro hoặc dễ nhầm lẫn.
Ví dụ, một case kiểm thử có thể bao gồm:
| Thành phần | Điều cần kiểm tra |
|---|---|
| Yêu cầu đầu vào | Yêu cầu cập nhật một deal và thông báo cho nhóm liên quan |
| CRM | Có nhiều khách hàng hoặc deal có tên gần giống nhau |
| Email | Có quy tắc xác định nhóm cần nhận thông báo |
| Bảng tính | Có dữ liệu cũ và dữ liệu mới hơn |
| Kết quả mong đợi | Chỉ bản ghi đúng được cập nhật; chỉ đúng nhóm nhận thông báo |
Các tình huống đáng đưa vào test gồm:
Hai khách hàng có tên gần giống nhau.
Dữ liệu cũ và dữ liệu mới cùng tồn tại.
Quy tắc nghiệp vụ nằm trong email thay vì nằm ngay trong yêu cầu.
Một ngoại lệ làm thay đổi cách xử lý thông thường.
Yêu cầu có từ ngữ chưa đủ cụ thể, như “mới nhất” hoặc “ưu tiên”.
Một hành động sai có thể ảnh hưởng đến khách hàng hoặc giao dịch.
Chấm bằng thay đổi trong hệ thống, không bằng lời AI tự báo cáo
Một agent nói “đã cập nhật thành công” không phải là bằng chứng quy trình đã chạy đúng.
Sau mỗi lần thử nghiệm, BA/PO nên kiểm tra trực tiếp các kết quả có thể quan sát:
Bản ghi CRM có đúng bản ghi cần sửa không?
Trạng thái hoặc trường dữ liệu đã đổi đúng chưa?
Email đã được gửi đến đúng người nhận chưa?
Có email hoặc cập nhật nào bị thực hiện thừa không?
Dữ liệu nguồn được sử dụng có phải là phiên bản phù hợp không?
Cách đánh giá này phù hợp với nguyên tắc của AutomationBench: một quy trình chỉ đạt khi toàn bộ kết quả mong đợi đều chính xác, không phải khi agent đưa ra câu trả lời có vẻ hợp lý.
Phân biệt tác vụ một bước và quy trình nhiều bước
Kết quả của Zapier cũng cho thấy giá không dự báo chắc chắn hiệu quả trên các workflow. Một số model chi phí thấp có thể phù hợp với tác vụ đơn lẻ như phân loại ticket hoặc xử lý nội dung ngắn, nhưng hoàn thành một chuỗi hành động qua nhiều ứng dụng là bài toán khác.
Trong backlog, BA/PO nên phân biệt rõ:
AI hỗ trợ một bước: phân loại ticket, tóm tắt email, trích xuất thông tin.
AI thực hiện quy trình: tìm bản ghi, cập nhật CRM, gửi email và điều phối công việc qua nhiều hệ thống.
Với loại thứ hai, Zapier khuyến nghị kiểm tra lại kết quả thay vì tin vào báo cáo của agent. Đối với quy trình liên quan khách hàng hoặc tiền, có thể bổ sung bước tra cứu lại bản ghi và bộ lọc để dừng luồng nếu trạng thái sau cập nhật không đúng kỳ vọng.
Checklist trước khi đưa AI vào workflow
[ ] User story mô tả rõ hành động AI được phép thực hiện.
[ ] Acceptance criteria nêu cụ thể bản ghi, kết quả và thay đổi mong đợi.
[ ] Có test case với tên gần giống, dữ liệu cũ/mới và ngoại lệ.
[ ] Kết quả được chấm bằng trạng thái thực tế trong hệ thống.
[ ] Có bước kiểm tra sau khi AI cập nhật dữ liệu hoặc gửi thông báo.
[ ] Model mới được thử trên một số ví dụ nghiệp vụ trước khi thay thế trong luồng chính thức.
Model trả lời hay chưa chắc là model đáng tin để vận hành workflow. Với BA và PO, giá trị nằm ở việc biến các quy tắc nghiệp vụ thành những điều kiện kiểm tra đủ rõ để phát hiện sai sót trước khi chúng tác động đến khách hàng và quy trình.