Model Rollback Architecture: מהתגלית לפתרון תוך שניות, לא שעות

מאת צוות מדיה דיל · 08.08.2026 · Enterprise AI · 7 דק׳

כשמערכת AI נשברת בשלוש בבוקר, ההבדל בין תקרית של דקות לתקרית של שעות הוא ארכיטקטורת Rollback שתוכננה מראש. הנה איך בונים אותה נכון.

שלוש בבוקר, on-call מקבל התראה: שיעור התלונות על תשובות ה-Agent זינק פי חמישה בשעה האחרונה. אין זמן לבדוק בדיקה מדוקדקת מה בדיוק השתבש - יש רק זמן לפעולה אחת: להחזיר את המערכת למצב שהיה יציב אתמול. זהו הרגע שבו כל ההשקעה, או היעדר ההשקעה, ב-Model Rollback Architecture משתלמת או עולה ביוקר. rollback טוב לוקח שניות ומבוצע בביטחון מלא. rollback גרוע לוקח שעות, דורש חיפוש בהיסטוריית קוד, ולעיתים מסתיים בכך שהצוות בכלל לא בטוח שהוא חזר בדיוק למצב הקודם. ההבדל בין השניים הוא ארכיטקטורה שתוכננה מראש, לא אלתור תחת לחץ.

מה בדיוק "חוזרים אליו" ב-Rollback של מודל

rollback אמיתי חייב להחזיר את כל המרכיבים שיוצרים את התנהגות המערכת יחד - לא רק את המודל עצמו, אלא גם את הפרומפט שהיה פעיל איתו, את רשימת ה-Tools, ואת קונפיגורציית ה-Retrieval שהזינה אותו. אם חוזרים למודל הישן אבל משאירים פרומפט חדש שנכתב במיוחד עבור המודל החדש, מקבלים קונפיגורציה שלישית שמעולם לא נבדקה - וזה מסוכן לא פחות מהבעיה המקורית. לכן rollback חייב להיות מוגדר ברמת ה-AgentSpec המלא, כפי שתואר במאמר על Agent Versioning, ולא ברמת רכיב בודד.

נקודה עדינה נוספת היא שהחזרה חייבת לכלול גם את השכבות התומכות - אם ה-Retrieval index השתנה בין הגרסאות, חזרה למודל הישן בלי חזרה גם לאינדקס הישן עלולה לייצר קונטקסט לא תואם, שהמודל הישן מעולם לא אומן או נבדק מולו. Registry שמנהל את כל הרכיבים כצירוף יחיד, ולא כרשימת פריטים בלתי תלויים, הוא התנאי המקדים לרול-בק אמין.

Warm Standby: המפתח למהירות

ה-rollback המהיר ביותר הוא זה שלא דורש שום פעולת בנייה מחדש - כלומר, הגרסה הקודמת כבר "חמה" ומוכנה להפעלה מיידית, לא רק מתועדת ב-Registry אלא גם פרוסה ופעילה ברמה טכנית, גם אם היא לא מקבלת תעבורה כרגע. שמירת שתיים-שלוש גרסאות אחרונות במצב warm, במקום להוריד אותן לגמרי כשגרסה חדשה מתפרסמת, היא ההבדל בין rollback שלוקח שניות (החלפת routing) לרול-בק שלוקח דקות ארוכות של deploy מחדש תחת לחץ תקרית.

{
  "rollback_targets": [
    { "version": "v41", "status": "warm", "last_healthy_at": "2026-08-04T09:00:00Z" },
    { "version": "v40", "status": "archived" }
  ],
  "current": "v42",
  "auto_rollback_trigger": {
    "metric": "eval_score_delta",
    "threshold": -0.03,
    "window_minutes": 15
  }
}

Rollback אוטומטי מול Rollback ידני

שאלה ארגונית מרכזית היא מתי לתת למערכת לבצע rollback לבד, ומתי לדרוש אישור אנושי. עבור מדדים חד-משמעיים וברי-מדידה מיידית - שיעור שגיאות טכניות, timeouts, קריסות tool-calling - rollback אוטומטי הוא הבחירה הנכונה, כי כל שנייה של עיכוב מגדילה נזק בלי תועלת מקבילה. עבור ירידה בציוני איכות סובייקטיביים יותר, שדורשים הקשר אנושי לפרש נכון, עדיף alert דחוף לצוות on-call עם כל הנתונים הרלוונטיים כדי לקבל החלטה מושכלת תוך דקות, לא rollback עיוור שעלול להיות תגובת יתר למקרה חריג בודד.

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

Rollback חלקי: לא תמיד הכל או כלום

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

מה עושים עם ה-State שנוצר בזמן הגרסה הפגומה

נקודה שקל לפספס: כשעושים rollback, מה קורה לשיחות שכבר התחילו ורצות מול הגרסה הפגומה? אם ה-Agent שומר state - זיכרון שיחה, פעולות שכבר בוצעו - צריך אסטרטגיה מפורשת: להשלים את השיחות הפעילות עם הגרסה הישנה (graceful drain), או להעביר אותן מיד לגרסה החדשה תוך אובדן קונטקסט מסוים. שתי הבחירות יש להן מחיר, וההחלטה תלויה בסוג המערכת - עבור Agent שמבצע פעולות בלתי הפיכות (כמו תשלום), graceful drain כמעט תמיד עדיף, כדי לא ליצור מצב ביניים מבלבל שבו חצי מהפעולה בוצעה תחת קונפיגורציה אחת וחציה השני תחת קונפיגורציה אחרת.

תיעוד ולמידה מכל אירוע Rollback

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

טעויות נפוצות בפרודקשן

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

מתי כדאי להשקיע בזה

כל מערכת AI שנוגעת בלקוחות אמיתיים זקוקה למנגנון rollback מהיר ומתורגל, ללא יוצא מן הכלל - זו לא שאלה של "אם" אלא "מתי" תהיה תקלה שתדרוש אותו. ההשקעה בבניית warm standby ובתרגול rollback סדיר קטנה משמעותית לעומת עלות תקרית שנמשכת שעות במקום דקות בגלל rollback שלא היה מוכן.

מדדים שכדאי לשים לב אליהם כטריגר

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

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

Rollback מול Roll-Forward: מתי לבחור תיקון מהיר במקום חזרה

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

אחריות ותקשורת בזמן Rollback

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

קשר ל-Canary: הקטנת הצורך ב-Rollback מלכתחילה

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

בדיקות תקופתיות של מנגנון ה-Rollback עצמו

מנגנון rollback שלא נבדק הוא בסיכון שקט להיכשל בדיוק כשהכי צריך אותו - קונפיגורציה ישנה שהצטברה עליה חלודה, גרסת warm standby שמישהו שכח לעדכן, או סקריפט אוטומציה שהופסק לתחזק. תרגול game day תקופתי, שבו מדמים תקרית ומפעילים rollback באמת בסביבת staging, הוא הדרך היחידה לוודא שהמנגנון עדיין עובד כמצופה, ולא רק מתועד יפה במסמך שאיש לא בדק זה חודשים.

מתי rollback מלא הוא לא אפשרות

יש מקרים חריגים שבהם rollback מלא לגרסה הקודמת אינו אפשרי - למשל כשגרסה חדשה כללה שינוי בפורמט נתונים שכבר נכתבו למסד הנתונים, וגרסה ישנה לא יודעת לקרוא אותם. עבור מקרים כאלה נדרש תכנון מראש של תאימות לאחור (backward compatibility) בכל שינוי סכמה, כדי שגם אם הקוד חוזר אחורה, הוא עדיין יכול לקרוא נתונים שנכתבו על ידי הגרסה החדשה יותר - עיקרון שחשוב לבדוק במפורש כחלק מתהליך ה-review לפני כל שינוי מבני.

סיכום

Model Rollback Architecture הוא רשת הביטחון שקובעת אם תקרית production נמשכת דקות או שעות. הוא דורש תכנון מראש - warm standby, טריגרים אוטומטיים מדודים, ותרגול קבוע - ולא ניתן לאלתר אותו בהצלחה בשלוש בבוקר תחת לחץ. ארגונים שמשקיעים בזה מראש הם אלה שישנים טוב יותר בלילה, ושמעזים לזוז מהר יותר בכל שאר הזמן, כי הם יודעים שיש להם דרך חזרה מהירה ואמינה אם משהו משתבש.

תגיות: Model Rollback · Rollback Architecture · MLOps · Enterprise AI · Incident Response · Warm Standby · AI Reliability

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