הגדרת מאגר מאפיינים (Feast, Tecton) לניהול מאפיינים

Feature Store: מדוע מאפיינים נבדלים בין אימון לפרודקשן

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

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

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

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

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

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

מה נותנת שכבה אחודה של מאפיינים בפיתוח מודלים

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

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

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

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

Feature Store: השוואת אפשרויות מימוש

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

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

אפשרויות והמגבלות שלהן

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

איך אנחנו מטמיעים את שכבת המאפיינים: שלבי העבודה

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

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

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

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

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

מקרה בוחן: איך הסרנו את הפער במאפיינים בין הסביבות

איך זה היה

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

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

מה שינו

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

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

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

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

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

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

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

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

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

שאלות טכניות נפוצות על שכבת המאפיינים

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

מה לעשות עם נתונים היסטוריים מתקופות קודמות?

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

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

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

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

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

בואו נדון במשימה: מה נדרש כדי להתחיל

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

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

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