מדריך מתקדם ל-Evals: איך לחשוף (ולתקן) כשלים חבויים במודלים ובסוכני AI פיננסיים

תשובה מהירה (Zero-Click Answer):
הערכות ביצועים (Evals) הן מערכת הבדיקות והאיכות של מודלים וסוכני AI, אך כתיבת מדדים (Metrics) מוקדם מדי מובילה למדידת הדברים הלא נכונים. השיטה הנכונה מבוססת על Error Discovery (גילוי שגיאות): מיפוי יומני ריצה מלאים (Traces), סקירה ידנית של מדגם מגוון למניעת Criteria Drift (סחיפת קריטריונים), ושימוש בסוכן קוד (Coding Agent) לבניית אפליקציית תיוג מקומית ואשכול דפוסי כשל (Failure Modes) לסדרי עדיפויות ממוקדי ROI.

---

אם שוחחתם לאחרונה עם מנהלי מוצר AI, מובילי פיתוח או סמנכ"לי כספים שמטמיעים מודלי שפה בארגון, המילה Evals (הערכות ביצועים) עלתה כנראה בכל שיחה שנייה. מייק קריגר (לשעבר ה-CPO של אינסטגרם וראש מעבדות Anthropic כיום) הדגיש לאחרונה כי "אם יש מיומנות קריטית אחת שעלינו ללמד אנשי מוצר וטכנולוגיה, היא כתיבת Evals". גארי טאן, מנכ"ל Y Combinator, הכריז כי "Evals הן החפיר (Moat) התחרותי האמיתי של חברות AI", ויותר ויותר מנהלים מתייחסים ל-Evals כאל ה-PRD החדש (Product Requirements Document).

חברות מובילות כבר מציגות תוצאות עסקיות חותכות מאימוץ מתודולוגיית Evals:

• Shopify השתמשה ב-Evals כדי לפתח בונה תהליכי עבודה מבוסס AI שהיה מהיר פי 2.2 וזול ב-68% ממודל ה-Frontier שהוחלף.
• Cursor שיפרה את מנגנון הניתוב האוטומטי (Auto Balance) שלה, מה שהביא לשביעות רצון גבוהה בהרבה לצד הפחתת עלויות תפעול ב-41%.
• Ramp הקפיצה את דיוק מערכת איסוף והתאמת הקבלות האוטומטית שלה מ-35% ל-83% לאחר השקעה ב-Evals.
• Harvey בנתה מחדש את סוכן בדיקת החוזים המשפטיים והכפילה את ציון האיכות הפנימי של המוצר.

אבל כאן בדיוק מסתתרת המלכודת: בעבודה עם מעל 50 חברות מובילות, המומחים המובילים בתחום — האמל חוסיין (Hamel Husain) ושריה שנקר (Shreya Shankar) — גילו שרוב הצוותים קופצים מיד לשלב כתיבת המדדים (Metrics) ובניית לוחות בקרה נוצצים, ומדלגים לחלוטין על השלב המכריע ביותר: Error Discovery (גילוי שגיאות).

במדריך מעשי זה נפרק את מתודולוגיית ה-Evals המתקדמת, נבין מדוע כשלים קריטיים חומקים מתחת לרדאר של מודלים פיננסיים וסוכני שירות, וכיצד ניתן להקים תהליך גילוי שגיאות היברידי בתוך כ-30 דקות באמצעות סוכני קוד דוגמת Claude Code או Codex.

---

המלכודת: למה כתיבת מדדים מוקדמת מזיקה למוצר שלכם?

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

מדוע אם כן רוב הצוותים נכשלים?

סריקת יומני אינטראקציה (Traces) ארוכים של משתמשים נתפסת כעבודה שחורה, איטית וקשה לסקייל, בעוד שכתיבת מדדים מספריים (כמו Accuracy, BLEU, ROUGE או התאמת מילות מפתח) היא קונקרטית, פשוטה לאוטומציה ונראית מצוין במצגות הנהלה. אך כשכותבים מדדים מוקדם מדי:

1. מבצעים הנחות יסוד שגויות: מניחים שיודעים מראש מהן נקודות השבר של המודל.
2. מודדים את הדברים הלא נכונים: מייצרים "מדדי יהירות" (Vanity Metrics) שלא משקפים את החוויה האמיתית של הלקוח או את הדיוק העסקי הנדרש.
3. מפספסים את ה-ROI: בדומה לכך ש-Product Discovery מגלה אילו בעיות שווה לפתור, Error Discovery מגלה אילו שגיאות שווה למדוד ולעקוב אחריהן לאורך זמן.

[!IMPORTANT] כלל זהב: אם יש לכם זמן לבצע רק חלק אחד מתוך כל תהליך ה-Evals — תנו עדיפות מוחלטת ל-Error Discovery. ללא שלב זה, תבנו מדדים סביב תקלות תיאורטיות ותפספסו את הנזקים האמיתיים בפרודקשן.

---

מהו Criteria Drift (סחיפת קריטריונים) וכיצד הוא מפיל מערכות AI?

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

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

דוגמה מעשית מהשטח: עוזר הליסינג הדיגיטלי (Nurture Boss)

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

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

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

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

תוצאות סריקת 100 שיחות פרודקשן:

במחקר מקיף על 100 יומני ריצה אמיתיים של הסוכן נמצאו תובנות קריטיות:

1. סוכנים פספסו כשלים שדורשים שיקול דעת מוצרי והקשר חיצוני: למשל, שימוש בעיצובי Markdown לא נתמכים ב-SMS, אי-ביצוע Human Handoff בזמן, או החמצת הזדמנויות מכירה.
2. סוכנים מצטיינים בזיהוי סתירות פנימיות בתוך ה-Trace: למשל, כאשר המודל טוען שדירה פנויה למרות שקריאת ה-API (Tool Call) החזירה שהיא כבר הושכרה.
3. סוכנים מייצרים "רעש" (False Positives): הם מתייגים תשובות טובות ותקינות ככישלונות עקב היעדר גמישות.

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

---