Blog / AI / Deep Article
τ-bench kiểm tra AI agent qua trạng thái dữ liệu, quy tắc nghiệp vụ và độ ổn định nhiều lần. Phân tích cơ chế, giới hạn benchmark và cách thử nghiệm agent thực tế.
Một chatbot có thể trả lời rất thuyết phục nhưng vẫn thất bại khi được giao nhiệm vụ có tác động thật: đổi vé, hoàn tiền, cập nhật hồ sơ hoặc sửa dữ liệu. Hệ thống phải thực hiện chuỗi hành động có trạng thái, tuân thủ quy định và kiểm tra kết quả. Một câu trả lời nghe hợp lý không chứng minh thao tác đã hoàn tất.
Nghiên cứu τ-bench năm 2024 của Shunyu Yao và cộng sự đưa ra cách kiểm tra khác: cho AI agent trao đổi với người dùng mô phỏng, sử dụng API và tuân theo chính sách lĩnh vực, rồi so sánh trạng thái cơ sở dữ liệu cuối cùng với mục tiêu định nghĩa trước. Cách tiếp cận này phân biệt khả năng sinh văn bản với năng lực hoàn thành công việc. Tuy nhiên, bộ nhiệm vụ gốc hiện đã được nhóm tác giả đánh dấu là lỗi thời.
Hãy xét yêu cầu: “Tôi muốn đổi món hàng đã nhận sang phiên bản màu đen, nếu không còn hàng thì báo lại, đừng tự ý hoàn tiền.” Chatbot thông thường có thể giải thích quy trình. Agent có quyền công cụ phải đọc đơn hàng, tìm mã sản phẩm, kiểm tra tồn kho, áp dụng điều kiện đổi trả và chỉ gọi API ghi khi đủ căn cứ.
Thành công không phải là câu “đã đổi xong”. Thành công đòi hỏi trạng thái đơn hàng thực sự thay đổi đúng loại, đúng số lượng, đúng tài khoản, không vi phạm chính sách và không thực hiện tác vụ ngoài phạm vi yêu cầu. Nếu API trả lỗi nhưng agent vẫn nói đã hoàn tất, đó là thất bại dù câu trả lời cuối có vẻ chuyên nghiệp.
Vấn đề phức tạp hơn khi hội thoại có nhiều lượt. Người dùng có thể đổi ý, bổ sung điều kiện, trả lời mơ hồ hoặc không đồng ý với phương án thay thế. Agent phải giữ ràng buộc cũ và không suy diễn rằng một lời đồng ý chung cho phép mọi hành động tiếp theo.
τ-bench xây dựng môi trường tương tác với người dùng được mô phỏng bằng mô hình ngôn ngữ, agent có công cụ API và quy tắc nghiệp vụ. Các lượt trò chuyện, đọc dữ liệu và thao tác ghi diễn ra theo trình tự. Sau khi kết thúc, bộ đánh giá đối chiếu trạng thái cuối với mục tiêu nhiệm vụ. Đây là phép đo kết quả thực thi, không chỉ chấm văn bản đầu ra.
Có ba thành phần. Thứ nhất, nhiệm vụ có mục tiêu định nghĩa trước, ví dụ trạng thái đặt chỗ hoặc đơn hàng phải đạt điều kiện cụ thể. Thứ hai, agent phải chọn đúng công cụ và tham số. Thứ ba, môi trường có chính sách giới hạn hành động, chẳng hạn cần xác nhận trước khi hủy một giao dịch.
Khi kết quả chỉ được chấm đúng hoặc sai, một thao tác thiết yếu bị thiếu có thể khiến cả phiên thất bại. Điều này phản ánh nhiều quy trình vận hành: cập nhật sai mã khách hàng không thể được bù bằng phần giải thích dài hơn. Nhưng cách chấm nhị phân cũng có nhược điểm: không thể hiện mức độ nghiêm trọng khác nhau giữa các lỗi.
Một điểm quan trọng của nghiên cứu là pass^k. Nếu một nhiệm vụ được thử nhiều lần với các biến thể tương tác, chỉ khi tất cả lần đều thành công mới tính là ổn định theo tiêu chí này. Nó khác pass@k, vốn quan tâm có ít nhất một lần thành công trong nhiều lần thử hay không.
Giả sử một agent có xác suất thành công độc lập 80% trên một nhiệm vụ. Xác suất thành công cả tám lần là 0,8 mũ 8, khoảng 16,8%. Đây chỉ là ví dụ toán học, không phải số liệu một mô hình thực tế; các lần thử có thể phụ thuộc nhau. Phép tính minh họa vì sao tỷ lệ thành công nghe khá cao vẫn có thể không đủ cho công việc lặp đi lặp lại.
Theo tóm tắt bài nghiên cứu năm 2024, những agent gọi hàm tiên tiến khi đó vẫn có tỷ lệ thành công thấp trên nhiều nhiệm vụ và pass^8 dưới 25% ở môi trường bán lẻ. Con số phản ánh bộ bài toán, mô hình và cấu hình lúc nghiên cứu; không thể dùng làm bảng xếp hạng cho mô hình năm 2026, cũng không đồng nghĩa mọi hệ thống triển khai thật thất bại với xác suất tương tự.
Một hành khách muốn đổi điểm đến. Hệ thống đọc điều kiện và thấy loại vé không cho phép đổi hành trình. Có thể có lựa chọn hủy trong thời hạn quy định, nhưng hủy là hành động khác với yêu cầu ban đầu.
Agent tốt phải giải thích giới hạn, đưa ra lựa chọn hợp lệ và chờ xác nhận rõ ràng trước khi hủy. Nếu tự hủy vì cho rằng đó là phương án “gần đúng nhất”, nó có thể gây thiệt hại. Nếu báo đã đổi vé khi API chỉ trả lỗi, nó tạo thông tin sai. Nếu gọi API ghi sau khi người dùng từ chối, nó vi phạm quyền quyết định.
Ví dụ cho thấy hai lớp kiểm tra phải tồn tại song song. Lớp thứ nhất xác minh trạng thái cuối của dữ liệu. Lớp thứ hai kiểm tra đường đi đến kết quả: ai cho phép hành động, điều kiện nào được đọc, công cụ nào được gọi và lỗi được xử lý ra sao. Chỉ nhìn trạng thái cuối có thể bỏ sót thao tác không được phép rồi bị hoàn tác.
Mô hình ngôn ngữ được tối ưu mạnh cho sinh câu trả lời phù hợp ngữ cảnh. Nhiệm vụ nhiều bước đòi hỏi thêm lập kế hoạch, duy trì trạng thái, chọn API, hiểu lỗi, xử lý dữ liệu bất thường và kiểm soát quyền ghi. Một mô hình có thể giỏi giải thích chính sách nhưng chọn sai mã giao dịch trong tham số công cụ.
Lỗi có thể tích lũy. Bước đầu đọc nhầm mã hàng; bước sau truy vấn nhầm biến thể; bước cuối ghi thay đổi cho đối tượng không đúng. Nếu chỉ kiểm tra câu trả lời cuối, chuỗi sai lệch có thể bị che khuất. Hệ thống production cần lưu bằng chứng từng hành động, không chỉ transcript hội thoại.
Một rủi ro khác là agent hiểu nhầm dữ liệu công cụ trả về thành chỉ dẫn. Ranh giới tin cậy phải phân biệt yêu cầu người dùng, quy tắc vận hành và nội dung không đáng tin từ nguồn ngoài. Một đoạn mô tả sản phẩm không được phép thay đổi quy trình xác nhận giao dịch.
Định nghĩa thành công bằng trạng thái kiểm chứng được. Với nhập liệu, phải đọc lại bản ghi sau khi lưu; với đăng bài, kiểm tra URL và nội dung xuất bản; với thanh toán, đối chiếu mã giao dịch và trạng thái phía máy chủ. Không lấy câu “thành công” do agent tự nói làm biên nhận.
Dùng khóa chống lặp cho thao tác ghi. Khi kết nối chập chờn, agent có thể không biết lệnh đã chạy chưa. Gửi lại bằng khóa mới có thể tạo tác vụ trùng; dùng cùng khóa và truy vấn trạng thái giúp giảm nguy cơ. Khóa chống lặp phải được máy chủ thực thi, không chỉ ghi trong prompt.
Thiết kế quyền tối thiểu. Công cụ đọc và ghi cần tách rõ; hành động hậu quả lớn cần xác nhận tương ứng. Agent không nên tự nâng quyền vì gặp trở ngại. Khi một bước bị chặn, hệ thống cần báo lý do cụ thể và giữ bằng chứng để tiếp tục an toàn.
Thử nhiều đường hội thoại. Một nhiệm vụ nên được kiểm tra với lời yêu cầu ngắn, dài, đổi ý, dữ liệu thiếu, API trả lỗi, thao tác lặp và kết nối ngắt quãng. Điểm trung bình chỉ là một chỉ số; cần thêm tỷ lệ thành công qua nhiều lần, tỷ lệ hành động không được phép và mức độ phục hồi.
Phân loại lỗi. Cần biết agent chọn sai công cụ, sai tham số, bỏ qua xác nhận, đọc sai trạng thái hay báo sai kết quả. Mỗi loại đòi hỏi biện pháp khác nhau: sửa schema, tăng kiểm chứng, cải thiện chính sách hoặc điều chỉnh giao diện xác nhận.
Không nên so sánh điểm từ hai bảng nếu môi trường, nhiệm vụ, số lượt thử hoặc cấu hình khác nhau. Trên kho mã τ-bench, nhóm phát triển cảnh báo các tác vụ bán lẻ và hàng không trong phiên bản gốc đã cũ, đồng thời hướng người đọc sang τ³-bench có sửa đổi và lĩnh vực mới. Điểm cao trên bài toán cũ chưa chắc chuyển thành hiệu quả trên quy trình mới.
Benchmark dùng người dùng mô phỏng cũng có hạn chế. Người thật có thể nhập sai, nói mâu thuẫn, dùng ngôn ngữ địa phương hoặc đổi yêu cầu bất ngờ. API doanh nghiệp có độ trễ, lỗi phân quyền, dữ liệu lịch sử không sạch và cạnh tranh giữa nhiều nhân viên. Môi trường giả lập giúp đo lường lặp lại, nhưng không thay thế thử nghiệm an toàn trên quy trình thực tế.
Trạng thái cuối đúng cũng không bảo đảm mọi hành động trung gian hợp lệ. Agent có thể tạo rồi hủy giao dịch không được phép, cuối cùng để lại trạng thái giống mục tiêu. Vì vậy, cần kết hợp đánh giá kết quả với nhật ký thao tác, chính sách và quyền phê duyệt.
Bắt đầu bằng tập nhiệm vụ có kết quả mong đợi rõ ràng. Mỗi nhiệm vụ lưu trạng thái ban đầu, quyền được cấp, chính sách áp dụng và trạng thái cuối cần đạt. Chạy nhiều biến thể hội thoại trên môi trường thử nghiệm không chứa dữ liệu nhạy cảm thật. Sau mỗi lượt, đọc trạng thái qua API độc lập và đối chiếu nhật ký.
Tiếp theo, đưa vào tình huống lỗi có kiểm soát: API trả 403, timeout sau khi ghi, bản ghi bị người khác sửa, thông tin khách hàng thiếu hoặc người dùng rút lại xác nhận. Kiểm tra agent có dừng đúng lúc, tránh ghi trùng và diễn giải trung thực về trạng thái chưa chắc chắn không. Hành động không thể hoàn tác cần cơ chế phê duyệt trước thực thi.
Cuối cùng, triển khai từng phần với giám sát, giới hạn ngân sách thao tác và khả năng tắt khẩn cấp. Chỉ mở rộng quyền khi bằng chứng kiểm thử đủ mạnh. Đánh giá phải lặp lại sau khi đổi mô hình, prompt, schema công cụ hoặc chính sách vì thay đổi có thể làm biến động hành vi.
τ-bench đặt câu hỏi hữu ích: agent có hoàn thành nhiệm vụ theo trạng thái và quy tắc không, và có làm được nhiều lần không? Nó không chứng minh mọi agent đều thiếu tin cậy, cũng không đưa ra ngưỡng điểm duy nhất phù hợp mọi ngành. Rủi ro khi gợi ý sản phẩm khác xa rủi ro khi chuyển tiền hoặc thay đổi hồ sơ pháp lý.
Giá trị của AI agent không nằm ở việc tự tin nói “đã xong”, mà ở việc hệ thống kiểm chứng được điều đã xảy ra. Chất lượng mô hình chỉ là một thành phần. Quyền hạn, biên nhận, khả năng khôi phục và kiểm thử lặp lại mới quyết định agent có đủ đáng tin để giao việc.
Nguồn tham khảo: τ-bench, Yao và cộng sự (2024); mã nguồn và cảnh báo phiên bản cũ của nhóm tác giả.