פיתוח מערכת ניהול גרסאות לסוכני AI (Agent Versioning)

מדוע ללא מערכת ניהול גרסאות לסוכני AI נשבר התפעול

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

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

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

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

נשארת הברירה לתקן בעיוורון עד למצב של «זה נראה דומה», או לעצור את הסוכן ולבדוק ידנית, תוך אובדן שעות בכל מקרה ובלי ערובה שהסיבה נמצאה.

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

מה משתנה בתפעול לאחר הנהגת ניהול גרסאות

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

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

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

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

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

השוואת גישות: צילום מצב, דלתא ומהדורה מדורגת

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

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

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

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

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

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

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

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

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

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

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

מה נשאר בידיים: מרשם גרסאות ומדיניות מהדורות

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

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

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

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

איך הוציאו מהדורות לפני ההטמעה

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

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

מה שינו ומה קיבלו

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

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

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

זמן ההשבתה של השירות באירוע הצטמצם מ-40–60 דקות ל-2–4, שיעור המהדורות עם התערבות ידנית — ממחצית למקרים בודדים, וניתוח התקלה מתחיל כעת בשאלה «איזו גרסה השיבה בדיאלוג הזה» ומקבל תשובה מדויקת לפי היומן.

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

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

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

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

שאלות של מהנדסים: חזרה לאחור, תאימות, הרשאות

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

תאימות אינטגרציות בעת עדכון הסוכן

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

איך מופרדת הגישה לגרסאות ולפריסה?

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

מה לעשות אם המודל החיצוני התעדכן אצל הספק?

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