Agent Evals ב-2026 — איך בודקים מערכת שאין לה תשובה דטרמיניסטית

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

למה assert(output===expected) לא עובד על סוכני AI, ואיך בונים Scorecard רב-שכבתי שבודק תוצאה, מסלול ושימוש בכלים יחד.

צוות הפיתוח שהטמיע סוכן AI לטיפול בפניות לקוחות בחברת e-commerce ישראלית הריץ ארבעים בדיקות אוטומטיות לפני ה-Deploy, וכולן עברו בירוק. שבוע לתוך הפרודקשן התברר שהסוכן, כשמשתמש ניסח שאלה במילים מעט שונות מהצפוי, בחר לאשר זיכוי כספי כפול במקום פעם אחת — תרחיש שאף בדיקה לא תפסה, כי כל בדיקה בדקה קלט ספציפי מול פלט ספציפי, וסוכן לא חייב לעבור באותו path פעמיים כדי להגיע לאותה מטרה. זה בדיוק לב הקושי של Agent Evals: מערכת שמבוססת על מודל שפה עם temperature, עם החלטות מרובות-שלבים ותלות בתוצאות כלים חיצוניים, לא ניתן לבדוק בשיטת assert(output === expected) הקלאסית. צריך מסגרת חשיבה שונה לחלוטין, שמתייחסת לחוסר הדטרמיניזם כתכונה מובנית של המערכת ולא כבאג שצריך לתקן.

למה בדיקות דטרמיניסטיות נשברות מול סוכן

אי-הדטרמיניזם של סוכן מגיע ממספר מקורות בו-זמנית, ולא רק מ-temperature גבוה מאפס. גם ב-temperature=0 אין הבטחה מלאה לתוצאה זהה בין הרצה להרצה, כי ספקי המודלים מריצים אינפרנס מבוזר עם batching דינמי שמשפיע על עיגול נומרי. מעבר לכך, ספק המודל מעדכן גרסאות "בשקט" מתחת לאותו שם API, כלים חיצוניים מחזירים תוצאות שמשתנות בזמן (מלאי, מחירים, סטטוס הזמנה), וסוכן עם יכולת planning עשוי להגיע לאותה מטרה דרך שני מסלולים שונים לחלוטין ועדיין להיחשב מוצלח.

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

שלוש שכבות של Evaluation לסוכן

Eval אפקטיבי לסוכן בנוי משלוש שכבות שנבדקות בנפרד. השכבה הראשונה היא Task-level (Outcome) — האם המצב הסופי תואם את המטרה, בלי קשר לאיך הגיעו אליו: הזיכוי אושר בסכום הנכון, הכרטיס נסגר בסטטוס הנכון. השכבה השנייה היא Trajectory-level — האם הדרך שבה הסוכן הגיע לתוצאה הייתה קבילה, גם אם התוצאה הסופית נכונה (למשל, סוכן שהגיע לתשובה נכונה אחרי שניסה למחוק רשומה בטעות ותיקן את עצמו לא באמת "עבר" בבטחה). על השכבה הזו יש הרחבה נפרדת במדריך Trajectory Evaluation. השכבה השלישית היא Turn-level / Tool-use — האם כל קריאה בודדת לכלי נעשתה עם הפרמטרים הנכונים.

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

מדוע "עבר/נכשל" בודד לא מספיק

הכלי הנכון הוא Scorecard רב-ממדי במקום ציון בינארי יחיד: נכונות התוצאה (0-1 או ציון מדורג), Efficiency — מספר צעדים, טוקנים ועלות עד לפתרון, Safety — האם נעשה שימוש בכלים מסוכנים שלא לצורך, ו-Latency — זמן עד תגובה. משקלול הממדים האלה תלוי בהקשר העסקי: לבוט תמיכה פנימי Efficiency פחות קריטי מ-Safety, ולסוכן שמריץ אלפי בקשות ביום העלות לבקשה יכולה להכריע החלטת ארכיטקטורה שלמה.

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

בניית golden dataset ייצוגי לסוכן

סט בדיקות טוב לא נכתב פעם אחת ונשאר קבוע — הוא נבנה מדגימה מבוקרת של תעבורת פרודקשן אמיתית, בשילוב מקרי קיצון שנכתבים ידנית. הדגימה צריכה להיות מרובדת (stratified) לפי סוג כוונה, מורכבות השיחה ומספר הצעדים הצפוי, כדי שמקרים נדירים אך קריטיים לא ייעלמו בתוך רוב הפניות הפשוטות. כדאי גם להוסיף מקרי adversarial במכוון — ניסוחים מטעים, בקשות סותרות, ניסיונות prompt injection — כדי לבדוק לא רק יכולת אלא עמידות. הבסיס לבניית סוויטת evals תקינה מתואר במדריך בדיקות לסוכני AI, ואילו ניהול הסוויטה כגרסה חיה לאורך זמן, כולל מעקב אחר שינויים בציון בין גרסאות מודל, מפורט במדריך ה-Evaluation Registry.

נקודה מעשית שרוב הצוותים מפספסים: golden dataset שלא מתעדכן מדגם התעבורה החדשה הופך לבלתי רלוונטי תוך חודשים, כי משתמשים אמיתיים ממציאים ניסוחים וזרימות שאף אחד לא צפה מראש. תהליך רבעוני של דגימה מחדש והוספת מקרים חדשים ל-suite הוא לא "nice to have" — הוא מה שמונע מהבדיקות להפוך למסך עשן.

הלולאה בין אוטומציה לבדיקה אנושית

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

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

מדדים כמותיים שכדאי לעקוב אחריהם לאורך זמן

מעבר לציון ה-Eval הבודד, שווה לעקוב אחרי כמה מדדים משניים שמספרים סיפור שהציון הכולל מסתיר: שיעור ה-Disagreement בין LLM-judge לבודק אנושי לאורך זמן (עלייה בו מעידה שהשופט "התיישן" ביחס להתנהגות החדשה של הסוכן), פיזור הציונים בתוך אותה קטגוריית משימה (שונות גבוהה מעידה שהסוכן לא עקבי גם כשהוא נכון בממוצע), וזמן עד גילוי — כמה זמן עבר מרגע ששינוי בהתנהגות התרחש בפרודקשן ועד שה-Eval הבא תפס אותו. שלושת המדדים האלה, יותר מהציון הממוצע לבדו, הם מה שמבדיל צוות שבאמת שולט ב-Evals מצוות שרק מריץ אותם.

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

תגיות: Agent Evals · AI Testing · Trajectory Evaluation · LLM Agents · Golden Dataset

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