שינוי גרסה: איך מתקנים בלי ליצור תקלה חדשה

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

שלושה עקרונות לפני פריסה#

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

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

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

מה בודקים לפני ואחרי הפריסה#

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

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