اختبار WebMCP باستخدام Evals

Kasper Kulikowski

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

فيديو توضيحي	الويب	الإضافات	حالة Chrome	النيّة بالشراء
Github	مرحلة التجربة والتقييم		العرض	Intent to Experiment

تتيح 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. تذكَّر محاكاة البيئة التي تعمل فيها الأداة للحصول على أفضل النتائج الممكنة. وهذه هي الطريقة نفسها التي تستخدمها لكتابة اختبار Application Integration آخر.

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

إذا كنت بحاجة إلى إخراج نموذج لاستدعاء الأدوات التالية بشكل صحيح، عليك كتابة 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.
• راجِع الدورة التدريبية إنشاء تقييمات باستخدام الذكاء الاصطناعي.