למה חייבת להיות הפרדה בין Test Code לקוד Production במערכות ML?

בעולם של למידת מכונה, יש משפט אחד שתמיד חוזר: מודל טוב אינו בהכרח אומר מערכת טובה.

מערכת ML כוללת:

• קוד אימון
• קוד בדיקות
• קוד פרודקשן
• קוד הערכה
• תשתיות נתונים
• מודלים, גרסאות ותיעוד

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

למה? כי ערבוב בין השניים עלול לגרום לתוצאות שגויות, שבריריות ובאגים שקשה לגלות.

מהו Test Code ומהו Production Code?

Test Code

קוד שנועד:

• לבדוק את המודל
• לוודא איכות
• לבצע בנצ’מרקים
• ליצור מצבים מבוקרים
• להשוות לתוצאות רפרנס

הוא לא רץ במערכת האמיתית, והוא לא מיועד לביצועים גבוהים או לעמידות לאורך זמן.

Production Code

קוד שנועד:

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

זה הקוד שלקוחות, משתמשים או מערכות אחרות באמת עובדים מולו.

למה חייבת להיות הפרדה?

1. אמינות - מניעת באגים חבויים

כשהבדיקות יושבות בקוד הראשי:

• שינוי קטן לצורך בדיקה עלול לשבור התנהגות בפרודקשן
• תנאי “זמני” נשאר ל-6 חודשים
• המערכת מתנהגת אחרת ממה שחשבת

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

2. ביצועים - Test Code כמעט תמיד איטי

קוד בדיקות:

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

בפרודקשן → אף אחד לא רוצה לשלם על זה.

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

3. רפרנסים וגרסאות - בדיקות מניחות ידע פנימי

Test Code:

• משתמש ב-ground truth (תוויות אמת) כדי להשוות עם תחזיות המודל
• קורא קבצי reference
• משווה תוצאות bitwise (בדיקת תוצאות ברמת דיוק של ביט אחר ביט)
• מריץ בדיקות רגרסיה (סט בדיקות שמוודא שהשינוי בקוד לא גרם לירידה בביצועים או לשבירת התנהגות שעבדה בעבר)

בפרודקשן → אין Ground Truth. זו מערכת “עיוורת” שצריכה להגיב לכל קלט.

לכן אסור לקוד פרודקשן להישען על הנחות של בדיקות.

4. אבטחה ויציבות

קוד בדיקות כולל לפעמים:

• הדפסות debug
• גישה לקבצים מקומיים
• כלים פנימיים
• פרמטרים נסתרים
• סימולציות

אלו דברים שלא אמורים להיכנס למערכת חיה.

איך מבטיחים הפרדה נכונה?

כלל 1: מחיצות בקוד תיקיות שונות, מודולים נפרדים.

כלל 2: אין בדיקות בפרודקשן לא השוואות, לא asserts, לא כתיבה ל-reference.

כלל 3: לא מערבבים נתוני בדיקות עם נתוני מערכת Ground Truth שייך לסביבת QA בלבד.

כלל 4: תצורה שונה לסביבות test.yaml, prod.yaml, dev.yaml - הפרדה חדה בעזרת קבצי קונפיגורציה.

כלל 5: כלי CI מריצים בדיקות - לא ה-Production Runtime חשוב במיוחד בפרויקטים של ML.

משל קצר

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

ב-ML זה בדיוק אותו עיקרון.

סיכום

במערכות ML הפרדה בין test code לבין production אינה “nice to have” - היא הכרחית.

• Test Code בודק איכות
• Production Code מספק ביצועים
• בדיקות משתמשות ב-ground truth
• מערכת חיה לא יכולה לסמוך עליו

ערבוב יוצר באגים, רעשים והדרדרות בביצועים.

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