Tool-Use Evals — מדידת בחירת הכלים והפרמטרים של הסוכן

מאת צוות מדיה דיל · 12.08.2026 · AI Evals · 5 דק׳

איך מודדים אם סוכן AI בוחר את הכלי הנכון עם הפרמטרים הנכונים: Precision/Recall על בחירת כלים, דיוק פרמטרים ברמת שדה, וטיפול בכלים דומים ומסוכנים.

סוכן שמטפל בבקשות "שנה את כתובת המשלוח" קרא לכלי הנכון — update_shipping_address — אבל שלח אליו את מזהה ההזמנה הישן במקום החדש, כי שני השדות נקראו בצורה דומה בהקשר השיחה. התוצאה: הכתובת עודכנה על ההזמנה הלא נכונה, ואף שגיאת runtime לא נזרקה, כי הקריאה הייתה תקנית מבחינת ה-Schema — רק שגויה מבחינה עסקית. זה בדיוק סוג הכשל שרק Tool-Use Evals תופס: לא "האם הסוכן קרא לכלי", אלא "האם הוא בחר את הכלי הנכון, עם הפרמטרים הנכונים, בהקשר הנכון". זו יחידת המידה הכי בסיסית והכי קריטית בהערכת סוכן, כי כל טעות ברמה הזו מתפשטת לכל מה שקורה אחריה.

שלוש שאלות נפרדות שצריך לבדוק בכל קריאת כלי

קריאת כלי בודדת דורשת שלוש בדיקות עצמאיות, שקל לבלבל ביניהן. בחירת הכלי — האם מתוך רשימת הכלים הזמינים, הסוכן בחר את זה שבאמת מתאים למשימה, ולא כלי דומה-אך-שגוי (כמו לבחור cancel_order כשהמשתמש ביקש refund_partial). תקינות הפרמטרים — האם הערכים שנשלחו תואמים ל-Schema מבחינת טיפוס וטווח, בדיקה שניתן לאכוף באופן דטרמיניסטי לחלוטין באמצעות JSON Schema Validation. נכונות סמנטית של הפרמטרים — האם הערכים שעברו את בדיקת ה-Schema גם נכונים בהקשר העסקי, כמו בדוגמת מזהה ההזמנה למעלה — וזו הבדיקה הקשה ביותר, כי שום Validator גנרי לא תופס אותה.

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

מדידה כמותית: Precision, Recall ו-Parameter Accuracy

כדי לעקוב אחר איכות שימוש בכלים לאורך זמן, שני מדדים שאולים מ-Information Retrieval עובדים היטב: Tool Selection Precision — מתוך כל הקריאות שהסוכן ביצע, כמה היו לכלי הנכון, ו-Tool Selection Recall — מתוך כל הקריאות שהיו נחוצות להשלמת המשימה, כמה בוצעו בפועל (כלי שהיה צריך להיקרא ולא נקרא הוא כשל שקל לפספס, כי אין הודעת שגיאה — פשוט משהו שלא קרה). לצדם, Parameter Accuracy נמדד בנפרד לכל שדה: אחוז הקריאות שבהן שדה מסוים קיבל ערך נכון, מה שמאפשר לזהות שדה בעייתי ספציפי (כמו מזהה הזמנה) שחוזר על עצמו כמקור טעויות, גם כשהדיוק הכללי נראה סביר.

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

כלים דומים ומטעים: מקור נפוץ לטעויות

ככל שלסוכן יש יותר כלים זמינים, גדל הסיכוי שכמה מהם דומים מספיק כדי לבלבל את המודל ביניהם — update_order מול update_order_status, או search_customer מול get_customer_by_id. בדיקת Tool-Use Evals טובה כוללת לא רק מדגם משימות אלא גם מבחן ייעודי לזוגות כלים דומים: תרחישים שנועדו במפורש להבחין בין שני כלים קרובים, כדי לוודא שהמודל לא "מנחש" ביניהם. תוצאות המבחן הזה לרוב מצביעות על תיקון פשוט וזול — שיפור תיאור הכלי (description) ב-Schema עצמו — לפני שפונים לפתרונות יקרים יותר כמו fine-tuning.

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

ביטחון ואבטחה: כלים עם השלכות בלתי-הפיכות

לא כל טעות בשימוש בכלי שווה באותה מידה. כלי קריאה-בלבד (search, get) שנבחר בטעות עולה בזבוז זמן ועלות; כלי כתיבה או פעולה (delete, charge, send) שנבחר בטעות עלול לגרום נזק אמיתי ובלתי-הפיך. לכן Tool-Use Evals צריך לתייג כלים לפי רמת סיכון, ולהגדיר סף דיוק גבוה משמעותית לכלים בקטגוריית הסיכון הגבוה — כולל דרישה ל-confirmation step נוסף לפני ביצוע בפועל בפרודקשן, לא רק בזמן בדיקה. הבדיקה הזו חופפת חלקית לתחום בדיקות האבטחה של סוכנים, שמתמקד בשאלה מה סוכן יכול לעשות אם מנוצל בזדון, ומפורטת במדריך Agent Security Testing.

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

בניית סוויטת Tool-Use Evals בפועל

הצעד הראשון בבניית סוויטה הוא לא לכתוב מקרי בדיקה חדשים, אלא לדגום קריאות כלים אמיתיות מלוגים של פרודקשן ולתייג אותן ידנית — נכון/שגוי, ואם שגוי, באיזה משלושת הממדים (בחירה, Schema, סמנטיקה). התיוג הידני הזה, גם על מדגם קטן של כמה מאות קריאות, כבר חושף פערים שקשה לצפות מראש בכתיבה תיאורטית של מקרי בדיקה. משם אפשר לבנות אוטומציה: כלל Schema ריצה על כל קריאה בלי יוצא מן הכלל, ובדיקת סמנטיקה רק על המקרים שה-Schema אישר אך שנראים חשודים לפי כללים היוריסטיים פשוטים (למשל מזהה שלא הופיע בהיסטוריית השיחה).

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

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

תגיות: Tool-Use Evals · Function Calling · AI Agents · Parameter Accuracy · Agent Security

← חזרה לבלוג · צור קשר