Agent Evaluation Metric là gì? Cách tìm đúng lượt khiến AI Agent thất bại

Agent Evaluation Metric (AEM) là cách đánh giá AI Agent theo từng lượt trong hội thoại multi-turn, thay vì chỉ nhìn vào kết quả cuối cùng. AWS giới thiệu framework này để trả lời một câu hỏi khó nhưng rất thực tế: khi một agent thất bại sau nhiều bước, lỗi thực sự bắt đầu từ đâu?

Trong bài kỹ thuật ngày 10/09/2026, AWS áp dụng AEM trước tiên cho correctness và tách nó thành hai phần: truthfulness và completeness. Mỗi response turn hoặc action/tool turn được chấm riêng, sau đó các lỗi downstream được phân biệt với root cause ban đầu.

Agent Evaluation Metric là gì?

AEM là một framework đánh giá decomposable và turn-level cho AI Agent. “Decomposable” nghĩa là chất lượng không bị nén thành một score mơ hồ duy nhất; nó được chia thành các sub-metric có tên rõ ràng. “Turn-level” nghĩa là evaluator nhìn vào từng lượt phản hồi hoặc từng lần agent gọi tool trong toàn bộ trajectory.

Phiên bản AWS mô tả trong bài đầu tiên tập trung vào correctness. Một lượt được xem xét theo hai câu hỏi cơ bản: nội dung/giá trị có đúng không và có đủ những gì lẽ ra phải có không.

AEM không thay thế mọi metric agent khác. Nó bổ sung một lớp chẩn đoán giúp đội phát triển biết lỗi nằm ở turn nào, thuộc loại nào và các lỗi sau đó có thực sự độc lập hay chỉ là hậu quả của lỗi trước.

Vì sao chấm kết quả cuối cùng chưa đủ cho AI Agent nhiều lượt?

Một agent có thể thực hiện năm hoặc mười bước trước khi trả về kết quả. Nếu bước thứ hai truyền sai một tham số, các bước sau có thể tiếp tục chạy “đúng quy trình” nhưng đều dựa trên dữ liệu sai. Task-level evaluator cuối cùng chỉ thấy toàn bộ tác vụ thất bại.

AWS minh họa bằng một agent tạo báo cáo bán hàng: tool đúng được chọn nhưng metric bị truyền thành “profit” thay vì “revenue”. Các lượt sau dùng kết quả này để lọc, tóm tắt và trình bày. Nếu chỉ chấm output cuối, team có thể tưởng có bốn lỗi khác nhau, trong khi root cause thực tế chỉ xuất hiện ở một action turn.

Đây là lý do multi-turn evaluation cần nhìn trajectory, tương tự cách debug một chương trình theo call stack thay vì chỉ nhìn thông báo lỗi cuối cùng. Với agent dài hạn như các hệ thống được mô tả trong bài Persistent AI Agent, nhu cầu này càng rõ.

Correctness trong AEM được tách thành truthfulness và completeness

Truthfulness kiểm tra giá trị mà agent tạo ra có nhất quán với ground truth hay không. Với tool call, đó có thể là giá trị của parameter. Với response turn, đó là các fact và khẳng định được trả lời cho người dùng.

Completeness kiểm tra agent có cung cấp đủ thành phần cần thiết hay không. Ở action turn, evaluator có thể phát hiện missing parameter hoặc extra parameter. Ở response turn, completeness hỏi liệu câu trả lời có bỏ sót một phần yêu cầu của người dùng hay không.

Tách hai lớp này rất hữu ích khi cùng một output có thể “đúng nhưng thiếu” hoặc “đủ nhưng sai”. Nếu chỉ dùng một score tổng, hai kiểu failure sẽ bị trộn vào nhau và dẫn đến cách sửa model/prompt khác nhau.

AEM chấm cả response turn lẫn action/tool turn

Response turn là lượt agent trả lời bằng ngôn ngữ tự nhiên. Ở đây AEM có thể dùng semantic similarity hoặc LLM-as-judge để đánh giá câu trả lời khác wording nhưng cùng ý, đồng thời kiểm tra độ đầy đủ của nội dung.

Action turn là lượt agent gọi công cụ. Evaluator không chỉ xem parameter value mà còn kiểm tra tool nào được chọn, action nào được gọi, có thiếu parameter bắt buộc hay có thêm parameter không mong muốn hay không.

Nhờ cùng một hierarchy, team có thể phân tích một trajectory chứa xen kẽ text, tool call và kết quả tool mà không phải biến mọi thứ thành một task-level score duy nhất.

Failure taxonomy của AEM giúp biến score thành lỗi có thể sửa

AWS đưa ra taxonomy gồm nhiều loại lỗi cụ thể. Với response turn có inconsistent_response và incomplete_response. Với action turn có tool_mismatch, action_mismatch, missing_parameters, extra_parameters và inconsistent_parameter_values.

Điểm đặc biệt là nhãn prior_action_failed. Nhãn này nói rằng lượt hiện tại thất bại không phải vì chính nó tạo ra lỗi mới, mà vì nó đang tiêu thụ output đã sai từ một lượt trước.

Ví dụ, nếu turn 2 chọn sai metric còn turn 3–5 chỉ dùng kết quả từ turn 2, AEM có thể đánh turn 2 là root cause và gắn prior_action_failed cho các lỗi cascade. Team vì vậy biết nên sửa turn 2 trước thay vì điều tra bốn điểm độc lập.

AEM phân biệt root cause với cascading failure như thế nào?

Sau khi mỗi turn có verdict và failure reason, evaluator chạy bước attribution. Một failure tự phát sinh tại turn hiện tại được tính là root cause. Một failure chỉ tồn tại vì phụ thuộc vào output lỗi trước đó được đưa vào nhóm cascading.

Kết quả có thể trả về các trường như first_failure_turn, root_cause, root_cause_count và cascading_count. Những trường này hữu ích hơn một tỷ lệ pass/fail đơn giản khi team cần ưu tiên bug nào để sửa.

AEM cũng theo dõi độ dài action chain. Chuỗi một tool call khác với workflow ba bước trở lên, và lỗi thường khó cô lập hơn khi dependency giữa các action dài lên.

AEM tạo một score tổng bằng cách compose các turn-level verdict

Sau khi decomposition tạo ra verdict theo từng turn và sub-metric, AEM cần một composition rule để đưa chúng về một indicator tổng. Trong bài đầu tiên, AWS dùng mặc định unweighted mean of passing turns.

Điểm quan trọng là composition không bị khóa cứng. Team có thể dùng weighted mean để tăng trọng số cho turn rủi ro cao, dùng gating rule để một critical failure giới hạn score tối đa, hoặc đặt threshold riêng cho từng sub-metric.

Điều này khiến AEM giống một framework đánh giá có cấu trúc hơn là một benchmark duy nhất. Cùng một decomposition có thể được compose khác nhau tùy domain, ví dụ customer support, coding agent hay workflow tài chính.

Ground truth cho multi-turn agent phải ghi cả response và tool call

AEM bắt đầu từ golden dataset: các hội thoại mà câu trả lời đúng và tool call đúng đã được annotate. AWS nói gold reference thường do con người gắn nhãn, hoặc do model mạnh bootstrap rồi được con người review.

Mỗi turn chứa expected output và predicted output. Với action turn, ground truth cần chỉ rõ tool ID, action và arguments. Với response turn, evaluator cần reference đủ rõ để biết câu trả lời có đúng và đủ hay không.

Đây cũng là chi phí lớn khi đưa AEM vào production. Một metric turn-level chỉ hữu ích khi golden data phản ánh chính xác workflow thật. Nếu reference sai hoặc quá cứng, evaluator có thể phạt một trajectory hợp lệ chỉ vì agent đi theo một thứ tự khác.

Semantic similarity và LLM-as-judge được dùng ở đâu?

Đối với text, exact match thường quá cứng. Hai câu có thể diễn đạt khác nhau nhưng cùng nghĩa. AWS vì vậy mô tả semantic similarity scorer để kiểm tra equivalence; scorer có thể dựa trên embedding hoặc LLM-as-judge.

Embedding-based scoring thường nhanh và rẻ hơn, nhưng có thể bỏ qua nuance. LLM-as-judge linh hoạt hơn với câu dài và logic phức tạp, nhưng bản thân judge là một model cần được kiểm soát về chi phí, ổn định và bias.

Trong ví dụ kỹ thuật, AWS dùng threshold 0,5 như một điểm khởi đầu trung tính chứ không phải giá trị tối ưu chung. Ngưỡng phù hợp phải phụ thuộc tolerance của từng domain đối với false positive và false negative.

AEM khác benchmark contamination ở chỗ đánh giá hành vi theo trajectory

Bài Benchmark contamination tập trung vào việc test set có bị model nhìn thấy hoặc bị rò rỉ hay không. AEM lại giải quyết một lớp khác: khi agent chạy nhiều turn và gọi tool, làm sao biết failure bắt đầu ở đâu.

Hai vấn đề có thể cùng xuất hiện trong một evaluation system. Benchmark sạch nhưng chỉ chấm final answer vẫn khó debug agent. Ngược lại, turn-level evaluator rất chi tiết nhưng dùng golden set bị contamination thì score vẫn có thể đánh lừa team.

AEM có thể dùng làm regression signal giữa các phiên bản model và agent

AWS đề xuất theo dõi correctness qua từng release để xem model swap, prompt update hoặc thay đổi tool có làm giảm turn-level success rate không. Team cũng có thể group theo chain length để tìm những workflow dài đang xuống chất lượng nhanh hơn.

Failure-reason distribution là một tín hiệu hữu ích khác. Nếu tool_mismatch tăng sau khi thay model, team biết vấn đề có thể nằm ở tool selection. Nếu inconsistent_parameter_values tăng, cần kiểm tra reasoning hoặc schema grounding.

AEM còn có thể được đối chiếu với latency. Khi agent phải chờ tool quá lâu hoặc accumulation latency tăng, đội vận hành có thể kiểm tra xem chất lượng có giảm theo các session phức tạp hay không.

Framework có thể tích hợp vào Strands Agents nhưng không bị khóa vào AWS

AWS minh họa cách đóng gói AEM thành custom evaluator trong Strands Agents evaluation SDK. Strands cung cấp runner, trace collection và report; AEM bổ sung logic decomposition, taxonomy và turn-level correctness.

Tuy nhiên methodology không phụ thuộc riêng Strands. Một đội dùng framework khác vẫn có thể áp dụng cùng pattern: thu trajectory, so sánh từng turn với gold, gán failure reason, attribute root cause rồi compose score.

Điều này đặc biệt phù hợp với hệ thống orchestration như GitHub HydraFusion, nơi một yêu cầu có thể đi qua nhiều model hoặc workflow khác nhau. Khi pipeline phức tạp lên, final-answer score càng khó nói cho developer biết phần nào cần sửa.

AEM hiện mới tập trung vào correctness, chưa phải thước đo đầy đủ cho agent

AWS nói correctness chỉ là chiều đầu tiên của AEM. Các hướng mở rộng được nêu gồm safety, instruction retention và reasoning depth; bài tiếp theo trong series dự kiến áp dụng cùng framework cho safety.

Vì vậy một AEM score cao hiện không có nghĩa agent an toàn, không bias hoặc luôn tuân thủ policy. Nó chỉ cho thấy agent đạt tốt theo cách correctness đang được định nghĩa và theo golden dataset được cung cấp.

Khi nào Agent Evaluation Metric hữu ích nhất?

AEM hữu ích nhất khi agent có nhiều turn, nhiều tool và dependency giữa các bước. Nếu ứng dụng chỉ là một câu hỏi một câu trả lời, metric turn-level có thể tạo thêm chi phí mà không đem lại nhiều thông tin.

Ngược lại, với coding agent, enterprise assistant, research agent hoặc workflow tự động hóa dài, việc biết “first failure turn” và “prior_action_failed” có thể rút ngắn đáng kể thời gian debug. Team sửa root cause trước rồi chạy lại trajectory để xem các lỗi cascade có tự biến mất hay không.

Giá trị lớn nhất của AEM vì vậy không nằm ở việc tạo thêm một con số. Nó nằm ở cách biến một thất bại dài và khó hiểu thành chuỗi lỗi có cấu trúc: turn nào sai, sai ở dimension nào, và lỗi nào chỉ là hậu quả. Đó là lớp thông tin mà AI Agent cần khi chuyển từ demo một bước sang workflow nhiều bước trong production.