التقييمات لـ WebMCP

Kasper Kulikowski

تاريخ النشر: 19 مايو 2026

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

ملاحظة: مزيد من المعلومات حول أهمية التقييمات وكيفية تصميمها لمواقعك الإلكترونية وتطبيقات الويب.

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

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

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

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

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

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

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

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

ماذا لو أراد المستخدِم التحقّق من محتويات سلّته؟

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

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

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

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

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

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

ملاحظة: يمكنك تفعيل استدعاء أداة WebMCP using navigator.modelContext.executeTool(...).

قياس دقة عمليات الاستدعاء

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

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

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

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

تقييم حالات الإخفاق في منتصف السلسلة

عندما يطلب مستخدِم طلب بيتزا باستخدام قسيمة خصم، يتم استدعاء سلسلة من الأدوات بالتسلسل: 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:

• نزِّل أدوات التقييم التجريبية على GitHub.
• راجِع الدورة التدريبية إنشاء تقييمات للذكاء الاصطناعي.