בדיקת WebMCP עם Evals

Kasper Kulikowski

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

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

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

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

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

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

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

מצבי כשל

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

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

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

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

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

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

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

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

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

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

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

הציצו בהדגמה שלנו, 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. כדי לקבל את התוצאות הכי טובות, חשוב לדמות את הסביבה שבה הכלי פועל. זו אותה טכניקה שבה משתמשים כשכותבים עוד בדיקת שילוב של אפליקציה.

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

אם אתם צריכים שהפלט של המודל יקרא בצורה נכונה את הכלים הבאים, אתם צריכים לכתוב 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.
• סקור את הקורס שלנו, צור הערכות בינה מלאכותית.