הסוכן ה-AI שהשקתי עבר 23 בדיקות יחידה (unit tests), אך תוך שעה מרגע עלייתו לאוויר הוא המציא תכונת מוצר ונתן הצעת מחיר נמוכה פי שלושה מהמציאות. כשהמשתמש העיר לו על כך, הבוט התעקש על עמדתו, השיחה הסתיימה, ואיבדתי לקוח. הטעות הוכיחה שחבילת בדיקות יחידה דטרמיניסטיות אינה יכולה להבטיח את האמינות של סוכן.
למה בדיקות יחידה אינן מספיקות עבור סוכני AI
בדיקות יחידה עובדות בקוד מסורתי מכיוון שאותו קלט תמיד מניב את אותו פלט. "2 + 2 = 4" זו הבטחה שניתן לאמת באמצעות בדיקת שוויון פשוטה. לעומת זאת, סוכן מונע LLM משנה את הפלט שלו בהתאם לפרומפט, להקשר הסובב ולמצב של כל כלי חיצוני שהוא קורא לו. בדיקה שבודקת שוויון מחרוזת מדויק מפספסת הזיות (hallucinations), שינויי טון או הפרות של מגנוני הגנה (guardrails). הכשל השקט שעלה לי בלקוח מראה שיש להעריך את האינטראקציה כולה, ולא רק פונקציות מבודדות.
בניית מערך הערכה (evaluation harness) לפני כתיבת קוד של תכונות חדשות
הפכתי את סדר הפיתוח: קודם כל תכנון מערך הערכה בעל ארבע שכבות, ורק אז כתיבת הסוכן. המערך מריץ 131 בדיקות במעבר אחד, עולה בערך שלושה סנט להרצה, ומסתיים תוך כעשר-עשרה דקות. אני מקצה לכל בדיקה את המודל הקטן ביותר שיכול להתמודד איתה, ושומר מודלים גדולים ויקרים יותר לרגעים שבהם הם באמת מוסיפים ערך.
שכבה 1 – פונקציונליות של כלים (Tool functionality)
קו ההגנה הראשון בודק האם הסוכן יכול לקרוא לכלים שלו בצורה נכונה. הבדיקות מכסות חיפושים מוצלחים, שאילתות משובשות במכוון וכשלים מסומלצים של API. מכיוון ששימוש בכלים הוא במידה רבה דטרמיניסטי – או שהבקשה מנוסחת נכון או שה-API מחזיר שגיאה – הצהרות (assertions) פשוטות ב-Python מספיקות. זיהוי בקשה משובשת בשלב זה מונע בלבול בשלבים הבאים.
שכבה 2 – מילוי הוראות (Instruction following)
לאחר מכן, המערך מוודא שהסוכן מכבד את מגנוני ההגנה (guardrails). LLM קטן יותר משמש כמעריך, וסורק את תגובת הסוכן כדי לוודא עמידה בדרישות: שמירה על דמות, הימנעות מנושאים אסורים והפקת סכימת JSON נדרשת. שכבה זו תופסת סטייה סמנטית (semantic drift) שבדיקות יחידה מפספסות, כמו החלקה לדמות לא מכוונת או דליפת פרומפטים פנימיים.
שכבה 3 – התנהגות מכוונת מטרה (Goal-oriented behavior)
השכבה השלישית היא הקריטית ביותר. היא בוחנת האם הסוכן אכן משיג את מטרתו. עבור בוט ליצירת לידים (lead-generation), המשמעות היא אישור שהוא שואל את שאלות הסינון הנכונות ומעביר את השיחה לנציג אנושי במידת הצורך. אני משתמש כאן במודל מונחה-הסקה (reasoning-oriented) מכיוון שהוא יכול להעריך את הזרימה הכוללת מבלי לנפח את העלויות. אם הבוט נכשל בהשגת מטרתו – גם אם עבר את שתי השכבות הראשונות – הוא מסומן לצורך עיצוב מחדש.
שכבה 4 – ביצועים (Performance)
לבסוף, המערך מתעד שיהוי (latency) ומהירות יצירת טוקנים. תגובות איטיות פוגעות בחוויית המשתמש, במיוחד בצ'אט בזמן אמת. על ידי מעקב אחר מדדים אלו לצד נכונות פונקציונלית, אני מבטיח שהסוכן יהיה גם מדויק וגם מהיר תגובה.
בחירות לחיסכון בעלויות
הנתון של 0.03$ להרצה אינו תעלול שיווקי; הוא נובע מהתאמת מורכבות הבדיקה לגודל המודל. בדיקות כלים דטרמיניסטיות רצות על סביבת ההרצה הזולה ביותר, בדיקת עמידה בהוראות משתמשת במודל קל משקל, ורק הערכות מכוונות-מטרה מפעילות מודל בעל יכולות גבוהות יותר, אם כי יקר יותר. גישה מדורגת זו שומרת על ההוצאה הכוללת נמוכה מספיק כדי להריץ את החבילה המלאה בכל שינוי בקוד.
הפשרה: מהירות מול בטיחות
הכנסת מערך ההערכה הוסיפה חיכוך ראשוני. מחזורי הפיתוח התארכו, ולוח הזמנים להשקה נדחה.
מה כדאי לעקוב אחריו בהמשך
- מעריכים מונחי-מודל: ככל ש-LLMs ישתפרו, המעריך בשכבה 2 יוכל להפוך למדויק ומורכב יותר, מה שיפחית התראות שווא (false positives) תוך המשך זיהוי הפרות מדיניות עדינות.
שורה תחתונה
אם אתם בונים סוכני AI לסביבת ייצור (production), מערך הערכה מדורג אינו אופציונלי; הוא יסודי. על ידי העברת עלויות הבדיקה המקיפה לתחילת התהליך – 0.03$ להרצה, אחת-עשרה דקות לכל חבילה – אתם מגינים מפני הכשלים השקטים שבדיקות יחידה פשוט אינן יכולות לזהות.