בדיקת סוכן AI אינה בדיקת תוכנה ואינה בדיקת מודל. סוכן מריץ מסלול שמשתנה בין הרצה להרצה, ולכן המדד היחיד שרלוונטי הוא התפלגות: אותה משימה, אותם תנאים, עשרים הרצות — כמה מהן הסתיימו נכון. החשבון פשוט ואכזרי: סוכן שמדייק ב-95% בכל צעד יסיים נכון רק 60% ממשימות בנות עשרה צעדים. מערך evals עובד מורכב מארבעה חלקים: סט מקרים מהעולם האמיתי, מדידה בארבע רמות, בדיקת רגרסיה בכל שינוי, וניטור בייצור.
למה בדיקות תוכנה רגילות לא עובדות כאן
בתוכנה רגילה הבדיקה מניחה דטרמיניזם: אותו קלט מייצר אותו פלט, ולכן מספיק לכסות את הנתיבים. בסוכן ההנחה הזו לא מתקיימת. אותו קלט יכול לייצר מסלול אחר, סדר כלים אחר ותוצאה אחרת — לא בגלל באג אלא בגלל אופן הפעולה של המודל.
לכן שאלת הבדיקה משתנה. במקום עבר או נכשל, השאלה היא באיזו שכיחות הוא מצליח, וכמה רחוקה הכישלון הגרוע ביותר מהממוצע. הצוותים שנשרפים הם אלה שראו הדגמה מוצלחת, הסיקו שהמערכת עובדת, וגילו בייצור שההדגמה הייתה ההרצה הטובה מתוך חמש.
מדד ההצלחה הנפוץ בתעשייה בודק הצלחה אחת בתנאים אופטימליים. בייצור מה שקובע הוא היציבות — אותה משימה, הרבה הרצות. הפער בין שני המספרים הוא הפער בין הדגמה לבין מערכת.
החשבון שמסביר כמעט הכול
סוכן מבצע משימה כשרשרת צעדים. אם כל צעד עצמאי, שיעור ההצלחה של המשימה הוא מכפלת הסתברויות. זה נראה טריוויאלי עד שמציבים מספרים.
| דיוק לצעד בודד | משימה בת 5 צעדים | 10 צעדים | 20 צעדים |
|---|---|---|---|
| 90% | 59% | 35% | 12% |
| 95% | 77% | 60% | 36% |
| 98% | 90% | 82% | 67% |
| 99% | 95% | 90% | 82% |
שתי מסקנות תפעוליות נובעות מכאן. הראשונה: קיצור המשימה שווה יותר משיפור המודל. מעבר מעשרים צעדים לעשרה בדיוק של 95% מכפיל את שיעור ההצלחה מ-36% ל-60%. השנייה: בשרשראות ארוכות צריך דיוק לצעד שקשה מאוד להשיג, ולכן משימות ארוכות מחייבות נקודות עצירה ואימות באמצע ולא לולאה אחת רציפה.
זו גם הסיבה שמשימות ארוכות במיוחד עדיין נכשלות ברוב המקרים גם עם המודלים הטובים ביותר. פירוק לתת-משימות עם אימות ביניים אינו פשרה הנדסית — הוא הדרך היחידה שהמתמטיקה מאפשרת.
איך בונים סט בדיקות שבאמת מלמד משהו
סט בדיקות שנכתב על ידי מי שבנה את הסוכן ייכשל בייצור, מפני שהוא משקף את מה שהמפתח דמיין. הסט הנכון מגיע משלושה מקורות.
| סוג מקרה | מאיפה לוקחים | כמה |
|---|---|---|
| מסלול תקין | עשרים הפניות האחרונות שטופלו ידנית | כ-40% מהסט |
| קצוות אמיתיים | תלונות, החזרות, מקרים שדרשו הסלמה | כ-40% מהסט |
| מקרים עוינים | ניסיונות הזרקה, קלט חסר, סתירות, בקשות מחוץ לתחום | כ-20% מהסט |
לכל מקרה צריך להיות מוגדר מראש מה נחשב הצלחה. לא ציון סובייקטיבי אלא תנאי בדיק: השדה עודכן לערך הנכון, המייל נשלח לכתובת הנכונה, הסכום זהה לחישוב הידני, או הסוכן סירב לפעול והסלים. מקרה בלי תנאי הצלחה הוא לא מקרה בדיקה, הוא התרשמות.
גודל התחלתי סביר: 40 עד 80 מקרים, כל מקרה מורץ חמש עד עשר פעמים. זה נשמע הרבה, אבל זו הרצה של דקות ספורות ועלות של כמה דולרים — לעומת לקוח אחד שקיבל תשובה שגויה.
ארבע רמות מדידה
מדידת תוצאה בלבד מסתירה את הסיבה. מערך שימושי מודד בארבע רמות במקביל.
| רמה | מה נמדד | מה זה מגלה |
|---|---|---|
| תוצאה | האם תנאי ההצלחה התקיים | האם המערכת עומדת ברף העסקי |
| מסלול | סדר הכלים שנבחרו ומספר הצעדים | איפה הסוכן מתחיל לסטות, לפני שהתוצאה נשברת |
| כלי | שיעור קריאות עם ארגומנט שגוי או כלי לא מתאים | אילו תיאורי כלים צריך לתקן |
| עלות | טוקנים, קריאות וזמן למשימה | האם הפתרון כלכלי בקנה מידה |
רמת המסלול היא החשובה ביותר לדיבוג. שגיאה בסוכן מתגלה בדרך כלל רחוק מהמקום שבו נוצרה, ולכן בלי לוג מלא של כל קריאה ותוצאה אי אפשר למצוא את הצעד שהתחיל את הסטייה. הרקע המבני לכך מוסבר באנטומיה של סוכן AI עסקי.
רגרסיה: מה שובר סוכן בלי שנגעתם בו
סוכן הוא מהמערכות היחידות שיכולות להישבר בזמן שאף אחד לא שינה בהן שורה. שלוש סיבות עיקריות.
עדכון מודל. ספק מעדכן גרסה, וההתנהגות משתנה — לרוב לטובה בממוצע ולרעה במקרים ספציפיים שהיו מכוילים לגרסה הקודמת. לכן כל שדרוג מודל מחייב הרצה מלאה של הסט לפני מעבר.
שינוי בסכמת כלי. שדה שהוסף, שם שהשתנה, ערך ברירת מחדל חדש. הסוכן לא יקרוס; הוא ימשיך לקרוא לכלי בצורה שהייתה נכונה אתמול.
סחף נתונים. מבנה הפניות משתנה עם הזמן, מוצרים חדשים נכנסים, ניסוחי לקוחות משתנים. סט בדיקות בן שנה בודק עולם שכבר לא קיים.
כלל עבודה פשוט: הסט רץ אוטומטית בכל שינוי בפרומפט, בכלים או במודל, ומתרענן ברבעון מתוך תנועה אמיתית.
ניטור בייצור — הדבר היחיד שמודד את האמת
הסט מודד מה שחשבתם לבדוק. ייצור מודד את מה שקורה. ארבעה מדדים מספיקים כדי לתפוס כמעט כל בעיה בזמן.
- שיעור השלמה. אחוז המשימות שהסתיימו בלי התערבות אנושית ובלי כשל.
- שיעור הסלמה. כמה פעמים הסוכן עצר וביקש אדם. עלייה פתאומית מסמנת שינוי בקלט, ירידה פתאומית מסמנת ביטחון מופרז.
- שיעור תיקון. באיזו תדירות אדם שינה את מה שהסוכן הציע. זה המדד הכי קרוב לאיכות אמיתית.
- עלות למשימה מוצלחת. לא עלות לקריאה. משימות שנכשלות ומורצות מחדש הן העלות האמיתית — הצד הכספי מפורט במדריך הורדת עלות ה-inference.
שיעור התיקון הוא גם הסימן המובהק ביותר לכך שנקודת האישור ממוקמת נכון או לא. אם כמעט אף אחד לא מתקן, האישור הפך לחתימה אוטומטית — נושא שמפורט במדריך האדם בלולאה.
רשימת בדיקה לפני שהסוכן נוגע בלקוח
- לכל מקרה בסט יש תנאי הצלחה חד-משמעי שנכתב לפני ההרצה.
- כל מקרה מורץ לפחות חמש פעמים, והמדד המדווח הוא היציבות ולא ההרצה הטובה.
- הסט כולל מקרים עוינים, כולל ניסיון הזרקה דרך כל ערוץ קלט — ראו מדריך ההרשאות.
- קיים לוג מלא של קריאות כלים ותוצאות לכל הרצה, שמור וניתן לחיפוש.
- הוגדר רף עסקי מספרי לעלייה לאוויר, ולא תחושה של מספיק טוב.
- הוגדר תרחיש נסיגה: מה קורה כשהסוכן נכשל, ומי מקבל את המשימה.
שאלות נפוצות
מה זה evals לסוכן AI?
מערך בדיקות שמודד את התנהגות הסוכן על סט מקרים מוגדר מראש, כל מקרה במספר הרצות, ומדווח את התפלגות התוצאות ולא הצלחה בודדת. הוא כולל מדידה של התוצאה, של המסלול, של שימוש בכלים ושל העלות.
כמה מקרי בדיקה צריך?
סט התחלתי של 40 עד 80 מקרים מכסה את רוב ההתנהגות של סוכן משימה יחידה, בתנאי שהוא מחולק בין מסלול תקין, קצוות אמיתיים ומקרים עוינים. חשוב יותר ממספר המקרים הוא מספר ההרצות לכל מקרה, שצריך להיות לפחות חמש.
למה סוכן שעבד בהדגמה נכשל בייצור?
מפני שההדגמה מדדה הרצה אחת בתנאים נוחים. בייצור המשימה ארוכה יותר, הקלט מלוכלך יותר, והשגיאות מצטברות לאורך הצעדים. סוכן בדיוק של 95% לצעד מסיים נכון רק כ-60% ממשימות בנות עשרה צעדים.
האם אפשר להשתמש במודל כדי לשפוט את הסוכן?
אפשר, אך רק כשכבה משלימה. שיפוט אוטומטי מתאים למדדים איכותיים כמו טון או שלמות תשובה, ולא לתנאי הצלחה שניתן לבדוק דטרמיניסטית. כל מקרה שאפשר לבדוק בהשוואת ערכים צריך להיבדק כך.
מתי מריצים את סט הבדיקות?
בכל שינוי בפרומפט, בכלים או בגרסת המודל, וכן ברענון תקופתי של הסט מתוך תנועה אמיתית. סוכן יכול להישבר גם כשלא נגעו בו, בעיקר בעקבות עדכון מודל או שינוי בסכמת כלי.
