פרק מספר 510 של רברס עם פלטפורמה, שהוקלט ב-6 בינואר 2026. אורי ורן מקליטים בכרכור ומארחים את טל (מאזין ותיק!) מחברת Rhino Federated Computing לשיחה על עולם של חישוב מבוזר, פרטיות רפואית, הצפנות הומומורפיות ונוסטלגיה ל-SETI@home (ולא AI! טוב, גם…). 🎗️
לפני הכל - טל הוא מאזין ותיק, אי שם מאזור פרק 300 [מה קורה באמת עם התחזית של נתי על המוצר הצעיר והחדשני Apache Spark?] שהחליט להרים את הכפפה בעקבות הקריאה בכנס האחרון לרעיונות לראיונות. תהיו טל!
[01:28] טל, Rhino, ומה זה Federated Computing / Learning
- טל טיאנו-עינת - מתכנת, בוגר 8200, 20 שנה בתעשייה.
- בעבר CTO ו-Co-Founder, פעמיים עובד מוקדם או בין הראשונים בסטארטאפים, 8 שנים בטכנולוגיה חינוכית.
- ו-Python Core Developer, ספציפית של CPython [כבוד!]
- היום מוביל את תחום ה-Backend ב-Rhino Federated Computing.
- ו-Rhino Federated Computing עוסקת בגדול ב“חישוב מבוזר ומשמר פרטיות”.
- תכל’ס - מאפשר לעבוד עם כל המידע וכל ה-Data הרב מאוד שקיים היום בעולם.
- יש המון Data - אבל זה מידע רגיש (רפואי, פיננסי) שצריך להישאר “נעול בכספות”.
- ועדיין - רוצים להפיק ממנו תובנות.
- הפוטנציאל משיתוף מידע כזה הוא עצום, וצריך לדעת לעשות את זה בזהירות.
- בגדול, העולם מלא ב-Data (שליש מהמידע הדיגיטלי הוא רפואי), אבל הוא יושב ב-Silos: אי אפשר להוציא אותו בגלל רגולציה ופרטיות, ולא עושים איתו כמעט שום דבר.
- "אם תשאל חוקרים, כמעט כולם יגידו: 'האתגר הכי גדול שלי זה להגיע ל-Data. הוא יושב שם, אבל לא עושים איתו כלום."
- הפתרון של Rhino Federated Computing זו פלטפורמה, שמאפשרת להשאיר את ה-Data “במקום הטבעי שלו” (ב-Edge), ולשלוח את הקוד/המודל למחשב מקומי שירוץ עליו ויחזיר רק תוצאות נגזרות - אגרגטיביות (Aggregated) או משקולות (Weights) - שלא חושפות יותר מדי.
- באופן כללי, Federated Learning (או Federated Computing) מדבר על אוסף של שיטות, טכניקות ואלגוריתמים, שעוזרים להשתמש במידע הזה - אבל לעשות את זה באופן שמשמר פרטיות.
[04:32] אז איך עובד הקסם הזה, מהם ה-Use Cases ומי מנהל את גן החיות?
- זה בדרך כלל תהליך איטרטיבי (Iterative) - מתחילים מנקודת התחלה משותפת של המשקולות ושולחים לכל מיני אתרים שיש בהם את ה-Data.
- בכל אתר עושים אימון מקומי נפרד - ואז שולחים עדכונים למשקולות (מכל אתר).
- עושים אגרגציה (Aggregation) של הנתונים המעודכנים - ושוב.
- רן (בתפקיד הפרקליט השטן): למה לסבך? למה לא לעשות אנונימיזציה (למחוק ת.ז ושם), לשלוח הכל לשרת מרכזי אחד ולאמן שם? נשמע הרבה יותר פשוט . . .
- טל ציין כמה סיבות -
- רגולציה: מקשה מאוד . . . . לפעמים החוק פשוט אוסר את זה.
- בירוקרטיה: צריך לחתום על חוזים להוצאת Data מבית החולים, וזה יכול לקחת חודשים ואפילו שנים (להגדיר למי ספציפית מותר לגעת במה וכו’).
- וגם אז - זה יהיה עבור פרויקט אחד ספציפי . . .
- פרטיות: אנונימיזציה זה לא מספיק - הצלבת מידע (Re-identification) היא קלה מדי היום.
- מקרה לדוגמא - נניח למשל חוקר באיזשהו מוסד רפואי, שלא מעוניין להקים לבד את כל התשתיות האלה (בשום מקרה, וגם לא במקרה הזה…) - וצריך איזשהו Orchestrator שיעבוד עם 5 (או 500) בתי חולים אחרים. מה נוסע לאן? אילו אבטחות (והבטחות) פרטיות יכול אותו חוקר לקבל? “מי מנהל את כל גן החיות הזה?”
- השאלה היא האם אתה עובד עם Rhino או לא . . .
- בדרך כלל מתחילים עם כל מיני כלי Open Source ועושים כל מיני חישובים
- מגלים כמה זה קשה - ואז מגיעים ל-Rhino . . .
- ואז נשאלת השאלה - מי מחבר את כל האחרים? איך כל הקהילה נוצרת?
- לאורי כל זה נשמע כמו “מסיבת מנמ”רים” . . . . צריך להגיע לכל CISO ולכל מנהל מערכות מידע של כל מוסד ולשכנע אותו (ואז לעבור את כל הבדיקות…).
- טל אמר שההתקנה של ה-Client היא מאוד קלה (“תוך שעה” במקרה מסוים, לעומת “כמה שבועות” אצל מתחרים אחרים).
[10:28] אילו חישובים ניתן לעשות? אילו מודלים? מה האלגורתמיקה שרצה?
- אילו סוגי מודלים הלקוחות בדר”כ רוצים לחשב?
- כמעט כולם עושים Deep Learning ו-LLM-ים, מכל מיני סוגים וגדלים.
- עושים Fine Tuning מכל מיני סוגים.
- רואים גם כאלה שרוצים מודלים “קלאסים” - רגרסיות מסוגים שונים, מודלי-הישרדות למיניהם (בהקשרים רפואיים).
- מה שיפה זה שבמסגרת של Federated Learning אפשר לאמן את כל הסוגים הללו של המודלים.
- למשל גם Boosted Trees מסוגים שונים, יש תמיכה מאוד רחבה.
- וגם אלגוריתמים שהם בכלל לא אימון של מודל - כל מיני אלגוריתמים סטטיסטיים (חלק קיימים וחלק כאלו שהחברה בונה עבור הלקוח).
- אפילו חישוב של חציון בצורה שהיא מבוזרת ומשמרת-פרטיות זה גם אתגר מורכב.
- מדובר ב”אולר שוויצרי”, שמחשב גם חציון וגם Deep Learning, למשל - או שיש כאן כלים שונים?
- יש פה בעצם שני Framework-ים עיקריים שנתמכים עבור Federated Learning - הראשון הוא NVFlare של NVIDIA ו-Flower של Flower Labs [יש שת”פ…].
- אפשר גם לממש בהם אלגוריתמים סטטיסטיים - אבל זה פחות נפוץ, יותר מורכב.
- הטכנולוגיה: הכל רץ על Containers. המשתמש שולח Image, הוא רץ מבודד (בלי גישה לרשת או ל-FS, רק ל-Data הספציפי), והתוצאה נשמרת מקומית או נשלחת חזרה (תלוי בפרוטוקול).
- (אורי) - כל קוד יכול לעבוד “פדרציה” על ידיכם (Rhino) - או שמי שכותב את הקוד צריך לחשוב מראש שהוא הולך “לרוץ Federated” ואז צריך לכתוב את הקוד בצורה אחרת? (רן) אפשר להריץ PyTorch as is, או שצריך התאמות כדי שירוצו “Federated”?
- במרבית המקרים זה משהו שבין Out-of-the-Box לבין “פשוט מאוד” - המפתחים של ה-Framework-ים “כבר סללו את הדרכים” עבור המודלים הנפוצים (כמו PyTorch או TensorFlow), ואז זה רק “להוסיף כמה שורות”.
- איך למצוא את ה-Data ולכתוב את המידע שיוצא (למשל משקולות) למקומות הנכונים.
- רגע, יש פה Double-Latency? אתרים נפרדים, מרחק פיזי, ענייני Orchestration מיבשת אחרת . . . בד”כ, לאמן מודלי Deep Learning זה משהו שדורש הרבה Data והרבה Iterations - אין פה צוואר-בקבוק (לפחות אחד או יותר)?
- בהחלט יכול להיות - ומעניין לראות אילו Trade-offs אפשר לעשות.
- יש הרבה פרמטרים שאפשר לשלוט בהם - כמה מידע משתפים? מה אורך האיטרציות? כל כמה זמן עושים עדכון מחדש ו”יישור קו” בין האתרים השונים (לכל פעם יש מחיר).
- ועדיין - טל אומר ש”לא מצאנו מקרה שזה היה כל כך איטי כך שאי אפשר היה להשיג את מה שרצו”.
- האם יש איזשהו Sandbox, שעליו אפשר להריץ את האיטרציות המהירות (יחסית) על “משהו לוקאלי” - ואחרי שבטוחים (נגיד ב-80%) שזה מה שאנחנו רוצים, רק אז לקחת את הכל ל-Federated, כדי לחסוך (זמן וכו’)?
- כן. ב-Rhino בנו כלי למפתחים, כך שיוכלו לעבוד ממש מקומית (Containerization) ולוודא שכל ההתאמות אכן עובדות.
- גם בשלב הבא, כשכבר מעלים ומריצים על גבי הפלטפורמה - יש פיצ’ר שמאפשר להריץ את זה ממש Federated, אבל שכל ה-Clients רצים באתר אחד.
- אפשר להרים מכונה חזקה עם כמה GPUs ולהריץ, כשכל ה-Flow וכל התקשורת מדמים מצב אמיתי - אבל בפועל זה רק באתר אחד או שניים.
- עם איזה מידע שהמשתמש רוצה - דמה או אמיתי.
[18:30] המקרה המוזר של החולה האנונימי בקיבוץ
(רן) נניח לדוגמא בית לחולים אחד עם 500 פציינטים, בית חולים שני עם 1000 - ושלישי עם 10 בלבד. כולם רוצים לחקור יחד, אבל לחלקם יש ממש מעט משתמשים (נתונים). האם יש כאן בעיית אנונימיזציה של “קיבוץ קטן”? כולם מכירים את כולם, ואם מישהו מחפש, יכול להיות שמאוד קל לזהות חולה ספציפי?
איך עדיין אפשר להשתמש במידע “קטן” יותר?
- חוסר-איזון בכמויות ה-Data זה תרחיש נפוץ יחסית, ויש אמצעים שונים שניתן להפעיל כדי לשמר פרטיות, בהתאם לסוג החישוב.
- שימוש ב-K-anonymization: מוודאים שתשובה לא מתבססת על מעט מדי פרטים, ולא מחזירים תשובה אם הקבוצה קטנה מדי (למשל, פחות מ-10 אנשים).
- "מי הם כל הגברים בני 30-40 ממוצא ספרדי שחלו בשפעת השנה? אם יש פחות מ-10, אל תחזיר תשובה”
- אפשר לקנפג (Configure) את זה פר-פרויקט.
- השותפים בפרויקט יכולים לתאם ביניהם ולהחליט להקטין או להגדיל את הקבוע שאיתו עובדים - זה פיצ’ר מאוד חשוב בפלטפורמה, שמאפשר לקבל החלטה, כל מקרה לגופו.
- (רן) מה לגבי “להמציא Data”? - טל אומר שזה משהו שקורה ויש חברות שמוסיפות מידע סינטטי.
- בעולמות ש-Rhino עובדת בהם ההעדפה היא למידע אמיתי.
- “הרעשה מכוונת” - Differential Privacy: הוספת "רעש" (Noise) אקראי מתמטי מכוון ל-Data או למשקולות, כדי למנוע הסקה על פריט בודד.
- לפי גישה ספציפית של “כמה רעש להוסיף?” - התפלגות וקבוע לעוצמת הרעש (ביחס למידע האמיתי עצמו), כדי להבטיח אינפורמציה על המידע המקורי.
- ה-”Differential” בשם מתייחס לכוונה למנוע התקפות שעלולת לחשוף מידע ספציפי מדי על הפריט ה-”N+1” במאגר (ע”י הצלבה של תת-קבוצות) - Re-Identification.
[25:21] ניקיונות במידע (וקוד) חסר
חלק לא קטן מהעבודה מגיע בכלל לפני האימון של המודל - ניקוי, מציאת חריגים . . . Data Cleansing. איך עושים את זה כשה-Data מפוצל בין המון גורמים?
- בשביל זה צריך פלטפורמה . . . . לפני כן, כל העבודה הזו הייתה מתבצעת בכל אתר בנפרד - לא יעיל, מסורבל, בכל פעם צריך לשלוח גרסא חדשה לכולם כדי שיריצו וישלחו בחזרה . . .
- כשזה On Platform”, יכול להיות מישהו אחד שעושה את החישוב - ואז הקוד שלו יכול לרוץ בכל האתרים השונים.
- אפשר לדבג (Debug) מרחוק, לקבל תוצאות והתפלגויות ולתקן במרוכז.
- אתגר נוסף הוא נורמליזציה בין האתרים השונים - צריך להביא את המידע לאותה “הצורה” - אותן יחידות וכו’
- נגיד - In 1999, NASA lost the $327 million Mars Climate Orbiter because Lockheed Martin used imperial units while NASA used metric, causing the spacecraft to crash into Mars due to a simple math error]
- בסוף, בניית ה-Data Pipeline והנרמול זה אחד השימושים הכי נפוצים של הפלטפורמה.
- הקוד (ולא התוצאה) נשלח בצורה של Container Image - רץ באתר מרוחק, וכמה במקביל.
- רץ Isolated, ללא גישה למערכת הקבצים, לרשת, למערכת ההפעלה וכו’.
- רק מקבל גישה לאותו Data ספציפי שנבחר, יכול לכתוב את התוצאות רק למקום מאוד מסויים - והתוצאה נשמרת כ-Data Set חדש באותו מקום שהוא רץ, ונשארת שם (לא נשלחת לשום מקום).
- אלא אם זה חישוב מבוזר - אז , ניתן לקבל למשל חישוב של ממוצע, תחת הגבלות של Anonymization ו-Privacy.
- ו-Rhino הוא זה שדואג להעביר את ה-Container, לוודא שהוא רץ במקום מבודד, מעביר רק את מה שמותר ולא את מה שאסור.
- במקרה של אימון מודל, כן יש Networking מוגבל בכל אתר, כדי שיוכלו להתחבר.
- יש Orchestrator של ה-Federated Learning, שרץ לרוב אצל Rhino בענן - כולם מתחברים אליו, ואז יש תהליך איטרטיבי (Iterative) שבו כל אחד מה-Clients מחליף מידע עם ה-Orchestrator.
- בתהליך הזה נשלחים המשקולות - וזה חלק מאותו Training Algorithm: מה נשלח ואיזה Differential Privacy מופעילים.
- בסוף, המשקולות נשמרים או בענן של Rhino, או באחד מהאתרים שהשתתף בתהליך - בהתאם להגדרות של המשתמש הספציפי.
מבחינה טכנולוגית, אפשר לכתוב באיזה Stack שרוצים (כל עוד זה נכנס בתוך Container), או שגם פה יש פרוטוקולים ספציפיים?
- אז לא רק Python . . . הרבה משתמשים ב-R.
- כן צריך להתחשב בצריכה של CPU ושל RAM - ואם רוצים לעבוד עם GPU אז זה גם משהו שצריך לוודא ולהגדיר שיהיה זמין בכל אחד מהאתרים.
- אבל בגדול - כן: כל עוד זה רץ בתוך Container, זה בסדר.
[30:20] ענייני Trust
- במידה מסויימת - יש הרבה מודלים של “עד כמה סומכים ועל מי”.
- לקוחות יכולים להצפין את הקוד ו/או את המשקולות שלהם - ואז ל-Rhino אין גישה.
- יש תמיכה שליפה של המפתחות רק מתוך Vault ורק בזמן ריצה, באמצעות Token שהלקוח מספק בצורה מאובטחת.
- יש שיטות כמו Homomorphic Encryption - ואז גם ה-Orchestrator שעושה את האגרגציה (Aggregation) לא רואה אתהמשקולות עצמם (שהוא עושה להם את האגרגציה…)
- מדובר בהצפנה ששני הצדדים עושים - ואף אחד מהם לא יכול לקרוא את התוצאה אם אין לו את המפתח של הצד השני.
- מה שמייחד את ה-Homomorphic Encryption זה שכל אחד מהצדדים, על אף שהוא עובד עם מידע מוצפן, עדיין יכול לבצע עליו חישובים (לרוב מאוד פשוטים - חיבור/חיסור, אולי כפל) - ולהחזיר לצד השני, שיכול לפענח ולקבל את התוצאות של הפעולות.
- מדובר באוסף של אלגוריתמים מאוד מעניינים מתימטית [להרחבה - נגיד כאן: #47 Fully Homomorphic Encryption | Part 1 | Quantum Algorithms & Cryptography - YouTube]
[32:08] זכרונות מקצה הגלקסיה / SETI@Home
אורי מזכיר שבתחילת שנות ה-2000 היה פרויקט בשם SETI@Home, שבו אנשים תרמו כוח מחשוב לחיפוש חייזרים [Search for Extraterrestrial Intelligence].
- גם היום עושים את זה - פשוט ל-Bitcoin . . . [הי - ?But how does bitcoin actually work]
- ההבדל: טל מדייק – שם זה היה חישוב מקבילי: החלק של ה-Distributed - כל אחד מחשב משהו נפרד, ואין קשר בין החישובים שמתבצעים באתרים השונים.
- ב-Federated Learning יש אגרגציה ושיתוף מידע בין הצמתים והמשקולות מהאתרים השונים, כדי לשפר מודל משותף.
- אז יש חיזרים או אין? [?Where is everyone]
- ואגב פיצול וענייני Trust - : רן שואל אם יש מערכות שהן ממש Zero Trust, ולא צריך לסמוך על אף אחד (כולם Peers, כמו Bitcoin, ואין Orchestrator)?
- טל מודה שבעולם ה-Federated Learning כרגע תמיד צריך לסמוך על מישהו (לפחות חלקית), ואין עדיין פתרון קסם של Zero Trust מלא.
- זה יותר “משחקים של על מי אני סומך ומתי”.
[34:25] גיוסים וסיום
- אז Rhino היא סטרטאפ בן 5; החברה גייסה לאחרונה 15 מיליון דולר (Round A).
- מה מחפשים? מפתחי Backend מנוסים, Frontend, DevOps ו-Product.
- ה-R&D יושב בארץ - בשרונה, תל אביב (הנהלה בבוסטון), 3 ימים בשבוע במשרד.
- מחפשים אנשים מנוסים שיודעים להתמודד עם Backend מורכב ולא קונבנציונלי - ומספיק ניסיון ב-Python (כי זה ה-Backend).
תודה רבה, ובהצלחה.
האזנה נעימה ותודה רבה לעופר פורר על התמלול!
