בדיקת WebMCP עם Evals

Kasper Kulikowski

פורסם: 19 במאי 2026, עדכון אחרון: 28 במאי 2026

סרטון הסבר	פיתוח אתרים	תוספים	סטטוס של Chrome	הרציונל
GitHub	גרסת מקור לניסיון		תצוגה	הבעת כוונות לניסוי

‫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 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" }
            }
          ]
        }
      ]
    }
  ]
}

הערכת כשלים באמצע השרשרת

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

"I'd like a small Pesto pizza. אני רוצה להשתמש בקוד ההטבה שלי, FreePizza".

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

ניסוי של WebMCP

כדאי להתחיל להתנסות בהערכות של כלים בבידוד ולהעריך את האתרים שלכם עם WebMCP באמצעות כל סוכן שתואם ל-WebMCP:

• אפשר להוריד את כלי ההערכה הניסיוניים שלנו ב-GitHub.
• מומלץ לעיין בקורס שלנו בנושא יצירת הערכות באמצעות AI.