WebMCP के लिए इवैल

Kasper Kulikowski
Kasper Kulikowski

पब्लिश की गई तारीख: 19 मई, 2026, आखिरी बार अपडेट की गई तारीख: 28 मई, 2026

WebMCP, जनरेटिव एआई मॉडल का इस्तेमाल करने वाले एजेंट के साथ काम करता है. जनरेटिव एआई का इस्तेमाल करने वाले किसी भी सिस्टम की जांच करने के लिए, आपके टेस्ट में संभावित नतीजों की सुविधा होनी चाहिए. इसका मतलब है कि एक इनपुट से, सटीक जवाबों के अलग-अलग लेवल के साथ हज़ारों जवाब मिल सकते हैं. जांच की इस तकनीक को इवैल्युएशन या इवैल कहा जाता है.

टूल को प्रोडक्शन में रिलीज़ करने से पहले, आपको यह पक्का करना होगा कि एजेंट को यह पता हो कि टूल को कब कॉल करना है, उसे कैसे चलाना है, और कौनसे जवाब स्वीकार किए जा सकते हैं. गड़बड़ी होने की संभावनाओं को पहले से ही हल करें.

लार्ज लैंग्वेज मॉडल (एलएलएम) के साथ अपने सिस्टम के टचपॉइंट की जांच करने के लिए, इवैल्युएशन लिखें:

  • पक्का करें कि मॉडल, आपके टूल के मकसद को समझता हो. यह जानकारी, टूल के ब्यौरे और स्कीमा के आधार पर तय की जाती है.
  • पुष्टि करें कि मॉडल, उपयोगकर्ता के मकसद को पूरा करने के लिए सही पैरामीटर के साथ सही टूल चुनता है.
  • पक्का करें कि मॉडल, मिली जानकारी के आधार पर काम कर रहा हो. उदाहरण के लिए, किसी दूसरे टूल को कॉल करने के लिए जानकारी का इस्तेमाल करना.
  • उपयोगकर्ता के सफ़र की पुष्टि करें. क्या कोई एजेंट, उपयोगकर्ता के मकसद को देखते हुए, उपलब्ध कराए गए टूल की मदद से मेरी वेबसाइट पर उपयोगकर्ता के सफ़र को पूरा कर सकता है?

आपको मॉडल के साथ कम्यूनिकेट न करने वाले किसी भी सिस्टम इंटरैक्शन के लिए, क्लासिक डिटरमिनिस्टिक टेस्ट लिखते रहने चाहिए.

गड़बड़ी के मोड

डेवलपर को अपने सिस्टम की जांच करनी चाहिए, ताकि गड़बड़ियां होने से पहले ही उन्हें रोका जा सके. इसके लिए, आपको यह समझना होगा कि सिस्टम कब गड़बड़ी कर सकता है. ऐसा तब हो सकता है, जब सिस्टम अपने-आप काम कर रहा हो या बाहरी फ़ैक्टर के साथ इंटरैक्ट कर रहा हो. WebMCP के लिए, टूल में गड़बड़ी हो सकती है. साथ ही, एजेंट, टूल का इस्तेमाल उम्मीद के मुताबिक नहीं कर सकते.

WebMCP टूल में गड़बड़ी हो सकती है. साथ ही, एजेंट, WebMCP टूल का इस्तेमाल उम्मीद के मुताबिक नहीं कर सकते. उदाहरण के लिए, मान लें कि आपका उपयोगकर्ता अपने कार्ट में टी-शर्ट जोड़ना चाहता है.

अपलोड नहीं हुआ उदाहरण समस्या हल करें
एजेंट, सही टूल नहीं चुन पाता या सीधे गलत टूल को कॉल करता है.

एजेंट, addToCart को छोड़ देता है और सीधे checkout पर चला जाता है.

  • क्या टूल का description साफ़, पूरा, और सटीक है? साथ ही, क्या यह टूल के काम को सही तरीके से दिखाता है?
  • क्या functionName समझने में आसान और जानकारी देने वाला है?
  • क्या टूल, मौजूदा स्थिति/कॉन्टेक्स्ट में एलएलएम के लिए सही तरीके से उपलब्ध है?
  • क्या इस टूल का स्कीमा, किसी दूसरे टूल के स्कीमा से काफ़ी मिलता-जुलता है? इसकी वजह से, कॉल करने में कोई समस्या आ सकती है.
एजेंट, टूल को गलत क्रम में कॉल करता है

एजेंट, पहले checkout को कॉल करता है और फिर addToCart को.

  • क्या टूल के ब्यौरे एक-दूसरे से मिलते-जुलते हैं? इसकी वजह से, एलएलएम को ज़रूरी क्रम के बारे में भ्रम हो सकता है?
  • क्या पहले टूल का आउटपुट, अगले टूल को कॉल करने के लिए ज़रूरी कॉन्टेक्स्ट उपलब्ध कराता है?
  • क्या स्थिति सही तरीके से अपडेट की गई है? साथ ही, क्या एलएलएम के लिए नए टूल, उम्मीद के मुताबिक उपलब्ध हैं?
  • क्या एंड-टू-एंड इस्तेमाल का तरीका अब भी सही है? ऐसा तब होगा, जब कुछ टूल को अलग-अलग क्रम में कॉल किया जाता है.
  • क्या आपने किसी खास टूल कॉल चेन को आइसोलेशन में टेस्ट किया है? इसके लिए, पहले के कॉल को फ़ोर्स करके, यह पक्का किया जाता है कि एलएलएम, अगले चरण के लिए सही टूल चुने.
एजेंट, गलत आर्ग्युमेंट के साथ टूल को कॉल करता है

एजेंट, addToCart को कॉल करता है, लेकिन टी-शर्ट के बजाय जूते जोड़ता है.

  • क्या inputSchema को साफ़ तौर पर तय किया गया है? इसमें enum वैल्यू और हर प्रॉपर्टी के लिए सटीक description शामिल है?
  • क्या सभी ज़रूरी पैरामीटर को साफ़ तौर पर मार्क और चेक किया गया है?
  • क्या आर्ग्युमेंट का ब्यौरा, एलएलएम को साफ़ तौर पर यह बताता है कि उपयोगकर्ता के इनपुट को उम्मीद के मुताबिक स्ट्रक्चर्ड डेटा (जैसे, कोई खास आईडी या फ़ॉर्मैट) में कैसे मैप करना है?

अगर उपयोगकर्ता यह देखना चाहता है कि उसके कार्ट में क्या है, तो क्या होगा?

अपलोड नहीं हुआ उदाहरण समस्या हल करें
टूल का आउटपुट गलत है या टूल में कोई जानकारी मौजूद नहीं है.

उपयोगकर्ता, viewCart के लिए कहता है, लेकिन एजेंट, प्रॉडक्ट के नाम और उनकी अलग-अलग कीमतों के बजाय, कार्ट की कुल कीमत दिखाता है.

  • क्या टूल की लॉजिक में कोई गड़बड़ी है? इसकी जांच डिटरमिनिस्टिक टेस्ट से करें.
  • क्या यूज़र इंटरफ़ेस (यूआई) की स्थिति सही तरीके से अपडेट की गई है? साथ ही, क्या एजेंट को साइड इफ़ेक्ट के बारे में सही जानकारी मिली है?
  • अगर एलएलएम, अगले कॉल के लिए आउटपुट का इस्तेमाल करता है, तो क्या आउटपुट को एलएलएम के इस्तेमाल के लिए साफ़ तौर पर फ़ॉर्मैट किया गया है?
  • क्या आउटपुट में ज़रूरत से ज़्यादा जानकारी है? क्या इसमें सिर्फ़ वह ज़रूरी जानकारी है जो एलएलएम को अगले ऐक्शन के लिए चाहिए?

आखिर में, किसी टूल में JavaScript से जुड़ी कोई भी गड़बड़ी हो सकती है. समस्या हल करने के लिए, इन चीज़ों की जांच करें:

  • क्या टूल का कोड, रनटाइम में होने वाली सभी संभावित गड़बड़ियों और अपवादों को सही तरीके से हैंडल करता है?
  • क्या गड़बड़ी की जानकारी, एजेंट और मॉडल को सही तरीके से दी जाती है?
  • क्या बाहरी एपीआई या सेवाएं सही तरीके से काम कर रही हैं? ये सेवाएं, टूल पर निर्भर करती हैं.
  • क्या गड़बड़ी का स्ट्रक्चर इतना साफ़ है कि मॉडल, अस्थायी समस्या (फिर से कोशिश करें) और गंभीर गड़बड़ी के बीच अंतर कर सके?

टूल को आइसोलेशन में टेस्ट करना

अगर कोई एजेंट, "मुझे एक छोटी पिज़्ज़ा चाहिए" जैसे अनुरोध के लिए यह नहीं समझ पाता कि किस टूल को कॉल करना है, तो वह उपयोगकर्ता के जटिल सफ़र में काम नहीं कर पाएगा.

टूल को आइसोलेशन में टेस्ट करके, ब्राउज़र सिम्युलेशन चलाने से पहले ही अपने स्कीमा और ब्यौरे ऑप्टिमाइज़ किए जा सकते हैं.

कॉल की सटीकता का आकलन करना

हमारा डेमो, the 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 टूल उपलब्ध कराता है. इनमें से किसी भी टूल को सटीक तरीके से टेस्ट करने के लिए, आपको सभी टूल शामिल करने चाहिए, ताकि सिम्युलेटेड और पूरी स्थिति बनाई जा सके.

ध्यान दें: हो सकता है कि किसी एजेंट के पास अन्य टूल का ऐक्सेस हो, लेकिन आपके पास सिर्फ़ उन टूल का आकलन करने का विकल्प होता है जो आपने उपलब्ध कराए हैं.

अब आपको पता है कि एजेंट, ज़रूरत के हिसाब से सही टूल को कॉल करता है. इसलिए, अब यह टेस्ट किया जा सकता है कि टूल कॉल में सही पैरामीटर हैं या नहीं. साथ ही, नतीजे उम्मीद के मुताबिक हैं या नहीं. इसके लिए, दो चरण हैं: डिटरमिनिस्टिक टेस्ट और प्रोबेबिलिस्टिक टेस्ट.

डिटरमिनिस्टिक टेस्ट करना

WebMCP टूल, JavaScript या एचटीएमएल एनोटेशन की मदद से बनाए जाते हैं. इसलिए, डिटरमिनिस्टिक टेस्ट लिखकर, ये काम किए जा सकते हैं:

  • टूल की लॉजिक की पुष्टि करना.
  • पुष्टि करना कि डिपेंडेंसी को सही तरीके से कॉल किया गया है.
  • पुष्टि करना कि यूज़र इंटरफ़ेस (यूआई), उम्मीद के मुताबिक अपडेट हुआ है. साथ ही, अन्य साइड इफ़ेक्ट भी उम्मीद के मुताबिक हैं.
  • पुष्टि करना कि दिखाई गई जानकारी, उम्मीद के मुताबिक वैल्यू से मेल खाती है.
  • टेस्ट पैरामीटर की पुष्टि करना.

उदाहरण के लिए, अगर आपका टूल, SearchComponent फ़ंक्शन का इस्तेमाल करता है, तो SearchComponent का मॉक पास करके टेस्ट किया जा सकता है. सबसे अच्छे नतीजे पाने के लिए, उस एनवायरमेंट को सिम्युलेट करना न भूलें जिसमें टूल काम कर रहा है. यह वही तरीका है जिसका इस्तेमाल, किसी अन्य ऐप्लिकेशन इंटिग्रेशन टेस्ट को लिखने के लिए किया जाता है.

प्रोबेबिलिस्टिक टेस्ट करना

अगर आपको अगले टूल को सही तरीके से कॉल करने के लिए, मॉडल के आउटपुट की ज़रूरत है, तो आपको इवैल लिखने होंगे.

उपयोगकर्ता, मॉडल को सीधे क्वेरी दे सकते हैं. इन क्वेरी में, टूल के काम के बारे में पूछा जा सकता है. इसके अलावा, ऐसी क्वेरी भी दी जा सकती हैं जिनसे यह पता चलता है कि किसी टूल का इस्तेमाल किया जाना चाहिए. उदाहरण के लिए, "मेरे पिज़्ज़ा में पेपरोनी जोड़ें" एक डायरेक्ट क्वेरी है. "मुझे अपने पिज़्ज़ा में सभी तरह का मीट चाहिए" एक ऐसी क्वेरी है जो साफ़ तौर पर यह नहीं बताती कि किस टूल का इस्तेमाल करना है. इसके लिए, मॉडल को यह समझना होगा कि उसे add_topping टूल की ज़रूरत है. साथ ही, यह भी समझना होगा कि किन टॉपिंग को मीट के तौर पर तय किया जा सकता है.

अपने इवैल के लिए डेटासेट बनाते समय, डायरेक्ट क्वेरी और ओपन-एंडेड क्वेरी, दोनों शामिल करें. डायरेक्ट क्वेरी से, टूल के बुनियादी तौर पर काम करने की जांच की जाती है. वहीं, ओपन-एंडेड क्वेरी से, मॉडल की रीजनिंग और टूल चुनने की लॉजिक की जांच की जाती है.

अगर आपका कॉफ़ी शॉप है, तो आप उन उपयोगकर्ताओं की मदद कर सकते हैं जो अपने एजेंट से, वही कॉफ़ी फिर से ऑर्डर करने के लिए कहते हैं जो उन्होंने पिछले महीने ऑर्डर की थी. पिछले ऑर्डर खोजने के लिए, OrderHistoryService नाम का एक टूल लिखें. साथ ही, कॉफ़ी ऑर्डर करने के लिए एक और टूल लिखें. ऑर्डर हिस्ट्री सेवा को टेस्ट करने के लिए, एक मॉक भेजा जा सकता है. यह मॉक, कॉफ़ी प्रॉडक्ट आईडी दिखाता है.

इस उदाहरण में, यह आकलन किया जाता है कि मॉडल, क्वेरी के मकसद को समझता है या नहीं. साथ ही, यह भी आकलन किया जाता है कि मॉडल, सही टूल चुनता है या नहीं. इसके अलावा, यह भी आकलन किया जाता है कि टूल, कार्रवाई करने के लिए सही जानकारी उपलब्ध कराता है या नहीं. अगर मॉडल, get_order_history को कॉल नहीं करता है, तो उसे यह नहीं पता होगा कि order_product के लिए किस item_id का इस्तेमाल करना है.

एंड-टू-एंड टेस्टिंग

एंड-टू-एंड टेस्ट लिखें, ताकि आपको यह भरोसा हो कि उपयोगकर्ता और उनके एजेंट, अपने सफ़र को सही तरीके से पूरा कर सकते हैं. अलग-अलग टूल को टेस्ट करने के अलावा, यह भी टेस्ट किया जाता है कि एक से ज़्यादा चरणों वाली कार्रवाइयां सही क्रम में की जाती हैं या नहीं.

उदाहरण के लिए, आपकी कपड़ों की एक ऑनलाइन दुकान है. कोई उपयोगकर्ता अपने एजेंट से पूछता है: "मुझे एक काले रंग की जैकेट और एक जोड़ी जींस खरीदनी है. क्या आप इस्तेमाल किए गए मटीरियल की जानकारी दे सकते हैं?"

एजेंट की मदद से उपयोगकर्ता का सफ़र इस तरह हो सकता है:

  1. कपड़ों की कैटगरी पर जाएं.
  2. अनुरोध किए गए कपड़ों में से कोई एक आइटम ढूंढें. आइटम को ढूंढने का क्रम मायने नहीं रखता.
  3. खास आइटम ढूंढें (search_clothes).
  4. प्रॉडक्ट की जानकारी पाएं. इसमें मटीरियल की सूची (get_product_details) शामिल होती है.
  5. अनुरोध किए गए हर आइटम के लिए, चरण 2 से 4 दोहराएं.

जब एजेंट, दूसरे चरण पर पहुंचता है, तो वह पहले काले रंग की जैकेट या जींस ढूंढ सकता है. आइटम को ढूंढने का क्रम मायने नहीं रखता. हालांकि, बाकी चरणों को क्रम से पूरा करना होगा.

एंड-टू-एंड इवैल लिखें, ताकि यह पुष्टि की जा सके कि एजेंट, टूल को उम्मीद के मुताबिक क्रम में कॉल करता है:

{
  "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 के साथ काम करने वाले किसी भी एजेंट की मदद से, WebMCP की सुविधा वाली अपनी साइटों का आकलन करें: