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

Kasper Kulikowski
Kasper Kulikowski

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

วิดีโออธิบาย เว็บ ส่วนขยาย สถานะของ Chrome ความตั้งใจ
GitHub ช่วงทดลองใช้จากต้นทาง ช่วงทดลองใช้จากต้นทาง ดู ความตั้งใจที่จะทดลอง

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

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

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

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

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

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

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

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

ล้มเหลว ตัวอย่าง แก้ปัญหา
Agent เลือกเครื่องมือไม่ถูกต้องหรือเรียกใช้เครื่องมือที่ไม่ถูกต้องโดยตรง

ตัวแทนจะข้าม addToCart และไปที่ checkout โดยตรง

  • description ของเครื่องมือชัดเจน ครบถ้วน และแสดงถึงสิ่งที่เครื่องมือทำได้อย่างถูกต้องหรือไม่
  • functionName ใช้งานง่ายและอธิบายรายละเอียดได้ดีไหม
  • เครื่องมือนี้แสดงต่อ LLM อย่างถูกต้องในสถานะ/บริบทปัจจุบันหรือไม่
  • สคีมาของเครื่องมือนี้อาจคล้ายกับเครื่องมืออื่นมากเกินไปจนทำให้เกิดความคลุมเครือในการเรียกใช้หรือไม่
ตัวแทนเรียกใช้เครื่องมือในลำดับที่ไม่ถูกต้อง

Agent จะเรียกใช้ checkout แล้วจึงเรียกใช้ addToCart

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

ตัวแทนโทรหา addToCart แต่เพิ่มรองเท้าแทนเสื้อยืด

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

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

ล้มเหลว ตัวอย่าง แก้ปัญหา
เอาต์พุตของเครื่องมือไม่ถูกต้องหรือเครื่องมือพลาดบางอย่าง

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

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

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

  • โค้ดเครื่องมือจัดการข้อผิดพลาดและข้อยกเว้นที่อาจเกิดขึ้นทั้งหมดในรันไทม์อย่างถูกต้องหรือไม่
  • ข้อผิดพลาดได้รับการรายงานกลับไปยัง Agent และโมเดลอย่างเหมาะสมไหม
  • 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 คุณจึงเขียนการทดสอบที่กำหนดได้เพื่อทำงานต่อไปนี้

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

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

ทำการทดสอบเชิงความน่าจะเป็น

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

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

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

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

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

การทดสอบตั้งแต่ต้นจนจบ

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

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

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

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

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

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

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

ประเมินความล้มเหลวที่เกิดขึ้นระหว่างการดำเนินการ

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

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

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

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

ทดลองใช้ WebMCP

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