הערכות ל-WebMCP

Kasper Kulikowski

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

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

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

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

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

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

מצבי כשל

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

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

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

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

כשל	דוגמה	פתרון בעיות
הפלט של הכלי שגוי או שהכלי פספס משהו.	המשתמש מבקש 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.