التقييمات الخاصة بـ WebMCP

Kasper Kulikowski

تاريخ النشر: 19 مايو 2026، تاريخ آخر تعديل: 28 مايو 2026

تتيح WebMCP استخدام الوكلاء الذين يستندون إلى نماذج الذكاء الاصطناعي التوليدي. لاختبار أي نظام يستخدم الذكاء الاصطناعي التوليدي، يجب أن تدعم اختباراتك النتائج الاحتمالية: يمكن أن يؤدي إدخال واحد إلى آلاف الإجابات بدرجات متفاوتة من الدقة. تُعرف تقنية الاختبار هذه باسم التقييمات.

قبل طرح الأدوات في مرحلة الإنتاج، عليك التأكّد من أنّ الوكلاء يفهمون متى يجب استدعاء الأداة وكيفية تنفيذها وما هي الإجابات المقبولة. معالجة فرص حدوث المشاكل قبل وقوعها

اكتب تقييمات لاختبار نقاط الاتصال في نظامك مع نموذج لغوي كبير (LLM):

• تأكَّد من أنّ النموذج يفهم الغرض من أداتك استنادًا إلى وصفها ومخططها.
• تأكَّد من أنّ النموذج يختار الأداة المناسبة مع المَعلمات الصحيحة لدعم نية المستخدم.
• تأكَّد من أنّ النموذج يتّخذ إجراءً بناءً على المعلومات التي تلقّاها، مثلاً استخدام المعلومات للاتصال بأداة أخرى.
• التحقّق من رحلات المستخدم الناجحة بالنظر إلى نية المستخدم، هل يمكن للوكيل إكمال رحلة المستخدم بنجاح على موقعي الإلكتروني باستخدام الأدوات المتوفّرة؟

عليك مواصلة كتابة اختبارات حتمية كلاسيكية لأي تفاعل مع النظام لا يتواصل مع النموذج.

أوضاع الإخفاق

على المطوّرين اختبار أنظمتهم لتجنُّب حدوث الأعطال قبل وقوعها. ولتحقيق ذلك، عليك فهم الحالات التي قد يتعذّر فيها عمل النظام، سواء بمفرده أو عند تفاعله مع عوامل خارجية. بالنسبة إلى WebMCP، قد لا تعمل الأداة نفسها، وقد لا يتمكّن العملاء من استخدام الأدوات على النحو المتوقّع.

قد لا تعمل أدوات WebMCP بشكل صحيح، وقد لا يعمل الوكيل مع أدوات WebMCP. على سبيل المثال، لنفترض أنّ المستخدم يريد إضافة قميص إلى سلة التسوّق.

تعذّر إتمام العملية	مثال	تحديد المشاكل وحلّها
يفشل الوكيل في اختيار الأداة الصحيحة أو يستدعي الأداة الخاطئة مباشرةً.	يتخطّى الوكيل addToCart وينتقل مباشرةً إلى checkout.	هل description الأداة واضح وكامل ويعكس بدقة ما تفعله الأداة؟ هل functionName سهل الاستخدام وواضح؟ هل يتم عرض الأداة بشكل صحيح للنموذج اللغوي الكبير في الحالة أو السياق الحاليَّين؟ هل مخطط هذه الأداة مشابه جدًا لمخطط أداة أخرى، ما يؤدي إلى عدم وضوح الاستدعاء؟
يستدعي الوكيل الأدوات بترتيب غير صحيح	يستدعي الوكيل checkout ثم addToCart.	هل تتداخل أوصاف الأدوات، ما يؤدي إلى إرباك النموذج اللغوي الكبير بشأن التسلسل المطلوب؟ هل يوفّر ناتج أداة سابقة السياق اللازم لاستخدام الأداة التالية؟ هل يتم تعديل الحالة بشكل صحيح وهل يتم عرض أي أدوات جديدة للنموذج اللغوي الكبير على النحو المتوقّع؟ هل تظلّ حالة الاستخدام الشاملة صحيحة إذا تم استدعاء أدوات معيّنة بترتيب مختلف؟ هل اختبرت سلسلة استدعاء الأدوات المحدّدة بشكلٍ منفصل من خلال فرض عمليات الاستدعاء السابقة للتأكّد من أنّ النموذج اللغوي الكبير يختار الخطوة الصحيحة التالية؟
يستدعي الوكيل الأداة باستخدام وسيطات غير صحيحة	يطلب الوكيل addToCart، لكنّه يضيف أحذية بدلاً من قميص.	هل تم تحديد inputSchema بوضوح، بما في ذلك قيم enum وdescription جيد لكل سمة؟ هل تم وضع علامة صريحة على جميع المَعلمات المطلوبة والتحقّق منها؟ هل يوجّه وصف الوسيطة النموذج اللغوي الكبير بشكل صريح بشأن كيفية ربط بيانات أدخلها المستخدم بالبيانات المنظَّمة المتوقّعة (مثل معرّف أو تنسيق محدّد)؟

ماذا لو أراد المستخدم التحقّق من محتوى سلّة التسوّق؟

تعذّر إتمام العملية	مثال	تحديد المشاكل وحلّها
ناتج الأداة غير صحيح أو أنّ الأداة لا تعرض بعض المعلومات.	يطلب المستخدم viewCart، لكنّ الوكيل يعرض التكلفة الإجمالية لسلة التسوّق بدلاً من أسماء المنتجات وأسعارها الفردية.	هل يتضمّن منطق الأداة الأساسي أخطاء (تحقَّق من ذلك باستخدام الاختبارات المحدَّدة)؟ هل تم تعديل حالة واجهة المستخدم بشكل صحيح وهل تلقّى الوكيل المعلومات الصحيحة حول التأثير الجانبي؟ إذا كان النموذج اللغوي الكبير يستخدم الناتج في طلبات لاحقة، هل يكون الناتج منسّقًا بشكل واضح لكي يستوعبه النموذج اللغوي الكبير؟ هل النتيجة طويلة جدًا؟ هل يحتوي على الحدّ الأدنى من المعلومات الأساسية التي يحتاجها النموذج اللغوي الكبير لاتخاذ الإجراء التالي؟

أخيرًا، يمكن أن تفشل الأداة بأي طريقة يفشل بها JavaScript. لتحديد المشكلة وحلّها، يُرجى التحقّق مما يلي:

• هل يتعامل رمز الأداة بشكلٍ سليم مع جميع أخطاء وقت التشغيل والاستثناءات المحتملة؟
• هل يتم إبلاغ الوكيل والنموذج بالخطأ بشكل سليم؟
• هل واجهات برمجة التطبيقات أو الخدمات الخارجية التي تعتمد عليها الأداة تعمل بشكل سليم؟
• هل بنية الخطأ واضحة بما يكفي ليتمكّن النموذج من التمييز بين مشكلة مؤقتة (إعادة المحاولة) وعطل خطير؟

اختبار الأدوات بشكل منفصل

إذا لم يتمكّن الوكيل من تحديد الأداة التي يجب استخدامها لتلبية طلب مثل "أريد بيتزا صغيرة"، لن يكون لديه أي فرصة في رحلة مستخدم معقّدة.

من خلال اختبار الأدوات بشكل منفصل، يمكنك تحسين المخططات والأوصاف قبل إجراء أي محاكاة للمتصفّح.

قياس دقة المكالمات

يمكنك الاطّلاع على العرض التوضيحي، وهو 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 أو كتعليقات توضيحية بلغة HTML، يمكنك كتابة اختبارات قطعية لتنفيذ المهام التالية:

• تحقَّق من منطق الأداة.
• تأكَّد من استدعاء التبعيات بشكل صحيح.
• تأكَّد من تعديل واجهة المستخدم على النحو المتوقّع، بالإضافة إلى أي آثار جانبية مقصودة أخرى.
• تأكَّد من أنّ المعلومات التي تم إرجاعها تتطابق مع القيمة المتوقّعة.
• التحقّق من صحة مَعلمات الاختبار

على سبيل المثال، إذا كانت أداتك تستخدم الدالة SearchComponent، يمكنك إجراء الاختبار من خلال تمرير نموذج أولي من SearchComponent. تذكَّر محاكاة البيئة التي تعمل فيها الأداة للحصول على أفضل النتائج الممكنة. وهذه هي الطريقة نفسها التي تستخدمها لكتابة اختبار تكامل تطبيق آخر.

إجراء اختبارات احتمالية

إذا كنت بحاجة إلى إخراج نموذج لاستخدام الأدوات التالية بشكل صحيح، عليك كتابة evals.

يمكن للمستخدمين توجيه طلبات مباشرة إلى النموذج تسأل تحديدًا عن وظيفة الأداة، أو طلبات غامضة تشير إلى ضرورة استخدام أداة. على سبيل المثال، "أضِف البيبروني إلى البيتزا" هو طلب مباشر. "أريد كل اللحوم على البيتزا" هو طلب أكثر غموضًا ويتطلّب من النموذج فهم أنّه بحاجة إلى أداة 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.
• راجِع الدورة التدريبية إنشاء تقييمات الذكاء الاصطناعي.