הערכות ל-WebMCP

Kasper Kulikowski

תאריך פרסום: 19 במאי 2026

‫WebMCP תומך בסוכנים שמשתמשים במודלים של AI גנרטיבי. כדי לבדוק מערכת כלשהי באמצעות AI גנרטיבי, הבדיקות צריכות לתמוך בתוצאות הסתברותיות: קלט אחד יכול להוביל לאלפי תשובות עם רמות דיוק שונות. טכניקת הבדיקה הזו נקראת הערכות או evals.

לפני שמשחררים כלים לסביבת הייצור, צריך לוודא שהנציגים מבינים מתי להפעיל את הכלי, איך להפעיל אותו ואילו תשובות מקובלות. לזהות מראש הזדמנויות לשיפור לפני שהן מתרחשות.

כתיבת הערכות כדי לבדוק את נקודות המגע של המערכת עם מודל שפה גדול (LLM):

• בודקים שהמודל מבין את המטרה של הכלי, על סמך התיאור והסכימה שלו.
• מוודאים שהמודל בוחר את הכלי הנכון עם הפרמטרים הנכונים כדי לתמוך בכוונה של המשתמש.
• מוודאים שהמודל פועל על סמך המידע שהוא קיבל, למשל כדי להשתמש במידע לקריאה לכלי אחר.
• אימות של תהליכים מוצלחים שעוברים המשתמשים. בהתחשב בכוונת המשתמש, האם סוכן יכול להשלים בהצלחה את התהליך שהמשתמש עובר באתר שלי באמצעות הכלים שסיפקת?

כדאי להמשיך לכתוב בדיקות דטרמיניסטיות קלאסיות לכל אינטראקציה עם המערכת שלא מתקשרת עם המודל.

מצבי כשל

מפתחים צריכים לבדוק את המערכות שלהם כדי למנוע כשלים לפני שהם קורים. כדי לעשות זאת, צריך להבין מתי המערכת עלולה להיכשל, גם לבד וגם באינטראקציה עם גורמים חיצוניים. ב-WebMCP, יכול להיות שהכלי עצמו ייכשל והסוכנים לא יוכלו להשתמש בכלים כצפוי.

יכול להיות שיהיו כשלים בכלים של WebMCP, וכתוצאה מכך גם בסוכן. לדוגמה, נניח שהמשתמש רוצה להוסיף חולצה לעגלת הקניות.

כשל	דוגמה	פתרון בעיות
הסוכן לא מצליח לבחור את הכלי הנכון או שהוא קורא ישירות לכלי הלא נכון.	הנציג מדלג על addToCart ועובר ישירות אל checkout.	האם התיאור של הכלי description ברור, מלא ומשקף באופן מדויק את מה שהכלי עושה? האם functionName אינטואיטיבי ותיאורי? האם הכלי נחשף בצורה נכונה ל-LLM במצב או בהקשר הנוכחיים? האם הסכימה של הכלי הזה דומה מדי לסכימה של כלי אחר, מה שמוביל לדו-משמעות בקריאה?
הסוכן משתמש בכלים בסדר שגוי	הסוכן מתקשר אל checkout ואז אל addToCart.	האם יש חפיפה בין תיאורי הכלים, שגורמת לבלבול של ה-LLM לגבי הרצף הנדרש? האם הפלט של כלי קודם מספק את ההקשר הדרוש לקריאה הבאה לכלי? האם המצב מתעדכן בצורה נכונה והאם כלי חדשים נחשפים ל-LLM כצפוי? האם תרחיש השימוש מקצה לקצה עדיין נכון אם קוראים לכלים מסוימים בסדר שונה? האם בדקת את השרשרת הספציפית של קריאות הכלים בבידוד על ידי אילוץ הקריאות הקודמות כדי לוודא שמודל ה-LLM בוחר את השלב הבא הנכון?
הנציג קורא לכלי עם ארגומנטים שגויים	הסוכן מתקשר אל addToCart, אבל מוסיף נעליים במקום חולצת טישרט.	האם inputSchema מוגדר באופן ברור, כולל ערכי enum וdescription טוב לכל מאפיין? האם כל הפרמטרים הנדרשים מסומנים ומסומנים בתיבת הסימון? האם תיאור הארגומנט מסביר במפורש למודל ה-LLM איך למפות את קלט של משתמשים לנתונים המובְנים הצפויים (למשל, מזהה או פורמט ספציפיים)?

מה קורה אם המשתמש רוצה לבדוק מה יש בעגלת הקניות שלו?

כשל	דוגמה	פתרון בעיות
הפלט של הכלי שגוי או שהכלי פספס משהו.	המשתמש מבקש viewCart, אבל הסוכן מציג את העלות הכוללת של העגלה במקום את שמות המוצרים והמחירים שלהם.	האם יש באגים בלוגיקה של הכלי הבסיסי (כדאי לבדוק באמצעות בדיקות דטרמיניסטיות)? האם מצב ממשק המשתמש עודכן בצורה נכונה והאם הסוכן קיבל את המידע הנכון לגבי תופעת הלוואי? אם הפלט משמש את ה-LLM לקריאות הבאות, האם הפלט מעוצב בצורה ברורה לצורך עיבוד על ידי ה-LLM? האם הפלט מפורט מדי? האם הוא מכיל רק את המידע החיוני המינימלי שנדרש ל-LLM כדי לבצע את הפעולה הבאה?

לבסוף, כלי יכול להיכשל בכל דרך שבה JavaScript נכשל. כדי לפתור את הבעיה, כדאי לבדוק את הדברים הבאים:

• האם קוד הכלי מטפל בצורה נכונה בכל השגיאות והחריגים הפוטנציאליים בזמן הריצה?
• האם השגיאה מדווחת לסוכן ולמודל בצורה תקינה?
• האם ממשקי API או שירותים חיצוניים שהכלי מסתמך עליהם תקינים?
• האם מבנה השגיאה ברור מספיק כדי שהמודל יוכל להבחין בין בעיה זמנית (ניסיון חוזר) לבין כשל קריטי?

כלי בדיקה מבודדים

אם סוכן לא יכול להבין איזה כלי צריך להפעיל כדי למלא בקשה כמו "אני רוצה פיצה קטנה", הוא לא יוכל להתמודד עם תהליך מורכב של משתמש.

בדיקת כלים בנפרד מאפשרת לכם לבצע אופטימיזציה של הסכימות והתיאורים לפני שמריצים סימולציה בדפדפן.

הערה: אפשר להפעיל קריאה לכלי WebMCP using navigator.modelContext.executeTool(...).

מדידת הדיוק של השיחות

מומלץ לעיין בהדגמה שלנו, WebMCP zaMaker. כשמשתמש מזין את ההנחיה 'I'd like a small pizza' (אני רוצה פיצה קטנה), אפשר לצפות לתשובה של המודל שמציינת את הכוונה לבצע קריאה ל-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. כדי לקבל את התוצאות הטובות ביותר, חשוב לדמות את הסביבה שבה הכלי פועל. זו אותה טכניקה שבה משתמשים כשכותבים עוד בדיקת שילוב של אפליקציה.

הרצת בדיקות הסתברותיות

אם אתם צריכים שהפלט של המודל יפעיל את הכלים הבאים בצורה תקינה, אתם צריכים לכתוב eval.

יכול להיות שמשתמשים יפנו למודל שאילתות ישירות שבהן הם יבקשו באופן ספציפי את מה שהכלי עושה, או שאילתות מעורפלות שמרמזות על שימוש בכלי. לדוגמה, "תוסיף פפרוני לפיצה שלי" היא שאילתה ישירה. ההנחיה "אני רוצה את כל הבשר על הפיצה שלי" היא יותר דו-משמעית, והמודל צריך להבין שהוא צריך להשתמש בכלי 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.
• מומלץ לעיין בקורס שלנו בנושא יצירת הערכות של AI.