אימון מודלים של ML ללא העברת נתונים: הטמעת Federated Learning

Federated learning: היכן נשבר המודל על נתונים מפוזרים

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

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

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

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

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

מה נותן אימון מודל בלי ייצוא נתונים החוצה

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

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

המודל לומד על כל המצרף מבלי לאסוף אותו במקום אחד

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

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

פחות שטח דליפה ופחות אישורים משפטיים

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

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

Federated learning: מצבי החלפת עדכוני מודל

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

החלפה סינכרונית ואסינכרונית

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

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

איגוד על שרת ייעודי או בלעדיו

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

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

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

שלבי הטמעת מתחם פדרטיבי

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

ביקורת ומיפוי מלאי של מתחמים

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

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

פיילוט על שני משתתפים לפני הרחבה

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

סכימות, מדיניות גישה ותקנות בפלט

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

מדיניות גישה ותפקידי משתתפים

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

תקנון חיבור מתחם חדש

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

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

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

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

מדדים לפני ואחרי

מה השתנה בתפעול

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

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

במה מתחם פדרטיבי שונה מאיסוף ריכוזי?

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

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

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

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

שאלות נפוצות: פרטיות, איכות המודל, כשלים

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

מה יקרה אם משתתף ינסה להרעיל את המודל?

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

איך משתתף יוצא מהמתחם וחוזר בחזרה?

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

למי שייכת המודל המאומן ואיך מחלקים את התרומה?

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

נדון במשימה שלכם: מתחם, נתונים, אילוצים

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

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

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