การประเมินสำหรับ WebMCP

Kasper Kulikowski

เผยแพร่เมื่อ: 19 พ.ค. 2026, อัปเดตล่าสุดเมื่อ: 28 พ.ค. 2026

WebMCP รองรับตัวแทนที่ใช้โมเดล Generative AI หากต้องการทดสอบระบบใดก็ตามที่ใช้ Generative AI การทดสอบต้องรองรับผลลัพธ์ที่เป็นไปได้ ซึ่งหมายความว่าอินพุต 1 รายการอาจนำไปสู่คำตอบนับพันรายการที่มีระดับความถูกต้องแตกต่างกัน เทคนิคการทดสอบนี้เรียกว่าการประเมินหรือ evals.

ก่อนที่จะเผยแพร่เครื่องมือเพื่อใช้งานจริง คุณต้องยืนยันว่าตัวแทนเข้าใจว่าเมื่อใดควรเรียกใช้เครื่องมือ วิธีเรียกใช้ และคำตอบใดที่ยอมรับได้ จัดการโอกาสที่จะเกิดความล้มเหลวก่อนที่จะเกิดขึ้น

เขียนการประเมินเพื่อทดสอบจุดสัมผัสของระบบกับโมเดลภาษาขนาดใหญ่ (LLM) ดังนี้

• ตรวจสอบว่าโมเดลเข้าใจวัตถุประสงค์ของเครื่องมือตามคำอธิบายและสคีมา
• ตรวจสอบว่าโมเดลเลือกเครื่องมือที่เหมาะสมด้วยพารามิเตอร์ที่ถูกต้องเพื่อรองรับความตั้งใจของผู้ใช้
• ยืนยันว่าโมเดลดำเนินการตามข้อมูลที่ได้รับ เช่น ใช้ข้อมูลเพื่อเรียกใช้เครื่องมืออื่น
• ตรวจสอบเส้นทางของผู้ใช้ที่ประสบความสำเร็จ ตัวแทนสามารถทำตามเส้นทางของผู้ใช้ในเว็บไซต์ของฉันด้วยเครื่องมือที่ให้ไว้ได้สำเร็จหรือไม่เมื่อพิจารณาจากเจตนาของผู้ใช้

คุณควรเขียนการทดสอบแบบดีเทอร์มินิสติกแบบคลาสสิกต่อไปสำหรับการโต้ตอบกับระบบใดก็ตามที่ไม่ได้สื่อสารกับโมเดล

โหมดความล้มเหลว

นักพัฒนาซอฟต์แวร์ควรทดสอบระบบเพื่อป้องกันความล้มเหลวก่อนที่จะเกิดขึ้น ในการดำเนินการดังกล่าว คุณต้องเข้าใจว่าระบบอาจล้มเหลวเมื่อใด ทั้งด้วยตัวเองและในการโต้ตอบกับปัจจัยภายนอก สำหรับ WebMCP เครื่องมือเองอาจล้มเหลวและตัวแทนอาจใช้เครื่องมือไม่เป็นไปตามที่คาดไว้

เครื่องมือ WebMCP อาจล้มเหลวและตัวแทนอาจล้มเหลวในการใช้เครื่องมือ WebMCP เช่น สมมติว่าผู้ใช้ต้องการเพิ่มเสื้อยืดลงในรถเข็น

ล้มเหลว	ตัวอย่าง	แก้ปัญหา
ตัวแทนเลือกเครื่องมือไม่ถูกต้องหรือเรียกใช้เครื่องมือที่ไม่ถูกต้องโดยตรง	ตัวแทนข้าม addToCart และไปที่ checkout โดยตรง	description ของเครื่องมือชัดเจน ครบถ้วน และแสดงให้เห็นอย่างถูกต้องว่าเครื่องมือทำอะไรได้บ้าง functionName ใช้งานง่ายและสื่อความหมาย เครื่องมือแสดงต่อ LLM อย่างถูกต้องในสถานะ/บริบทปัจจุบันหรือไม่ สคีมาของเครื่องมือนี้อาจคล้ายกับเครื่องมืออื่นมากเกินไป ซึ่งนำไปสู่ความคลุมเครือในการเรียกใช้หรือไม่
ตัวแทนเรียกใช้เครื่องมือตามลำดับที่ไม่ถูกต้อง	ตัวแทนเรียกใช้ checkout แล้วจึงเรียกใช้ addToCart	คำอธิบายเครื่องมือซ้อนทับกัน ทำให้ LLM สับสนเกี่ยวกับลำดับที่ต้องใช้หรือไม่ เอาต์พุตของเครื่องมือที่มาก่อนให้บริบทที่จำเป็นสำหรับการเรียกใช้เครื่องมือถัดไปหรือไม่ สถานะได้รับการอัปเดตอย่างถูกต้องและเครื่องมือใหม่แสดงต่อ LLM ตามที่คาดไว้หรือไม่ กรณีการใช้งานแบบครบวงจรยังคงถูกต้องอยู่หรือไม่หากมีการเรียกใช้เครื่องมือบางอย่างตามลำดับที่แตกต่างกัน คุณได้ทดสอบเชนการเรียกใช้เครื่องมือที่เฉพาะเจาะจงแบบแยกกันโดยบังคับให้มีการเรียกใช้ก่อนหน้าเพื่อยืนยันว่า LLM เลือกขั้นตอนถัดไปที่ถูกต้องหรือไม่
ตัวแทนเรียกใช้เครื่องมือด้วยอาร์กิวเมนต์ที่ไม่ถูกต้อง	ตัวแทนเรียกใช้ addToCart แต่เพิ่มรองเท้าแทนเสื้อยืด	inputSchema ได้รับการกำหนดไว้อย่างชัดเจน รวมถึงค่า enum และ description ที่ดีสำหรับพร็อพเพอร์ตี้แต่ละรายการหรือไม่ พารามิเตอร์ที่จำเป็นทั้งหมดมีการทำเครื่องหมายและตรวจสอบอย่างชัดเจนหรือไม่ คำอธิบายของอาร์กิวเมนต์แนะนำ LLM อย่างชัดเจนเกี่ยวกับวิธีแมปข้อมูลจากผู้ใช้กับ Structured Data ที่คาดไว้ (เช่น รหัสหรือรูปแบบที่เฉพาะเจาะจง) หรือไม่

จะเกิดอะไรขึ้นหากผู้ใช้ต้องการตรวจสอบสิ่งที่อยู่ในรถเข็น

ล้มเหลว	ตัวอย่าง	แก้ปัญหา
เอาต์พุตของเครื่องมือไม่ถูกต้องหรือเครื่องมือพลาดบางอย่างไป	ผู้ใช้ขอ viewCart แต่ตัวแทนแสดงต้นทุนรวมของรถเข็นแทนที่จะเป็นชื่อผลิตภัณฑ์และราคาแต่ละรายการ	ตรรกะของเครื่องมือพื้นฐานมีข้อบกพร่องหรือไม่ (ตรวจสอบด้วยการทดสอบแบบดีเทอร์มินิสติก) สถานะ UI ได้รับการอัปเดตอย่างถูกต้องและตัวแทนได้รับข้อมูลที่ถูกต้องเกี่ยวกับผลข้างเคียงหรือไม่ หาก LLM ใช้เอาต์พุตสำหรับการเรียกใช้ในภายหลัง เอาต์พุตได้รับการจัดรูปแบบอย่างชัดเจนเพื่อให้ LLM รับข้อมูลได้หรือไม่ เอาต์พุตมีรายละเอียดมากเกินไปหรือไม่ เอาต์พุตมีเฉพาะข้อมูลสำคัญขั้นต่ำที่ LLM ต้องการสำหรับการดำเนินการถัดไปหรือไม่

สุดท้าย เครื่องมืออาจล้มเหลวในลักษณะเดียวกับที่ JavaScript ล้มเหลว หากต้องการแก้ปัญหา ให้ตรวจสอบสิ่งต่อไปนี้

• โค้ดเครื่องมือจัดการข้อผิดพลาดและข้อยกเว้นที่อาจเกิดขึ้นทั้งหมดในรันไทม์อย่างเหมาะสมหรือไม่
• ข้อผิดพลาดได้รับการรายงานกลับไปยังตัวแทนและโมเดลอย่างเหมาะสมหรือไม่
• API หรือบริการภายนอกที่เครื่องมือใช้ทำงานได้ดีหรือไม่
• โครงสร้างข้อผิดพลาดชัดเจนพอที่โมเดลจะแยกแยะระหว่างปัญหาชั่วคราว (ลองอีกครั้ง) กับความล้มเหลวร้ายแรงได้หรือไม่

ทดสอบเครื่องมือแบบแยกกัน

หากตัวแทนไม่สามารถระบุได้ว่าจะเรียกใช้เครื่องมือใดสำหรับคำขอ เช่น "ฉันต้องการพิซซ่าขนาดเล็ก" ตัวแทนก็ไม่มีโอกาสที่จะทำตามเส้นทางของผู้ใช้ที่ซับซ้อนได้

การทดสอบเครื่องมือแบบแยกกันช่วยให้คุณเพิ่มประสิทธิภาพสคีมาและคำอธิบายได้ก่อนที่จะทำการจำลองเบราว์เซอร์

วัดความแม่นยำในการเรียกใช้

ดูเดโมของเรา ซึ่งก็คือ WebMCP zaMaker เมื่อผู้ใช้แจ้งว่า "ฉันต้องการพิซซ่าขนาดเล็ก" คุณคาดหวังได้ว่าโมเดลจะตอบกลับเพื่อแสดงความตั้งใจที่จะทำการเรียกใช้ set_pizza_size ด้วย "size":"Small"

ฟังก์ชัน expectedCall จะกำหนดฟังก์ชันและอาร์กิวเมนต์ที่คาดไว้ แนวทางนี้ยืนยันว่าตัวแทนจะเลือกเครื่องมือที่ถูกต้องเพื่อรองรับความตั้งใจของผู้ใช้ตามสคีมาที่ให้ไว้

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

expectedCall ใช้เพื่อทำการทดสอบแบบดีเทอร์มินิสติกตามกฎ

คุณสามารถเชื่อมโยงเครื่องมือ WebMCP กับวงจรชีวิตของคอมโพเนนต์ ซึ่งหมายความว่าคุณต้องทดสอบเมื่อสถานะแอปพลิเคชันตรงกับสิ่งที่ WebMCP คาดหวัง หากต้องการจัดการเรื่องนี้ ให้ระบุรายการเครื่องมือทั้งหมดที่เกี่ยวข้องกับสถานะที่คุณต้องการประเมิน เช่น ผู้ใช้กำลังเรียกดูร่วมกับตัวแทนและเปิด WebMCP zaMaker

[
...
  {
    "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)",
  ...
  },
...
]

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

เมื่อเปิด WebMCP จะแสดงเครื่องมือ add_topping, set_pizza_size และ set_pizza_style หากต้องการทดสอบเครื่องมือแต่ละรายการเหล่านี้อย่างแม่นยำ คุณควรรวมเครื่องมือทั้งหมดเพื่อสร้างสถานะที่จำลองขึ้นและสมบูรณ์

หมายเหตุ: ตัวแทนอาจมีสิทธิ์เข้าถึงเครื่องมือเพิ่มเติม แต่สิ่งที่ดีที่สุดที่คุณทำได้คือประเมินเครื่องมือที่คุณให้ไว้

เมื่อทราบแล้วว่าตัวแทนเรียกใช้เครื่องมือที่เหมาะสมตามความจำเป็น คุณสามารถทดสอบได้ว่าการเรียกใช้เครื่องมือมีพารามิเตอร์ที่ถูกต้องและผลลัพธ์เป็นไปตามที่คาดไว้ การทดสอบมี 2 ขั้นตอน ได้แก่ การทดสอบแบบดีเทอร์มินิสติกและการทดสอบแบบโพรบิลิสติก

เรียกใช้การทดสอบแบบดีเทอร์มินิสติก

เนื่องจากเครื่องมือ WebMCP สร้างขึ้นด้วย JavaScript หรือเป็นคำอธิบายประกอบ HTML คุณจึงเขียนการทดสอบแบบดีเทอร์มินิสติกเพื่อทำงานต่อไปนี้ได้

• ยืนยันตรรกะของเครื่องมือ
• ยืนยันว่ามีการเรียกใช้การขึ้นต่อกันอย่างถูกต้อง
• ยืนยันว่าอินเทอร์เฟซผู้ใช้ได้รับการอัปเดตตามที่คาดไว้ รวมถึงผลข้างเคียงอื่นๆ ที่ตั้งใจไว้
• ยืนยันว่าข้อมูลที่ส่งกลับตรงกับค่าที่คาดไว้
• ตรวจสอบพารามิเตอร์การทดสอบ

ตัวอย่างเช่น หากเครื่องมือใช้ฟังก์ชัน SearchComponent คุณสามารถทดสอบได้โดยส่งผ่านการจำลอง SearchComponent อย่าลืมจำลองสภาพแวดล้อมที่เครื่องมือทำงานอยู่เพื่อให้ได้ผลลัพธ์ที่ดีที่สุด นี่เป็นเทคนิคเดียวกับที่คุณใช้ในการเขียนการทดสอบการผสานรวมแอปพลิเคชันอื่น

เรียกใช้การทดสอบแบบโพรบิลิสติก

หากคุณต้องการให้โมเดลแสดงเอาต์พุตโมเดลเพื่อเรียกใช้เครื่องมือถัดไปอย่างเหมาะสม คุณต้องเขียนการประเมิน

ผู้ใช้สามารถส่งคำค้นหาโดยตรงไปยังโมเดลเพื่อถามสิ่งที่เครื่องมือทำได้โดยเฉพาะ หรือส่งคำค้นหาที่คลุมเครือซึ่งหมายความว่าควรใช้เครื่องมือ เช่น "ใส่เปปเปอร์โรนีในพิซซ่าของฉัน" เป็นคำค้นหาโดยตรง "ฉันต้องการเนื้อทั้งหมดในพิซซ่าของฉัน" คลุมเครือมากกว่าและต้องให้โมเดลเข้าใจว่าต้องใช้เครื่องมือ add_topping และท็อปปิ้งใดที่กำหนดเป็นเนื้อได้

เมื่อสร้างชุดข้อมูลสำหรับการประเมิน ให้รวมทั้งคำค้นหาโดยตรงที่ทดสอบการดำเนินการเครื่องมือพื้นฐานและคำค้นหาแบบปลายเปิดที่ทดสอบการให้เหตุผลของโมเดลและตรรกะการเลือกเครื่องมือ

หากคุณเปิดร้านกาแฟ คุณสามารถรองรับผู้ใช้ที่ขอให้ตัวแทนสั่งกาแฟแก้วเดิมที่สั่งเมื่อเดือนที่แล้วอีกครั้ง เขียนเครื่องมือเพื่อค้นหาคำสั่งซื้อก่อนหน้า OrderHistoryService และอีกเครื่องมือหนึ่งเพื่อสั่งกาแฟ หากต้องการทดสอบบริการประวัติการสั่งซื้อ คุณสามารถส่งการจำลองที่ส่งกลับรหัสผลิตภัณฑ์กาแฟ

ในตัวอย่างนี้ คุณจะประเมินว่าโมเดลเข้าใจเจตนาของคำค้นหา เลือกเครื่องมือที่เหมาะสม และเครื่องมือดังกล่าวให้ข้อมูลที่ถูกต้องเพื่อดำเนินการหรือไม่ หากโมเดลไม่เรียกใช้ get_order_history โมเดลจะไม่ทราบว่าจะใช้ item_id ใดสำหรับ order_product

การทดสอบแบบครบวงจร

เขียนการทดสอบแบบครบวงจรเพื่อให้มั่นใจว่าผู้ใช้และตัวแทนของผู้ใช้จะทำตามเส้นทางได้สำเร็จ นอกจากการทดสอบเครื่องมือแต่ละรายการแล้ว คุณยังทดสอบด้วยว่าการดำเนินการหลายขั้นตอนจะดำเนินการตามลำดับที่ถูกต้อง

ตัวอย่างเช่น คุณเปิดร้านขายเสื้อผ้าออนไลน์ ผู้ใช้ถามตัวแทนว่า "ฉันกำลังมองหาเสื้อแจ็กเก็ตสีดำและกางเกงยีนส์ คุณช่วยแสดงรายละเอียดวัสดุที่ใช้ได้ไหม"

เส้นทางของตัวแทนที่ประสบความสำเร็จอาจมีลักษณะดังนี้

1. ไปที่หมวดหมู่เสื้อผ้า
2. ค้นหารายการเสื้อผ้าที่ขอ (ลำดับไม่สำคัญ)
3. ค้นหารายการที่เฉพาะเจาะจง (search_clothes)
4. รับรายละเอียดผลิตภัณฑ์ที่มีรายการวัสดุ (get_product_details)
5. ทำซ้ำขั้นตอนที่ 2-4 สำหรับแต่ละรายการที่ขอ

เมื่อตัวแทนไปถึงขั้นตอนที่ 2 ตัวแทนอาจค้นหาเสื้อแจ็กเก็ตสีดำก่อนหรือกางเกงยีนส์ก่อนก็ได้ ลำดับไม่สำคัญ อย่างไรก็ตาม ต้องทำตามขั้นตอนที่เหลือตามลำดับ

เขียนการประเมินแบบครบวงจรเพื่อยืนยันว่าตัวแทนเรียกใช้เครื่องมือตามลำดับที่คาดไว้

{
  "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" }
            }
          ]
        }
      ]
    }
  ]
}

ประเมินความล้มเหลวระหว่างเชน

บางครั้งตัวแทนอาจต้องเรียกใช้เครื่องมือหลายรายการตามลำดับ จะเกิดอะไรขึ้นหากเครื่องมือล้มเหลวระหว่างกระบวนการนี้ ตัวอย่างเช่น ผู้ใช้ต้องการสั่งพิซซ่าด้วยรหัสคูปอง

"ฉันต้องการพิซซ่าเพสโต้ขนาดเล็ก ใช้รหัสโปรโมชัน FreePizza"

ตัวแทนอาจล้มเหลวที่ add_discount_coupon และดำเนินการชำระเงินสำหรับพิซซ่าราคาเต็ม หากต้องการทดสอบเครื่องมือ add_discount_coupon คุณสามารถเรียกใช้ลำดับการเรียกใช้เครื่องมือนี้ด้วยตนเองโดยไม่ต้องโต้ตอบกับโมเดลเพื่อจำลองสถานการณ์นี้ นำแอปพลิเคชันไปสู่สถานะที่คุณคาดว่าเครื่องมือจะล้มเหลว ในกรณีนี้คือหลังจากเครื่องมือ start_checkout จากนั้นคุณจะประเมิน add_discount_coupon แบบแยกกันได้

ทดลองใช้ WebMCP

เริ่มทดลองใช้การประเมินสำหรับเครื่องมือแบบแยกกันและประเมินเว็บไซต์ที่เปิดใช้ WebMCP ของคุณเองด้วยตัวแทนที่เข้ากันได้กับ WebMCP

• ดาวน์โหลดเครื่องมือประเมินแบบทดลองของเราใน GitHub
• ดูหลักสูตรสร้างการประเมิน AI