TASTE: Khi benchmark cho AI agent cuối cùng cũng được làm nghiêm túc

Nếu bạn đang theo dõi mảng AI agent gần đây, chắc cũng đã thấy một pattern khá quen: model mới ra, chạy benchmark, đạt score cao ngất, rồi deploy vào production thì... không như kỳ vọng. Mình đã gặp chuyện này không ít lần, và phần lớn vấn đề nằm ở chỗ các benchmark hiện tại đang quá dễ, quá hẹp, và không thực sự phản ánh những gì agent phải làm ngoài thực tế.

Đó là lý do paper TASTE (A Matter of TASTE: Improving Coverage and Difficulty of Agent Benchmarks) vừa drop trên Hugging Face khiến mình khá chú ý.

Vấn đề cốt lõi: benchmark đang bị "học vẹt"

Hiện tại, cách tạo benchmark cho tool-using agent thường đi theo flow này: người ta nghĩ ra một task nghe có vẻ thực tế, viết task description, rồi mới map nó vào các tool mà agent cần gọi. Nghe có vẻ ổn, nhưng vấn đề là cách này dễ bị bias theo những task mà người viết benchmark quen nghĩ tới thường là các happy path, ít edge case, và tool combination khá đơn giản.

Kết quả là các model lớn như GPT-4 hay Claude đạt score rất cao trên những benchmark này, nhưng khi gặp task phức tạp hơn một chút trong thực tế chẳng hạn cần chain nhiều tool theo thứ tự cụ thể, hoặc xử lý output của tool này làm input cho tool kia thì performance tụt đáng kể.

Mình thấy đây là một dạng benchmark overfitting ở cấp độ dataset design, không phải model. Và đó là thứ khó fix hơn nhiều.

TASTE lật ngược cái flow đó

Thay vì task → tool sequence, TASTE làm ngược lại: tool sequence → task.

Cụ thể hơn, pipeline của TASTE hoạt động như sau:

Enumerate tool sequences: Thay vì nghĩ task trước, TASTE bắt đầu bằng cách liệt kê các chuỗi tool calls có thể xảy ra bao gồm cả những combination phức tạp, multi-step, và ít phổ biến hơn.
Synthesize realistic tasks: Từ mỗi tool sequence đó, TASTE dùng LLM để sinh ra task description nghe tự nhiên và hợp lý kiểu như "người dùng thực sự sẽ yêu cầu gì nếu agent cần thực hiện đúng chuỗi tool calls này".
Verify và filter: Các task được synthesize xong sẽ qua bước verification để đảm bảo chúng thực sự yêu cầu đúng tool sequence đó, không phải shortcut được bằng cách khác.

Cái hay ở đây là bằng cách bắt đầu từ tool sequences, bạn tự động có được coverage rộng hơn nhiều vì bạn đang sample từ không gian của tất cả các cách kết hợp tool có thể, thay vì bị giới hạn bởi trí tưởng tượng của người viết benchmark.

Tại sao điều này quan trọng với dân làm AI agent

Nếu bạn đang build hoặc evaluate AI agent dù là coding agent, customer support bot, hay workflow automation thì cái mình lo nhất không phải là model có pass benchmark không, mà là liệu benchmark đó có đang đo đúng thứ mình cần không.

Theo kinh nghiệm của mình, khi integrate agent vào các hệ thống có nhiều tool (API calls, database queries, file operations...), phần fail nhiều nhất thường là ở những sequence phức tạp: agent gọi tool A, lấy kết quả, rồi cần dùng kết quả đó để quyết định có gọi tool B hay C, với params phụ thuộc vào output của A. Đây là loại task mà benchmark cũ rất ít cover.

TASTE về cơ bản đang address đúng cái gap này.

So sánh nhanh hai approach

| Tiêu chí | Benchmark truyền thống | TASTE |
|---|---|---|n| Điểm khởi đầu | Task description | Tool sequence |
| Coverage | Bị giới hạn bởi người viết | Systematic, rộng hơn |
| Độ khó | Thường thiên về happy path | Bao gồm complex chains |
| Verification | Manual hoặc heuristic | Automated |
| Bias | Task-space bias | Ít bias hơn |
| Scalability | Tốn công viết tay | Có thể tự động hóa |

Mình đặc biệt chú ý cột scalability vì một trong những lý do benchmark AI agent hiện tại còn hạn chế là tạo task tốt rất tốn công. TASTE giải quyết điều này bằng cách automation cả pipeline.

Model "strong" trên benchmark cũ sẽ thấy gì?

Paper đề cập rằng các model trông có vẻ mạnh trên existing benchmark sẽ đối mặt với bài test khó và rộng hơn nhiều khi chạy trên TASTE-generated benchmark. Đây không phải là kết quả bất ngờ, nhưng nó confirm một điều mình đã nghi ngờ từ lâu: leaderboard hiện tại đang overestimate khả năng thực của agent.

Anh em nào đang dùng benchmark score để justify việc deploy agent vào production nên lưu ý điểm này. Score cao trên một benchmark hẹp không có nghĩa là agent sẽ handle được diverse real-world requests.

Liên hệ với các paper cùng hướng

Cũng trong tuần này, có một số paper liên quan đáng đọc thêm nếu bạn quan tâm mảng này:

GenesisFunc đang tackle vấn đề tương tự nhưng từ góc độ data generation cho function-calling
CRAB-Bench focus vào complex task dependencies và human-aligned simulation cũng là một hướng hay để evaluate agent realistically hơn
Pioneer Agent thú vị ở chỗ nó nghiên cứu cách improve small language model liên tục trong production setting thực tế hơn cho những team không có budget chạy GPT-4 cho mọi thứ

Mình thấy đang có một làn sóng rõ ràng trong research: cộng đồng đang dần nhận ra rằng cách chúng ta evaluate agent đang là bottleneck, không phải khả năng của model. Và TASTE là một bước đi đúng hướng để fix điều đó.

Practical takeaway nếu bạn đang build agent

Ngay cả khi bạn không đọc paper này, có một lesson quan trọng bạn có thể apply ngay:

Khi design test suite cho agent của mình, thay vì chỉ nghĩ "user sẽ hỏi gì", hãy thử bắt đầu từ "agent cần gọi những tool nào theo thứ tự nào" rồi mới ngược lại tạo test case. Bạn sẽ tự nhiên cover được nhiều edge case hơn và phát hiện ra những chỗ agent fail mà bạn chưa nghĩ tới.

Mình đã thử approach này với một project internal gần đây và tìm ra khá nhiều bug thú vị liên quan đến error handling khi tool chain bị interrupt giữa chừng thứ mà test case viết theo kiểu truyền thống không bao giờ catch được.

TASTE đang làm điều tương tự nhưng ở quy mô lớn hơn và có systematic verification. Mình sẽ theo dõi xem team này release code và dataset không nếu có thì đây sẽ là một tool khá hữu ích để integrate vào evaluation pipeline.