Regression Testing לסוכני AI אחרי החלפת מודל

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

למה החלפת מודל יכולה לשבור סוכן בלי שינוי קוד אחד, ואיך בונים Benchmark Diff מבוסס נתונים סטטיסטיים בין גרסת מודל ישנה לחדשה.

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

למה Regression Testing לסוכן שונה מ-Regression רגיל

ב-Regression Testing מסורתי, ריצה חוזרת על אותו קוד עם אותו קלט מבטיחה אותה תוצאה — ולכן שינוי בתוצאה מצביע ישירות על שינוי בקוד. עם סוכני AI, שלושה גורמים יכולים לשנות התנהגות בלי שינוי קוד כלשהו: עדכון גרסת מודל אצל הספק, שינוי בתוצאות כלים חיצוניים (API של צד שלישי שהתנהגותו השתנתה), ואפילו שינוי סמוי ב-System Prompt שמוזרק ע"י שכבת תשתית משותפת. המשמעות: כדי לבודד את מקור הרגרסיה, צריך לתעד ולנעול כל אחד מהגורמים האלה בנפרד בזמן ההשוואה — לא רק "להריץ שוב ולהשוות ציון".

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

Benchmark Diff: השוואה ישירה בין שתי גרסאות מודל

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

results = run_suite(model="old-model", cases=golden_set)
results_new = run_suite(model="new-model", cases=golden_set)
regressions = [c for c in golden_set
  if results[c.id].passed and not results_new[c.id].passed]
print(f"{len(regressions)} regressions found")

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

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

בגלל אי-הדטרמיניזם, השוואת ציון בודד בין שני מודלים לא מספיקה — צריך להריץ כל מקרה מספר פעמים (למשל 5-10 חזרות) על כל מודל, ולהשתמש במבחן סטטיסטי (כמו McNemar's Test להשוואת שני מסווגים על אותם מקרים) כדי לקבוע אם ההבדל בציון משמעותי או בגדר רעש. הבדל של שתי נקודות אחוז בין מודלים על סט של 50 מקרים לרוב לא משמעותי סטטיסטית, וקבלת החלטה על בסיסו היא טעות נפוצה.

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

ניהול Baseline: מתי "מעדכנים" את קו הבסיס

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

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

עדכוני מודל "שקטים": איך תופסים אותם בכלל

לא כל שינוי מודל הוא מעבר יזום ומתוכנן. ספקי מודלים לעיתים משדרגים גרסה מתחת לאותו מזהה API בלי הודעה מפורשת, מה שאומר שהתנהגות הסוכן עשויה להשתנות בלי שאף אחד בצוות יזם שינוי. הדרך היחידה לתפוס את זה היא הרצה מתוזמנת (nightly או שבועית) של אותה סוויטת Regression על אותו מזהה מודל, והשוואת התוצאות מול Baseline השבוע הקודם — לא רק מול Baseline המקורי. סטייה פתאומית בציון בלי שום שינוי קוד היא אות אזהרה ברור לעדכון שקט אצל הספק, ומצריכה חקירה מיידית ולא התעלמות.

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

מעבר לזיהוי, כדאי להחזיק תוכנית Rollback מוכנה מראש לכל מודל בפרודקשן — לא רק תיאורטית אלא כ-Feature Flag שניתן להפעיל תוך דקות, שמחזיר את התעבורה לגרסת המודל הקודמת עד שהבעיה נחקרת. ארגונים שמגלים רגרסיה אבל לוקח להם יום שלם רק כדי לחזור אחורה סופגים נזק מיותר לגמרי, שהיה נמנע בקלות עם תשתית Rollback שהוכנה מראש ולא אולתרה תחת לחץ.

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

תגיות: Regression Testing · Model Migration · AI Evals · Benchmark Diff · Shadow Evaluation

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