Trajectory Evaluation — בדיקת הדרך שבה הסוכן הגיע לתוצאה

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

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

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

למה תוצאה נכונה לא אומרת דרך בטוחה

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

המסגרת המושגית שעובדת כאן היא לא רק "עבר/נכשל" אלא סיווג כל צעד בנפרד: צעד נחוץ, צעד מיותר אך לא מזיק (בזבוז טוקנים/עלות), וצעד מסוכן (פעולה בלתי-הפיכה או הרסנית שלא הייתה צריכה לקרות). הסיווג הזה מתחבר ישירות ל-Scorecard הרחב שמתואר במדריך ה-Agent Evals הכללי, שם Trajectory הוא אחת משלוש שכבות ההערכה.

איך בונים Assertion על מסלול שלם

בדיקת מסלול נכתבת כרצף של תנאים על סדר האירועים, לא רק על הפלט הסופי. דוגמאות למבני assertion שימושיים: "כלי X לא נקרא לפני שכלי Y הצליח" (תלות סדר), "כלי מחיקה נקרא לכל היותר פעם אחת בכל הריצה" (הגבלת תדירות על פעולה מסוכנת), "אם כלי Z החזיר שגיאה, הצעד הבא חייב להיות ניסיון חלופי ולא חזרה זהה" (בדיקת התאוששות תקינה), ו"מספר הצעדים הכולל לא עולה על סף מוגדר ביחס למורכבות המשימה" (יעילות).

המבנה הזה מצריך שכל ריצה תתעד את הרצף המלא — לא רק את הפלט הסופי — כדי שה-Eval יוכל לרוץ עליו אחרי מעשה. זו בדיוק הסיבה שהתשתית של Trajectory Evaluation תלויה בתשתית Tracing תקינה: בלי לוג מובנה של כל צעד וכל קריאת כלי, אין על מה להריץ את ה-Assertion. הקשר בין השניים — איך לוכדים trace שניתן לבדוק — מפורט במדריך LLM Observability.

הקשר בין Trajectory Eval לבדיקת שימוש בכלים

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

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

עלות וסקייל: אי אפשר לבדוק כל מסלול ידנית

הקושי המעשי ב-Trajectory Evaluation הוא שכתיבת Assertion ידני לכל מסלול אפשרי לא סקיילבילית — למשימה מורכבת יש עשרות מסלולים תקינים שונים. הפתרון שעובד הוא לשלב חוקים דטרמיניסטיים לתנאים ברורים (למשל תדירות קריאה לכלי מסוכן) עם LLM-judge שמקבל את המסלול המלא ומעריך אותו מול רובריקה כללית ("האם הרצף הגיוני ובטוח ביחס למטרה?") — כשהשילוב הזה עצמו כפוף לכל אזהרות הכיול שחלות על כל שימוש בשופט מבוסס מודל, ולא רק על ציון תוצאה בודדת.

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

מסלולים "יצירתיים": מתי סטייה מהתוכנית היא בעיה ומתי היא יתרון

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

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

בניית ספריית מסלולי ייחוס (Reference Trajectories)

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

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

תגיות: Trajectory Evaluation · AI Agents · Tool Use · Observability · Agent Testing

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