בדיקות רגרסיה - ולמה הן ההגנה החשובה ביותר נגד הידרדרות במערכת?

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

עכשיו מגיעה השאלה המתבקשת: איך מונעים רגרסיות?

כאן נכנסות לתמונה בדיקות רגרסיה (Regression Tests).

מהן בדיקות רגרסיה?

בדיקות רגרסיה הן סט של בדיקות קבועות, שנועדו לוודא:

שכל שינוי בקוד, בגרסה, במודל או בתצורה - לא גרם להידרדרות בהתנהגות המערכת לעומת מה שהיה קודם.

במילים אחרות: הן בודקות שהמערכת לא “הלכה אחורה”.

איך בדיקות רגרסיה עובדות בפועל?

הרעיון פשוט:

1. יש רפרנס - התנהגות שנחשבת “תקינה”.
2. מריצים את אותה פעולה בגרסה החדשה.
3. משווים בין התוצאות.
4. אם יש סטייה משמעותית - יש רגרסיה.
5. אם התוצאות זהות או טובות יותר - אפשר להתקדם בביטחון.

מה בדיוק משווים?

תלוי במערכת.

1. בדיקות רגרסיה לביצועים (Performance Regression Tests)

מודדים:

• זמן ריצה
• FPS
• שימוש בזיכרון
• קצב Throughput
• Latency
• צריכת משאבים של חומרה

כל שינוי קטן למדדים האלה עלול להצביע על רגרסיה.

2. בדיקות רגרסיה לפלט מודל (Output Regression Tests)

משווים פלט חדש מול:

• Golden Output - תוצר תקני שנשמר מראש
• Reference Labels - תוויות ידועות
• Output Bitwise - במערכות שבהן נדרש פלט זהה ביטית

אם הפלט שונה מהותית - יש בעיה.

3. בדיקות רגרסיה פונקציונליות

בודקות:

• האם API עדיין עובד
• האם פונקציות קיימות עדיין מחזירות ערכים תקינים
• האם מקבלים אותו מספר אובייקטים
• האם צדדים רלוונטיים במערכת לא נשברו

למה בדיקות רגרסיה חיוניות במיוחד במערכות ML?

מערכות ML שונות ממערכות תוכנה רגילות:

• פלטים רגישים לכל שינוי קטן
• תלויות בין שכבות ותצורות
• אופטימיזציות שיכולות להשפיע על חלקים אחרים
• התנהגות שמושפעת מצנרת (pipeline) שלמה, לא רק משורה אחת של קוד
• מבחנים של “איכות” ולא רק “נכונות” קשיחה
• קוד אינפרנס שעובד על חומרה ייעודית ויכול להאיט/להאיץ באופן לא צפוי

לכן במערכות ML - רגרסיות קלות מאוד להתרחש, וקשות לזהות ללא כלים מסודרים.

איך בונים סט טוב של בדיקות רגרסיה?

1. משתמשים בנתונים קבועים אותם קלטים → אותן בדיקות → השוואה מדויקת.

2. שומרים רפרנסים תקניים Golden Outputs, מדדים, זמני ריצה, קונפיגורציות.

3. קובעים ספי סטייה לדוגמה: “ירידה מעל 5% בדיוק → רגרסיה”.

4. מריצים את הבדיקות בכל שינוי ב-CI, ב-PR, או לפני שחרור גרסה.

5. כותבים בדיקות שמכסות גם את הביצועים וגם את הפלט שילוב של שני ההיבטים מגלה כמעט כל סוג רגרסיה.

דוגמה פשוטה

נניח שיש לנו מודל YOLO.

רפרנס: על תמונה מסוימת - אמורים להתגלות 5 אובייקטים, וזמן העיבוד אמור להיות 12ms.

בגרסה חדשה:

• המודל מזהה רק 3 אובייקטים, או
• המודל רץ ב-25ms

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

משל

תחשבו על מבחן ריצה שקבועים לו:

• מסלול
• זמן יעד
• מספר תחנות

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

בדיקות רגרסיה הן אותו מבחן - רק לעולם של תוכנה ו-ML.

סיכום

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

• לא שובר פונקציות
• לא פוגע בביצועים
• לא מוריד איכות מודל
• לא משנה פלטים בצורה לא צפויה
• ולא מחזיר את המערכת אחורה

בעולם של ML - שבו קל מאוד לייצר רגרסיות - בדיקות רגרסיה הן הכרח ולא המלצה.