NVIDIA chia sẻ cách đánh giá AI Agent: Từ gọi công cụ đến hoàn thành nhiệm vụ

Khi bạn triển khai một AI agent, câu hỏi then chốt là liệu nó có thể thực hiện một chuỗi công việc thông qua hàng chục lệnh gọi công cụ (tool calls) tuần tự trong môi trường thực tế hay không, và liệu nó có thể phục hồi khi một bước bị lỗi hay không. Việc chấm điểm dựa trên việc mô hình nghe có vẻ "đúng" hay không gần như không cho bạn biết gì về việc công việc đó đã hoàn thành hay chưa.

Khoảng cách đó là lý do tại sao việc đánh giá agent đã phải tiến hóa từ việc chấm điểm một lệnh gọi hàm đơn lẻ sang chấm điểm toàn bộ tác vụ, với việc gọi công cụ đóng vai trò là sợi dây kết nối bên dưới. Bài viết này phác thảo quá trình đó và giải thích lý do tại sao gần như mọi bộ tiêu chuẩn đánh giá (benchmark) agent nghiêm túc hiện nay đều dựa trên việc sử dụng công cụ.

Tại sao các tiêu chuẩn đánh giá LLM thông thường là chưa đủ?

Các bộ công cụ đánh giá ban đầu được xây dựng cho các tác vụ tĩnh. Bộ công cụ mã nguồn mở, không phụ thuộc vào mô hình đầu tiên đã tách biệt mô hình khỏi giao thức đánh giá.

Các agent đã phá vỡ giả định này. Khi hoạt động qua các tác vụ đa bước, một agent sẽ gọi các công cụ, xử lý lỗi và quan sát kết quả qua nhiều bước, khiến cho một chuỗi đầu ra đơn lẻ trở nên không đủ. Berkeley Function-Calling Leaderboard (BFCL) đã ra đời để đánh giá khả năng chọn hàm và độ chính xác của đối số trong các kịch bản đơn lượt và đa lượt. Tuy nhiên, BFCL chỉ đánh giá các lệnh gọi riêng lẻ—một lệnh `issue_refund` hợp lệ vẫn sẽ thất bại nếu các bước kiểm tra hoặc cập nhật cơ bản bị bỏ qua. Độ chính xác của lệnh gọi là cần thiết, nhưng chưa đủ.

Từ chấm điểm lệnh gọi đến chấm điểm môi trường

Đánh giá agent toàn diện hiện đòi hỏi một môi trường thực thi đầy đủ: một môi trường thực thi từng lệnh gọi công cụ, theo dõi trạng thái qua các bước và đọc kết quả sau đó để quyết định xem công việc đã được hoàn thành hay chưa.

Hai lớp chấm điểm nằm bên trên nó:

Cấp độ bước (Step-level) cho bạn biết chuỗi bị đứt ở đâu, đây là điều bạn cần khi gỡ lỗi hoặc nhắm mục tiêu nỗ lực tinh chỉnh (fine-tuning); E2E (End-to-End) gộp lỗi ở bước một và lỗi ở bước chín thành cùng một kết quả "tác vụ thất bại". E2E là những gì người dùng của bạn thực sự trải nghiệm, đó là lý do tại sao hầu hết các đánh giá trong môi trường sản xuất (production) đều lấy nó làm tiêu chuẩn để quyết định phát hành, trong khi vẫn giữ lại việc theo dõi cấp độ bước để gỡ lỗi.

Hai điểm số đó là hai cách đọc của một đối tượng: dấu vết (trace). Dấu vết là nhật ký có thứ tự của một lần thử nghiệm duy nhất: thông báo của người dùng, từng bước thực hiện và trạng thái môi trường khi lần thử nghiệm dừng lại. Chấm điểm quy trình (Process scoring) đánh giá các hàng. Chấm điểm E2E đánh giá trạng thái cuối cùng.

Một lần chạy benchmark đo lường những gì

Một benchmark về gọi công cụ sẽ chấm điểm ba thứ theo thứ tự: quyết định sử dụng công cụ, chọn đúng công cụ và điền các đối số của nó. Một mô hình tìm đến công cụ khi một câu trả lời trực tiếp là đủ sẽ thất bại cũng tệ hại như việc nó bỏ qua một công cụ mà nó cần. Chi phí và độ trễ được tính thêm vào, dựa trên độ dài và thời gian chạy của lệnh gọi.

Mỗi lần chạy được tổng hợp thông qua một hệ thống phân cấp cố định: Benchmark → Trial (Thử nghiệm) → Task (Tác vụ) → Turn (Lượt) → Step (Bước):

Một bước thường là một lệnh gọi công cụ, và mọi điểm số bên trên nó đều được tổng hợp từ các bước đó. Các chỉ số đáng theo dõi tập trung vào ba trục: độ chính xác, độ dài (verbosity), chi phí (xem Bảng 1 bên dưới).

Các cặp chỉ số rất quan trọng: tỷ lệ thành công mà thiếu tính nhất quán chỉ là ước tính điểm trên một hệ thống ngẫu nhiên (một mô hình đạt 90% rồi 74% là một lựa chọn tệ hơn so với mô hình duy trì ổn định ở mức 84%); độ chính xác của lệnh gọi công cụ mà thiếu độ chính xác của đối số sẽ che giấu các lỗi điền dữ liệu (slot-filling).

Số bước thường là trục thay đổi nhiều nhất giữa các mô hình trên cùng một tác vụ — bốn bước so với mười lăm bước — mặc dù trên các bộ như Terminal-Bench 2.0, số bước mỗi lượt cũng thay đổi, vì vậy trục nào thay đổi nhiều nhất còn tùy thuộc vào từng benchmark. Gọi công cụ song song giúp giảm số bước và độ trễ, nhưng không giảm số lượng lệnh gọi: một lượt một bước kích hoạt bốn công cụ vẫn tạo ra bốn lệnh gọi. Hãy tổng hợp theo thứ tự; đừng lấy trung bình số bước rồi gọi đó là điểm benchmark.

Cách đọc một kết quả đánh giá

Hai benchmark có thể cùng tuyên bố kiểm tra việc gọi công cụ và đưa ra các con số không thể so sánh được. Ba khía cạnh giải thích phần lớn khoảng cách này:

Sự nhiễm dữ liệu (Contamination) hiện nay đã vượt ra ngoài việc rò rỉ dữ liệu huấn luyện sang các biến thể trực tiếp: các agent tìm kiếm web truy xuất đáp án trong quá trình đánh giá, và các tập dữ liệu trên Hugging Face nhanh chóng bị cào lại vào kho dữ liệu tiền huấn luyện. Các đánh giá trong miền riêng tư (private domain) giải quyết vấn đề này bằng cách không thể cào dữ liệu.

Bảng 2 bên dưới là một dấu vết công khai từ một lần chạy benchmark thực tế sử dụng chấm điểm cấp độ bước và E2E, nơi bộ công cụ thay vì một ticket nhân tạo cung cấp các công cụ, người dùng và tiêu chí hoàn thành.

Nhìn vào các kết quả đầu ra, điều quan trọng là phải xem 5 mục cuối: kiểm tra E2E, điểm E2E, điểm cấp độ bước, độ chính xác của lệnh gọi công cụ và độ chính xác của đối số. Kiểm tra E2E cho chúng ta biết rằng các bài kiểm tra liên quan đến lỗi mà nó tìm cách sửa đã vượt qua, nghĩa là điểm E2E trong trường hợp này là 1 (is_resolved: true). Chỉ số tiếp theo là điểm cấp độ bước cho biết bao nhiêu bước mô hình thực hiện là thực sự cần thiết. Nhìn vào điểm số cho bảng trên, cấp độ bước là 3/4 do một trong các bước trong trường hợp này là dư thừa – cụ thể là bước 2. Trong trường hợp này, nó ảnh hưởng trực tiếp đến độ chính xác của lệnh gọi công cụ, vốn cũng nhận được 3/4 do sai sót nhỏ đó. Đối với dấu vết này, chỉ số cuối cùng của chúng tôi là độ chính xác của đối số cho thấy tất cả các đối số được điền chính xác mà không có đối số nào bị định dạng sai.

Tại sao các benchmark đang hội tụ về việc sử dụng công cụ

Ranh giới giữa "gọi một công cụ" và "hoàn thành một tác vụ" không còn tồn tại: hầu hết các benchmark đo lường khả năng tổng quát hiện nay cũng đo lường việc sử dụng công cụ vì các mô hình không được chạy mà không có công cụ trong bất kỳ triển khai khả thi nào. Một benchmark từ chối quyền truy cập công cụ sẽ chấm điểm một khả năng mà không ai triển khai thực tế.

Không phải benchmark nào cũng chứng minh được điều này. HumanEval chạy Python được tạo ra dựa trên các bài kiểm tra đơn vị (unit tests), cung cấp xác minh thực thi, nhưng không có lệnh gọi công cụ và không có môi trường để tác động vào. SWE-bench là nơi sự thay đổi trở nên rõ ràng: giải quyết một vấn đề thực tế trên GitHub có nghĩa là điều hướng một cơ sở mã, viết một bản vá và vượt qua bộ kiểm tra — các lệnh gọi đọc tệp, tìm kiếm và chỉnh sửa theo trình tự. Điểm số đo lường kết quả, nhưng quỹ đạo bên dưới hoàn toàn bao gồm các lệnh gọi công cụ. Trong nhiều trường hợp, các benchmark bạn đã chạy cho khả năng tổng quát thực chất đã đang thực hiện việc sử dụng công cụ. Điều đó định hình lại câu hỏi quan trọng:

Các benchmark học thuật đo lường giới hạn khả năng của mô hình một cách trừu tượng. Các benchmark doanh nghiệp trả lời câu hỏi hẹp hơn, hữu ích hơn: nó có thể làm công việc của tôi không — các tác vụ của bạn, dựa trên các API của bạn, theo các chính sách của bạn? Benchmark càng gần với môi trường sản xuất, điểm số của nó càng nên được cân nhắc trong quyết định của bạn.

Phân tích Nemotron 3.5 Lightning qua lăng kính này

Hãy đọc bộ tiêu chuẩn được công bố của NVIDIA Nemotron 3.5 Lightning dưới dạng hoàn thành tác vụ và thời gian hoàn thành, không phải độ chính xác của lệnh gọi riêng lẻ. Banking chấm điểm việc hoàn thành qua một cuộc hội thoại ngân hàng đa lượt — dấu vết hoàn tiền ở quy mô lớn, không phải một lệnh gọi đơn lẻ. GDPval-AA v2 chấm điểm công việc agent thực tế từ các đầu ra công việc thực tế, được đánh giá theo cặp bởi một hội đồng giám khảo LLM với Elo được neo vào mức cơ sở 1.000 chuyên gia con người — kiểu xác thực của con người giúp điểm số của giám khảo đáng tin cậy. Trên PinchBench, Nemotron 3.5 Lightning đạt độ chính xác 86% trong khi hoàn thành 10.000 tác vụ nhanh hơn 30% so với Qwen3.6 35B ở độ chính xác tương đương — một mô hình hoàn thành hiệu quả sẽ đánh bại mô hình có điểm chính xác cao hơn nhưng lại tiêu tốn nhiều bước và token hơn.

Điểm số công khai là một tín hiệu tuyệt vời, nhưng chúng không nên được coi là rào cản phát hành. Việc điều chỉnh mô hình cho tác vụ và trường hợp sử dụng của bạn vẫn quan trọng như mọi khi.

Benchmark khối lượng công việc của riêng bạn

Xác minh các hậu quả trong môi trường, sử dụng giám khảo cho ngôn ngữ, và sử dụng độ chính xác của lệnh gọi công cụ và độ chính xác của đối số để tìm nơi chuỗi bị đứt.

Để tái tạo các con số đã công bố, Nemotron cung cấp các tài liệu tái lập bao gồm các cấu hình đằng sau điểm số trên thẻ mô hình. Hãy thử trên build.nvidia.com, lấy trọng số từ Hugging Face hoặc làm theo hướng dẫn NIM.

Gọi công cụ trong lĩnh vực benchmark LLM là nền tảng mà các đánh giá ngày nay dựa vào. Có khả năng xây dựng, đọc và hiểu các đánh giá này là điều cần thiết để đưa ra quyết định sáng suốt cho trường hợp sử dụng của bạn.

Tìm hiểu thêm

Cập nhật thông tin về NVIDIA Nemotron bằng cách đăng ký nhận tin tức từ NVIDIA và theo dõi NVIDIA AI trên LinkedIn, X, YouTube và kênh Nemotron trên Discord.

Truy cập các mô hình Nemotron mở trên Hugging Face và bộ sưu tập các dịch vụ vi mô NIM cùng các ví dụ dành cho nhà phát triển trên build.nvidia.com.