הגדרת Model Registry לניהול גרסאות מודלים

למה בלי Model Registry גרסאות המודלים מתפצלות מהפרודקשן

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

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

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

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

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

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

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

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

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

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

וריאנטים של Model Registry: ענן, סביבה עצמאית, היברידי

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

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

איך לבחור

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

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

רישום מודלים (model registry) לא פורסים «על מקום ריק»: קודם צריך להבין מה כבר עובד בפרודקשן ומה בכלל קיים בתוך הצוות. להלן — המסלול ההנדסי ממיפוי ועד מסירה, שדרכו עוברת ההטמעה.

1. ביקורת מודלים. אוספים רשימה: אילו מודלים משרתים את המוצר, מי הבעלים, מאיזה ארטיפקט מתבצעת הפריסה. בנפרד מסמנים כפילויות ו«יתומים» — את גורלם מחליטים לפני הגדרת הרישום.
2. סכמת רישום. מגדירים היררכיה «פרויקט → מודל → גרסה → שלב», כללי שמות ומטא-נתונים חובה: נתוני אימון, מדדים, יוצר. מזה תלויה יכולת השחזור והיכולת לבצע רולבק.
3. הגדרת הרשאות. מפרידים תפקידים לפי פעולות: פרסום גרסה, העברה לפרודקשן, קריאה בלבד. מקשרים את הרישום לסביבת הפריסה, כדי שפרודקשן לא ימשוך מודל מענף ניסויי.
4. סביבת בדיקות. מריצים תרחיש מקצה לקצה על עותק: פרסום, מעבר בין שלבים, רולבק לגרסה קודמת. בודקים שההרשאות באמת חוסמות את מה שצריך, ושהמדדים ניתנים לשחזור.
5. העברת ידע. מעבירים גרסאות פעילות עם היסטוריה ומתעדים מה נשאר מחוץ לרישום. מוסרים לצוות תקנון פרסום, הוראות לפעולות שגרתיות ונוהל לחקירת אירועים.

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

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

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

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

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

מה היה לפני

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

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

מה שינו

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

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

מה נהיה

אחרי רבעון תחת ניהול הרישום — 100% מהמודלים, זמן הפצת גרסה התקצר מ-4 שעות ל-40 דקות, רולבק — מ-3–4 שעות ל-8 דקות, בשעות היום וללא עצירת השירות. אירועים חוזרים מסוג «מודל מיושן חזר לפרודקשן» פסקו. המיפוי כעת אורך דקות: רשימת גרסאות, שלבים ובעלים נשלפת מהרישום בשאילתה אחת.

במה שונה רישום מודלים מאחסון ארטיפקטים?

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

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

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

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

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

ספקות טכניים: מפרקים שאלות נפוצות

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

איך להפריד גישה בין צוותים וסביבות?

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

מודלים בירושה בלי מטא-נתונים יצטרכו להיבנות מחדש?

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

כמה מקום יתפסו כל גרסאות המודלים?

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

נדון במשימה ונחזור עם הערכה ותוכנית עבודה

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

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

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