פריסת Canary של סוכני בינה מלאכותית: השקה מדורגת וחזרה לאחור אוטומטית

Canary deployment: מה נשבר בעת עדכון סוכני AI

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

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

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

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

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

מה נותן שחרור מדורג: אפקט במדדים מדידים

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

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

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

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

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

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

מצבי שחרור: ישיר, כחול-ירוק ו-canary deployment

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

השוואת גישות

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

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

סדר ההטמעה: מהביקורת ועד למסירה לתפעול

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

1. ביקורת הקו וקו הבסיס. מנתחים את נתיב השאילתה, הלוגים והמטריקות הנאספות ממילא, ומקבעים את הערכים הנוכחיים בגרסה הפעילה — בלעדיהם אין עם מה להשוות תוצאות חדשות.
2. תיאום מטריקות איכות התשובות. מסכימים מה נחשב להצלחה: שיעור התשובות ללא תיקונים של המפעיל, נכונות החילוצים, תדירות כשלי המודל וההסלמות לאדם.
3. תכנון ניתוב התעבורה. קובעים כיצד מתחלקים הזרמים בין הגרסאות — לפי שיעור משתמשים, סגמנט או סוג שאילתה — ומה קורה למצב של שיחות ארוכות בעת המיתוג.
4. חישוב ספי ה-rollback. עבור כל מטריקה מגדירים גבול סטייה וחלון תצפית, שבחריגה מהם השחרור נעצר והתעבורה עוברת לגרסה הקודמת.
5. הגדרת קו הקנארי. מחברים אוטומציה להשוואת מטריקות, הרצת צל לבדיקה ללא השפעה על המשתמש ותיעוד החלטות הסוכן לניתוח מאוחר יותר.
6. בדיקה על קבוצה מבוקרת. מריצים את הגרסה על מדגם מוגבל, משווים לקו הבסיס, מנתחים אי-התאמות ידנית ורק לאחר מכן מגדילים את שיעור התעבורה.
7. מסירה לתפעול. מוסרים קונפיגורציות, סכמת ניתוב, ספי rollback, נוהל לניתוח תקלות והוראות למשמרת התורן — הצוות משנה שיעורים וגרסאות באופן עצמאי.

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

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

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

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

מקרה בוחן: שחרור גרסה חדשה של סוכן עם rollback אוטומטי

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

השחרור החדש שינה את אסטרטגיית החיפוש ואת בניית התשובה: מערך בדיקות אופליין על נתונים סינתטיים עבר ללא הערות, ולכן שחרור קנארי (canary deployment) הופנה ל-5% מהתעבורה החיה — ולצידו הושארה קבוצת ביקורת באותו גודל על הגרסה הקודמת.

מטריקות לפני ואחרי

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

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

rollback אוטומטי

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

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

מה לעשות אם סוכן AI כבר בפרודקשן ללא rollback?

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

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

לאחר מכן בונים שחרור בטוח — קנארי (canary deployment). הגרסה החדשה אינה מחליפה את הישנה, אלא מופעלת בהדרגה: תחילה שיעור קטן של שאילתות עובר אליה, ואת שאר התעבורה משרתת הגרסה המאומתת.

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

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

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

ספקות טכניים: השהיות, הפעלות שווא, נתונים

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

כיצד ה-rollback לא פועל סתם כך?

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

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

מה קורה עם נתוני המשתמשים?

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

עד כמה אפשר לסמוך על המטריקות?

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

נדון במשימה: סכמת שחרור לקו שלכם

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

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

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