Evals cho WebMCP

Kasper Kulikowski
Kasper Kulikowski

Đã xuất bản: Ngày 19 tháng 5 năm 2026, Cập nhật gần đây nhất: Ngày 28 tháng 5 năm 2026

WebMCP hỗ trợ các nhân viên hỗ trợ sử dụng mô hình AI tạo sinh. Để kiểm thử bất kỳ hệ thống nào sử dụng AI tạo sinh, các bài kiểm thử của bạn cần hỗ trợ kết quả xác suất: một thông tin đầu vào có thể dẫn đến hàng nghìn câu trả lời với mức độ chính xác khác nhau. Kỹ thuật kiểm thử này được gọi là đánh giá hoặc evals.

Trước khi phát hành các công cụ vào phiên bản chính thức, bạn phải xác nhận rằng nhân viên hỗ trợ hiểu rõ thời điểm gọi công cụ, cách thực thi công cụ và những câu trả lời nào là chấp nhận được. Giải quyết các trường hợp có thể xảy ra lỗi trước khi chúng xảy ra.

Viết các bài đánh giá để kiểm thử các điểm tiếp xúc của hệ thống với mô hình ngôn ngữ lớn (LLM):

  • Kiểm tra để đảm bảo rằng mô hình hiểu rõ mục đích của công cụ dựa trên nội dung mô tả và giản đồ của công cụ.
  • Xác minh rằng mô hình chọn đúng công cụ với các tham số chính xác để hỗ trợ ý định của người dùng.
  • Xác nhận rằng mô hình đang hành động dựa trên thông tin mà mô hình nhận được, chẳng hạn như sử dụng thông tin để gọi một công cụ khác.
  • Xác minh hành trình thành công của người dùng. Với ý định của người dùng, nhân viên hỗ trợ có thể hoàn thành thành công hành trình của người dùng trên trang web của tôi bằng các công cụ được cung cấp không?

Bạn nên tiếp tục viết các bài kiểm thử xác định cổ điển cho mọi tương tác của hệ thống không giao tiếp với mô hình.

Chế độ lỗi

Nhà phát triển nên kiểm thử hệ thống của họ để ngăn lỗi xảy ra trước khi chúng xảy ra. Để làm như vậy, bạn cần hiểu rõ thời điểm hệ thống có thể gặp lỗi, cả khi hệ thống hoạt động độc lập và khi tương tác với các yếu tố bên ngoài. Đối với WebMCP, bản thân công cụ có thể gặp lỗi và nhân viên hỗ trợ có thể không sử dụng được các công cụ như dự kiến.

Các công cụ WebMCP có thể gặp lỗi và khi nhân viên hỗ trợ có thể gặp lỗi với các công cụ WebMCP. Ví dụ: giả sử người dùng muốn thêm một chiếc áo phông vào giỏ hàng.

Lỗi Ví dụ Khắc phục sự cố
Nhân viên hỗ trợ không chọn được công cụ chính xác hoặc trực tiếp gọi công cụ không chính xác.

Nhân viên hỗ trợ bỏ qua addToCart và chuyển trực tiếp đến checkout.

  • description của công cụ có rõ ràng, đầy đủ và phản ánh chính xác những gì công cụ thực hiện không?
  • functionName có trực quan và mang tính mô tả không?
  • Công cụ có được hiển thị chính xác cho LLM ở trạng thái/bối cảnh hiện tại không?
  • Giản đồ của công cụ này có thể quá giống với một công cụ khác, dẫn đến sự mơ hồ khi gọi không?
Nhân viên hỗ trợ gọi các công cụ theo thứ tự không chính xác

Nhân viên hỗ trợ gọi checkout rồi gọi addToCart.

  • Nội dung mô tả công cụ có trùng lặp, khiến LLM nhầm lẫn về trình tự bắt buộc không?
  • Kết quả của một công cụ trước đó có cung cấp bối cảnh cần thiết cho lệnh gọi công cụ tiếp theo không?
  • Trạng thái có được cập nhật chính xác và mọi công cụ mới có được hiển thị cho LLM như dự kiến không?
  • Trường hợp sử dụng toàn diện vẫn chính xác nếu một số công cụ được gọi theo thứ tự khác nhau không?
  • Bạn đã kiểm thử chuỗi lệnh gọi công cụ cụ thể một cách riêng biệt bằng cách buộc các lệnh gọi trước đó để xác nhận rằng LLM chọn bước tiếp theo chính xác chưa?
Nhân viên hỗ trợ gọi công cụ bằng các đối số không chính xác

Nhân viên hỗ trợ gọi addToCart, nhưng thêm giày thay vì áo phông.

  • inputSchema có được xác định rõ ràng, bao gồm các giá trị enumdescription phù hợp cho từng thuộc tính không?
  • Tất cả các tham số bắt buộc có được đánh dấu và kiểm tra rõ ràng không?
  • Nội dung mô tả đối số có hướng dẫn rõ ràng cho LLM về cách ánh xạ hoạt động đầu vào của người dùng với dữ liệu có cấu trúc dự kiến (chẳng hạn như một mã nhận dạng hoặc định dạng cụ thể) không?

Điều gì sẽ xảy ra nếu người dùng muốn kiểm tra nội dung trong giỏ hàng của họ?

Lỗi Ví dụ Khắc phục sự cố
Kết quả của công cụ không chính xác hoặc công cụ bỏ sót thông tin.

Người dùng yêu cầu viewCart, nhưng nhân viên hỗ trợ đưa ra tổng chi phí giỏ hàng thay vì tên sản phẩm và giá riêng lẻ.

  • Logic công cụ cơ bản có lỗi không (kiểm tra bằng các bài kiểm thử xác định)?
  • Trạng thái giao diện người dùng có được cập nhật chính xác và nhân viên hỗ trợ có nhận được thông tin chính xác về tác dụng phụ không?
  • Nếu kết quả được LLM sử dụng cho các lệnh gọi tiếp theo, thì kết quả có được định dạng rõ ràng để LLM tiếp nhận không?
  • Kết quả có quá chi tiết không? Kết quả có chỉ chứa thông tin thiết yếu tối thiểu mà LLM cần cho hành động tiếp theo không?

Cuối cùng, một công cụ có thể gặp lỗi theo bất kỳ cách nào mà JavaScript gặp lỗi. Để khắc phục sự cố, hãy điều tra những vấn đề sau:

  • Mã công cụ có xử lý đúng cách tất cả các lỗi và ngoại lệ tiềm ẩn trong thời gian chạy không?
  • Lỗi có được báo cáo lại cho nhân viên hỗ trợ và mô hình một cách suôn sẻ không?
  • Các API hoặc dịch vụ bên ngoài mà công cụ dựa vào có hoạt động bình thường không?
  • Cấu trúc lỗi có đủ rõ ràng để mô hình có thể phân biệt giữa vấn đề tạm thời (thử lại) và lỗi nghiêm trọng không?

Kiểm thử các công cụ một cách riêng biệt

Nếu nhân viên hỗ trợ không thể xác định được công cụ nào cần gọi cho một yêu cầu như "Tôi muốn một chiếc pizza nhỏ", thì nhân viên hỗ trợ sẽ không có cơ hội trong hành trình phức tạp của người dùng.

Bằng cách kiểm thử các công cụ một cách riêng biệt, bạn có thể tối ưu hoá giản đồ và nội dung mô tả trước khi chạy mô phỏng trình duyệt.

Đo lường độ chính xác của lệnh gọi

Hãy xem bản minh hoạ của chúng tôi, the WebMCP zaMaker. Khi người dùng đưa ra lời nhắc "Tôi muốn một chiếc pizza nhỏ", bạn có thể mong đợi phản hồi của mô hình cho biết ý định thực hiện lệnh gọi set_pizza_size với đối số "size":"Small".

Hàm expectedCall xác định hàm và đối số dự kiến. Phương pháp này xác nhận rằng nhân viên hỗ trợ sẽ chọn đúng công cụ để hỗ trợ ý định của người dùng dựa trên giản đồ được cung cấp.

{
  "messages": [
    {
      "role": "user",
      "content": "I'd like a small pizza."
    }
  ],
  "expectedCall": [
    {
      "functionName": "set_pizza_size",
      "arguments": { "size": "Small" }
    }
  ]
}

expectedCall được dùng để thực hiện bài kiểm thử xác định dựa trên quy tắc:

Bạn có thể liên kết các công cụ WebMCP với vòng đời của một thành phần, nghĩa là bạn phải kiểm thử khi trạng thái ứng dụng của bạn khớp với những gì WebMCP mong đợi. Để quản lý việc này, hãy cung cấp danh sách đầy đủ các công cụ có liên quan đến trạng thái mà bạn muốn đánh giá. Ví dụ: người dùng đang cùng duyệt web với nhân viên hỗ trợ và mở WebMCP zaMaker.

Trạng thái ứng dụng

[
...
  {
    "name": "add_topping",
    "description": "Add one or more toppings to the pizza",
    ...
  },
  {
    "name": "set_pizza_size",
    "description": "Set the pizza size directly.",
    "inputSchema": {
      "type": "object",
      "properties": {
        "size": {
          "type": "string",
          "enum": [
            "Small",
            "Medium",
            "Large",
            "Extra Large"
          ],
          "description": "The specific size name."
        },
      }
    }
  },
  {
    "name": "set_pizza_style",
    "description": "Set the style of the pizza (colors/theme)",
  ...
  },
...
]

Lệnh gọi dự kiến

...
 "expectedCall": [
   {
     "functionName": "set_pizza_size",
     "arguments": { "size": "Small" }
   }
 ]
...

Khi mở, WebMCP hiển thị các công cụ add_topping, set_pizza_sizeset_pizza_style. Để kiểm thử chính xác bất kỳ công cụ riêng lẻ nào trong số này, bạn nên đưa tất cả các công cụ vào để tạo trạng thái mô phỏng, hoàn chỉnh.

LƯU Ý: Nhân viên hỗ trợ có thể có quyền truy cập vào các công cụ bổ sung, nhưng bạn chỉ có thể đánh giá các công cụ mà bạn cung cấp.

Giờ đây, bạn đã biết nhân viên hỗ trợ gọi đúng công cụ khi cần, bạn có thể kiểm thử xem lệnh gọi công cụ có các tham số chính xác và kết quả có đúng như dự kiến không. Có 2 bước: bài kiểm thử xác định và bài kiểm thử xác suất.

Chạy các bài kiểm thử xác định

Vì các công cụ WebMCP được xây dựng bằng JavaScript hoặc dưới dạng chú thích HTML, nên bạn có thể viết các bài kiểm thử xác định để thực hiện các tác vụ sau:

  • Xác minh logic công cụ.
  • Xác nhận rằng các phần phụ thuộc đã được gọi chính xác.
  • Xác nhận rằng giao diện người dùng đã được cập nhật như dự kiến, cùng với mọi tác dụng phụ có chủ ý khác.
  • Xác minh rằng thông tin được trả về khớp với giá trị dự kiến.
  • Xác thực các tham số kiểm thử.

Ví dụ: nếu công cụ của bạn sử dụng hàm SearchComponent, bạn có thể kiểm thử bằng cách truyền bản mô phỏng của SearchComponent. Hãy nhớ mô phỏng môi trường mà công cụ đang hoạt động để có được kết quả tốt nhất có thể. Đây là kỹ thuật tương tự mà bạn sẽ sử dụng khi viết một bài kiểm thử tích hợp ứng dụng khác.

Chạy các bài kiểm thử xác suất

Nếu bạn yêu cầu đầu ra của mô hình để gọi đúng các công cụ tiếp theo, thì bạn cần viết evals.

Người dùng có thể đưa ra các truy vấn trực tiếp cho mô hình để hỏi cụ thể về những gì công cụ thực hiện hoặc một truy vấn mơ hồ ngụ ý rằng nên sử dụng một công cụ. Ví dụ: "Thêm pepperoni vào pizza của tôi" là một truy vấn trực tiếp. "Tôi muốn tất cả các loại thịt trên pizza của tôi" mơ hồ hơn và yêu cầu mô hình hiểu rằng mô hình cần công cụ add_topping và loại topping nào có thể được xác định là thịt.

Khi tạo tập dữ liệu cho evals, hãy đưa cả các truy vấn trực tiếp kiểm thử việc thực thi công cụ cơ bản và các truy vấn mở kiểm thử logic suy luận và lựa chọn công cụ của mô hình.

Nếu bạn điều hành một quán cà phê, bạn có thể hỗ trợ những người dùng yêu cầu nhân viên hỗ trợ đặt lại loại cà phê mà họ đã đặt vào tháng trước. Viết một công cụ để tìm kiếm các đơn đặt hàng trước đó, OrderHistoryService và một công cụ khác để đặt cà phê. Để kiểm thử dịch vụ lịch sử đặt hàng, bạn có thể gửi một bản mô phỏng trả về mã sản phẩm cà phê.

Trong ví dụ này, bạn đánh giá xem mô hình có hiểu ý định của truy vấn, chọn đúng công cụ và công cụ đó có cung cấp thông tin chính xác để thực hiện hành động không. Nếu mô hình không gọi get_order_history, thì mô hình sẽ không biết item_id nào cần sử dụng cho order_product.

Kiểm thử toàn diện

Viết các bài kiểm thử toàn diện để bạn tự tin rằng người dùng và nhân viên hỗ trợ của họ có thể hoàn thành hành trình của mình một cách thành công. Ngoài việc kiểm thử các công cụ riêng lẻ, bạn cũng đang kiểm thử để đảm bảo rằng các hành động nhiều bước được thực hiện theo đúng thứ tự.

Ví dụ: bạn điều hành một cửa hàng quần áo trực tuyến. Người dùng hỏi nhân viên hỗ trợ của họ: "Tôi đang muốn mua một chiếc áo khoác màu đen và một chiếc quần jean. Bạn có thể cung cấp thông tin chi tiết về các chất liệu được sử dụng không?"

Hành trình thành công của nhân viên hỗ trợ có thể như sau:

  1. Chuyển đến danh mục quần áo.
  2. Tìm một trong các mặt hàng quần áo được yêu cầu (thứ tự không quan trọng).
  3. Tìm mặt hàng cụ thể (search_clothes).
  4. Nhận thông tin chi tiết về sản phẩm có chứa danh sách chất liệu (get_product_details).
  5. Lặp lại bước 2-4 cho từng mặt hàng được yêu cầu.

Khi nhân viên hỗ trợ chuyển đến bước 2, nhân viên hỗ trợ có thể tìm kiếm chiếc áo khoác màu đen trước hoặc chiếc quần jean, thứ tự không quan trọng. Tuy nhiên, bạn phải thực hiện tuần tự các bước còn lại.

Viết một eval toàn diện để xác minh rằng nhân viên hỗ trợ gọi các công cụ theo thứ tự dự kiến:

{
  "messages": [
    {
      "role": "user",
      "content": "I am looking to buy a black jacket and a pair of jeans.
        Could you provide a breakdown of the materials used ?"
    }
  ],
  "expectedCall": [
    {
      "functionName": "navigate_to_category",
      "arguments": { "category": "clothes" }
    },
    {
      "unordered": [
        {
          "ordered": [
            {
              "functionName": "search_clothes",
              "arguments": { "query": "black jacket" }
            },
            {
              "functionName": "get_product_details",
              "arguments": { "productId": "JACKET002" }
            }
          ]
        },
        {
          "ordered": [
            {
              "functionName": "search_clothes",
              "arguments": { "query": "jeans" }
            },
            {
              "functionName": "get_product_details",
              "arguments": { "productId": "JEANS001" }
            }
          ]
        }
      ]
    }
  ]
}

Đánh giá các lỗi giữa chuỗi

Ví dụ về lệnh gọi công cụ cho một người dùng yêu cầu bánh pizza chiết khấu.
Khi người dùng yêu cầu đặt pizza bằng phiếu giảm giá, một chuỗi công cụ sẽ được gọi tuần tự: start_pizza_creator, set_pizza_style, set_pizza_size, start_checkout, add_discount_coupon, và complete_checkout. add_discount_coupon gặp lỗi, nhưng quy trình vẫn có thể hoàn tất, nghĩa là người dùng không nhận được chiết khấu.

Có thể có những trường hợp nhân viên hỗ trợ phải gọi nhiều công cụ một cách tuần tự. Điều gì sẽ xảy ra nếu một công cụ gặp lỗi ở giữa quy trình này? Ví dụ: người dùng muốn đặt pizza bằng mã phiếu giảm giá của họ:

"Tôi muốn một chiếc pizza Pesto nhỏ. Sử dụng mã khuyến mãi của tôi, FreePizza."

Có thể nhân viên hỗ trợ gặp lỗi ở add_discount_coupon và chuyển đến trang thanh toán cho chiếc pizza có giá đầy đủ. Để kiểm thử công cụ add_discount_coupon, bạn có thể thực thi thủ công chuỗi lệnh gọi công cụ này mà không cần tương tác với mô hình để mô phỏng tình huống này. Đưa ứng dụng của bạn về trạng thái mà bạn dự đoán công cụ sẽ gặp lỗi. Trong trường hợp này, đó là sau công cụ start_checkout. Sau đó, bạn có thể đánh giá add_discount_coupon một cách riêng biệt.

Thử nghiệm với WebMCP

Bắt đầu thử nghiệm với evals cho các công cụ một cách riêng biệt và đánh giá các trang web hỗ trợ WebMCP của riêng bạn bằng bất kỳ nhân viên hỗ trợ nào tương thích với WebMCP: