רברס עם פלטפורמה

[קישור לקובץ mp3]פרק 484 (מספר יפה!) של רברס עם פלטפורמה, שהוקלט ב-20 בנובמבר 2024. אורי ורן מארחים באולפן בכרכור את שי ילין ואת רון קליין לשיחה על מגדלי שן (מבחינה ארכיטקטונית).
(רן) למעשה, גם שי וגם רון הם שניהם מפתחים / ארכיטקטים מאוד מאוד מנוסים, ובחודשים האחרונים יצא לנו פה ושם לחוג סביב הנושא הזה של איך “נכון” להנדס תוכנה בחברות צעירות ובחברות ותיקות יותר, איך נכון לבנות ארכיטקטורה בשלבים שונים של החיים של החברה - ופחות או יותר על זה אנחנו נדבר היום.ובעיקר נדבר על מהות התפקיד וההבדלים השונים בין תפקידי הארכיטקט במקומות השונים. אבל עוד לא הצגתם את עצמכם . . . [בפרקים הקודמים - 469 Software development in early stage startups with Shai Yallin478 with Haim Yadid, Software in young startups]
01:05 שי ורון
(רן) אז קודם כל - ספרו קצת על עצמכם. שי, בבקשה . . .(אורי) בפינה השמאלית, ארכיטקט הניצחון . . . .

• (שי) האמת שאני לא מגדיר את עצמי כארכיטקט . . . . אני שי, אני עצמאי בתחום הנדסת התוכנה.
• לפעמים אני מכנה את עצמי “Fractional Principal Engineer”, או “Principal as a Service”.
• אני מתעסק באיך מהנדסים תוכנה - איך בונים ארגונים ומערכות שקל לעשות להן שינויים, בכל מיני Level-ים של חברות.
• יש לי לקוחות שהם חברות ממש אחרי Seed או אפילו לפני Seed ויש לי חברות שהן כבר אחרי Round E
• וכל מיני דברים באמצע ביניהם.

(רן) וזו לא ההופעה הראשונה שלך פה בפודקאסט . . . . אז מוזמנים לבוא ולהקשיב לפרק הקודם עם שי, שאני כרגע לא זוכר את מספרו [469! הנה שוב - 469 Software development in early stage startups with Shai Yallin, יש שם גם הפניות להרצאות בכנסי רברסים לאורך השנים].רון!

• (רון) היי, Nice to be here, נתחיל מזה.

(רן) מאזין מפרק אחד!

• (רון) אכן! כשעוד היו קצת תקלות עם האודיו וה-Level של הווליום ודברים כאלה . . .

(אורי) השתפרנו מאז . . . 

• (רון) בתחום פיתוח התוכנה - אני לא יודע, 20 שנה + בקטע הזה של “לפרנסתי”
• עוד לפני זה גם היה תחביב.
• בעשר השנים האחרונות אני בתפקידי Tech Leadership ב-Scope-ים ופורמטים שונים.
• יצא לי גם להיות Tech Lead ו-Staff Engineer ובTitle-ים ב-Corporates סטייל ב-eBay וב-Semi-Garage Startups - וכל מיני In-Betweens יצא לי גם לעשות בעשור-פלוס האחרון.

(רן) וכיום אתה . . . .

• (רון) כיום אני ארכיטקט - “ארכיטקט הפלטפורמה”, אפרופו רברס עם פלטפורמה - בחברת Elementor.
• זו חברה שמייצרת הרבה מאוד כלים ל-Web Creators, שזה Title מאוד מגוון, Fluid-י כמעט כמו “ארכיטקט” . . . .
• ובגדול זה אומר שבעבר, כדי לבנות אתר אינטרנט, היינו ככה פונים לאיזה “איש מקצוע” - היום זה הרבה הרבה יותר מורכב.
• ו-Elementor נותנת מענה להרבה מאוד בעיות או Pain Points בכל ה-Life cycle של Websites
• מהתכנון עד ההרצה, Growth, Payments - כל הדברים האלה, Elementor נותנת להם מענה.

(רן) כלומר, רכיבים שאפשר להשתמש בהם בפלטפורמות שונות?

• (רון) לגמרי.

(רן) מעולה, אז Web זה כיף . . . .

• (רון) Web זה Fun-Fun-Fun, זה כן . . . .

03:55 “ארכיטקט”? !There's No Such Thing As A Gruffalo
(רן) אז סיפרתם לנו קצת לפני הקלטה, שבעצם הרעיון לפרק הזה התחיל מאיזושהי שיחה, שאתה ושי דיברתם - ואתה אמרת “אני ארכיטקט!” ושי אמר “אין דבר כזה!” . . .  פחות או יותר, אני קצת אולי מתמלל את זה אחרת.אז מה זה בעצם “ארכיטקט”? בוא נשפוך את זה, בוא נפתח את זה כבר עכשיו - מה בתפקיד? מה זה ארכיטקט?האם יש דבר כזה? האם צריך דבר כזה? (אורי) אני לא הייתי שואל מה בתפקיד - אני שואל מה בתפריט? . . . כי מהצד אחד, אתה יכול להגיד “אין דבר כזה?” ומצד שני, זה יכול להיות כל כך הרבה דברים. אז יאללה - המיקרופון שלכם.

• (רון) אז אני רוצה רגע לתת ככה מענה, תשובה.
• אני באמת חושב שזה פחות ה-Title ויותר באמת המהות או התפקיד עצמו, או תחומי האחריות.
• בעיניי, ארכיטקט - יש לו כמה כובעים.
• הוא, מבחינת ה-Leadership, זה כובע משמעותי - הוא צריך להיות “מגדלור” כזה, של מצוינות טכנית ו-Seniority טכנולוגי.
• בנוסף לזה, הייתי אומר שהוא גם אמור לא להיות “היחיד” - כלומר, הוא אמור להעלות את הרף, וליצור סביבו את ה-Next Generation של ארכיטקטים או Tech Leaders בארגון, ב-Scope-ים שונים.
• להיות ה . . .  נקרא לזה “בן אדם שאיתו מתייעצים” ויחד איתו מקבלים החלטות שיש להן משמעות מאוד גדולה Moving Forward.
• כלומר אי אפשר - או שיהיה מאוד קשה - To roll back, לקחת את הצעד הפוך ולשנות את ההחלטה.
• וזה בדרך כלל החלטות בתחום הטכני-טכנולוגי, פחות החלטות מוצריות Pre-se.

(רן) כלומר, אז דיברת על העניין של מצוינות - אבל בוא אני אתריס: האם צריך לעבור דרכך דרך כל Code Review, דרך כל Design Review? לקבל אישורים ו”סטמפה” כדי לשחרר פיצ'רים? 

• (שי) . . . . ”בשלושה עותקים!” . . . 

(רן) האם אתה ה-Gatekeeper?

• (רון) אז שאלה טובה . . . . ולדעתי, יש כאן, כאילו, כמו כל ארכיטקט אני אגיד “זה תלוי . . .. “.
• אני חושב שדבר ראשון, יש כאן פונקציה מאוד משמעותית של Seniority ו-Engineering Level בארגון.
• ואני חושב שהשאלה שאתה שואל, אם ירושה לי לנסח אותה בדרך אחרת, זה עד כמה הארגון מעוניין להיות ב-DNA שלו Centralized לעומת Decentralized.
• כלומר, כמה חופש או מה דרגת-החופש שאנחנו מעוניינים לתת לEngineering Teams או ל-Silo-ים השונים מצד אחד, לעומת . . .
• מצד אחד בסקלה זה “אוטונומיה מוחלטת” - כל אחד שיחליט על הכלים הטכניים שלו וכו’.
• ומצד שני, יש לך את מה שכרגע התרסת - הכל עובר ומתנקז דרך איזושהי פונקציה אחת בארגון - “הארכיטקט!”
• ועל פיו ישק דבר, ומה שהוא מאשר הוא מאשר, ומה שלא - לא.
• אני לא חושב שזה . . .  לא חושב שיש כאן תשובה אחת נחרצת.
• אני חושב שזה מאוד מאוד מבטא את ה-DNA הארגוני, בכללי.

(רן) כן, בסדר. יצא לך, דרך אגב, לעבוד במקום שבו באמת היה ה-DNA כזה ריכוזי, ואתה או אולי מישהו אחר היה בתפקיד הארכיטקט והיה ה-Gatekeeper של כל הפיצ'רים?

• (רון) כש . . . בלי להגיד שמות, במקום שבו ה-Engineering Level היה יחסית נקרא לזה “פחות מהממוצע”, היה לי סוג של Carte blanche 
• קיבלתי גיבוי מוחלט - “רון, קח אותנו קדימה, קח אותנו ל-Next Level!”.
• ובאמת לא הייתה ברירה - עשינו הרבה הכשרות פנימיות, כדי לייצר איזשהו Baseline, שמשם ואילך כבר היה יותר קל לתת לכל צוות לנוע בקצב שלו, לתת את האוטונומיה.
• אבל בהתחלה, זה היה שלב כזה של “אוקיי, הרבה מאוד דברים עוברים דרכי”
• הרבה מאוד דברים - נקרא לזה “כל מיני Design Reviews” - עוברים דרכי וכו’.

08:30 עניין של מורכבות
(רן) אוקיי, אז דיברנו על העניין הזה של מצוינות ואולי, ככה, “להראות את הדרך” וכל זה.אבל לפעמים גם יש כל מיני משימות שהן “מורכבות” - Debugging מורכב, אולי תכנון של מערכת חדשה, אולי אינטגרציה בין הרבה מערכות אחרות של אותה חברה, אולי יש גם מורכבות-עסקית . . .  זה יכול להיותכל מיני דברים.(אורי) לפעמים יש גם . . . אתה נגעת ב-Debugging, אבל יש “בעיות שרק הארכיטקט יכול לפתור”. כאילו, משהו באיזה Monolith כזה, ש”להכניס את היד ואתה לא יודע איזה נחש ינשך אותך” . . . .

• (רון)  . . . . או שמה שאתה מוציא הוא . . . אתה חושב שזה מתחיל באיזה “צ'ופצ'יק קטן”, ולאט לאט אתה מגלה כמה זה מתחבר לעוד סבך מאוד גדול של דברים.
• (שי) אני חושב שאם יורשה לי, יש פה נקודה מאוד מעניינת . . . שבעצם, ה-Role או הצורך הארגוני הוא לא בהכרח ב-Gate-Keeping.
• אני חושב שGate-Keeping זה “שריר” שצריך להיול מסוגלים להפעיל בנקודות מסוימות, ברגעים מסוימים.
• כמו שרון אמר - זה לא דיכוטומי.
• אבל יותר מזה - אני חושב שהארכיטקט זה Variant אחד של איזשהו קונספט יותר רחב, יותר גדול, שבתוכו ישבים גם דברים כמו Principal Engineer או Fellows, כל “הגווארדיה היותר בשלה ומנוסה” שיש בארגון.
• כי באמת, יש מקומות שזה יכול להיות או “ה-Monolith הישן”, או שהמערכת כל כך גדולה, שקשה, כאילו, To Grok the entire thing.
• קשה להכניס את כל המערכת לראש של בן אדם אחד, ואז יש צורך שיהיה בארגון אדם אחד - או כמות של אנשים - שהם אלה שרואים את המערכת “ממעוף הציפור”.
• אבל - שגם יכולה להיות להם יכולת לעשות Zoom-In או Drill-Down איפה שצריך, כדי להיות מסוגלים לדבר גם בשפה שהיא High Level וגם בשפה שהיא Low Level.
• גם בשפה שהיא כללית - כל המערכת - וגם בשפה של Silo ספציפי, Pod ספציפי, מוצר או קו-מוצרים ספציפי.

10:52 רגע, מה ההבדל?
(רן) אז מה, הזכרת “Principal” וכו’ ו-Title-ים אחרים,  ולא יודע אם כולם או כל מי שמקשיב לפודקאסט בהכרח מכיר. זה משהו שמקובל בחברות יותר גדולות, שיש בהן Level-ים שונים ל-ICs. אבל נשאלת השאלה, ככה בגדול - אז מה ההבדל בין Principal או Distinguished או Fellow Engineer כלשהו לבין ארכיטקט? האם יש הבדל ואם כן - מהו או מה הוא צריך להיות, לדעתכם?

• (רון) אני אקח את זה רגע מהצד שלי - אני חושב שזה Title-ים שונים שמייצרים סולם של Tech Leadership, של IC טכני, פשוט עם Scope - עם היקף-פעילות או “Level של מעוף ציפור” יותר ויותר גבוה.
• אני חושב שנדרש מתפקידים “נמוכים” יותר להיות הרבה יותר פעילים ב  . . .  נקרא לזה ב”Component Level” או ברמת ה-Design הפנימי של תת-מערכת כזו או אחרת.
• ככל שעולים בסולם הדרגות של ה-IC, הכוונה היא להוביל - להיות ה-Focal Point הטכני או הארכיטקטוני, אם נרצה.
• במערכת שהיא כבר יותר Cross-Teams או Cross-Siloes או Whatever.
• וככל שעולים למעלה; יש כנראה גם יותר ויותר מקום לחזון או לכיוון ההתקדמות הטכני-טכנולוגי של הארגון
• הנושא הזה של “האם צריך להחליף שפה?” או, לא יודע - “האם אנחנו רוצים להמשיך להשתמש בכלי הטכנולוגי הזה או אנחנו רוצים לבחון אלטרנטיבות אחרות?”
• וככל שהארגון גדול יותר - ושוב, זה מאוד מאוד פונקציה של גודל הארגון, ה-Dev.
• ככל שהארגון גדול יותר, ככה יש לדרגות הגבוהות יותר יותר מקום.
• ויכול להיות שבארגונים קטנים - זה . . . אפרופו, יכול להיות שבארגונים קטנים, נגיד פחות ממאה מפתחים - אולי לא חייבים שם ארכיטקט או משהו כזה.
• זה יכול להיות באמת איזה משהו שהוא מקביל ל-Principal או משהו דומה, זה לא חייב להיות אחד.
• והם עושים עבודה מצוינת.

(רן) כמה אתם אצלכם בארגון, בפיתוח?

• (רון) ב-Elementor מעל מאה איש בפיתוח, World-wide.

(רן) אוקיי, יש גם CTO?

• (רון) יש, יש . . . 

(רן) ואיך החלוקה ביניכם, בינך ובינו?

• (רון) הוא באמת נמצא במקום . . . הוא CTO שהוא גם Co-Founder, והוא נמצא במקום הרבה יותר של “לנווט

את הספינה הגדולה הזאת קדימה”, דברים הרבה יותר Visionary מאשר הקונקרטיזציה שאני אמון עליה.
13:52 ארכיטקט זה המטבע-קריפטו החדש (ישן)?
(אורי) אני רוצה להגיד משהו, קצת, לא יודע - “דרסטי” פה: זה מטבע, הדבר הזה שנקרא “ארכיטקט”. זה בעיקר “חי ב-LinkedIn”. זה סוג של Crypto שחי . . . .(רן) . . . היום Crypto הולך טוב . . . (אורי) . . . כן, ה-Bitcoin . . .  “עלה דווקא שער הארכיטקט” . . .  אבל זה סוג של “מטבע וירטואלי”. בכל חברה זה אומר משהו אחר לגמרי, כמו גם ה-Principal וה-Fellow, זה בכל . . ..  זה משהו שאתה יכול לשים ב-LinkedIn שלך, זה לא אומר שום דבר על התפקיד שלך בחברה.בהרבה מקרים משלמים לך במטבע הזה, “סוג של קידום”, אוקיי? זה לא אומר כלום, נגיד, על השכר שלך.ואני יכול להגיד שהרבה פעמים, בשלב מסוים מצאנו את עצמנו שזה מה שאנחנו עושים. אם מישהו לא מתקדם כי אין לו שום סולם קידום בחברה כ-IC - “תיהיה ארכיטקט!”. הוא יכול לכתוב את זה ב-LinkedIn, הכל בסדר.בהרבה חברות, הסולם-קידום היחיד שבעצם יש להן זה בעצם רק בציר ניהולי, אז  ב-IC אומרים “קח את הארכיטקט ותעזוב אותנו בשקט” . . . . הדבר הבאמת נכון לדעתי לעשות, וזה כבר לא משנה אם אתה שם שמות לדברים האלה או שם מספרים של Level-ים, זה פשוט להגדיר בצורה מאוד טובה מה אומר כל Level, מה ה-Expectations שלך מה-Level הזה.עושים את זה כמובן ארגונים גדולים יותר - כשהם מתפנים, לדעתי, לעשות את זה - אבל זה עושה המון סדר בקריירה של ICs.(רן) אורי, אתה זוכר באיזה שלב אתם עשיתם? כמה הייתם אז בארגון לפיתוח כש...(אורי) מאוחר  . . .(רן) כמה? - מאות?(אורי) כמה מאות.(רן) מאות אנשים. . . ואצלכם, רון, יש כבר Leveling כזה?

• (רון) יש “התהוות” של הגדרת התפקיד שנקראת Tech Lead.
• בחברות קודמות שעבדתי בהן, זה היה הרבה יותר מסודר.
• הן כבר עברו את שלב ה-Incubation של הגדרות התפקיד, של ה-Level-ים.
• ואני חושב ש . . . אני כאילו קצת נותן לך פינג-פונג מהכיוון ההפוך - אין לך איזושהי “רגולציה” שאומרת רוחבית “Principal זה ככה!”
•  בכל חברה Principal מוגדר X, או Staff Engineer מוגדר ככה, או Tech Lead, או Whatever.

(אורי) מהבחינה הזאת, אמרנו בגדול לאנשים - “שימו מה שאתם רוצים ב-LinkedIn - מבחינתי אתה Level 6”.

• (רון) אוקיי, אבל מה שאתה אומר - ואני מאוד מסכים - זה שיש הגדרה . . .

(אורי) “מבחינתי אתה Level 6 - וזו ההגדרה של ה-Expectations שלי מה-Level”.

• (רון) אבל למה אנחנו . . .  אוקיי, למה ה-Title חשוב כאן? אני יכול להגדיר את עצמי כ”שרברב תוכנה”. אני פותח סתימות . . .

(אורי) אגב - זה מה שאתה עושה, כן? אבל... כאילו, כולנו בעולם התוכנה . . . 

• (רון) לא המצאתי את זה, אני כבר ראיתי את זה.

(רן) אנחנו קודם מחביאים אותן טוב-טוב, את הסתימות . . . שמים את החומר - ואז פותחים!

• (רון) כן, בדיוק. אבל מה זה משנה ה-Title?

(אורי) אז בגלל זה אני אומר - זה לא כל כך משנה. מה שמשנה זה . . . אני רק יכול להגיד, נגיד ספציפית לארכיטקט, שאמנם היה את הסיפור שאני מספר בסוף, הוא עניין של “כאילו Title”, אבל בנקודה מסוימת, אנחנו רצינו להתחיל גילדות . . . . [הנה, כאן - 367 Guilds at Outbrain]

• (רון) או, הנה - שי נדלק . . . 

(אורי) כן, כן . . . ובעצם אמרנו שאנחנו מחפשים מישהו שיוביל את הדבר הזה שנקרא “גילדות”. היינו . . .  בשלב הזה, עזב ארכיטקט שהיה לנו - ולא חיפשנו ארכיטקט, אבל חיפשנו מישהו שיוביל גילדה. וספציפית, אותו בן אדם שרצינו שהוא יוביל את הגילדה אמר לנו “סבבה - אבל אני גם רוצה להיות ארכיטקט”.תכל’ס אמרנו לו “סבבה” - והרווחנו את שניהם באמת ביחד.וזה יצא מאוד מאוד טוב שמי שנגיד “קובע את הסטנדרטים” של הארכיטקטורה ושל איך שהקומפונננטות (Components) מדברות אחד עם השני ובאיזה פרוטוקולים - הוא גם זה שמצד אחד דואג שהתשתית תיבנה לזה, ומצד שני גם מלמד את האנשים איך זה עובד ואיך צריך לעבוד - והגילדה היא בעצם “הזרוע החינוכית” של הארכיטקט. וזה יצא פגז.
19:45 ה-Title וחותם המלך

• (שי) זה מהמם, זה מהמם . . . אני רוצה להתייחס רגע לסיפור של Title. Title, זה בעיניי זה לא-“לא חשוב”. מכמה סיבות.
• הראשונה היא שאוקיי - אנחנו יודעים שה-Title הוא Meaningless וגם ה-Founder-ים יודעים שה-Title הוא Meaningless.
• אבל כל מיני מנהלי-ביניים, שלא בהכרח מכירים אותי, ואני בא ואני אומר להם “חבר'ה תקשיבו - הרעיון שלכם למוצר, הוא יכול לעבוד ככה ב-Micro, בתוך המוצר הניסיוני הזה שאתם עכשיו מריצים ב-Pod שלכם”
• “אבל אתם חייבים לחשוב גם על שאר הארגון” - על איך “האדוות” שאתם יוצרים ישפיעו ויפגעו במוצרים אחרים, ב-Pod-ים אחרים.
• ואם זה מגיע מתוך IC שאין לו Title - זה יכול להיתפש אחרת, מאשר אם זה מגיע מתוך IC שיש לו Title שנשמע יותר “מפוצץ”.
• אני לא אוהב את זה, זה לא כאילו . . .  זה לא “כיף לי” שזה המצב - אבל בהרבה מקומות, זה המצב.
• אז כדי שיקחו אותך ברצינות, כדמות שיש לה “השפעה בלי סמכות”, לפעמים כן צריך לתת - לא בהכרח סמכות ניהולית “עם שיניים”, אבל כן איזשהו Title-ון כזה או משהו.
• שעוזר לאנשים שעדיין לא מבינים בדיוק מי אתה בתוך הארגון - אולי כי הם חדשים, אולי כי לא אכפת להם . . .

(אורי) או שהארגון הוא מאוד גדול - והקשרים שאתה צריך לייצר או ה-Interface-ים שאתה צריך לייצר, הם מעבר לרמת ההיכרות האישית. כי אני מכיר את רון, אני יודע שהוא “אייס”, בסדר? ושיש לו פה . . . “הוא כתב חצי מהמערכת”. אז כאילו, ברגע שהארגון גדול מעבר לזה - יכול להיות שאתה צריך לבוא גם עם איזשהו Title. אני לא יודע, אתה [רן] עבדת ב-Google - זה היה שם ככה?(רן) קודם כל, ה-Google שבה עבדתי וה-Google של היום הן כנראה מאוד מאוד שונות . . .(אורי) לא, אבל גם ה-Google שבה עבדת הייתה כבר גדולה, עם Interface-ים . . .(רן) הבת שלי, שנולדה כשהייתי שם - היום היא בת 16 . . . אז עבר הרבה זמן. אבל כן, ללא ספק - כמעט בכל חברה גדולה, במיוחד שזה ככה, “Across the Ocean” ובאנגלית וכל זה, כן, יש - הTitle עוזר. זאת אומרת, תמיד יש אנומליות, אבל זה לגמרי יכול לעזור. זה קצת מזכיר לי שבימי-הביניים היית מסתובב עם “החותמת של המלך” - אף אחד לא היה מכיר אותך, אבל אם היית מציג את החותמת של המלך, אז אוקיי, סבבה, “הבנו מי שמך”. אתה לא  בהכרח את הבן אדם הכי טוב, אתה לא בהכרח הכי חכם - אבל מישהו סומך עליך וזה המלך, וזה בסדר, אנחנו צריכים לעשות מה שתגיד,אבל אורי - הזכרת מקודם משהו מעניין: אמרת שאותו בן אדם, שהוא היה ארכיטקט טוב והבין את הטכנולוגיה מצוין, הוא גם ידע לארגן את האנשים, לארגן גילדות, שזה תפקיד לגמרי של הובלה, אבל אנושית. זאת אומרת, אולי יש פה גם צד טכנולוגי, אבל זה מישהו שצריך להלהיב את האנשים, להוביל אותם, לשכנע אותם וכל זה. ולפעמים זה Skill קצת שונה . . . אם יש לך מזל, יש לך את שניהם באותו בן אדם, אבל לפעמים זה לא.זה לא אותו דבר, זאת אומרת - אותו אחד שיודע לעשות Low-Level Debugging או High-Level Architecture זה לא בהכרח אותו אחד שיסחוב אחריו אנשים לתוך גילדות ולשינוי של מבנה וכל זה . . .(אורי) אז אחד הדברים שבנינו, כשבנינו את ה-Leveling של ה-ICs, אז אחד הקריטריונים שהולכים ותופסים יותר  מקום ככל שאתה עולה ב-Level, זה היכולת-הובלה שלך - היכולת השפעה שלך על אנשים.

• (שי) אבל זה גם בדיוק מה שאמרתי קודם לגבי ה-ICs, מבחינת Level-ים בתוך ארגון.
• הקריטריונים - מה שאתה אומר ה-Expectations, “הציפיות המוגדרות היטב” - מתייחסות גם להיקף של  הפרויקטים שהבן אדם אמור להוביל.
• הם יכולים להיות פרויקטים ברמת . . . לא יודע, 
• “שני צוותים ומעלה” זה, לא יודע, “זה Level X”
• “להוביל לפרויקטים של, לא יודע, חמישה צוותים, או משהו כזה, או שני Silo-ים, זה Level Y”.
• זה בדיוק זה.
• אני לא מצליח כל כך להבין, איפה הגילדה נכנסת כאן - בקטע הזה של Scope הובלת פרויקטים.
• כלומר, אם אנחנו מדברים על Expectations, נגיד מארכיטקט - אז בעיניי, זו נקודה מאוד משמעותית, של מה היקף הפרויקטים, ברמה טכנית, שהבן אדם יכול לקחת על הכתפיים שלו.

(אורי) אז אני מבדיל בין שני דברים - כשאתה מוביל הובלה טכנית של פרויקט, חלק ממה שמצופה ממך להוביל זה ה-What: זאת אומרת, “מה תעשו כדי שהפרויקט יקרה?”, 

• (שי) אוקיי . . .

(אורי) המקום של גילדה, הוא מקום של How? - מה הסטנדרטים שאנחנו מיישרים בארגון, בשביל שהארכיטקטורה  מסויימת או שקומפוננטות (Components) - ברמת הארגון - יוכלו לדבר אחת עם השניה, “עושים את זה ככה”.

• (שי) אני רוצה לתת דוגמה לעניין הזה. יש לי לקוח - אני לא אנקוב בשמו - אבל לקוח שמאוד שם בפוקוס את העצמאות של ה-Pod-ים.
• חברה בשלה כבר - יש להם הרבה שנים, מצאו את ה-Product-Market Fit שלהם, הם גדלו לאט ובביטחון
• אבל הם יצרו מספר לא קטן של Pod-ים, שכל אחד עובד לבד - בלי בכלל להתייחס למה ש-Pod-ים אחרים עושים.
• וזה עבד להם מעולה - כשהם היו קטנים. 
• אבל ככל שהם גדלו, הצורך ב”משהו מרכזי” נהיה יותר ויותר ויותר ניכר - ובאמת בשנה האחרונה, יחד איתם, התחלנו לבנות להם את הקונספט של גילדת Engineering,
• ושם היה ניכר שיש באמת צורך בשתי הפונקציות - ובאמת שתי הפונקציות האלה יכולות להיות באותם אנשים, או באנשים שונים..
• מצד אחד, הבן אדם שיגיד “לא! אנחנו לא נייצר “God Object” עם מאה שדות, ונשים אותו ב-Mongo”.
• “אנחנו נתחיל לנסות לייצר הפרדה ל-Domain-ים”.
• ומצד שני...

• (רן) ה”שלילי על שלילי” זה בסדר, נכון? “God Object” ו-”Mongo” זה בסדר . . .

• (שי) אני חושב שאם תשאל את העובדים של אותה חברה, הם יגידו לך שלא כל כך כיף להם להתעסק עם ה-God Object” הזה.
• ומצד שני יש צורך לקחת את “הציוויים האלה של המלך” - ולחלחל אותם לשטח.
• עכשיו, אתה יכול לחלחל את זה בציווי - ואתה יכול לחלחל את זה גם בשכנוע ולימוד.
• וגילדה היא פונקציה בארגון, שעוזרת לחלחל דברים - לא בכוח אלא באמת בהובלה, בהשפעה, בפסיליטציה (Facilitation) ולא ב-Prevention.

• (רן) כן, סוג של “הובלה ללא סמכות” - למרות שכן יש את הסמכות, אוקיי? “קורטוב של סמכות”.

• (שי) בדיוק, בדיוק - הסמכות היא “נעלמת” כזה, “היא שם והיא לא שם”.

(רן) כן. זאת אומרת, זה לא מנהל “Line Manager” מה שנקרא, לא מנהל ישיר. כן, אתה לא זה שהולך לקבוע את המשכורות של כל העובדים באותה גילדה, אתה לא הולך לפטר או לגייס - אבל כן יש איזושהי סמכות. היא קצת  Implicit, היא שונה בכל חברה, אבל בעצם זה ששם לך את ה-Title של Principal, מנהל גילדה, ארכיטקט או Whatever, נתנו לך איזשהו קרדיט מהנהלה, אוקיי? ויש איזושהי סמכות שהיא לא לגמרי מוגדרת, נכון? אבל זה לא אפס.

• (שי) I beg to defer, מה שנקרא . . .  לדעתי, נקרא לזה הפונקציה הזאת של מנהל או מוביל של הגילדה - הוא Facilitator.
• הוא מישהו שיודע לתפעל ולארגן קבוצה כנראה די קטנה של אנשים, או שיש שם איזושהי תחלופה, “מילואים”, לא יודע . . . 
• כל ארגון בסוף והגילדה או הגדרת-הגילדה שלו.
• ואני לא בטוח שזה אותו Skill-set. סליחה - זה לא בהכרח אותו Skill-set.
• (רן) זה לא אותו Skill-set, זה מה שאתה רוצה לומר. אל תתבייש . . . 
• (שי) זה לא אותו Skill-set, לדעתי, שיש לארכיטקט,
• אחד הדברים שהארכיטקט אמור לדעתי לדעת לעשות זה גם לדבר עם אנשים שהם לא טכניים
•  ולתווך להם את ארגון הפיתוח
• ולכן הוא סוג של גם “פונה כלפי חוץ”.
• נגיד, אני יכול לשבת עם צוות ה-Billing ולהסביר לו איך לדעתי כדאי לעשות את, לא יודע . .  את צורת ה-Payments וה-Billing שאנחנו עושים בארגון, במוצרים שלנו.
• ולעבוד עם אנשי-מוצר, כדי להבין האם המידול שלהם או האם ה-Business - איך אנחנו יכולים למדל את זה טוב יותר ל-Domain-ים אצלנו ומה יהיו החלטות קשות יותר וקשות פחות.
• ואני צריך לפעמים גם לדבר עם CX, עם Customer Experience Persons, כדי לברר טוב יותר איזושהי בעיה.
• כל אלה - אני לא רואה אותם חיים באותו Facilitator, באותו Guild-Manager.
• ואני חושב שזה ממש סמכויות שונות. 
• אגב, אני חושב שיש לארכיטקט סמכות, זה כמו שאתה... “הקורטוב סמכות” הזה - הוא חל גם על הארכיטקט, סוג-של.
• אם בסוף אני לא מצליח לשכנע את, לא יודע, את ה-Product Manager שאנחנו עושים כאן טעות גדולה, אז אני צריך למעשה להפעיל את המנהל שלי - שיתחיל להתקוטט עם המנהל שלו או משהו כזה. 
• בסוף יש לי את - אפרופו “חותם המלך” - יש לי את “חותם המלך”, לפחות של המנהל הישיר שלי.
• אז לא... בעיניי זה ממש לא אותו הדבר.

• [זוהר בדיוק דיבר על זה במוצרלה - (Mozzarella - Organizational Politics 101 (feat. Zohar Sacks]

30:00 שובו של (חותם) המלך וה-Fractal שממשיך פנימה
(אורי) אני חושב שפה זה ממש עניין תרבותי, כי במקום שהארגון צריך להיות מאוד גדול ומאוד סקלבילי (Scalable), אתה מתחיל לחלק ל-Domain-ים גם את הארגון. ובסוף, לכל Domain יש את ההתמחות שלו, שהייתי מאוד מעדיף שצוות שמתמחה ב-Domain X יעבוד עם צוות ה-Customer Success או ה-Business ב-Domain X ישירות - בלי להצטרך את “חותם המלך” בסיפור הזה.ואני ממש מעדיף - ואני גם מגדל את האנשים הרלוונטיים בתוך הצוות הזה - כדי שהם יוכלו לעשות את זה.עכשיו, זה בסדר שהם יכולים לעשות את זה - אבל כדי שלא יווצרו תת-Domain-ים שפועלים אחרת לגמרי, כן צריך את אותו בן אדם שייישר את ה-How - לא את ה-What, את ה-How. בסדר? What? - תעבדו ישירות. קצרו תהליכים. קצרו מעגלים . . . .

• (שי) רגע, שנייה - וכשאתה מקצר את התהליכים האלה, סבבה. הלוואי. 
• הלוואי ולכל מתכנת או מתכנתת יהיה את ה-Drive הזה.

(אורי) אנחנו לא מדברים על מתכנתת בארגון גדול - אנחנו מדברים כבר על תת-ארגון, קבוצה או צוות.

• (שי) סבבה, אוקיי, מקסים - יצרת את ה-Silo עם הדינמיקה שלו.
• לפעמים בכל זאת, אחרי שבררנו מה שבררנו, צריך לחשוב האם אנחנו רוצים למדל את זה כך או אחרת.

(אורי) הם אמורים לדעת לעשות את זה לבד, כי הארכיטקט נותן להם את זה ב-Push, בחינוך.

• (שי) אז רגע, אז שנייה . . .
• (רון) אני טוען שזה פרקטלי (Fractal), כי בתוך Silo צריך להיות Tech-Lead
• איזשהו Level 3 - 4, לא יודע, תלוי בארגון.
• מישהו שהוא מספיק בכיר או מישהי מספיק בכירה, עם מספיק סמכות וניסיון והשפעה ו-Gravitas, בשביל להיות מסוגלים להשפיע אל מחוץ ל-Silo, מחוץ לפוד.
• אבל היא גם צריכה להיות בחניכה על ידי אנשים שהם ב-Level-ים יותר גבוהים ממנה - שנמצאים בתת-ארגון שמכיל את תת-הארגון שהיא נמצאת בו . . . 
• וככה אנחנו הולכים פרקטלית (Fractal) למעלה ולמעלה, עד שאנחנו מגיעים לאיזה CTO או לאיזה Chief Architect או לאיזה Guild Leader.
• ובאמת, השמות משתנים מארגון לארגון, ולפעמים בארגון אחד מי שקוראים לו “גילדה”, בארגון אחר זה יקרה “ארכיטקט” - למרות שהוא עושה בדיוק אותו הדבר.
• ולפעמים לא . . .

(רן) ה-Fractal הזה, שי, ממשיך פנימה - זאת אומרת, בתוך אותו בן אדם: לפעמים אני הארכיטקט-שבי, לפעמים אני המנהל-שבי, לפעמים אני המקודד-שבי. [שירה].
33:03 דייג - אוהב דגים?
(רן) אבל בואו רגע - לא נגענו פה באיזושהי נקודה רגישה, שאותי תמיד סיקרנה: ארכיטקט מקודד? כלומר, צריך לדעת לצייר, נכון? צריך לדעת לכתוב . . .

• (רון). . .  את המלבנים והחיצים, זה ממש טוב . . . 

(רן) . . . המלבנים והחיצים, כן, Sequence diagrams, דברים כאלה - חייבים, חייבים! את הדמויות של ה-User, לצייר כזה יפה יפה, עם רגליים ישרות . . .  וצריך, כנראה, לדעת לכתוב איזשהו Spec טכני וזה.אבל אתה מקודד? או - ארכיטקטים מקודדים, למיטב ידיעתך?

• (רון) אני חושב - לדעתי, זה שוב, זה מאוד משתנה לפי ה-DNA הארגוני.
• יש ארגונים שיגידו “בוודאי!” ויש ארגונים שיגידו “עזוב אותך, יש דברים יותר חשובים שהיינו רוצים שתעשה”.
• ואני נמצא במקום שבו אני מקודד להנאתי, ככה “בפנאי” - אז זה לא כזה.
• כאילו, הכושר נשמר מצד אחד
• ומצד שני, כשצריך לפתור בעיית עומק - אפרופו, מה שתיארת קודם, כששולחים, “כשמכניסים את היד פנימה לקישקעס, ומנסים להבין מה קרה”
• כאן, לדעתי, נמדדת היכולת של כל הניסיון שצברתי עם הזמן.
• זה לאו דווקא הקידוד - זה הרבה יותר לשאול את השאלות הנכונות, לרדת מה-High Level, “מהמלבנים והחיצים”
• לרדת ולעשות את ה-Drill-Down לתוך הקוד, לתוך הפונקציות עצמן, ולהבין.
• כאילו, התנודתיות הזאת, מרזולוציה גסה לרזולוציה עדינה - זה, לדעתי, אחד ה-Added Value שהארכיטקט אמור להביא איתו.
• לא משנה אם זה כולל לכתוב את הקוד של הפיצ'רים הבאים או לא.
• וזה, שוב - זה קצת DNA, זה קצת מבטא את ה-DNA הארגוני.
• הייתי גם . .  “טעמתי מזה ומזה”.
• (שי) אני רוצה להגיד שאני מאוד מסכים עם כל מה שרון אומר - ועם זאת . . .
• (רון) . . . לא יכולת אולי לעצור קודם? . . . 
• (שי) . . . מאוד חשוב שהארכיטקט . . .  שלא יהיו ארכיטקטים שלא כותבים קוד.
• כאילו, זה לא מספיק בעיניי לכתוב קוד כ-Hobby, בצד - זה צריך להיות לכתוב קוד בתוך המוצר.
• כי אם אתה, כארכיטקט, מייצר כל מיני סטנדרטים ועקרונות, ומכתיב דברים, ועושה ולפעמים גם עוצר דברים - ולא חווה את חוויית-המפתח בתוך המערכות שבסוף אתה בונה, אני מרגיש שאתה עלול לפספס משהו מאוד מאוד חשוב.
• (רון) אני מסכים איתך . . .  אני מסכים איתך.

(רן) אבל . . .

• (רון) לא, אני פשוט חושב שזה . . . אבל - זו שאלה של מינון.
• אני בעד פעם ברבעון, או לכל או יותר פעם במחצית, להיכנס, להיות סוג של Shadow או לחבור לאיזשהו צוות ברמת פיצ'ר.
• לכתוב משהו, לראות שזה מגיע ל-Production, לקחת את ה...
• (רן) אתה תגיד לעצמך “מי הדביל הזה שהכתיב את ה-Spec הזה?! אה, זה אני . . .”
• (רון) אה, זה אני . . . מה, זה הסטנדרט?
• (רן) . . . כן, סוג של Eat your own Dog food, למפתחים.
• (רון) כן, אבל רציתי להגיד משהו עוד קודם - בעיניי כל הנושא הזה של הסטנדרטיזציה זה באמת אחד התוצרים של הארכיטקט,
• ואנחנו, לדעתי, כל הזמן בשיחה, תסלחו לי - מדברים על איזשהו ארגון פיתוח על גבול האוטופי . . .
• של מהנדסים ומהנדסות מאוד מוכשרים, שאפשר לתת להם את כל האוטונומיה שבעולם
• והם יכולים לרוץ קדימה כמה שהם רק רוצים, והשמיים הם הגבול.
• המציאות היא לא כזאת.

(רן) זאת אומרת, לפעמים צריך “ללכת אחורה ולדחוף את האלה עם האלונקה” . . . . אלה שקשה להם, אלה שנשארים מאחור.

• (רון) כן, ולמפות . . . . בדרך כלל, אחד הדברים שאני עושה - אני ממפה את הפערים של ה-Engineering Skills
• של ידע, לפעמים, “טהור”.
• וזה חלק מהתפקיד.
• ועד אז - עד שהארגון יהיה “מצוין" - כן, יש מקום ל-Centralism.
• אתה דיברת קודם ככה על ה... אמרת “משהו מרכזי” . . . 

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

• (רון) זה מאוד תלוי כמה כבר יש לך חוב טכני עמוק להתמודד איתו, ולפעמים צריכים קצת “פעולות רדיקליות".
• ולפעמים, כמו שאתה אומר, זה... אורי, אתה התייחסת לזה שזה חלק מ”החינוך העקבי והמתמיד”.
• זה מתחיל כאילו, To Pay Off, אפשר להתחיל “לקטוף את הפירות”
• ונדרשת לזה הרבה סבלנות.
• (רון) אבל עד אז, אני שוב אומר - ולא כל ארגון הוא בכלל רוצה לקבל את החינוך הזה, זה גם איזשהו DNA, או איזושהי תרבות ארגונית שהארגון . . .
• שלא כל ארגונים - יש להם את הראש לזה.

(אורי) לכל ארגון יש “מערכת חיסונית” לשינויים  . . . 

• (רון) תכל’ס . . . 

(אורי) אז כאילו, אין מה לעשות. צריך לפעמים...

• (רון) אבל לא כל ארגון - בכלל יש לו אותה “שאיפה למצוינות טכנית”, שאנחנו לדעתי, בשיחה הזאת, איפשהו  מניחים שהיא קיימת by default.
• ו”החינוך” הזה שאתה מתאר - לא תמיד אתה מוצא לו את הפרטנרים.
• ואז זה קצת “לחצוב את הדרך” ולעשות צעדים מאוד קטנים.
• וליצור את הדינמיקה שתאפשר את זה.
• אבל לא תמיד יש לך Stakeholders מספיק בכירים בארגון, שבכלל “קונים את הסחורה” הזו.
• ולכן, אני חושב שהדיבור - גם על גילדה, שזה רעיונית . . . אני מאוד מתחבר לזה - אבל היא מתאימה לדעתי לארגון שהוא יותר בשל...

(אורי) . . . או שמצוינות טכנולוגית זה חלק מה-DNA שלו.

• (רון) כן, כן - ואני לא חושב שזה “פתרון קסם” לכל ארגון.
• ויש ארגונים שירצו לפחות להתחיל עם דמויות
• לאו-דווקא “ארכיטקט”, לא משנה איך נקרא לזה ב-Title, אמרנו “זילות ה-Title”  . . . 
• לא משנה איך נקרא לזה - יש ארגונים שמבינים שבתור התחלה, צריך ליצור כאן פונקציות “בכירות טכנית”.
• עם אימפקט של  . . .  סוג של “צריך להקשיב להן”.
• ואחר כך, Hopefully, הם יגיעו כבר לאיזשהו מקום יותר טוב.

39:54 מבוא לחוויית הפיתוח(אורי) רציתי רק להוסיף עוד משהו מהניסיון שלנו: אחרי שנהיה כזה “ארכיטקט" - שהוא גם ראש גילדה, שהוא אחראי על ה-Practices וכו’ - אחרי זה קורה עוד דבר די מגניב, אם אתה נותן עוד יעד - ליצור אוטומציות. כי מפתחים, בינינו, זה טיפוס עצלן . . .  כשאתה מכניס Practices, הם בדרך כלל יבואו עם עוד עבודה, נכון? אז חלק ממה ש...(רן) והעבודה זה הדבר הזה שמונע ממך ללכת הביתה . . .(אורי) בדיוק.(רון) חוסם אותך ביציאה . . . (אורי) כן, או סתם מלשחק FIFA . . . אצלנו, קראנו לזה הצוות של ה-DevX, ה-Developer Experience - הוא פשוט לוקח את כל הדברים שאפשר לעשות להם אוטומציה, ומכניס אותם לתוך התשתיות ולתוך תהליכי העבודה, ומייצר פשוט סטנדרטיזציה הרבה יותר טובה לתהליך.

• (רון) וכמה ארגונים אתה מכיר, שמחזיקים את הפונקציה הזאת, של Developer Experience, של הצוות DevX הזה? אני מכיר מעט מאוד . . . 
• ואני לא בטוח בכלל שזה... אני לא יודע לתת לכם אחוזים, אבל זה שוב - “הלוואי”.
• הלוואי ובכל ארגון הייתה את הראייה הבוגרת והבשלה הזו.
• יצא לי מספיק פעמים בחיים לראות ארגונים וגם לדבר עם אנשים - אני עושה קצת Mentorships, ככה כחלק מהדרך.
• ואני שומע הרבה מאוד אנשים שמדברים איתי, ולמעשה - תכל’ס, אני מזקק את זה ואומר “חבר'ה, זה לא ארגון פיתוח שעשה מצוינות כערך”
• ועכשיו אנחנו צריכים להבין איך אנחנו מתקדמים ואיך מתפתחים בכל זאת שם.
• אוקיי? כאילו זה בסוף, לא כזה פשוט החיים בחוץ. It’s complicated. 

• 
  

42:13 לתת בהם סימנים ותיאום ציפיות
(רן) אוקיי, אולי שאלה אחרונה לסיום - נניח שאני מנכ״ל או CTO או VP R&D של איזושהי חברה, ואני קם בבוקר  ושואל את עצמי “רגע, רגע, אין לי ארכיטקט! איך זה יכול להיות שאין לי ארכיטקט?! האם אני צריך אחד כזה?”אז מה הם הסימנים, לדעתכם, שמעידים על כך שאולי שכחתי משהו?שי - נגיד, מקודם הזכרת כמה Pod-ים שפועלים באופן שלא אולי לא מודע אחד לשני, אולי עושים עובדה מיותרת.אבל מה הם הסימנים המעידים על כך שאולי כדאי לי לחשוב על תפקיד כזה,כמו של ארכיטקט, או אורי - כבלת את זה יחד עם “מנהל גילדות", כדברים קשורים.מה הם אותם דברים שיצא לכם לראות, שיגרמו לכם לזעזוע הזה ולהחליט לגייס מישהו או לקדם מישהו ולשים את התפקיד הזה?

• (רון) For fun, הייתי רוצה ששי יענה על זה . . . 
• (שי) בשמחה. מהניסיון שלי, קודם כל, אני חושב שמהרגע הראשון, כדאי שיהיו אנשים שיכולים להתפתח לשם - ויצמחו עם הארגון.
• זאת אומרת, אפילו שה-Founding-team של הסטארטאפ - ה-Founder-ים והמפתחים הראשונים שהם  מגייסים, שתיהיה להם את ההבנה שהם יצטרכו מתישהו להתחיל להסתכל על התמונה הכללית.
• מלמעלה יותר, לעשות Zoom-Out.
• אבל כן - הסימפטומים שאנחנו חווים בארגונים שאין להם את הדמויות האלה, הם ארגונים שבהם קשה מאוד לייצר שינוי רוחבי ביחד.
• קשה מאוד לנווט, “אנחנו לא אונייה אחת” - אלא אנחנו “צי” של הרבה מאוד ספינות קטנות.
• אבל הן לא בהכרח כולן שטות לאותו כיוון שאנחנו רוצים שהם ישוטו אליו.
• ואז צריך להבין איך אנחנו מייצרים להם איזשהו “שייט במבנה”.
• (רון) “היד המכוונת”
• (שי) סליחה על השימוש בטרמינולוגיה ימית . . . 
• (אורי) לא, לא. אתה בטוב.
• (רן) נניח מטוסים, שלא כולם טסים לאותו כיוון . . . 

(אורי) אני רוצה לשאול את השאלה - זה לא כזה משנה אם יש “ארכיטקט” או לא, משנה אם מישהו “עושה ארכיטקטורה” או לא.

• (שי) לגמרי.
• (רון) לא ממש, לא מסכים.
• בעיניי, ארכיטקטורה זה תוצר אחד - אבל לא היחיד.
• בעיניי, ארכיטקט - או לא משנה, ה-Title הטכני הזה - הוא נדרש.
• כשמנהל הפיתוח מבין שה-Velocity של ה-Dev Org שלו הוא לא כמו שהוא היה מצפה
• הוא רואה יותר מדי באגים, הוא רואה יותר מדי עיכובים בלתי צפויים . . .
•  וכל אלה מייצרים איזושהי תובנה עמוקה יותר, שה-Engineering Level הנוכחי -או החוב הטכני הנוכחי, זה בדרך כלל בא ביחד - זה בעייתי מדי כרגע לארגון.
• ואנחנו צריכים Somehow לדחוף יותר גבוה או יותר למעלה את הארגון.
• וזה כנראה . . . כוח האדם שנמצא כרגע - כנראה שאין לו את ה-Attention או את היכולת לבצע את זה.
• אחרת זה כבר היה קורה מאליו.

(אורי) או שלא ציפית את זה ממנו . . . 

• (רון) לא ציפיתי מהמפתחת או מה...?

(אורי) מכוח-ההאדם הנוכחי - זה מפתחת, זה ראשי צוותים, ראשי קבוצות.

• (רון) ומה זה אומר? אוקיי, אז בוא נפרוט את זה - מה זה אומר “לא ציפית את זה ממנו”?

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

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

(אורי) זו הגדרת תפקיד . . . . אצלנו, הרבה מאוד שנים, אולי אפילו עדיין ככה, תכל’ס - הארכיטקטים של קומפוננטות  (Components) שנמצאות אצל צוותים מסויימים, זה בסוף על הראש-צוות או הראש-קבוצה. בסוף, המצויינות  הטכנולוגית של הצוות שלהם - זה על הראש שלהם.

• (רון) אבל מי לוקח? . . .  לא, רגע, שנייה - בסוף, יש לך איזשהו ארגון, ולא סתם יש לנו שם מנהל פיתוח, נכון?
• הוא אמור, אתה יודע, הוא שם את ה... סליחה, “התחת שלו על הגריל”, כן?
• זה הוא שאמור לקחת את האחריות על התוצרים.

(אורי) אבל מתחת לתחת שלו, יש את התחת שלהם . . . (רן) אנחנו יורדים נמוך מאוד פה . . . 

• (רון) בסדר - אבל אפרופו פוליטיקה אקטואלית, מה האחריות המיניסטריאלית שלו? הוא אחראי ל...

(אורי) זה נכון שהוא אחראי.

• (רון) הוא אחראי - אבל הוא אחראי גם על ה-DNA הארגוני. הוא אחראי.
• ואם ה-DNA הארגוני בסופו של דבר . . . הוא בסוף רואה את התוצרת בעצמו, נכון?
• וכנראה שהוא לא יכול לבד . . . 
• מה שאני מנסה לחדד פה, זה שאם הוא היה - אם ה-DNA הארגוני היה כזה שבאמת התוצרים היו טובים, זה אומר שהוא תקשר ונתן את הציפיות והשקיע מה שהשקיע והכל, כדי לייצר את המצוינות הטכנולוגית שלדעתי אתה מכוון אליה.
• אבל אולי אין לו את זה
• ואני חושב שאני קצת כן נותן לך את התשובה, רן - שלא תמיד יש לך את המנהל הכי הכי טכנולוג או שבאמת מודע למקום הזה, של מצוינות טכנולוגית
• והוא צריך את “ה-Wingman שלו” - להלן “ארכיטקט”, או ראש גילדה או What Not - שהוא יהיה זה שמחזיק את הטיקט של האיכות והשאיפה למצוינות ו-Raising the Bar.
• (שי) אבל איכות זה שאיפה למצוינות . . . 

(רן) תגיד “אני מסכים, אבל . . . “.

• (שי) אני מסכים . . . 

(רן) . . . “עם כל מה שהוא אמר” . . . 

• (שי) . . . . אני אציין ואני אחדד ואני אגיד שמצוינות טכנולוגית ושאיפה למצוינות וכל דבר - הם לא מטרה.
• הם אמצעי - בסוף, כדי שה-Buisness יהיה יותר מוצלח.
• ולכן, אני חושב שזה מאוד מאוד נכון שמצוינות טכנולוגית ופוקוס על טכנולוגיה ועל הנדסה, זה אחד מהדברים ש-IC ב-Level בכיר, בין אם אתה קורא לו ארכיטקט או Principal, צריך לעשות.
• אבל עוד אחד מהדברים האלה שהוא צריך לעשות, זה לעזור לתתי-ארגונים לראות את התמונה הגדולה.
• לראות לאן הארגון הולך.
• לא לעשות אופטימיזיה לוקאלית (Local), אלא לעשות אופטימיזציה לטובת הארגון כולו - גם במחיר של ה-KPI's או של ה-OKR's של התת-ארגון שלי.
• (רון) אני מסכים איתך!

(רן) ונעצור כאן . . . .

• (רון) כן, זהו.

(אורי) הייתי כבר בדיון שבו מישהו אמר “אני מבין מה שאתה אומר - אבל זה חרטא” . . . (רן) כולם מסכימים, אבל רבים מסכיב . . .

• (רון) כן, אני מקווה שזה . . . אין כאן רמז.

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

 האזנה נעימה ותודה רבה לעופר פורר על התמלול!

[קישור לקובץ mp3]

פרק 483 של רברס עם פלטפורמה, שהוקלט ב-12 בנובמבר 2024. אורי ורן מארחים באולפן בכרכור את אופיר ביבי מחברת Lightricks לשיחה על למה הם כל כך מזוכיסטים, או במילים אחרות - למה ב-Lightricks החליטו שהם רוצים לאמן מודלי Foundational, ויותר מעניין מזה - איך?

01:04 אופיר ו-Lightricks(רן)  אז קצת לפני שנצלול לשם - אופיר, ספר לנו קצת על עצמך.

• (אופיר) אז אני אופיר. אני קודם כל נשוי ואבא שלושה. ב-Lightricks אני מנהל את מחלקת המחקר, אני שם כבר כמעט תשע שנים.
• ובמחלקת המחקר שלנו, אנחנו עושים בעצם את כל “הקסם שמאחורי הקלעים” במוצרים של Lightricks.
• והגעתי לשם מתוך המקום - חוץ מזה שבאמת הכרתי חלק מהפאונדרים, וכל הזמן ירון, שהוא ה-CTO שלנו, שאל אותי מתי אני מצטרף - אני רציתי לבנות את המצלמה הכי טובה שיש.
• ובאתי מהמקום של Statistical Signal Processing וגם של Neural Computation, שזו בעצם התחלה האקדמית שלי.
• אמרתי “טוב, די, יש חישובים שאפשר לעשות”, כולנו מסתובבים כבר עם המצלמות הכי טובות עלינו, כי הן פשוט בכיס שלנו
• אבל הן לא באמת טובות - פיזית. בואו נעשה אותן טובות יותר.
• וזה היה האתגר הגדול שרציתי לפתור.
• וככה התגלגלתי ל-Lightricks, אחרי כל מיני דברים אחרים - כולל אנרגיה סולארית וכו’.
• ובאמת בניתי את המוצר הראשון שכלל מוצר-מצלמה, אבל כמו שאני חושב שכולנו יודעים, מוצרי-מצלמה שזה לא ה-Stock Camera של הטלפון לא באמת שורדים . . . 
• אז כמובן של-Lightricks יש הרבה מאוד מוצרים אחרים שבנינו והרבה דברים מעניינים שאנחנו עושים.

(רן) ורק למקרה שמישהו לא היה בכדור ולא מכיר את Lightricks, אז גם כמה מילים על החברה?

• (אופיר) כן, אז Lightricks זו חברה שבעצם עושה כלים לעריכת תוכן ויצירת תוכן.
• אנחנו נותנים הרבה יכולות וכלים ל-Creatives וגם ל-Brands שעובדים איתם ושצריכים להשיג Creatives.
• יש לנו בסוף, כמו שאמרתי, הרבה מאוד מוצרים שונים. היום יש לנו שלושה מוצרים שהם בפוקוס.
• בעולם ה-Mobile, שממנו גם הגענו, יש לנו את Facetune, שזה המוצר הראשון והכי גדול שלנו, לעריכת תמונות פורטרט, הידועות בשמן “Selfies”.
• יש לנו את המוצר החדש שלנו שנקרא LTX Studio, נדבר גם עליו לא מעט.
• שהוא מוצר ליצירת סיפורים, בסוף, ליצירת וידאו, ליצירת Story Board.
• שהמנוע שלו זה כבר מנוע ממש מהדור החדש, מנוע גנרטיבי (Generative) כמעט לחלוטין.
• בסוף הוא איזה שהוא “היברידי” של עולם ישן -  עולם חדש, אבל זה כבר לא “בואו נרנדר (Render) את כל התלת-ממד”, אלא מנוע הרינדור (Rendering Engine) המרכזי הוא Generative Models.
• וזה גם מוצר שמבחינתנו היה חידוש גם בקהל שהוא פונה אליו, קהל יותר של Professionals, יותר אפילו של Studios, של Enterprises.
• וגם ב-Web ולא ב-Mobile, אז זה חלק מהחידושים.

(אורי) . . . . ויצאתם בעצם מאפליקציה, נכון? כאילו - זה כבר לא בהכרח אפליקציה.

• (אופיר) כן.  אפליקציה, מוצר - זה בסוף משהו שהיום הוא כבר “פתוח לעולם”.
•  הוא מתחיל מ-Early Access - רשימת המתנה, המוני אנשים שנרשמו.
•  ושוב,  יש לו באמת שתי פנים
• צד אחד זה הצד שגם היינו רגילים אליו, של אותו Consumer - של פשוט אינדיבידואלים, Creator-ים, אנשים נלהבים שפשוט מגיעים למוצר ומשתמשים בו לצרכים שלהם.
• ויש לנו בעצם את הצד החדש מבחינתנו, של ה-Businesses - של B2B, של שיווק המוצר ל-Enterprises, ל-Production Houses, שמנסים לעבוד בצוות ביחד על הדברים שמייצרים שם.
•  זה עולם עולם ומלואו.
• (רן) אז דיברת על Facetune, על LTX - והשלישי?
• (אופיר) כן, אז LTX Studio, והשלישי זה מוצר שנקרא Popular Pays
•  זו בעצם חברה שרכשנו, שמחברת בין Brands ל-Creators.
• המטרה שלנו שם זה לאפשר לכל ה-Creator-ים שנמצאים בפלטפורמות השונות שלנו להתחבר עם Brands.
• ול-Brands לקבל בעצם את ה-Creator-ים ואת ה-Creatives הנכונים ביותר עבורם.
•  גם שם אנחנו מכניסים המון המון חידושים עם AI ועם אלמנטים גם של Tooling ו-Generative AI.
• ממש עכשיו גם הוספנו שם איזושהי יכולת-ניתוח, שבסוף כשאתה Brand ואתה בא לשתף פעולה עם איזה שהוא Creator אתה רוצה לדעת איזה סוגי-תכנים יש לו
• האם הם עומדים בכל מיני דרישות שיש לך - אולי של Safety, אולי של סגנון
• לקבל ממש דוח מאוד מעמיק - אבל מהר ואוטומטית, דברים שבעבר היו הרבה יותר קשים, אז . . . 

(רן) 06:23 מה זה Foundational Models?(רן) אוקיי, עכשיו - לכל כל המוצרים שלכם יש צד ויזואלי מאוד חזק . . . . אז בחלק מהמקרים זה תמונות, בחלק מהמקרים זה וידאו.והזכרת את המילה “ג'נרטיבי” (Generative): הרבה אנשים נתקלו במושג הזה כשהם פגשו את ChatGPT וחבריו, אבל פה אנחנו מדברים על מודל Generative-י שמג’נרט (Generates) או תמונות או וידאו - שזה קצת-קצת יותר מורכב, לפחות מבחינת . . .  טוב, לכל אחד יש את המורכביות שלו, אבל המורכביות פה הן שונות.אז מה . . .  בעצם פה, אנחנו רוצים לדבר על מה זה Foundational Models - למה צריך אותם ואיך לעזאזל עושים את זה? כלומר, אם אני מחר בבוקר רוצה לקום ולהתחיל לאמן מודל כזה - מה כדאי שאדע לפני שאני מתחיל את זה?(אורי) שאתה הולך לישון בערב של . . . 15-יום אחר כך.(רן) אז בוא נתחיל אולי בקצת הגדרה, ככה בקטנה, של מה זה Foundational Model? במה הוא שונה מהאחרים?

• (אופיר) כן, אז בסוף - Foundational Models, וזה שונה מ-Generative Models, אסור לבלבל בין השניים  . . . Foundational Models זה מודלים שהם כל כך רחבים בידע שלהם, במה שהכניסו לתוכם, שהמשימות שהם מסוגלים לבצע בסוף הן מאוד מאוד מאוד רחבות.
• זאת אומרת, הידע שעצור בתוך מודל כזה מאפשר לך אחר כך לבוא עם משימות חדשות, ובין אם במה שנקרא Zero-Shot,  פשוט . . . .
• שוב, למשל במודלים גנרטיביים (Generative Models) של טקסט
• אז פשוט אני עורך את ה-Prompt קצת אומר לו “בוא, תענה לי על איזושהי בעיה” שהוא לא בהכרח אומן ספציפית לבעיה הזו.
• והוא פותר לך את הבעיה.
• למה? כי הידע כבר נמצא שם, מתוך תהליך האימון.
• לפעמים זה גם לא הסתכלות של Zero-Shot אלא של Few-Shots או Fine-tuning - כמה, בעצם, מאמץ אני צריך לעשות כדי להביא אותו מאיפה שהוא נמצא לאיזושהי יכולת שאני רוצה להגיע אליה.
• עכשיו, מאחורי הקלעים, מה שזה אומר זה שהמודלים האלה אומנו על כמויות “היסטריות” של Data.
• הם ראו באמת כל כך הרבה Data, שתפיסת-העולם שלהם, תפיסת-ההתפלגות של ה-Data שעליו הם הסתכלו, בין אם זה טקסט בין אם זה Visuals, היא כל כך כל כך רחבה, שבסוף אם אתה בא, וגם אם אתה מתמקד באזור מאוד מאוד מסוים, רוב הסיכויים שהוא כבר למד משהו, אפילו באופן לא ישיר, על האיזור הזה של העולם.
• ובמאמץ מאוד מאוד קטן אתה יכול לחלץ ממנו את הידע הזה.

(רן) כן, אז לפני כמה שנים - אני לא זוכר, כמה שנים - יצאו עם הקונספט של “בוא נאמן מודלים בשני שלבים”:  אחד זהאימון של ה- Foundational Model עצמו, בין אם זה בעולם השפות, בעולם ה-Video ובמקומות אחרים, ואחר כך נוכל לעשות או להשתמש בו As-is, או בהרבה מקרים לעשות לו איזשהו Fine-tuning, אבל זו פעולה שהיא הרבה יותר קלה.עכשיו, הרבה כאלה שנמצאים בעולם הזה, של מודלים גנרטיביים (Generative Models), פשוט לוקחים Off the Shelf איזה Foundational Model - ועושים לו קצת Fine-tuning, אם צריך. אתם החלטתם שלא. אתם החלטתם לייצר את ה-Foundational Model בעצמו - בעצמכם.למה?

• (אופיר) אז הרבה סיבות  . . . .
• הסיבה אני חושב שהמרכזית ביותר זה שב-Domian שלנו, שזה ה-Domain הוויזואלי (Visual), כמעט תמיד
• גם כשהיינו מדברים על הגרסאות הקודמות, של מודלים גדולים, ואם באמת לא בעולם הגנרטיבי (Generative), בעולם הדיסקרימינטיבי (Discriminative)
• אז היו כל מיני מודלים שהם Pre-Trained, ואז היית מוסיף קצת Data ופתאום יש לך מודל קלסיפיקציה (Classification) או Detection או כל מיני דברים כאלה.
• אז לבוא ולקחת את המודלים האלה Off-the-Shelf - היסטורית, פתר לנו 20% מהבעיות . . . 
• בגלל שלמשל היינו ב-Mobile, ומאוד מאוד היה חשוב לנו שכל המודלים יהיו יעילים ומהירים
• לא יגמרו את הסוללה, יעבדו מהר וכו’
• אז מצאנו שאנחנו צריכים הרבה פעמים לבנות את המודלים בעצמנו
• או לעשות תהליכים שהם יותר גדולים, יותר כבדים
• כולל Distillation מלא, למשל, של מודלים, ולכן . . .

(רן) Distillation - זיקוק . . . 

• (אופיר) זיקוק, בעברית צחה . . . 

(רן) . . . זה למעשה לקחת מודל גדול, שאולי עושה עבודה טובה, ולייצר ממנו - או על ידו - לייצר מודל יותר קטן, בטכניקה שקיימת שנקרא, Distillation.(אורי) . . . אבל יותר “יעודי”, נכון?

• (אופיר) אז לפעמים יותר יעודי - ולפעמים לא . . . 

(רן) לפעמים פשוט יותר “קומפקטי” . . . 

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

(אורי) אבל זה קורה על ידי זה שאתה בערך מאתר את “האזורים הטריוויאליים” במודל, ואתה אומר “אוקיי, זה טריוויאלי,” או “את זה אני יודע, את זה לא צריך, זה לא רלוונטי לבעיה”. או בוא נגיד ככה, כנראה שיש איזה מודל שיודע להוציא את הדברים האלה, הלא רלוונטיים, ולעשות את “הזיקוק”.

• (אופיר) לא, אז הזיקוק נעשה בעיקר מתוך ניסיון לחקות את המודל הגדול.
• אתה יכול להטות את מה שהמודל הקטן לומד, על ידי באמת לבחור סוג בעיות או סוג Data שאתה רוצה “לזקק החוצה”.
• אתה יכול גם לבוא ולהגיד “אני רוצה לעבור על כל מרחב ה-Input-ים אי פעם”
• ואז יכול להיות שזו תהיה בעיה באמת קשה מדי, והמודל הקטן - הוא ילמד משהו מאוד מאוד “טוב”, אבל הוא יאבד קצת באיכות
• הדיוק יהיה קצת יותר נמוך או משהו כזה.
• לפעמים - זה מפתיע - לפעמים לא מאבדים באיכות בכלל.
• ולפעמים אפילו המודל הקטן משתפר לעומת המודל הגדול.
• זה חלק ממה שקורה בתהליך הזה של זיקוק.

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

• (אופיר) כן.

13:35 אוקיי, אז איך עושים את זה?(רן) אוקיי, אז זאת אומרת, ניסיתם כמה דברים. בחלק מהמקרים זה פשוט היה מודל שהוא צרך יותר מדי חשמל, או אולי יותר מדי זיכרון - ובסופו של דבר לא התאים לטלפונים. זו, נגיד, סיבה אחת למה אולי אתם כן רוצים לייצר מודלי-Foundational בעצמכם. ואני מניח שיש עוד - אבל בואו נמשיך הלאה ונדבר על “אוקיי, אז איך עושים את זה?”זאת אומרת, דיברת על (1) יכול להיות שזה מודל שהוא מאוד גדול ו-(2) הוא צריך המון המון Data, וכנראה הרבה מאוד שעות-אימון.

• (אופיר) כן, אז הרבה מאוד שעות-אימון.
• ושוב, תמיד מחשבים את זה בשעות כפול כמות החישוב שנכנס פנימה, וצריך הרבה מאוד Data.
• האתגר אני חושב הוא, שוב - הוא כפול.
• הדבר הראשון הוא באמת החסמים האלה, של להבין איך מארגנים - ברמה הטכנית, ברמה ההנדסית - את כל הדברים האלה שהם יעבדו.
• זה דברים שככל שהזמן עובר הופכים להיות יותר קלים, כי גם החומרה וגם התוכנה משתפרות.
• אבל זה עדיין אתגר מאוד מאוד מאוד גדול, לגרום להרבה GPUs או הרבה TPUs לעבוד ביחד.
• חומרה נופלת, כי בעולם האמיתי לא הכל עובד כל הזמן . . . 
• בתוכנה יש מגבלות שאם צריך לעבור אותן, אז צריך לכתוב הרבה דברים Custom מעל זה.
• ואני חושב שבצד האלגוריתמי, מה שקורה זה שכשאתה מאמן איזשהו מודל קטן יותר, וסדר-הגודל של אימון הוא בין שעות לבין ימים בודדים, אתה מקבל כל מיני החלטות החלטות.
• ואתה צריך לבחון האם ההחלטות האלה היו טובות.
• אז אתה יכול להסתכל על האימון, לעשות לו Babysitting, אולי אפילו לבוא ולהגיד באמצע אם זה כן עובד לך או לא עובד לך.
• אבל אתה יכול הרבה פעמים - במקרה של מודלים מאוד קטנים, אפילו לפעמים תוך דקות, או תוך כמה שעות - אתה יכול להגיד “אוקיי, זה מתכנס לי, לא מתכנס לי - אני אחליט משהו אחר, אני אמשיך ככה”.
• כהשניסויים קטנים, אז אפשר אולי להריץ גם עשרה ניסויים במקביל.
• כהשניסויים גדולים, אתה מקבל החלטה - והיכולת שלך לשנות אותה היא כבר לא בסדר- גודל של שעות.
• היא בסדר-גודל של יום, יומיים, לפעמים אפילו שבוע.

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

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

(אורי) הרבה קפה? . . .

• (אופיר) הרבה קפה, הרבה קפה . . . 

(אורי) . . . .זה כמו ה-Complier-ים ש . . . 

• (אופיר) זה באמת הצוות, שאתה יודע - גם כשהם לא עושים Babysitting, הם עושים Babysitting לאימונים האלה . . . .
• הם כל הזמן חושבים על זה.
• אני רואה את הגלגלים בראש - “רגע, אולי אני לא צריך מחר בבוקר, אולי היום, לא יודע מה, ב 11 בלילה, אני אוכל לראות אם האימון הזה מתכנס או לא” . . .
• “ . . . - ואם לא, אז אני עוצר אותו ואני אעשה את השינוי שחשבתי עליו כבר אתמול, אבל לא יכולתי אפילו לבדוק אותו, ואני אתחיל אותו מחדש” . . . .
• זה דברים שבאמת אתה רואה אותם גם קורים בפועל, כל הזמן.

17:50 איך מתחילים?(רן) כן, אז אוקיי, אז כאילו - איך מתחילים? זאת אומרת, איך אתה בונה? רשתות נוירונים - הרי יש להן מיליארדים שלפרמטרים, ואיך אתה מתחיל עם זה? כאילו מה, אתה מתחיל עם ארכיטקטורה מאפס? אתה לוקח ממישהו אחר? אתה מתחיל לקרוא מאמרים? איך מתחילים?

• (אופיר) כן, אז ללא ספק מתחילים מלקרוא מאמרים, כמו כמעט כל דבר שאנחנו עושים.
• וקצת חזרה לבעצם למה . . . בסוף, כשהייתה את ההכרזה הגדולה של OpenAI על Sora
• מוצר שבעצם הוא לא מוצר היום - כי הוא לא פתוח, הוא לא חשוף, הוא לא מוצר. . . .
• זה התניע הרבה מאוד תהליכים בקהילה, של גם לנסות להבין ומה קורה, ולעשות השערות.
• ובאיזשהו מקום זה גם מגדיל את הביטחון של “אוקיי, רגע - אנחנו כל הזמן חשבנו, ואולי כן ואולי לא, ואולי אפשר לעשות את זה, ואולי אי אפשר”
• ואז “רגע, אם עשו את זה, אז אפשר לעשות את זה” . . . 

(רן)  כן, Sora, רק למי שלא מכיר, זה מודל שמחולל וידאו. זאת אומרת, כאילו איזשהו Prompt טקסטואלי “תעשה לי סצנה של המערב הפרוע בעיירה, וסוסים וזה” - והוא פשוט עושה את זה.

• (אופיר) נכון, נכון.
• ואחרי שיצא לנו לעבוד הרבה עם מודלים גנרטיביים (Generative) של תמונות, ואפילו התחלנו לעבוד עם מודלים גנרטיביים (Generative) של וידאו, אבל שהם היו בסדר-גודל הרבה הרבה יותר קטן,
• אז הגענו להבנה שאם אנחנו רוצים מודל שיביא אותנו - יום אחד, לא היום - ל-Production-Grade Quality, אז אנחנו צריכים להתחיל.
• ושיש לנו דרך שבה “כמות הסיכון” היא עדיין מאוד גדולה - אבל זה לא “אוקיי, אף אחד לא ראה כזה דבר, לא חשב על כזה דבר”.
• אז אני חושב שבשלב הזה זה התניע - זה התניע את זה בהרבה קבוצות, כולל בקבוצות אקדמיות.
• ולמזלנו גם באמת אותו חוקר שבנה את Sora, היה רגע לפני זה ב-NYU, באיזושהי קבוצה אקדמית שהיא אחת מהבודדות במערב שבאו והשתמשו בכמות Compute מאוד מאוד גדולה כדי לאמן מודלים כאלה.
• אז הסתכלנו על העבודה הזו בתור הבסיס.
• תוך כדי תנועה, כמות העבודות המשיכה בשטף כמו שיש היום בקהילה - וזה הכניס עוד ועוד אינפורמציה. 
• לפעמים זה רגע לפני שבאנו לעשות ניסוי - ואז הכנסנו את זה פנימה.
• לפעמים אחרי שאנחנו כבר חשבנו על הרעיון הזה - ואז היה לזה שם.
• אבל באמת, כמות האינפורמציה מבחוץ היא מאוד גדולה ומשמעותית.
• ועדיין,  אני חייב להגיד שזה אחד מהניסיונות שאני מרגיש, בלי צל של ספק, שעד שאתה לא “מלכלך את הידיים” בדבר זה, אין לך מושג.
• זה הכל תיאוריה, זה ממש ממש הכל תיאוריה.

(אורי) אז לי יש שאלה - אתה מדבר פה על זה שיש הרבה תיאוריה וצריך כל מיני מחקרים ואני צריך שיתוף-פעולה עם גופים אקדמיים ובכלל לעשות ניסוי של של אימון כזה לוקח הרבה זמן . . . .  וגם אמרת “אנחנו רצים למרחק הרחוק”.והשאלה שלי - האם יש Feature או מוצר של Lightricks, שאתם אומרים “אנחנו צריכים בשבילו את הדבר הזה בעוד X זמן, כדי לצאת לשוק” - והאם הדבר הזה הוא בכלל “מתחת לאופק”? זאת אומרת, אתם רואים אותו או שאתם אומרים “וואו, יש עוד כל כך הרבה זמן של פיתוח של הדבר הזה” . . . והשקעה ומחקרים וכאילו - פרויקט-מחקרי הוא . . . אתה יודע מתי אתה מתחיל, אתה לא יודע מתי זה יסתיים.

• (אופיר) נכון, אבל שוב: אני חושב שפרויקט-מחקרי בתעשייה - כמעט אף פעם אי אפשר לבוא ולהגיד “אני יודע מתי זה מתחיל” . . . 
• אפשר להגיד “איך” זה נגמר, אבל מתי זה נגמר או Milestones - תמיד חשוב שיהיו.
• במקרה הזה, LTX Studio היה לנגד עינינו.
• עכשיו, קודם כל רגע מבחינה מוצרית - המוצר לא מכוון כרגע לייצר Production Videos.
• עשינו את זה, שמנו פרסומת באולימפיאדה - של eToro, שיצרו מההתחלה ועד הסוף בתוך המוצר,
• האיכות הוויזואלית שם היא טובה,
• להגיד לך שזה נראה כאילו צילמו שחקנים בחוץ בעולם האמיתי? זה לא.
• המטרה של LTX Studio הייתה קודם כל לייצר את ה-Storyboarding ואת ה-Pre-Production, את השלבים האלה.
• ובתוך הדבר הזה, אחד הדברים הכי משמעותיים מבחינתנו היה לבוא ולראות שאנשים שעובדים עם המוצר, יכולים לעשות איטרציות מאוד מאוד מהירות.
• בסוף אנחנו נתנים את זה לאנשים שצריכים להיות יצירתיים - חושבים על רעיון, רואים תוצאה, עושים איטרציה (Iteration), משנים אותה וכו’ וכו’.
• בגלל זה המהירות הייתה מאוד מאוד חשובה לנו - אמנם הפעם זה דברים שרצים ב-Backend, על שרתים מאוד מאוד גדולים ולא ב-Mobile,
• ועדיין המהירות הייתה מאוד חשובה.
• זה, יחד עם שוב - לטווח הרחוק אנחנו רוצים להגיע גם ל-Production Grade Quality, ברמת הווידאו שאנחנו מייצרים.
• היום זו לא הייתה המטרה המרכזית.
• המטרה המרכזית הייתה שיהיה וידאו שהוא נראה איכותי, קונסיסטנטי (Consistent).
• שהוא מסוגל לייצר וידאו יותר ארוך - תנועה יותר “מעניינת”.
• המודלים הראשונים של וידאו יצרו תנועות מאוד עדינות, שנראו טוב - וככל שהתנועה הלכה וגדלה זה נראה פחות מציאותי.
• וכן, ללכת ולהרים את הרמה באופן המשכי - ובאותו הזמן גם שוב: השתמשנו במודלים גם שפיתחנו פנימית, שהם הרחבות של מודלי-תמונה.
• השתמשנו בדברים שהגיעו באמת מהקהילה של הקוד הפתוח, מ-Stability, עם רישיונות וכו’ וכו’,
• אבל דברים שהתחילו להיות מפורסמים, מחברות יותר גדולות - לא היה נראה שזה הולך להיות משהו פתוח.
• ולכן האמונה שלנו הייתה א' - יש לנו צרכים ספציפיים שלנו.
• אנחנו מבינים את המוצר שלנו, אנחנו מבינים מה אנחנו רוצים לבנות.
• והדבר השני זה שאנחנו לא רואים מישהו שפשוט מגיש לנו את זה על מגש של כסף
• גם אם במחיר של License כזה או אחר.
• דרך אגב, היום כל מיני חברות כאלו ואחרות שמציעות את המודלים הגנרטיביים (Generative models) שלהם לוידאו ב-APIs - העלויות שם הן אסטרונומיות.
• לייצר וידאו ב-APIs שלהם מאוד מאוד יקר.
• אם היינו מגלגלים את כל הדברים האלה ללקוחות שלנו, היינו פוגעים בסוף בחוויה שלהם ובמוצר - ועל הדרך, גם אף אחד מהם לא עושה את זה מהר.
• אז הם לא נתנו את הפתרון הזה.
• ברגע שזה גם היה הפוקוס שלנו, יכולנו לקחת צוות שלם - שהפוקוס שלו זה עכשיו לקחת את כל הידע שהם הביאו מבחוץ.
• וכן הלכנו על דברים סטנדרטיים, מבנים שמשתמשים ב-Transformer-ים, שזה היה הדור החדש של מודלי דיפוזיה (Diffusion Models).
• להשתמש ב-Latent Diffusion - זאת אומרת שיש שם מודל נוסף, שזה ה-Encoder, ה-VAE, ה-Variational Auto-Encoder.
• והיה מאוד מאוד חשוב לנו לוודא שכל הדבר הזה הוא יעיל, מהיר - ועונה על הצרכים שלנו.
• מסוגל לייצר וידאו “שנראה טוב” - שעונה ל-Prompt בטקסט, שמסוגל להתחיל מתמונה אולי שהביאו מבחוץ גם.
• כי בסוף שוב - אנשים קריאיטיביים, יש להם חזון. הם הרבה פעמים מייצרים Asset-ים גם אולי במקומות אחרים.
• וממש לענות על כל הצרכים שלנו.

26:10 מדברים מדע בכמה מימדים(רן) בוא נדבר קצת מדע: הזכרת את המילה Transformer-ים, ואני בטוח שהרבה נתקלו בזה לפני זה - אבל דווקא בעולם השפות. (אורי) גם פה, בפודקאסט, הסתובב איזה Transformer אחד או שניים . . . .(רן) בטוח, בטוח, כן [נגיד לאחרונה - 475 Jamba with Hofit from AI21].אז בעולם מודלי השפה, Transformer-ים זה אלה שיודעים לתת תשומת לב לכל מילה [Attention Is All You Need], ו-Transformer-ים בעצם עובדים מ-Sequence אחד ל-Sequence הבא.עכשיו, כשמדובר על משפטים, אז אתה יכול לחשוב על תרגום, אתה יכול לחשוב על יצירה של טקסט, אתה יכול לחשוב על דברים כאלה. Transformer-ים הם מאוד נוחים, והם עובדים על Token-ים, שאפשר לחשוב על זה כמו על מילים. אוקיי . . .אבל פה זה תמונות, זה לא משפט. זה לא מערך חד-מימדי - זה מערך דו-מימדי.וכשזה וידאו, אז מה זה? זה תלת-מימדי? לא יודע איך מתייחסים לזה . . . .אז איך אתה מתרגם Input שעכשיו הוא דו-מימדי? אוקיי, במקרה הטוב, אולי תלת-מימדי . . .  איך אתה מתרגם Input כזה ל-Transformer, שבכל אופן למיטב-ידיעתי עדיין רוצה משהו שהוא חד-מימדי.זאת אומרת, איך אתה לוקח תמונה, והופך אותה לאוסף של Token-ים שה-Transformer-ים ידעו . . . Sequence של Token-ים שה-Transformer “ידעו לדבר איתם"?

• (אופיר) כן, אז המהלך הזה קרה כבר כמה שנים אחורה, עם מודלים שנקראו ViT, שזה Visual Transformer
• שבעצם עוד בעולם התמונות, מי שראה את זה מגיע, ראה את ה-Attention, ראה את ה-Self-Attention, את ה-Cross-Attention שיש ב-Transformer-ים,
• וזה באמת נשמע מאוד מאוד טבעי ב-Token-ים ובשפה.
• אבל כשאתה מסתכל רגע על מה המודל עושה, אז הוא פשוט “מאפשר לך יותר”.
• זה גם עולה יותר - הוא ריבועי באורך ה-Sequence, יש שם אינסוף מקומות שהיום מנסים לגרום לדברים האלה לעבוד גם בצורה יעילה יותר ברמה המתימטית או האלגוריתמית, על אותו Attention מלא.
• אבל בעצם באו ואמרו רגע - יש לנו פה Sequence. זו לא פעם ראשונה שניקח סיגנל דו-מימדי - במקרה שלנו תמונות - ונכניס אותו לאיזשהו חד-מימד.
• אפילו שאין איזשהו Cardinality, כן? איך אני עובר על התמונה - מימין לשמאל, מלמעלה למטה? אם אני הופך את הסדר, מה זה עושה?

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

• (אופיר) נכון, נכון, אז יש איזשהו מבנה לתמונה.
• ובעצם, המודלים הראשונים שעשו, הם היו דיסקרימינטיביים (Discriminative) - הם באו לעשות קלאסיפיקציה (Classification), או לעשות . . . 
• לפעמים, באיזשהו שלב נכנסו כבר לאיזורים גם של סגמנטציה (Segmentation), שזה גם ממש לייצר תמונה בצד השני.
• אבל שם השתמשו ב-Patch-ים - לקחו Patch-ים של התמונה.
• ואחד המאמרים הראשונים, אם לא ממש הראשון, היה נקרא A Token is Worth a Thousand Pixels [הכוונה ל-An Image is Worth More Than 16x16 Patches?]
• ובעצם שם ממש הסתכלו על איך לוקחים Patch-ים של התמונה, ועושים להם טוקניזציה (Token).
• במקום מילה - או חלקי מילה, נכון, לפעמים זה גם שתי מילים ביחד, שהופכות לאיזשהו Token - אז פה גם איזשהו Field of View על התמונה.
• דו-מימדי, במקרה של תמונות, וכן - תלת מימדי במקרה של וידאו - הופך ל-Token.
• היה שם מחקר שלם, על מה גודל ה-Patch המתאים ביותר - במשימות שונות, גדלי Patch-ים שונים, היו . . . 

(רן) כלומר - לוקחים מלבן, או אולי אפילו ריבוע מהתמונה, ורואים כל ריבוע, נגיד הפינה השמאלית העליונה? זה Token אחד. אחר כך ניקח אחד ימינה - זה Token שתיים. Token שלוש - אולי יש חפיפה ביניהם אם זה הגיוני, אבל בגדול, אתה אומר “ככה אתה עושה טוקניזציה” (Tokenization) של התמונה. ומסתבר שזה עובד לא רע עם  Transformer-ים.

• (אופיר) זה עובד לא רע.
• מה שהוסיפו לזה . . . הדבר הראשון שהוסיפו מעל זה זה מה שנקרא Positional Encoding.
• שזה עוד איזשהו מידע, שאתה מכניס ב-Input כדי להגיד רגע מאיפה הגיע אותו . . . .

(רן)  . . . בדיוק, שתדע שזה מהפינה השמאלית העליונה, ואז מהפינה ליד וכו'.

• (אופיר) בדיוק. ואז מה שראו זה שהתכונה הכי גדולה של Transformer-ים זה שהם Scalable, אוקיי?
• הם באמת רפיטטיביים (Repetitive), יחסית, באיך שהם עובדים.
• הם אפשרו, במודלי השפה, להכניס יותר Data, יותר פרמטרים - ולהגדיל אותם.
• וממש הראו שזה עובד אותו הדבר על Token-ים שהגיעו מ-Modality אחר - לא של טקסט, אלא של תמונות
• ומאוד מהר הם היו ה-Benchmark של התוצאות הטובות ביותר מבחינת מודלים דיסקרימינטיביים (Discriminative).
• ואחרי - אני בעצם קצת קופץ קדימה - פריצת מודלי הדיפוזיה (Diffusion Models) . . . 

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

• (אופיר) עדיין לא לייצר תמונות, כשבעצם, שוב, איך עשו את זה?
• אם, נכון ב-GPT רגיל - אתה מאמן אותו ל-Next-Word Prediction? 
• אז אתה מכניס את ה-Sequence שלך, ושואל אותו “אוקיי, מה ה-Token הבא שאתה רוצה לייצר?”
• אז פה הכניסו את ה-Sequence של התמונה - ויצרו עוד איזשהו Token כאילו . . . .
• (רן) “החביאו חלק מהתמונה?”
• (אופיר) כן . . . לא. אז בגנרטיבי (Generative), “החביאו” חלק מהתמונה, וכך יצרו את זה - אבל עוד בדיסקרימנטיבי (Discriminative), בעצם באו ואמרו “יש Token ‘אחרון’, שבמקום להיות הנקודה בסוף המשפט, הוא “תגיד לי איזה Class זה’”, נגיד של קלאסיפיקציה (Classification).
• עכשיו, במקום להגיד “אוקיי, תן לי רק עוד Token אחד שהוא כמו הסוף משפט”, החליפו אותו בקלאסיפיקציה (Classification) . . . 

(רן) מה שנקרא Surrogate Task, כמו שמאמנים Embeder-ים.

• (אופיר) בדיוק.
• אז באו ואמרו, אוקיי - עכשיו אני, יש לי איזושהי אינפורמציה שנכנסת, “בוא תיתן לי את הדבר הבא”.
• אז המודל של השלמת מילה, עובד אותו דבר ב-Inpainting, מה שנקרא “מילוי חורים בתמונות”
• זה ממש אחד לאחד.
• באיזשהו שלב גם נכנס הסיפור המולטי-מודלי (Multi-Modal)
• זאת אומרת, אני נותן לו Input טקסטואלי - ומצפה ממנו לייצר בעצם תמונות.

(רן) שזה למעשה מה שאתם צריכים, כנראה, במוצר, נכון? בסופו של דבר, ה-User לא נותן לך תמונה ומצפה לקבל תמונה, הוא רוצה לתת תיאור . . . .

• (אופיר) לאו דווקא . . . גם וגם.
• זאת אומרת, הרבה פעמים רוצים לתת תיאור, אבל אם אתה תשאל את רוב האנשים, זאת אומרת, רוב ה-Use-Cases-ים, דרך אגב, של Lightricks, היו “תן לי תמונה - ותייצר לי תמונה ממנה”
• כשיש איזשהם Instructions . . .

(רן) זאת אומרת איטרציה (Iterations) על תמונה - שיפורים לתמונה, ניקויים וכאלה . . . (אורי) זה מה שקורה כשאתה מבקש וריאציות על Image.(רן) כן. אז למעשה המודל צריך גם להבין את ה-Input מה-Modality של תמונה, וגם את ה-Input מה-Modality של הטקסט, ולהבין, בהינתן שניהם, מה הולכת להיות התמונה הבאה.

• (אופיר) נכון, נכון.

(אורי) והטקסט הוא יהיה Prompt? בצורה של Prompt?

• (אופיר) כן. אז הטקסט הוא, שוב - זה מאוד תלוי איך מאמנים את המודלים.
• זאת אומרת, למשל, במודל הוידאו שאנחנו מאמנים עכשיו, ה-Prompt הוא מאוד דיסקריפטיבי (Descriptive), כן?
• הוא מתאר את הסצנה, את הפעולות שקורות, את התנועה של המצלמה, כל מיני דברים . . .

(אורי) האם יגיע יום שאפשר . . . שנוכל לדלג על כל ה-Production, ופשוט ניתן את ה-Script למודל, את “התסריט” שאנחנו רוצים, ו...

• (אופיר) . . . ולקבל משהו . . . אז אנחנו, אני חושב שהיום ה-Flow שיש, למשל, ב-LTX Studio, מאפשר לך את זה, ברמה מסוימת.
• אני לא חושב שאנחנו, או, נגיד אותם אנשים שהיום אתה סומך עליהם להיות ה-Creatives, שמייצרים את הדבר שאתה תרצה לראות גם
• הם אוהבים את דרגות-השליטה שלהם.
• ולא רק כי זה כיף להם, אלא כי בסוף אתה יכול לתת Script, ואז אתה רואה את התוצאה, ואתה רוצה לשנות קצת כל מיני דברים, ואתה רוצה לשנות דברים, לפעמים, ברמת ה-Pixel, אוקיי? . . . 
• זה באמת חבר’ה שהם אובססיביים לגבי ה-Pixel-ים שלהם - ולגבי הסיפור שהם מספרים, והעוויתות בפנים של הדמות שיצרת. 
• אז כבר היום, אחד ה-Flow-ים שיש ב-LTX Studio זה “תן לי Script”.
• “תן לי Script” - ואני מייצר לך סצנות, ו-Shot-ים בתוך הסצנות, וממש את הכל.

(אורי) אבל זה, כאילו, “חומר הגלם” שעליו אתה מתחיל את העבודה אחר כך, נכון?

• (אופיר) נכון, אבל בסוף זה בדיוק העניין, אני נותן לו את ה-Shot-ים - וזה Still Photos, ואז הוא יכול להחליט איך התנועת מצלמה נראית.
• עכשיו, זה, אם הוא נתן לי את ה-Shot-ים כבר, והוא נתן לי גם תנועת מצלמה, מה שבתהליך Production די ארוך מגיעים אליו בסוף, גם בסרטים.
• זאת אומרת, כשאני בא לצלם Shot מסוים, האיש מאחורי המצלמה יודע מה הוא אמור לעשות.
• הוא לא כזה “טוב, אני אחליט תוך כדי תנועה אם אני אזוז ימינה או שמאלה, או אעשה Dolly”.
• הוא יודע מה הוא אמור לעשות באותו Shot, הוא קיבל את ההוראות האלה מראש. 
• אז התהליך של הבנייה זה - אם עשית את כל העבודה מראש, איכשהו, “עם נייר ועט” - מצוין, תכניס לנו את הדבר הזה, ואז זה גם יוכל להגיע.
• אם לא - המטרה של המוצר, זה בדיוק . . . .
• זה בדיוק הסיפור של מוצר מעל Foundational Models, כי Foundational Models יודע לייצר
•  יש אחד שיודע לייצר תמונות, אחד שיודע לייצר Video-ים
• ידיע לייצר Video-ים מטקסט, יודע לייצר Video-ים מטקסט ותמונה, ידיע לייצר Video-ים מ-Video-ים, כן . . . 
• אבל כל הדברים האלה צריכים להיכנס איכשהו לתוך Flow - שאנשים מבינים מה הם עושים, מה הם מקבלים, במה הם שולטים, במה הם לא שולטים.
• ושם אני חושב שנשאר.

[(אופיר) לשאלת ה"מה עושים עם זה?" - האינטרו עשוי ב LTX Studio והסצינה הראשונה, עם עריכות של הבמאי: ארץ נהדרת עונה 22, פרק 1, 06.11.24  -  המושבה הישראלית ביוון]
36:40 על חומרה, כסף ותרומה ל-Open Source(רן) אוקיי. בואי נדבר קצת על חומרה וכסף, מה שאפשר לספר . . .  אז כמה בעצם מודלים כאלה אימנתם, Foundational? אחד? יותר?

• (אופיר) אז שוב - היסטורית, אימנו הרבה, בעיקר בהתחלה של תמונות.
• באיזשהו שלב אני חושב ש”הבעיה”, נקרא לזה, של Foundational Models ליצירת תמונות הפכה להיות יחסית “Commodity”.
• ושם באמת עברנו לעשות דברים יותר שדומים ל-Finetunes ודברים מעל מודלים אחרים.

(רן) ובעולם הוידאו?

• (אופיר) ובעולם הוידאו, אימנו מודל אחד מרכזי - יש לו הרבה גרסאות מאחורי הקלעים
• כמו שאמרתי, זה הרבה “דם, יזע, דמעות ו-Compute” . . . 
• (רן) “לכל Checkpoint יש שם” . . . 
• (אופיר) “לכל Checkpoint יש שם” . . . ולמודל יהיה איזשהו שם, שנחליט עליו כשאנחנו מוציאים אותו.
• אבל היום יש לנו בעצם מודל אחד שאנחנו רוצים גם להוציא ל-Open Source [הנה - LTXV - The First Real-Time AI Video Generation Open Source Model]
• שהמטרה שלו זה באמת לאפשר לקהילה, שאנחנו מרגישים שאנחנו נתרמים ממנה המון - ולתרום חזרה 
• ולאפשר להם לבנות דברים מעל זה.
• וגם הצרכים שלנו הם יחסית תואמים
• זאת אומרת, אנחנו רצינו מודל שיהיה מאוד מאוד יעיל ומהיר
• בקהילה הרבה פעמים, אתה רואה שיוצאים כל מיני מודלים שיודעים לרוץ על חומרה “גדולה” של nVIDIA כזה, A100, H100 וכו’.
• ואז אנשים יושבים בבית שלהם ושואלים “רגע, איך אני מריץ את זה על ה-4090 שלי?”, או “איך אני מריץ את זה” - חס וחלילה - “על 3080?” . . .
• ופתאום הם מתקשים עם זה.
•  אז המודל שאנחנו רוצים להוציא לקהילה הוא מודל של שני מיליארד פרמטרים, שזה מודל יחסית קטן

(רן) גם בעולם השפות זה נחשב קטן . . .

• (אופיר) זה נחשב מאוד מאוד קטן . . . 

(רן) בדרך כלל “שבע” [7 מיליארד פרמטרים] זה “קטן”, 1-2 [מיליארד פרמטרים] זה “קטנצ’יק” . . . .

• (אופיר) כן . . . 

(רן) . . .  והגדולים הם באזור המאות-מיליארדים או יותר.

• (אופיר) נכון.
• אז מודל 2B, שדווקא החלק החשוב והמשמעותי בו זה ה-Autoencoder שלו.
• אנחנו ממש בנינו אותו מ-0 לצרכנו, את כל המודל.
• וב-Autoencoder אנחנו ראינו שהתייחסות לוידאו כוידאו - לא לקחת Autoencoder שהיה של תמונות, וקצת “לנפח אותו”, קצת להוסיף עליו ולעשות לו Patching.
• בעצם להסתכל על זה - ממש כמו ששאלת קודם - כתלת-מימד.
• יש לנו מימד שלישי, שהוא מימד הזמן, אנחנו רוצים לעשות דחיסה בצורה שהיא מאוד מאוד יעילה
•  גם כדי שכל המודל יהיה יעיל, גם כדי שהלמידה תיהיה יעילה, כדי שלא תיהיה יתירות במידע שמגיע מה-Autoencoder.
• וכל הדבר הזה יצר בעצם איזשהו Autoencoder עם יחס-דחיסה מאוד מאוד מאוד גדול . . . 

(רן) כלומר לקחת את ה - Raw Video ולהפוך את זה ל-Stream של משהו שעליו אפשר להתאמן?

• (אופיר) כן. זה מה שנקרא בעצם Latent Code, זה לעבור מה Image Domain או הVideo Domain ל-Latent Code
• במקרה שלנו, בגלל שבנינו את זה ייעודית לצרכים שלנו, ה-Autoencoder ממש מוציא את ה-Token-ים שנכנסים לתוך ה-Transformer, שעושה את ה-Diffusion ישר אחריו.
• (רן) אז Video2Vec, פחות או יותר . . . .
• (אופיר) Video2Vec.

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

• (אופיר) כן, אז דווקא נתחיל מהסוף - אני חושב שקודם כל, את הדולרים הספציפיים אני לא אחלוק.
• אני כן יכול להגיד שכדי להגיע מהמקום שאתה מתחיל מאפס למודלים איכותיים, עובדים, זה “מיליוני-דולרים רבים”, בסדר?
•  זה דברים שיש שם איזשהו חסם-כניסה.
• אבל בסוף, ככל שהדברים האלה מתקדמים, כן תהיה את האופציה בדיוק לאנשים לקחת מודל כמו המודל שאנחנו משחררים.
• לעשות עליו אדפטציות (Adaptations), לעשות באמת לא רק “Finetunes פשוטים” אלא לעשות דברים הרבה יותר גדולים ומשמעותיים.
• וגם לדעת שהארכיטקטורה שהם קיבלו היא ארכיטקטורה שיכולה לעבוד - זאת אומרת, הם לא עכשיו “יורים בחשיכה”.
• ברגע שאתה כן עושה את כל הניסויים האלה ומנסה להגיע לאותן רמות, שאתה לא מקבל סתם ככה “מהמדף” מה-Open Source, אז יש הרבה ניסוי וטעייה
• וכמו שאמרנו בהתחלה - הם לוקחים הרבה זמן, על הרבה Compute.
• עכשיו, כשאני אומר “הרבה Compute”, אז גם - זה לא . . . .
• בלי להיכנס למספרים הספציפיים, אנחנו - את רוב האימונים הגדולים שלנו עשינו דווקא על TPUs, שזו החומרה של Google.
• זאת אומרת, השתמשנו הרבה גם ב-GPUs לאימונים קטנים יותר - להכנה של ה-Data, עושים הרבה Captioning של ה-Data כדי שה-Input-ים ללמידה יהיו “נקיים”.
• כי אני אם אתה מביא וידאו ואת התיאור שמישהו כתב - זה בדרך כלל יהיה חצי-קשור למציאות.
• והיום יש מודלים - שוב, דיסקרימינטיביים (Discriminative) בסופו של דבר, אנליטיים - שיכולים לתת Caption מאוד מאוד איכותי.
• וברגע שמסתכלים על האימון “הגדול” - באימון הגדול אתה צריך הרבה מאוד Tera-flops, אתה צריך הרבה מאוד Core-ים.
• זה ברמת המאות של Chip-ים - כשבעצם, לכל Chip יש לא מעט גם Cores פנימיים . . .
• אבל הסדרי-גודל זה “עשרות” לניסויים “קטנים”, “מאות” לניסויים “גדולים".
• ובסוף - זה הכל עניין גם של קצב: ברגע שאתה פורץ את מחסום ה-Scale, אז ככל שאתה נותן לי יותר Chip-ים, אני פשוט מגיע לתוצאות יותר טובות יותר מהר.

(רן) אז יש כמובן את האתגרים הנדסיים, שקצת-קצת הזכרת בהתחלה, אבל לא היה לנו זמן להיכנס אליהם - של איך לנהל Cluster כזה, איך לעשות Redundancy, איך לטפל בשגיאות - כי אתה לא רוצה שברגע שיש שגיאה אחת אתה צריך להתחיל מחדש ימים או אולי שבועות של אימון . . . אתה רוצה להיות מסוגל להתאושש בקלות משגיאות כאלה. ודיברת על זה שלפעמים אתם עושים לתוכנה או לחומרה “יותר ממה שהתכוון המשורר" שתעשו לה - ואז צריך לכתובדברים קצת, “לתפור את הדברים ידנית” כדי שזה יתאים למגבלות הזיכרון ושאר מגבלות החומרה.כל זה שריר ונכון - אבל לא נוכל להיכנס לזה, כי זמננו עוד מעט נגמר . . .
44:02 אז איך מתחילים?(רן) אבל אולי ככה מילה אחרונה - אז ברגע שתשחררו את זה, או שאולי בזמן שאנחנו נפרסם את הפודקאסט כבר שיחררתם את זה [שוחרר! LTXV - The First Real-Time AI Video Generation Open Source Model] - מה בעצם אנחנו - זאת אומרת “ההדיוטות בבית” - יכולים לעשות? זאת אומרת, מורידים את המודל הזה, מוצאים GPU מספיק חזק, וכמו שאמרת לא צריך נורא חזק אבל מוצאים GPU מספיק חזק, שיודע להריץ את זה, ואפשר מה -  פשוט לייצר Video-ים?

• (אופיר) כן, אפשר יהיה לתת לזה פשוט טקסט ב-Prompt - ולקבל וידאו שתואם ל-Prompt.
• אפשר יהיה לתת לזה תמונה בתור ה-Frame הראשון שאתה רוצה וגם איזשהם Directions של לאן ללכת משם. 
• ואפשר יהיה לתת וידאו ולהגיד לו איך לערוך את הוידאו הזה בעצם.

(אורי) אבל אנחנו נצטרך להריץ אותו - אצלנו?

• (אופיר) או בשירות בענן, שיהיו הרבה שירותים שיריצו את זה.

(אורי) כן - אבל זה לא שירות, אתם לא מתכוונים לתת שירות כזה . . .

• (אופיר) לא, אז אנחנו ניתן את זה בתוך המוצר שלנו - איזושהי גרסה, שיהיו בה גם דברים נוספים.
• אבל זה בתוך המוצר של LTX Studio.

(אורי) אבל אם לקחתי את ה-Open Source הזה ואני רוצה עכשיו לשפר אותו ולאמן אותו, אז אני כנראה אצטרךלעשות, כאילו . . . יש איזשהו Barrier to Entry מאוד גדול בכסף, נכון?

• (אופיר) אז אם זה רק אימון של Finetunes ו-LoRAs, כל הדברים שבעצם באים ומוסיפים מעל המודל הזה, אז ה-Barrier הוא לא כזה גדול.
• זאת אומרת, זו המטרה גם בלשחרר מודל כזה לקהילת ה-Open Source - שהם בדיוק יוכלו לעשות את  האימונים האלה.
• שהם יותר קטנים והם ב-Scale הרבה יותר קטן.
• גם מבחינת Data - זאת אומרת, אם אנחנו רואים עשרות-מיליוני Data Points, אנשים עושים Finetunes למודלים עם עשרת-אלפים Data Points . . .

(אורי) כן.
45:57 סיום וגיוסים(רן) אוקיי אז קודם כל תודה על התרומה חזרה לקהילה! אני מקווה שיהנו מזה.וכאן אנחנו מסיימים . . . אולי רק לפני זה, עוד כמה מילים על Lightricks? אז מה - אני מניח שכמו הרבה חברות אחרות, אתם תשמחו לפגוש אנשים . . . .

• (אופיר) כן בוודאי - אנחנו מגייסים ב-Lightricks  כל הזמן, להרבה מאוד משרות.
• ספציפית גם אצלי בקבוצה אנחנו מגייסים חוקרים, גם כדי לעבוד על האתגרים של אימון מודלי-Foundational
• גם לצוותים שעובדים על המוצרים שלנו ועל ממש State of the Art שימוש ב-Generative AI לכל דבר כמעט שאנחנו עושים.
• תמיד עשינו Generative AI, גם לפני שזה היה Buzzword מאוד מאוד גדול - ואנחנו שמים את זה בחזית אצלנו.

(רן) “שמים את ה-”Gen” ב-”GenAI”” . . . [וגם כאן - 417 Developer Growth with Barak Yoresh from Lightricks][והנה המודל והתיעוד וכל מה שאתם צריכים - LTXV - The First Real-Time AI Video Generation Open Source Model]
טוב - אז תודה רבה, אופיר, והצלחה!
 האזנה נעימה ותודה רבה לעופר פורר על התמלול!

[קישור לקובץ mp3]


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

00:52 רן - DSPy, סקרים, Code Assistants Wars ו-Self-Driving code

• (רן) אז אני אתחיל : אחד הדברים שיוצא לי להתעסק בהם בזמן האחרון זה עבודה עם LLM-ים, אולי כמו רבים אחרים.
• ואחד הדברים שעושים בעבודה עם LLM-ים, זה “תופרים Propmt-ים, נכון?
• צריך לוודא שה-Prompt נכון, שהסיומת נכונה, שמבקשים יפה, שעושים Chain of Thoughts, שעושים כל מיני ש*ט כאלה, כדי שהדברים יעבדו - ולפעמים נראה כאילו זה איזשהו Witchcraft שאמור כבר לעבור מהעולם . . . .
• כאילו, למה זה משנה אם אני שם סימן שאלה בסוף המשפט או לא? אם אני שם פסיק או לא? כאילו, הוא אמור להבין אותי, לא?
• אז המציאות היא שלפעמים כן, ולפעמים לא . . . זה כנראה גם תלוי באיכות ה-LLM.
• אבל תמיד חיפשתי איזושהי דרך קצת יותר מתודולוגית, אולי קצת יותר מדעית, לבוא ולייצר Propmt-ים בצורה שהיא פחות “Black Magic” כזה.
• ואז, נתקלתי בכלי - ספרייה - שנקראת DSPy.
• ו-DSPy בעצם מתיימרת לעשות דבר כזה: למעשה, אתה מציב לה מטרה.
• אתה בא ואומר “אני רוצה סוג כזה של Output”
• אתה מגדיר איזושהי פונקציה שבוחנת את האיכות של ה-Output, ומגדיר לה את ה-Input-ים.
• והיא מנסה, על סמך זה, לעשות ניסוי וטעייה - בעצם לטייל באיזשהו גרף של טקסטים שהיא מייצרת, על מנת למצוא את ה-Prompt האידיאלי ל-Use Case שלך.
• אם זה נגיד, הזכרנו Chain of Thoughts, אם זה להגדיר דוגמאות - זאת אומרת, לתת 2-3 דוגמאות, אולי אפילו לתת מקרים שהם “קשים”
• זאת אומרת, למצוא את הדוגמאות המעניינות, כדי לתת.
• ובסופו של דבר, מספקת לך Prompt בצורה שהיא “חצי-אוטומטית”, נקרא לזה, שעושה אופטימיזציה ל-Use Case שלך.
• אז אפשר לחשוב על זה כמו על סוג של בניית Prompt אוטומטי, אם אתה יודע להגדיר את זה כמו שצריך, אם אתה יודע להגדיר את הצרכים שלך כמו שצריך.
• למי שיצא להתעסק בעולם הזה, יכול להיות שהוא מכיר ספריות או כלים אחרים, כמו נגיד, LangChain או LlamaIndex - זה לא אותו דבר. 
• הם דואגים לאספקטים אחרים של הפיתוח.
• ו-DSPy למעשה מתממשק אליהם - זאת אומרת, הם “מכירים אותו”, ואפשר לעבוד איתם ביחד.
• (אלון) אי אפשר להחליף את זה ב-LLM? כלומר, אני נותן ב-LLM את ה-Prompt, ואומר לו “תכתוב Prompt נורמלי” - כותב לי Prompt נורמלי, וזה עובד . . .
• (רן) ומה אתה חושב שהם עושים?
• (אלון) אז מה צריך אותם? . . . .
• (רן) אז כן, בגדול, כאילו, “זה שילוב של כן”
• א', הם משתמשים ב-LLM, זה כן.
• אבל חלק מהאתגר זה לבוא ולמדוד את האיכות של התוצאה - וזה משהו שהם עוזרים בו.
• וגם בלפרמל את הדברים האלה.
• אבל בסופו של דבר, מתחת לפני השטח, כן - הם גם עושים את זה.
• אבל ללכת ולהגיד ל-LLM “תייצר לי Prompt אידיאלי” - הוא אולי ייצר לך משהו, אבל החלק המאתגר ביותר זה לבוא ולעשות איזו אופטימיזציה.
• זאת אומרת, לדעת שהוא באמת אידיאלי, לדעת שלא עשית ממש . . . .  שאין איזשהו שינוי קטן, שיכול לעשות את זה קצת יותר טוב, בקיצור.
• אז זה איזשהו שילוב של באמת עבודה עם LLM-ים והיכולת למדוד את האיכות של התוצאה.
• (דותן) אני רואה שזה של stanfordnlp  . . . 
• (רן) נכון . . . 
• (דותן) אז כאילו, זה הניסיון שלהם להגיד “גם אנחנו בו במשחק”, נכון?
• אני זוכר הספרייה הזאת, של NLP, כבר שנים, שנים אחורה . . .  מה שנקרא “סטנדרט בלתי כתוב”.
• ואני מסתכל ככה גם על הפרויקטים שלהם - נראה שזה הפרויקט הראשון שהוא עוסק ב-LLM.
• אני לא יודע אם אפשר להשליך מזה שזה פרויקט טוב או לא, אבל...
• (רן) אפשר רק להזכיר ש-NLP, לפני הימים של-LLM, היה דיסציפלינה די מוכרת - אבל שיטות אחרות לגמרי. אוקיי?
• לנסות לנתח את המבנה התחברי של המשפט, להבין על מה זה פועל, הטיות וכו’.
• זה לא מה ש-LLM עושים היום. היום ה-LLM עובדים בצורה סטטיסטית לחלוטין, בלי איזשהו ניסיון - או לפחות ניסיון מהותי - לבוא ולהבין מבנה תחברי, או סמנטיקה.
• אפשר אולי להתווכח על זה, אבל זה גישות שונות. NLP זה כאילו “הגישה היותר קלאסית” והדרך שבה ה-LLM-ים עובדים היום זו דרך שונה.
• אז בעצם מה שדותן אומר, זה שהם “הצטרפו לעגלה”, כן? הצטרפו לקהל הרב . . . 
• (דותן) פעם, אם רצית NLP, היית הולך ל-stanfordnlp.
• לא היית יודע בכלל מה זה, היית פשוט הולך לשם.
• (אלון) אני יכול להגיד שבעולם הזה, של “קצת להבין את ה-LLM-ים”, אפילו Datadog הוציאו כלי של LLM Observability,
• שזה קצת להבין איזה Prompt-ים, מה היו התוצאות? מה זו תוצאה טובה? וקצת לעזור . . . 
• הכלי שלהם נראה יותר מרשים, אני חייב להגיד, של Datadog, אבל אני לא יודע מה יותר טוב או פחות טוב.
• לא התעסקתי לא עם זה ולא עם זה.
• (רן) עד כאן . . . 
• (דותן) נתנו חסות?
• (אלון) “אוהבים דאטה?! . . .”
• (רן) ובמעבר חד: התפרסם לא מזמן - וכשאני אומר “לא מזמן”, זה נראה לי משהו כמו חודשיים - הסקר השנתי  של Stack Overflow 2024.
• בעבר היינו סוקרים את הסקרים האלה, זאת אומרת היינו באים ומביאים Highlights - אבל אני חייב להגיד שאני לא יודע מה מעניין שם הפעם . . .
• אז רק רציתי להרים פה, אם במקרה לכם יצא להסתכל על הסקר הזה . . 
• עברתי עליו, כאילו בסדר - ראיתי שם מספרים וזה, אבל אני לא יודע, שום דבר לא תפס שם את עיני.
• שזה אולי האייטם - כאילו זה נראה כאילו זה כבר, אוקיי, “עבר זמנו” . . .
• אבל בכל אופן - יצא לכם לעבור עליו? יצא לכם לראות שם משהו מעניין?
• (דותן) לא . . . 
• (אלון) יצא לי משהו מעניין אחר - יצא לי לראות את כמות המשתמשים ב-Stack Overflow, מאז ש-GPT יצא לראשונה.
• וכמות המשתמשים המשתמשים ירדה באיזה 65 אחוז, אם אני זוכר נכון, בשנתיים האחרונות [ChatGPT is putting Stack Overflow out of business traffic is down over 50%].
• ואז גם כנראה הסקר הזה, זה אנשים שלא משתמשים כל כך בכלים המודרניים - ואז הייתי אומר, לא יודע . . . זה כאילו מראש קהל בעייתי, לא הייתי אומר את זה כל כך.
• (רן) כאילו, בוא נגיד מראש, זה היה סקר של משתמשי Stack Overflow, שזה קהל מוטה באיזשהו אופן.
• אבל אתה אומר שהיום ההטייה היא כבר שונה לחלוטין, אז לא לבנות על תוצאות הסקר.
• כן, בסדר, בקיצור - עשינו @Mention, נמשיך . . .
• נושא אחר, ועדיין קשור מן הסתם ל-LLM-ים, זו כל הזירה הזו של Code Assistants, או “המלחמה” אני קראתי לזה, “The Code Assistants War”.
• אז יש שוק מאוד מאוד פעיל, שאני בטוח שכל מפתח תוכנה מכיר, של כלים להשלמת קוד או לעזרה בקידוד.
• בין אם זה Copilot של GitHub, שהיה בין הראשונים, Tabnine שאפילו היה עוד לפניו - חברה ישראלית - וחדשים, כמו Cursor ו-Codium 
• שדרך אגב - יש שתיים כאלה, אחת מהן ישראלית ושינתה את השם [466 With Itamar from Codium]
• אבל יש עוד ועוד ועוד  . . .  ואלה הבולטים, יש לדעתי עוד עשרות כאלה.
• וגם כל אחד יכול להרים לעצמו אחד פרטי, כזה על הלפטופ כבר, זה לא כזה מסובך . . . 
• העולם הזה די מתפוצץ, החברות - חברות כמו Cursor ו-Codium שהזכרתי - יש להן הערכות שווי במיליארדים גדולים, למיטב זיכרוני.
• זאת אומרת - זה שוק לא קטן.
• ורציתי סתם לפתוח לשיחה של מה אתם חושבים - כאילו, לאן זה ילך? זאת אומרת, איך אתם רואים את העתיד של עולם ה-Code Assistants?
• (אלון) קודם כל, אני חושב שהערכות-שווי שלהם הן מה-זה מגזמות, כי בסוף תיהיה קונסולידציה (Consolidation) ובחיאת ראבאק - הם לא יוצאו על אותו כלי כל כך הרבה כסף . . . זה הראשון.
• דבר שני, אני יכול להגיד ש-VS Code, למשל, הוא לאט לאט נהיה Cursor  . . .
• כאילו, הם מתחילים להעתיק פיצ'רים, ואני לא יודע עוד חצי שנה, איזה יתרון יהיה ל-Cursor, ולמה לא להשתמש ב-VS Code.
• בטח שיש לו גם את כל המודלים “המתוחכמים” - עכשיו גם הוסיפו את Claude, ואתה יכול לגרות קבצים, ולשאול אותו על ה-Context . . . 
• ואני לא רואה יתרון . . . יש עדיין יתרון ל-Cursor, אבל זה לא נראה לי משהו שיחזיק לנצח.
• בסוף, בוא נתחיל מזה - הם מבוססים על VS Code, אז כן, זה לא בעיה לעשות את הכיוון ההפוך גם.
• (רן) כן, בדרך כלל, זה מעניין שרוב ה-Assistants מתלבשים על IDEs קיימים, כמו VS Code, או ה-IntelliJ או vim, או אחרים.
• ו-Cursor בחרו לפתח “IDE משלהם” - ואני עושה כזה “גרשיים”, אני עושה “מרכאות באוויר”, כי למעשה, גם ה-IDE שהם פיתחו כמובן מבוסס על VS Code . . . 
• זאת אומרת, הם לא פיתחו את זה מאפס - זה נראה די דומה, הם רק החליטו לשים את הפאנלים ולסדר אותם קצת אחרת, אבל די ברור לכולם שזה VS Code מתחת.
• אבל כן, הם הלכו על איזושהי אסטרטגיה של שיווק, שבה יש להם את ה-IDE משלהם, זאת אומרת, הם הפלטפורמה.
• אבל כמו שאתה אומר, אלון - תכל’ס, התוצאה היא די דומה.
• כאילו אולי Cursor - היה להם איזשהו יתרון לתקופה, אבל אני רואה את כולם סוגרים את הפער.
• ל-GitHub גם היה פעם יתרון - וגם אחרים סגרו את הפער, כלומר, זה משחק שכל הזמן קורה.
• (דותן) נראה לי שיש פה שתי שאלות . . . .
• אחת זה “מי מכל ה-Editors האלה יהיה  “ה-Editors המוביל”
• ובלי קשר לזה, יש פה המון “ללמוד מההיסטוריה” - אני מרגיש שכל התשובות נמצאות כבר, כאילו. “ההיסטוריה חוזרת על עצמה”.
• ונראה לי שפה מי שינצח, זה מי שיש לו את הפלטפורמת-הפצה, 
• פשוט ככה, כמו עם ה-Browser-ים . . .
• (אלון) אמרת הרבה בשביל להגיד “Microsoft” . . . .
• (דותן) לא יודע. . . . אולי זה Microsoft, יכול להיות שזה Microsoft, בסיכוי מאוד מאוד גבוה.
• אבל יש פה הרבה התפלפלויות . . . 
• היה גם איזשהו Editor שעשה Fork, זה קבוצה של אנשים שעשתה Fork - וככה הם הקימו חברה, עשתה פורק של Editor קיים.
• והקהילה כזה “נכנסה בהם” והם נעלמו, אני לא זוכר בדיוק מי אלה.
• אבל בסוף, כמו כל דבר, הפלטפורמת הפצה תנצח.
• השאלה השנייה זה “איך ייראה העולם הזה?” - ש”יש לי Editor ש-AI כותב לי את הכל”.
• גם פה נראה לי שזה איפשהו בהיסטוריה, האמת שעוד לא נכנסתי לזה לעומק במחשבה.
• אבל פילוסופית, זה צריך להיות איפשהו להסתכל על המאמצים של Microsoft עם IntelliSense, ומה IntelliSense עשה . . . . IntelliSense, כשזה יצא, זה היה “ביג דיל”.
• היו גם כל מיני חברות של “AI של פעם”, שכתבו טסטים אוטומטית - מה קרה איתם ואיך זה עבד?
• ו-Refactoring - כל מיני כאלה שעשו תוספים של Refactoring של קוד, ואיך זה עבד להם וכמה השתמשו בזה?
• כאילו, איפשהו זה שילוב של הכל, ולא יודע . . . בינתיים אני יודע שיש Sweet-Spot-ים שאני משתמש
• כל מה שקשור לטסטים עובד טוב,
• “שכתב לי את הקוד הזה בצורה יותר טובה - תן לי לראות מה אתה חושב” - גם עבד לי טוב. 
• “תכתוב לי קוד” - נפלתי לא מעט פעמים, שלקחתי קוד שהוא כתב לי, ופשוט הבאגים שהיו הם היו כל כך עדינים, שפשוט בלמצוא ולתקן הפסדתי את כל הזמן שהרווחתי, פשוט ככה.
• זה בטח ישתפר, אבל כרגע זה מה שאני ראיתי.
• (אלון) ומן סתם ל-Boilerplates גם - אחת השיטות זה לתת לו לכתוב קוד, לכתוב טסטים, או להגיד לו “זה ה-Output” - ואז הוא מתקן את עצמו,
• כאילו, לעשות את איטרטיבי.
• (דותן) כן, אז אני זורק לו את ה-Error ונותן לו להתמודד עם מה שהוא יצר, כאילו . . . 
• (אלון) כן, אנחנו עדיין סתם בלופ כדי לתת לו את ה-Error-ים - כאילו, ועוד מעט הם יעשו את זה לבד . . .
• זה כמו השיחות שלי עם ה-Support ב-Amazon - אני כאילו פותח את ה-ChatGPT, ואני . . . 
• שני ה-ChatGPT מדברים אחד עם השני, אני סתם עושה Copy-Paste-ים . . .  זה ממש מטומם.
• (רן) כן, יפה - אז בדיוק בשביל זה הבאתי את הבלוג הבא: אז בחור בשם Graham Neubig, וזה האייטם הבא שלי, בא ועשה איזשהו . . . ניסה לקחת איזשהו מבט-על העולם הזה, של כלים לכתיבה של קוד - AI Enhanced Software engineering - והשווה אותם לעולם של Self-Driving Cars, אוקיי?
• הוא בא ואמר “אוקיי, בעולם של מכוניות אוטונומיות, כבר הוגדרו חמש רמות:
• רמה הראשונה זה . . . זאת אומרת רמה אפס אולי זה אפס אוטומציה
•  רמה מספר אחת זה נקרא Driver Assistance - או במילים שלנו זה Code Completion, אוקיי? שזה פחות או יותר רוב הכלים שיש לנו היום, כל מיני “סייענים” אבל לא יותר מזה.
• רמה שנייה נקראת Partial Automation - אז נגיד ששם הוא שם את Tesla Autopilot, ובעולם של Code Completions, נגיד Copilot או Chat Refactoring
• זאת אומרת שאפשר לעשות צ'אט ולעשות Refactor באמצעות זה לקוד.
• ויש את זה גם ב- Cursor ואני חושב שיש את זה גם לכלים אחרים, דיברנו על זה שכולם משלימים את הפיצ'רים אחד של השני, אז זה קיים.
• ברמה השלישית הוא שם את Conditional Automation. דרך אגב, אני לא חושב שזו הגדרה שלו, זו הגדרה די סטנדרטית - ובעולם של Self-Driving Cars זה נגיד מוצר של Mercedes-Benz שנקרא DRIVE PILOT.
• שאני לא מכיר אישית, אבל אני מניח שהוא עושה קצת יותר מ-Autopilot של Tesla.
• בעולם של Software Development, הוא מזכיר כלים כמו Diffblue Test Generation, וטכניקה שנקראת TransCoder for code porting
• שלי לא יצא לעבוד עם אף אחד מהם, אבל אני מניח ש-Diffblue, לפי השם, מייצר טסטים בצורה אוטומטית, קצת דומה למה שדותן ואלון הזכרתם מקודם.
• אבל כנראה שיש שם רמת אוטומציה עוד יותר גבוהה.
• ברמה הרביעית, יש מה שנקרא High Automation, שלמעשה ברכבים אוטונומיים זה נהיגת . . . נקרא זה “Cruise Control על סטרואידים”.
• זאת אומרת  רכב שיודע להגיע מנקודה א' לנקודה ב', בלי עזרה של בני אדם.
• בגדול זה Self-Driving Cars . . . אולי בלי החוכמה של מעבר, אולי כאילו בלי “חוכמת-הכביש” שמעבר, אולי בלי טיפול במצבי קיצון, אבל זה בגדול די Self-Driving Cars.
• ובעולם של פיתוח תוכנה, זה כלים שהוא מזכיר, כמו Devin, שיצא לי קצת להסתכל עליו, Devin או, OpenDevin
• שלמעשה זה Agents שאתה אומר להם “אני רוצה לייצר אפליקציית iPhone” או “אני רוצה לייצר אתר, שעושה ככה וככה”
• והוא עושה לך את זה, אוקיי?
• האם הוא עושה את זה טוב? האם האיכות גבוהה? זה עדיין לחלוטין נתון לויכוח, אבל אתה לא כותב שורות קוד שם, זאת אומרת - אתה רק מתאר Spec.
• אתה רק בא ואומר לו “אני רוצה את התוצאה הזאת - תייצר אותה”. זה כמו להגיע מנקודה א' לנקודה ב', במכונית, אוקיי?
• רמה חמישית של אוטומציה מלאה - פה אין לו דוגמאות, אני לא יודע מה הן הדוגמאות, אולי אנחנו עוד לא שם - אבל בכל אופן, אני חשב שזה נחמד.
• זאת אומרת, הבלוג הזה נחמד. Graham Neubig הוא Computer Scientist ב-CMU, זאת אומרת לא אוניברסיטה קטנה.
• והוא גם עובד בחברה שמייצרת כלים כאלה, אז אני מניח שהוא חושב על הנושא הזה לא מעט.
• וזהו, חשבתי שזה מעניין לבוא ולהשוות את עולם המכוניות האוטונומיות לעולם פיתוח התוכנה, ולשים אותם ככה, אחד מול השני.
• ובאותה הזדמנות גם להכיר את הכלים השונים במערכה הזאת.
• זהו, אז קריאה קלילה, זה לא מאוד ארוך - מוזמנים, נשים לינקים כמובן.
• (דותן) נראה שהזווית של המאמר זה בעצם להגיע בסוף ל-OpenDevin, שעכשיו נקרא OpenHands, ששייך ל-All Hands . . .
• (רן) כן, שזו החברה שבה הוא עובד . . . 
• (דותן) כן . . . 
• (רן) הוא בעצם רוצה לבוא ולהגיד “אוקיי, אנחנו ברמה הכי גבוהה, כל השאר שחקנים קטנים” . . . בסדר, אתה יודע, יכול להיות שזאת הזווית שלו . . . 
• אבל זו סקירה מעניינת של השוק ופרספקטיבה נכונה, אני חושב.
• (דותן) כן, תראה, זה Open Source - אני רואה שיש פה איזשהו Docker שאתה יכול להריץ.
• אתה מריץ, מופיע לך כזה ב-Local Host - ונראה לי שאחרי זה אני אנסה את זה קצת
• כאילו, ניתן לזה לכתוב משהו, בסוף זה המבחן, הרי, נכון?
• אפשר להמשיך להגיד שזה עובד ו”עובדים עם זה”, ו-”AI כותב את כל הקוד” וכו'.
• בסוף, אתה מריץ את ה-Docker הזה, אומר לו “אתה עושה לי אפליקציה של  . . . “ - לא יודע מה, Pomodoro.
• ואתה נוגע בזה ורואה . . .  כאילו, ה-Bottom-Line זה מה שחשוב.
• (רן) כן. דרך אגב, אני לא ניסיתי, אבל נראה לי שלייצר . . . פעם ראשונה זה סבבה, לבוא ולהוסיף פיצ'רים ולתקן באגים - זה כבר דורש קצת יותר מעורבות טכנית.
• ופה אני בספק עד כמה באמת זה יעבוד.
• אבל שווה לנסות!
• טוב, עד כאן LLM-ים, מודלי-שפה, Code Completions וכו’ - ונעבור אליך, דותן! יצא לך לעבוד על איזשהו Framework קטן בזמן האחרון . . . 

18:53 דותן - [loco.rs] This section is LLM-Free

• (דותן) כן, האמת שכל האייטמים שלי הם נטולי-LLM [כמעט פלינדרום], או “LLM-Free”, אז כל מי שבשוחות . . . 
• (אלון) אפשר לתייג את זה  . . . “This Section is LLM Free”
• (רן) “ מכיל LLM בכמות גבוהה” . . . .
• (דותן) “No-AI”, כאילו זה משהו זה ללא גלוטן . . . בקיצור, כן - אני בשוחות, חופר את הבוץ.
• אתם שם למעלה, במגדל של ה-AI . . . 
• וזה מיועד לאנשים שהם נגד AI.
• בקיצור, אז יש לי מסע, שקצת מתועד פה בפודקאסט, אני מניח . . .
• שבאיזשהו שלב - גם אלון היה איתי במסע הזה - באיזשהו שלב עזבתי את Rails ואת Ruby והבית החם הזה.
• שאני חייב להגיד שעם Rails ו-Ruby ממש הרגיש כזה כמו בית - אתה יכול לבנות הכל פשוט, כל דבר אתה מתרגם לסדרת פקודות של Rails - Rails New, scaffold זה, scaffold זה . . . - בום! יש לך אפליקציה חיה ועובדת.
• ופה מדובר על 20 שנה אחורה - היום אתה יכול לראות את זה בדמות אנשים שכאילו עושים פוסטים על AI - “תראו, אמרתי ל-AI מה לעשות, והוא ייצר לי אפליקציה!”
• סוג של אותה חוויה - אתה בא עם רעיון ואנרגיה, ויוצא לך משהו.
• אז איפשהו, באיזשהו שלב, עזבתי את העולם של Ruby - עברתי ל-Go, עברתי ל-Kotlin, כל מיני מקומות שביקרתי בהם.
• אבל בסופו של דבר, תמיד רציתי את החוויה הזאת . . .
• איפשהו השתקעתי ב-Node.js לתקופה, תקופה יחסית ארוכה.
• ובניתי Framework שהוא תואם Rails ב-Node.js -
• ו-Production, הכל, זה עובד סבבה - יש כמה אפליקציות שרצות על זה, אנשים משתמשים בזה וכו',
• אבל ראיתי שכ-Maintainer, אני פשוט לא יכול לחיות . . .  זאת אומרת שאחד הדברים ב-Open Source, זה שכשאתה רוצה לשים את הפרויקט שלך Online, מידי פעם לבוא ולא יודע, להוסיף דברים שאתה רוצה להוסיף בכיף.
• כי בסוף, אם אתה לא נהנה מזה, וזה Open Source בזמן החופשי שלך, אז זה פשוט לא יעבוד.
• וראיתי שבאמת . . .  קודם כל, לקח לי זמן להבין למה אני מרגיש רע עם זה כל הזמן.
• כל פעם שאני רוצה לבוא לתקן משהו שמישהו כותב משהו, זה פשוט הופך להיות סיוט של לפתוח את הפרויקט - ופיתחתי “רפלקס אנטי” כזה.
• לא בא לי לפתוח, לא בא לי לעשות Pull, לא בא לי לעשות Clone.
• וזאת הייתה תחושה שהקיפה אותי עם הפרויקט, שהוא ה-Clone של Rails ב-Node.js.
• ובסוף החלטתי רגע לקחת צעד ולהבין למה יש לי את התחושה הזאת, הסתכלו פנימית כזאת - והבנתי שפשוט כל פעם יש איזשהו “טקס של שבירה”
• אני מוריד את הפרויקט אליי - וזה הפרויקט שלי, זו האירוניה - אני עושה איזשהו npm install, whatever, עם כל הכלים הכי חדשים והמודרניים,
• ואני מבלה שעתיים של להבין למה ספרייה נשברה, ולמה סביבה דפוקה, ולמה אני לא יכול לשחזר פה, ולא יכול לשחזר שם . . . 
• (רן) Don't get me started on Python  . . . 
• (אלון) כן, כן . . . והאמת שאתה יודע מה? ב-Python - 
• (רן) . . . עוד יותר גרוע . . . .
• (דותן) . . . התסכול זהה, אבל אני חושב ש-Node.js הפך . . . 
• (אלון) תסכול כפול . . . 
• (דותן) לא, לא . . . אני חושב שלפחות מה שאני התעסקתי, שה-Framework הזה זה “Framework שלוקח”
• הוא שואב ספריות, מלא ספריות . . . .
• באמת מה ששמתי זה זה Full Stack לגמרי, כולל Authentication, כולל הכל, ממש הכל.
• אז כמות ה-Dependencies שהייתה לי היא משוגעת - וגם “ Dependencies Shady” כאלה, למשל Express.js, שלא עודכן שנים על גבי שנים, רק עכשיו הם הוציאו גרסה . . . 
• וכל מיני ספריות אותנטיקציה (Authentication) שוואלה - לפני 6-7 שנים היית אומר “זה הפרארי”, והיום זה פשוט סיוט של Memory Leaks וכל מיני קשקושים כאלה.
• ובאיזשהו שלב אמרתי “טוב, אני לא יכול, אני חייב פתרון - אני חוזר ל-Rails!”
• כאילו אני חוזר ל-Rails - כי כשיש לך רעיון ואתה רוצה להוציא אותו לפועל, אתה לא יכול שיש לך משהו שיעצור אותך.
• אתה רוצה את “החלק” הזה בדרך לבנייה.
• אז חקרתי על Rails - ואז איפשהו השתלבו לי העולמות: אני בא מ-Rust עכשיו, כל דבר שאני עושה זה Rust, ואני אומר את זה בכיף ובגאווה.
• ואמרתי, אוקיי - בוא נעשה רעיון משוגע: בוא ננסה, נתחיל, Baby Steps: 
• אני אקח את ה-Framework ב-JavaScript הזה
• אני אסתכל כאילו, מה עבד שם
• ואני אתחיל לעשות איזה Porting ל-Rust, ממש Porting.
• ומה שנקרא “לפני ששמתי לב” - אני כבר מסתכל על Framework ש”מנגן לי יפה בידיים”.
• עיקר הבעיה הייתה למצוא ה-RM טוב - ברגע שמצאתי אחד כזה, שהוא מאוד מאוד Rails-י, הכל התחבר.
• והיום יש Framework שהוא כבר עובד, שהוא Clone של Rails ב-Rust - נקרא Loco-RS, מלשון Locomotive.
• והוא עובד פצצה!
• אני יכול להגיד שהמבחן האמיתי זה הכיף - לבוא ולהוריד אותו ולעבוד עליו - זה פשוט תענוג צרוף.
• אין לי שבירה של תלויות, אין לי שבירה של כלים.
• כל פעם שאני רוצה להוסיף פיצ'ר, אני עושה Clone
• ו-Rust עוזר בזה, “Rust שומר עליי” - כי ה-Compiler מאוד מאוד חזק.
• הרמת-ביטחון שלי בלהוסיף פיצ'ר ל-Framework כזה מורכב היא אחת הגבוהות שהייתה לי בקריירה בכלל.
• כאילו, בכל השפות שהתעסקתי,
• וזה פשוט תענוג לעבוד על זה.
• וזה עובד - אנשים משתמשים בזה, מתלהבים מזה, זה ברמה של Rails עד כדי “חמש דקות - ואתה כותב בלוג”.
• עם Generators, עם כל ה-Magic.
• עם scaffold מלא של Full REST API, וגם Full Stack - גם מייצר UI והכל.
• וזה 100% תודות ל-Rust.
• כאילו, קצת מהניסיון שהבאתי והזה . . . .
• אבל מלא מלא מלא הולך לספריות הסופר-יציבות של Rust, זה פשוט כיף.
• אז אני ממליץ למי ש...
• (רן) כן, אני הייתי בטוח שאתה קורא לזה Loco - כי אתה משוגע . . .
• (דותן) לא, האמת זה יצא ככה . . . . זה יצא ככה. זה באמת שילוב משוגע.
• אבל תשמע - יש בזה חוויה. 
• כאילו זה “קפה” כזה - זה קצת מר, זאת אומרת, זה לא Rails, שאתה עושה Rails New ואז יש לך אפליקציה ואתה מרים אותה בשנייה, כן?
• אז אתה עושה Loco New - יש לך אפליקציה בפחות משנייה - כי זה Rust, הוא מייצר קבצים בצורה מטורפת.

• ואז בסדר, ה-Loco Start ייקח לך משהו כמו חצי דקה עד שהוא מקמפל (Compile) את הכל,
• ואז כל קימפול נוסף זה ברמה של שניות.

• אז זה הטיפה מר בפה - אבל החצי דקה הזאת, או השניות האלה - לקבל פרויקט שבאמת יש בו אפס באגים
• פשוט ככה - כל הבאגים המוזרים של Dynamically Typed Languages וכאלה
• אפס באגים, אין לי באגים - כאילו אני אומר את זה לא בשחצנות, פשוט אין באגים, פשוט ככה. [הקומיטים שלי טובים].
• עזוב באגים של לוגיקה, כן? אין לך את “הש*ט הלא צפוי” - אין, אפס.
• וזה פשוט מטורף.
• עכשיו, אחרי כל זה, אתה בונה את האפליקציה שלך - אתה מקבל Binary בגודל של איזה 20-30 מגה, כשהכל “אפוי” בפנים.
• אתה לוקח ואתה עושה Copy ל-Binary הזה - כאילו חוויית Go.
• אבל מה שלא חוויית Go זה שהדבר הזה תופס 6 מגה בזיכרון - ונותן לך, בבדיקה האחרונה שעשיתי, 50 אלף Request-ים לשנייה, כולל קריאות ל-Database.
• ו-200-300 Request-ים לשנייה בלי Database
• 500 אלף, כאלה מספרים.
• אז אתה יכול על Raspberry Pi לעשות מה שאתה עושה על שרתי-ענק,
• ו-Go לא נותן את התוצאות האלה פה.
• (רן) אפשר להתקין את זה על השעון שלי . . . 
• (דותן) כן . . .
• (רן) ולשרת משם את ה-Spotify . . . .
• (רן) כן, אז אתה מצטנע - התחלת לפני שנה ומשהו, כן? והיום יש לך 5.3K סטארים, 225 Fork-ים, ו-Contributors יש כמה?  80 ומשהו . . .  זאת אומרת פרויקט גדול, גדול בכל קנה-מידה.
• (דותן) כן, אני לא מסתכל על הסטארים - אני מסתכל על החוויות הקטנות האלה. 
• למשל, כשבאתי ובניתי . . . יש שם איזה Background-Jobs Framework, מה שב-Rails לקח הרבה זמן להתבשל.
• אז אמרתי תשמע, “אני גונב את כל זה . . .  כאילו, את כל הלמידה אני גונב”.
• ואני בונה בעצמי Background-Jobs Framework.
• אז זה, מטעמי נקרא לזה “קמצנות” - הלכתי ובניתי כזה דבר
• לקחתי אחד ל-Redis, כמו מה שמי שמכיר sidekiq, ובניתי אחד ל-postgres, קטצ’יק כזה.
• ואמרתי “אין לי כוח לבנות ל-SQLite” -  אני לא תומך ב-SQLite, אני לא חושב שזה - מטעמי קמצנות - אני חושב שזה יהיה מאמץ מיותר. 
• ולפני כמה ימים בא מישהו, והוסיף אימפלמטציה (Implementation) ל-SQLite, של Background-Jobs Processing Framework.
• מה שכאילו, בעולם המקביל, ב-Rails או ב-Node.js, זה כאילו “טקס” - מישהו בא ובונה, ונזילות זיכרון, במיוחד בדברים האלה, ולוקח זמן עד שזה יציב . . . 
• והדבר הזה פשוט “ברזל” - הבן אדם בא עם ניסיון, מכיר את הנושא, נותן אימפלמטציה
• כל מה שנשאר לי זה לעשות Merge - וזהו.
• אז זה החוויות שאני אומר “וואלה, זה עובד”.
• כאילו, כשיש את האינטראקציות האלה, זה באמת כיף.
• (רן) יפה, אז תתחדש על ה-Framework החדש שלך.
• (דותן) כן - ואני ממליץ: מי שרוצה לעשות Rust, אז עבדתי קשה כדי שלא תפגשו את ה-Borrow Checker . . 
• שלא יהיו לכם בעיות של Lifetimes.
• כי בעצם, Request מתחיל, הוא לוקח Data, אתה משחק עם ה-Data - וה-Data הולך לפח בסוף  ה-Request.
• לא מחזיקים שום דבר באוויר, ככה שאין לך בעיות של “יש לי Pointer לפה, Pointer לפה, ועכשיו אני צריך לדבר עם ה-Compiler”.
• אז כל מה שנשאר זה רק לריב עם ה-Syntax, מה ש... זה ה-Friction היחיד, לדעתי.
• זהו  . . . 
• (רן) מגניב . . . אוקיי. אז loco.rs, חפשו ותיהנו.
• (דותן) כן, וזה “Framework לקמצנים”, אני חייב להגיד . . . זו גם אחת מהמוטיבציות: אתה יכול להרים Business ב... לא יודע מה, $10 לחודש באיזשהו שרת-פח כזה, ב-Hetzner או Whatever, ולקבל “1000% החזר” על ההשקעה.
• (רן) כן, למרות שצריך - כדי להשתמש נורמלי - צריך להכיר Rust, כן?
• (דותן) כן, צריך. אבל כן - אני לוקח איזה... העולם איתי! העולם בסוף יתכנס לשם, לדעתי.
• (אלון) כן . . . עם שפה, זה דבר הרבה יותר קטן, כאילו, אם הקשבת לעצמך, עם כל ה-LLM-ים, אז אני חושב שהיום זה הרבה יותר קל.
• כי אתה לא יודע איך עושים משהו? אתה מקבל את ה-Boilerplate, ואז אתה מתחיל לשנות.
• זה לא כמו פעם להתחיל “איך אני . . . “
• כאילו, הוא נותן לך את ה-Template הראשוני, ויאללה - אתה מתחיל, יותר קל להתחיל לעבוד על זה.
• (דותן) זהו, אז יש הרבה דברים גם מעניינים שאנחנו עושים שם.
• למשל, אני אתן סתם דוגמה, סתם להצית את הדמיון, לא קשור ל-Framework - כל מיני ספריות-צד שנולדו.
• אז אחת הספריות, או איזשהו Framework קטן, שבא ואומר, רגע - אם יש לי אפליקציה שאני רוצה להתקין, נגיד Rails
• ועכשיו אתה רוצה להתקין Rails, ולבחור Database כזה, ולבחור Background Job כזה, וכל מיני אופציות, במהלך ההתקנה של הספרייה, של ה-Framework או Whatever.
• אז אני צריך לעשות טסטים לדבר הזה, ליצירה של אפליקציה - אני צריך לעשות טסטים עם Database postgres, עם SQLite, עם MySQL . . . 
• ואז אני צריך לעשות טסטים . . .  רגע, הבן אדם רצה API, או רצה SaaS, או רצה אותנטיקציה (Authentication) או לא רצה אותנטיקציה . . . 
• מלא מלא מלא שילובים, של כל מיני קומבינציות של אפליקציה שאתה רוצה לייצר כסטארטר, Starter-App כזה.
• אז מה שעשינו, זה בנינו Framework, שעושה Fuzzing לזה: לוקח את כל הפרמטרים שיש, לוקח את כל הקומבינציות, סוג של prop.test כזה.
• ומייצר שעות על גבי שעות, את כל הקומבינציות של כל האפליקציה - כשבסוף כל Generation של App חדש, הוא מריץ Suite של טסטים.
• הטסטים יוצרו על ידי LLM - כאילו, השתמשנו קצת כדי להרחיב את הדמיון, מה שנקרא.
• אבל ה-Fuzzing הוא Fuzzing סטנדרטי כזה.
• למשל, עשינו אפליקציה עם אימוג'י, בתור השם של האפליקציה - וזה שבר לא מעט דברים.
• כל מיני קשקושים כאלה . . . 
• אז זה עם Rust גם עובד ממש טוב - כי קודם כל הספרייה היא  Statically Typed, היא גם באה מעולם של ML, אז יש שם אנשים שאוהבים את התחום של prop.test וכאלה.
• אז זה ככה התלבש “כמו כפפה ליד”.
• זהו.
• (רן) אוקיי, אחלה, תודה! זהו, הבא בתור!

31:49 עוד דותן - gitbutler, openobserve, 100-exercises-to-learn-rust,PDF ל-Markdown, Rust based editor, shadcn/ui

• (דותן) הבא בתור - אז יש את סקוט שקון, או צ'קון [Scott Chacon] - מי שבנה, נדמה לי שהוא בנה, את libgit, היה אחד מהשפיצים ב-GitHub, אני חושב שהוא כתב את הספר של git - הספר - אני מדבר מהזיכרון.
• באיזשהו שלב הוא יצא כזה הצידה, מעולם היזמות, לבנות אפליקציה שהיא Desktop App ל-git.
• קוראים לזה gitbutler וזה Open Source.
• זה אחלה Codebase לקרוא - וגם אחלה אפליקציה להשתמש, אם מישהו אוהב UI מעל ה-git שלו.
• ו...יפה.
• (אלון) מי אוהב UI מעל ה-git שלו? אנשים לא אומרים את זה בקול רם . . . 
• (דותן) נכון, צריך להגיד את זה יותר! אנשים שאוהבים UI מעל ה-git שלהם.
• אז זו אפליקציה ממש נחמדה, כתובה ב...Rust! 
• זאת אומרת, יש Framework שנקרא tauri, מבוסס Rust ו-JavaScript וכל מה שצריך.
• זה אחלה דרך לראות מה אפשר להשיג ואיך אפשר לכתוב Desktop App, היום בימינו, Cross-Platform.
• כשאתה עושה את ה-JavaScript שלך והכל, אבל כל ה-Backend Functions, כל הדיבור עם מערכת ההפעלה, מתבצע ב-Rust.
• וזה אחלה פתרון.
• הדבר הבא - פרויקט שנקרא openobserve
• יש איזשהו Track כזה, איזשהו Journey של Tracing ו-Open Tracing וכל מיני מאמצים של Log-ים ו-Tracing ומטריקות (Metrics).
• וזה אותו דבר? זה לא אותו דבר? זה שרת לזה, שרת לזה . . . ויוניפיקציה (Unification) וסטנדרטים וכו' 
• אני כבר לא עוקב אחרי כל הסיפור - OpenTelemetry, OpenTracing - כבר לא זוכר ולא עוקב.
• אבל יש פה איזשהו פרויקט שבא לתת פתרון, שהוא Low Cost - High Performance ל-Elastic.
• לפי מה שהם כותבים, זה, איך נגיד, פי 140 פחות Storage [140x lower storage cost,], או ב-140 פעמים פחות Storage מ-Elasticsearch.
• ומי שיודע ומכיר, אז במטריקות, Log-ים וכאלה, הנתון הזה הוא סופר-סופר-חשוב, ה-Storage.
• זה  high performance,  petabyte scale, אלטרנטיבה ל-Datadog, ל-Elastic וכו’
•  הכל בשרת אחד, כזה Single Binary.
• והפתעה - כתוב ב-Rust!
• (רן) זו הפתעת היום . . . 
• (אלון) בשרת אחד . . . כאילו, הוא יודע לעבוד גם כמה? 
• כאילו, מתישהו הוא ימות, ממקום או מביצועים או ממשהו . . . 
• (דותן) יש לו Clustering ו-High Availability . . . .
• לא שאני פרשתי אותו, אבל זה למשל פרויקט שאני אומר “אה, לא יכול להיות . . . .”
• “לא יכול להיות שזה כפול 140!”
• נכנס, קורא את הקוד - ואז אומר “אוקיי, הבנתי”.
• קודם כל, הרבה מזה זה חוק 80-20 - 80 אחוז מזה זה פשוט Rust . . . 
• ואחרי זה אני מתחיל לקרוא את הקוד, אני רואה את ה-Design, אני רואה מה הם עשו.
• ואני אומר “אוקיי, אני נוטה להאמין לזה” . . . ככה אני בונה את הביטחון שלי.
• זה נטו לקריאה של קוד ולמידה בשבילי.
• אז זה מי שרוצה לנסות, נראה לי שזה, לפחות מה שאני קראתי ובדקתי מהקוד, זה אחלה פרויקט.
• פרויקט הבא - יש פה את mainmatter, שהיא חברה כזאת, “חברת למידה” נקרא לה, חברה שמייצרת חומרי -למידה, שיצרה פרויקט שנקרא 100-exercises-to-learn-rust.
• 100 תרגילים כאלה, וזה אחלה דבר.
• מי שאוהב לבוא ולפצח גרעינים כזה - זה אחלה אחלה פרויקט, למי שרוצה לנסות.
• לא נראה לי שיש פה מה להפסיד, זה קליל, זה נחמד.
• אז זה זה.
• ונכון שהבטחתי בלי LLM-ים, אבל יש פה איזשהו משהו שחיפשתי הרבה זמן, וזה PDF ל-Markdown.
• לקחת PDF, ולהפוך אותו ל-Markdown עם מודל שפה כזה.
• זה וואו . . . . לא יודע למה, אבל להתעסק עם PDF-ים בשבילי זה וואו, וזה עובד מטורף.
• (רן) אני יכול להרחיב - מי שמכיר HTML חושב לעצמו “אוקיי, מה הבעיה? יש Title-ים, יש Header-ים, יש מבנה, יש טבלה, אפשר להבין מה קורה גם בתוך PDF.
• אבל האמת העצובה היא שלא, ב-PDF זה לא ככה. ב-PDF זה בלגן אחד גדול.
• ה-Title-ים הם בהרבה מקרים לא לוגיים, זה פשוט פונט יותר גדול.
• הטבלאות - יש עשר דרכים שונות לייצר טבלאות . . . 
• בסופו של דבר, פשוט לקרוא את ה-Source Code של PDF זה אומנם אפשרי - אבל זה לא תמיד נותן לך את הערך, זה לא תמיד בנוי לוגית נכון, כמו ש-HTML . . . 
• זאת אומרת, לא שתמיד HTML כמובן בנוי נכון, אבל יותר נכון.
• אז אי אפשר פשוט לקרוא את ה-Source, והרבה פעמים מה שאתה נאלץ לעשות, זה פשוט להפעיל מודל Vision על ה-PDF, כדי להבין מה באמת . . . איך זה באמת אמור להיראות.
• עד כמה מגוחך שזה נשמע . . . 
• יש לך טקסט כ-Input, ובסוף תצטרך, צריך לעשות Render ולראות מה יצא.
• אבל כן - זה מה שהרבה פעמים עושים, ובגלל זה זה וואו.
• עכשיו, דרך אגב, למה Markdown? כי Markdown זה די סטנדרטי, ו-LLM-ים עובדים מאוד יפה עם Markdown.
• זאת אומרת, אתה יכול לקחת אחר כך את ה-Markdown הזה, ולדחוף את זה לתוך-LLM - ואז “הם” בדרך כלל יבינו הרבה יותר טוב.
• (דותן) כן. גם הפרויקט הזה עובד ככה - מעבירים ל-Image ומה-Image “זורמים”.
• אגב, יש דמו, שאפשר להעלות קובץ
• תיזהרו עם קבצים! עם טבלאות שאתם לא רוצים שיהיו . . .
• אבל אתם יכולים להעלות, כדי לאתגר את העניין, מערכת שעות של גן או משהו כזה - ולראות מה יקרה.
• אז זה ממש נחמד.
• (אלון) אין סיכוי שהוא אוכל מערכת שעות של גן . . . . כאילו, גם בנאדם לא מצליח . . . .  לא, אין סיכוי.
• (דותן) יש עולם של סטנדרטים, יש עולם של סטנדרטים שבורים - ויש מערכת שעות של גן.
• זה באמת מאתגר כל...
• (רן) אבל מה שכן, הייתה לי כן חוויה טובה - לאו דווקא מערכת שעות של גן, אבל נגיד כל מיני דוחות של בנקים
• נגיד שהם בעברית, ואני צריך לתרגם לאנגלית, לאיזשהו צורך.
• עכשיו, זה לא כזה מסובך, כן? אתה יכול ללכת ולתרגם, זה פשוט מלא מלא עבודה, מספרים וזה.
• אני זורק את זה - ניסיתי את Claude, ניסיתי את ChatGPT - אחרי כמה תפירות קלות של Prompt יוצא פשוט מדהים.
• מתרגם מנגיד עברית לאנגלית - אפס טעויות, כולל לשמור את הטבלאות איפה שצריך, כאילו . . . . ממש ממש יפה.
•  עכשיו, זה לא הסיפור הזה של PDF ו-Vision, זה משהו אחר - אבל עדיין, עושה אחלה עבודה, גם בלהבין איך הדבר הזה בנוי. 
• דרך אגב, ה-Source הוא כן PDF, אז אני לא כל כך יודע מה הם עושים מאחורי הקלעים. אולי הם כן מפעילים שם איזשהו Vision, אין לי מושג.
• אבל זה גם עושה את העבודה של להבין את המבנה של המסמך, וגם את התרגום מעברית לאנגלית.
• ששוב - זה לא כזה מסובך, כל אחד יכול לתרגם, אבל זה פשוט מלא עבודה שחורה, וזה עושה את זה ממש יפה.
• אז מגניב.
• (אלון) כן, זה בכל מיני פורמטים אחרים גם . . . .
• (דותן) כן, כן.
• (דותן) אז זהו, נושא הבא - דיברנו קצת על Editors, אז כבר, לא יודע, די לפני הרבה זמן, נולד Editor שנקרא Zed [כבר מזמן Zed's dead, baby]
• וגם ל-Zed יש “היסטוריית אנשי GitHub" - כמה חבר'ה מ-GitHub, שפיצים כאלה, שבאו ואמרו, אנחנו רוצים לא לעשות עוד סטארטאפ, אנחנו רוצים לבוא ולבנות Editor כזה.
• אז יצא להם Zed.
• איך שזה נראה, לפי הקוד והכל, זה לא VS Code Clone
• זה אומר שהם יצאו מאפס, כתבו...
• (אלון) התחיל מ-Atom . . . 
• (דותן) נכון, Atom - אבל בפרויקט הזה הם כאילו התחילו מאפס, בלי שום בסיס, From Scratch, עד ה-Rendering של הפונטים, הכל כתוב מאפס. 
• הכל ב-Rust, שוב פעם.
• וזה פרויקט שהתחיל כסוג של VS Code Clone כזה. אולי נגיעות-סיומת של Sublime, נקרא לזה.
• מרגיש סופר סופר מהיר - בטירוף.
• ה-Vim Mode שלו, שזה מה שהיה חשוב לי, עובד סביר - לא טוב, אבל סביר.
• ונראה שעכשיו הם בעצם הלכו לכיוון של AI - זאת אומרת להכניס את זה כ-First class citizen בתוך ה-Editor.
• אז מי שאוהב את השילוב של AI ו-Performance ב-Editor וכאלה - זה יכול להיות אחלה.
• לי זה קצת מוריד, הפוקוס על AI
• אבל זה אני באופן אישי, לא מעיד על כלום.
• זהו.
• (רן) הורדתי, התקנתי . . . 
• (דותן) כן, אין כאילו, אתה לא משלם כלום, אין שום חיסרון, אין התקנה, אין כלום - זה Binary, Super lightweight
• אתה עושה Double-Click, מתפוצץ לך לפרצוף מרוב שזה מהיר . . .
• אהבת - אהבת; לא אהבת - סגור.
• (רן) כאילו, אני גם, אני אנסה את ה-Vim Mode, אבל מהניסיון שלי בדרך כלל, כאילו, Vim Mode . . . 
• ה-Vim עובד סבבה ב-Terminal, הוא לא עובד לי טוב כל כך ב-UI.
• כאילו, איכשהו האינטגרציה בין כל שאר הדברים ל-Editor עצמו, לא יודע, לא זורמת לי . . . 
• אולי זה עניין של להתרגל, אולי זה עניין של למפות את המקשים נכון . . .
•  אבל כשאני עובד ב-Terminal ואני מפעיל vim - סבבה, כאילו, אני רגיל, “האצבעות רצות”
• כשאני עובד עם IDE ואני מפעיל Vim Mode, אף פעם לא באמת זרם לי . . . .
• (דותן) שמע, ב-VS Code, ה-Vim Mode [VSCodeVim] בשבילי הוא מדהים
• עד כדי כך שהחלטתי באיזשהו שלב להפסיק לתחזק את ה-”Vim-Vim” שלי, את הקונפיגורציה
• זרקתי את זה לזבל, ובכל מקום - Linux, whatever, לא משנה איפה, אני פשוט פותח VS Code בלי להתבייש, וזהו.
• וכאילו, אמרתי ביי ל-vim, ו-Neovim וכל זה.
• (רן) דרך אגב, הם קראו לפרויקט zed.dev - אני תוהה, האם זה איזושהי קריצה לכיוון למשפט האלמותי Zed's dead, שנשמע קצת דומה, מתוך Pulp Fiction?
• (דותן) יכול להיות שיש שם . . . .יכול להיות.
• (רן) כן, ולא היו מספיק אמיצים כדי ללכת על Z.dead . . . אבל אולי אחר כך.
• (דותן) יכול להיות . . . עוד דבר, למי שאוהב, שווה לציין שאם נכנסים לבלוג שלהם, אז אפשר to geek out לגמרי . . . 
• מדברים עם האלגוריתמים שהשתמשו לעריכת טקסט, והמבני-נתונים המיוחדים שהם השתמשו בהם, ואיך הם עובדים עם tree-sitter, שזו הספרית-Coloring, נדמה לי, שהכי בשימוש היום, ואיך נראה Extension, ולמה הוא עובד ומלא, מלא, מלא חומר הנדסי טכני, ו...
• וכתוב בצורה מדהימה, כאילו ציורית - עם גרפים, עם כל מה שצריך.
• באמת אחלה חומר, כאילו, ממש כיף לקרוא.
• (דותן) זהו, אז האייטם הבא - האמת שבשבילי זה היה ממש וואו: מי שמכיר את הספרייה של ה-UI שנקראת shadcn/ui
• זה בחור שבנה . . . 
• (אלון) מה זה shadcn?
• (דותן) זה השם שלו . . . זה בחור שלא יודעים מיהו, הכינוי שלו זה shadcn
• הוא בא משום מקום כזה, הוא בנה ספריית UI ל-React, מבוססת Tailwind, 
• והיא כל כך טובה שהיא דיברה בשבילו . . . הוא לא היה צריך לקחת . . .  אפס, כאילו, פעילות ב-Social, בכלום.
• זה פשוט ספרייה שכל כך עשויה טוב, מבחינת הדיוק שלה וה-UI והכל
• כשאני השתמשתי בה, זה היה Flawless.
• ואז הרבה, כאילו, הבינו את זה דרך השימוש, דרך הפה-לאוזן
• והספרייה עצמה - היא ממש התפוצצה, והרבה בזמנו לקחו, כאלה כל מיני ספריות מובילות של React, הרבה פשוט עברו לזה, Wholesale, כאילו, בבת אחת.
• חבר'ה של Vercel זיהו אותו, וזיהו את הגדילה של הדבר הזה, וקנו אותו - ועכשיו הוא עובד שם
• וזה עדיין מדהים.
• עכשיו, אחד הדברים שהיו חסרים ב-Toolkit הזה - וזה באמת רמה של פינוק, כאילו, כי יש שם המון, יש שם כל כך הרבה - זה Sidebar
• זאת אומרת, בסופו של דבר אתה רוצה לבנות איזשהו SaaS-App כזה, נגיד, או איזושהי אפליקצית-Admin
• אז אתה רוצה את ה-Shell, אתה רוצה את ה-Menu, אתה רוצה את ה-Sidebar ואתה רוצה את כל מה שמקיף,
• וזה היה חסר הרבה זמן.
• ולפחות בשבילי, זה היה אחד הדברים הכי מעצבנים לעשות, במיוחד ב-Tailwind, שאם אתה רוצה לעשות Refactoring, ואולי אז אתה מעדכן ערימות על גבי ערימות של CSS Classes כאלה מגעילים.
• ואז הוא בנה Sidebar - והוא נתן משהו כמו מאה וריאציות, מספר משוגע . . . 
• ופשוט היום, אתה לוקח את הדבר הזה, אתה פשוט בונה SaaS עיצוב ברמת-קצה, רק עם הספרייה.
• עכשיו, אחד הדברים המיוחדים שהוא עשה, שאולי זה שיעור ללמוד בכלל, לבנייה של Open Source וכאלה,
• הוא בנה את הספרייה בצורה שאתה מעתיק את ה-Sheet  שאתה רוצה להשתמש בו.
• ניתן רגע לזה לשקוע . . . .
• אתה לא עושה npm install לקומפוננטים (Components), אתה עושה Copy לקוד שלהם.
• זאת אומרת, אתה יכול לחשוב שזה כזה מגושם וכאלה - אבל זה פשוט עובד.
• כי אתה רואה, נגיד, כפתור שאתה אוהב - אתה עושה Copy לקוד של הכפתור אליך.
• וככה “התקנת”, “במרכאות”, את הכפתור.
• יש בעיה ענקית לשדרג ולעבור לגרסאות יותר מתקדמות - ממש ידנית אתה צריך לבוא ולהעתיק קוד חדש ולתקן שבירות . . . 
• אבל לדעתי זה אחד הדברים שפשוט עשו את הפיצוץ של הספרייה, כי ה-Friction להשתמש היה אפס.
• (רן) כלומר, זה יורד ברקע אחר כך, או שפשוט לא צריך להוריד כלום?
• (דותן) הקטע ב-Tailwind, בכלל, זה שאתה יכול לבוא, לעשות View source, להעתיק את ה-Source, לזרוק אליך - וממש יש לך הכל, הכל מתקתק, כי זה נטו-CSS.
• אז הוא לקח את אותה הגישה - שאתה מסתכל, זה React, זה עדיין React - ואתה פשוט עושה Copy למה שאתה אוהב מהאתר שלו
• אתה עובד ממש עם האתר - כל הזמן האתר פתוח, אתה עושה Copy, זה  . . . 
• (אלון) כי הבעיה בדברים האלה, אתה אומר “אה, כבר התחלתי, אין לי איך . . .  זה רק להתחיל פרויקט מאפס”.
• וכשיש לך משהו כאן, אתה אומר “אני רוצה איזה גרף” . . . 
• (דותן) ממש . . .  הוא ממש פיצח את ה-Friction של הדבר הזה.
• עכשיו שהוא הצטרף ל-Vercel, זה קטע מעניין - אם עכשיו עוקבים אחריו ב-Twitter, אז הוא נהיה ממש ביג -דיל כזה.
• ובגלל שאנחנו מדברים פה על העתקות של קוד, אז Vercel חיברו לזה כזה כמו משהו שמייצר אפליקציה - לא יודע, LLM-based, whatever, זה לא משנה
• אבל יש כזה דבר שלוקח את כל shadcn/ui - ויכול לייצר אפליקציות שלמות.
• כמובן שהכל צריך להיות Hosted ב-Vercel, והכל “Sponsored by Vercel” כזה . . . 
• זהו, אז מי שרודף אחרי - לפחות אני הרבה זמן רדפתי אחרי ה-Holy Grail
• “תן לי UI-Toolkit, עזוב אותי, לא רוצה להתעניין בשום דבר, תן לי רק ליצור איזשהו Shell, להתחיל איזשהו פרויקט, ליזום איזה משהו כזה”
• בלי להתעסק ב-Style, בלי להתעסק להרכיב את החלקים
• זה הדבר. זה מדהים.
• זהו.

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

[קישור לקובץ mp3]

פרק מספר 481 של רברס עם פלטפורמה, שהוקלט ב-5 בנובמבר 2024, יום רווי אירועים פוליטיים. אורי ורן מארחים את דרור לדרמן מחברת Honeycomb לשיחה על Machine Learning בעולם הביטוח ואולי קצת מעבר.

00:43 דרור ו-Honeycomb(רן) אז ברוך הבא, דרור. ספר לנו קצת על עצמך ועל Honeycomb?

• (דרור) דרור לדרמן, בן 49, כבר לא צעיר . . .  נשוי, שלושה ילדים, נמצא ב-Honeycomb כבר ארבע שנים.
• במקצועי אני בתחום הנדסת חשמל - דוקטורט בתחום הנדסת חשמל, כבר לא מעט שנים.
• למעשה בתעשייה מ-2007, משלב גם עם אקדמיה, הוראה.
• התגלגלתי בלא מעט חברות - גם Corporate כמו Intel, Citi Bank במשך מספר שנים.
•  והצטרפתי ל-Honeycomb ב-2020 - ולמעשה כבר ארבע שנים ב-Honeycomb, הכי הרבה שהחזקתי מעמד עד היום בתעשייה . . . כבר מספר מכובד לכשלעצמו, נהנה מכל רגע, נדבר על זה.

• [וחזר לאוויר גם הפרק בגיקונומי - גיקונומי #542 – דרור לדרמן (עלה מחדש)]

(רן) מעולה, אז נחמד שאתה פה - ו-Honeycomb, במה עוסקים?

• (דרור) אז Honeycomb זו חברת ביטוח, חברת InsurTech, שפועלת בארצות הברית בעיקר, כלומר - אנחנו מבטחים מבני-מגורים, מתחמי-דיור למעשה, מה שנקרא Multi-families ו-Single-Houses בארצות הברית.
• והרעיון המרכזי בחברה שבעצם אנחנו משלבים מודלים של AI בתהליך החיתום וה-Risk Selection
• כלומר, במקום - או אם נסתכל על העולם הקלאסי של ה-InsurTech, שבו יש חתמים, מה שנקרא Underwriter-ים, מושג שהוא טיפה פחות מוכר בארץ . . . 

(אורי) אולי שנייה נעצור, נדבר על כל הסיפור הזה של “חיתום” . . . . מה? מילה שנשמעת “עברית יפה”, אבל מה קורה שם?

• (דרור) אז בהחלט - תהליך החיתום זה תהליך שבו, אם אנחנו מדברים על ביטוח של מבנה מגורים, יש חיתום בתכשיטים וברכבים אפילו, אבל תהליך החיתום בהקשר של מבנה מגורים אומר, שבעצם כשאנחנו - או כל חברת ביטוח - כשהיא מקבלת איזשהו נכס או Property - בית או מתחם-דיור שרוצים לבטח אותו - בעצם אנחנו מקבלים את כל האינפורמציה שיש על אותו נכס.
• אם מספקים, מספקי-משנה ואם מהלקוח עצמו או מהסוכנות, זה הרבה פעמים עבודה עם סוכנויות
• אז הסוכן פונה, מגיש בקשה דרך נניח האתר - במקרה שלנו זה הכל דרך האתר, דרך האפליקציה שלנו.
• מגיש בקשה לבטח נכס בכתובת מסוימת.
• אנחנו מקבלים ממנו פרטים ראשוניים על הנכס, כולל תמונות של הנכס, כולל . . . כל מיני אינפורמציה, כל מה שאפשר, כמובן כתובת ומעיין Credit-History, יש איזה מושג כזה בעולם הביטוח, וכל האינפורמציה שרק אפשר להשיג.
• אנחנו שולפים אינפורמציה נוספת מכל מיני ספקים, כולל צילומי אוויר וכו’ וכו’ - ובעצם בתהליך החיתום, החתם, מה שהוא עושה בתהליך הקלאסי
• הוא מסתכל על הנכס, הוא בוחן גם את התמונות, גם מידע ויזואלי וגם מידע טאבולרי, טבלאי, על הנכס.
• מסתכל על זה מכל הכיוונים האפשריים, נכנס לאתרים כמו Google Maps  וכו',
• ובעצם מעריך את הסיכון שנובע מתוך הנכס.
• למשל, אם מדובר בנכס חדש, מתוחזק היטב, הגינה מטופחת והבית נראה מעולה וחדש וכו’, אז כנראה שהסיכון הביטוחי מאוד מאוד נמוך, ולכן אפשר לאשר את הנכס.
• לעומת זאת, אם הוא רואה שהגג למשל במצב גרוע, יש שם סימני רטיבות . . .
• אפילו מתמונות, הוא לא חייב לבקר בנכס - בעבר היו מבקרים בנכס, מתקופת הקורונה כבר לא עושים את זה . . . 
• גם בגלל שעל הגג קשה לעלות פיזית ואת זה הביטוח לא מכסה, הביטוח של החתם או של הבודק לא מכסה את זה . . . 
• (רן) גם לזה צריך ביטוח . . . .
• (דרור) כן, אז לא לוקחים סיכונים היום, אז מסתפקים בצילום האוויר, בוחנים - ולפי זה מתקבלת ההחלטה, באחריות החתם בעצם, האם לבטח את הנכס.
• ההתהליך הזה, הוא לוקח הרבה זמן . . . 

(אורי) אבל גם יש פה ניסיון של החתם, נכון?

• (דרור) נכון, בהחלט. אז תהליך החיתום - חתמים זה מקצוע שהוא במידה רבה . . . הוא לא מקצוע אקדמי, אין תואר.
• בטח לא בארץ אבל גם לא בארצות הברית - אין תואר שלם, אבל אתה לומד את זה תוך כדי העבודה.
• החתמים שיש לנו בחברה זה חתמים עם המון המון שנות ניסיון, שראו אלפי מבנים בחייהם.
• אז כן, יש פה הרבה מומחיות ולא משהו שבנקל . .  אתה לא יכול לקחת מישהו, אדם מן הרחוב, ולהגיד לו “בוא, תבדוק את הנכס”, זה כמובן לא יעבוד . . .
• ולראייה, אחד הפרמטרים שבהם נמדדת כל חברת ביטוח זה מה שנקרא Loss-ratio - שזה בעצם יחס בין הנכסים שאנחנו מקבלים ובין התביעות שאנחנו מקבלים, בדולרים.
• ככל שה-Loss Ratio יותר גבוה, אז החברה נמצאת בסיכון - וזה אומר שהיא לוקחת סיכונים מיותרים וגם משלמת את זה ב-Claims, בתביעות.
• ה-Loss Ratio אצלנו מצוין, באזור ה-30% ויורד - בין היתר כי אנחנו מסתמכים על תהליך חיתום מאוד מאוד יסודי ומסודר.
• ואז בעצם השאלה שאתה שואל אותי “רגע, אז אם זה דורש מומחיות, איך בכל זאת אפשר להכניס מודלים?”
• אז כמובן שלא כל מבנה אפשר לסמוך רק על מודלים, ובאמת בשלב ראשון לא הכנסנו ישר מודלים ו”יאללה, בואו נסמוך”, לא.
• אבל ראינו שיש הרבה מקרים שהנכסים במצב מצוין, מהסתכלות על התמונות או אינפורמציה שיש לנו על נכס
• באמת יש לנו עשרות Feature-ים שאנחנו מקבלים על אותו נכס.
• אז בשני מצבים קיצוניים כבר די מהר אפשר להגיד אנחנו לא צריכים חתם - 
• אם הבית הוא במצב מצוין מכל הבחינות האפשריות
• או לחילופין אם הבית במצב גרוע, למשל - אם הגג נראה זוועה וברור שצריך להחליף אותו בשנים הקרובות, אנחנו לא ניקח את הסיכון הזה, אנחנו לא צריכים חתם . . .
• מספיק כשהגג נראה זוועה והמודלים עוברים מסתכלים ועושים בעצם אנליזה אוטומטית, אנחנו יכולים להיות בטוחים ורגועים שאנחנו דוחים את הנכס הזה.
• עם כל הכבוד ללקוח, הוא מקבל תשובה מהירה
•  ואגב גם הוא מרוצה מזה - כי בעצם בזה שאנחנו משלבים מודלים ומאפשרים מצב שבו חלק מהנכסים לא עוברים בכלל, לא מגיעים לחתם, הלקוח יוצא בזה דווקא נשכר, כי הוא מקבל תשובה מיידית.
• נכון, היא שלילית, אבל הוא מקבל תשובה מהירה והוא יודע שהוא צריך ללכת לחברת ביטוח אחרת, אז זה גם בסדר מבחינתו.
• (אורי)  או לתקן את הגג . . .
• (דרור) או לתקן את הגג, בהחלט כן, זה גם אופציה שאנחנו מאפשרים . . . יש מצבים שאנחנו אומרים “הגג במצב לא טוב - אנחנו מוכנים לבטח את הנכס, אבל בוא תתקן את הגג”.

(רן) רגולטורית, אין בעיה? זאת אומרת, אפשר לסרב לכל לקוח? אין איזושהי רגולציה שאמרת שצריכים לספק סיבות  וכו'?

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

07:40 על מכונות וחתמים(רן) בסדר, אז למעשה הנושא של היום, כבר פחות יותר הצגנו את זה, אבל בגדול אנחנו מדברים על איךלוקחים את עולם החיתום - את עולם הביטוח של בתים במקרה הזה, אבל אני מניח שזה גם תקף למקרים אחרים - נתונים שמגיעים בצורה טבלאית, ויזואלית, ואולי גם יש עוד דברים שנדבר עליהם בהמשך - איך לוקחים את זהומפעילים על זה Machine Learning, זאת אומרת - מחליפים את החלטת החתם, במקומות שזה אפשרי, ולומדים ומשתפרים מזה.אז ככה, דרך אגב, התחילה החברה? זאת אומרת,  זה היה ה-Claim to Fame של החברה מלכתחילה?

• (דרור) כן, בהחלט - זה היה המוקד וזה היה החידוש המרכזי בחברה.
• כי תהליך החיתום היום, דיברנו עליו, הוא תהליך קצת Old Fashion, וחתמים גם זה קצת, זה Old Fashion, כי יש להם “שטאנץ” מסוים שהם עובדים לפיו.
• ובאנו ובעצם רצינו לשנות את זה די מהיסוד - אבל כמובן שעשינו את זה בהדרגה, לא מיד “נכניס מודלים ותשכחו מהחתמים” זה לא . . .

(רן) אז אני, תרשה לי לנחש - וגם קצת דיברנו לפני זה, אז אני יודע - אבל תרשה לנחש שככל שיש יותר חתמים, כך יש יותר דעות . . . זאת אומרת, יכול להיות שחתם מסוים יבוא ויסתכל על בית ויגיד “X”, וחתם אחר יבוא ויסתכל על ביתויגיד “Y”, ולנו, כאנשי שMachine Learning זה עושה חיים קשים, כי פתאום יש שני תיוגים שונים לאותו ה-Data . . .אז איך מתמודדים עם אתגר כזה?

• (דרור)  כן, זו שאלה מעניינת.
• אני מכיר את זה קצת גם מעולם הרפואה, אני עסקתי הרבה ועוסק הרבה בעולם הרפואה, גם במישור האקדמי וגם בעצמי כפאראמדיק מתנדב במד”א הרבה שנים, אז אני מכיר את זה גם מעולם הרפואה.
• אבל שם זה עוד, זה פחות חמור - ואצלנו באמת בתהליך החיתום . . . 
• למשל, אחד הפרויקטים שאנחנו כבר עובדים עליו ומשקיעים בו הרבה, זה פרויקט שבו אנחנו רוצים להסתכל על בתים - מראה חיצוני, על ה-Front, על החזית של הבית - ולתת ציון.
•  זה הדבר, זה ה-Holy Grail - אם נצליח להשיג את זה, אז שיחקנו אותה בגדול.
• וכשאתה נותן . . . דבר ראשון שעשינו זה שלקחנו שלושה חתמים בחברה, ואמרנו להם “בוא תסתכלו על נכסים, כל אחד שייתן ציון”.
• כל אחד לא ידע מה השני נתן.
• עשינו מעין תחרות כזו בחברה - ובאמת קיבלנו שלוש דעות שונות.
•  עכשיו, זה לא מצב שבו חתם אחד אומר שהנכס הוא מצוין, “מאה מתוך מאה", והשני יגיד שזה “אפס מתוך מאה”, אבל יש Variance, ישנה שונות מסוימת בציונים.
• וכן, בעולם ה-Machine Learning, הדבר הכי חשוב זה אנוטציות (Annotations) מדויקות, תיוג מדויק - וכשאין לך את זה, אתה בבעיה.

(אורי) או סטטיסטית . . . .(רן) . . . או שלפחות יהיה מספיק . . . (אורי) . . .  כן, או שאתה צריך משהו שהוא Significantly סטטיסטי.(רן) אבל פה, זהו - התיוג הוא יקר, אז אין כל כך הרבה תיוגים, וגם יש הרבה Variance.(אורי) נכון . . .

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

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

• (דרור) נכון. לא רק זה, יש בעיה מסוימת בעולם החיתום - אגב, היא מתרחשת גם בעולם הרפואה - שבניגוד לעולמות אחרים, שיש Data אינסופי שמתפרסם, ו-Google ו-Microsoft וכולם, בעולם החיתום, נתוני התביעות לא מתפרסמים.
• אתה לא יכול לקבל . . . אנחנו גם, אין לנו גישה לנתוני התביעות, למעט התביעות שלנו כמובן.
• תביעות של חברות אחרות - אין “Open Source”, אנחנו לא יכולים, היינו מאוד רוצים . . .
• ולכן אנחנו צריכים להימדד באמצעות Data פנימי שלנו, ובאמת התחלנו לאסוף כמויות מטורפות של Data.
• החברה משקיעה בזה המון המון משאבים, לא רק כסף, אלא גם אנשים שעובדים ומתייגים.
• ואחת הדרכים - יש מספר דרכים להתמודד עם הדבר הזה - אז קודם כל אם היית שואל אותי לפני שנתיים, הייתי אומר לך “תקשיב, זו חתיכת בעיה, לא הייתי נוגע” . . .
• זו בעיה מאוד קשה, בעיה של סובייקטיביות, של האנוטציות והחוסר-עקביות - אפילו אם אתה נותן לאותו חתם את אותו נכס, תמונה של אותו נכס שבוע אחרי שבוע, התשובה לא תהיה זהה.
• (רן) כמו שופטים בבקשות Paroles . . . זאת אומרת, אם זה לפני ארוחת צהריים או אחרי ארוחת צהריים [Hungry judge effect].
• (דרור) כן, בהחלט. אגב, גם עולם המשפט, אפשר לדבר על זה, שיחה נפרדת, גם את זה אני קצת מכיר מקרוב.

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

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

(אורי) שאגב, גם הוא לא קונסיסטנטי (Consistent) תמיד . . .

• (דרור) נכון, והשאלה איך מפצחים את הדבר הזה? קודם כל, באמת אתגר שהוא . . .  אני לא יכול להגיד שפיצחנו אותו לגמרי, אבל אני חושב שאנחנו מתחילים לראות “סימני נפט”.
• ואיך שעשינו את זה, אז קודם כל ברור שאתה לוקח מספר חתמים, אתה לא מסתמך רק על אחד.
• אתה צריך שיתוף פעולה שלהם, אתה צריך שהם יקדישו לזה זמן
• ואתה נותן להם המון תמונות - היעד שלנו להגיע למאות-אלפי תמונות שהם עוברים עליהם ומתייגים.
• זה לא טרויוויאלי בכלל, אבל החברה Dedicated לזה ו-Committed לזה.
• דבר נוסף, אתה צריך לעשות תהליך מאוד מסודר איתם, וזה דורש מחויבות מאוד גדולה, של Training מסודר.
• כלומר, קודם כל, עוד לפני שזה בעיה של Machine Learning - זו בעיה של החברה.
• כלומר, איך יכול להיות שעל אותו מקרה או על אותו בית, חתם אחד יגיד “כן, אני מאשר את זה לחיתום, אני מאשר את זה לביטוח”, ואחר יגיד שלא?
• בחברה מתוקנת, אסור שזה יקרה, יש פה פוטנציאל או להפסד כספי של נכס שוויתרנו עליו, או לתביעות - ואת זה אנחנו צריכים לפתור.
• ועושים את זה דרך תהליך שיתוף פעולה עמוק עם החתמים
• למזלנו הם בתוך החברה, הם לא חיצוניים, אז יש  להם את אותו אינטרס בדיוק כמו צוות ה-AI
• ואתה יושב איתם, ואתה בונה Training Material מאוד מסודר, עם Guidelines מאוד מסודרים, Checklist ממש
• כשאתה עובר על נכס, זה לא סתם להסתכל . . .
• זה מזכיר לי, באקדמיה כשאתה בודק בחינות - גם בחינות, במידה מסוימת, זה סובייקטיבי.
• איך אתה מתמודד עם זה? אתה עושה Checklist - כמה אתה מוריד על כל שגיאה? זה אינטנסיבי, זה דורש הרבה יותר זמן פר בחינה, אבל זאת עוד הדרך להגיע לעקביות, בתהליך מסודר.

(רן) זאת אומרת, הם למדו את המקצוע, הם חתמים - אבל אתה עכשיו צריך “לכייל” אותם . . . 

• (דרור) צריך לכייל אותם . . . .

(אורי)  . . .  כדי לייצר מהם Training Data . . . 

• (דרור) . . . לייצר מהם Training Data - ולא רק Training Data, לייצר עקביות בחברה עצמה . . .
• זה לא רק זה. זה פתאום משליך, כשהחברה מתחילה להבין את זה, ונופלים כל האסימונים, אז אתה מבין שרגע, איך מקבלים חתם חדש לחברה? איזה תהליך Training הוא עובר?
• ואז אנחנו מבינים שאנחנו צריכים באמת “לכייל” את כל התהליך ה-Training, עוד לפני ה-Machine Learning, כדי שתהליך החיתום יהיה עקבי בחברה, זה דבר ראשון.

(רן)  דרך אגב, חברות אחרות - יש להן אינטגרציה לזה? זאת אומרת, הן עושות נגיד Review כפול או משולש או דברים בסגנון הזה? איך מתמודדים?

• (דרור) אז קודם כל, עולם החיתום הוא די לא אגיד “סודי”, אבל הוא לא פתוח . . . אז קשה לי לדעת מה עושה כל חברה וחברה.
• אני יודע שיש כל מיני ניסיונות להתמודד - אבל אני לא מכיר פעילות כזאת שנעשתה בחברות אחרות.
• יכול להיות שאני לא יודע, אני מן הסתם לא יודע הכל, אבל אני לא מכיר פעילויות כאלה.
• הדבר הנוסף שעשינו זה בעצם לא להילחם עם זה.
• כלומר, יש מידה מסוימת של סובייקטיבית, “לא יעזור בית דין”.
• אתה יכול להגיד, לבוא למנכ״ל - איתי, המנכ״ל שלנו - ולהגיד “תקשיב, זה לא יעבוד, בוא נשכח מזה ובוא נעבוד לדברים יותר בטוחים”.
• ופה התעקשנו - אנחנו, הנהלה של החברה אמרה “לא, אנחנו מוכנים לקחת את הסיכון”.
• כן זה פרויקט בסיכון גבוה, אנחנו . . . יש תקציב, אנחנו מוכנים לקחת את הסיכון, גם זה אומר שאני צריך להשקיע הרבה מאוד משאבים ויכול להיות שבסוף זה לא יעבוד.
• בעיניי, זה חלק מהדברים הכי יפים שקרו לי ב-Honeycomb ואחד מהדברים שאני הכי מעריך
• זו המוכנות של החברה לקחת גם סיכונים, לקחת פרויקטים בסיכון גבוה.
• להשקיע המון כסף.

15:15 אבל למה?(אורי) אבל בוא נדבר קצת על ה-Benefit . . . . כאילו, למה? למה פרויקט של להכניס Machine Learning לעולם  הזה היה להם כל כך חשוב?

• (דרור) אני חושב ש . . . אוקיי, אז יש פה כמה סיבות
• קודם כל, סיבה פרקטית - אתה לא רוצה . . . כל הרעיון של החברה זה לא עכשיו לגייס צבא שלם של חתמים, שעולים הרבה כסף וגם איטיים בתהליך החיתום שלהם, זה אחד.
• החברה - אין זכות קיום לחברה,  זה החידוש המרכזי בחברה.
•  הדבר השני, והיותר חשוב בעיניי, זה החוויית משתמש - אתה רוצה שתהליך החיתום יהיה הכי מהיר שאפשר, לפחות ב-Subset של מקרים. 
• כלומר, היעד שלנו, החזון של החברה, זה 80% מהאפליקציות לביטוח שיתקבלו ללא מעורבות של חתמים, אוקיי?
• איך משיגים את זה? רק באמצעות Machine Learning.
• והיתרון בזה שבעצם הלקוח . . . סליחה, זה יכול להיות לקוח זה יכול להיות סוכן של הלקוח,  מקבל תשובה מיידית.
• גם אם התשובה שלילית, הוא מקבל תשובה מיידית.
•  בתור אחד שהיה לו בית בארצות הברית בזמנו, זה מאוד מאוד קשה עד היום, אגב, בחלק מהחברות.
• כש-Honeycomb לא פעלה . . .  אני, הבית שלי היה בפנסילבניה, בפיטסבורג, ו-Honeycomb בזמנו לא פעלה שם, אז היה לי ביטוח דרך Nationwide.
• ואחרי שנה, כשרציתי לחדש את הביטוח, פתאום אוקיי אמרתי “בוא נעשה סקר שוק”.
• אתה פונה - וכל חברה שאתה פונה, עד היום, אתה צריך למלא הרבה מאוד אינפורמציה על הנכס . . .
• לא גרתי בדירה, זו הייתה דירה להשקעה במקרה הזה.
• מאיפה אני יודע בכלל מה ה-Type of Wall וכל מיני פרמטרים . . . Square ft. וזה . . . 
• התהליך הזה מאוד מאוד קשה - וגם אז כשאתה פונה, אתה צריך לחכות שבועיים-שלושה לקבל את התשובה.
• מה קורה אחרי שבועיים-שלושה? התאריך של הביטוח . . .  הביטוח עוד מעט פג-תוקף, ואתה מקבל תשובה  שלילית . . . 
• אתה צריך עכשיו ללכת . . . אתה קודם כל נלחץ, ואתה צריך ללכת לחברת ביטוח אחרת.
• אנחנו משנים את זה מהיסוד. אנחנו נותנים תשובה מיידית ללקוח - בין אם היא חיובית, בין אם היא שלילית
• בין אם זה על תנאי - “בוא, תתקן את הגג ונבטח” . . .
• אז הלקוח מרוויח מזה, וחוויית-המשתמש הרבה יותר טובה.
• ואנחנו מקבלים פידבקים מאוד חיובים על זה - ורואים את זה גם כמובן בהכנסות.

(רן) כן אני מניח שיש גם לקוחות שממקבלים . . . אז אולי שולחים לכמה חברות אחרות במקביל, ואם יש תשובה מכם ראשונים אז יקנו אצלכם.

• (דרור) בהחלט. אז באמת בהקשר הזה, יש לנו מוצר די חדש שמאפשר לסוכנים לקבל . . . להעביר רשימה של נכסים.
• כי הרבה פעמים סוכן מטפל עבור לקוח מסוים בעשרות דירות - המשקיעים הגדולים בארצות הברית.
• אז אנחנו מקבלים רשימה של דירות, ואמרו להם בוא תבדקו על כל הדירות האלה - מה האחוז מתוך הדירות שאתם תהיו מוכנים לבטח?
• ויש לנו אפשרות לתת להם מענה די מיידי - לעבור על הנכסים, להוציא את כל האינפורמציה, בלי שהם יכניסו, אנחנו שולפים את האינפורמציה מ-3rd Parties ומההיסטוריה שלנו ונותנים תשובה מיידית לסוכנות.
• (רן)  ממש מעבר על ה-Portfolio . . . .
• (דרור) כן, לגמרי.

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

• (דרור) אז זה די מתחבר לעולם התוכן האקדמי שלי. 
• במשך הרבה שנים לימדתי קורסים, למשל קורס שנקרא “אותות אקראיים”.
• זה קורס שבעצם מדבר על התפלגויות של נתונים. כל דבר, בעצם, שקורה בעולם האמיתי - טמפרטורה, לחות, משקעים וכו', גובה הגלים . . . זה איזשהו משתנה אקראי. 
• ובעצם, אתה מבין שגם הציון שחתמים נותנים זה איזשהו משתנה אקראי - הוא לא לגמרי אקראי, במובן זה שכל פעם הוא ייתן ציון אחר, אבל יש פה . . . יש לו איזושהי התפלגות.
• כשאתה מבין את זה, וכמובן אני לא אצלול ל-Details הנקרא לזה “סודיים” של האלגוריתם וה-IP, אבל כשאתה מבין את זה, אז אתה מבין שבעצם אתה צריך לשערך איזושהי התפלגות, ולא את הציון עצמו.
• כלומר, יש איזשהו, בוא נניח רק לצורך הפשטות, שיש, אם אתה לוקח את כל הציונים של חתמים - ולקחנו הרבה חתמים ולא חתם אחד, אז יש להם איזושהי התפלגות לכל Property.
• ואם אתה תצליח לשערך טוב את ההתפלגות הזאת, אז אתה במצב טוב. 
• כלומר, אתה תדע שיש טווח ערכים “סביר” שחתם ממוצע אמור לתת, צפוי לתת את הציון.
• את זה אתה משערך, את זה המודל שלך משערך - ואז אנחנו במצב...

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

• (דרור) אז אנחנו לא עושים את זה - כי אנחנו לא רוצים להניח הנחות מוקדמות.
• אנחנו פשוט משתמשים ב-AI - ברשתות נוירונים - כדי לשערך התפלגות כללית.
• דיברת על גאוסיאנית - גאוסיאנית מאוד ממקד אותך, שוב, בלי לי להיכנס ל-Details היותר משעממים, אבל התפלגות גאוסיאנית היא התפלגות מאוד מאוד ספציפית, שלמעשה לא קיימת במציאות . . .
• (רן) נכון, נכון . . .
• (דרור) . .  אז אתה משערך משהו יותר כללי.
• (רן) חוץ מאולי חוק המספרים הגדולים [משפט הגבול המרכזי], אבל זה לא שם. 
• (דרור) כן, בדיוק.
• (רן) נכון מאוד, כן. ואולי למדתי באוניברסיטה שכל דבר . . . כל תרגיל מתחיל בהתפלגות גאוסיאנית, אבל במציאות זה בדרך כלל לא.
• (דרור) זו אחת השאלות הראשונות שאני שואל את הסטונדטים שלי . . . 
• הסטונדטים בדרך כלל באים אחרי קורס מבוא להסתברות, אני אומר “למדתם התפלגות גאוסיאנית ופואסונית וכו’… בואו תגידו לי . . . “
• קוראים לזה “התפלגות נורמלית" או “גרף פעמון”, עוד מהתיכון מכירים, מה במציאות מתפלג?
• אז כל פעם זורקים לי כל מיני דברים, אבל בפועל אין שום דבר שמתפלג גאוסיאנית, כי זו התפלגות שהיא סימטרית ואינסופית, לא קיים דבר כזה במציאות.
• (רן) אולי זה סכום כל ההתפלגויות בעולם, וזהו.

20:35 ואז מגיעים לקוחות(רן) אוקיי, עכשיו - עוד בעיה שקורית די הרבה למי שמתעסק בעולם ה-Machine Learning זה שבמעבדה הכל עובד יפה, תחת אור הניאון . . .  זאת אומרת, אתה מאמן מודל, אתה בודק את הביצועים שלו, זה נראה יופי-טופי. גם אחרי שאתה פורש את זה, כנראה ביום-יומיים הראשונים הכל טוב - ואז אחרי איזשהו זמן, לפעמים אתה לא שם לב, וזה קורה בכל חברה, אורי, אז בטוח שזה שגם קרה ב-Outbrain . . .(אורי) ואחרי זה מגיעים לקוחות . . .(רן)  . . . כן, ואחרי איזשהו זמן פתאום דברים משתנים, פתאום דברים לא עובדים כמו שצריך.עכשיו, זה לא שהכנסת איזשהו באג, אולי בכלל לא שינית את הקוד. לא פרשת שום גרסה, אבל פתאום הביצועים של המודל ניהיים יותר ויותר גרועים.האם קרה לכם? אני מנחש שכן . . . ואם כן, אז איך מתמודדים?

• (דרור) א' - כן, קרה.
• ב' - זה הפחד הכי גדול שלי . . . 
• אני, בעצם למעשה מ-97' בעולם ה-Machine Learning, עוד לפני שקרו לזה AI, לפני שהיה Deep Learning ו-LLM-ים ו-HGBT, אז אני לא מעט שנים, וכמו שאתם רואים כבר שיערות אין לי על הראש, אז אני למוד ניסיון . . .
•  אבל זה תמיד מפחיד, כי באמת, אתה מכניס מודל, אתה עובד עליו הרבה זמן, אתה מוכיח תוצאות טובות . . .
• ושוב, האינטראקציה עם החתמים - החתמים צריכים, מי שבפועל, לא הייתי אומר מוביל את החברה אבל אולי  אחד התפקידים הכי משמעותיים בחברה, זה ה-Chief Underwriter [בטוח יש דמות כזו אצל Terry Pratchett], החתם הראשי.
• שהוא בעצם מאשר לנו כל מודל, כי האחריות היא שלו.
•  דיברנו על רגולציה קודם, האחריות היא שלו.
• ובאמת, סתם, לצורך הדוגמא - יש לנו מודל שהכנסנו ל-Production כבר, לדעתי, לפני שנתיים או משהו כזה, וזה מודל שמקבל החלטות, בלי מעורבות חתם.
• הוא מחליט לדחות חלק מהנכסים, על סמך האינפורמציה שיש על הנכס, כמובן בלי להיכנס ל-Details ו-Feature-ים.
• וזה מודל שהוכיח תוצאות יפות, והראינו את זה - הצגנו להנהלת החברה, והם נתנו לנו אור ירוק.
•  זה גם יוצר אמון - אתה בא, אתה עושה עבודה יסודית, במקרה הזה לא אני אישית, מישהו מהצוות שלי.
• הראה להם תוצאות, שכנע אותם שזה מודל שעובד טוב.
• יש לו משמעות אדירה לחברה - לטוב ולרע - כי הוא דוחה נכסים.
• כי אם אתה דוחה נכסים טובים, אז החברה הפסידה כסף נקי.
•  מצד שני, הראינו שהוא - יש לו יכולת לזהות מראש נכסים שהם פוטנציאליים לתביעות.
• כלומר, ראינו שבשימוש במודל אנחנו מורידים דרמטית את כמות התביעות שאנחנו מקבלים, שזה מאוד דרמטי לחברה.
• ובזכות זה בין היתר הגענו ל- Loss Ratio המאוד מאוד נמוך שהזכרתי קודם.
• הכנסנו את זה ל-Production, זה רץ - רץ, חודשים, עובד טוב.
•  ומדי פעם אנחנו מעדכנים אותו, כי אם נוסף לנו עוד Data אז אנחנו מאמנים אותו מחדש, בודקים, מנסים אותו ל-Production, כולם שמחים, הכל בסדר.
• יום בהיר אחד, אנחנו פתאום רואים - ואני מודה, טעות שלי, לא עקבנו יום יום, היינו רגועים, כי ראינו שזה כבר נכנס ועובד טוב - יום בהיר אחד אנחנו רואים קפיצה בדחיות שהמודל עושה, קפיצה דרמטית מאוד.
• קפיצה שהגיעה בעצם לאזור ה-400 אלף דולר של הפסדים רק בשבועיים.
• לקחנו זמן, כי לא עקבנו, כי סמכנו על המודל, וגם הנהלה סמכה עלינו - ופתאום אנחנו באמת מגלים, בודקים את זה, רואים משהו פה לא מסתדר.
• מיד עצרנו את זה, החזרנו את המודל הקודם - והסתבר שבאותה תקופה בדיוק הוכנס עדכון נוסף, עשינו אימון נוסף, בדקנו, אבל הסתבר שעשינו שם טעות בהערכת ביצועים.
• הייתה שם בעיה, בדיעבד מאוד מאוד נפוצה בעולם ה-Machine Learning, שזה באמת הפחד הכי גדול שלי, שזה שינוי בהתפלגות.
• המודל עובד, הוא משפיע, הוא דוחה חלק מהנכסים - אז בגלל שהוא דוחה חלק מהנכסים שהם הפחות טובים, הוא משנה את ההתפלגות שיש לנו ב-Production . . . 
• אז פתאום, מה שקרה זה בעצם Drift בתוצאות - פתאום ההתפלגות שהמודל רואה ב-Production זו לא  ההתפלגות שאימנו אותו ב-Offline.
• מקבלים Drift משמעותי בתוצאות.
• אני מספר על זה, זה נשמע עכשיו פשוט - לקח לנו זמן להבין את זה . . .

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

• (דרור) בהחלט. אז קודם כל, מה שעשינו זה שעשינו הקפאת מצב, כלומר - החזרנו את המודל הקודם, היציב  והטוב, אמרנו “בואו עכשיו, תנו לנו רגע לעשות Post Mortem ולהבין, כמו בחיל האוויר, להבין בדיוק מה קרה  פה.
• (רן) הנה, זאת שיטה - אז חודש מודל ישן, חודש מודל חדש . . . 
• (דרור) כן . . . אבל יש פה בעיה הרבה יותר קשה מ . . .
• סתם, עזוב את ה-400 אלף דולר, “לא קרה כלום” - החברה יודעת לספוג, ואני מאוד גאה ב-Honeycomb  שיודעת להכיל גם מקרים כאלה, להגיד, לא קרה כלום.
• אני זוכר שאני הייתי מוטרד, לא שיפטרו אותי, אבל יגידו לי “נו- נו- נו” . . .  לא, אנחנו, המוטו של Honeycomb, ואני ארבע שנים, זה כמעט מהרגע הראשון - “בואו נטעה מהר”
• בואו נטעה מהר - העיקר שנלמד ונתקן.
• אני אישית מאוד מעריך את זה.
• ובאמת נתנו לנו את הזמן, קודם כל להבין, לחקור.
• הצגנו דוח מסודר לכל הנהלה של החברה, ול-Chief Underwriter.
• הם קיבלו את הדוח, ראו, קודם כל יצרנו אמון מחדש בזה - זכינו באמון מחדש בזה, שבאנו, לא התביישנו להגיד, אמרנו, “הנה, לקחנו אחריות”
• האחריות שלי כראש צוות - הנה התקלות, והנה ככה אנחנו מתקנים את זה.
• וקיבלו את זה, וזה היה יופי של דבר מבחינתי.
• זאת אומרת, מצד אחד, זה חתיכת פשלה שלי כראש צוות, תקלה שאסור שתקרה, עם הפסדים מאוד משמעותיים.
• אבל אני שמח שזה קרה - זה אולי נשמע מוזר, אני שמח שזה קרה.
• למדנו, תיקנו, למדנו, כשזה היה ב-Scale נמוך, היום זה היה יכול לגרום לנזק הרבה יותר גדול.
• אנחנו שיפרנו את התהליכים, אנחנו עושים Monitoring הרבה יותר מדוקדק, אנחנו הרבה יותר חכמים.
• אני בטוח לזה עוד יקרה, אבל אנחנו יודעים גם לתקן את זה מהר, בזכות זה שאנחנו עושים Monitoring שוטף.
• ואנחנו גם למדנו את הבעיה הזאת - יש הבדל בין להכיר את זה בתיאוריה, אני הכרתי את זה בתיאוריה, חוויתי את זה גם ב-Citi Bank -  לבין לראות את זה בשטח, כשזה משפיע על Production בצורה כזו דרמטית,
• אז למדנו מזה ושיפרנו את התהליכים - וגם שוב, רכשנו את האמון וזה מאוד חשוב
• כי בעבודה עם ה-Underwriter-ים, כמו עם רופאים אגב, אתה חייב את האמון.
• אם לא יאמינו לך ולא יאמינו במוצר, הם לא ישתפו פעולה ואיבדת אותם - וזה לא פחות חשוב מהאמון של לקוחות.
• במקרה שלנו, הלקוחות שלנו, ה-Stakeholders שלנו זה כמובן החתמים - אנחנו חייבים אותם איתנו.
• ולמזלי זה קרה, ואפילו חזקנו את הקשר איתם, אז אני שמח שזה קרה.

27:04 אתה יכול להסביר?(אורי) לי יש שאלה,  שגם נוגעת לאמון וגם נוגעת למשהו שאמרת בהתחלה: שלפעמים, יש . . . פסלתם בגלל שהגג ישן,אז אתה רוצה להחזיר פידבק - שהגג ישן או למה פסלת, או למה המודל לקח החלטה. זה קשור לאקספליינביליות (Explainability) של המודל, כמה אפשר להסביר את ההחלטות שלו. ויש סוגי מודלים שהם יותר אקספליינביליים (Explainable) וכאלה שהם פחות. וזה גם שהאקספליינביליות הזאת - היא מייצרת אמון, גם של לקוחות אבל גם של מי שאמור לאשר לך את המודל.אז איפה אתם עומדים עם זה?

• (דרור) אז קודם כל, יש Debate מאוד גדול בעולם האקדמי והתעשייתי על הנושא של אקספליינביליטי (Explainability).
• אני קצת לוקח גישה קיצונית, אני אסביר טיפה - קודם כל יש סתירה בין הרצון שלך להיות מסוגל להסביר את המודל לבין הביצועים של המודל.
• בעיני, ביצועים מעל הכל - כלומר, ככל שהמודל יותר טוב מבחינת ביצועים, אז הוא מן הסתם יותר מורכב.
• בעולם הרשתות היום, רשתות עמוקות - The Deeper The Better כמו שאומרים.
• ככל שהרשת יותר עמוקה, זה אומר הרבה יותר פרמטרים.
• אנחנו מכירים היום כולנו את ה-LLM ו-HGBT - זה מיליונים ואפילו מיליארדים של פרמטרים.
• ככל שהרשת יותר עמוקה, עם יותר פרמטרים, אתה לא יכול להסביר אותה - אין סיכוי.
• יש ניסיונות, יש Grad-CAM, יש כל מיני מודלים - הם לא עובדים טוב, זה עדיין לא בשל.
• לכן, אם אתה רוצה למקסם את הביצועים של המודל שלך, זה על חשבון Explainability.
• אנחנו, כחברה - נכון, חשוב לנו להיות מסוגלים להסביר את זה לחתמים, אבל מקבלים את זה שזה מודלים שעובדים במרחב המולטי-פרמטרי או במרחב הרב-פרמטרי, ולא נדע להסביר את זה.
• איפה שאפשר, אנחנו מנסים.
• במודלים היותר קטנים, יש לנו מודלים שעובדים על קומץ - לא  קומץ אבל כמה עשרות של פרמטרים - ושם אנחנו משתמשים בכלים שמאפשרים, Shapely וכל מיני כלים
• כלים שמאפשרים להסביר את המודל, וזה באמת עוזר במוצבים מסוימים להסביר.
• ברגע שאתה רוכש את האמון - בדם, יזע ודמעות - של ההנהלה ושל החתמים, אתה לא צריך את האקספלינביליטי (Explainability).
• הם סומכים עלינו - לא אגיד “בעיניים עיוורות”, הם כל הזמן מסתכלים ואנחנו כל הזמן צריכים להראות, לחדש את האמון ולזכות בו מחדש באמצעות מעבר ביחד על התוצאות ועל התהליכים אצלנו.
•  והם חלק מהעשייה אגב, הם לא איזשהם “לקוחות-קצה”, הם חלק מה-Squad-ים, חלק מהעשייה, חלק מהפעילות שלנו.
• ברגע שאתה רוכש את האמון, הם לא מבקשים הסברים.
•  זה אולי קצת שונה מעולם הרפואה, שם הרופא רוצה לדעת
• רגע, הוא - לא מספיק לו שיש התקף לב, אני יודע את זה כפאראמדיק, המכשיר אומר “התקף” - וזה לא מספיק לי, אני רוצה לראות איפה.
• בין היתר, כי לא סומך על האלגוריתם, מה לעשות?
• בעולם החיתום, לפחות אצלנו בחברה, ברגע שהוכחנו שהמודלים עובדים טוב . . .
• אגב - לא 100%, אף מודל לא עובד 100%, יודעים שיש איזשהו טווח-שגיאה
• אבל ברגע שקבלנו את האמון, הם לא מחפשים את “בואו תסבירו לי למה זה ככה ולמה זה ככה”.
• זה כן קורה עדיין במקומות מסוימים - איפה שאפשר אנחנו באמת משתמשים במודלים, ה-State if the Art, הכי מתקדמים לנסות ולהסביר.
• מהניסיון והידע שלי, המודלים האלה עדיין לא בשלים ולכן צריך לקבל אותם בהסתייגות.

(אורי) הם בעצמם צריכים לרכוש את האמון . . .

• (דרור) הם בעצמם צריכים לרכוש את האמון, כן . . .
• זה די סתירה, כי אתה רוצה מודלים חזקים שעובדים טוב - זה מודלים עם המון פרמטרים, שה-Explainability Models לא עובדים עליהם מספיק טוב
• ולכן אני מאוד נזהר מהשימוש במודלים האלה.

(רן) כן , זה אחד - ושתיים, זה גם להשקיע מאמץ, זאת אומרת כוח אדם. אם אתה רוצה Explainability, אתה צריך לפתח את זה, וגם אם המודל, עקרונית, מסוגל לתת לך את זה, אתה עדיין צריך להשקיע מאמצים כדי שזה יקרה.

• (דרור) בהחלט.

(רן) אוקיי. אז דרך אגב, יש מקומות שבהם, מבחינה רגולטורית, אתם כן צריכים? זאת אומרת, נגיד אם אני מסתכל על עולם הבנקאות והלוואות וכל זה, אז אני יודע ששם כן, יש מקומות שבהם פשוט צריך לספק הסבר [למיטבי שמע - 476 ML Explainability and friends with Dagan from Citrusx]. זה לא מספיק שתגיד “אבל המחשב אמר לי שאסור!” . . . אצלכם, יש מקרים כאלה שצריך את זה?

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

32:13 חסמי-כניסה(רן)  אוקיי, בואו ככה לקראת הסיום, נסטה קצת הצידה. אמרת לי קודם שאתה כבר בתחום מכמה - 97’? ועולםה-Machine Learning / AI, לא חשוב איך קוראים לזה היום, נראה מאוד אחרת. אז, הרשתות לא היו עמוקות,גם לא כל כך אהבו אותן אז.והיום הדברים נראים אחרים - כל אחד יכול להרים LLM, לעשות Embedding, להשתמש במודל Computer Vision, מפלצתי ככל שירצה, וזה עולה סנטים בודדים.בואו נדבר קצת על פרספקטיבה, ככה, של חסמי-כניסה לעולם הזה. ממה שהספקת לראות לאורך השנים,איך זה נראה היום לעומת איך זה נראה פעם?

• (דרור) שאלה מעניינת . . .  אגב, אני אתחילו אולי מהסוף: רואים את זה יפה מאוד בצוות שלי
• אנחנו היום עשרה אנשים, ואגב, אם מותר להגיד - מחפשים כל הזמן אנשים טובים, בתחומי ה-Machine Learning, Deep Learning, Analytics וכו’
• אז יש משרות פתוחות, מוזמנים להגיש.
• הצוות שלי הוא צוות מאוד מגוון, ואחד מהדברים היפים שלגאוותי הצלחתי להרים, או החברה הצליחה, זה לאסוף אנשים מגוונים.
• יש לנו מישהו מתחומי הכימיה ויש הנדסה ביו-רפואית עם דוקטורט בכימיה, הנדסה ביו-רפואית והנדסת חשמל ופיזיקה ומדע המחשב
• וגייסנו בדיוק שני סטודנטים גם שיעזרו . . .
• אז באמת, הגיוון הזה מעיד על עצמו. כלומר, אם בעבר, אם נלך אחורה ל-96-97’, זה היה פרויקט ההנדסי שלי, במסגרת תואר ראשון להנדסת חשמל באוניברסיטת בן גוריון
• אז באמת התחלתי לעסוק - אז זה נקרא Signal Processing, Machine Learning . . . 
• ה-”Classical” , כמובן לא היה “Deep”  . . . 
• היו מודלים של פעם, מה שנקרא Gaussian Mixture Model ו-Hidden Markov Model - כל מיני מודלים כבר שאף אחד לא זוכר אותם.
• היית צריך לעבוד קשה כדי להיכנס לתחום
• אני, בתואר ראשון, עשיתי ארבעה קורסים בתחום ופרויקט הנדסי, שחרשתי עליו כל שנה ד'
• המשכתי ישר לתואר שני - הייתי עתודאי, זה היה תוך כדי הצבא - עשיתי . . .  כל התואר השני שלי בעצם היה קורסים ב-Machine Learning והתזה שלי ב-Machine Learning.
• המשכתי לדוקטורט וכו’.
• כדי להגיע למצב שבו אני יוצא לתעשייה - יצאתי לתעשייה ב-2007, הסטארטאפ הראשון שעבדתי בו בעולם  הרפואי - הייתי צריך לעבוד קשה, להגיע עם כמעט דוקטורט מלא והמון קורסים והמון השקעה
• והמון Coding - אז זה היה ב-MATLAB ו-C וכאלה.
• היום המצב שונה לחלוטין, ולמעשה אני - גם כאדם בתחום - הייתי צריך להמציא את עצמי בחדש.
• כי ב-2012 קרתה לנו מהפכה, בזכות איזשהו בחור יהודי נחמד בשם Alex Krizhevsky [AlexNet, עם Ilya Sutskever ו-Geoffrey Hinton, ושוב למיטבי שמע - 363 GPU @ Nvidia].
• עבד ב-Stanford [ב-Toronto? . . .], עשה שם את הדוקטורט שלו, לא ניכנס ל-Details אבל בעצם כל העולם הזה עבר מהפכה.
• היום, כדי להיכנס לתחום - אפשר לראות את זה לטובה ולשלילה - לטעמי, ואני קצת אקצין -  מספיק לעשות קורס אחד טוב של Stanford
• זה CS231N למי שמתעניין - קורס בדיוק בעולם ה-Deep Learning ליישומי Vision
• ויש קורסים מקבילים כמובן במקומות אחרים, גם אני מלמד קורס דומה באקדמיה לא מעט שנים.
• ובאמת, מספיק לעשות קורס אחד טוב - אבל לעשות אותו כמו שצריך, להבין טוב את התיאוריה ולתרגל אותו - ואתה יכול יפה מאוד להסתדר.
• עכשיו, לא רוצה להגזים - בתעשייה, בדרך כלל היום התעשייה כן מצפה עדיין לראות אנשים תואר שני, עם תזה.
• גם אנחנו מחפשים אנשים טובים עם ותק בתחום וכמובן תארים ותזה וכו’.
• אבל עדיין אתה יכול לעשות הרבה דברים אחרי קורס אחד טוב - וכמובן, שוב, אתה צריך להשקיע
• אתה צריך ללמוד Python טוב הכל מבוסס על Python - אבל זה בהחלט אפשרי.
•  כלומר, החסם הוא הרבה הרבה יותר נמוך
• זה מאתגר, זה גם שואל את השאלה, ככה, אפשר לפתוח את זה לדיון שלם - אבל מה היתרון של אנשים כמוני, עם דוקטורט ופוסט-דוקטורט?
• לא סיפרנו או לא סיפרתי את כל קורות חיי, אבל פוסט-דוקטורט והרבה שנים באקדמיה ופטנטים  ומאמרים . . . 
• אני חושב שפחות היום . . . זאת אומרת, החסם הרבה יותר הרבה . . .
• זה יוצר גם תופעות שליליות, אגב - הרבה אנשים נוהרים לתחום, כי “AI זה AI”, המשכורות גבוהות, התנאים טובים, כולם רוצים לעסוק בזה
• הרבה אנשים נוהרים לתחום - ולא כולם טובים
• חלקם בינוניים, חלקם עשו כל מיני הסבות מקצועיות - אני לא פוסל, חלילה, אבל זה מאוד אינדיבידואלי.
• אתה צריך עדיין להשקיע כדי להיות באמת טוב בתחום שלך.
•  אז זה יוצר לא מעט בעיות. כלומר, גם אנחנו צריכים לברור טוב מאוד את האנשים, בתהליכים ובראיון מסודר  ומבחני בית
• אין מה לעשות, חייבים לבדוק טוב את החבר’ה, אנחנו באמת מחפשים את האנשים הטובים.
• אז מצד אחד, כן - לאנשים יותר קל להיכנס לתחום, לעשות הסבה המקצועית או ללמוד במסגרת הלימודים.
• אנחנו רואים היום אנשים בתואר ראשון, סטודנטים אפילו או כאלה שסיימו תואר ראשון - יש להם יכולות ויכולים כבר מ-Day One לפתח מודלים ולעשות הרבה דברים, ליצור אימפקט.
• לא צריכים תארים מתקדמים בהכרח.
• ויחד עם זאת, יש הרבה נהירה של אנשים שהם גם פחות טובים, עם פחות יכולות, פחות יכולת להבין טוב את המודלים.
• לי אישית מאוד חשוב שאנשים שאצלי בצוות יבינו טוב את המודלים שמאחורי הדברים, ולא רק ידעו להשתמש. 
• להשתמש זה מאוד קל, להריץ ChatGPT זה מאוד קל, כל אחד יכול.
• להבין מה קורה מאחורי המודלים - מתי אפשר להשתמש, מתי לא, דיברנו קודם על התפלגויות וכו’ ואמון, שינוי בהתפלגות . . . .
• מאוד מאוד חשוב עדיין להיות זהירים.
•  אז בהחלט זה יוצר . . . מצד אחד החסם ירד, מצד שני - נהירה שדורשת מאיתנו להיות יותר זהירים, בטח בעולמות הביטוח.
• אבל זה חלק מהאתגר, זה חלק מהכיף, ואנחנו מתמודדים עם זה, למזלי, בהצלחה.

• 
  

37:38 ה-Waze של ה-Machine Learning(רן) כן, אני אנסה אולי להציע תיאוריה, או לפחות לשאול אותך על דעתך, למה יכול להיות שזה קרה. אז נגיד, אפשרות אחת זה אולי כי הכלים יותר “בוגרים”, הכלים יותר מוכנים. זאת אומרת, כמו שאמרת, אפשר להריץ, כל אחד  יכול להשתמש ב-GPT וגם בכלים יותר מורכבים, הם פשוט הרבה הרבה יותר נגישים ממה שהם היו פעם. אז זו, נגיד,יכולה להיות תיאוריה אחת. תיאוריה אחרת היא שאם אולי קצת לחזור לשיחה על האספלניביליות (Explainability), גם ככה אף אחד לא מבין . . .  זאת אומרת, המודלים כל כך גדולים, גם ככה “הכל שם בנפנופי-ידיים”, ככה שאין ערך-מוסף להבנה עמוקה  בסטטיסטיקה או ב-Machine Learning. זאת אומרת, יש פה קצת יותר תחושות-בטן, אולי, ככה, ניסיון הנדסי,אבל לא בהכרח הבנה מתמטית, כי גם ככה ההבנה המתמטית לא כל כך עוזרת.(אורי) . . .  גם יש הרבה דברים שהם Off the Shelf - אתה לא צריך לבנות אותם, אתה לא צריך להבין אותם מתמטית . . . (רן) כן כן, זה היה פחות או יותר הטיעון הראשון שלי. זאת אומרת, זה פשוט יותר נגיש, יש יותר כלים. כמובן, זה לא . . . הטיעונים לא סותרים, אבל יש לך איזשהו Take על מה גורם לשינוי הזה?

• (דרור) אז אני אקח את זה רגע, באמת עם דוגמא מהצוות שלי.
• אנחנו . . . אני התחלתי כאדם, כעובד יחיד בצוות ה-AI, ולאט-לאט זה התרומם, ובנינו בצוות תשתית מאוד מאוד טובה, השקענו המון בתשתית
• תשתית קוד, לפני עידן ה-ChatGPT וכו'
• ואני כל הזמן אומר למנכ״ל ול-CTO - לאיתי ולנמרוד - אני אומר להם תקשיבו . . . 
• נגיד דיברנו קודם על המודל של ההערכת-סיכון על בסיס תמונה, אמרתי שזה שורת קוד אחת
• והם אמרו לי “מה זאת אומרת שורת קוד אחת? על זה משלמים לך?!”
• אמרתי “כן, זה שורת קוד אחת, בנינו תשתית טובה - ואלגוריתם היום זה שורת קוד אחת”
• והם לא האמינו לי . . . והראיתי להם.
• אז כן, יש מצבים היום שזה שורת קוד אחת, ויש לך כלים כמו GitHub Copilot ויש לך Cursor, שמאפשרים לך לכתוב.
• ומאפשרים לך לכתוב קוד “מאפס” וזה עושה יופי של עבודה.
• ועדיין, לדעתי, אתה כן צריך להבין מה אתה עושה, כי אם אתה לא תבין מה אתה עושה, אז תקלה כמו שהייתה לנו, היה לוקח חודשים להבין אותה.
• אני באתי עם ניסיון והכרתי וחוויתי את זה גם בעבר, אז היה לנו יחסית קל לזהות את זה.
• ועדיין - הרבה שיעורי-מוחות וחקירות.
• אני חושב שעדיין, אני מאמין גדול שאתה צרךה להבין את המתמטיקה.
• נכון, אפשר להצליח גם בלי זה. אני רואה הרבה אנשים שמצליחים יפה מאוד בחברות אחרות, גם בלי להבין את המתמטיקה, את הארכיטקטורה.
• אני אולי קצת Old Fashion, אני עדיין מצפה מאנשים בצוות שלי ובטח ממני, להבין טוב את הארכיטקטורה, את המתמטיקה מאחורי הדברים, כדי לדעת להתמודד עם בדיוק המצבים שתארתי קודם. 
• אז בעיניי זה “יהרג ובל יעבור”. 
• אני אתן רגע דוגמה אולי עם עולם אחר - אני מלמד קורסים של Introduction to Machine Learning כבר הרבה שנים באקדמיה, בין היתר במכון הטכנולוגי בחולון ואוניברסיטת בן גוריון.
• ולא מזמן הרצאתי קורס בסמסטר קיץ, ולאורך הסמסטר, הסטודנטים - יש להם מטלות, והשתמשו ב-ChatGPT, אני לא יכול למנוע.
• אני אפילו מעודד את זה, כי אין מה לעשות, זה מאוד עוזר, גם אני משתמש על בסיס יומיומי בכלים כמו ChatGPT. 
• אבל אמרתי להם, מתחילת הסמסטר, “חבר'ה, אתם צריכים לדעת מה אתם עושים, אתם צריכים להבין”
• כי בסופו של דבר יש בחינה, ובתעשייה גם תבחנו בלי . . . אתם צריכים יכולת לקודד ולהבין מה אתם עושים. 
• באמת הייתה בחינה, ובבחינה הם צריכים פתאום בלי ChatGPT להסתדר ולכתוב קוד
• לא מ-0, אבל לדעת לתקן קוד, להבין למה הקוד לא עובד - אז צריכים להתמודד עם זה. 
• אז מי שלא עשה כלום כל הסמסטר, אז באמת התקשה בבחינה, וכנראה צריך לעשות מועד ב’.
• ומי שכן הקשיב וכן קודד בעצמו והבין - אין בעיה להשתמש בכלים - זה חובה להשתמש - אבל עדיין זה לא פותר אותך מלהבין מה אתה עושה. 
• (רן) כן, פעם היו מפחדים מבחינות עם Closed Books, היום הם מפחדים מבחינות עם “Closed GPT” . . . 
• (דרור) לגמרי .  . 
• זה כמו, אגב, Waze -  אני זוכר שנסעתי בזמנו לכנס, לפני הרבה שנים - ב-2009 נדמה לי - כנס באיזושהי מדינה בקנדה, אני לא זוכר בדיוק.
• ונסענו, הייתי עם המשפחה, נסענו לכנס מניו יורק, משדה התעופה לקחנו רכב, נסענו צפונה, וכיוונתי את ה-Waze.
• בהתחלה לא בדיוק הסתכלתי, כיוונתי לאן שכיוונתי, ובסדר.
• התחלנו לנסוע, ואז משהו לא מסתדר לי בדרך . . . 
• (רן) . . . גילית שאתה במקסיקו? . . . 
• (דרור) . . .  גיליתי שכיוונתי למדינה הלא נכונה בקנדה, עם אותו שם של עיר . . . 
• ואם לא היינו שמים לב, אז כנראה שהיינו נוסעים הרבה יותר ממה שצריך.
•  אז Waze לא פותר אותך משנייה להבין את המפה, את הגיאוגרפיה, ולשים לב לאיך אתה מתנהל
• אותו דבר גם בעולם ה-Machine Learning.
• (רן) . . . וגם שאנחנו פה בצפון, ולא כל יום יש GPS . . .
• (דרור) אתה צריך לדעת להסתדר . . .

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

• (דרור) לגמרי. אני חייב לקחת את זה רגע - דיברת על GPS, ולא מזמן, אני לא זוכר בדיוק את ה-Timeline, אני עושה משמרות באופן קבוע כפאראמדיק במד”א
•  ויום שישי אחד היה את הבאג הזה, היה איזה באג עם Microsoft, עם איזשהו GPS, נכון? כל ה-GPS-ים של מד”א הפסיקו לעבוד . . .
• הוציאו אותנו לקריאה לאיזושהי החייאה בבית אבות, אני לא זוכר בדיוק איפה.
• מערכות לא עובדות, אין לך Waze, אתה לא . . .
• עכשיו בגלל כל הבלגן, אז גם המוקד קשה, עמוס
• ויוצאים להחייאה, והבנאדם . . . . בקיצור, למזלנו, מד”א מספר ימים לפני זה, תרגל את זה על יבש - בדיוק את המצב הזה, אז כולם ישר פתחו פקל”אות, ידעו בדיוק איך להסתדר.
• עדיין הם צריכים להסתדר בלי Waze - זה לא טריוויאלי, אתה מגיע למקום, איפה זה, לא פשוט . . . 
• גם טלפונים וחלק מהמכשירי הקשר לא עבדו . . . 
• בקיצור, היה חתיכת בלגן, אבל באמת בגלל שמד”א נערך מראש . . .
• וזו בדיוק דוגמא טובה - כשאתה נערך מראש, אתה יודע להסתדר גם בלי ה-GPS.
• אז ברור שזה קצת פחות טוב . . . 
• (אורי) . . . וגם בלי Microsoft . . .
• (דרור) . . . גם בלי Microsoft . . . אז עדיין אפשר לחיות ולהחיות, גם.
• באותו מקרה זה לא הצליח, אבל זה בלי קשר.
• (רן) נאחל להצלחות בפעם הבאה . . . .

43:24 סיכום וגיוסים(רן) טוב, תודה רבה,  דרור מחברת Honeycomb. וכן,  אמרת שאתם מחפשים - אז ספר לנו על החברה: איפה נמצאים? כמה עובדים? מה עוד מחפשים?

• (דרור) אז החברה - קודם כל, By Far החברה הכי טובה שעבדתי בה, ולעוד שנים רבות, אני באמת אוהב את החברה.
• החברה היום כוללת . . .  רק אתמול הצטרפו שבעה עובדים, אז היום לדעתי זה כבר מתקרב ל-130 עובדים בכל העולם.
• פולין, ישראל וארצות הברית.
• אנחנו כרגע בהרצליה-פיתוח, אבל בראשון לדצמבר עוברים למשרדים משלנו, ב-Midtown.
• ומגייסים עובדים כל הזמן - אנחנו מגייסים, מפתחים
• אגב, גם בארץ וגם בארצות הברית
• אם נהיה טיפה יותר ספציפיים, לצוות שלי
• קודם כל, כל הזמן מחפשים אנשים טובים בחברה
• אבל לצוות שלי, אנחנו מחפשים אלגוריתמאים בשלושת התחומים - גם בעולם ה-Computer Vision, גם בעולם ה-Tabular Data, דאטה-טבלאי, וגם בעולם ה-NLP.
• אנשים טובים - רצוי עם תארים מתקדמים: תאור שני, תזה בתחום.
• תגישו מועמדות - יש לנו לא מעט משרות עכשיו, אנשים שבאים באמת לעבוד בסביבה דינמית, עם אימפקט.
• אני - הדבר שהכי חשוב לי בחברה זה אימפקט - אגב, מתחבר למה שאני עושה במד”א. 
• אימפקט בעיניי זה הדבר הכי חשוב, ו-Honeycomb מאפשרת את זה.
• היכולת לעשות שינויים - גם לטעות, לא קורה כלום, לטעות, ללמוד - זה הדבר שאני אוהב ב-Honeycomb
• אז אני מזמין כל מי שבתחום לבוא ולהגיש מועמדות - אחלה מקום, בואו!

(רן) טוב, אז תודה רבה דרור, בהצלחה ל-Honeycomb - ובהצלחה במד”א.תודה רבה.
 האזנה נעימה ותודה רבה לעופר פורר על התמלול!

[קישור לקובץ mp3]פרק מספר 480 של רברס עם פלטפורמה, שהוקלט ב-30 באוקטובר 2024. אורי ורן מארחים בפרדס חנה - כרכור את רועי - מנהל ומפתח בחברת Hello Heart לשיחה בדיוק על המעברים האלה, שבין ניהול לפיתוח לניהול.
01:05 על רועי ו-Hello Heart(רן) ספר לנו קצת עליך וקצת על החברה, שנכיר?

• (רועי) בשמחה - אז אני רועי, אני בן 40 גר בתל אביב, מפתח מכיתה ד' . . . .

(אורי) כבר אז היה לך קול רדיופוני? או שהסיגריות התחילו אחר כך . . . .(רן) לא אמרנו מפתח-קול . . .

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

(רן) אוקיי, ומתי פגשת את הלב שלך ואמרת לו שלום? [הפסקה מתודית מתבקשת]

• (רועי) את הלב שלי פגשתי בשלב מאוד מוקדם בחיים שלי - את Hello Heart פגשתי לפני שנתיים . . . 
• חברה שאני מאוד מאוד אוהב ומאוד מאוד גאה לעבוד בה - שבעצם נותנת פתרון שעוזר למשתמשים שלנו לנטר, לשמור ולשפר את בריאות הלב שלהם.
• עובדים בעיקר בשוק האמריקאי . . .

(רן) אז זאת אומרת שלקוח הקצה הוא אותו פציינט (Patient) פוטנציאלי, אותו משתמש - או שזה רופאים ומוסדות וכאלה?(אורי)  . . . . חברות ביטוח-רפואי וכאלה . . .

• (רועי) אז לקוח הקצה שלנו הוא המעסיק
• המשתמשים שלנו הם עובדים אצל המעסיקים - שמקבלים את האפליקציה בחינם.
• אנחנו יודעים לשפר את בריאות הלב ובעצם להוריד לחץ דם סיסטולי ולעזור להם לחיות יותר נכון - וזה מתורגם להחזרים ביטוחיים הרבה יותר נמוכים.
• בארצות הברית - מעל כמות מסוימת של עובדים, המעסיקים הם Self-Insurers, ולכן בעצם אנחנו מאפשרים להם לשלם לנו כסף.
• העובדים שלהם מקבלים את האפליקציה בחינם וחיים חיים בריאים יותר - והלקוח שלנו חוסך כסף
• אז זה מעיין “משולש-זהב" נחמד.

(רן) יש בזה גם אמצעים רפואיים - כאילו, חומרה-רפואית או כאלה - או שזה הכל כזה “רק” אפליקציה-נטו ו...(אורי) שעון?

• (רועי) אז אין שעון - וליוזרים (Users) שלנו אין את הסביבה שתומכת בשעונים חכמים.
• אלו בדרך כלל עובדי צווארון-כחול, שהתלהבו מהחומרה שכן יש לנו - שהיא מוניטור לחץ דם, שיודע להתחבר Bluetooth לפלאפון.
• מבחינתם, ה-Connectivity הזה היא “נס” - זה משהו ששמענו באיזשהו ראיון עם אחת היוזרים.
• אנחנו גם מפתחים עכשיו חומרה בעצמנו - זה משהו שקורה פעם ראשונה והוא מאוד מאתגר מהאספקט של ניהול טכנולוגיה, אבל עיקר הפוקוס הוא על האפליקציה.
• ומשהו שקצת Unique-י בעולם הרפואי זה שהפוקוס הוא על User Experience - כי בבריאות הלב, רפואה מניעתית היא מאוד מאוד חשובה.
• אנחנו יודעים מה צריך לעשות כדי לשפר מאוד את הסיכויים שלנו - ופה זה פוגש את האלמנט האנושי, שלא רוצה לעשות את זה . . . . 
• לא רוצה לרוץ, לא רוצה לאכול נכון, לא רוצה למדוד לחץ דם כל יום . . . .
• [“Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so.”]
• ובעצם יש לנו בעיית Engagement - שמתורגמת בעצם לרווח בריאותי, זה מאוד נחמד.

04:53 לב העניין - מנהל-מפתח-מנהל-מפתח-…(רן) מעניין, אז הסתקרנתי על Hello Heart - אבל זה לא בעצם הלב של השיחה, אפשר גם להגיד אולי כמה מילים על החברה בסוף, אני בטוח שאתם מחפשים אנשים טובים . . . אבל יצא לך - ואני מניח שלא רק לך בתעשייה - אבל יצא לך לעשות מספר מעברים בין להיות מפתח למנהל או IC [Individual Contributor] ושוב מנהל - וכל אחד מהמעברים האלה לימד אותך קצת - גם לעשות את התפקיד הנוכחי יותר טוב, גם אולי לנהל יותר טוב או גם לעבוד עם מנהלים בצורה יותר נכונה - וחשבנו שיהיה מעניין לדבר על זה ולשמוע את התובנות שלך, כי שוב, כאמור, זה כנראה קרה לפחות ל-50% מהעובדים בתעשייה, אז שווה גם לחשוב ולאפטם (Optimize) את הדבר הזה.אז תן לנו ככה קצת רקע לסיפור - איך זה היה מבחינת ה-Timeline פחות או יותר? אילו תפקידים עשית ואיזה מעברים קרו לך.

• (רועי) אז באמת, אני התחלתי את קריירת הפיתוח שלי באמצע הלימודים - עבדתי בחברת פרויקטים כג'וניור שלא מודע לג'וניורותו . . . .
• משם, בעצם דרכם, הקמתי את החברה הראשונה והיחידה שהקמתי - הם היו כמו חממה שלנו, ועם Title שהיום אני קצת מתפדח להגיד של “מנכ”ל”, בעצם התחלתי את כל הסיפור.
• אחרי בערך שנה, כשהבנתי שאני לא מתאים לתפקיד, השארתי את החברה בידיים של השותף שלי, שהמשיך איתה כמה שנים, ועברתי להיות מפתח מתחיל ב-Trusteer.
• בתוך Trusteer, שהפכה ל-IBM באיזשהו שלב, בעצם התקדמתי לכיוון ניהולי יחסית מהר - בערך שנה, שנה וחצי אחרי שהתחלתי שם כבר הובלתי צוות.
• משם עליתי ל”ראש צוות בכיר”, מה שזה לא יהיה, ואז לראש-קבוצה
• ואחרי חמש שנים ב-IBM עברתי בעצם לתפקיד VP הראשון בחברה שנקראת CYE.
• ושם, בערך אחרי שנתיים, הגעתי לאיזושהי נקודה שבה הייתי צריך לחשוב מה אני עושה  . . .

(אורי) כי מיצית?

• (רועי) וואו, זאת שאלה קשה . . . אני חושב שזה היה שילוב של הרבה גורמים.
• אני חושב שקודם כל, מי שבאמת באמת אוהב את התחום ומגיע מעולם של אהבת תוכנה, שזה משהו שהוא מאוד נפוץ, לשמחתי, אבל כן הולך לכיוון של הניהול - יש תמיד דיסוננס שמלווה אותך, בין הקריירה שאתה רוצה למה שאתה רוצה לעשות כשאתה רואה מחשב.
• כי כשאני רואה מחשב, אני רוצה להסביר לו מה לעשות - אני רוצה לכתוב שורות קוד.
• אין עונג בעולם הזה שמשתווה לקוד שכתבת ורץ סוף סוף.
• (אורי) כמו בכל יצירה, נכון? אתה יוצר מחומר משהו, אתה יוצר משורות קוד משהו, זה דומה.
• (רועי) זה זהה . . . אני חושב ש . . .
• (אורי) פשוט הכלי הוא אחר, אבל זו יצירה.
• (רועי) הכלי הוא אחר אבל זה מעניין . . .  זה קצת Detour מהשיחה, אבל זה מאוד מעניין להסתכל על Code Review למשל, ולראות איך אנחנו כמפתחים משתמשים בשפה שהיא מאוד אסתטית
• “זה קוד יפה”, “זה קוד מכוער” - זה משהו שאני חושב מראה שבסוף מדובר בתהליך של יצירה, שיש בתוכו את האיכויות האלה.
• כולנו יודעים שאפשר לראות קוד והוא יהיה יפה או ממש ממש לא - וזה כמעט אורטוגונלי (Orthogonal) לשאלה “האם הוא עובד”, לפעמים אפילו סותר . . . .
• (רן) למרות שאת יורדי-הים לימדו שקשר טוב זה קשר חזק, נכון? יש כזה משהו . . .  סליחה, קשר יפההוא קשר חזק.

• (אורי) אבל גם, כאילו - הקשרים הטובים, הם קשרים שאפשר להתיר אותם . . .  זה כמו שאתה מכין את הקוד שלך ל-Refactoring, כי אתה יודע שזה יבוא מתישהו, הדבר הזה, או שמישהו אחר יצטרך לפתוח את הקשר. זה כמו . . . .

• (רן) אבל אם אתה רואה סירה קשורה עם קשר מכוער כזה, אז אתה קצת מפחד, נכון? . . .  “אוקיי, יש פה בעיה”.

• (רועי) אבל לפעמים אתה יכול לראות קשר יפה שהוא לא חזק, וגם קוד - יכולות להיות חתיכות קוד מדהימות . . . 

• (אורי) . . . אבל לא רובסטיות (Robust)

• (רועי) לא רובסטיות, לפעמים פשוט לא נכונות . . . . היופי שם הוא משהו שקיים, לכשלעצמו.

(רן) זאת אומרת, תמיד יש לך איזשהו מתח בין האהבה שלך לקידוד, האהבה שלך ליצירה של קוד, לבין, אולי, הקריירהשהיית רוצה שתהיה לך, שזו קריירה של “מנהל בכיר”, כמו שהגעת אליה.

• (רועי) “כמו שאמא רצתה” . . . . 
• אז הרקע הזה היה שם - אבל הוא לא היה מספיק.
• כי בסוף, קשה מאוד לקבל החלטה כזאת - הייתה שם הצטברות של נסיבות.
• בדיעבד, אני יודע להגיד שזה היה שילוב גם של ילדים בגילאים שהם דורשים הרבה תשומת לב וגמישות שאין לך כמנהל שצריך להיות זמין.
• וגם בדיעבד, Culture-fit פחות טוב עם המקום שעבדתי בו.
• ואני חושב שזה הוביל אותי לנקודה שבה אני אמרתי אוקיי, אני צריך משהו אחר - ו”המשהו האחר” הזה צריך להיות פיתוח.

(אורי) זה מעניין, הנושא של ה-Cultural Fit . . . כאילו, זה לא גרם לך להרגיש גם בתור מפתח שאתה לא במקום עם עם -Cultural Fit נכון, ואולי פשוט עדיף לא להיות במקום?

• (רועי) היה לי מזל לעבור להיות מפתח במקום שאני חושב - אני מקווה, צריך לשאול אותם - שהייתי Cultural Fit מאוד מתאים . . .

(רן) כלומר, בחברה אחרת . . . (אורי) בחברה האחרת, כן.(רן) אני חושב שמה שאורי שאל, ואולי אין לך את התשובה לזה, אבל האם באותה חברה, שבה הרגשת אי-התאמה בתור מנהל, האם הרגשת אחר כך כן התאמה בתור מפתח, אבל כמו שאמרנו - זה לא היה A/B Testing לזה  . . .

• (רועי) לעולם לא נדע, אבל אני חושב שהתשובה הייתה “לא” . . .

(אורי) כי עברת מקום . . .

• (רועי) גם כי עברתי מקום, אבל גם כי בדיעבד, אני לא חושב שזה יעבוד שם ואני לא יודע אם זה בגלל שלא היה Cultural Fit, גם כמפתח, או בגלל שאני כרועי - עם האגו שלי והדברים שאני סוחב, לא הייתי מצליח להכיל את זה.
• כי כמו שלמדתי שהגעתי ל-Salto, החברה שבה כן עבדתי כ-IC [Individual Contributor] - “האפסון” הזה של האגו בצד וההפיכה שלך לסוג-של-ספוג הייתה מאוד קריטית
• גם להצלחה וגם להנאה שלי בתפקיד.

(אורי) ההפיכה שלך לסוג של ספוג בקטע טוב, זאת אומרת . . . (רן) “טאבולה ראסה”, מוכן לספוג דברים . . .(אורי) לבוא וללמוד . . .

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

(אורי) ותוך כמה זמן מצאת את עצמך שוב בניהול?

• (רועי) שנתיים וחצי . . . קצת נשלפתי . . . 

(אורי) האמת שזה הרבה . . . .

• (רועי) זה הרבה. היו שנתיים וחצי מדהימות - והרגשתי רוויה כבר בשלב הזה.
• זאת אומרת, כמו ש”דגדג לי לחזור לפתח”, זה כבר היה שלב, אני חושב בגלל הדרך ש-Salto עשתה.
• היא מאוד גדלה והתפקיד שלי כמפתח טיפה השתנה.
• אבל כבר הרגשתי דגדוגים של אולי לחפש לחזור לזה.
•  ואז היה לי מזל שמיכל, ה-CTO של Hello Heart, שעבדה איתי בעבר, פנתה אליי ובעצם הציעה לי לבוא ולדבר ולראות ולהתראיין אם אני אוכל לעשות את התפקיד הנוכחי.
• לשמחתי זה הבשיל.

12:30 התמודדויות, פינות ולמידה מחדש(רן) אז בוא רגע נדבר על הנקודה שבה סיימת להיות מנהל, עברת ל-Salto ונהיית מפתח, נגיד ג'וניור. זאת אומרת,כנראה שמבחינת קריירה במקום קצת יותר אחורי ממה שהיית לפני זה - ואתה לא חייב להסכים, אני מציע.זו חוויה של . . .  פתאום אתה צריך ללמוד, אוקיי? אתה לא מוביל, אתה צריך ללמוד. יש בזה אולי את החווייה של הלימודים, אבל אולי גם הזכרת מקודם אגו, אז מעניין איך התמודדת עם זה.וגם אני מתאר לעצמי שראית מנהלים, אולי מעליך ואולי ליד, שכאילו דגדג לך לבוא . . . כמו שאתה עושה Code Review למישהו, זאת אומרת, דגדג לך לבוא ולתקן את הקוד שלו, אז דגדג לך לבוא ולתקן את הניהול שלהם, אבל פתאום אתה בפוזיציה אחרת . . . אז איך התמודדת עם כל זה?

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

(אורי) אבל זה בחמישייה הראשונה של הארגון פיתוח - אין הרבה מעמדות, אין הרבה . . .

• (רועי) נכון - וזה עזר, כי הסיפור שסיפרתי לעצמי הוא סיפור של “אוקיי, אבל עדיין יש Impact”.
• ובאמת היה המון Impact,  כי מפתח - בטח מפתח, אני אגיד את זה בזהירות, “כמוני” [הקומיטים שלי טובים] - שיודע לדלבר (Deliver) מהר, יכול לעשות המון Impact בארגון קטן.

(רן) זאת אומרת, זה לא רק להיות מפתח - זה גם להיות Founding Member בחברה . . . (אורי) גם מי שמנהל הוא IC, רוב הזמן . . . .

• (רועי) כן ולא . . . - זה נכון שהמנכ״ל כתב את האתר המרקטיאלי (Marketing) הראשון וכמובן שהסתיר בתוכו משחק של Pong . . . . 

(רן) גיל היה המנכ״ל?

• (רועי) המנכ״ל היה רמי. גיל דווקא לימד אותי את החשיבות של להיות מוכוון יותר לבניית הצוות.
• וגם צריך לבוא ולהגיד - שוב בדיעבד, לא הייתי מאוד מנוסה כמנהל כמו שחשבתי.
• ולראות אנשים עם גישה שונה ועם ותק שונה נתן לי פרספקטיבה גם בכיוון הזה.
• אבל יש איזה רגע אחד, שאני זוכר שאולי “קימט בתוכו”, הוא היה בדיעבד רגע מכריע, שהיה יכול ללכת לשני כיוונים מאוד מאוד שונים - שזה היה ה-Code Review הראשון שלי.
• ושוב, דיברנו על זה טיפה קודם - Code Review הוא משהו מאוד רגשי.
• זאת אומרת, מעבר לעובדה שהוא מאוד “אסתטי” באופי שלו, גם כל הקרביים שלנו נשפכים לתוך הקוד.
• “הקוד שלך זה אתה”.
• ואני זוכר שהגעתי ל-Code Review הראשון שלי, תיקתקתי עבודה, זה בעצם היה Commit שסגר מעגל פעם ראשונה והפך את המוצר למשהו שעובד.
• שש-שבע שנים לפני זה, אני הייתי זה שעושה את ה-Code Review אז אני הייתי זה שמכתיב את ה-Guidelines.
• והגשתי את מה שלעניות-דעתי היה ה-PR המושלם - בגדול, ציפיתי למחיאות כפיים. little did I know שלא תמיד זה נראה ככה.
• עד היום, מפתחים שמקבלים ממני . . .  אני כבר לא עושה כל כך הרבה Code Reviews, אבל כשאני עושה  אני מראה להם את ה-PR הספציפי הזה.
• כי אותו קוד הוא Open Source, אז זה עדיין שם ב-GitHub.
• אני חושב שהיו שם מעל למאה הערות . . . החל מ-Nitpicking, סטיילים שונים של קוד שאני בכלל לא הכרתי, דרישות לטסטים, באגים שפספסתי . . . 
• באמת, כמות מאוד מאוד גדולה של הערות.
• ואני הרגשתי את החום הזה שעולה בגב אחרי שמבקיעים גול עצמי בטעות בשכונה . . . 
• “מי אני? למה אני פה? מה אני עושה עכשיו?”
• ובנקודה הזאת החלטתי שאני סופג - שבמקום לבוא ולהתחיל להתווכח על כל הערה, אני - לפחות בתקופה הראשונה - פשוט מבצע את התיקונים.
• ואני חושב שזה עזר מאוד.
• זאת אומרת, מאותה נקודה בעצם ראיתי מה אני יכול ללמוד.
• ועם הזמן גם עוד פעם בניתי את הביטחון לבוא ולהגיד “רגע, זה משהו שאני יודע שהוא לא נכון”.
• ועברתי בעצם תהליך “סיניוריזציה” (Seniority) מאוד מאוד מזורז
• כי את הרקע, את המערכתיות, את ה-Design-ים - זה כבר היה לי.

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

• (רועי) אני חושב שכן.
• שוב, בעיקר - וזה משהו שאני אגיד בזהירות, מאפיין יחסית את מסלול הקריירה הישראלי, שבו הרבה אנשים עוברים לניהול בשלב יחסית מוקדם.
• כי היו לי המון לאקונות על חוויות של מפתחים . . . אני כן אגיד שגם אמרת קודם שלא למדתי להיות מפתח ברמה הטכנית - אני לא אסכים איתך.
• כשאתה מנהל שבע שנים, העולם מתקדם - סטנדרטים משתנים, תשתיות משתנות, קונספטים נכנסים . . . 
• נגיד, אני התחלתי לנהל בתקופה ש-Manual QA היה Must - וחזרתי לפתח בתקופה ש-No QA היה בשיא ה-Hype
• את זה, אגב, לא לקחתי בשום צורה - אני אוהד מאוד גדול של QA ידני . . . 
• וגם יש גישות שונות לפיתוח - למשל טסטים: אני למדתי לפתח בחברה שבה לא עשו טסטים.
• אנחנו יכולנו לעשות Deploy ל-Production מהר, Production עוד לא היה עם Container-ים אז היה VM ב-Production, שזה טוב כמו טסטים . . . 
• ובאמת הגעתי לחברה, שבה אחד מהמפתחים הבכירים האחרים, פשוט יצר לנו את הסביבת פיתוח, שם Threshold של 99.7% Test Coverage - ופרש לחדרו . . . 
• (רן) “ישחקו הנערים לפני” . . .
• (רועי) ממש . . .  וזה משהו שלקחתי איתי, כי הבנתי פתאום את ה-Benefit שלו “מהידיים”.
• כי פתאום הרגשתי את התחושה הזאת של לעשות שינוי כשאתה יודע שיש לך Test Coverage, ואיך זה משפיע על Velocity.
• דברים שכשאתה לא חווה אותם - קל לפספס.

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

• (רועי) נכון - וגם לפעמים זה שאתה נתקל במנהלים אחרים עוזר לך למצוא את הסגנון שלך.
• יש דברים שאימצתי לחלוטין, ויש דברים שראיתי ואמרתי ““זה יכול להיות טוב, אבל זה לא אני”.
• וזה עוזר לדייק אותך ולציוק קצת אותנטיות באיך שאתה מתנהל, ואני חושב שזו איזושהי נקודת מפתח בניהול, אני מקווה מוצלח.
• זה גם נותן לך לראות דברים שאתה לא רואה ממקום אחר.
• פרויקטים ארוכים זה דוגמה מאוד טובה - כי זה הרבה פעמים יש Friction בין הנהלה לבין המפתחים, שלקחו את הפרויקט הזה.
• וזה נגיד משהו שהשתנה אצלי מהותית. בתור מישהו שהוא מאוד Velocity ו-Delivery-Oriented באופי שלו, אין לי סבלנות.
• והיה פרויקט ספציפי, “פרויקט הדגל” שלי בעצם, שעבדתי עליו כמפתח - שהוא פרויקט שמנקודת המבט של מנהלים היה יכול לראות כישלון מוחלט - ובצדק.
• ומצד שני, כמפתח הוא אחד הפרויקטים שאני הכי גאה בו בחיים.
• טכנית, היה איזשהו משהו שיצר Limit-ביצועים די רציני במערכת, ברמת ה”אי אפשר להשתמש בה על מידע אמיתי” . . . 
• בפועל, היינו צריכים לעשות איזשהו שינוי שהחליף לנו פונקציה מאוד בסיסת ל-Promise, וזה תורגם בעצם למשהו שהערכנו בחודש עבודה.
• עשינו אותו בחודש עבודה - ואז ראינו שהוא שבר את כל הטסטים בצורה שמאוד קשה להתמודד איתה  . . .
• והיה שם אתגר טכני מאוד קשה והתמודדנו איתו יפה - זאת אומרת, ה-Velocity של הפיתוח ופתרון הבעיות בפרויקט הזה היו בשמיים - אבל פספסנו את ה-Estimations בחודשיים.

• (רן) ומבחינת ההנהלה - לא עשיתם כלום . . . . כי לפני זה היה מוצר, אחרי זה היה מוצר - מה ההבדל? הם לא היו מודעים למגבלת Performance הזו, מגבלת-הביצועים הזו שהזכרת . . . 

• (רועי) הם היו מודעים למגבלת ביצועים - בגלל זה בכלל נתנו לנו לצאת לזה.
• הם לא ראו את כל ההתקדמות שנעשתה בעצם “על ריק” - את כל “הריקושטים”.
• זה קורה תמיד ב-Refactor, זה תמיד קורה בשינוי תשתיתי - אתה משיג את המטרה, והכל נשבר . . . 

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

23:59 ההנהלה “מדברת MBA-ית” ואתה מדבר “Engineer-ית"(רן) דרך אגב, בדיעבד כמפתח אז ובהיותך מנהל לפני זה - אתה חושב שהיית יכול לנהל את המנהלים שלך יותר טוב? זאת אומרת, לנהל את הציפיות, לתקשר, או דרך אחרת לבוא ואתה יודע, להראות “הנה, תראו כמה אני מזיע פה - אתם תראו שזה הולך להשתלם לנו”?

• (רועי) אני חושב שהייתי מנהל את זה באותה צורה, כי יש פה קצת מהלך של “קורבן עצמי”.
• יש פרויקטים שאם אתה לא תעשה להם Under-estimation אז לא יקרו, והם צריכים לקרות.
• אולי . . . 

(רן) ודי לחכימא ברמיזה . . . (אורי) לא, אבל יש פה גם . . . אתה צודק במה שאתה אומר, יש פה הרבה דברים שזה שייך לבדידות של מנהל פיתוח, שבעצם כל שאר ההנהלה “מדברת MBA-ית” ואתה מדבר “Engineer-ית”, הארגון שלך מדבר “Engineer-ית”, והארגון, התרבות, השפה, הכל - ה-Incentives. וכמו שאמרת “מה שלי נראה פרויקט מאוד מוצלח, מבחינת ההנהלה הוא כישלון גמור” - זה חלק מהמקום הזה, הבדידות הזאת.

• (רועי) אני חושב שזה משהו שאפשר להרגיש גם כמפתח - שאתה חוזר הביתה ומנסה לדבר על העבודה שלך.
• כי יש משהו ב. . . אם אתה עורך-דין או איש מכירות, השפה שבה אתה משתמש לתאר את העבודה לך היא שפה שכולם מבינים, אתה יכול לספר סיפור.
• כמפתח זה לא נכון - מי שלא מפתח לא יבין למה זה שעשית עכשיו Refactor של אלפיים קבצים ב-sed זה משהו שהוא, אתה יודע, “מרגש” . . . וזה אותו דבר.
• פה אני חייב להגיד שאני לא מרגיש היכולות שלי לתקשר את זה מסביב השתפרו. . . .
• אבל אני כן פיתחתי את היכולת להגן על מאמצים כאלה.
• זאת אומרת, בסוף כמנהל שצריך לגשר בין ה-Business ל-Engineers, אתה לבחור איפה אתה נותן את הגב.

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

• (רועי) רק נדייק - מנהל שחושב שהוא יותר טוב, who am I to say . . . .

(רן) פה אפשר לחלק קרדיטים חינם [מאות עובדי AWS מרגישים הפרעה בכוח . . . ].

• (רועי) הכי טוב . . . .

(רן) אם אהבתם - תעשו לנו חמישה כוכבים ב-Apple ו-Spotify [גם אם לא] . . . . כן, אז באמת איך החוויה הזו, של לחזור להיות מפתח ושוב מנהל אחר כך, עשתה אותך מנהל - לכאורה - יותר טוב? אוקיי, נהיה זהירים . . . .

• (רועי) חשוב להיות זהירים בתקופה הזאת . . . .
• אני רוצה לקוות שבהרבה אופנים, אני חושב שזה עזר לי, אני חושב, להבין מה באמת קורה “בשטח” - משהו שאתה מתנתק ממנו עם הזמן.
• אני חושב שזה נתן לי הבנה אנקדוטלית על המון המון המון נושאים, שבסוף מצטברים לאיזושהי גישה שונה לניהול
• בעיקר סביב התנהלות מול מפתחים מאוד מאוד בכירים, מול Staff Engineers.
• ההבנה, למשל, שיש סוגים שונים של Staff Engineers, שכל אחד מהם תורם משהו אחר - וברגע שיש לך מישהוא טוב במשהו מסוים, Let him(or her) at it . . .
• ה-Staff שמחזיק ב-PR-ים את כל החברה, והוא לא יכול לעשות שום דבר אחר - הוא יכשל בכל משימת פיתוח שתיתן לו, כי הוא עסוק בלתת Value משוגע בלעשות PR-ים.
• ה-Staff Engineer כמוני, שפשוט יודע לקחת כל פרויקט ולתקתק אותו מההתחלה עד הסוף, להחזיק אצלו את הבעיות.
• ה-Staff שתמיד עושה תשתית, שנראית גנרית מדי שנה וחצי - עד שפתאום אתה מגלה שבדיעבד היא חסכה לך חודשי עבודה.
• אני חושב שזה עזר לי לשחרר, לתת לאנשים שאני יודע שהם טובים להתמודד עם בעיה
• ולתת להם את השקט לעשות את זה, לא לשאול אותם . . . 

(רן) דרך אגב, הנושא הקודם  - אורי, תקן אותי אם אני טועה, זה נקרא “ניהול מתוך חוזקות” או . . . נכון? זה אחד הנושאים החביבים עליך, זאת אומרת, למצוא במה כל אחד חזק, לתת לו ולא לנסות לחזק אותו אולי בתחומים שבהםהוא פחות חזק. זה פשוט לתת לו להתפקס (Focus) במה שהוא חזק.[הפרק המעולה הזה - 443 Hiring for strength, not skill with Sahaf from Hippo והספר המעולה הזה - First, Break All the Rules ]

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

29:30 יש מנהלים זיג-זג גם על אוניות(רן) עכשיו, יש דרך שלישית - זאת אומרת, פה תיארנו קריירה כסוג של “זיג-זג”: מנהל, מפתח, מנהל - אבל הדרךהאחרת לעשות לזה זה אולי להיות מפתח, מנהל שהוא Hands-On, כלומר ששומר לעצמו X זמן, X אחוז, כדי להיות Hands-On, או בוחר לעצמו באגים לתקן, או בוחר לעצמו פיצ'רים לעשות. וזה גם משהו שלא מעט אנשים עושים - או לפחות מנסים לעשות - ולפעמים זה מצליח יותר ולפעמים פחות.וזהו, רציתי אולי לעשות איזשהו Brainstorming ככה, שלושתינו, של Pros and Cons, להשוות את שתי הגישותולעשות, לחשוב למי יותר מתאים מה, איפה או לאיזה גישה יש יתרונות, באילו סיטואציות - זאת אומרת, “הזיג-זג”לעומת, נקרא זה “Hybrid” - מנהל שמנסה להישאר Hands-On באיזשהו אחוז מזמנו.(אורי) אני לא חושב שיש דבר כזה . . . . למה? כי זה לא משנה. ממש לא אכפת לי מה אתה עושה - תתקן באגים, תעשה PR-ים, לא יודע, תעשה מה שאתה רוצה - השאלה היא, בהגדרת התפקיד שלך - מה האחריות שלך? האם האחריות שלך היא על הקוד של עצמך או שהאחריות שלך היא על ההצלחה של הצוות, הבנייה של הצוות. האם האחריות שלך מסתיימת בך, או שהיא מסתיימת באנשים אחרים, שצריכים לעשות בסוף משהו.ועשית את הסוויץ' הזה . . . כאילו, אם אתה מתקן באגים או לא מתקן באגים - זה לא משנה, מה אכפת לי?(רן) אבל אורי, אתה מסתכל על זה מכיוון ה-KPI - אתה אומר . . . . (אורי) לא, בסדר - אני מסתכל על זה מהגדרת התפקיד . . .(רן) כן, אתה מסתכל על זה מהצד של הניהול הארגוני - של איך הכי נכון לנהל את התפקיד, איך אנשים יהיו הכי פרוטוקטיביים. אני דווקא רוצה לסתכל על זה מהכיוון של רועי. כשהוא דיבר מקודם על ה-Passion שלו “להיות בקוד”, האהבה שלו לקודד, מצד אחד, ומצד שני גם הרצון לבוא ועדיין ולהיות מנהל ולפתח קריירה, ואני מסכים שאולי זה לא הדבר הכי נכון ל-Business - לפעמים כן, לפעמים לא - אבל אני דווקא לא מסתכל עם הפרספקטיבה הזאת. אני יותר מסתכל עם הפרספקטיבה של ה-Gen-Z - של המימוש העצמי, של איך תרגיש יותר טוב, האם תרגיש יותר טוב, או בכלל, איזשהו ניסוי מחשבתי, השוואתי, בין “קריירת זיג-זג” נקרא לזה, לבין “קריירת Hybrid”, של מנהל שהוא גם 20% מפתח. ואני גם מבין את הפרספקטיבה של, כאילו, אוקיי - זאת אולי לא דרך נכונה לנהל - אבל שוב, אני מנסה להסתכל על זה מרמת ההגשמה העצמית.

• (רועי) אז אני חושב שברמת ההגשמה העצמית, אי אפשר להגשים את עצמך אם אתה לא מצליח - ואתה לא יכול להצליח להיות באמת מנהל, שעושה 20% Hands-On בשביל זה.

(רן) באף רמה, אגב?ז את אומרת, גם אם זה ראש צוות, או שלזה אנחנו לא קוראים “מנהל”?

• (רועי) זה חד-משמעית מנהל - אבל זה ניהול מסוג אחר.
• אני כן חושב - אם ניקח את השאלה לכיוון טיפה אחר - שבכל רמה שונה של ניהול, כן צריך להיות איזשהו אלמנט “בקיאותי””בתוכנה, שעד גודל מסוים מגיע הכי טוב מאיזושהי עבודה Hands-On-ית.
• אבל זה מאוד משתנה . . . 
• אז אם אתה רוצה להגשים את עצמך - פתח כתחביב: אפשר לעשות דברים מאוד מגניבים ולהגיע למקומות מאוד מעניינים.
• אבל במסגרת התפקיד שלך כמנהל, שרוצה להיות אפקטיבי ולהצליח - אתה צריך להיות Hands-On-י בצורה הולמת.
• אם אתה ראש צוות, אתה צריך לכתוב קוד ולהכיר אותו.
• אם אתה מנהל ברמה בכירה יותר - עדיין יש דברים שאתה חייב לחוות, כדי שתוכל לדעת מה צריך לתקן.
• אם לא עשית Deploy, איך תדע את המחיר הנוראי שכל הצוות משלם כשהוא מנסה לעשות Deploy?
• אם לא ניסית למצוא משהו בקוד, איך תדע שהשתמשתם ב-Constant-ים, ששברו את כל ה-Auto-Navigation ב-IDE, וכל דבר לוקח פי-ארבע? . . . 
• זאת אומרת, כדי שתוכל להקצות משאבים נכונים לפתרון בעיות בחוויית המפתח - שזה משהו שהולך ותופס יותר מקום ככל שארגון גדל - חייבים לגעת בזה.
• ופה אתה צריך לדעת איך לעשות את זה - בלי לייצר נזק.
• וזה קשה, כי כל דבר שתעשה, אם הוא חשוב למישהו, אתה במקרה הטוב תעשה אותו באיחור, ובמקרה הרע לא תעשה אותו בזמן או שתעשה אותו שגוי.

(רן) זאת אומרת, אם יש סיבה טובה להיות Hands-On, זה רק כדי שתוכל להיות מנהל יותר טוב, לא בשביל הערך “השיעורי” שלך בתיקון של באג נוסף, או הוספה של פיצ'ר נוסף.(אורי) כי החלפת מקצוע - אתה עברת להיות מנהל, החלפת מקצוע. וזה לדעתי הרבה מאוד מהאנשים שעושים את הסוויץ' הזה לא מבינים. אתה לא מנהל עכשיו כי אתה מפתח ממש טוב. אתה מנהל - אתה החלפת מקצוע, וההצלחה שלך תלויה בהצלחת הצוות ולא בהצלחה האישית שלך. גם הרבה ארגונים עושים את הטעות הזאת, ומקדמים לניהול את המפתחים הכי טובים שלהם רק בגלל זה, ולא בגלל שיש להם Passion למקצוע החדש הזה, שעכשיו יש להם, שהם צריכים לראות שאנשים מתפתחים ושאנשים עומדים בהתחייבויות שלהם ושהצוות . . . ושהתרבות של הצוות היא התרבות הנכונה, ושכאילו...

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

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

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

(רן) זה מעניין, אולי דווקא הגישה השונה של אורי בצבא דווקא מוביל אותו לנקודה אחרת, כי הרבה פעמים אתה אומר ש...(אורי) . . . זה נכון, כן . . (רן)  . . . בצבא לא למדת [אורי] “לנהוג באונייה”, נהגת לנהל את האנשים שמטפלים במנוע ובמערכת הטילים.(אורי) לעומת זאת, אף אחד לא נגע לי בהגה וב-Throttle-ים . . . ומי שנגע, קיבל מכה על היד. 

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

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

• (רועי) אתה מרגיש שזה עבר גם לאנשים שלא רגילים לדינמיקה כזאת? כי בחיל הים, החיילים מצפים לזה. זה ב...

(אורי) נכון, הם יודעים שיהיו לך עכשיו שלושה חודשים פאדיחות נוראיות . . . 

• (רועי) אז אני תוהה, אני לא יודע לענות על זה . . . האם זה נכון למפתחים בכירים? האם יכול להגיע מישהו שהוא בישראל, שהוא “מנהל-על", לצוות של מפתחים שרגילים לתרבות שלנו פה בישראל, ולהצליח לעשות את אותו מעבר?
• אני בטוח שזה אפשרי, אבל זה יהיה... זה יהיה קשה.

(אורי) תראה, בסוף, מה הכלים שקיבלתי מהדבר הזה? אחד זה היכולת לשאול את השאלות החכמות, בצורה הנכונה,שאנשים -לא תהיה להם בעיה לענות לי. והיכולת השנייה זה ללמוד מאוד מאוד מהר, ללמוד את המטריה (Material) מאוד מהר, להבין את העקרונות שמאחורה. כי בסוף כל התוכנה וזה - זה בסוף “אינסטלציה”, הכל אינסטלציה. זה Data שזורם בצינורות, ולפעמים יש סתימה בצינור, ולפעמים יש נזילה בצינור, וכאילו, בסוף זה זה.אז היכולת להבין את העקרונות, ועל זה להלביש את השאלות הנכונות ומהר מהר מאוד להבין את התמונה.

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

(אורי) אין שם . . . זה אני, החיילים, הכלי - ולך לים.

• (רועי) אבל החיילים יודעים . . . 

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

• (רועי) אני חייב להגיד שחוויית הפיתוח ב-Salto הייתה פחות אינטנסיבית . . . .

(רן) כן, חזרת הביתה בשלום . . .

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

42:32(רן) בסדר אז כיף לנו ונעים אבל אוטוטו נגמר הפקק - כבר הגענו ואנחנו לקראת הסוף. אז אולי עוד כמה מיליםלפני שאנחנו נסיים? קודם כל תודה רבה! השיחה הייתה סופר-מעניינת.כמה מילים על Hello Heart - ככה, איפה אתם נמצאים? אם אתם מגייסים אז מה אתם מחפשים? וזהו, ספר לנו קצת.

• (רועי) אז קצת זלגתי לזה בהתחלה, אז אני אשתדל לא לחזור, אבל שוב - חברה שקיימת כבר עשר שנים.
• חיפשנו - צוות המייסדים חיפש -  חיפש את ה-Product-Market-Fit הרבה מאוד זמן - ומאז אנחנו בגדילה מאוד גדולה.
• גם מבחינת הכנסות, גם מבחינת כוח-אדם, גם מבחינת תחומים שאנחנו מפתחים בהם פיצ'רים של המוצר.
• יושבים בתל אביב, מגייסים - כרגע אני מגייס משרת QA, תחום שקרוב לליבי.
• אשמח להוסיף, אבל נראה לי שאמרתי . . . 

 האזנה נעימה ותודה רבה לעופר פורר על התמלול!

[קישור לקובץ mp3]

פרק 479 של רברס עם פלטפורמה, שהוקלט ב-8 באוקטובר 2024, תאריך עצוב. אורי ורן מארחים את אריק מחברת Remitly לשיחה על Distributed Workflow Engines.
00:50 אריק ו-Remitly(רן) אז קצת לפני זה - קצת ספר לנו עליך וקצת על החברה.(אורי) באיזו שפה ספרת לנו? . . . 

• (אריק) ספרתי ברוסית.

(אורי) אוקיי, אז הנה - כבר פרט Intro שלא ידענו עליך . . . 

• (אריק) לגמרי. אני יודע רוסית - אבל אני אוקראיני.

(רן) יודע, אך לא אוהב.(אורי) אמרנו שמדברים על טכנולוגיה, לא? . . . 

• (אריק) אז אני אריק שטיבלברג - מגבעתיים, אני מתכנת מגיל 11 בערך.
• נגעתי במלא תחומים, למדתי תלת-למד ובניתי מערכות הפעלה וכל מיני דברים לכיף, אבל מבחינת הקריירה, אז עבדתי בכמה סטארטאפים, חברות בחו”ל.
• הצטרפתי לסטארט-אפ בשם Rewire, ממש חצי שנה לפני הרכישה - ואז Remitly העולמית באה וקנתה אותנו, ומאז אני כבר שנתיים וחצי בחברה.
• ו-Fun Fact עליי - הייתי פעם טכנאי מכונות תפירה . . .
• (רן) Singer?
• (אריק) כן, גם - אבל עבדתי ב-Bernina.
• (רן) אוקיי, לא היתה לי כזו - אבל Singer היה
• (אריק) מכיר . . . 
• (רן) כן, אמא שלי מאוד אהבה לתפור ואני כילד קטן, הייתי השוליה שלה. ידעתי להחליף חוטים ולתקן תקלות פשוטות.

אוקיי, מעולה, נחמד לשמוע. אז הזכרת פה שתי חברות, Remitly ו-Rewire. מה עושים?

• (אריק) אז מה ש-Remitly עושה - היא מספקת שירותים פיננסיים ללקוחות שצריכים לנהל כספים ביותר ממדינה אחת.
• יש לנו מיליוני משתמשים, שמעבירים עשרות-מיליארדי דולרים בשנה.
• היא הונפקה ב-2021, אז אם יעניין מישהו.

(רן) אז בגדול זה חברות רב-לאומיות, כן? כמעט כל חברה רב-לאומית עושה את זה גם, או שהן אולי לא?

• (אריק) אז אני אפקס את זה, כי מה שאנחנו עושים זה בעיקר העברת כספים בינלאומית, בעיקר למהגרים, כן? אנשים.
• אם ראיתם את הפיליפינים שעומדים בתור בדואר? - זה שלנו.

(רן) אז כמו Wise, למשל? זו הנישה?

• (אריק) זה בין המתחרים שלנו. Wise נועדו יותר ל-Digital Nomads, אנשים שיש להם יכולות כלכליות.
• אנחנו מדברים פה על מהגרי-עבודה, שפחות יש להם את היכולות הכלכליות.
• (רן) חתך סוציו-אקונומי שונה.
• (אריק) בדיוק.

(רן) אוקיי, אז העברות כספים בינלאומיות זה Remitly. ו-Rewire זה גם?

• (אריק) Rewire זה הסטארטאפ הישראלי, שהמוצר שלו עדיין רץ מאוד חזק בארץ.
• אבל זה פשוט אחד מהמוצרים של החברה, והוא לאט-לאט משתלב לתוך Remitly העולמית.

(רן) הבנתי. אני יכול רק לדמיין שבתהליך כזה של העברת כספים יש איזשהו Workflow, נכון? יש איזשהו תהליך שקורה - ולכן התכנסנו כאן.
03:42 מה זה Workflow?אז בוא נדבר: מה זה Workflow? מה הצרכים-המוצריים שהולידו את מה שאנחנו הולכים לדבר עליו עכשיו?

• (אריק) אז Workflow - כעיקרון ההגדרה שלו זה פשוט “תהליך”, כן? תהליך שכאילו, זו המילה שלו בעברית, שהוא מורכב מכל מיני פעולות.
• אם ניקח אפילו דברים שכל אחד מכיר, לא יודע - “אתה רוצה להזמין משהו”, כי אני עבדתי בחברות eCommerce: אתה מזמין משהו, מחייבים אותך, שולחים לך הודעה, מישהו אוסף את זה במחסן, שולח . . . יש תהליך שלם.
• ואתה רוצה לעקוב אחרי זה ולדעת מה קורה שם.
• תראה, בעולם פשוט - למי אכפת? אז זה נפל . . . כאילו, בוא נראה, בעולם הכי פשוט זה לא יפול, כן?
• זה ירוץ, חלק - בניתי Script לוקאלית, והוא עובד.

(רן) אבל האופטימים לא שורדים, זה אנחנו יודעים . . . [Only the Paranoid Survive, וגם הם מג’עג’עים לאחרונה . . . ]

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

(רן) כן, זה תהליך שנראה פשוט - נגיד, העברת כסף ממדינה א' למדינה ב' - יכול להיות מורכב, יש נקודות כשל רבות באמצע, ואתה אומר שעמידות זה אחד מהם. הזכרת גם עוד משהו, נגיד שקיפות - להבין מה קורה עם התהליך, להבין האם זה נתקע, איפה זה נתקע, Debuggability או Whatever. זאת אומרת, היכולת גם של אנשים שלכם ואולי גם אנשי-תמיכה לבוא ואולי לתקן את התהליך אם צריך.(אורי) אנחנו מדברים גם על ה-Recoverability שלו - האם הוא יכול גם לתקן את עצמו?

• (אריק) כן, אז העניין הוא או שהוא מתקן את עצמו, או שאתה נותן לו - נותן את האפשרות למפתח לבוא וסוג של לעשות Upgrade. 
• זאת אומרת, Upgrade לתהליך, בזמן שהוא רץ, כדי שאתה מתקן אותו, ואתה לא יודע, מבטל הכל, מתחיל מההתחלה.
• כי יש גם מערכות כאלה.
• אז אנחנו מדברים על כלים שנועדו להפוך את כל הניהול והעבודה עם ה-Workflow-ים בכללי למשהו שהוא הרבה יותר נגיש למתכנת, למפתח, נותן את ה-Visibility הזה.
• ויש, אם אנחנו נעשה Zoom-in לכלי הספציפי שאנחנו מדברים עליו, שזה Temporal - אז הוא נותן לנו הרבה מהדברים האלה, ואפילו טיפה מעבר.

(רן) אוקיי, אז הפתרון שבחרתם, זה כלי בשם Temporal - אבל הוספתם אליו או מעליו עוד פונקציונליות או שכבות נוספות, או פיצ'רים שתיכף תספר לנו עליהם - שלא היו קיימים בכלי המקורי.(אורי) אני רק רציתי לשאול - רבים ממאזיננו מכירים Workflow-ים של Data: יש Workflow Engines ויש Airflow, הרבה משתמשים ב-Airflow, או Workflow אחר של ETL-ים או דברים כאלה שקשורים ל-Data. זה דומה? זה שונה?

• (אריק) אני חושב שזאת שאלה מעולה.
• נגיד, כלים כמו Airflow - הם נועדו יותר למה שנקרא ETL, כן? - Extract Transfer Load.
• שזה באמת, אתה מעביר Data ממקום למקום, משנה אותו טיפה בדרך.
• הרבה שימושים, אם זה ב-Machine Learning, אתה יודע - אתה מעביר את זה ל-Data Lakes, כדי ש-BI יוכלו לבנות על זה כל מיני אנליטיקות מגניבות . . . 

(אורי) אבל גם שם - מאותם אתגרים - זה יכול ליפול, ואתה לא יודע מתי זה נפל. חוץ מזה, שהסינים מכבים את השרתים, כאילו, גם שם הרבה דברים יכולים לקרות.

• (אריק) אז אני חושב שהשוני - כי אנחנו, הפוקוס המרכזי שלנו פה הוא מה שנקרא Business-Logic Workflows.
• השוני ביניהם הוא גם בצורך שלך בעמידות - כי אם אתה אומר “יש לי מיליון שורות ב-Database, שאני רוצה להעביר אותן ממקום למקום”.
• אם עכשיו התהליך הזה לא עובד במשך שעה, מאיזושהי סיבה, או שהצלחתי להעביר 500 אלף, אבל עוד איזה 2-4 באמצע נכשלו - איפה יותר אכפת לי מזה?
• האם אכפת לי מזה כשלקוח מחכה שההזמנה שלו תצא לפועל - תגיע, תתעדכן, להבין מה הסטטוס?
• לעומת BI - שיכול להיות ששם אנחנו, בתור עסק, נגיד “בסדר, לא נורא - מישהו יבוא, ייכנס, יתקן את זה, נריץ את כל המיליון מההתחלה” . . . .

(אורי) בוא נאמר ככה - כשיש לך המון לקוחות שמחכים לדאטה, שהוא יהיה Visible ושיהיה . . .  זה כואב. זה כואב, לצורך העניין, באותה מידה כמו שלקוחות מחכים למשהו.

• (אריק) כן, כן,

(רן) אז אני חושב, אורי, אני אנסה רגע - ואריק, תקן אותי - קודם כל, אתה צודק: זאת אומרת, יש דמיון בין כלים כמו Airflow לבין Temporal, שתכף נדבר עליו. בגדול, Workflow Engines מסוגים שונים, יש יש גם Drools, אם אתה זוכר, ויש AWS Step Functions, ויש azkaban . . .  זאת אומרת שלא חסרים כלים. אני חושב שהצורך של Remitly הוא בעצם בכלי, שהלקחות שלו הם לא מפתחים, אלא הם החברה כולה, בגדול. זה אחד. שתיים - Scale שונה לגמרי. אני מדבר על מיליוני-טרנזקציות (Transactions), או מיליוני תהליכים, שרצים במקביל. קשה לי לדמיין ש-Airflow מסוגל לסחוב דבר כזה, הוא לא נועד לזה. אולי זה אפשרי, אבל . . . .(אורי) אולי. אצלו, האתגר הוא שכל Data זה . . .  כאילו, כל Flow מריץ, פשוט.(רן) כן - אבל פה מדובר על מיליוני Workflows. ה-Workflows עצמם הם אולי “Lightweight” כאלה, זאת אומרת - הם יכולים לקחת אולי כמה ימים, כי יש דברים באמצע, אבל הם לא “Data Heavy”, אוקיי? ויש מאפיינים אחרים, נגיד של נגיד שקיפות, שהוא צריך. זאת אומרת, קשה לי לדמיין . . . לתת Airflow לאנשי התמיכה, והלגיד להם “בוא, תדבג (Debug) את הגרף”, כאילו - “תבין מה קרה”.אז כן, אז משתמש-הקצה - הוא שונה לגמרי, כנראה, באופי.

• (אריק) כן, אני חושב שתמיד נקודה חשובה, שאנשים מפספסים אותה, זה שגם יש לנו לקוחות פנימיים - BI, Data, זה גם עוד Interface מאוד משמעותי ונקודה טובה שאנשים מפספסים אותה.
• אבל, לגמרי - אנחנו, מעניין אותנו הפרט, לעומת מקרים אחרים, שלפעמים מעניין אותך ה-Batch של ה-Data.
• אז אנחנו באמת חייבים, ברמת הפרט, ברמת הזמנה הספציפית, ברמת ההעברה הכספית - לדעת בדיוק מה קורה שם, לדעת איפה, מה הסטטוס שזה נמצא בו, ולא לאבד את זה בשום שלב בדרך.
• ובמקביל, אם יש הזמנה אחרת שהיא “רצה” - אז לתת לה לרוץ.

(אורי) גם בוא נודה על אמת - אתה מתעסק פה עם כסף של אנשים, אז זה חייב להיות ממש מדויק, אבל גם עם “אופי טרנזקציוני” (Transactional) יותר, שכאילו . . . (רן) כן, אולי עם יכולות Roll-back מסוימות, או - הזכרנו הרבה פעמים - אבל שקיפות, או יכולת לבוא ולתקן בעיות, כי אנחנו יודעים שתיהינה בעיות, מתישהו.(אורי) אבל גם מאוד חשוב לדעת מה ה-State - איפה ה-Flow נמצא.
12:37 על כוראוגרפיה (Choreography) ואורקסטרציה (Orchestration)(רן) אוקיי, אז הזכרנו כמה פעמים את השם של הכלי - Temporal - אבל לא ממש הסברנו מה הוא. אז תן לנו ככה איזשהו “גיץ” של מה זה Temporal - מאיפה הוא הגיע ומי פיתח אותו, למה ומה אתם עושים איתו. הרבה שאלות . . . 

• (אריק) אז אני רק אזכיר: יש בעולם הזה של ניהול Workflow-ים - Workflow-ים Business-יים - אנחנו, לרוב, יש כזה . . . לא יודעים אם “ריב”, אבל יש לנו שתי דרכים מאוד מרכזיות, שבדרך כלל מתעסקים בזה, שזה או כוראוגרפיה (Choreography) או אורקסטרציה (Orchestration).
• בכוריאוגרפיה (Choreography), אנחנו אומרים שיש לנו כל מיני חלקים, כל חלק מכיר את האיזור שלו - הוא יודע מה נכנס, מה יוצא - אבל לא מכיר את כל התהליך.
• ואז מה שאנחנו מדברים עליו, זה שאנחנו רוצים לעשות אורקסטרציה (Orchestration).
• וגם לנו חשוב האורקסטרציה, כי כל העניין הזה של ה-State - אז זה עוזר לנו שיש לנו כלי אחד, נקודה אחת שבה אנחנו מסתכלים על כל התהליך ויודעים בדיוק איפה הוא נמצא.
• ויש תמיד מישהו ש”עם היד על הדופק” - מה קורה לדבר הזה.

(רן) כן, זו הפעם ראשונה שאני שומע את ההבדלה הזאת, בין כוריאוגרפיה לאורקסטרציה, אז בוא נראה האם הבנתי, בוא נראה האם הפנמתי: אז נגיד, אורקסטרציה זה באמת Workflow Engine, והזכרנו פה כמה כאלה - Airflow ו-Temporal - אז יש מנהל אחד, שהוא אחראי על כל התהליך ואתה יכול לבוא ולשאול אותו “תגיד, מה קורה עם X?” והוא ידע להגיד לך מה קורה עם X. בכוריאוגרפיה, אני מנחש, אולי microservices? זאת אומרת, כל אחד אולי מכיר אותו ואולי את השני שכנים שלו, אבל הוא לא מבין את כל המערכת, אין Service אחד, אין microservice אחד “טיפוסי”, שבאמת מכיר את כל שאר המערכת ויודע לבוא ולהגיד מה המצב בהכל.אני כמובן מוציא מהכלל נגיד שירות Monitoring, שאולי זאת העבודה שלו, אבל בגדול, microservice עצמו . . .  זאת אומרת, אין איזשהו Orchestrator ב-microservices.

• (אריק) אני חושב שכשאנחנו מדברים על אורקסטרציה (Orchestration), אתה עדיין יכול שיהיה לך  microservices, ואחד מהם עושה לך אורקסטרציה (Orchestration) לשאר ה-microservices, אבל ככלל . . .
• כאילו, גם בכוראוגרפיה (Choreography), אתה יכול לרצות לשלוח את כל המידע של הסטטוס הגלובלי לנקודה מסוימת, אבל המטרה בכוראוגרפיה (Choreography) זה שלא תיהיה לך נקודת-כשל אחת.
• לעומת זאת, באורקסטרציה (Orchestration), אתה יוצר - בכוונה - נקודה אחת מרכזית, שהיא . . .  כמו “מנצח על תזמורת”.

(רן) אז Database מבוזר, או “האינטרנט”, יכול להיות דוגמה לכוראוגרפיה (Choreography), אני מנחש . . . אוקיי, בסדר.
15:04 מי בנה אותו?(רן) אז אורקסטרציה (Orchestration) - Temporal. מי הוא?

• (אריק) אז כשאנחנו מדברים על אורקסטרציה (Orchestration), ואנחנו אמרנו “תהליכים” - אנחנו רוצים שהתהליכים האלה יהיו עמידים.
• יש מושג כזה שנקרא Durable Execution - שזו אבסטרקציה (Abstraction) של בדיוק כל הדיבור הזה על ה-State.
• התפקיד שלה זה לשמר את המצב של התוכנה.
• זאת אומרת, כל פעולה שנעשית, מבחינת האבסטרקציה - היא אומרת “אני עושה את הפעולה, ישר סיימתי אז אני לוקח את התוצאה, שומרת את זה אצלי ב-Database, הולכת לפעולה הבאה, שומרת את זה אצלי ב-Database” . . . . 
• ותמיד יודעת איפה אני.
• והמטרה של זה היא שאם ה-Orchestrator שלי או משהו אצלי נפל - אני קם ואני יכול . . . .
• נגיד, אם אנחנו מדברים על Kubernetes ויש לי כמה Pod-ים, אז אם Pod אחד נפל, Pod אחר יכול לקום.
• והוא יודע באיזו נקודה זה התהליך עצר, ויכול להמשיך.

(רן) כן, אז מי שמגיע מעולם ה-Database-ים, כמוני, מכיר את הקונספט של Commit Log - כל פעם לפני שכותבים ל-Database, קודם כל כותבים מה הפעולה, מתי היא התחילה ואם היא הסתיימה בהצלחה אז גם איך היא הסתיימה. ואז אפשר באמת לעשות, אם צריך להתאושש, אפשר לעשות Replay ל-Commit Log, או לדעת בדיוק איפה זה נעצר.

• (אריק) בדיוק, בדיוק. אז הקונספט הזה של Replay - רק ברמה של קוד.
• אז תדמיין . . . . ניכנס ל-Temporal יותר, כי Temporal בסופו של דבר, זו אימפלמנטציה (Implementation) של הקונספט הזה.
• יש כמה אימפלמנטציות, ו-Temporal היא מאוד מפורסמת, היא גם באה מ-Uber . . .

(אורי) . . . היא באה ב-Uber . . . .

• (אריק) ל-Uber היה . . . יש כלי פנימי שקוראים לו Cadence, אז החבר'ה שיצרו את זה ב-Uber יצאו, עשו את הכלי Open Source הזה, שנקרא Temporal.

(רן) אז אני יכול לדמיין שב-Uber, אז Temporal [כנראה ש-Cadence] הוא הכלי הפנימי שלהם והוא זה שנגיד מנהל את הנסיעות, וכל נסיעה זה איזשהו Task, ויש לה איזשהו Workflow מוגדר של לקוח שהזמין, ואז נהג קיבל, ואז הם נפגשו וכו' . . . .

• (אריק) לגמרי.

(אורי) עובד - חוץ מביוון . . .(רן) טוב, את זה אפשר להגיד על הרבה דברים, אורי . . . (אורי) לא, הקונספט הזה - של נהג קיבל, הגיע, מתי, לא . . . . (רן) האנשים עובדים, חוץ מביוון . . .  אוקיי, אז זאת אומרת - Temporal צמח ב-Uber, ואחר כך יצרו גרסת Open Source שלו - ואתם מצאתם אותו ככה?

• (אריק) אני מכיר את Temporal עוד מהחברה הקודמת - עבדתי ב-Avo, שכבר נסגרה.
• עשינו גם תהליך מאוד מורכב, eCommerce וזה - ואנחנו לא השתכנענו אז ש-Temporal הייתה מספיק בשלה [לא, כי אבוקדו . . . ]
• וגם זה דרש שינויים מאוד גדולים.
• ברגע שאנחנו ב-Remitly החלטנו לבנות איזשהו מוצר חדש, הייתה לנו הזדמנות לבנות מערכת “From the Ground Up”.
• ב-Rewire, אנחנו ידענו את כל הצרכים האלה, וכמו כל סטארטאפ, כמו כל חברה, בנינו כלים משלנו - בדיוק לעשות את כל הדברים האלה  . . . .
• לנהל את ה-State, לנהל Re-Try-ים, לנהל את כל הדברים המורכבים האלה.
• כמובן שלא עשינו את זה טוב כמו כלי שנבנה לטובת זה כמו Temporal - אז ברגע שהייתה לנו את ההזדמנות לבנות Form Scratch, קפצנו ישר על הדבר הזה.

(רן) שנייה . . .  אתה אומר “Form Scratch”, אבל למעשה זה להשתמש בכלי - להשתמש ב-Temporal, אבל “להתחיל אותו נקי”.

• (אריק) להתחיל “נקי” - כי התחלנו מוצר חדש.
• אז אני אומר - אתה מתחיל מוצר חדש, אתה יכול לבנות, לבחור את ה-Technical Stack שלך - אז זה היה מאוד No-Brainer מבחינתנו, כי פשוט זה “ישב לנו מאחורה” כבר הרבה זמן.

(רן) כן, אבל אתה אומר שפעם אחת “עשיתם את הטעות הזאת” - אני עושה ככה “מרכאות באוויר” [מיתרונות הטקסט] - ושאמרתם, או אולי לא הכרתם את ה-Temporal, אבל בניתם כלי כזה בעצמכם. הבנתם מה האתגרים, ואז אמרתם “אוקיי, Never Again! אנחנו הפעם הולכים לחפש כלי שיודע “לתת לנו את ה-80%".
19:20 השלמות(רן) אבל כמו שאנחנו יודעים - זה רק 80%. זאת אומרת, זה אף פעם לא הכל.אז איפה . . . או איזה השלמות הייתם צריכים לעשות?

• (אריק) אז אני אכניס לפה עוד אחד מהדברים שיכולים להתקשר - אנחנו מדברים הרבה על Race Conditions.
• יש לנו, כאילו . . . אם אנחנו מדברים למשל, אז יש לנו לקוח, שיכול לבצע כמה, נגיד, שליחות כספיים, הזמנות, כל מיני דברים כאלה.
• וכמו כל FinTech, מעניין אותנו להתעסק עם Risk, כן? הרי נגיד שאתה שולח עכשיו ב-bit, יש לך מגבלה יומית של כמה אתה יכול לשלוח.
• יומית, חודשית - לא משנה מה.
• (רן) אז אם המגבלה היא אלף, ואתה פעמיים שולח אלף בו-זמנית - אז אתה עלול לעבור את המגבלה.
• (אריק) כן, גם בתור . . . כאילו, אנחנו חברה גלובלית, וחברה שכמו כל חברה בנינו microservices . . . .
• אז אם זה היה Service אחד, Database אחד - אז זה No-Brainer להשתמש בטרנזקציה, ב-Database, וסגרת את העניין.
• אבל ברגע שאנחנו רצים בכמה microservices - איך אתה יוצר טרנזקציה, Across-Services? זה משהו שהוא קצת יותר קשה.
• אז מה שעשינו - בנינו מערכת Distributed Locks מעל Temporal - ככה שכל Workflow כזה שרץ, אנחנו כאילו אומרים לו “היי! תקשיב - אני רוצה לנעול את המשתמש הזה, למהלך הריצה של הפעולה הזאת”.
• וזה משהו שהיינו צריכים, כדי לוודא שאין מצב שיש לנו . . . שלקוחות עוברים, נגיד, את המגבלות היומיות שמותר להם לעשות.

(רן) כן, אז סוג של Two-phase Commit כזה - של “אני מתחיל פעולה, תנעל”, ובסוף לעשות לזה שחרור . . . . אז למעשה זו מערכת Locking כלשהי.

• (אריק) כן.

(רן) אוקיי, שזה משהו שלא היה קיים ב-Temporal?

• (אריק) Temporal - מה שהיא נותנת לך . . . היא נותנת לך הרבה גמישות.
• איך ש-Temporal בנויה, כמו שאמרנו, יש לנו את ה-Workflow, וה-workflow זה פשוט קוד, כן?
• כאילו, זה Polyglot, אז כאילו - תבחר כל שפה שאתה רוצה . . .
• אנחנו עובדים בעיקר עם Node.js, ויש לנו עוד כמה צוותים שעובדים עם Go.
• זה לא משנה, השפה - זה פשוט פונקציה. פונקציה שקורית . . .
• כאילו, אתה יכול פשוט לקרוא את הקוד הזה - אין שם איזשהו Boilerplate
• נגיד, יש Step Functions או דברים כאלה, שאתה מגדיר את ה-Workflow שלך ב-JSON, או ב-Airflow, אם אני לא טועה אז גם, אתה מגדיר את זה ב-Python, אבל מגדיר את זה באיזשהם Pipe-ים כאלה.
• וזה - פה אנחנו מדברים נטו-קוד: פונקציות שקוראות לפונקציות.
• אתה יכול לעשות שם If-ים, אתה יכול לעשות שם For-Loop, אתה יכול לעשות שם קוד . . . 

(רן) כן, זאת אומרת - אין DSL נוסף, זה השפה - זה Node או זה Go, אבל אין DSL נוסף “שעוטף”, ושיכול להוסיף מורכבות ושצריך קונטקסט כדי להבין אותו. זאת אומרת, faמגיע מפתח חדש לחברה, והוא פתאום צריך להבין כל מיני דברים שלא כתובים בקוד.
22:22 מה עם לא-מפתחים? ועם Code Versioning?(אורי) רגע, אמרנו לפני כן שה-Workflow-ים האלה יכולים לשמש, או שיכולים להשתמש בהם, גם אנשים שהם לא מפתחים . . . 

• (אריק) אז אני לא יכול להגיד שלא-מפתחים, אבל אני חושב שגם מפתחים ברמות מאוד התחלתיות יכולים להיכנס, ומאוד בקלות להבין מה כתוב שם.
• כי בסופו של דבר, זה פשוט קוד, כן? אם אתה יודע לכתוב פונקציה פשוטה, עם Loop-ים . . . אתה יודע, אתה מסיים כמה קורסים באוניברסיטה, אתה יכול לקרוא Workflow.
• כמובן, אתה צריך את הרמות-החשיבה היותר גבוהות, להתמודד עם דברים יותר מורכבים - אבל אני חושב שמה ש-Temporal מביא, וזה אחד מהדברים הכי חזקים לעומת המתחרים שלו, זה Mental-Model יותר קל.
• כי הוא לקח לעצמו הרבה מה-Heavy Lifting לתוך הפלטפורמה.
• הוא מנהל לך את ה-Failure-ים, הוא נותן לך Re-Try-ים, הוא נותן לך את הכל - ככה שכשאתה רץ ב-Workflow, ויש לך שורה שאומרת “תשלח לי את ההודעה” - אז זה קורה לפונקציה מאחורי הקלעים.
• מבחינתך, זו פשוט שורה בקוד, שאתה באמת קראת לפונקציה.
• והוא יודע להכניס את זה ל-Queue, לשמור את ה-State, לדאוג שאיזשהו Worker יריץ את הקוד . . . 
• ואנחנו יכולים להיכנס בדיוק לאיך שהדברים האלה עובדים.

(אורי) זאת אומרת, בכל הדברים שהם  . . . נקרא לזה “התוספות הפנימיות שלכם” - לעשות Locking, רק על זה דיברנו עכשיו . . . את כל זה אתם “מחביאים” מהמשתמש?

• (אריק) משתדלים, כן.
• אבל אני חייב להגיד שאנחנו לא היינו צריכים לבנות המון מעל Temporal.
• יש איזו אימפלמנטציה (Implementation) שאתה מחבר אותו למערכת Race-ים, ו-Log-ים ו-Bug-ים וכל זה.
• אבל הוא נותן לך המון - גם כי זה קוד, כן? אז תכניס איזה קוד שאתה רוצה.
• אבל בסופו שעבר אנחנו לא בנינו הרבה מעל Temporal, אלא פשוט התמקצענו באיך להשתמש ביכולות שלו.

(אורי) אגב, זה מעלה לי עוד שאלה - אתם מנהלים Code Versioning של ה-Workflow-ים עצמם?

• (אריק) זאת נקודה מעולה, כי התחלנו להגיד . . .  הזכרנו מקודם על הנושא הזה ש(למשל) יש לנו איזושהי תקלה, ואנחנו רוצים עכשיו, בזמן אמת, לבוא ולתקן את ה-Workflow.
• אז Temporal נותן מערכת שנקראת Patching.
• הרי אמרנו, אם אנחנו  . . . נגיד, ה-Workflow נפל באמצע, והוא מקים את עצמו מחדש, ורן - אמרת שזה מאוד דומה לאיך ש-Database-ים עובדים . . .
• אז הוא עושה את ה-Replay הזה כל פעם.
• ומה שאתה יכול לעשות - אתה יכול פשוט לעשות Deploy לקוד חדש, הוא יעשה Replay מההתחלה, הוא יגיע לקוד החדש שלך - והקוד החדש שלך פשוט יתווסף בתוך ה-Workflow.
• (אורי)  . . . והוא גם ירוץ מה-State שבו הוא נעצר . . . 
• (אריק) נכון. יש שם נקודה אחת, שזה אם ה-State החדש לא תואם את ה-State הישן.
• כי אם נגיד אתה בנקודה מסוימת שלחת SMS - אני כל פעם נופל על SMS, אבל אפשר להגיד נגיד “לחייב את הלקוח” - ופתאום אתה כבר לא מחייב את הלקוח, אלא אתה נגיד מחכה, שמת שם איזושהי נקודה ואתה מחכה שמישהו מ-Customer Support יאשר את הדבר.
• אז אם אתה תעשה את זה בצורה נאיבית, זה אמור להגיד לך “היי! אני לא מכיר את המצב הזה! הכנסת אותי למצב מוזר!” . . .
• מה שצריך להגיד לו זה “היי, אני עושה לך Patch - זאת הגרסה החדשה, הנה מה שאתה עושה אם אתה בגרסה הקודמת”.
• ואתה פשוט כותב קוד של if-else כזה - אם אתה בגרסה החדשה, תעשה את זה; אם אתה רצת כבר בגרסה הקודמת, אז הנה מה שאתה עושה.
• (רן) אז צריך אחר כך ללכת ולנקות את זה, אני מניח . . .
• (אריק) נכון, נכון - אבל זה כמו כל . . . יש לך API, אתה עשית...
• (רן) כן, זה צריך להיות Backwards-Compatible לפחות גרסה אחת אחורה - אבל אם אתה בצרות אז יש לך כמה גרסאות אחורה . . . ב-Production  אתה צריך לתחזק גם את זה, אבל מדי פעם ללכת ולנקות את “השובל” הזה.

(אורי) אבל השאלה שלי היא באמת על, אתה יודע - על Code Versioning, על Code Cottrol “רגיל” - יש  ל-Workflow-ים עצמם?

• (אריק) יש לך בדיוק שתי אופציות: אחת אמרתי - זה ה-Patch-ים,
• האופציה השנייה זה שאשכרה אתה יכול לשמר את הגרסה הקודמת - בגרסאות האחרונות, Temporal אפילו יכול לשמור את הקוד שלך אצלו, בגרסה הקודמת.
• ואתה יכול להגיד לו “תריץ את מה ששמרת כבר אצלך”.
• הנקודה החשובה פה זה שאתה זה שמריץ את הקוד באמת, כן? או ה-Pod-ים שלך, ה-Worker-ים שלך - הם אלה שהם . . .
• אפשר לחשוב על זה כמו “Subscriber-ים” להוראות שמגיעות מהמערכת של Temporal.
• יש את המערכת של Temporal, והיא מחזיקה את ה-Queue-ים, היא מחזיקה את ה-State, מחזיקה את ה-Database.
• והיא מודיעה לך: “תריץ עכשיו את הפעולה הזאת, תריץ עכשיו את ה-Workflow הזה”.
• אז אתה מחליט איך אתה מנהל את הקוד שלך - 
• אתה יכול להגיד “אוקיי, תנתב את כל האלה הישנים לגרסה הזאת, שאני שומר במקביל”.
• כמו שהייתי שומר Version 1 ו-Version 2 של API.
• או “תנתב את שניהם לאותה נקודה” - ושם אני אעשה את ה-If-Else הזה, כן? Backwards-Compatible או לא Backwards-Compatible.
• או אופציה שלישית, שזה להגיד ל-Temporal “היי, שמור את הגרסה הישנה אצלך במערכת, ותריץ את זה בנפרד”.
• אבל זה משהו די חדש, רק נכנס כדי לעזור עם הקטעים האלה.
• אבל לרוב, הם תמיד ממליצים לרוץ עם Patch-ים, זה הרבה יותר נוח.
• כי גם אתה תמיד יודע - אתה מנהל את המעבר, ואתה יכול לעשות אותו כמה חלק או כמה לא חלק שאתה רוצה.

28:34 מערכות מבוזרות ובאגים מאתגרים(רן) אוקיי, אז נשמע שאנחנו מדברים על מערכות מבוזרות - ולמערכות מבוזרות תמיד תמיד יש באגים מעניינים, ומאתגרים, וקשה למצוא . . . . ולפעמים, רק שנה אחרי זה אתה מוצא אותם . . . אז אולי תספר לנו על איזשהם באגים “מאתגרים” שאולי נתקלתם בהם, או Use-Case-ים שאולי לא חשבתם שתצטרכו ופתאום גיליתם שאתם צריכים, או כל מיני ככה, שלא צפיתם בבוקר שבוא החלטתם ש”הולכים על Temporal!”, וגיליתם אחר כך ואיתגרו אתכם.

• (אריק) אני יכול לדבר על Use-Case-ים מעניינים, גם בהקשר של עוד Feature-ים מגניבים של Temporal.
• אנחנו, נגיד, עובדים עם איזשהו ספק-צד-שלישי, שהוא - אתה פונה אליו ב-API, זה אחד ממה שנקרא Activities ב-Temporal - והוא מחזיר לנו תשובה.
• אז הוא אומר “היי, הצלחתי לבצע את הפעולה!” או “לא הצלחתי לבצע את הפעולה” - סבבה.
• בנקודה מסוימת, הספק הזה, בחלק מהפעמים, הוא מחזיר לך תשובה - אבל בחלק מהפעמים הוא אומר לך “היי, אני ב-Pending, ואני אחזיר לך Webhook”.
• אז פתאום הוא מוציא אותך מהתהליך הרגיל הזה, שאתה רגיל להתמודד איתו.
• (רן) “מוציא אותך מה-Zone” . . . אוקיי.
• (אריק) כן, ושם הייתה לנו . . . 
• (רן) בדרך כלל אתה אף פעם לא יכול להיות בטוח אם הוא ישלח לך את ה-Webhook הזה או לא - כי תמיד יכול להיות שגם אצלם תיהיה איזושהי תקלה . . .
• (אריק) לגמרי.
• (אריק) אז אנחנו, מה שעשינו זה מצד אחד . . .  זה גם ספק שלפעמים הוא שולח לך Webhook גם על פעולות שלא אתה ביצעת, כן?
• כי, לא יודע - ה-Customer Support יכול לפנות ב-UI שלהם ולעשות דברים, אז אתה לא יכול לדעת עד שהוא שולח לך.
• אם שתעשה לו Polling לדוגמה, משהו כזה.
• (רן) כן . . . .אז “סליחה, הכסף הזה שלך? אה, לא שלך? לא, שלך? לא. כן? 50 דולר . . . .”
• (אריק) אז מה שעשינו בהתחלה - חשבנו על לקבל את Webhook-ים, ול-Temporal יש כלי מגניב כזה, שאתה אומר לו “Workflow - חכה”
• “וחכה” זה יכול להיות לשעה, דקה, יום, אפילו שנה, כן?
• יש Use-Case-ים שאתה משתמש ב-Temporal בשביל לעשות לך את החשבונית החודשית של לא משנה איזה שירות, כן?
• אתה עושה כזה Loop, ואתה פשוט . . ה-“Wait” . . . .
• (רן) “מתעורר” פעם ב-30 יום? . . . 
• (אריק) בדיוק.
• (רן) . . . או 31, או 28 . . . זה גם מעצבן, כל החודשים האלה.

(רן) אוקיי, אז אתם מחכים ל-Webhook הזה?

• (אריק) אז אנחנו אומרים לו “תחכה” - ול-Temporal יש משהו מגניב שנקרא Signal.
• זה לא רק תהליך, שאתה פשוט יוצר את הגרף - אלא אתה יכול לבוא אליו מבחוץ, ולהגיד לו “היי, שומע? תעשה את הדבר הזה”.
• הוא יוצר API כזה, ל-Webhook, ל-Workflow, סליחה.
• אז כשאנחנו מקבלים את ה-Webhook, אנחנו יכולים או בדרך הרגילה, “הישנה” - כביכול “ישנה”, במרכאות - ללכת ל-Database ישירות ולשמור את זה.
• או להגיד שאני רוצה שכל הקוד שמנהל לי, נגיד, את הטרנזקציה הפיננסית הזאת - שיהיה בתוך Workflow, כן? Workflow אחד ארוך.
• שאני רואה ואני יודע בדיוק מה קורה ובין איזה שלב לאיזה שלב.
• ואז אני רואה שיש לי שורה של “חכה, אני קיבלתי Webhook! אני עושה Signal לתוך ה-Workflow”.
• ו-Signal זה פשוט כמו קריאת API, ואז מהנקודה הזאת ה-Workflow אומר “אוקיי, קיבלתי” ,וממשיך לרוץ.
• החלק המעניין של Signal-ים, כי אתה יכול להגיד “רגע, ואם ה-Workflow נפל?”.
• אז הוא זוכר והוא שומר בהיסטוריה הזאת, ב-Log שלו, שהוא קיבל את ה-Signal הזה, ומאותו רגע אתה לא צריך שה-Webhook יגיע שוב פעם או משהו כזה.
• ואז הוא מקבל את ה-Input הזה - ואז הוא יכול להמשיך לרוץ איתו כרגיל.
• מצד שני, אתה יכול לעשות גם Polling - שגם את זה לפעמים עשינו, כשבאמת לא סמכנו על ה...

(רן) אז נגיד שם אתה יכול לבוא ולהגיד “אוקיי, אם ה-Webhook הזה לא מגיע אחרי” - נגיד שעה - “אז תרים לי איזשהו Exception”,“תגיד לי שמשהו פה קרה” או זאת אומרת, לטפל בכל מיני מקרים כאלה, של דברים שלא קרו. זאת אומרת, עד עכשיו דיברנו על דברים שקרו, אוקיי? אתה מחכה לדברים שיקרו, אתה עושה דברים, אתה מחכה שהסינים יתעוררו בבנקים שלהם . . . . אבל לפעמים, אתה רוצה לדעת גם כשדברים לא קרו.

• (אריק) אז זאת נקודה טובה, כי אם אנחנו מדברים . . . . ב-Node.js, יש לנו את ה-Sleep, אז מה שאנחנו יכולים לעשות זה להגיד לו “היי, תחכה ל-Signal הזה, שאמור להגיע מה-Webhook - או אם עברו, לא יודע, X שעות”, כן?
• ואז, אם עברו X שעות, אז אולי תעשה את ה-Polling בעצמך, ישירות מהספק הזה ותתחיל תהליך, כשאתה טיפה יותר אגרסיבי עם הדבר הזה.
• כי ציפית שזה יגיע - וזה לא מגיע.
• בנקודה אחרת, אתה יכול - הרי זה קוד, אז אתה יכול להגיד “אוקיי, בנקודה הזאת, תתריג (Triger) תוסיף כזה משימה ל-Customer Support או ל-Operations זה משהו כזה, שיסתכלו על זה”.
• ואז - אתה יודע, עוד שורה בקוד, של “תחכה לתגובה מגורם אנושי”.
• (רן) כן.

34:01 כללי-אצבע(רן) אוקיי, אז אנחנו כבר קרובים לסוף הזמן שלנו, הזמן עובר מהר. אולי ככה לקראת סיכום, תן לנו איזה שהם כמה כללי אצבע - מתי כן ומתי לא? כלומר, עכשיו אם מישהו מקשיב לפודקאסט, ואומר “ואוואי! Temporalכלי מגניב! איזה יופי, אני רוצה להשתמש בו!” - אולי תיתן איזה כמה כללי-אצבע למתי זה כנראה נכון וכדאי להסתכל, או מתי, לחלופין, לא - זה פשוט לא הכלי שאתם מחפשים ואולי תסתכלו בכיוון אחר.

• (אריק) אז כמו אמרנו, דיברנו על ETL-ים - Temporal יכול לעשות ETL-ים, ויכול להיות שיש כבר Use Case-ים לזה - אבל אני חושב שיש כלים כבר שמאוד מפוקסים בדבר הזה, אז הייתי נמנע מזה.
• ל-Temporal, מאחורי הקלעים יש לו Queue-ים, אבל אם אנחנו מדברים על פעולה קטנה שצריכה להיות ב-Queue, אז גם - לא יודע: RabbitMQ או Pub/Sub או דברים כאלה, יש כבר את הכלים.
• ברגע שאנחנו מדברים על עמידות, Temporal באמת מעולה - אבל אם לא אכפת לנו מה-Data מסיבות מסוימות לזה, ו-AdTech לדוגמה, זה תחום מאוד מפורסם, ש”מאבד מידע בכוונה”, כי פשוט זה מאוד יקר לעשות  Processing . . .
• (רן) לא יודע אם “בכוונה”, אבל פשוט לא מתאמץ מאוד לשמור אותו . . . 
• (אריק) בדיוק,
• אז ה-Temporal בא עם עלות, כמו כל כלי.
• ברגע שאתה שומר State, אתה שומר היסטוריה, אתה שומר הרבה הרבה דברים - הוא בא עם עלות מסוימת.
• לנו, ב-FinTech ב-Remitly, מאוד אכפת לנו ואנחנו מוכנים להשקיע את העלות הזאת
• כדי לוודא שהכל מגיע לסיום ואנחנו יודעים תמיד איפה הכל.
• אז אם אכפת לכם מאיפה הכל נמצא, בכל רגע נתון - יש להם כלי UI מאוד טובים, שאומרים לך בדיוק.
• אתה יכול לראות בדיוק את ההיסטוריה הזאת, הסתעפויות של Workflow-ים ותתי-Workflow-ים ותתי -Workflow-ים וכל הקשרים האלה, וכל ה-Re-Try-ים האלה.
• סאגות למיניהן, מאוד קל לעשות שם.

(אורי) אגב, הוא כלי SaaS? או שהוא...

• (אריק) הוא גם כלי SaaS, אבל בגלל שהוא Open Source, אתה יכול פשוט להריץ אותו On-Prem או, אתה יודע, “בענן שלך”, מאוד בקלות.

(רן) כן, אוקיי, אז אם Workflow זה חלק מהותי מהמוצר שלכם, אם אתם צריכים, למשל, משהו שנראה כמו  טרנזקציות (Transactions), אבל לא על Database אחד אלא על איזושהי מערכת קצת יותר מבוזרת, אם אתם צריכים לחכות שהסינים יתעוררו בבוקר כדי להריץ או מחכים לאיזשהו Webhook, זאת אומרת, כל הדברים שהם ככה יחסית א-סינכרוניים (Async) או אולי איטיים ודורשים ויזיביליות (Visibility) - אז יכול להיות ש-Temporal הוא הכלי שאתם מחפשים.
36:44 סיום, סיכום ומשרות פתוחות(רן) אוקיי, אז נראה לי שכאן אנחנו מסכמים. אולי קצת לפני זה - עוד כמה מילים על Remitly: איפה אתם יושבים בישראל? או שזה כזה...

• (אריק) אנחנו יושבים ממש ליד מגדלי אלון - יש לנו קומת-קרקע מאוד יפה, מאוד מעוצבת . . . 
• (רן) “תל-אביבה”. 
• (אריק) מאוד תל-אביבה . . . 

(רן) טוב. מחפשים עובדים? מגייסים?

• (אריק) תמיד, תמיד - יש לנו איזה 12 משרות פנויות עכשיו, בכל התחומים.
• כמובן מלא Engineering - אבל גם לא רק Engineering.

(רן) כמה פחות או יותר אתם באזור של הפיתוח בישראל?

• (אריק) בישראל, אם אני לא טועה, אנחנו באזור ה-80 איש; ברחבי העולם אנחנו משהו כמו 500, ב-Engineering Org.

(רן) אוקיי, ויש קשר עם חברת-האם, הגדולה יותר? איפה היא נמצאת, בעצם?

• (אריק) כן. חברת-האם מבוססת בסיאטל.
• נבנתה לפני 12 שנה, ואנחנו גם עם מעל 10 Site-ים ברחבי העולם, אנחנו מאוד גלובליים.
• כמובן, אנחנו עובדים עם לקוחות גלובליים, אנחנו גלובליים.

 האזנה נעימה ותודה רבה לעופר פורר על התמלול!

[קישור לקובץ mp3]
פרק 478 של רברס עם פלטפורמה, שהוקלט ב-27 באוגוסט 2024. אוטוטו מתחיל החופש הגדול של ה-1 בספטמבר - ואורי ורן מארחים (לראשונה, באורח פלא) את חיים ידיד לשיחה על, ובכן - תוכנה.
Image by DALL-E
(רן) חיים עשה איתנו המון דברים, כולל כנסים והרבה פרויקטים יפים - אבל מעולם מעולם לא יצא לנו להקליט פודקאסט עם חיים, אז הנה - אנחנו עושים את זה סוף סוף בפעם הראשונה.
00:54 חיים, Next disclaimers והכנות למזגן בממ”ד
(רן) אז לפני שנצלול לנושא של היום - רמז: “תוכנה” - אז חיים, בוא קצת ספר על עצמך ועל המקום שבו אתה נמצא כעת.

• (חיים) אז אני בעולם התוכנה כבר הרבה מאוד שנים, יש האומרים יותר מדי - ועדיין לא למדתי להתקרב למיקרופון . . . 
• יצא לי לעשות הרבה דברים, אבל בתפקיד האחרון שלי אני עובד בחברה שנקראת Next Insurance
• בעצם, הייתי המפתח הראשון בחברה, וראיתי איך החברה גדלה מחברה של אנשים שנכנסים בחדר אחד מאוד מאוד קטן לחברה עם אלף איש והמון המון מכירות והרבה מאוד כסף שמתגלגל.
• עם 1000 אנשים - 700 בחו”ל, 300 בערך בישראל - בהחלט אופרציה מרשימה.
• [גיקונומי #306 – אלון חורי מבטח עסקים]
• ויש הרבה מאוד דברים שלמדתי בדרך, ושאליהם בעצם הייתי רוצה להתייחס בפרק הזה.

(רן) כן, אז למעשה הפרק הזה זה איזשהו Follow-up לפרק קודם, שאני כרגע לא זוכר את מספרו [469!] אבל לא מזמן [~4 חודשים], שהקלטנו עם שי ילין [469 Software development in early stage startups with Shai Yallin] - ובפרק הזה אנחנו גם נפגש עם שי, בקרוב, עוד מעט, אז Stay Tuned.ובפרק הזה, שי דיבר על טעויות - או לפחות הפרספקטיבה שלו - לגבי טעויות שהרבה סטארטאפים צעירים עושים בהנדסת תוכנה או בתכנון של מערכות תוכנה, שלדעתו קצת מאטים או פוגעים בהתקדמות שלהם. אז הפרק הזה למעשה מתכתב עם אותו פרק עם שי, וחיים בעצם מביא פרספקטיבה שונה על חלק מהנקודות ששי הזכיר.אז רק נזכיר כמה מהנושאים, ותיכף גם נצלול אליהם - אחד זה Microservices vs. Monolith, כן או לא?; השני זה תלויות או שימוש ב-Framework-ים - לא יודע אם נגיע לזה או לא; טסטים - איזה טסטים? מתי ואם בכלל; טיפול ב-Infrastructure ואחרים.אז חיים פה, למעשה אפשר לנחש לפי ה-Intro, מייצג את הפרספקטיבה של סטארטאפ שהתחיל קטן - וגדל, ועדיין גדול (טפו-טפו), וגם שם יש לקחים.
(רן) אז במה נתחיל?

• (חיים) אז קודם כל, אני רוצה לתת ה-Disclaimer, כי Next Insurance שטיפה רציתי לדבר עליה, זו בעצם חברה בעולם של InsurTech. עולם הבעיה הוא עולם של ביטוח.
• זה בגדול אומר Scale, מבחינת טרנזקציות (Transactions) בשנייה שהוא יחסית נמוך.
• זה אומר - אתה יודע, אם יש “Big Data”, אז הרבה שנים הייתי אומר שאנחנו “Small Data - Big Money” , אבל זה כבר לא נכון כל כך היום . . .
• יש לנו כבר כמויות מאוד מאוד גדולות של Data, שעוזר לנו בעצם לתמחר את הפוליסות יותר נכון, אז זה כבר לא ממש מדויק.

(רן) דרך אגב, בעולם הביטוחים - איפה אתם? יש סוגים שונים של ביטוחים . . . 

• (חיים) אנחנו מתעסקים בעצם בביטוחים לעסקים קטנים - ביטוחים לעסקים קטנים בארצות הברית.
• לדוגמא, אם אתה צלם או שיש לך מסעדה - אתה צריך ביטוח, כי אחרת אם יתבעו אותך אתה תפשוט את הרגל.
• ו-Next Insurance בעצם פותרת את הבעיה הזאת - זה שוק מאוד מאוד גדול, אנחנו שולטים על חלק קטן ממנו ויש לנו הרבה לאן לגדול.
• דרך אגב, אם רוצים תיאור מלא על ה-Business של Next Insurance, יש פרק בפודקאסט גיקונומי עם  ניסים טפירו, שהוא ה-CTO של החברה.
• מאוד מאוד מעניין, עם הרבה מאוד היבטים עסקיים וראיית-עולם מאוד מפוקחת על איך בונים סטארטאפ מאוד מאוד גדול
• ונראה לי שפה אני אעצור על נושא ה-Business, למרות שגם בזה יש הרבה דברים מעניינים.

(רן) אז יש כמה Take-aways מעניינים . . . אחד - זו חברה בתחום הביטוח, שאני מניח שיש משמעות לתשתיות כשהולכים לתחום כזה; ושתיים - אמרת מקודם ואני אזכיר שוב, היית שם ממש מההתחלה, והחברה היום גדולה.

• (חיים) ואני עשיתי את הטעויות . . . אם שי אמר שאותו שונאים ב-Wix, אז אותי שונאים ב-Next Insurance על הטעויות שאני עשיתי . . . .
• אני רוצה להגיד עוד Disclaimer - מה שאני אומר הוא מהניסיון שלי, ושקצת כולל את השקפת-העולם שלי.
• לא כל הדברים הם בהכרח נכונים.
• אני מאוד מעריך את שי מבחינה מקצועית, ואם אתם בוחרים אם להאזין למה שאני אומר או למה שהוא אומר - אז תבחרו את שלו.
• אני כן רוצה לתת את הפרספקטיבה שלנו.
• ופה בעצם הייתי רוצה להתחיל בשני דברים: הדבר הראשון שהקפיץ אותי, המשפט הראשון שהקפיץ אותי, זה “ההכנה למזגן”.
• אנחנו בשנת 2024! - התחממות גלובלית! אם יש משהו שכל אחד צריך זה מזגן. צריך להחליף את האנלוגיה למשהו אחר.
• “הכנה לחימום”? הכנה לכל דבר אחר . . . .
• אבל מזגן - תמיד צריך.

(רן) הכנה לממ”ד . . . 

• (חיים) הכנה לממ”ד . . . גם ממ”ד צריך.

(אורי) ממ”ד עם מזגן.
06:10 מזגן מסוג Microservice ובעיית כמות המפתחים
(רן) אז בואו אולי נדבר, לפני שאנחנו ככה צוללים, נצא מעולם הסיסמאות ונכנס למקום יותר… למשהו קצת יותר “תוכנתי”. אז תן דוגמה של “הכנה למזגן” שאתה חושב שצריך?

• (חיים) Microservices - ותיכף נגיע לזה.
• אני רוצה להביא איזושהי פרספקטיבה - הרבה פעמים אומרים שכשמתחילים סטארטאפ, אתה לא יודע לאן אתה  תגיע ואתה לא תדע לאן צריך, אבל יש משהו שצריך לקחת בחשבון: יש סיכוי שהחברה תצליח . . . 
• ואם היא תצליח, הרבה מהדברים שאתה עשית בהתחלה, שהיה מאוד מאוד קל לעשות אותם, בעיקר באיזורים של תשתיות - יהיה מאוד מאוד קשה להזיז אותם אחרי זה, בהמשך.
• ואם אנחנו רגע ננסה להיכנס לנושא הזה של Microservices - יצא לי לראות בלא מעט מקומות Monolith-ים שהיה סיוט לפרק אותם.
• ויש פה שני דברים: אחד, במישור הארכיטקטוני; אבל הדבר השני הוא בכיוון של התשתיות.
• זאת אומרת, לעבוד כ-Monolith ולעבוד כ-Microservice זה לא רק לעשות חלוקה ארכיטקטונית לחלקים, אלא גם להצהיר שהולכת להיות חלוקה ארכיטקטונית לחלקים.
• זאת אומרת שלצורך העניין, יש הבדל בין חברה שמגדירה את עצמה כ-Monolith לחברה שמגדירה את עצמה עם “Microservice אחד”.

(רן) בוא נהיה רגע בפוזיציה, אני אשחק את ה-Devils’ Advocate - אתה אומר “תתכוננו למצב שבו החברה תצליח  ותגדל”, ואני אומר “אם תלכו יותר מדי עם Microservices, היא לעולם לא תצליח”, כי אתם תשימו לעצמכם “מקל בגלגלים”, תסבכו יותר מדי את העניינים, תכינו יותר מדי “פתחים למזגן”, whatever הדימוי שתבחר לעצמך. ולכן, גם הקיצוניות השנייה היא כנראה לא טובה. 

• (חיים) לגמרי. זאת אומרת, אם הייתי יכול לתת עצה לחברה שמתחילה, אז תתחילו עם שני Microservices - ואל תעלו מעל לשני Microservices הרבה מאוד זמן.
• למה אני חושב שזה נכון? אני חושב שזה נכון כי זה מכריח אותך “לחשוב Microservices”, זה מכריח אותך  שתהיה לך תשתית ל-Microservices.
• אבל להתחיל עכשיו לבנות מאות Microservices, עשרה Microservices - זו כנראה טעות.

(רן) בוא נגיד שאם מפתח אחראי לעשרה Service-ים שונים, בשלב הזה - כנראה שעשית משהו מוגזם. 

• (חיים)כן. 

(אורי) אז אני רוצה לתת, כאילו, משהו שמנחה אותי - גם Outbrain הייתה הפעם Monolith . . .

• (חיים) אני יודע . . .

(אורי) . . . אבל די מהר היא יצאה מזה - ואחד הדברים שהנחו אותי הרבה מאוד זמן, זה משפט שלמדתי מספר שקשורל-Scalability: תאמין שאתה הולך להיות גדול פי אלף; תתכנן כאילו אתה הולך להיות גדול פי מאה; תקודד כאילו  אתה הולך להיות גדול פי עשר - ותעשה Deploy לפי-2 (x2).עכשיו, אפשר להזיז את זה לפה ולפה, אבל המקום הזה של “תאמין שאתה הולך להיות ממש גדול”, הוא נותן לך איזו פרספקטיבה, כי בסוף, תראו כש...(רן) אז בוא רגע נתרגם את זה [גרסת ההגדה ל-Microservices?] - ה”תאמין שאתה הולך להיות גדול” זה ההבנה ששני ה-Service-ים שחיים דיבר עליהם, יום אחד יכולים לפוך להיות אלף. זה כנראה לא בשנה הקרובה, לא בשנתיים  - אבל יום אחד זה יכול לקרות, ויש הבדל בין להתחיל עם Monolith אחד לבין להתחיל עם, נקרא זה “שני Monolith-ים”, זה אפילו לא שני Microservices, אבל שני Monolith-ים. זה State of Mind שונה.(אורי) “Two-o-Lith-ים” . . . 

• (חיים) זה State of Mind שונה, שאומר אחד - אתה יכול לדפלט (Deploy) אותם בנפרד.
• יש לך איזושהי מחשבה שיש חלוקה-לוגית שאמורה לקרות.
• לדוגמא - אחת מהטעויות הכי גדולות שיכולים לעשות זה Database משותף, במקרה של Microservices.
• אני מניח שאתם ב-Outbrain מכירים את זה.
• היה לכם את ה-Outbrain DB - ולקח לכם שנים לפרק את זה, וזה היה פרויקט מאוד מאוד גדול.
• אני חושב שבכל מקום שבו עושים טעות באזור של התשתיות, במיוחד במקומות של ה-Data, זה קטסטרופה לתקן את זה אחר כך.
• אתה משלם פי-עשר, אם לא פי-מאה, בשביל לשכתב את המערכת.
• (רן) זאת אומרת, לייצר Data-Contracts ו-Database זה לא Data-Contracts, אוקיי? לצורך הבהרה . . . 
• (חיים) נכון.
• ודרך אגב, Monolith זה לא רק Microservices - בעצם, כל דבר שהוא יחיד במערכת הוא Monolith.
• אני יכול לתת דוגמה שוב מ-Outbrain, כי כפי שאתם יודעים עבדתי ב-Outbrain, ואני רוצה לתת דוגמה ממש מקסימה.
• היא מתחילה ב-Commit של [אחד] רן תבורי, לפני המון זמן, שבה הוא מציג את הקונפיגורציה (Configuration) החדשה שהוא פיתח  . . .
• (רן) סיקרנת . . . 
• (חיים) . . .  והוא אומר שעכשיו סוף סוף יש לנו קונפיגורציה מאוחדת, וכל ה-Service-ים יכולים לשים את הכל במקום אחד, וסוף סוף יפסיק להיות לנו בלאגן.
• (רן) אני זוכר שהיה לי איזושהי גירוד בראש כשכתבתי את זה . . . 
• (חיים) 8 שנים - או 10 שנים או 12 שנה אחרי זה - חיים ידיד מגיע ל-Outbrain
• ובמשך שנה, כל מה שהוא עושה - אחד מהפרויקטים החשובים שהצוות שלו עושה - זה לפרק את אותה קונפיגורציה, שהפכה כבר להיות מפלצת . . . .
• כי ברגע שמשהו הוא Monolith, הוא הופך להיות סוג של “פח זבל” - כולם זורקים לשם דברים, אף אחד לא יודע מה קורה שם.
• היו שם כמה עשרות-אלפי רשומות, בתוך הדבר הזה, שאף אחד . . . כולם פחדו לגעת.
• (רן) “אומני ה-YAML” הגדולים ביותר מפחדים לגעת בקובץ . . . 
• (חיים) . . . ולקח מלא זמן לפרק את זה.

(אורי) אבל אני חושב שה . . . . אם כולנו פה, או אם יש מישהו מהמאזינים שחושב, שהבעיה Scalability שנתקלים בה היא בעיה של כמות הטרנזקציות (Transactions) או כמות הפניות שה-Monolith שלך יקבל - לא, זאת לא הבעיה. הבעיה היא כמות המפתחים. (רן) כן, תודה אורי, וגם חיים הקדים ואמר - אנחנו היינו חברה של Small Data, Big Money [ו-Gartner יוצרים קטיגוריה סביב ה-Acronym של SDBM בעוד 3,2,1…]. נכון, הבעיה היא בדרך כלל “הבעיה האנושית”, הבעיה הארגונית - ולא באמת בעיה של Data Keys. אוקיי, אפשר בהרבה מקרים, לפחות בשלבים הראשונים, אפשר “לזרוק CPU יותר גדול” או דיסק יותר גדול, אבל לייצר Concurrency בין מפתחים זה החלק הכי מורכב.

• (חיים) נכון.

(אורי)  . . .  או גם שהקוד שלך הוא Monolith - אבל אתה יכול לשכפל אותו, זה לא פותר את הבעיה. זאת אומרת, אתה יכול לדפלט (Deploy) כמה שאתה כמה שאתה רוצה, אבל זה לא תמיד פותר את הבעיה - כי הבעיה היא מה קורה כשיש בעיה? או כשצריך לפתח Feature חדש, וב-Monolith זה פשוט “להכניס את היד לקן נחשים” . . . 

• (חיים) לגמרי . . . וב-Next Insurance, אנחנו דאגנו להתחיל ב-Microservices From Day 1, ובעצם . . . 

(רן) בלי חרטות? כלומר, לא היו נקודות שבהן אמרת לעצמך “לא . . . .”

• (חיים) לא נתת לי להגיע ל”אבל” . . . 
• אז לא - בלי שום חרטות על התשתית ששמנו בשביל Microservices.
• ולהגיד שאנחנו נמנענו מ-Monolith? זה Wrong  . . . 
• אנחנו נפלנו בכל מיני מקומות, שאחרי זה היה מאוד מאוד קשה לתקן אותם
• ואני אסביר - יש משהו מאוד נחמד שעשינו: בגלל שאנחנו עובדים עם Microservices ואנחנו חברה מאוד מאוד צעירה, החלטנו לעשות משהו, שבזמן שעשינו אותו היה נשמע מאוד הגיוני - והוא גרם לקטסטרופה כמה שנים אחר כך.
• דיפלטנו (Deployed) את ה-Service-ים ביחד [מוזמנים להאזין ל-Soundtrack של Jaws להנאתכם]
• לכאורה - פעולה פשוטה. מה זה משנה? דפלט אחד, תדפלט שניים, שלושה  . . . - זה כל מה שהיה, מה זה משנה?

• (רן) מה זה משנה? קובץ קונפיגורציה (Configuration file) אחד, שניים, שלושה . . . .

• (חיים) . . .  בפועל, זו הייתה טעות אחת - והייתה עוד טעות אחת, שנוגעת דווקא לנושא של טסטים.
• חודש אחרי שהתחלנו לעבוד כבר עלינו ל-Production - שזה די מרשים בשביל סטארטאפ.
• ואני התחלתי לכתוב Framework של End-to-End Tests
• וה-Framework של End-to-End Tests הזה פשוט בא “ותפר” כמה שרשראות כאלה של רכישה של פוליסה של ביטוח - כל השלבים לעבור דרכם ששמתי.
• וזה היה בעצם התחלה של תשתית - תשתית של End-to-End Tests, שבעצם הפכה להיות מאוד מאוד מצליחה, וגרמה לכמה דברים - 
• אחד, אנשים כמעט לא כתבו Unit Test-ים - הם התמקדו בלהרחיב ולשפר את ה-End-to-End Tests.
• דבר שני - ה-End-to-End Suite הזה היה רץ בתוך ה-Deployment המשותף של כל ה-Services.
• ובלי לשים לב, הפכנו להיות “Distributed Monolith”  . . . - כי לא היינו יכולים לדפלט (Deploy) Service אחד - היה לנו Build אחד שמשותף לכל הצוותים.
• וה-Build  הזה הפך להיות לא יציב ולא הגיוני
• ובאיזשהו שלב התחלנו לשבור את זה - וזה כבר היה פרויקט כואב . . . .
• אני חושב שזה לקח בערך שנה לשבור את הדבר הזה לחתיכות, לגרום לזה ש...

(אורי) זה בעצם, בתכל’ס, כשהצוות מתרחב - קורים דברים שהם בכלל לא הארכיטקטורה של התוכנה שלך. הםהארכיטקטורה של איך שאתה מפתח קוד - אם הקונפיגורציות (Configurations) שלך הן Monolith-יות, אם ה-Build-ים שלך, אם אתה על עץ אחד או כמה עצים . . . 
16:30 מה עם “ה-Business”?
(רן) אבל שוב אני אשחק את “פרקליט השטן” - כשאתה בונה את הדברים בצורה “מהונדסת נכון”, לצורך העניין אתה אומר “אוקיי, צריך איזון נכון בין End to End Tests לבין Unit Tests, צריך שכל Service יהיה Deployed באופן עצמאי ולא יהיה Coupling שם, צריך שהחוזים יהיו כמו שצריך ולא דרך ה-Database”. כל הדברים האלה נכונים - אבל האם זה לא מאט את ה-Business?ופה אני אשאל אותך, נגיד, האם היו סיטואציות שבהן . . . אתה אומר שהייתם באוויר אחרי חודש? ואולי אחר כך  רציתם, כמו כל חברה, לעשות איזשהו Pivot - קטן? גדול? ואני מניח שאחרי שנה היה עוד Pivot, ואחרי שנתיים עוד Pivot - ולפעמים זה לא כזה בינארי - “Pivot או לא?” יש Pivot לחלק מהמוצר, יש . . . .האם היו רגעים שבהם עצרת עצמך או שאנשים אחרים באו ואמרו “רגע-רגע-רגע! למה אנחנו צריכים את כל ה-t!h$ הזה?! אנחנו ‘רק שנייה’ ורק רוצים לבדוק פה איזשהו Concept, רוצים לעשות איזשהו MVP - ואחר כך נכתוב את זה ‘כמו שצריך’” . . . .?

• (חיים) אז בגדול זה נכון - אבל אני רוצה להדגיש שוב דבר אחד: הבדל בין Business “עסקי” לתשתיות.
• תשתיות מאוד מאוד קל לכתוב בהתחלה
• אתה כותב, אם נגיד אתה רוצה שתיהיה לך מערכת Monitoring, אז אתה בונה מערכת Monitoring עם שני Monitor-ים, ולוקח לך חמש דקות לעשות את זה
• ואתה בונה CI/CD, אז זה לדפלט Service אחד - ולוקח לך חמש דקות לעשות את זה.
• ברגע שהנחת את ה-Concept-ים, זה Streamlined עם תהליך הפיתוח וההתקדמות של החברה.
• ואם הזנחת אספקט קריטי בתוך תהליכי הפיתוח, יהיה לך מאוד מאוד קשה לתקן את זה.
• ודברים שאתה לא תרגיש, שהם קצת כמו “לצחצח שיניים” - הם פתאום יהיו הפכו להיות פרויקטים מאוד מאוד גדולים ומאוד מאוד כואבים.
• אני יכול לתת דוגמה - ב-Service-ים של ה-Java של ה-Backend, יש לנו Service-ים של-Java של Backend, שכאילו תומכים בכל המנועים שלנו.
• ויש לנו Service-ים שהם יותר Frontend-oriented, שהם קצת סוג של Router-ים של דברים ומכוונים את הדברים של מפתחי Frontend.
• ל-Service-ים של מפתחי ה-Frontend לא היה מיגרציות אוטומטיות (Migrations) של Database, והם כל פעם בנו כאילו את השאילתות בעצמם.
• הריצו אותi פה ב-Staging, הריצו אותi ב-Production וכו' וכו'.
• לכאורה, הם חסכו זמן של לבנות את התשתית הזאת, אבל זה התנקם בהם.
• בסופו של דבר, להכניס את זה זה היה תהליך כואב - כי כבר אין לך את כל ההיסטוריה של כל הטרנזקציות (Transactions) שעשית על הסכמה של ה-Database.
• והגעת לאיזשהו מצב שבאיזשהו מצב כבר נשבר ה . . . - אבל אתה החלטת לעשות את זה.
• אנחנו אף פעם לא סבלנו את זה ואף פעם לא הרגשנו את זה - כי בהתחלה זה היה פשוט לבחור את התשתית, לעשות שאילתת Database אחת, כל פעם להמשיך ככה.
• ואתה מתקדם ואתה לא מרגיש את זה.
• בגלל זה אני אומר שזה שאתה תעשה Pivot-ים - אתה לא תעשה Pivot-ים כנראה בתשתית, אלא אם כן עשית  טעויות מהותיות בבחירת ה-Stack הטכנולוגי שלך.

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

• (חיים) אבל אין ספק שה-Business כנראה מאוד ישתנה במשך הזמן.
• לדוגמה, כל הקוד שאני כתבתי - כבר נמחק.
• לא נשארה שורת-קוד שאני כתבתי בתחילת הדרך.
• וחגגנו כל פאזה (Phase) כזאת.
• התשתיות שאני הנחתי בתחילת הדרך עדיין קיימות היום.

20:15 אנשים שהקונספט זר להם
(רן) אז הפעם אני אחזק את דבריך, ואני אתן דוגמה מהעבודה שלי בחצי השנה האחרונה, באיזשהו מכון מחקר.יש שם הרבה אנשי Machine Learning, זאת אומרת חוקרים - שמעולם בחיים שלהם לא כתבו Unit Testing, אוקיי? “הקונספט זר להם”. הם יודעים מה זה, אבל זה לא חלק מההרגל.אז אמרתי, טוב - אני רוצה עכשיו לייצר איזשהו Template של פרויקט חדש, נגיד ב-Python, אוקיי? ובפרויקט הזה, אני אכתוב רק Unit Test אחד: “2+2=4”, זה הכל. סופר-סופר פשוט, בתור דוגמה לאיך כותבים Unit Test.ביקשתי מכולם להשתמש באותו Template, ופתאום ה-Unit Test-ים פרחו כמו פטריות אחרי הגשם . . . . זאת אומרת, פתאום אתה רואה חוקרים הולכים וכותבים לעצמם Unit Test-ים יפים מאוד, כן? כמובן שהייתה להם את היכולת, אבל היה רק צריך את ה-Push הזה, או את הדוגמה הזאת או את התשתית הזאת, האוטומציה הדי-פשוטה של ה-Test הראשון - ומשם כבר כולם, ככה, עוקבים אחרי הדרך.(אורי) אז אני אגיד משהו - היום, מהנדס חדש שמגיע ל-Outbrain, עושה את ה-Bootcamp - ותוך כמה ימים הוא יודע לייצר Service חדש בכמה לחיצות כפתור. אבל לייצר את הדבר . . .  זאת אומרת, אם אני רוצה לייצר מחר משהו שמייצר Service חדש בכמה לחיצות כפתור, בסטארטאפ חדש, כשה-Service הזה יודע להתחבר לכל ה-Database-ים ויש לו Self-Test ויש לו זה ויש לו זה -  הוא וואחד Undertaking . . . .

• (חיים) ברור, ולא הייתי נכנס לזה.
• אבל אני כן אומר, שאם אתה בונה את המערכת שלך ב-Mode של Microservices - אתה לא תעשה את זה.
• אתה תבנה את השני Microservices, יחסית Hardcoded . . . 

(אורי) . . .  “תאמין שיהיו לך אלף מפתחים" . . . 

• (חיים) זה אפילו לא זה. אתה בונה את זה בצורה כזאת שאתה מדפלט (Deploy) שני Service-ים.
• איך תעשה את זה? כנראה הכי “רוק ודבק” - אבל הנחת איזשהו משהו, שאחרי זה אתה יכול להניח איזשהו Vision,  שבסוף תגיע אליו.
• לדוגמה, אנחנו התחלנו ב-Elastic Beanstalk. אני קצת מצטער שלא התחלנו ב-Kubernetes, כי להתחיל ב-Kubernetes, כמה שזו מערכת מגושמת, כשאתה מתחיל כשזה קטן אז מה קרה?
• להכניס Kubernetes אחרי זה, זה היה פרויקט שלקח בערך שנה
• אבל Once שעשינו את זה, פתאום התחלנו לעשות משהו שלא יכולנו לעשות [קודם] - התחלנו להרים סביבות דינמיות בלחיצת כפתור.
• ל-Production ולא ל-Production, למה שאנחנו רוצים.
• זה לא משהו שכנראה הייתי משקיע בו בהתחלה - אבל אם הייתי מניח Kubernetes ביום הראשון, יכול להיות שהייתי לאט לאט לוקח את המערכת לשם, ולא הייתי שם לב שזה אפילו קורה.

23:19 שחק אותה ערן הראל
(רן) חיים, אני חייב “לשחק אותה ערן הראל” נקרא לזה, או כל דמות אחרת שמקשיבה לך ושומעת “Kubernetes“ וקופצים להם הפיוזים . . . .

• (חיים) דרך אגב - הקשבתי לערן הראל, ובגלל זה לא הכנסתי Kubernetes בתחילת הדרך. . . 

(רן) . . . אז הוא יבוא ויגיד, וברור שהוא לא בדעת-יחיד בעניין הזה - למה אתה צריך את הסיבוך הזה על ההתחלה? Kubernetes From Day One?! אוקיי, אני מבין שאחר כך החיים יהיו יותר קלים - אבל אתה עושה היום את החיים יותר קשים, כשהמפתחים שלך עדיין גם ככה “נאבקים  ב-Pivot-ים כל שני וחמישי”, ב-Hiring, בגידול של הצוות,  במיליון צרות אחרות . . . בוא תחסוך לעצמך צרה אחת, ובסדר, נכון - תשלם את ה-Technical Debt הזה אחר כך, אבל זה ישתלם לך עשרות מונים.אני לא מדבר על האם Kubernetes זה כלי טוב או לא טוב - אני רק שואל על תזמון של האם באמת אתה מאמין שנכון להכניס, נקרא לזה “Kubernetes מ-Day One”?

• (חיים) אני לא הייתי אומר “מ-Day One”, אבל אני אומר שככל שדוחים את ההחלטה הזאת לשלב יותר מאוחר, זה לא ליניארי.
• להזיז תשתית של חברה Mature זה משהו שהוא יחסית קשה, וההכנסה של תשתית בשלב מוקדם היא משהו מאוד מאוד קל.
• כי זה לא באמת חייב לעבוד עד הסוף . . .

(אורי) אז אני פה קצת Devil Advocate . . .(רן) יש פה הרבה שטנים בפודקאסט הזה . . . (אורי) כן . . . ההנחה, שלי לפחות, ברוב ימיי כ-CTO, היא שתמיד אנחנו נחליף תשתיות. למה? זה לא קשור בכלללדרך שבה אנחנו עושים את הארכיטקטורה, אלא פשוט כי העולם מתקדם, כי עולם התשתיות תמיד מתקדם, ותמיד יש תשתית טובה יותר שאנחנו נרצה להתקדם אליה מתישהו, וחברה צריכה להיות מסוגלת להחליף תשתיות.ואני אגיד לך עוד משהו - בשלב ש-Outbrain רצתה לפרק את ה”קובץ קונפיגורציית-רן-תבורי” - כל הקללות בהמשך - היא הייתה מוכנה לשלם את השנה שיקח לחיים ידיד לעשות את זה . . . (רן) “וצוותו!” . . . .(אורי) . . . . וכולם יקללו את רן תבורי . . . .(רן) עכשיו אני מבין מה זה המבט המזוגג הזה בעיניים . . . .

• (חיים) זה לא היה אני באופן אישי . . . .תראה, זה ברור שאפשר להחליף תשתיות, אבל יש כמה דברים שאתה יודע שאתה תצטרך, בהנחה שאתה יודע - יש לך קצת ניסיון בעולם התוכנה.
• כנראה שאם אתה חברת SaaS, אתה תרצה שיהיה CI/CD, נכון? כי זה Proven Practice של התעשייה.
• כנראה שאתה תרצה Monitoring.
• כנראה שאתה תרצה Logging - ואולי גם איזה Log Shipping לאיזשהו שירות חיצוני . . . 
• כנראה שאתה תרצה מיגרציות אוטומטיות (Automatic Migrations) של ה-Database
• כנראה שאתה תרצה Microservices.
• כנראה שאתה תרצה עוד כמה דברים . . . .

(רן) . . . . אתה תרצה Deployment  אוטומטי  . . . 

• (חיים) . . . אתה תרצה CI/CD, אתה תרצה להיות מסוגל לעשות Spawning לסביבות נוספות  . . . 

(רן) . . . כן, אתה תרצה יכולת לבנות את ה-Database מאפס, לקחת חלקים קטנים שלו לצורך טסטים . . . .(אורי) אבל כל הדברים האלה - כשאתה אומר “תרצה”, אצלי זה ב”תאמין” . . . 

• (חיים) אבל ה”תאמין” הזה - אם אתה לא בוחר תשתית, שתיאורטית יכולה לבנות את זה או לתמוך בזה, אז אתה כאילו הכנסת איזשהו “עז” לתוך המערכת שלך, שאתה תצטער עליה אחר כך.

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

• (חיים) . . . זה לא “גדלה” - היא גדלה אקספונציאלית . . .

(רן)  . . . גדלה אקספונציאלית - אבל אמרתי “דריבית”, דריבית זה ה-Exponent - ואתה צריך להחליט. אז עכשיו, כשהבנת את זה, תחליט האם אתה מוכן לשלם המון אחר כך, או אולי קצת פחות עכשיו - או קרוב לאפס אתמול. אוקיי? אז אני גם מזדהה עם זה.עכשיו, הקושי בדרך כלל, של אנשים שיש להם פחות ניסיון  משל חיים, זה לדעת להעריך את המחיר - וכמובן שזה לא הכי . . . . זאת אומרת, כל חברה עם כוח האדם שלה, כל חברה עם ה-Business שלה, התשתיות משתנות . . .  זאת אומרת, אין פה איזושהי נוסחת-קסם. הדבר היחיד שאני חושב שלא משתנה, זה שהריבית נצברת אקספונציאלית, כמו שאמרת, ושצריך להבין שכל מה שלא תציג היום - אתה תשלם עליו הרבה אחר כך.
28:04 חיים בהכחשה עם Latin1

• (חיים) אני יכול לתת דוגמאות לכל מיני טעויות.
• הטעות הכי מטופשת, שנראה לי שאני עשיתי באופן אישי - אנחנו עובדים עם MySQL . . .

(רן) הנה - אמרת . . . 

• (חיים)  . . . ה-Default היה Latin1 לטבלאות ול-Database.

(רן) “להטעין אחד”? . . . 

• (חיים) Latin1 - זה ה-Encoding כאילו . . .  

(רן) חיים, לא הייתי מאמין עליך . . . . Latin1.

• (חיים) ואני זוכר שהסתכלתי וזה היה לי מוזר, אבל אמרתי “אבל מה אכפת לי מזה עכשיו?”

(רן) . . . “מי צריך ל-UTF?” . . . 

• (חיים)  . . . “אז נעביר את זה בהמשך ל-UTF” . . . 

(רן) כן, “notescript אחד קטן וסוגרים עניין” . . . 

• (חיים) כעבור כמה שנים הבנו את חומרת המצב - אנחנו כבר, נראה לי יותר משנה וחצי, מנסים להעביר את כל הטבלאות שלנו ל-UTF, כי ה-Latin1 הזה הוא קטסטרופה בכל פרמטר וסכנה ל-Data Corruption בכל מיני צורות.
• וכולה הייתי צריך לעשות מיגרציה (Migration) פשוטה ל-Database, כשעוד הייתי יכול.

(רן) אז רגע, נעשה גנרליזציה (Generalization) ל-Database-ים, או Data בכלל - מאוד קשה לשנות כל דבר שקשור ב-Data, בין אם זה Database-ים, בין אם זה Pipeline-ים של Data, בין אם זה כל . . .  תמיד תמיד יהיה יותר קשה. ופה כנראה שכדאי לשלם מוקדם, כי שם החוב הולך ותופח בצורה סופר-אקספונציאלית.(אורי) אבל בוא נודה על האמת - גם ה-Data שלך מאוד קשור ל-Business שלך, ל-Business Model, למה שיהיה איתו, וזה...

• (חיים) נכון, נכון - אבל אתה לא רוצה טעויות של Latin1.
• בוא נגיד שאנחנו עשינו גם טעויות במידול, כי לא ידענו - לא ידענו את מורכבות הבעיה העסקית שלנו, והיינו צריכים לעשות פרויקטים ענקיים בשביל להחליף את המידול של ה-Data שלנו.
• בגדול, Level of indirection - שזה הגיוני.
• אבל לא להתחיל כ-UTF8 - זה סתם דבילי  . . . .

(רן) כלומר, אם אתם עובדים ב-Latin1, אתם "חיים בהכחשה” - זה מה שאנחנו אומרים לכם היום.

• (חיים) כן . . .

30:25 מפתחות זרים(רן) אוקיי, עוד כמה דוגמאות? דוגמא צבעונית, יפה . . . 

• (חיים) אז שוב - נחזור רגע לנושא של המיגרציות (Migrations).
• אני מאוד הייתי גאה בזה ששמנו Flyway, ושכל המיגרציות שלנו אוטומטיות או קרוב בזה.
• והייתי מאוד גאה בעצמי - עד שדיברתי שוב עם שלומי נוח [388 Remote Work (Coronavirus special) With Shlomi Noach], ואז הבנתי שאנחנו עושים דברים לא כל כך טובים.
• שאנחנו לא כל כך מסוגלים להתמודד עם טבלאות גדולות. 
• האמת, ידעתי את זה - אבל אם הייתי מדבר עם שלומי על איך צריך לעשות מיגרציות (Migrations), יכול להיות שהייתי בונה תהליך אחר, מוקדם בתהליך הזה, שהיה מאוד עוזר לעבור לסכמות, ששלומי יודע לעשות אותן - ושב-GitHub עשו אותן כמו שצריך.
• כמו לדוגמה - העובדה שיש לנו Foreign Keys דופקים את כל היכולת של כלים כמו Ghost וכל מיני כלי מיגרציה,  שיודעים להעתיק גם טבלאות תוך כדי, ולא לעשות איזשהו משהו שלא מתאים לטבלאות גדולות - פיזיבילי (Feasible).
• ועכשיו, לך תעיף את כל ה-Foreign Keys שדאגת לשים בשמחה ובששון . . . 

(רן) בוא רק נזכיר למי שלא “חי ונושם Database-ים” בעשור האחרון - Foreign Key עוזר לך לעשות ולידציה (Validation), שאם יש לך רשומה עם מפתח שהוא מתייחס לטבלה אחרת, אז זה יהיה קונסיסטנטי (Consistent).זאת אומרת, אותו המפתח יהיה קיים גם בטבלה ההיא - וזה נחמד, זה עוזר, זה סוג של וולידציה, איזשהו Test ל-Database.אבל מה הבעיה כשאתה רוצה לעשות רפליקציה (Replication)?

• (חיים) . . . שאתה לא באמת יכול להעביר את ה-Data -  כי אין לך את ה-Foreign Keys . . . 
• אתה לא יכול ליצור טבלה נוספת, כאילו, שאליה אתה אמור להעתיק את הסכמה החדשה - כי אין לך את ה-Foreign Keys.

(רן) כן, כי הרפליקציה (Replication) כנראה תרוץ באיזשהו Stream - ואז אתה לא יכול פשוט לקחת Snapshot של ה-Data בלי להעביר את זה, כי זה לא באמת רפליקציה. זו “רפליקציית ה-Offline” אולי, אבל זה לא מה שאתה רוצה, אתה רוצה להסטרים (To Stream) את ה-Data. אבל כשאתה מסטרים (Streamlining) את ה-Data, יכולות להיווצר - לשניות בודדות או לאיזושהי תקופה - איזשהן אינקונסיסטנטיות (Inconsistencies), ואתה כנראה מוכן לחיות עם זה, לטובת היכולת באמת לרפלק (Replicate) את ה-Data.אוקיי, אז אתה אומר “Foreign Keys זה Big No-No”? - או שאולי זה קצת...

• (חיים) . . . .זה בגדול “Big No-No” . . . 

(רן) אוקיי, אז הלכנו עד הסוף עם זה . . . 

• (חיים) כן.

(אורי) כאילו, אם אתה מאמין, שאתה תגדל . . . 

• (חיים) כן.

(אורי) ואגב - אגב, מי שמאמין לא מפחד.(רן) מי שלא מפחד - משלם . . . [מי שמאמין,  לא מתעד - חזי לפלאסיאן]
32:40 לשבור את ה-Mono-Repo?

• (חיים) להריץ את כל הטסטים - גם של צוותים אחרים - בכל Build, זה לא Scalable-י.
• ולכן, אם אין לך סוויטה של טסטים (Tests Suite), של הצוות שלך, שעוזרת לך לדפלט (Deploy) את ה-Microservice שלך, אתה נמצא באיזשהו סוג של מצב, שבסופו של דבר זה יתפוצץ.
• ושוב, אני חוזר לאותו Framework של End-to-End Tests שהיה מאוד מאוד מוצלח - יותר מדי מוצלח - וגרם לנו לזנוח Component ו-Unit Tests, ולקח לנו הרבה מאוד זמן לתקן את זה.

(אורי) זה Practice “שמגיע בחינם” אם מפצלים Repos בין הצוותים?

• (חיים) דרך אגב, אנחנו רצים ב-Mono-Repo, לפחות כל ה-Service-ים של ה-Backend רצים אצלנו ב-Mono-Repo.
• יש אנשים ששונאים את זה ומקללים אותי על זה . . . אבל יש לזה גם יתרונות.
• אנחנו עוד לא הגענו לנקודה ששוברים את ה-Mono-Repo - אבל יש כבר אנשים שמדברים על זה ורוצים את זה.

(רן) כן, ברמה טכנולוגית, כאילו, GitHub, GitLab - זה לא חוסם אתכם?

• (חיים) אנחנו עובדים ב-GitHub, וזה לא חוסם אותנו ב- Mono-Repo של כמה מיליוני שורות Kotlin.
• ה-IDE - כאילו, יש אנשים שטיפה מתלוננים על זה, אבל רוב הזמן זה בסדר
• או נסבל, או שהתרגלו . . . 
• אני בטוח שזה יכול להיות יותר טוב.
• ויש לנו כלים שדואגים, לדוגמה, לעשות אנליזה לבאיזה מקומות נגעו בקוד, בשביל לעשות Triggering ל-Pipeline הנכון, של ה-Service הנכון שהשתנה
• וכלים שמתריעים על זה, אם מישהו נגע ביותר מ-Service אחד.
• כי זה בגדול, למעט מקרים קיצוניים - זה לא מצב תקין.

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

• (חיים) כן.

(אורי) אני זוכר את הוויכוח הזה, מ-Outbrain - כשבסופו של דבר, לא יודע, אני הבנתי שזה הופך לסוג של “ויכוח דתי”. אבל כשאתה מפרק אותו, בסוף - כל דרך שיש . . . לכל דרך יש יתרונות וחסרונות, ובסוף תצטרך לבנות כלים שיתגברו על החסרונות בדרך שבחרת. אמרנו לארכיטקטים: “תבחרו דרך, ותבנו את הכלים כדי לפצות על זה”, וזהו.(רן) כן, אתה אומר “בין אם תבחרו Mono או Multi - בכל מקרה נצטרך לבנות כלים מסביב לזה”, אז יאללה, “נטיל מטבע”.
34:32 בעיות בזמן, במרחב ועם Conway's law
(רן) אוקיי, אנחנו ככה ממש כבר לקראת סיום. יש עוד איזה “סיפור צבעוני” אחד שהיית רוצה לחלוק?

• (חיים) אני חושב שהדבר אולי הכי מטופש שעשינו - והוא לא כזה דרמטי, אבל הוא עדיין מטופש - זה שבחרנו לשים את ה-Time-zone של ה-Database להיות PST.
• כי ה-Headquarters ב-Palo Alto, והלקוחות שלנו בארצות הברית.
• ואין לי מושג למה עשינו את זה - וזה מעצבן ומטריד כל פעם מחדש, כי זה לא הגיוני.
• זה לא הגיוני מבחינה סיסטמית (System)

(רן) כן, אני אגיד לך סוד - כשאני הייתי ב-Google, וזה לפני הרבה מאוד זמן, גם שם עשו את הטעות הזאת . . . . אבל שם אולי רוב העובדים גם חיו בקליפורניה. אבל עדיין, בתור אנשים בישראל זה כאילו, “מה?! WTF?” כאילו, יש לכם . . . “יש UTC, למה שלא תשתמשו בזה? מה נסגר?” אבל כן, מבחינתם, העולם נמצא בקליפורניה - “ושכולם יתיישרו  לפינו”.

• (חיים) ויש עוד דבר, שלפי דעתי הוא אולי חומר לפרק שלם, אז אני אזכיר אותו רק במילה אחת . . .
• בעצם כאילו, מה שקורה זה שבגדול יש לנו מוצר אחד - בערך 40 Microservices, אבל שמשרתים מוצר אחד, אספקטים שונים שלו.
• ויש עוד Level של התייחסות של המוצר הזה, שבו יש סוגים של מוצרים.
• והרבה פעמים יש לנו Squd-ים Business-יים, שנועדים לקדם סוגים מסוימים של מוצרים - והם נוגעים שוב בכל ה-Service-ים האלה.
• וזה יוצר לנו איזו מטריצה מאוד מאוד מסובכת, בין Squad-ים ל-Team-ים
• כשה-Squad-ים מייצגים את הנושא ה-Business-י וה-Team-ים מייצגים את התוכן הטכני.
• וזה, לפי דעתי, בעיה מאוד מאוד קשה להתמודד איתה.

(אורי) גם ב-Outbrain . .  .

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

(אורי) זו בעיה שהיא בין “ארגונית” ל”תרבותית” - כי השורש של . . . מה קורה עם ה-Service? ה-Service שייך לצוות, והצוות מרגיש המון המון Ownership על ה-Service הזה - ונוצר מצב שבעצם ה-Service-ים . . .  הארכיטקטורה שומרת על חוק Conway, אוקיי? והיא נשמרת ככה עם המבנה הארגוני. ולשבור את זה - זה לשבור.וה-Squad-ים הולכים לפי ה-Business - וזה לא מתיישר, וזו בעיה.(רן) טוב, אז עשית לעצמך Build-up לפרק הבא - אז הישארו איתנו, עם ה-Cliff-hanger הזה, עד שנפתור את כל בעיות עולם התוכנה!
38:55 כתוביות
(רן) אז תודה רבה, חיים. אולי ככה לפני הסיום קצת על Next? מגייסים? מה יש לנו לספר?(אורי) What’s Next? . . . 

• (חיים) אז כמובן שאנחנו מגייסים - אין תמיד המון משרות פתוחות, כי אנחנו מנסים לשמור על איזשהו Budget ולהגדיל את ה-Capacity ואת הריווחיות של החברה, על בסיס אותו Budget.
• אבל בתוך ה-Framework הזה, אנחנו עדיין קצת גדלים, וגם לפעמים יש אנשים שעוזבים ואז צריך לחפש אנשים במקומם.
• ואני מקווה שתנאי השוק יבשילו, ושנוכל להגיע למצב שרצינו ושאנחנו כל כך רוצים להגיע אליו - שזו הנפקה.

(רן) מבחינה טכנולוגית, הזכרת קצת. הזכרת MySQL ו-JVM - מה עוד יש לך לספר על זה? Kotlin הזכרת  . . . 

• (חיים) אנחנו בעצם מפתחים את ה-Service-ים של ה-Backend ב-Kotlin, מעל JVM.
• את הקוד ה-Frontend-י שלנו אנחנו כותבים ב-TypeScript - יש לנו Angular ויש לנו גם React.
• כשזה מתחלק בין סוגי האפליקציות.
• ויש לנו גם Stack מאוד מורכב של Data Engineering ושל BI
• אנחנו עושים הרבה מאוד אנליזות על ה-Data, ויש שם הרבה מאוד מרכיבים שאוספים ועושים אנליזות על כל הדברים.
• אני חושב שיש כרגע משרה פתוחה של ראש צוות ב-Data Engineering.

(רן) אוקיי, ואמרת איפה אתם יושבים?

• (חיים) אה - והרבה מאוד תוכניות לגבי Machine Learning, כי כל הנושא של LLM הוא מאוד מאוד רלוונטי לעולם של ביטוח.

(רן) איפה אתם בארץ? הזכרת?

• (חיים) אנחנו נמצאים בכפר סבא, ה-Headquarters ב-Palo Alto.
• יש לנו עוד מרכז ב-Waltham, שזה על יד Boston.

אוקיי, טוב - אז תודה חיים! תודה רבה. האזנה נעימה ותודה רבה לעופר פורר על התמלול!

[קישור לקובץ mp3]פרק מספר 477 של רברס עם פלטפורמה, שהוקלט ב-20 באוגוסט 2024. שלהי הקיץ,  עדיין חופש גדול - ואורי ורן מארחים את מושיקו מחברת upwind לשיחה על Security, חולשות וסיפורי-קרב מעניינים.
Photo by DALL-E




00:45 מושיקו(רן) אז לפני שנתחיל - מושיקו: קצת היכרות איתך ועל החברה שבה אתה עובד . . . 

• (מושיקו) בשמחה. אז קודם כל - מושיקו, בן 26, עוד מעט 27, אשקלוני במקור.
• קצת על איך בעצם הגעתי לפה - אז באשקלון יש מגמת מחשבים אחת, ויש שני דברים שאני אוהב לעשות - אחד, זה לפתור בעיות; ושתיים זה שתמיד רציתי לצאת מאיזור-הנוחות, מהפריפריה, לצאת החוצה.
• וזה מוביל אותי בעצם לשירות הטכנולוגי . . . 

(אורי)  . . . זה דווקא “להיכנס” . . . . כאילו, מבחינת רוב האנשים, הפריפריה היא “בחוץ”. [חוץ מאסימוב . . .]

• (מושיקו) כן, אז אתה יודע - בתור ילד באשקלון, אתה תמיד חולם לפרוץ את הגבולות, לעשות משהו מיוחד.
• ואני מאוד אוהב לפתור בעיות, זה אחד הדברים שאני תמיד הכי אהבתי . . .

(אורי) נראה לי שאתה האשקלוני השני שמתראיין בפודקאסט . . . . (רן) כן, זהו, אני מנסה להיזכר . . . (אורי) יוסי תגורי. [Summit 2013: How To Fuckup, by Yosi Taguri](רן) לא, היה עוד מישהו, לדעתי . . . אנחנו ניזכר.

• (מושיקו) כן, אנחנו בונים מותג, לגמרי.
• אז “מתגלגל” - מגיע ליחידה טכנולוגית, מגיע לממר”מ, בצד של חטיבת-ההגנה, בעצם “איש סייבר”.
• קורס יחסית חדש, לא מאוד מוכר - בעיקר לא בפריפריה.
• מתחיל כ”רברסר” (Reverser) - Malware Analysis, עולמות של מחקר-איומים, מחקר-פוגענים
• מה התוקף עושה? למה הוא עושה?
• עוסק ב-Low-level בעיקר - זה רוב השירות הראשוני שלי.

(רן) רברס - לא עם פלטפורמה, במקרה הזה . . . 

• (מושיקו) אמת, כן.

(אורי) אבל מרפרר, מרפרר . . . 

• (מושיקו) כן, בעצם זה Reverse Engineering - לקחת יכולת, איזה Capability טכנולוגי, ולהנדס אותו לאחור.
• להבין, בעצם, מי שעשה - למה עשה? איך עשה?
• בעצם מה המשמעות של הדבר הזה.
• ומשם אני מתגלגל . . . אני שואל את עצמי שאלה של “איך אני ניהיה ראש צוות? איך אני יוצר השפעה בארגון?”
• בארגון סייבר גדול - ממר”מ בעצם זה היום ארגון של כמעט 3,000 איש, עם יחידות התוכנה.
• רוצה לייצר השפעה - יוצא לקצונה, עושה מספר תפקידי ראש-צוות R&D, בעיקר בעולמות הסייבר, פיתוחי סייבר הגנתיים.
• ובשנת 2019 מתמנה להיות ראש צוות מחקר “הגנה בענן” הראשון בצה”ל.
• בעצם, פותחים משהו חדש בצה”ל - “ענן ציבורי!”.
• אנחנו רוצים להיות חלק בדבר הזה, יש לנו ענן On-Prem מאוד מאוד גדול.
• ואני נכנס ככה פעם ראשונה לעולם של הגנה בענן - מקים צוות, מקים הכל מאפס, ומתחילים להיכנס למחקר,
• משם מתגלגל - בגיל 23 ניהיה ראש-מדור בממר”מ
• 45 אנשים, בעצם לנהל את כל ה-Security Pipeline “בצבא הירוק”.
• 45 אנשים - 200 מיליון Endpoints בערך . . . Endpoints כ-"IP-יים”  נקרא להם, לא Endpoints Desktop.
• ושם בעצם אני נחשף להמון המון אירועים, להמון המון תקיפות - ותוך כדי אני בעצם מתאהב בנושא של סייבר-הגנתי, סייבר-מחקרי.
• ובעצם מפתח איזו נישה של מה הקשר בין הקוד שכתבתי למוצא האתני שלי - שזה בעצם מה שנדבר עליו, אני מניח, גם היום.
• מחליט להשתחרר בהפתעה, לפני השביעי לעשירי. פוגש את עמירם שחר - בעצם נפגשים ב-upwind.
• מה שמביא אותי למקום שאני נמצא בו היום, כראש קבוצת המחקר.
• כשב-upwind - אנחנו חברת הגנה בענן: מוצר פלטפורמה, CNAAP, Cloud-Native Application Protection Platform, כמו שאוהבים להרבות באותיות באנגלית . . .
• (רן) קצרצר . . . 
• (מושיקו) כן, “קצר וקולע” . . . בגדול, נותנים הגנה הוליסטית על שכבת הענן.
• חברות בורסאיות, דברים יחסית גדולים, רציניים.
• ונותנים הגנה בעצם בפרספקטיבה שהיא קצת שונה - הרי בסוף, רוב המאזינים שלנו ישמעו ויגידו “אז מה זה שונה מ-WIZ ו-Orca?” ועוד מתחרים כאלו ואחרים.
• ובעצם, upwind הביאה גישה לפני שנתיים, שאומרת “אני מסתכל מה-Shift-Right”.
• מה שהיינו רגילים זה ל-Shift-Left - בעצם “מה-Runtime אחורה" לסביבת הענן.
• זאת אומרת, אני בא למצב נתון, מצב קיים - ואני אומר “קורה פה משהו, ואיך קרה הדבר הזה?”
• ולא “הולך לקרות פה משהו - ואולי הוא יקרה ואולי לא”.
• ואז אנחנו מאפשרים . . . .

(רן) “קורה פה משהו” במובן של “התקפה כלשהי”?

• (מושיקו) נכון, בדיוק - בין אם זו התקפה או מיסקונפיגורציה (Misconfiguration) - אני חי במצב נתון, שאומר “הנה Production - ככה הוא נראה, ככה הוא מתנהג”.
• ובעצם הפאונדרים (Founders) שלנו, שבאו מ-Spot.io [גיקונומי 319 - עמירם שחר חוסך כסף בענן] מביאים גישה חדשה לעולם ה-Security, שאומרת “רגע -איך עושים שילוב ידיים בין ה-SecOps ל-DevOps?”
• איך בעצם מקדמים ארגון שהולך יד ביד - ולא ראש בראש.
• וזה בעצם מה ש-upwind באה לפתור.

(רן) אוקיי, נדבר אולי עוד קצת בסוף על upwind אבל אולי כמה מילים בכל אופן - כמה עובדים היום בחברה, פחות או יותר? איפה נמצאים?

• (מושיקו) אז היום אנחנו מונים כ-150 עובדים, נמצאים בקו רכבת בתל אביב, Midtown.
• חברה ב-Hyper-growth, משקיעות בנו Cyberstarts ו-Greylock, כל מיני קרנות מאוד גדולות, קרן Craft גם.

05:15 התקפות ב-Live, חמאס ב-CI/CD ושיטויי-AI(רן) אז יצא לך, פה ושם, לראות כמה התקפות - בין אם זה תוך כדי, אולי קצת אחרי. אולי נדבר על כמה מהן, לפני שככה נכליל - מה אנחנו עושים כשאנחנו רואים דברים כאלה?

• (מושיקו) אז לראות זה עניין של מזל - אתה יכול לעבור שירות שלם של שמונה שנים ולא לראות דבר, או לעבור שנה האחרונה של שירות ולראות המון - וזה מה שקרה לי.
• את הסיפור שלנו אנחנו מתחילים בעצם בסוף - אני מקבל הודעת WhatsApp מחבר: “אחי, תעזור לי רגע, יש פה כלי שאני לא יודע אם זה כלי או לא - אבל זה קפץ ב-Antivirus, סביבת Production.”
• אני לא רוצה להדליק את כולם - אתם מכירים אנשי SecOps, מדליקים את כל הארגון, נועלים את הדלתות, באלגן . . . . - “תבדוק את זה”.
• אני Reverser מהולל בעברי - “תביא!”.
• יושב במחשב בבית, פותח, פורק את הכלי - בעצם מרוורס (Reverse-Engineer) אותו - ואומר לו “תקשיב אחי, יש פה כלי ששוקל Executable 6Kb, עם URL Reference לעוד Stage, שבעצם התוקף יכול להביא את שאר ה-Binary שלו מחוץ לארגון”. אמרתי לו . . . 
• והקימפול, בעצם תהליך הקומפילציה (Compile) - הוא השאיר את ה-PDB, בעצם Header כזה, שמעיד על התהליך -  מי קימפל (Compile).
• ורשום שם “כונן D של מוחמד” . . . .

(רן) כלומר, אני אתרגם שנייה - אז אתה מקבל משהו בשפת מכונה כלשהי, של איזושהי פלטפורמה - Windows, Linux, whatever - עושה איזו די-קומפילציה (Decompile) כלשהי, ואתה מגלה שיש שם איזשהו לינק לכונן D של מוחמד כלשהו.

• (מושיקו) בדיוק, ו...

(רן) . . . והוא בטעות השאיר את ה-PDB, אז זה מה שעזר לך - ה-PDB זה קובץ Debug - אז זה מה שעזר לך לגלות את זה.

• (מושיקו) . . . ואז בעצם אנחנו גם מקבלים את ה-Sense של מי הבן אדם שקימפל את זה - כי אפשר בעצם להבין לפי איכות הקובץ.

(אורי) אגב, “מוחמד” זה אחד השמות הנפוצים בעולם, כן? . . .  להצביע על מוחמד ספציפי, זה . . . 

• (מושיקו) כשזה מגיע מהשיוך הארגוני שאני השתייכתי אליו, אז זה מתבצע קצת בצורה פחות גלובאלית, מן הסתם . . .
• ואז בעצם אני אומר לו “תקשיב אחי - אין שום סיכוי בעולם שזו לא תקיפה” - ומאותו רגע בעצם מתחילה “יממת-זהב”.
• בעולמות של תקיפה, בעצם בעולמות ה-Response, אנחנו מחלקים את הזמן ל”יממות זהב" - ו-72 השעות הראשונות, שהן 72 שעות שבהן למגן יש באמת סיכוי לבצע איזושהי פעולה משמעותית בתהליך התקיפה.
• ואז אנחנו בעצם מגיעים לארגון . . .

(אורי) זה בעצם תלוי מאיזה רגע תפסת את זה - כאילו, יכול להיות שתפסת את זה ביממה ה-96 . . .

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

(רן) זאת אומרת, אם גילית את זה בזמן, אז יש לך כנראה 72 שעות. אם גילית את זה מאוחר מדי, אז זה מראש Game-over.(אורי) אבל השעון מבחינתך מתחיל לרוץ כשגילית?

• (מושיקו) נכון, כי בעצם יש לי מספר צוותים - אני ניהלתי 45 אנשים, היו לי מספר צוותי תגובה, אני יכול להחזיק כל צוות מספר שעות . . . 
• יש פה ממש תהליך אופרטיבי שלם, של איך מנהלים צוותים, איך משמרים דופק, איך מנהלים רגע לוחמה מבצעית.
• ברמת ה”מתי מכניסים את הפיצות לחדר, כדי לשמור עוד שעה של משמרת” . . . .
• ובעצם, אנחנו מתחילים להתגלגל לתוך נוהל-קרב - מכניסים אנשים לחדר, נכנסים לרשת, ואנחנו מתחילים בעצם לפרוש את התקיפה לאחור, מה שנקרא תהליך ה-Lateral Movement, פשוט מהצד השני, של המגן.

(רן) “לפרוש לאחור” - כלומר, להבין מה היו הצעדים שהביאו אותנו לאותו כונן D ו-Executable PDB? 

• (מושיקו) נכון. בעצם, מגיע עם איזה כלי, עם איזה שרת בתוך רשת Production, שהיא מנוהלת על ידינו, כיחידה - ואנחנו צריכים רגע להבין איך הכלים בעצם נכנסו לתוך הרשת שלנו.

(אורי) זאת אומרת, מה הדרך שה-Executable הזה עבר, כדי להגיע...

• (מושיקו) בדיוק, בדיוק.

(רן) כן,  רק שאתה עושה את זה “ברוורס” - זאת אומרת, אתה יודע את הסוף, ואתה מנסה להבין איך זה התחיל.

• (מושיקו)  . . . וזו בדיוק הבעיה הכי גדולה . . .

(אורי) כמו, סליחה על ההשוואה - לפני כמה ימים התפוצץ מחבל בתל אביב, והדרך שמצאו זה שהלכו אחורה למצלמות אבטחה. בדומה לזה?

• (מושיקו) אז זו הדוגמה - לא יכולתי לתת דוגמה יותר טובה למה שזה.
• בעצם, זו הדוגמה הכי מדויקת שאני חושב עליה.
• סייבר זה מרחב-לחימה - וככה אני תופס אותו.
• בעצם מתנהל פה קרב בין גוף שהוא מנהל מלחמת הגנה ומלחמת התקפה - יש שני גופים, אחד מול השני.
• ובעצם התהליך שאנחנו מגיעים - אנחנו מגיעים בעצם ל”זירת-הפיגוע" או “זירת-הפשע” ומנסים להתחקות חזרה לאחור.
• אז אנחנו בעצם מגיעים לאותו Executable, מבינים רגע מי שם אותו על השרת - מבינים שזה אחד מהקבלני-תוכנה שהשתמשנו בהם לטובת פיתוח מערכת די מבצעית ביחידה.
• ואנחנו בעצם מתחילים לאתר את אותו כלי במספר המקומות - ופה המאמץ מתפצל לשניים:
• המאמץ - נקרא לזה “המאמץ התקשורתי”, זאת אומרת איתור התקשורת, איתור התנועה של התוקף ברשת.
• והמאמץ הפרימתי-תוכנתי, שאומר “זה הכלי - מה הוא יודע לעשות? איך הוא מתנהג? מי כתב אותו?”
•  זאת אומרת, “מוחמד” זה אחלה - אבל “מוחמד” זה השם הכי נפוץ בעולם, דיברנו על זה . . . . אז איך אני  מאתר את הבן אדם הזה? איך אני יודע למי הוא שייך בסוף?
• מי שהגיע לפה, רצה מאוד להגיע לפה - הוא לא הגיע סתם.

(רן) נקרא לזה “פרופיל פסיכולוגי”.

• (מושיקו) בדיוק, בדיוק. אז בעצם, הצוותים מתפצלים לשתיים
• הצוות התקשורתי בעצם מבצע את הניתוח לאחור: מגיע לשרתים, מבצע מיפוי-רשתי נורא נורא איכותי
• ואנחנו בעצם נגיע תיכף ל-Victim Number One, נקרא לו - “נדבק מספר אחת”.
• אבל קודם נדבר שנייה על הכלי . . . 

(רן) אבל בואו שנייה נעצור פה - Executable ב-PDB. איך אתה בכלל מתחיל ללכת אחורה מזה? כאילו, איך אתה . . . יש לך מושג מאיפה זה הגיע?(אורי) אתה יודע איפה מצאת אותו . . . (רן) אוקיי - מצאת אותו על איזשהו מחשב, אולי יש שניים. אבל איך אתה הולך אחורה משם? כאילו מה - איזה “חץ” יש לך אחורה?

• (מושיקו) אז קודם כל, אנחנו אנשי מערכת-ההפעלה. זה האלף-בית שלנו.
• אנחנו חיים את מערכת ההפעלה, אנחנו יודעים לזהות ממש “שריטות קטנות” ברמת מערכת ההפעלה.
• מ-Port-ים שנפתחים, שרתי DNS שהוא בטעות תשאל אותם, כתובות שהוא פנה אליהן, מה ה-One Drive-ים שה-Windows שלו מזהה כ-One Drive-ים “שלו”, כל User שהתחבר ובאיזו שעה . . . 
• אנחנו בעצם בונים איזה “סיפור” - ממש תהליך מז”פ-י, אפשר לדמות את זה, תהליך מז”פ.

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

• (מושיקו) בדיוק - ואנחנו גם בעצם, כמו שאמרתי -מחלקים את המאמץ.
• כחלק מבניית הפרופיל סביב אותו כלי תקיפה, אני מבין גם מה “הציפיות שלי”.
• אנחנו, בתור גוף בטחוני,  מכילים המון המון מידע מודיעיני סביב אותם גופים.
• ואז אני בעצם יודע שיש פה שיוך; אני לוקח את אותו שיוך שאומר - רגע, סתם, “זה כלי שמושיקו כתב”.
• לוקח את אותו כלי, נותן אותו בעצם, אומר “אוקיי, מושיקו השתמש בזה על רן” -  זאת אומרת שיש פה שיוך מזרח-תיכוני, יש פה שיוך של תוקף, שבסופו של דבר מתגלה כחמאס.
• ואנחנו אומרים “אוקיי, אלו היכולות, זה הבן אדם, זו הסביבה, זאת המטרה - בוא נבנה את הפרופיל”.
• ומפה אנחנו בעצם יוצאים למאמץ אחד, אחרי שהבנו את הכלי  - שאומר מהו היעד שהתוקף ניסה להשיג?
• שמפה אנחנו בעצם ממש מנהלים “קרב נכסים” - מה הנכס שהוא רוצה להחזיק? מה הנכס שהוא לא רוצה להחזיק? מה הבעיות בסביבה? מה הנתיב החדירה? . . . 

(רן) . . . כש”נכס” זה יכול להיות Database-ים, תחנות-קצה של עובדים . . . 

• (מושיקו) בדיוק. אז במקרה שלנו, היה מדובר בסביבה מבצעית, Production - בעיקר שרתים, ליבות מבצעיות . . . 
• ושרת CI/CD - “חצוף", נקרא לו - שמחובר לסביבת חברת-התוכנה, אותו בית-תוכנה, שממנו “מתחילה המסיבה”.
• עכשיו, פה צריך להבין שבין תוקף לתוקף, יש “תהום של ידע”.
• בעצם, התוקף שאנחנו התמודדנו פה, זה הגוף-תקיפה המשוקם של חמאס - אפשר לקרוא באינטרנט.
• סביב התקיפות הקינטיות, הפיזיות של צה”ל על גופי הסייבר של חמאס - פיזית בתוך עזה - מה שמצריך אותם כל כמה שנים לחדש את מצבת כוח האדם . . . .
• ובעצם מדובר בגוף תקיפה די חדש.
• אותה מטרה - מטרה שיודעים שחמאס מתרגט (Targets) מספר פעמים, ואנחנו בעצם מזהים את נתיב החדירה ובונים פרופיל-רשתי בתוך הרשת שלנו.
• ופה אני רגע צריך לחלק את המאמץ - 
• יש מאמץ של התוקף, שבגדול זה נקרא “מאמץ שיטוי” זה נקרא בעולמות הביון - שבו תוקף בעצם מנהל ממש “שיחה קולחת" עם הנתקף
• ממש מנהל איתו "חוויית לקוח” - מדבר איתו, שולח לו תמונות, מתכתב איתו . . . “תוריד את זה, תעשה את זה” . . . 
• ואז יש שמונה חודשים של תקיפה - שהתוקף שלנו עושה על אותו מפתח בבית התוכנה
• מדביק את המחשב שלו, מדביק את הארגון, מדביק עוד חמישה Enterprise-ים ישראלים, מאוד מאוד גדולים, באותה תקיפה.
• והם מגיע אלינו, לשרתי ה-CI/CD.
• ופה המזל שלנו שיחק לטובתנו - שמדובר בחמאס.

(רן) בוא נבין, זאת אומרת - מצאו איזשהו בן אדם שעובד בחברת פיתוח תוכנה כלשהי, שבצבא, כמו גם בחברות אחרות, השתמשו בתוכנה שלהם. הוא - התוקף - עשה סוג של Social Engineering, כלומר התחזה למישהו או למישהי, ואמר “בוא תוריד את התמונות, בוא נדבר, בוא תוריד את התוכנה הזאת, תתקין אצלך ונוכל לדבר” - וככה הצליח לחדור אליו, וממנו הצליח לחדור הלאה.

• (מושיקו) לגמרי. ואחד הדברים הכי יפים שראינו פה בתקיפה - “יפים” זה מושג שאפשר להתווכח עליו . . . - זה שבעצם יש פה שיטוי בתצורת AI.
• מתנהלת שיחה מלאה בעברית - פעם הראשונה שאנחנו רואים את זה - שיחה בעברית-צחה לחלוטין, שקשה לקרוא ולהבין שזה לא בן אדם - אל מול אותו עובד.
• זאת אומרת, ממש משטים אותו (בו) במשך 4-5 חודשים.
• הבנאדם עובר שיטוי שיטתי, של הודעות “בוקר טוב”, “ערב טוב”, “שלח לי תמונות” . . . .

(רן) אני מניח שמי שכתב את הטקסטים בעברית - זה AI, או תרגום כלשהו . . .

• (מושיקו) אז לאור ההיכרות המודיעינית שלנו - כן.
• זאת אומרת, אנחנו מבינים רגע את היכולת של הארגון - ואנחנו לא מכירים יכולת של עברית כשפת-אם.
• ואנחנו מניחים שזאת הסיבה בעצם, כולל התמונות שאנחנו רואים, כ-Artifact, על אותו נתקף.
• וממנו מתחיל תהליך השיטוי - בעצם מתקינים עליו כלי RAT, כלי ריגול בעצם, שמאפשר הרצת קוד מרחוק.
• ובאמת, כמו שאמרתי - המזל משחק לטובתנו, שמדובר בגוף שלא מבין תשתיות, לא מבין אפליקציה, ולא מבין תהליכים ארגוניים.
• [טוב, זה מתאר גם לא מעט ארגונים לגיטמיים לכאורה . . . ]

(רן) כלומר, התוקף.

• (מושיקו) התוקף, נכון. התוקף לא מבין.
• ולמה זה מזל? כי הוא מבין שהוא יכול להתקדם בין מחשב למחשב רק על בסיס Username ו-Password.
• זאת אומרת, ההתקדמות הכי בסיסית, שכל ילד בכיתה ג' מחשב יודע - שמחשב צריך להשתמש בסיסמה.
• אז בעצם אנחנו רואים שלאורך זמן, הם כן מטילים את הכלים, את כלי-הריגול שלהם, הרוגלה
• אבל הם כן מתמשים בסיסמא ושם-משתמש בשביל לנוע ברשת - לא שימוש באקספלויטציה (Exploitation) מתקדמת . . .

(רן) כן, היו יכולים לעשות את זה אוטומטית, יותר מהר - אם היו להם יכולות.

• (מושיקו) בדיוק. ממש רגע, חוסר הבנה טכנולוגי לחלוטין.
• הם מגיעים אלינו לתוך שרת, שהוא Jump-Server נורא נורא חזק בתוך הארגון
• אחרי שהם בעצם משיגים את ה-CI/CD, משיגים גם את שרת ה-Jump-Server.

(רן) Jump-Server - תסביר . . . 

• (מושיקו) אז בעצם, Jump-Server זו טכנולוגיה שנהוגה ל-Trust בין ארגונים, או לעבודה מהבית.
• שאיתה בעצם, אותו עובד עם מחשב אישי יכול להתחבר לשרת-מרוחק ולנהל את הארגון ממנו.

(רן) אוקיי, סוג של Gateway, בעברית צחה.

• (מושיקו) בגדול, כן. לגמרי.

(אורי) מעיין VPN כזה? או . . . 

• (מושיקו) אז VPN זה קצת גדול על מה שהיה שמה . . . “שרת מכובד”, עם איזה Firewall, לא חדש.

(רן) כן, Bastion לפעמים קוראים לדבר הזה.

• (מושיקו) כן, Bastion זה גם גדול על מה שהיה שמה . . .
• אבל אני באמת אפרגן להם ואגיד ש-”Bastion” זו באמת מילה טובה.

(אורי) כשאתה מדבר על הארגון - זה על הארגון הצבאי או על הקבלן?

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

(אורי) אנחנו לא נישן בשקט אחרי מה שאתה מספר . . . .

• (מושיקו) אני כבר הרבה זמן לא ישן בשקט . . .  לאחרונה חזרתי, אחרי תקופה ארוכה, אז אני מרגיש בנוח להגיד שיש לנו אנשים מאוד טובים בכל מקום, זו קודם כל נקודה שצריך לזכור אותה.
• אז אם רגע נעשה “קפיצה לאחור" - בעצם, מגיע אותו תוקף, מגיע לאותו שרת, המון משתמשים נורא חזקים.
• אבל הוא לא מבין את זה - הוא לא יודע להשתמש ביכולת הזאת.
• הוא יושב על תהליך ה-CI/CD - הוא יכול להזריק קוד, כמו במקרה SolarWinds המוכר בתעשייה.
• יכול לעשות מה שהוא רוצה - אבל פשוט אין לו את ההבנה של על מה הוא יושב.
• ולאורך חודשים רבים הוא בעצם זז בתוך הרשת, ממשתמש למשתמש - וקורה פה משהו מעניין. שני דברים מעניינים, למען האמת . . . 
• הוא ידע להשתמש בחולשות-לוגיות. זאת אומרת, אם יש, לצורך העניין, בעיית-הגדרה, הוא לפעמים ידע להשתמש בה.
• והוא מכיר בזה שיש מאמרים בקהילה - זאת אומרת, הוא “חי בקהילת-הסייבר”, הוא לא מנותק יותר.
• והדבר הנוסף - שהוא ידע לעבוד Cross-Platform.
• חוויה מעניינת בטירוף - זאת אומרת, יש פה תוקף שלא יודע לנהל תקיפת Domain, או תקיפת-רשת רגילה, שזה א'-ב' של כל קורס Ethical-Hacking
• אבל אשכרה יודע לנהל ארבע גרסאות ולהוריד גרסאות תוך כדי - הוא מנהל תהליך CI/CD של כלי-תקיפה. סופר מרגש . . . 

(רן) יש לו Continuous Deployment לכלי-תקיפה שלו . . . 

• (מושיקו) כן. Bandwidth נמוך, אבל כן - CI/CD נהדר.
• והוא משתמש בטכניקות של חבריו מחיזבאללה ואיראן - בעצם מערך Polonium המשוייך לחיזבאללה, ומערך 42, שאני מקווה שנדבר עליו, מאיראן.
• בעצם, הוא ממש משתמש בטכניקות שלהם - בשבירות הלוגיות שהם משתמשים בהן.
• ואם רגע נפרט יותר לעומק - התוקף, מזה שאנחנו ארגון Enterprise גדול
• משתמשים ב-Word
• מי שמשתמש ב-Word משתמש ב-365
• משתמש ב-365 משתמש ב-FQDN-ים סופר-מתירניים של Microsoft, שמאפשרים שימוש, בגדול, בכל פלטפורמת ה-365
• מה שאנחנו לא היינו צריכים מסביבת-השרתים - מה שאיפשר לו בעצם לעבוד מול OneDrive בצורה חופשית  . . . .
• זאת אומרת, Once שהוא השיג את הנגישות לסביבה שלי, הוא אשכרה המנהל מבצע והורדת-גרסא דרך ה-OneDrive הפרטי שלו
• שנקרא, כאילו, “live.one.drive”, משהו כזה . . . . שזו אשכרה כתובת פרטית.

(רן) כלומר, URL-ים של OneDrive, אמרת של FQDN, שזה Fully Qualified Domain Name, שהם של Microsoft, ולמעשה משרתים קהל מאוד גדול של לקוחות - ואין שם סגמנטציה (Segmentation) מבחינת אבטחה מספיק חזקה . . . . אז למעשה אפשר, עם קצת הבנה, להעביר מידע מ-Drive אחד ל-Drive אחר, אחרי שהצלחת לעשות קצת פריצה. כן, זאת אומרת, זה לא...

• (מושיקו) לגמרי - והתוקף מבין את זה, והוא מבין שאנחנו פגיעים לבעיה-הלוגית הזאת
• זאת אומרת, זו חולשה-הלוגית שהיא לא כל כך גדולה, אבל היא עדיין מאפשרת לו תנועה הלוך-חזור בצורה מדהימה.
• ויותר מזה - הוא מבין שרכיב ה-Firewall שלנו, ספציפית מדגם 40 בגרסאות 6 ו-7, פגיע לחולשה-לוגית, שאומרת, “אם אני מעביר פרוטוקול מוצפן . . . “ 
• סליחה, אם אני מעביר בחוק מוצפן תעבורה לא מוצפנת - זה עדיין עובר.
• מה שאפשר לו בעצם להעביר תעבורה מהסוג שהוא רצה להעביר - על גבי חוקים פתוחים שלנו.
• זאת אומרת, בעצם, אנחנו הגדרנו תקשורת שהיא ולידית (Valid) . . . 

(רן) זאת אומרת שה-Firewall לא יבדוק את זה, כי הוא מניח שזה מוצפן - אז הוא לא יסתכל, לא יעשה Packet-Inspection, לא “יסתכל פנימה” לתוך הפרוטוקול וינסה להבין מה קורה שם. אבל למעשה זה לא מוצפן - הוא פשוט מעביר “Free Text“ . . . 

• (מושיקו) נכון, ואז בעצם התוקף מצליח לעשות הרבה דברים שהוא לא יכול היה לעשות, אילו הוא היה צריך לעמוד בסטנדרט של פרוטוקולים ודברים כאלה.
• הוא גם לא יודע לנהל בעצם תהליכים של שמירה ושל קונפיגורציה (Config) - אלו דברים שהוא לא ידע לעבוד איתם.
• אנחנו רואים שכל פעם שהוא מוריד גרסא של הכלי, הוא אשכרה משנה את נתיב-ההורדה שלו, כי הוא לא יודע לנהל את זה בצורה שהיא קצת יותר דינמית, באופן נורא מביך.
• מה שכן - מדובר בגוף שהוא נורא אסרטיבי: הוא יודע מה הוא רוצה, הוא נורא נורא אגרסיבי, הוא לא מפחד  “להתלכלך”.
• מה הכוונה ב”להתלכלך”? הוא עושה צעדים נורא לא שקטים, הוא “מרסס”, הוא נוגע ממש בנפגעים, הוא “חי איתם במקביל”, באותו Session.
• ומגיעים לנו לשרת ה-Database, ששם אנחנו בעצם - בתוך “יממת-הזהב", בתוך ה-72 שעות, 24 שעות-זהב - מבינים ש”אכלנו אותה”.
• אנחנו יודעים, כי חטפנו - יודעים מה הנזק, יושבים איתו על אותו שרת Database מבצעי, ואומרים “אוקיי, חוסמים או לא חוסמים?”
• יש פה מערכת מבצעית - מורידים או לא מורידים?
• וזו הדילמה מספר-אחת של ה-CISO בכל ארגון
• האם אני “מפסיד Revenue” - במקרה שלי זו יכולת מבצעית כלשהי.
• או האם אני רגע “הורג את התוקף”, ו”נותן תחושה טובה לבורסה".
• ופה רגע - מלחמה.
• במקרה הזה, לצערי, הפסדנו. כן היה דלף.
• למזלנו, עוד פעם - תוקף שלא מבין התנהלות ארגונית, מדליף Database מוצפן, בצורה חלקית.
• מקבל Corruption, ה-Database בגדול נשבר.
• והפסד לא נעים, הפסד צורם - והיינו צריכים ללכת הביתה אחר כך.

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

• (מושיקו) אז כן. בעצם, אנחנו רואים אותו - תפסנו אותו “בזמן אמת”, על אותו השרת.
• צריך להגיד - זה תהליך תומך-לחימה, לא תהליך מבצעי, מה שאפשר לנו יותר מרחב תמרון.
• זאת אומרת, ב-Business השוטף של העסק - אבל לא ב-”Core Business” שלו, לא משהו שהוא “Zero Tolerance”.
• ואנחנו מחליטים בעצם להחליט על “ניתוקים כבדים” - ניתוקים של רכיבים, ניתוקים של אנשים, איפוסים כבדים, רגולציות נורא נורא כבדות.
• כי אנחנו מבינים שיש פה אזור שהיינו לא טובים בו - ואנחנו צריכים עכשיו לבוא “לתת בראש”.
• וב-Security, התוקף יכול לממש כל כך הרבה פרצות, כל כך הרבה יש Backdoor-ים בעצם, שזה משחק כמעט אבוד.
• אבל אם אתה מספיק יסודי, מספיק חזק - יש סיכוי לנצח.

(אורי)  . . . או שהוא יעבור למטרה אחרת - שזה הרבה מההיגיון של Security: אתה לא צריך להיות הכי טוב, אתה צריך להיות יותר טוב מהשכן שלך  . . . 

• (מושיקו) לגמרי, כן.
• אז פה בעצם נותרו עוד חמישה “שכנים” נורא גדולים בישראל, שהיו צריכים להתמודד עם זה אחרינו . . . 
• וזה תלוי במזל, כן.

(אורי) אבל מה שאתה מתאר זה בעצם so-called “תוקף נאיבי”, שהצליח להגיע עמוק. ובוא נאמר - אתם יודעים דרך איזה פרצות, ואם הוא היה טיפה פחות נאיבי, הוא היה יכול להיכנס. וזה מצריך “Overall” של כל שיטת ההגנה.

• (מושיקו) נכון. אז אנחנו בעצם מתחילים תהליך של “זיכוי-קוד” - 
• באיזשהו שלב, התחלנו לקחת את כל ה-Codebase של כל הפרויקטים שלנו - בין אם הפרויקטים שפותחו אצלנו או אצל הספק, בסוף זה תהליך ה-CI/CD אחוד.
• עוברים על הקוד, סורקים שורה-שורה ["!Comb the Desert”]
• מחפשים שבירות לוגיות, מחפשים בעיות, מחפשים פרצות, מחפשים התנהגות שהיא חריגה ברמת-הקוד . . .
• זאת אומרת, זה משהו שקרה - לא הסרנו מזה אחריות.
• כן, תעדפנו את זה נמוך - זאת אומרת, במאמץ המלחמתי, ככה אנחנו תופסים אותו, כמאמץ-מלחמה, אנחנו בעצם מתעדפים רגע “איפה אנחנו שמים את השקל?”
• האם נשים אותו רגע בציר התקשורתי הישיר, שאותו תוקף מנהל
• הוא ממש מנהל עלינו CMD - יש לו Shell ו-Terminal ב-Live, פתוח מישראל לטורקיה.
• זה קורה תוך כדי שרשור של מספר VPN-ים ו-Proxy-ים - אבל הוא ממש מנהל איתנו קשר רציף, אפילו יותר טוב מ-WhatsApp . . . 
• ואנחנו מחליטים להשקיע את המאמץ שם.

25:08 ה-AI אוכל את העולם (וגם תוקף אותו)(רן) אז יש לך עוד כמה סיפורים . . . . בשיחת-הכנה שדיברנו, היו לך גם כמה סיפורים מעניינים אחרים. קודם כל, סיפרת את זה מצוין - אבל רציתי קצת להכליל.הזכרת, נגיד, שהתוקף השתמש ככל הנראה ב-AI, כדי לג'נרט (Generate) את הטקסטים בעברית, כדי להגיע בסופו של דבר לנקודת-התורפה, וכמו שאנחנו יודעים, “AI אוכל את העולם”.בוא עכשיו נסתכל נקודת-הראות של התוקף, ותוליך אותי קצת דרך וקטורי-תקיפה חדשים שאולי יצא לך להיתקל בהם, או שאולי מדוברים בתעשייה - שהיום הם אפשרים באמצעות AI וחברים, ופעם לא. [להרחבה - הפרק המופתי של Radiolab על Darkode]

• (מושיקו) אז בואו נתחיל דווקא מהנקודה שבה סיימנו עכשיו, לפני שנייה - היכולת לייצר Content.
• עד לפני שנתיים, ייצור Content היה “אירוע משמעותי”.
• היום, ייצור Content זה הדבר הכי פשוט שיש - אתה נכנס . . .  יש היום שלושה מודלים ענקים מאוד מאוד טובים, שאתה יכול להשתמש בהם בחינם.
• אנחנו רואים היום תוקפים, שמשתמשים בצורה עקבית - ממש מאמצים את המונח “Disinformation 2.0” - ומייצרים “ערימות של תוכן”.
• “השפעת תודעה” - זה אפילו לא אירוע טכנולוגי, זה ממש אירוע של השפעת-תודעה, השפעה על קהילה, השפעה על תהליכי-בחירות.
• עכשיו, ממש היום או אתמול, פרסמו על קמפיין איראני, שנחסם ב-ChatGPT - כדי שהוא לא יוכל לייצר יותר תוכן כדי להשפיע על הבחירות בארצות הברית.
• זה נראה לי הזוי, שאשכרה האיראנים משלמים כסף ל-API של OpenAI - כדי לייצר תוכן.
• ואנחנו רואים שזה בעצם הוקטור הראשון שהם תוקפים בו.
• מיס-אינפורמציה (Misinformation), כמו Tinder-Bots, הגעה ליעדים דרך בעצם Spear-Phishing בצורה מעולה, כמו שראיתי גם בעוד אירוע נוסף בקהילה הביטחונית, שהיה באזור סוף 23-24.
• שממש באמצעות Spear-Phishing הגיעו לקהילות-הביטחון, בדגש על התעשייה האווירית . . . 

(רן) מה זה Spear-Phishing?

• (מושיקו) בעצם, אתה מזהה מהנתקף - אתה אומר “רגע, יש פה איזה מהנדס, שהוא נורא חובב תעופה והחלום שלו כנראה לעבוד ב-Boeing או Airbus וכו’ - ואני מאוד רוצה להגיע אליו, אז אני אדאג לפנות אליו בצורה שהוא הכי אוהב”
• לרוב זה בדרך כלל דברים יותר “מלוכלכים”, כמו חיבה ל-Fetish-ים ולדברים קצת יותר “פריפריאליים”, אבל במקרה שלנו זה היה באמת חברת Boeing.
• (רן) . . . התחזו לאנשי Boeing - וניסו לפתות אותו לדבר איתם.
• (מושיקו) ומה ש”נהדר” היום, זה שהם פותחים כבר פרופילים ב-LinkedIn . . . הם מייצרים תמונות, הם מייצרים Record של עבודה מזוייפת, ממש תהליך ודבר שקורה.
• נחזור רגע קצת לעולם אפילו הרבה יותר טכנולוגי - מה קורה בעולמות הכלים?
• בעצם, היום מערכות ההגנה - גם אנחנו ב-upwind - מתמודדים עם מצב שבו תוקף יכול לכתוב כלי-תקיפה בשבוע, מה שהיה לוקח פעם שלושה חודשים, ארבעה חודשים . . .
• טסטים, ריצות . . . 
• הוא נכנס ל-ChatGPT, אומר לו “אני צריך Module שמבצע 1,2,3”
• לא נותן לו אפילו Context - לוקח את הקוד ומטמיע; לוקח עוד קוד, מטמיע . . . 
• בעצם, זמן-פיתוח של כלי-תקיפה יורד מבין שלושה חודשים-לשנה, לרמה של שבוע-שבועיים.
• ואנחנו רואים את זה בעצם בשני צידי המתרס - זאת אומרת, גם היכולת לפתח מודל-הגנתי הצטמצמה דרמטית, אבל גם התוקף מסוגל לייצר פרמוטציות (Permutations) בכמויות מטורפות של כלי תקיפה.
• זאת אומרת, אם עד היום חתמתי, נגיד, קבצים ב-HASH-ים, וזה היה באמת סביר - היום זו כבר לא טכניקה רלוונטית.

(רן) כן, כלומר, אתה אומר - “זיהיתי איך נראה איזשהו Binary, ואני אומר, אוקיי, זיהיתי את זה כאיזשהו Malware, אבל זה כבר לא רלוונטי, כי נורא קל לעשות פרמוטציות שונות של אותו קובץ”. ולא סתם “פרמוטציות נאיביות”, אלא באמת, לשונות שורות קוד - אמיתי, זה עדיין יעבוד, יעשה את העבודה, רק האלגוריתם קצת אחר - והחתימה תיהיה שונה לגמרי.

• (מושיקו) בדיוק. אנחנו רואים תוקף, שבאופן עקבי . . .  רואים תוקפים, שיכולים לשבת על אותו שרת, עם גרסה שהיא עובדת - ופתאום הגרסה מפסיקה לעבוד, אבל הוא השיג את אותה נגישות, אותו Backdoor.
• והוא בעצם מתחיל להוריד גרסאות, עד שה-Antivirus מפסיק לתפוס אותו.
• אנחנו רואים שהם ממש מורידים, גרסא אחרי גרסא.
• וכל פעם - שינוי, הזחה קטנה בקוד, שינוי של דברים בקוד, שינוי של דברים בחתימה . . .
• שינוי של דברים שבעצם אשכרה מייצרים Binary חדש, פרמוטציה חדשה - שמערכות-הגנה צריכות להתמודד איתה.
• פה מגיע עולם חדש - שבו אנחנו, כאנשי-הגנה, משחקים בו - שזה עולם ה-Behavior
• שהוא גם קיים כבר המון המון שנים - רק שהפעם אנחנו משחקים קצת שונה
• קצת “הקשבנו לתוקף" והבנו שרגע, אתה משחק עם מה שיש לך כדי לנצח, ולא כדי רגע להיות “הוגן”.
• והתחלנו בעצם לאמץ הרבה מודלים, לטובת זיהוי של Bainary-ים בקצה.

(רן) זאת אומרת “אם הם משתמשים במודלים, גם אנחנו יכולים להשתמש במודלים! מה החוכמה פה?” . . .

• (מושיקו) בדיוק, ואז אנחנו מתחילים רגע...

(אורי) . . . אבל מי אמר שזה לא הוגן?

• (מושיקו) זה עניין של השקפה . . . כמו ששלמה ארצי אומר, “זו שאלה של השקפה”.
• בסוף, היום אנחנו לוקחים גישות הרבה יותר “אמיצות” בעולם ה-Security, שלא נהגנו לקחת עד היום.
• אני, כאיש Security שגדל “בתעשייה המסורתית” של Low-level ו-”Research קלאסי”’, הלכנו על שיטות מאוד מאוד בינאריות, מאוד “100%”
• גם עולם האנליזות של 2020, 2021, 2022, של Big Data - לא לקחנו בקלות, “לא לקחנו סיבוב על זה בכיף”.
• ואנחנו מבינים שאין ברירה . . . 
• (רן) זאת אומרת, היום False-Positives מפחידים אותך הרבה פחות - כי פשוט המסה של התקיפות היא כל כך יותר גדולה, שאתה חייב לשלם על זה איכשהו.

30:30 מחפשים צרות עם Agent (Smith?)(רן) בסדר, אז אמרת והזכרת כמה דברים. אחד זה תקיפה באמצעות תוכן - זה יכול להיות ממש תקיפה או הנדסת-הודעה, כמו שהזכרת, שזה דרך אגב אחד הדברים שמטרידים את כל העולם, לא רק אנשי ה-Security. גם לי יצא להיתקל בלא מעט מחקרים, שמדברים על ההשפעה החברתית של הסיפור הזה, אז זה לגמרי בעולם הפוליטי-חברתי והכל. דיברת על קידוד-אוטומטי, אלגוריתמי, “Copilot וחברים”, שעוזרים בעצם לתוקפים פשוט לייצר את כלי התקיפה שלהם יותר מהר.יש גם תקיפות דרך המודלים עצמם, או דברים שטכנולוגית-ספציפיים לעולם של Machine Learning?

• (מושיקו) אז אני אפתח סוגריים מאוד . . .  דווקא אולי לא מהר, אבל Walk me through here . . .
• יש עולם של תקיפה  - כלומר, אני תוקף את המודל, את הפלטפורמה.
• זה עולם שאנחנו ב-upwind עוסקים בו יחסית רבות.
• מתעסקים בעולמות של אימפלמנטציות (Implementations) של AI - מה קורה כשארגון מטמיע, איך שזה נראה.
• ויש את העולם של “איך אני לוקח מודל והופך אותו למרושע?”
• העולם של “איך אני לוקח מודל והופך אותו למרושע?” הוא עולם הרבה יותר, נקרא זה, “נסתר מהעין”.
• הרבה יותר “מחקרי”, היום בתעשייה.
• זאת אומרת, מי שמכיר אותו זה הרבה יותר CTO-ים, מחקרים שהם יותר “אקדמאיים”, שבאים ואומרים “מה יקרה ביום שבו הבינה המלאכותית תוכל לתקוף בעצמה?”.
• זאת אומרת, אני אקח מה שנקרא בעולם Agent-ים, בעצם רכיב שמאפשר ל-AI להריץ פונקציונליות מסוימת - ואני אגיד לו “תריץ פיקוד, תריץ את זה, תתפשט לשרת, תריץ חולשה” . . . 
• מה יקרה ביום שנוכל לעשות את זה?

(רן) לצורך העניין, בוא אני ארחיב רגע את הנקודה [כי ישנו ממש טוב עד עכשיו…] - זאת אומרת, סיפרת על התקפה שאותה חווית בשירות, ואתה אומר “ראינו את התוקף, ראינו שיש לו CMD”. לצורך העניין, אולי התוקף הזה עכשיו יתחלף באיזשהו Agent שיעשה את הכל באופן אוטומטי - והרבה יותר מהר, ואולי גם הרבה יותר טוב.

• (מושיקו) נכון - והוא יוכל לחשוב. הוא ישאל את עצמו, באופן תיאורטי כמובן, אבל הוא ישאל את עצמו: “אוקיי, What is the best way for a Defensive agent?”
• פרקטית בעברית - “איך אני מתחמק מההגנה?”
• ויתחיל לממש את כל שיטות ההתחמקות מההגנה - בטווח של עשר דקות . . . .
• זה משהו שתוקף לא יוכל לעשות - כי לא תיהיה לו את היכולת הזאת בזמן אמת, בלחץ, בהיסטרה של התקיפה. זה משהו שאתה לא עושה.
• ופתאום יכול לבוא מודל - שהוא לא בלחץ, הוא לא ממהר לשום מקום . . . . הוא “תריץ אותי, אני בסדר אחי, תן לי לרוץ.”
• וזו חווייה שונה . . . 

(רן) כן, זאת אומרת - אתה יכול להעסיק עשרה תוקפים, או פשוט לפרוש עשרה מודלים שונים, או עשרה Agent-ים שונים, וכל אחד עם קצת פרמוטציות שונות, וכל אחד יתקוף קצת אחרת, ואולי אחד מהם יצליח . . .

• (מושיקו) נכון, אבל היום אנחנו רואים מודלים מהממים שרצים ב-Edge.
• זאת אומרת, מודלים שלדעתי Meta ו-Google פרסמו, שיכולים לקחת החלטה בקצה
• זאת אומרת, ב-Compute מאוד מאוד סביר, של כמה ג'יגות (Gb) זיכרון, עם CPU סביר, על שרתים.
• ובעולמות ה-On-prem זה “יכול לחיות בכיף”, בלי שאף אחד יזהה אותו.

33:24 שרשראות אספקה של מודלים(רן) כן . . . ההתקפה שתיארת מקודם בעצם מתחילה דרך שרשרת-האספקה של התוכנה. נכון? מגיעה דרך CI, זאת אומרת, דרך חברת תוכנה ואחר כך מגיעה ל-CI. אתה מכיר גם התקפות שרשרת-אספקה (Supply-Chain) על מודלים?

• (מושיקו) אז יצא לנו לראות לאחרונה המון מחקרים שיוצאים דווקא על “המעטפת של המודלים”.
• אני לא מדבר על המודל עצמו - זה דווקא מחקר שאנחנו מנהלים בימים אלה אצלנו בחברה, על ממש לעשות Poisoning למודל כדי שיחזיר תשובות שהן מלוכלכות.
• אבל ראינו המון מודלים ב-Hugging Face שקבצי הקונפיגורציה (Config files) שלהם, ה-Python-ים שלהם, כל קבצי ה-Tensor למיניהם - מודבקים במודולים מקודדים.
• זאת אומרת, אשכרה יש כזה “קידוד מספרי”, שבעת ההרצה ב-TensorFlow בעצם נפרק.
• ואז זה ליטרלי Code Execution ל-Remote Code.
• יצא לנו לראות הרבה, דווקא בעולמות הפלטפורמה, ש-Hugging Face...

(רן) . . . זאת אומרת, זה “סוג של Macro”. אם פעם היינו מפחדים מ-Macro ב-Word, אז היום יש Macro-ים כאלה בתוך TensorFlow, שאתה מוריד אותם בלי שאתה יודע, מ-Hugging Face, כי שם נמצאים המודלים. ולמעשה אתה מריץ איזשהו “Macro” שלא התכוונת. אולי התכוונת להוריד סט של משקולות למודל - אבל אתה גם מריץ פה איזשהו Executable, בלי שאתה יודע.

• (מושיקו) בדיוק - ובעצם אנחנו רואים שזה מתפשט בטירוף.
• כי תוקפים מבינים שהם יכולים לקחת מודל קיים, לשכפל אותו, לתת לו שם מגניב, לעצב אותו קצת יפה, לפרסם אותו ב-Medium - ופתאום יש קליינטים, יש קליאנטורה  . . . 
• הם רצים בסביבות Production - אף אחד כמעט לא מריץ מודלים במחשב האישי, “לכיף”, אלא, אתה יודע, לפיתוח, וזו הכניסה לסביבה.
• ורואים וקטור תקיפה משמעותי שנבנה שם.
• לגבי, רגע, מודל שהוא בעצמו זדוני - זאת אומרת “במהות שלו"
• שאתה אומר לו “תביא לי קוד Python” - ואתה מקבל בפועל קוד זדוני של Python.
• זה מחקר שאנחנו עובדים עליו בימים אלה - התוצאות מעורבות.
• בסוף, נקרא לזה ה-”Fine Tuning” או ה-”Embedding” לא מספיק איכותי בשביל לגרום לו לסטות בטירוף.
• אנחנו כן מצליחים לגרום לו לבצע הזרקות מאוד מינימליות, של URL-ים, של Request-ים ספציפיים, בעולמות ה”תקיפה Light”.
• לא מצליחים לגרום לו להוציא קוד זדוני ממש, שייתן לנו Reverse שלו, קוד Executional ללקוח.
• וזה באמת אירוע נורא דרמטי - כל עולמות הפלטפורמה וההרצה הם עולמות נורא חדירים, בעיקר כי הם עולמות נורא מחקריים.
• זאת אומרת, מי עד לפני שנה עשה “הנדסת AI”? בפועל,  אלו היו חוקרים, כנראה באקדמיה או אנשי Data Science, שהיו “בשמנת של השמנת” של הארגון.
• הם ו-DevOps או הם ו-Security זה בערך הדבר הכי רחוק אחד מהשני . . . 
• ובסוף, היום אנחנו לצורך העניין מתמודדים עם מספר לקוחות שהם פלטפורמות-AI
• ב-upwind אנחנו נותנים שירות-הגנה לספקי AI.
• ואנחנו רואים שבאופן עקבי, תוקפים נכנסים לפלטפורמה, באים לאמן מודל לכאורה - אבל בפועל מצליחים לחדור את תשתיות-החברה בצורה נורא נורא פשוטה, נורא מהירה.
• כאילו, מקבלים Shell Jupyter, ממפים אותו, 
• מוצאים בדרך כלל חולשה לוגית כזאת או אחרת בשירות - כי כנראה שלא מידלו אותו מספיק טוב.
• ומתחילים בעצם להריץ Miner-ים או כלי-תקיפה על אותה סביבה.
• וזה וקטור-תקיפה נורא דרמטי בעולם ה-AI והפלטפורמות.

36:34 סיפורים מהקופסא ו-72 שעות(רן) אוקיי . . . אז פה, בפודקאסט הזה, לקחנו בעיקר את הצד של התוקף. קודם כל - אל תדאגו, יש הרבה שמגינים, חשוב להזכיר, בצבא ובאזרחות. זאת אומרת, רצינו להתמקד על הצד של התוקף, ככה, כדי שיהיה מעניין - אבל יש לא מעט טכנולוגיות, גם כמו שרמזת קצת, בצד המגן.ובעיקרון הזמן שלנו כבר די נגמר - אבל יש עוד כמה סיפורים יפים, שחשבתי שאולי יהיה נחמד לדבר עליהם, אז בואו אולי ניקח בקטנה עוד איזשהו “סיפור קרב” אחד כזה, מהדברים שעברת? לא בהכרח AI, איך שמתאים לך - וככה נעבור אותו קצת יותר בקצרה.

• (מושיקו) בשמחה. אז באמת, חוזרים מהמילואים, תקופה מאתגרת . . . לדעתי, במילואים האחרונים שעשיתי, במהלך המלחמה, הגענו לקונצנזוס פעם ראשונה בצבא.
• “עשרה יהודים בחדר”, מה שנקרא - כולם מסכימים בפעם הראשונה . . . 
• זו התקופה שנתקפנו בה הכי הרבה פעם, היסטורית. תקיפות Non-Stop.
• ובעצם, דבר אחד משותף - לא מעניין אותם שום דבר יותר. הם רוצים להגיע ליעד, הם רוצים להגיע לנכס.
• ואנחנו בעצם רואים . . . .הגענו לסביבת משתמשים, סביבת לקוחות, שבה ככה, בהחלטה מודעת של אותה תעשייה ביטחונית, לא בוצעו בה תהליכי-הגנה, לא בוצעו שגרות-הגנה, כתהליך מודע.
• ובעצם התוקף “חי” שם בסביבת-משתמשים סטנדרטית - אבל פה הפעם מדובר במערך 42
• מערך איראני, מערך שקצת מבין יותר התפשטות, מבין יותר רשת - והוא בעצם פה כן מנהל תקיפת-Domain ותקיפות על בסיס פלטפורמות-הגנה.
• אנחנו רואים אותו נע לאורך הרשת - הוא בעצם פה כן מנהל סביבנו מבצע, הוא מריץ עלינו כלי-תקיפה די “רזה”
• באופן מאכזב . . . זאת אומרת, ציפינו דווקא ממערך כזה לנהל כלי-תקיפה יותר משמעותי.
• אבל פה הוא מתמקד דווקא באנשים - באנשים שבארגון, זה מה שמעניין אותו.
• הוא מתמקד באנשים, הוא מתמקד ב-Active Directory, הוא בודק מי עובד בארגון, מי זה האנשים האלה . . .
• הוא “חוקר אותנו” - אנחנו ממש רואים אותו שולף את השמות האישיים של האנשים שיכולים להתחבר.
• והוא מתמקד ב-WhatsApp-ים - פעם ראשונה אנחנו רואים מישהו שאשכרה מעין אותו ה-WhatsApp Web, זה היעד שלו.
• עובר תיבה-תיבה, כאילו - תיבת-מייל, תיבת WhatsApp, עובר כל פלטפורמה שהוא יכול - ובעצם עושה לנו Data Mining בסביבה,
• ואנחנו רואים שהוא “חי שם”, לאורך סדר-גודל של שבועיים-שלושה - והפעם, רגע, יש מישהו “שמבין תוכנה”.
• יש תוקף שיודע מה זה תוכנה - הוא יודע לקמפרס (Compress), הוא יודע על בעיות Bandwidth, הוא ממש חי את זה.
• הוא מבין רגע שה-SYSVOL - בעצם תיקיית הפצת-העדכונים של Windows, נגישה לכולם.
• ועוד פעם, כמו במלחמה - נכנסים ל-72 שעות מאוד מאוד ארוכות . . . .
• אני יכול להגיד לכם בנימה אופטימית ש . . .

(אורי) . . . כנראה שיכולות להיות רק 72 שעות ב-72 שעות . . . (רן) דיברנו על “דונם גדול” ו”דונם קטן”?

• (מושיקו) המדינה יותר קטנה בלילה, כן . . . זה טיפ חשוב.
• אז לדעתי המון זמן לא אכלתי 72 שעות רצוף, מה שנקרא.
• “נכנסים לקרב”, בעצם רצים משרת לשרת, ממכונה למכונה - ופה המזל לא משחק לנו, כי פה זו סביבה שיכולה לצאת לאינטרנט מכל Endpoint, כל Endpoint נגיש.
• ופה מתחיל “חתול ועכבר” . . .
• וכאן כמה טיפים כן טובים שאני לקחתי מהאירוע הזה.
• אחד - ערנות מוגברת ומודעות משתמשים הרבה יותר טובה ברוב הפעמים מכלי-הגנה נורא נורא יקרים.
• פה היה חוסר מודעות של משתמשים והתנהגות בעצם שהיא “Misbehaving” - התנהגות שהיא קצת לא תקינה.
• שימוש ברכיבים-ארגוניים לטובה צרכים אישיים.
• בעצם ייצרו איזושהי יכולת לתוקף להשיג מידה שהוא לא יכול היה להשיג, אלא אם היה צריך להגיע אליי הביתה.
• זאת אומרת הוא לא . . . אני דמות, אני בחור ממש נחמד, אני Head of Research - אבל כנראה שאת הכתובת של אמא שלי הוא לא ידע להשיג, כי זה לא הדבר הכי חשוב בעולם בשבילו.
• אבל פתאום, כשיש לו נגישות ל-WhatsApp שלי, לשמות של הילדים שלי, לחברים שלי מהקורס טייס, לחברים שלי מכל מיני מקומות - יש לו נכס מאוד מעניין ביד.
• ופה אנחנו בעצם נלחמים מלחמה שהיא בין התודעה לבין “מלחמת נוחות” - ופה אנחנו דווקא יוצאים עם ידינו על העליונה, באירוע הזה.
• זאת אומרת, מבצעים מיטיגציה (Mitigation) הרמטית - חוסמים את התוקף, מצליחים “לצאת מנצחים הביתה”.
• כן מצליחים לחסום את מרבית ה-Data שנגנב - זאת אומרת, רוב ה-Data שנגנב בעצם נאסף לתוך איחסון מרוכז, מקומפרס (Compressed), זאת אומרת הוא דוחס אותו . . .

(רן) . . . עדיין אצלכם, זאת אומרת - ראיתם את זה . . .

• (מושיקו) כן, עדיין אצלנו. אנחנו רואים “זרזיף-תקשורת”, נקרא לו ככה, שיוצא החוצה - זאת אומרת, ממש ניסוי “העברת חוטר”, אבל לא הצלחה.
• ופה בעצם אנחנו אומרים “חבר'ה, הפסדנו פעם אחת לפני חצי שנה שנה - בואו ננצח הפעם”.
• חוסמים את התוקף בזמן, מצליחים בעצם “לצאת מנצחים”.
• ועוד פעם, טיפ מאוד חשוב לאירועים האלה - יש בדרך כלל באירוע Cyber, שבו יש תוקף “חי” ולא איזה מערך -Bot-ים, יש 72 שעות עד שאתה . . . בעצם, מהרגע שהחלטת לפעול ועד הרגע שבו לתוקף ולך “נגמר האוויר”.
• וזה זמן לקחת “החלטות אמיצות” - החלטות שיכולות להציל את הארגון.
• אז ככה אני הייתי מסיים, בנימה אופטימית זו, את הסיפור הזה.

41:47 נימה אופטימית(רן) טוב, סיפור אופטימי לסוף זה כבר נחמד . . . נשמע מרתק.דיברנו בעיקר על הניסיון הצבאי - אבל יש, אני מניח, גם לא מעט באזרחות. אז בואו נסיים - אבל רק כמה מילים אולי שוב על upwind? אז אני מניח, ואתה אמרת, שאתם משהו כמו 150 עובדים, באזור תל אביב.מחפשים אנשים? מגייסים? מה?

• (מושיקו) כמובן, רגע - ה-Talent הישראלי זה לדעתי הדבר הכי מהמם שיש לנו פה במדינה שלנו.
• מגייסים. היום יש לנו מעל עשרה תקנים, מעל עשר משרות עם מעל עשרים תקנים.
• מחוקרי-חולשות וחוקרי Security עד ל-Frontend ו-Backend ו-QA ו-BDR וכל מה שצריך בתעשייה.
• חברה מעולה, אפילו משפחה - בשבילי זה קצת יותר משפחה לפעמים.

(רן) שם אין 72 שעות . . .

• (מושיקו) שם כל יום הוא 72 שעות - בקטע הטוב, כמובן.

(רן) תמכור קצת . . .
תודה רבה.

 האזנה נעימה ותודה רבה לעופר פורר על התמלול!

[קישור לקובץ mp3]
פרק 476 של רברס עם פלטפורמה, שהוקלט ב-25 ביולי 2024 (יומיים אחרי ההקלטה הקודמת). אורי ורן מארחים בשבוע ה-ML (הלא רשמי) את דגן מחברת Citrusx לשיחה על ארגונים ש-ML חשוב להם. 00:45 דגן ו-Citrusx ורברס עם פלטפורמה (באמת)(רן) אז לפני שנצלול לעסק - קצת עליך ועל החברה?

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

(אורי) . . . . אתה בחברה טובה . . . . לא מעוטף-עזה, אבל גם אנחנו, שנינו.

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

(אורי) לא, אבל בוא נשאל את השאלה - מתי בפעם הראשונה עשית רברס עם פלטפורמה?

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

(אורי) . . . . חרא עד הברכיים הברכיים - קדימה . . . 

• (דגן) זה כן . . . 

(רן) טוב, אז אתה בחברה טובה . . . . אוקיי, אז גדלת שם, ואחר כך?...

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

(רן) . . . נשארת עם הכלי . . . 

• (דגן) נשארתי עם הכלי - אבל תמיד איפשהו התעסקתי בדברים שקשורים.
• אם זה ראייה ממוחשבת, Machine Learning - זה איפשהו בעולמות האלה.
• אחרי התואר עבדתי גם ב-Mobileye ובעוד כל מיני סטארטאפים - תמיד סביב טכנולוגיה, דברים מוחשיים, על התפר שבין תוכנה לאלגוריתמיקה.
• עם הרבה מאוד התעניינות באמת בעולם הזה של ה-Machine Learning, AI - השמות השתנו עם הזמן . . . 
• “איך המחשב חושב” ואיך לגרום לו “לחשוב יותר טוב”.

(רן) כן. עוד יש כאלה שקוראים לזה אלגוריתמיקה . . . מעולה. והיום אתה נמצא בחברת CitrusX - באיזה Capacity? מה תפקידך שם?

• (דגן) אז היום אני ב-CitrusX כבר שנתיים וחצי, אפילו קצת יותר.
• בתפקיד של ה-VP R&D - בעצם מוביל את הצד הטכנולוגי, את הפיתוח של המוצרים.

(רן) אוקיי. אז CitrusX - מה עושים שם?

• (דגן) אז CitrusX - קודם כל אנחנו סטארטאפ צעיר יחסית, היום 16 עובדים, נמצאים בתל אביב.
• ובעצם המטרה שלשמה החברה קמה היא לעזור לארגונים שהם בסיכון גבוה להיכנס לעולמות של Machine Learning.
• אם היום הטרנד זה GenAI, ואי אפשר לעשות פודקאסט טכנולוגי בלי להגיד GenAI ...
• (רן) הנה, עשינו “v” גם על זה . . . .
• (דגן) עשינו “v” גם על זה . . . . 
• אז ארגונים רבים - כאילו, תעשיות של פיננסים וביטוח וכאלה - הם ממש לא שם.
• הם עוד... 30 שנה, 40 שנה אחורה - והם מנסים להיכנס לעולמות של ה-Machine Learning הקלאסי.

(רן) עוד קשה להם עם הרגרסיה הלינארית . . . 

• (דגן) הרגרסיה לינארית הם בסדר - קשה להם לעשות את הצעד הבא.

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

• (דגן) אז אני חושב שמילת-המפתח פה היא “אמון” - זאת אומרת, לקבל אמון “בקופסה השחורה” הזאת.
• והצד ההפוך של זה זה ה-Risk, זה הסיכון - זאת אומרת, כל מיני קבוצות בארגון שמפחדות לקחת סיכונים, ומשליכות את זה על המפתחים, על האלגוריתמיקה.

(רן) כן. זאת אומרת, אם יש איש Machine Learning או Data Science או אלגוריתמיקה או איך שלא נקרא על זה, שעובד בבנק, והוא פיתח מודל נהדר לחיזוי של Whatever - מניה או ריסק בהלוואה או כל דבר כזה. אפילו אם המודל, יש לו ביצועים נהדרים - יכול להיות שהבנק יימנע מלהשתמש בו, בגלל סיבות של אקספלינביליות (Explainability), סיכון . . . 

• (דגן) אז כל הדברים האלה - אקספלינביליות (Explainability), סיכון, רגולציות, ביצועים של המודל . . .  בעצם “לסמוך על המודל".
• אז יש פה תסכול של שני הצדדים - ה-Data Scientist שעובד על המודל חצי שנה, תשעה חודשים, שנה . . .  כמה זמן שלוקח לפתח את המודל הנהדר שהזכרת קודם - ואז, בישורת האחרונה אומרים לו “לא, לא, לא, אתה לא יכול להתקדם”.

(אורי) למה? כי אין אמון.

• (דגן) למה? כי אין אמון . . . “כי אני צריך שתוכיח לי שהמודל לא יפשל בזמן אמת” ו-”אני צריך שאני אוכל להסביר כל החלטה שהמודל מקבל” ו-”ויש לי רגולציות על הראש!” . . . .
• אולי נדבר על זה עוד מעט, אבל עד לפני שנה-שנתיים זה היה בעיקר רגולציות פנימיות, כי החברות חוששות ולא רוצים שיתבעו אותן ולא רוצים “לעשות פאדיחות” או נזקים של מיליונים, ויש דוגמאות כאלה . . .

(אורי) אבל זה קצת, בוא נגיד ככה, “מובנה”. מכיוון שרוב - בוא נודה על האמת - רוב ה-Machine Learning ורוב ה-AI - בסוף הוא סטטיסטי. ובמשהו שהוא סטטיסטי, יש איזשהו סיכון. אני הייתי נוהג להגיד לאנשי Risk או כל מערכת טכנולוגית, “קחו את זה בחשבון כשאתם עולים על מטוס” . . . . אז צריך לדעת לנהל סיכונים בכל מקום.

• (דגן) נכון, וזו בדיוק מילת המפתח פה - “ניהול סיכונים”.
• צריך לדעת מתי זה בסדר לקחת את הסיכון ומתי זה לא בסדר לקחת את הסיכון.
• ואם המודל Machine Learning, בתפיסה של הרבה מאוד אנשים, זה “קופסה שחורה”, אז “אני לא מתעסק עם זה”.
• כי אני לא יודע מתי הוא יפשל, אני לא יודע איפה.
• וכאן אנחנו נכנסים בתמונה, בעצם.

(רן) כן, אני מניח שעולם מקביל לזה זה עולם של נגיד מכוניות שנוהגות אוטונומית - שגם שם יש סיכונים, ומצד שני, אנחנו מבינים שגם לתת לבני אדם הגה בידיים זה מסוכן, ככה שזה לא . . . אין פה איזשהו משהו שהוא חד וחלק.
07:35 אז איך עוזרים?(רן) אז איך אתם בעצם עוזרים לאותן חברות? נניח שפיתחתי איזשהו מודל לחיזוי של סיכון של מתן הלוואה ללקוח, אוקיי? איך אתם עוזרים לבנק לקבל ביטחון באותו מודל? (אורי) מה שבעצם זה “חיתום” . . .

• (דגן) נכון. אז זה באמת דוגמא למודלים שאנחנו מתעסקים איתם ביום-יום.
• אז בעצם אפשר להגיד שהמטרה שלנו היא להושיב סביב שולחן אחד את ה-Data Scientist ואת ה-Chief Data ואת ה-Risk Manager ואת ה-Compliance Executive.
• להושיב אותם סביב שולחן אחד - ושכולם ידברו באותה שפה ויבינו אחד את השני.
• והתפקיד שלנו זה לתרגם ביניהם - לקחת את הדאטה והסטטיסטיקות, שה-Data Scientist מפתח, ולתרגם את זה למסמך Legal שהאיש Compliance יודע להבין אותו ולהתייחס אליו.
• ומהמסמך הזה הוא יכול להגיד מה בסדר ומה לא בסדר, מה הוא מוכן לספוג ומה הוא לא מוכן לספוג.
• ואם צריך אז להחזיר את זה חזרה לשולחן השרטוטים - אבל מדויק.
• נגיד, “בנקודה הזאת - את זה אני לא מוכן לקבל”, זאת אומרת...

(אורי) וכמה יוצא לכם, אתה יודע, כאלה שאומרים “אני לא מוכן לקבל כלום!” . . . “לא מוכן לקבל שום פאדיחה”.

• (דגן) אז קודם כל - יש כאלה . . . תלוי בתחומים, אבל יש תחומים שהם עוד יותר שמרניים.
• אבל מה שרואים היום בשוק זה שהחברות מבינות שאין להן ברירה - כי הם פשוט יישארו מאחורה.
• אם המודל-חיתום שלך הוא “פרימיטיבי”, אז יצוצו Digital Banks וכל מיני כאלה שיש להם מודלים יותר חכמים עם סיכון פחות “מפחיד" - ויעקפו אותך.
• [דניאל שרייבר מדבר כאן בגיקונומי על Lemonade ו-AI]

(אורי) וגם בוא נודה על האמת - יש מגבלות Scale. כאילו, אתה יכול לעשות את הכל ידנית, אבל זה פשוט יעלה לך המון.

• (דגן) נכון - וזו אחת הבעיות בעצם.
• כי לקחת מודל אחד ולעשות עליו את הוולידציה (Validation) הזאת וכל התהליך הזה - אפשר לעשות את זה, ואנחנו רואים חברות שעושות את זה.
• ומשיחות שלנו עם לקוחות - זה לוקח להן שישה חודשים, תשעה חודשים . . . 
• לא הבנייה של המודל - מהרגע שהמודל הסתיים וה-Data Scientist “הניח את ההצעה שלו”, עד לרגע  שהבנק או איזה גוף שזה לא יהיה אישר את המודל ואמר “יאללה, אנחנו Good to go”.
• אז זה בסדר כשיש לך מודל אחד - אם יש לך 20, 40, 50 מודלים, זה כבר לא Scalable-י.

10:14 איפה הטכנולוגיה?(רן) כן. אוקיי - אבל זה נשמע כמו איזשהו מוצר . . . . אפילו לא נקרא לזה “מוצר” - זה נשמע כמו “בוא נושיב את האנשים סביב השולחן”. זאת אומרת, איפה הטכנולוגיה פה? אתם בסך הכל חברה טכנולוגית, נכון? אז מה הכלים הטכנולוגיים שמשרתים אתכם?

• (דגן) אז אנחנו באמת חברה טכנולוגית שמייצרת מוצר - ואם תסתכל בשוק, אז השוק הזה הוא “חי”.
• יש כל מיני כלים, אלגוריתמים, שבאים לפתור בעיות ספציפיות - אין איזשהו כלי אחד שמאחד את הכל.
• כמו שאמרת - “להושיב את כולם ביחד ולדבר באותה שפה”.
• והדרך שלנו לעשות את זה היא הטכנולוגיה - בעצם, לקחת את המודל הזה ולעשות לו “X-ray”, להראות בדיוק איך הוא עובד ומה הוא עושה, לפרק אותו לגורמים.
• ולהצביע על איפה באמת יש בעיות ואיפה כדאי להסתכל - ואיפה זה לא מעניין ואפשר להמשיך הלאה.

(רן) כלומר- בואו נעשה את זה רגע ציורי - נלך עם הדוגמא שלי, של מודל של “האם כדאי להלוות ללקוח כסף או לא”. מסתכלים על, נגיד, רקע, השכלה, גיל, מצב משפחתי, תעסוקה וכו’ . . . מסתכלים על כל מיני מיני פרמטרים. ויכול להיות שהמודל אומן כבר על אלף או מיליון כאלה, אז הוא פחות או יותר יודע מה התשובה.אבל אם אתה מקבל פתאום איזשהו Outlier - לצורך עניין, השכלה ממדינה שונה, שאתה לא יודע להגיד עליה כלום, או מישהו שהוא צעיר במיוחד ושמעולם לא ראית - פה למעשה יש לך איזשהו Blind-spot, נכון? אתה לא יודע מה המודל הולך לענות עליו. איך פותרים את זה?

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

(רן) אין בעיה.

• (דגן) אז בעצם, הדבר הראשון שהמערכת שלנו עושה, בהינתן מודל של הלקוח וה-Training Data Set של הלקוח, זה למפות את המרחב.
• אתה דיברת קודם על מודל שמקבל חמישה פרמטרים - במציאות יש מאות.
• אז למפות את זה ידנית זה לא אפשרי.
• אז בעצם הדבר הראשון שהמערכת עושה זה היא לפרוש את המרחב הזה, ולהבין מה לא מעניין.
• למפות את כל האזורים שלא קורה בהם כלום - אין לקוחות כאלה ולא מעניין אף אחד - ולצמצם את זה, קודם כל, ולהתמקד באזורים המעניינים.

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

• (דגן) נכון, אז זה הדבר הראשון - וכבר הורדת את החישוביות שלך בהמון.

(רן) כן. לצורך העניין, ילד בן שלוש עם עשרים שנות ניסיון בעבודה - לא קיים, אז לא צריך להתייחס.

• (דגן) נכון. והדבר השני זה עכשיו להסתכל על החלקים היותר מעניינים - ולהתחיל לאפיין אותם, ולהתחיל בעצם לנתח אותם.
• ופה זה קצת דומה לעולמות של עיבוד-תמונה - כשאני בא לדחוס תמונה, אז יש אזורים בתמונה שהם . . . שקורה בהם משהו, אבל הם לא כל כך מעניינים.
• אם יש לי זברה שעומדת על דשא וברקע שמיים כחולים, אני יכול לייצג את השמיים הכחולים האלה במעט מאוד מידע, כי אין שם שום דבר מעניין . . .
• יש שם איזה גרדיאנט (Gradient) מתכלת לכחול, אבל קל מאוד לאפיין אותו - והוא משעמם.
• (רן) כשדוחסים את התמונה . . .
• (דגן) נכון.
• (דגן) אז בעצם, אם אני מסתכל שוב על המרחב הזה שדיברנו עליו קודם, אז אפשר להגיד שכל מי שהוא מתחת לגיל 18, אז זה טווח גילאים מאוד גדול אבל זה לא מעניין, לא קורה שם כלום.
• המודל יגיד לך “לא”. [“Computer says No”]

(רן) כן. זאת אומרת לעשות איזשהו . . . לייצר איזשהו Bucket כזה. במקום להגיד “לא!”, זה מרחב רציף - לבוא ולהגיד “יש לי פה Bucket ‘מתחת לגיל 18’, וכולם מבחינתי אותו דבר, ב-Bucket הזה”.

• (דגן) אותו דבר, או שקל לי לאפיין אותם באיזשהו קירוב פשוט.

(רן) כן, אוקיי. אז אתה כאילו מקטין את המרחב שלו.

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

(אורי) בעיות יותר קטנות - או בעיות, בעלות סיבוכיות קטנה יותר?

• (דגן) שניהם.
• בעצם, המודל - יש לו סיבוכיות מאוד גבוהה, כי הוא יכול להיות בצורות מאוד משונות.
• הוא בכל נקודה במרחב הוא נותן פרדיקציה - וזה יוצר איזושהי פונקציה מורכבת.
• זה היתרון שלו גם - לכן אנחנו אוהבים אותו, כי הוא יכול לתפוס ניואנסים קטנים.
• אבל עכשיו, מה שאנחנו בעצם באים לעשות בשלב הראשון, זה להתחיל לפרק אותו 
• ולנסות, קודם כל, למצוא Chunk-ים כאלה כמה שיותר גדולים, אבל איפה שאי אפשר - אנחנו נצטמצם.
• אז אם אני חוזר עוד פעם לזברה - 
• השמיים יהיו אזור מאוד גדול, שאני מאפיין אותו מאוד בקלות ואני יכול לתת עליו המון מידע.
• איפה שהזברה נמצאת אני כבר מתחיל לחלק את זה לאזורים הרבה יותר קטנים - כדי לתפוס באמת את הניואנסים האלה.
• (אורי) חלקם שחורים וחלקם לבנים . . . .
• (דגן) חלקם שחורים וחלקם לבנים - ומה שמעניין זה המעבר. 
• בסופו של דבר זה המעבר, כמו בעיבוד תמונה.
• (רן) “קווי המיתאר”, ה-Contour . . . 
• (דגן) מעניין אותי איפה שקורה השינוי.
• אז החוכמה בעצם היא להצליח למצוא את האזורים האלה - שהם מספיק גדולים כדי שתיהיה להם משמעות.
• בסוף, אני לא רוצה להגיע לקוביה שמייצגת בן אדם אחד בלבד.
• אבל מספיק קטנים כדי שאני אוכל לאפיין אותם.
• ואז בעצם מה שקורה בדרך שאנחנו עושים את זה, זה שנוצרים אזורים שהם Interpretable by Design . . .

(רן) כן, אז אתה אומר כאילו שעכשיו לעשות לזה QA זה כבר הרבה יותר פיזיבילי (Feasible) - כי מקודם אם היה מרחב “אינסופי", או “אינסופי בחזקת 100”, אז עכשיו יש לך מרחב של אולי הרבה Bucket-ים, אבל זה כבר הרבה הרבה יותר פיזיבילי, ושם אתה יכול לקחת, נגיד, מייצג אחד מכל Bucket, ולבוא ולבדוק מה קורה איתו, או אולי לגלות שאין לך כיסוי ל-Bucket הזה, ואז לייצר כיסוי.

• (דגן) אז שם, עכשיו אני יכול לגלות המון דברים על כל Bucket כזה.
• אני יכול לגלות מה משפיע על המודל - בגלל שהצורה שבה בניתי את האיזור הזה, אז קל לאפיין אותו.
• אני יכול להגיד “אוקיי - באזורים האלה, מה שמשפיע על החלטה של המודל זה רק המשכורת והגיל של הבנאדם, וכל שאר הדברים הם יותר זניחים”.
• אז כבר...

(אורי) אתם עושים את זה בניסוי וטעייה, או... זאת אומרת, מריצים את המודל, משנים כל מיני פרמטרים ורואים מה ההשפעה, או שמראש בהתבוננות על “ב-X-ray” הזה של המודל, אתם יודעים להגיד מה משפיע ומה לא משפיע?

• (דגן) אז . . . . קצת שניהם.
• קודם כל, אנחנו מסתכלים מראש על הצורה של המודל, וככה אנחנו מפרקים אותו לחלקים יותר ויותר קטנים.
• אבל לא תמיד יש מספיק מידע - זה בדיוק מה שאמרתם לפני דקה.
• לפעמים הגעתי לאיזשהו אזור - והוא מעניין, אני מאוד מאוד רוצה לאפיין אותו, אבל אין לי מספיק נתונים בו.
• ואז נכנס לחלק השני של להוסיף “Data סיננטי” - בעצם, לסמלץ (Simulate) נקודות חדשות, אבל בצורה חכמה.
• שהן מתאימות להתפלגות המקומית.
• זאת אומרת “באיזור הזה - ככה ה-Data נראה”, אז עכשיו אני אייצר עוד הרבה דוגמאות כאלה בתוך האזור הזה, ועכשיו יש לי עוד המון מידע רלוונטי בשביל להגיד איך המודל מתנהג באזור הזה.
• וזה עוזר גם בשביל לדעת מה הצורה של המודל - אבל גם אפשר להשתמש באותו כלי בשביל דברים מאוד ספציפיים.
• למשל, אם אני רוצה לדעת  . . . אחת הבעיות שמאוד מעסיקות חברות, אם זה מתן הלוואה, אז זה אולי ה-Top, זה “הוגנות”.
• אני צריך להוכיח שהמודל שלי “הוגן”.
• ואם הוא לא הוגן אז יתבעו אותי - וזה בעיה מאוד גדולה.
• (רן) מה שנקרא בעברית Fairness ו-Bias . . . 
• (דגן) בדיוק.
• אז אחד הדברים שהכלי הזה מאפשר לנו להגיד זה, אוקיי, אם עכשיו אני מסתכל על Bucket מסוים, שזה “אנשים בגיל ארבעים ומטה שגרים באלסקה”.
• אין לי נשים שם . . . .ב-Database שלי אין נשים.
• והבעיות בתחומים האלה שאי אפשר “לייצר” . . . 
• זה לא כמו בתחומים שאנחנו יכולים להגיד “אז לכו תאספו עוד נקודות ותעשירו את המודל”
• אין - אין לי מה לעשות.
• אז פה אנחנו כן יכולים לעשות זה, כי נגיד . . . 

(אורי) . . .  כי ה-Data סינטטי  . . . 

• (דגן) נכון. אני רוצה לדעת האם באיזור הזה של אלסקה, מתחת לגיל ארבעים, יש אפליה? יש לי רק גברים, אז אני “אייצר נשים” שם.
• אני “אפזר נשים” במרחב הזה, ובוא נראה איך המודל מגיב - האם הוא הוגן או לא הוגן.

(רן) כן, אז נזכיר, כאנקדוטה, נגיד סיפור מפורסם שהיה נגיד - כש-Amazon ניסו לפתח מודל של Hiring, ולהבין האם ה-Hire הבא מתאים או לא מתאים, אז הם למדו על Data היסטורי שלהם. שזה נשמע הגיוני, זאת אומרת - ההגיון של “אנשים שקיבלנו לחברה ונגיד החזיקו מעמד חמש שנים או עשר שנים, ואולי גם עוד הצליחו בתפקיד שלהם - אנשים עם מאפיינים דומים כנראה יהיו מועמדים טובים”. בסך הכל נשמע הגיוני. אבל ברגע שבאו להפעיל את המודל הזה, גילו שהרבה הרבה מאוד נשים מסוננות החוצה . . . עכשיו, זה לא שלמודל היה משהו נגד נשים, אלא שבמידע שעליו הוא התאמן, לצערנו - וכנראה גם לצערם - פשוט היו הרבה פחות נשים, וזה למעשה יצר איזשהו Bias, איזשהו Unfairness מאוד מאוד משמעותי, וכמובן שהם הסירו את המודל הזה ולא השתמשו בו יותר באותו רגע.אבל זו דוגמה שכבר קרתה, אולי אפילו בתום לב - ויכולה לקרות בכל בנק . . . [זה לא משהו שמודלי-AI המציאו - דוגמא של Daryl Morey, מפספס את Jeremy Lin מאחד הפרקים האחרונים של  Freakonomics - Here’s Why You’re Not an Elite Athlete]

• (דגן)  נכון, וזו דוגמה מצוינת - והבעיה פה היא קצת יותר חריפה.
• כי בסוף, מודלים של Machine Learning רוצים למקסם (Maximize) - אז אם היה לי Bias קטן לטובת גברים, עכשיו המודל יכול לקבל נטייה למקסם את הדבר הזה . . . .
• כי בסוף הוא רוצה להוציא את התוצאות הכי טובות, ולגבר יש סיכוי יותר טוב מאשר לאישה - אז הוא “ידחוף” לשם כדי לקבל בסוף תוצאות “יותר טובות”.
• אז לגבי מה שדיברנו עליו קודם, על ה-Data הסינתטי - הוא בדיוק נועד בשביל, בין היתר, לטפל במקרים האלה.
• בשביל להחזיר את הנשים “שנעלמו”.

20:37 הוגנות(רן) בוא נדבר קצת על Fairness - אילו עוד דרכים יש לבוא ולתקן הוגנות של מודל? או בוא נתחיל - לבדוק האם המודל הוגן, ואולי אחר כך גם לתקן אותו? אז אמרת - דרך אחת זה לבוא ולייצר Data סינתטי, במקומות שאנחנו רואים שיש Under-Representation. אוקיי, זו דרך אחת. יש עוד דרכים?

• (דגן) אז קודם כל, אנחנו מדברים כרגע, בתור שלב ראשון, על לזהות את זה.
• ואני אגיד גם שאיפשהו, אחד הדברים שאנחנו למדנו, הוא . . . אנחנו - מאוד בער לנו להגיד “אוקיי, אנחנו מזהים בעיה - בוא נתקן אותה.”
• ועצרו אותנו - כי אמרו לנו “לא לא - אתם לא יכולים גם להיות ‘ה-Validator ההוגן‘, וגם לגעת במודל” . . .
• (רן) . .  יש רגולציה . . . “אל תיגע לי במודל”.
• (דגן) רגולציה . . . 
• אז אני אגיד - אנחנו מתעסקים בלזהות את הדברים, ומשאירים את המיטיגציה (Mitigation) ללקוחות.
• אבל אנחנו כן אומרים להם מה אפשר לעשות.
• זאת אומרת, אני לא נוגע - אבל אני יכול להגיד לך מה כדאי לך לעשות.
• (רן) Fair enough . . . 
• (דגן)  ובעצם, החלוקה הזאת היא ל-Bucket-ים, שתיארנו קודם - היא מאפשרת פתרון יותר חזק מאשר הפתרון הסטנדרטי, שאתה תגיד “אוקיי, המודל מפלה נשים, אז תיתן העדפה לנשים!”.
• כי אז אתה בעצם פוגע בביצועים של המודל . . . 
• ופה אתה יכול לעשות משהו שהרבה יותר גרנולרי (Granular).
• אני לא צריך לתת העדפה לכל הנשים באשר הן - אני אזהה את המקומות שבהם יש בעיה ואני אטפל ספציפית בנקודות האלה.
• זה יכול להיות שידנית מישהו מהבנק יעבור על המקרים האלה.
• או אוטומטית - טיפול שונה באזור אחד, טיפול שונה באזור אחר.

(אורי) יש פה . . .  לתקן או להעשיר Data לאימון - זה לא בדיוק אפליה מתקנת. זה לא אותו דבר.

• (דגן) נכון. אז קודם כל, אני אגיד שאנחנו לא מעשירים את ה-Data של האימון - אנחנו משתמשים ב-Data הזה בשביל לבדוק את המודל.
• בשביל להצליח לבחון אותו בצורה יותר טובה.

(אורי) . . .  כדי להצביע ש”שם יש בעיה” .  . .

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

אפשרי.
23:07 אתה יכול להסביר את זה?(רן) אוקיי, בואי נדבר רגע על נושא אחר - נושא האקספליינביליות (Explainability). לצורך העניין, אני פקיד בבנק ואני רוצה עכשיו לבחון את האם ללקוח מגיע . . . אני רוצה לתת לו הלוואה, ואני מריץ את הנתונים במחשב - והמחשב אומר לי לא. אוקיי, מה אני עושה עם זה עכשיו? . . . אני רוצה איזשהו הסבר - למה הוא אמר לי לא? קודם כל, כדי  להבין, אולי זה טעות, ודבר שני - אולי אני גם צריך לנמק את זה, מתישהו. אוקיי?עכשיו מקודם, אורי - אתה הצעת איזושהי שיטה של אולי לנסות ערכים שונים ולראות מה יצא. להזיז קצת ימינה, להזיז קצת שמאלה - לשיטה הזאת יש שם. קוראים לזה SHAP, פחות או יותר. זאת אומרת, יש שיטה ב-Machine  ,Learning שבעצם מנסה להסביר התנהגות של מודל על ידי ניסיונות. היא קצת יותר משוכללת מזה, אבלבגדול היא יודעת לעשות את זה.אבל מי שאי פעם ראה SHAP, יודע שזה לא משהו שהוא רוצה להציג לפקיד בבנק. אוקיי? . . . . השאלה היא איך כןמסבירים מודל עם 100 . . . עם וקטור באורך 100 של Input ואיזשהו Output שהוא לא יודע, איזשהו מספר Float או Whatever. איך אתה בכל אופן מנגיש אקספליינביליות (Explainability) של מודלים כאלה ללקחות-קצה, שהם לא אנשי Machine Learning או Data Science?

• (דגן) אז קודם כל בוא נתחיל בזה שהבנקאי - הוא לא רוצה לתת הסבר, הוא חייב לפי חוק . . .
• לפי רגולציה, אם ביקשת משכנתא ואמרו לך ‘לא’, הלקוח זכאי לקבל הסבר ללמה הוא לא קיבל את המשכנתא - ומה הוא יכול לעשות בנידון.
• זאת אומרת, הבנק מחויב לתת את המידע הזה.
• ואם דיברת על SHAP, אז SHAP באמת זה משהו גלובלי - הוא נותן מין הסבר על באופן כללי איך שהמודל עובד ואיזה פיצ'רים חשובים יותר וחשובים פחות.
• ופה, מעניין אותנו דווקא ההסבר המקומי - ספציפית במקרה הזה.

(רן)  עבור הלקוח הזה -  לא באופן כללי לאוכלוסייה, עבור הלקוח הזה. 

• (דגן) אז אם אנחנו חוזרים ל-Bucket-ים של קודם, אז אנחנו יכולים להגיד בדיוק באיזה Bucket הלקוח הזה נופל.
• גם אם זה לקוח חדש, שלא ראיתי אותו באימון ולא ראיתי אותו בשום שלב אחר.
• ואני יודע מה מאפיין את ה-Bucket הזה - 
• אני יודע איזה פיצ'רים חשובים שם, אני יודע איזה פיצ'רים לא חשובים שם.
• אני גם יודע להגיד יותר מזה, כי אני בעצם אומר “אוקיי, אני רואה איפה נקודה של ה-Sample הזה, של הלקוח הנוכחי, נפל” - והוא באמת לא קיבל משכנתא.
• אבל אני יכול מאוד בקלות להסתכל מסביב, ולראות מה הוא צריך לשנות כדי כן לקבל את המשכנתא הזאת.
• זאת אומרת, מה המסלולים - מסלולים בגרף הזה - ההכי קצרים, בשביל להגיע מ”לא” ל”כן”.

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

• (דגן) וזה כבר הסבר שבנק יכול להבין - ויכול להנגיש אותו ללקוח.

(רן) כן - וזה גם Actionable-י. זאת אומרת, הלקוח יכול כנראה לעשות עם זה משהו . . .
(אורי) . . . יש לו מה לעשות עם זה, כן. אבל אני רוצה לדבר על הנושא של ה-Auditing, בסדר? שינוי במודל, או ב-Training של המודל, יכול פתאום לגרום לבנק או לחברת ביטוח לשנות את מדיניות החיתום שלה. ובסך הכל מה קרה? אימנו מודל . . . עכשיו, בחוקים של Auditing, של בקרות - זה “Big No-No”.אז איך מתמודדים עם זה?

• [דגן] אז קודם כל אני אגיד שזו אחד הסיבות שהגופים האלה - הם לא יכולים לעשות, נגיד, מודלים שלומדים On” the Fly”. 
• הם לא יכולים לעשות Online Learning משום סוג - כי אסור להם, בשורה התחתונה.
• אבל גם אם היה מותר להם - הם לא היו עושים את זה, בדיוק מהסיבות האלה.
• אני לא רוצה לגלות יום אחד שהמודל שלי טעה, והיו דוגמאות ל...

(אורי) פשוט אין לי את מי להאשים . . . .

• (דגן) אתה מאשים את ה-Data Scientist בסוף . . . 

(אורי) לא, “המודל טעה”, כאילו...

• (דגן) נכון, וזה באמת פחד מאוד גדול של כל החברות האלה.
• וזה לא רק בבנקים - זה באופן כללי.
• הרצון לדעת איפה אני יכול לסמוך על המודל - ואיפה אני פחות יכול לסמוך על המודל.
• וזה מאוד חשוב.
• ושוב, מאותם כלים שדיברנו עליהם קודם - זה עוד מידע שאפשר להפיק אותו.
• הפתרון שלנו, או פתרונות דומים, “ממפים את המרחב” בעצם
• ויכולים להגיד לך “באיזור הזה יש לך סיכון יותר גבוה”
• “סיכון” במובן “שהמודל יטעה”, או שהמודל יעשה את מה שלא חשבת.
• באיזורים אחרים, אתה יכול לסמוך על המודל.
• כי למרות שזה איזור מורכב - מבחינת הצורה של המודל וכו - הוא אמין באיזורים האלה.
• “כשהוא אומר אז הוא צודק במה שהוא אומר”
•  עכשיו אתה שואל “אבל איך אני יודע שההסבר או הצורה שבה המודל חושב היא נכונה, ושהיא תואמת את מה שאני רוצה ואת המדיניות חיתום שלי”?
• ופה עוד פעם נכנס ה-Explainability הזה לתמונה - ואחד הדברים שאפשר לעשות . . . 
• אם אתה עכשיו ממפה את כל המרחב ויש לך את ה-Explainability עבור כל נקודה במרחב, אחד הדברים שאפשר לעשות זה להסתכל עכשיו על כל ההסברים האלה ולראות האם הם הגיוניים.
• אז אני למשל יכול לקבץ אותם ל-Cluster-ים ולהסתכל על כל Cluster ולהגיד “אוקיי, זאת המדיניות שלי בעצם - ה-Explainability של ה-Cluster זה המדיניות”.
• זה אומר “ גיל מעל ככה וככה והשכלה כזאת וכזאת” - וזה מה שמשפיע על החיתום, “כן” או “לא”.
• זה Cluster אחר - הוא מתנהג אחרת.
• ואם עכשיו יש לי Sample-ים שהם לא מתאימים לזה
• אז א' - אני יכול לראות שה-Explainability שלהם שונה, שיש לי פה איזו אנומליה, משהו שהוא חורג ממה שאני מכיר

• (אורי) ואת זה גם אפשר לבדוק אוטומטית . . . 

• (דגן) ואת זה אפשר לבדוק גם אוטומטית וגם ידנית - זאת אומרת, יש לי משהו חורג, אז א' - אני יכול להגיד “רגע רגע רגע -  בוא נעצור”, ובמקרה “הקיצוני” נקרא לזה, יבוא הבנאדם, יבוא הבנקאי, ה-Domain Expert, יסתכל על ההסבר ויגיד “הגיוני” או  “לא הגיוני”, “אני מקבל את זה” או  “אני לא מקבל את זה”

• (אורי) . . . או שבעצם המטרה של האימון של המודל הייתה לתקן את הבעיה הזאת והזאת - זה באמת קרה, ולא נגרם שום נזק אגבי אחר.

• (דגן) נכון.

• (דגן) ואגב, גם בדרישות של הרגולציה, והיום זה ניהיה נושא מאוד חם, הרגולציות שיוצאות - האם זה טוב לשלוט על ה-AI, האם זה לא טוב לשלוט על ה-AI - דיון סוער בכל העולם, אבל בפועל זה קורה, רגולציות קורות.
• אז אחד הדברים שאומרים שם ברגולציה זה לא שאסור לך לעשות שום דבר ולא שאסור לך להפלות אף אחד באוכלוסייה - אבל “אתה צריך להראות לנו את ה-Tradeoff”.
• אתה צריך להראות לנו “מה היה קורה אם” -  כי אם עכשיו היית מפלה אנשים פחות, כמה אתה היית מפסיד מזה? כמה העסק שלך היה נפגע מזה?
• ויש להם איזה כללים, למתי זה בסדר ומתי זה לא בסדר.
• ועכשיו אתה צריך להוכיח שזה באמת המצב . . . 

(רן) קודם כל שבדקת . . . 

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

30:54 תקרת-הזכוכית והדברים היותר “Cool-יים”(רן) אני שם רגע את הכובע של איש ה-Data Science או ה-Machine Learning - ונשמע לי שהפתרון הזה יכול לעבוד בפועל על מודלים יחסית פשוטים, מה שנקרא מודלים של Machine Learning “קלאסי” - אם זה עצי-סיווגאו רגרסיה-לוגיסטית או דברים בסגנון הזה, ואולי גם לדברים קצת יותר מתוחכמים. אבל “אין מצב” שזה יעבוד עבור Deep Neural Networks או כל הדברים ה-Cool-יים שפועלים היום. זאת אומרת, אם אני בתור בנקאי, ורוצה לשים איזשהו מודל Chat שיבוא ויסביר ללקוח האם הוא זכאי או לא זכאי ומה הוא צריך לעשות כדי כן להיות זכאי למשכנתא, כנראה שהכלים שלכם לא יכולים לעזור לי שם . . . (אורי) אבל השאלה, רן, האם צריך כלים כאלה? . . . (רן) לא משנה, עזוב, אני לא איש-המוצר כרגע - אני איש ה-Machine Learning . . . (אורי) . . . אתה מחפש משהו Cool לעבוד עליו? . . . (רן) כן . . . . לא, אז מה שאני שואל בעצם זה מהי כרגע תקרת-הזכוכית שלכם? זאת אומרת, לאיזה סוג של מודלים זה יכול לעבוד ואיפה אתם יודעים שפשוט לא כדאי לנסות אפילו?

• (דגן) אז קודם כל אני אתחיל בזה שזה בעצם תלוי בהגדרת הבעיה ולא באיךאתה פותר את הבעיה.
• זאת אומרת, אם הבעיה שלך היא לקחת כמה עשרות או מאות פיצ'רים (Features), ולקבל בסוף פרדיקציה (Prediction), כמו שדיברנו קודם - אז “לא אכפת לנו” אם אתה תפתור את זה עם Deep Neural Network או עם רגרסיה-לינארית או עם “קבוצה של הודים” שידנית מהר-מהר-מהר נותנים לך תשובה [הם מריצים מודל בעצמם . . . .]
• מבחינתנו, יש Input, יש Output - ואנחנו נדאג לכל מה שקורה באמצע.
• אז במקרה הזה, הטכנולוגיה היא . . .  ה-Framework שאיתו בנית את המודל לא מעניין אותנו.
• אבל כמו שאמרת, יש... 

(רן) אז ה-Output הוא סיווג - “כן” או “לא”, או אולי איזשהו מדד Risk, מספר Float - אבל לא יותר מזה.  אבל אם ה-Output הוא רצף של Token-ים, כמו שה-LLM מוציא - אז זה כבר סיפור אחר . . .

• (דגן) נכון - וזה בעצם מוצר אחר לגמרי.
• כל מה שדיברנו עד עכשיו זה מוצר מסוג א’ - ויש גם מוצר בעולמות האלה של ה-Generative AI.
• ופה באמת הגדרת הבעיה ישנה וגם ההגדרת הפתרון ישנה - וגם הרגולציה ישנה . . .
• זאת אומרת, אנשים - במקרה הזה לא מעניין אותם להגיד איזה Feature גרם לך להגיד מילה מסוימת.
• האקספלנביליות (Explainability) פה היא בצורה אחרת.
• פה בעצם מעניין אותך דברים כמו Hallucinations - איך אני יודע שמה שהמודל הוציא עכשיו זה אמיתי וזה לא סתם איזו המצאה שהוא”הזה”?
• אני רוצה לדעת על מה זה מבוסס - נתת לי איזושהי תשובה בנית Chatbot או איזה דוגמה שאני לא ארצה - על מה זה מסתמך? איפה הרפרנסים (References) האמיתיים לדבר הזה?

(רן) הנה, אתה רואה, אורי -  זה לא רק אני! הם בונים מוצרים, זה לא רק אני מדמיין . . . 

• (דגן) וזה . . . בוא נגיד שאם הגופים המאוד Regulated הם עדיין בעולם של ה-Machine Learning “הקלאסי”, אז הרבה חברות אחרות הן באמת כבר מאמצות טכנולוגיות יותר מתקדמות.
• ויש להן סט של בעיות אחרות - והתמודדות היא גם שונה.
• ואגב - זה יכול להיות אותו גוף. 
• כאילו, אותו “בנק דמיוני” שדיברנו עליו קודם - כשהוא צריך לתת הלוואה, אז הוא משתמש במודל המאוד פשוט . . . 

(אורי) . . . כי התשובה שם היא “כן” או “לא”.

• (דגן) כי התשובה שם היא “כן” או “לא”.

(אורי) . . . לא צריך פה לכתוב נאום לקונגרס . . .

• (דגן) . . . וכשהוא מפעיל שירות-לקוחות, אז הוא רוצה איזשהו Chat Bot GenAI מתוחכם - וגם שם יש עכשיו כבר  . . .
• הרשת מלאה בדוגמאות של לקוח ששכנע את ה-Chatbot למכור לו רכב בדולר אחד - וברגע שה”Computer says Yes”, אז הוא מקבל את הרכב שלו בדולר אחד. 

• (רן) יש סיפור, אני חושב שעל Air Canada, שמכרו כרטיסים בזול מדי בגלל טעות של ה-Bot. 

• (דגן) נכון . . .

• אז יש - הדוגמאות הולכות ומצטברות, לדברים האלה - והחברות באמת נלחצות מזה, ובצדק.
• זאת אומרת, הבעיות הן אחרות, הפתרונות הם אחרים - אבל המהות היא אותה מהות: “אמון”. 
• “איך אני יכול לסמוך על המודל הזה, ששחררתי אותו לחופשי, שלא ימכור לי כרטיס טיסה במחיר מופחת או כל מיני דברים אחרים” . . .
• שלא יקנה בית . . . אחת הדוגמאות המוכרות - שלא יתחיל עכשיו לקנות בתים ולגלות שאין משהו שעומד מאחורי זה ואני אפסיד מיליונים . . . 
• (רן) איך קראו לחברה הזאת? חברת הנדל”ן הזו? שכחתי . . .  
• (דגן) Zillow?
• (רן) כן, Zillow . [ד”ש - Why the iBuying algorithms failed Zillow, and what it says about the business world’s love affair with AI]

• 
  

35:10 עוד סוגי חברות ו-Domains(רן)  אוקיי אנחנו ככה כבר לקראת הסוף בואו נעשה איזשהו סיכום. אז דיברת על חברות שיש להן מודל Risk גבוה,ודיברנו בעיקר על פיננסים - במקרה, סתם -  אני משכתי לשם. אבל מה עוד יש שם ב-Domain הזה? איזה עוד סוגי חברות?

• (דגן) אז כל חברה שיש לה סיכון גבוה, בעצם. 
• זה יכול להיות חברות ביטוח, זה יכול להיות חברות ביטחוניות, זה יכול להיות חברות רפואיות . . . .
• מפעלים שהם, שוב - ב-High risk.

(רן) ובשבילכם זה Same-Same? כאילו, אתם יכולים לעבוד עם כולם? אתם לא צריכים אדפטציות (Adaptions)?אתם-עצמכם לא צריכים להיות Domain-Experts בכל אחד מהם?

• (דגן) אז יש פה שני אספקטים. באספקט של ה-Deep Tech - מספרים.
• יש לי Data-set אחד עם מספרים, שקראתי לזה “מודל חיתום”, ו-Data-set אחד עם מספרים שקראתי לו . . . לא יודע מה, “Digital Health” . . .

(אורי) אבל במקום הזה, ה-Domain העיקרי שהמודלים האלה מתעסקים בהם זה הערכת ריסק? או לא קשור?

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

(רן) צריך להבין מי הלקוח, גם לדעת איך למכור לו .. . 

• (דגן) נכון, ואנחנו סטרטאפ קטן, אתה לא יכול “להתפזר על כל העולם”.
• ופה אתה רוצה כן לעשות את הספציפיקציה (Specification) הזאת.
• כאילו, כמוצר אתה תגיד “אוקיי, אני עכשיו אתן אתן מוצר ל-Fair-Lending: הוא מתאים לרגולציה של Fair-Lending, הוא בודק ריסקים (Risks) של Fair-Lending, וכו’.
• או לחילופין, מוצר שהוא . . . לא יודע מה - ביטוח סייבר!

(רן) אוקיי, והלקוחות שלכם, שאתם עובדים איתם - הם בישראל? חו”ל? מה?

• (דגן) בעיקר בחו”ל, בעיקר צפון אמריקה. זה ה-Go-To Market.
• הסיבה לזה היא כוח אדם - צריך להתמקד, שגם לנו יהיה את ה-Expertise הזה.
• בסוף, אני בצוות הטכנולוגי - אבל צוות של ה-Business, חוץ מהדברים הרגילים שצוותי Business עושים, הם גם צריכים להיות מאוד מאוד עם היד על הדופק.
• במובן של איזה רגולציות יוצאות, איזה רגולציות עומדות לצאת.
• ואם עכשיו פתאום בכמה חודשים אחרונים, פתאום ה-EU-AI Act, שזה “ה-GDPR החדש” - הרגולציות בעצם על Machine Learning של האיחוד האירופי - יצאו כבר, בעצם זה כבר שהמדינות חתמו עליהם.
• עכשיו בונים איזשהו Timeline ליישום שלהם,
• אז “פתאום כולם קופצים” . . .

(רן)  כולם מחפשים פתרונות - ואתם מגיעים עם מוצר חם לשוק.

• (דגן) נכון. אז אם לפני שנה-שנתיים, אנחנו היינו צריכים להסביר מה זה, ולמה זה טוב, ולמה צריך את זה - אז עכשיו באים אלינו, ואומרים “רגע, יש לכם פתרון עבור הדבר הזה, שהולך ליפול לנו על הראש?”

38:14 יש מתכנתים ברפת?(רן) אוקיי, אז אתם מגייסים? מחפשים אנשים? מחפשים עובדים?

• (דגן)  תמיד.

(אורי) אם אתם רפתנים לשעבר, אז...

• (דגן) רפתנים שיודעים לתכנת . . .

(רן) איפה אתם יושבים?

• (דגן) תל אביב, שרונה, על הרכבת.

(רן) יפה. אז תודה רבה - ושיהיה בהצלחה.מי שמעניין אותו לעשות Machine Learning קצת יותר בטוח, לעולם בטוח יותר - אז דברו עם דגן.להתראות, תודה רבה. האזנה נעימה ותודה רבה לעופר פורר על התמלול!

[קישור לקובץ mp3]
פרק 475 של רברס עם פלטפורמה, שהוקלט ב-23 ביולי 2024, שיא הקיץ. אורי ורן מארחים את חופית מחברת AI21 Labs, כדי לדבר על מודלי-שפה גדולים עם Context ממש-ממש ארוך (וגם להסביר מה זה).



00:40 חופית ו-AI21(רן) אבל קצת לפני זה - עליך, חופית, ועל החברה. מי את? מה עשית עד היום? מה עושים אצלכם בחברה?

• (חופית) אז אני חופית, ואני כרגע חוקרת ומפתחת מודלי-שפה בחברת AI21 Labs.
• נולדתי וגדלתי ברמלה, אם נחזור ממש להתחלה.
• בגיל 14 כבר התחלתי לתכנת - בבית הספר הכניסו אותנו לזה יחסית מוקדם - והבנתי שזה מה שאני הולכת לעשות כבר אחרי יומיים.
• אז הגעתי למודיעין, ליחידה צבאית, יחידה מודיעינית - דווקא לא תכנתתי שם, אבל ישר אחרי הצבא התחלתי תואר במדע המחשב באוניברסיטה העברית.
• מהר מאוד הבנתי שאני רוצה לשלב עם מתמטיקה. התאהבתי במתמטיקה - מתמטיקה תיאורטית, חשוב לציין, כי בתיכון לא כל כך אהבתי . . . 
• אז עשיתי תואר משולב עם מתמטיקה.
• (רן) אז אם אני אבקש ממך עכשיו את הנוסחא של דטרמיננטה, את לא תדעי לשלוף לי . . .
• (חופית) ממש לא . . . 
• (רן) . . . אבל תורת החבורות - בכיף . . . 
• (חופית) תורת החבורות - אני מקווה שזה יהיה הדוקטורט שלי יום אחד . . . [ד”ש לגלואה].
• (חופית) ולקראת סוף התואר השני התחלתי לעבוד ב-Mobileye, בתור חוקרת - אבל בעולם ה-Vision.
•  בעצם, כל עולם הראייה ממוחשבת וזיהויים, ופיתוח המכונית האוטונומית של Mobileye.
• וגם החלטתי שאני ממשיכה לתואר שני.
• בתואר השני, בהתחלה לא הייתי בטוחה מה אני רוצה לעשות - ידעתי שזה יהיה Machine Learning, ידעתי שאני רוצה לשלב גם תיאוריה.
• זאת אומרת, לא רציתי להתנתק מהתיאוריה.
• ובעצם התחלתי את את התזה שלי אצל פרופסור אמנון שעשוע.
• (רן) שמענו עליו . . . 
• (חופית) כן . .
• (רן) נזכיר - אחד המייסדים של Mobileye, וגם של החברה, של AI21 . . .
• (חופית) נכון, ועוד כמה חברות כאלה ואחרות.
• וביום שהגעתי, המעבדה של אמנון עד אז התעסקה יותר ב-Vision, בקוונטים, בדברים כאלה ואחרים.
• כן בהקשרים כמובן של Machine Learning.
• וביום שהגעתי, אמנון פשוט החליט שעושים העברה לטרנספורמרים (Transformers) ול-NLP, כי יצאה עכשיו הארכיטקטורה.
• זה היה ב-2018, כשזה עוד לא התפוצץ - אבל אמנון ראה שזה הולך להתפוצץ.
• (רן) ימי BERT העליזים . . . 
• (חופית) בדיוק, ימי BERT העליזים, לגמרי - זה היה הדבר הראשון באמת שהתעסקתי איתו.
• וככה הגעתי לתחום - זו הייתה הפעם הראשונה שבה בעצם נחשפתי לתחום בכלל.
• אפילו לא לקחתי קורסים ב-NLP לפני זה - אז זה באמת היה ממש כניסה שהייתה מאוד מפתיעה מצד אחד, ומצד שני הרגשתי שלא חסר לי יותר מדי רקע.
• כי טרנספורמרים היה משהו מאוד חדשני ושונה מהכלים שהיו קיימים לפני זה . . .
• (רן) . . . כולם פחות או יותר זינקו באותו זמן, זה היה איזשהו Equator, שהשווה את הסיכויים לכולם
• (חופית) נכון - אבל גם אם נסתכל על זה מבחינת מודל מתמטי, זה מאוד שונה מ-RNN ומ-LSTM, מה שהיה לפני, אז לא הרגשתי שיש לי יותר מדי פער, אפשר להגיד.

(אורי) כמו לכולם . . . (רן) כן . . . . אז למי שזוכר את הרובוטריקים, כן היו שם טרנספורמרים - אבל לא עליהם אנחנו מדברים . . . . Transformer זה ייצור מתמטי, שמשתמשים בו ברשתות-ניורונים. למעשה, הוא ה-Building-Block המשמעותי בתוך מנועי-שפה גדולים. והזכרנו מקודם את BERT - זה היה אחד ממנועי-השפה הראשונים שהשתמשו ב-Transformer, אם לא הראשון בכלל . . . . זה הראשון או אחד הראשונים?

• (חופית) אני חושבת שהוא הראשון . . . . הוא היה Encoder-Only.

(רן) כן, Attention Is All You Need . . . . אוקיי, אז היית במעבדה של פרופסור אמנון שעשוע . . . 

• (חופית) . . . . ושם נכנסתי לתחום. 
• ביליתי שם בערך שנתיים - הוצאנו תזה שיש בה גם פן תיאורטי וגם פן טכני
• בעצם, דיברנו שם וחקרנו את ה-Tradeoff שבין עומק ורוחב של רשת
• “עומק” זה אומר כמה שכבות יש לה, וכשאנחנו מדברים על “רוחב” זה לרוב מימד-ההטלה (Projection), “הגבוה” שאנחנו מגיעים אליו כשאנחנו מטילים את הוקטורים של האינפוטים (Input vectors) שנכנסים למודל, שתיכף נדבר גם על זה יותר.
• בגדול, חקרנו את זה כי הבנו וראינו - גם הבנו תיאורטית, לשם אני פחות אכנס - אבל גם בעצם עשינו ניסויים ממש פרקטיים, שמראים את זה.
• שמה שהתרגלנו עד היום במודלי Vision, בכל הרשתות-קונבולוציה (But what is a Convolution?), זה שבעצם הרבה פעמים היא הייתה יחסית “צרה” ומאוד מאוד “עמוקה”.
• אנחנו מדברים על איזה 90, 120 אפילו 150 שכבות.
• ובטרנספורמרים (Transformers) פתאום זה קצת משתנה.
• אז באמת חקרנו את כל ה-Tradeoff הזה, הגענו למסקנות כאלו ואחרות ולכל מיני סוג-של-נוסחאות, שבעצם מראות מתי עדיף שרחב יותר, מתי עדיף שיהיה צר יותר
• יותר רדוד או עמוק יותר.

(רן) זאת אומרת שבאותו מספר פרמטרים, נגיד מיליארד פרמטרים - היום הרשתות, רק כדי לסבר את האוזן, הרשתות “הקטנות” זה שבעה מיליארד, בגדולות זה מאות-מיליארדים - אבל גם שם אפשר להחליט עד כמההרשת היא עמוקה או רחבה. זאת אומרת, הגעתם לאיזושהי נוסחה של מה ה-Tradeoff העדיף בהינתן Use Case.

• (חופית) נכון, ובעצם AI21, החברה שאז לא הכרתי בשלב הזה, אימצה את השיטה שלנו - וככה גם לראשונה נחשפתי אליהם.
• למה אימצה? כי AI21 מאמנת מודלי-שפה מאפס בעצם, Foundation Models, את כל שלב ה-Pre-Train, ממש ממש מאפס, משקולות מאותחלים ראנדומית (Random Initialization) לגמרי, כבר המון שנים.
• וזו החברה היחידה שעושה את זה בארץ.
• אז ככה הגעתי אליהם - כי ידעתי שזה מה שאני רוצה לעשות.

(אורי) אז רגע רגע - אולי תספרי לנו שנייה מה עושה AI21? חוץ מלאמן מודלים “לצורכי שעשוע” . . . זה משחק מילים, . . .

• (חופית) אז באמת, כל הפן של חדשנות טכנולוגית מאוד מאוד חשוב לנו, שעל זה גם ניכנס גם עם Jamba וניגע בזה ולמה ואיך.
• אבל היא בעצם מנגישה מודלים לעסקים כאלה ואחרים - אם זה בתחום ה-Finance ואם זה בתחום הבריאות ודומיינים (Domains) כאלה ואחרים.
• זאת אומרת, הרבה פעמים זה לעסקים שצריכים ממש את ה-Domain הספציפי שלהם, ומודל שאפילו הרבה פעמים המשיכו לאמן אותו על ה-Data הספציפי שלהם.
• והיום, רוב התעשייה לא יודעת לעשות את זה בעצמה - היא צריכה את האנשים שיעשו את זה בשבילה, ולהתבסס על המודלים שלהם גם.

(אורי) אז בא לקוח, יש לו Data, הוא יודע מה הוא רוצה להשיג מה-Data הזה - והוא בא אליכם, ואתם מאמנים לו מודל?

• (חופית) נכון, כן. “בין היתר”, אפשר להגיד . . . 
• הרבה פעמים אנחנו מכוונים אותו למה הוא רוצה - כי הוא רוצה דברים מאוד גדולים,
• ואבליואציה (Evaluation) של מודל - זאת אומרת, השלב שבו אתה עושה לו טסט על בכלל מה אתה רוצה ממנו - זה שלב שהוא אתגר בפני עצמו.
• אם נשים רגע את האימון של המודל בצד, שזה האתגר שלי בצוות, אם אני כרגע בעצם בצוות של ה-Pre-Train Model ב-CTO Office, אני חוקרת שם.
• אז אנחנו עושים בעצם את כל השלב של ה-Pre-Train, כל השלב הראשוני
• ויש את השלב של אבליואציה (Evaluation) של הטסטים - של איך בכלל אנחנו בוחנים אותו.

(רן) האמת שהיום היו לי שלוש פגישות על זה . . . כן, זאת אומרת, יש דומיינים (Domains) שבהם אתה - יש לך איזשהו Ground Truth, זאת אומרת, אתה יודע מתי התשובה נכונה. עם LLM-ים, אין לך את זה בדרך כלל - אתה לא יודע מתי “הוא עושה עבודה טובה" או לא, וצריך לפתח גם את זה. כן, זה מורכב . . . .אוקיי, אז  את אומרת שעוזרים ללקוחות להבין מה הם רוצים - ומדלברים (Deliver) את מה שאתם יודעים בכיוון הזה. 

• (חופית) נכון - וגם חשוב לנו לתרום לקהילה.
•  זאת אומרת, אנחנו לא סתם שחררנו את Jamba כ-Open Source, כי רצינו באמת לראות מה הקהילה עושה,.
• מה היא לוקחת ומה היא עושה איתו.
• זה מאוד היה חשוב לנו לראות ההתפתחויות של הדבר הזה.

09:13 מה Jamba?(אורי) טוב, אז זה פעם שלישית שאמרתם “Jamba” . . . (רן) . . . עכשיו צריך להסביר . . . . כן, אז מה זה Jamba? אולי אפשר גם להתחיל היסטורית מה זה Mamba,  “האימא שלו” . . . [לא קובי?]

• (חופית) נכון, אז בטרנספורמרים קצת נגענו - ואולי ניכנס קצת לטרנספורמר לפני שאנחנו בכלל מדברים על Jamba, על בעצם למה מגיעה המוטיבציה לדבר הזה, לשילוב ארכיטקטורות.
• אז ה-Core העיקרי, הדבר העיקרי, “הבלוק העיקרי” בטרנספורמרים בעצם, שהביא את כל החידוש, זה בלוק שנקרא Self Attention.
• שזו בעצם איזושהי מטריצה, שמתארת אינטראקציות בין כל Input - לעצמו.
• זאת אומרת שכל Token - יש לו איזושהי . . . .
• ובעצם זו מכפלה-וקטורית שקורית בסוף - אבל זה איזשהו Score או . . . בעצם, כמה יש לי אינטראקציה עם ה-Token שהיה לפני בסדרה.
• זאת אומרת, לכל ה-Token-ים, לאורך כל ה-Context.
• אז בהינתן סדרה - יש את החישוב הזה שקורה, ואפשר לקרוא לו . . .

(רן) . . . סליחה, אני אתן דוגמא -   . . . 

• (חופית) כן, מעולה

(רן) . . .   - “איש עומד ליד עץ - האם הוא יפה?”. “הוא” - מתייחס לאיש או מתייחס לעץ? המילה “הוא”. אני אגיד שוב את המשפט - “איש עומד ליד עץ, האם הוא יפה?”. זה דו-משמעי, נכון? האם המילה “הוא” מתייחסת לעץ או מתייחסת לאיש, שעומד לידו? אנחנו לא יודעים. המטרה של ה-Self-Attention היא למעשה למקד את ה-Attention של המילים האחרות אל הסובייקט, אל החלק במשפט, אל ה-Token במשפט שהוא למעשה הנושא שלשאליו מתייחסים - וזה משהו שהיה מאוד מאוד קשה לעשות לפני הטרנספורמרים, ובאמת מה שחופית מסבירה זהשהטרנספורמרים בעצם נותנים לנו כלי-מתמטי לעשות את זה, וזו החדשנות האמיתית.

• (חופית) נכון, זו אחלה דוגמה. למשל, אם נסתכל על מטריצה אחרת או על מודל שאומן כבר, אנחנו אכן נראה שכנראה “הוא” מתייחס . . .  
• אנחנו נראה Score יחסית גבוה של “הוא” ו”עץ” ושל “הוא” ו-”האיש”
• זה למשל מה שרואים בסוף המטריצה הזאת אחרי שהיא מאומנת.
• אחרי שכל הפרמטרים כבר מאומנים, נעשה את ה-Self-Attention וזה מה שנראה.
• אז מה שקורה בעצם זה שיש לנו את המטריצה הזאת בכל Block Attention . . . 

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

• (חופית) אבל כמו שאמרנו - זו בעצם מטריצה שהיא אורך ה-Input על אורך ה-Input
• כי כל Token - יש לו אינטראקציות עם כל שאר ה-Token-ים, זה ממש מחושב, כל ה-Score הזה, הממוצע המשוקלל הזה.
• וכשאנחנו מגיעים כבר לסדרות באורך 256K Token-ים למשל, שעל אורך הסדרה הזאת אימנו את Jamba בין היתר, אז אנחנו מדברים על חישוב שהוא כבר ריבועי באורך ה-Context, באורך הסדרה.
• ואם ניכנס לזה אפילו יותר ונדבר על זה שבזמן, ב-Inference Time, זאת אומרת שעושים Decoding, כשאנחנו מייצרים בכל פעם את ה-Token הבא, אנחנו שומרים איזשהו . . . 
• זה נקרא KV-Cache - ל-Token-ים  הקודמים שהיו.
• כי אתה לא רוצה לחשב על כל פעם מחדש - זה מאוד מאט לך את האימון.
• אבל אז השמירה של של הוקטורים האלה, כשיש לנו קונטקסט מאוד מאוד ארוך, ולכל אחד ממנו בעצם יש וקטור כזה . . . 
• בכל Block-Attention, לאורך כל הטרנספורמר - זה בעצם כבר תופס המון המון זיכרון.
• אז זה לא רק עניין של Latency - שאנחנו בעצם מחשבים הכל וזה מאט אותנו - זה גם עניין של זה שזה תופס הרבה זיכרון.

(רן) וגם חשוב להגיד - זה לא רק פוגע באימון. אז נניח יש כאן “טונה כסף” באימון, אבל הצלחנו לאמן. אבל זה גם פוגע ב-Inference. זאת אומרת, כשרוצים להשתמש במודל, אז אני גם צריך “טונה של זיכרון ב-GPU” - וזה יקר . . . .(אורי) כדי לסרוק את כל המטריצה הזו . . . (רן) כן, כדי להחזיק את זה . . . . עכשיו, אם מדובר על משפט פשוט בן עשר מילים, אז אוקיי - אז מאה, עשר בריבוע זה מאה, סבבה. אבל כשאנחנו מדברים על Context מאוד ארוך, כמו נגיד ספר או סרט, אז מספר ה-Token-ים הוא ענק, מגיע למאות אלפים, כמו שאמרת 256K . . . 

• (חופית) נכון מאוד, ואם כבר מדברים על ספר או סרט - אז למה בכלל מעניין אותנו ספר או סרט? 
• אז לאחרונה, אנחנו בעצם מחפשים כל פעם להתאים את עצמנו לדברים החדשנים - כרגע - בתעשייה.
• ו-Retrieval למשל זה אחד הדברים היותר מדוברים כרגע.
• שמה זה אומר? זה אומר שכשאני מבקש איזשהו Output מהמודל שפה, יש לי Instruction שאני נותן לו - ואני לאו-דווקא רוצה שהוא יתבסס על הידע שלו.
• זאת אומרת, אני לא רוצה שהוא ייתן לי “בשלוף” פשוט פרדיקציה (Prediction) של המודל.
• הייתי רוצה שלפני זה, יהיה איזשהו שלב מקדים - של כלי, שמביא בעצם כל מיני מסמכים שמתאימים לשאילתה שלך, מסמכים שמגיעים ממקור שהוא אמין ובטוח.
• ועל בסיס זה . . .  זאת אומרת, המודל יראה את כל המסמכים האלה כ-Prompt, והוא יג'נרט (Generate) לך תשובה בהתאם למסמכים האלה.
• אז כשאנחנו כבר מגיעים ונכנסים לעולמות ה-Retrieval האלה, שאנחנו מגיעים ל-Context-ים שהם מאוד מאוד ארוכים.
• אתה יכול לקבל מסמכים, שאולי לא כל המסמך קשור, אבל חלקים בו קשורים אז אתה כן מקבל את כולו.
• המודל בעצמו יודע לעשות האדפטציות (Adaptations) המתאימות - אבל בסוף, ה-Context הופך להיות מאוד ארוך. 

(רן) בואי ניתן דוגמא - נגיד, רופא בבית חולים שרוצה להתייעץ עם מנוע-שפה: “מה הבעיה של איציק?”. אוקיי, הגיע חולה, קוראים לו איציק, והוא רוצה לשאול אותו מה הבעיה שלו [הוא חושב שהעולם יפה?]. אוקיי, נניח שהוא אומר שיש לו תסמינים, לא יודע - חום גבוה, דופק וכו’. אבל מה המנוע-שפה לא יודע? את כל ההיסטוריה הרפואית של איציק, נכון [שלא לדבר על תל אביב ב-80s]? ובלי להבין את ההיסטוריה הרפואית של איציק, אי אפשר או שקשה מאוד לתת פרוגנוזה או דיאגנוזה או איך שקוראים לזה. אבל אנחנו יכולים לעזור לו - אנחנו יכולים לשלוף מתוך ה-Database את ההיסטוריה הרפואית ולבוא ולהגיד לו ב-Prompt “הנה ההיסטוריה הרפואית של איציק”, וזה יכול להיות ספר, זאת אומרת שזה יכול להיות הרבה הרבה דברים. “בהינתן זה, עכשיו תגיד מה הבעיה של איציק”, בהינתן שיש לו לחץ דם ודופק גבוה. זה משהו שאפשר לעשות רק עם Context מאוד ארוך, נכון? כי צריך לספק אתכל ההיסטוריה הרפואית. אז זה Use Case אחד. 

• (חופית) נכון - ויש גם את עולמות הקוד, שניהיו נורא מבוקשים, שאנחנו מדברים ב-Repo-ים שלמים, שהמודל יכול להחזיק בעצם ב-Context שלו.
• ויש את עולמות ה-Chat - שאתה בעצם מתחיל Chat עם איזשהו מודל-שפה כזה או אחר, השיחה מאוד מאוד מתנפחת, אתה מקבל סוג של Out of Context - “אין לי Token-ים יותר! בוא נתחיל שיחה חדשה . . . “.
• אז בעצם אנחנו רוצים להיתגבר על הקשיים האלה באמצעות אימון מודלי-שפה ל-Context-ים ארוכים.

(רן) אז זו המוטיבציה, ואם עד עכשיו דרך אגב, מי שכן משחק עם אימון שפה והרבה פעמים מוגבל באורח ה-Context,אז החדשנות פה היא שעכשיו ה-Context הולך להיות הרבה הרבה הרבה יותר ארוך. וראינו גם עבודות מחברות אחרות על Context-ים ארוכים, ואני מניח שגם הם משתמשים בדברים כאלה. אוקיי.
16:28 איך פותרים את בעיית ה-Context?(רן) אז איך פותרים את בעת ה-Context? אמרנו שבטרנספורמרים, צרכי הזיכרון גדלים ריבועית כגודל ה-Input, וזו בעיה . . .  אז איך כן פותרים את זה?

• (חופית) אז זה גם זיכרון וגם בעצם ה-Latency עצמו - המהירות שבה אנחנומחשבים את המטריצה הזאת, לאורך כל הטרנספורמר.
• אז בעצם, לאחרונה יצאו כל מיני מודלים שהם לא מבוססים Self-Attention, מודלי-שפה שהם מבוססי State-ים
• כמו ה-RNN-ים שאנחנו מכירים - זאת אומרת ש-Token נכנס, יש לנו איזושהי הכפלה במטריצה שקורית, ויש לנו State שמתעדכן בכל פעם שה-Token הבא נכנס.

(רן) כלומר, “מה קראתי עד עכשיו במשפט?” - זה ה-State.

• (חופית) נכון, “מה קראתי עד עכשיו במשפט”, בדיוק.
• אבל ה-State הזה מתעדכן כל פעם - זאת אומרת, ה-Token לא יוצר איזושהי אינטראקציה עם כל ה-Token-ים שהיו עד עכשיו. אלא רק עם ה-State, כפי שהוא עודכן עד עכשיו.

(אורי) אבל ה-State הוא בעצם ה-State של המטריצה - מעובד בצורה כלשהי . . . המטריציה שהייתה עד עכשיו.

• (חופית) נכון - אבל הוא כבר ראה המון Token-ים עד עכשיו . . . 

(רן)  זה איזשהו “סיכום”, סיכום-ביניים - “הנה זה מה שקראתי עד עכשיו”.(אורי) . . . איזשהו Inference מסוים של מה היה עד עכשיו. 

• (חופית) כן, נכון. 

(רן) . . . . ואז האינטראקציה היא Order of 1, פחות או יותר, אם אני מבין אותך. או קרוב לזה . . .

• (חופית) כן, אפשר להגיד. אם מסתכלים על זה בהשוואה ל-Attention אז אפשר להגיד.

(רן) כן, אבל רגע - אבל זאת לא בדיוק הבעיה ש-RNN נתקלו בה? זאת אומרת, גם ה-RNN-ים ניסו לסכם איזשהו  State, והם עשו את זה ביעילות אבל לא באפקטיביות אם נקרא לזה . . .  זאת אומרת, הם “לא סיכמו את זה טוב”.אז איך המודלים החדשים  . . . .?

• (חופית) נכון. אז הם לא סיכמו את זה טוב, היו כל מיני בעיות כאלה ואחרות.
• מה שקרה זה שבעצם ב-RNN זה שמהר מאוד אתה “שכחת את ה-Token-ים הראשונים שלך”, וזאת הייתה אחת הבעיות.

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

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

(רן) כן - “ספר”. ו-Mamba פותר את זה? איך?

• (חופית) אז ה-Mamba  . . . . בעצם, יש כל מיני דברים, יש כל מיני שיטות לאתחל את המטריצה הזאת, שבעצם על בסיסה אנחנו כל פעם מעדכנים את ה-State.
• את ה-State הזה, שאחר כך רץ בין כל Token-ים.
• אז יש כל מיני שיטות כאלה ואחרות - יותר שיטות מתמטיות, שבעצם עוזרות יותר לתת משקלים גם ל-Token-ים שהיו בעבר.
• שיהיה להם יותר משקל, שאתה לא “שוכח” אותם, אתה כן נותן להם יותר משקל.
• וזה לא רק זה - ה-Mamba, בעצם החידוש שלהם היה גם שאומנם המטריצה הזאת, שמעדכנת את ה-State, היא מטריצה אחת ויחידה, אבל יש עוד כל מיני מטריצות שנכנסות לתהליך.
• ששם, לכל מטריצה, לכל Token, היתה מטריצה משלו.
• זאת אומרת, המימדים שלנו הם כבר לא היו על מימד אחד, אלא כן על מימד אורך הסדרה.
• אז אתה אומר לעצמך “רגע, אבל שוב אני מגיע למצב ש...”

(רן) “שאני מרגיש מרומה קצת . . . .”

• (חופית) נכון . . .  אז איך אני עושה את זה, אם שוב יש לי משהו שתלוי באורך הסדרה? אז מה קורה פה?
• אז בעצם, Mamba - הגישה החדשנית שלהם הייתה ש”אנחנו עושים את זה בצורה יעילה”, וזה נכנס לרמת החומרה (Hardware) אפילו .
• הם ייעלו את זה ברמת ה-Copy מרכיב זיכרון אחד לרכיב זיכרון אחר ב-GPU, הרכיב הרחוק יותר והקרוב יותר.
• “איך אני מצמצם כמה שיותר את ה-Copy האלה, את העתקות משני הרכיבים וכו’.
• אני לא אכנס לזה יותר מדי . . . 

(רן) אוקיי, כלומר - דרישות-הזיכרון נשארו בערך אותו דבר, אבל ה-Latency פחת? או שגם דרישות-הזיכרון . . . .

• (חופית) יש יותר דרישות-זיכרון. לא כמו דרישות . . . . בסוף זה כן - ה-State בסוף כן נשאר ומתעדכן, ה-State עצמו כן מתעדכן ע”י מטריצה יחידה.
• אבל דרישות-הזיכרון הן הרבה פחות מטרנספורמרים, כמובן.
• הן כן יותר מ-RNN-ים - אבל שוב, הכל עניין של Tradeoffs, כי Mamba מאוד משמר את ה-Token-ים הראשונים האלה.

(רן) כן אוקיי - זאת אומרת, זה איזשהו Sweet-Spot בין ה-RNN-ים, שהיו “שוכחים” הרבה, לבין הטרנספורמרים  - שהיו זוכרים “הכל”, אבל גם היו מאוד “בזבזנים” מבחינת זיכרון וגם, כמו שאמרת, מבחינת Latency.

• (חופית) נכון - ואנחנו חשבנו מאוד לאפטם (Optimize) את ה-Inference בעיקר, אפילו יותר מאשר את האימון.
• כי בסוף, הלקוח זה מה ש...

21:14 מ-Mamba ל-Jamba ו-Mixture of Experts(רן) אוקיי. עכשיו: Mamba זה איזושהי שיטה וזה משהו שהוא ככה, Widespread - ואתם לקחתם ובניתם מודליםמשלכם, שקראתם להם Jamba. אז מה קורה שם?

• (חופית) נכון. אז קודם כל, אם נסתכל באופן כללי על טרנספורמרים, מודלי שפה, או שנקרא לזה Deep Neural Network - זה בעצם המון המון בלוקים שמקונקטים (Concatenate) אחד אחר השני.
• כל בלוק הזה - יש לו Input שהוא באורך הסדרה, ו-Output שהוא באורך הסדרה.
• אז אם נסתכל על כל בלוק הזה בנפרד, נגיד לעצמנו “זה לא מדע נורא נורא קשה או מאתגר”, לחבר את הדברים האלה
• כי זה כל היופי בבלוקים האלה - גם של ה-Self-Attention וגם של ה-Mamba
• ומזה אתה בעצם יכול לבנות רשת עמוקה.
• אז קודם כל, יש לנו בעצם גם את ה-MLP, שזו השכבה הליניארית בעצם - שאנחנו מטילים למימד גבוה יותר, ואז  מחזירים למימד נמוך יותר, כדי תמיד להיות באותה מימד שאיתו נכנסת לרשת, לבלוק.
• אז זה בעצם מה שעשינו - שילבנו. 
• הגענו לאיזושהי נקודה, שהיא גם עם Latency יחסית טוב - כרגע פי שלוש ממודל Transformer-Only, Self-Attention-Only.
• (רן) . . . זאת אומרת פי-שלוש יותר מהיר . . .
• (חופית) . . . פי-שלוש יותר מהיר - על Long-Context, על קונטקסטים ארוכים.
• ומצד שני - לא איבדנו מה-Accurecy של המודל, מכמה הוא “טוב”, מכמה . . . .
• זאת אומרת - על המון Benchmark-ים מוכרים היום, ראית איך Mamba . . .
• כי  לפני זה, עשינו המון המון אבלציות (Ablation) עד שהגענו לדבר הזה, בכלל לשילוב הזה.
• חשבנו שאנחנו נוציא בהתחלה מודל שהוא רק Mamba ומודל שהוא רק טרנספורמר - ואז ראינו של-Mamba יש את הבעיות שלו
• שאני אתן לכם דוגמא - יש למשל את כל נושא ה-Few-Shots - זה כשאני אתן לך איזשהו From פורמט של Input ו-Output, אתן לך כמה דוגמאות, והייתי רוצה שבשאלה הבאה שלי, תוציא לי את אותו Format, אוקיי? למשל...
• (רן) נגיד, אם אתה זוכר ממבחן פסיכומטרי - אנולוגיות: “בית לדלת, זה כמו מטבח למקרר”, זה כמו... “עכשיו, תן לי עוד אחד!”
• (חופית) נכון. אז אנלוגיות זה עוד משהו קשה - אני אלך אפילו למשהו קל יותר, אני אלך לביקורות.
• ביקורות הכי בסיסיות - על הסרטים, של Negative ו-Positive
• אז נתת לו כמה דוגמאות, ואמרת לו “תן לי עכשיו ביקורת על הדוגמא החדשה הזאת”
• ובמקום להשתמש ב-Positive או Negative, שממש-ממש חשוב לך שזה יהיה מדויק ל-Input של ה-User שלך, הוא יכול להגיד לך “Nice”, או “Bad”, או להשתמש לאו דווקא ב...
• (רן) כן, זאת אומרת - להגיד לו “הנה, תענה בסגנון של שלושת הדוגמאות הבאות” - ומעכשיו הוא עונה בסגנון של שלושת הדוגמאות שנתתי לו.
• (חופית) נכון - אז את זה הוא לא עשה, הוא לא השתמש בדיוק באותו פורמט, וזה מאוד מזכיר State
• כי State בעצם שומר באיזשהו מקום את “המהות” של המילה - לאו דווקא את המילה עצמה.
• זאת אומרת, את המשמעות שלה, או מה היא אומרת.
• אז זו הבעיה שנתקלנו בה, וזה אכן . . .  כל הבנצ'מרקים (Benchmarks) שהיו מבוססים למשל, על Few-Shot, או בכלל על פורמטים מסוימים של איך שאלה ותשובה אמורות להיראות - שם Mamba היה נופל.
• ואז, פשוט אמרנו “אז בואו נשלב!”
• בסוף, Sequence to Sequence - נכנסת סדרה, יוצאת סדרה, של Token-ים.
• אז בעצם, שילבנו את שני הדברים האלה - ביחס שהוא יחסית כל . . . .
• שבע שכבות, שיש בהן בלוקים של Mamba, ואז עוד שכבה אחת של Attention
• כי כמו שאמרתי - ה-Attention היה מאוד “מעיק”, מבחינת זיכרון ו-Inference Time, ב-Long Context, שהיה חשוב לנו מאוד מאוד לאפטם (Optimize).

(רן) זאת אומרת, אם מנועי-שפה, מתקופת BERT ועד פחות או יותר מלפני שנה, השתמשו בהרבה בלוקים של טרנספורמרים, את אומרת שהגיע המאמר של Mamba ואמר “בואו, את כל הטרנספורמרים תחליפו בבלוקים של Mamba” - ואז אתם באים ואומרים “אוקיי, נחליף כמעט את כולם, אבל נשאיר כמה טרנספורמרים”, והם עושים את העבודה, הם בעצם נותנים תוצאות יותר טובות.

• (חופית) נכון, כן, בדיוק.
• כן יצא לנו לעשות . . . בעצם, המאמרים שיצאו על Mamba, זה היה על מודלים מאוד מאוד קטנים, כל הניסויים.
• על מודלי מיליארד אחד, אפילו שבעה מיליארד.
• ואנחנו נכנסנו כבר לעולמות של  . . . . אמנם, זה ה-Jamba ששחררנו היה מודל של 12 מיליארד Active Params, שתכף אני אסביר מה זה.
• אבל כל המודל היה 50 מיליארד פרמטרים - שזה המון.
• והתחלנו גם לאפטם (Optimize) את הדברים ב-Mamba עצמו
• ראינו שהאקטיבציות (Activations), למשל - שהגדלים של הוקטורים שהוצאנו ב-Mamba ממש “מתפוצצים”, נהיים עצומים. 
• אתה צריך להוסיף Layer Normalization, אתה צריך כן להיכנס קצת לדברים שהם יותר “פנימה”
• זה לא איזשהו משהו סגור לחלוטין, שאתה לא נוגע בו.
• אז כן היה את האתגרים שם, שזה אתגרים באופן כללי של מודלים גדולים, כשאתה נחשף למודלים.
• זה היה, אני זוכרת כשעברתי מהתזה - פתאום בתזה, כשאתה מאמן מודלים קטנים, ללאמן מודלים גדולים
• אתה נחשף לאתגרים אחרים לגמרי . . . 

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

• (חופית) אני מסכימה . . . 

(אורי) . . . . העולם האמיתי הוא Outlier . . . . [באמפר סטיקר?]

• (חופית) נכון, אני גם חושבת שאני ממש רואה את זה ככה.
• אני הייתי חוקרת בתזה, והפכתי להיות  . . . . נקרא לזה מ-Deep Learning Researcher, ל-Deep Learning Engineer Researcher.
• כי פתאום, למקבל מודל . . . כי מודל גדול - אתה חייב למקבל אותו, הוא לא ייכנס לך.
• גם כשאתה מגיע לשכבה היחידה שאתה כרגע מתעסק בה באימון - היא לא תיכנס לך בזיכרון. זה לא יקרה.
• ואז יש כבר Model Parallelism - אתה מתחיל לחלק את ה-Tensor-ים של הפרמטרים שלך בין GPU-ים  שונים.
• זה פתאום להתעסק עם דברים שאתה לא... זה ממש מרגיש שלא נגעתי בהם לפני זה - וזה עולם ומלואו.
• וזה עולם שצריך לחקור בו. אז זה...

(אורי) בסוף, זה ה-Blocker-ים . . . . 

• (חופית) נכון ,זה ה-Blocker-ים  . . . . אלו בדיוק ה-Blocker-ים.

(אורי) אז רציתי לשאול כאילו... בין ה-Mamba ל-Jamba קצת התבלבלתי. הבנתי שהתוצאות ב-Jamba נהיות יותר טובות, שפתאום אנחנו מצליחים להכניס... אני לא יודע אם זה לא Context, אלא יותר...(רן) Inputs יותר?  . . . “מבין יותר טוב”?

• (חופית) הוא יותר “Context-aware”, בוא נקרא לזה.

(אורי) כן ... הוא “מקבל טון” בתוצאות שלו. אבל כשאת אומרת “בסדר, לקחנו כמה State-ים של ה-Jamba”,והוספנו כמה... סליחה, “ . . . כמה State-ים של ה-Mamba, והוספנו עוד כמה טרנספורמרים” - בסוף, מה קרה לזיכרון?

• (חופית) אז הזיכרון . . . אז אתה מוצא את ה-Tradeoff, אתה מוצא את ה-Tradeoff ביניהם.
• אז אתה לא תהיה עם הזיכרון הכי מינימלי שתקבל רק עם Mamba-only, אבל אתה כן חסכת המון.
• אני יכולה להגיד לך שלפחות ב... אני אתן לך דוגמא: 
• ב-Inference time של 256 - של Context באורך של 256K, אם ניקח מודל שהוא זהה ל-Jamba שהוצאנו, אבל Transformer-only, ה-KV Cache שלו יהיה בגודל של 32GB, על ה-Context הזה של 256K,
• ואם זה יהיה... וה-Jamba שלנו מגיעה ל-8GB - אז חסכנו פה לא מעט...

(אורי) אז בכל מקרה זה חיסכון . . . .(רן) עכשיו, שימו לב - זה לא Disc-Space - כי Disc-Space לא חסר. מדובר פה על זיכרון ב-GPU, וזה מאוד מאוד  יקר. אוקיי? תסתכלו בטבלה של מחירים של AWS ותבינו מה המחירים של הדברים האלה. זה לא משחק ילדים - לחסוך כל כך הרבה GB של זיכרון זה מאוד מאוד משמעותי. זה יכול להיות הבדל בין “יש לנו עסק” או “אין לנו עסק”.

• (חופית) נכון - וגם אנחנו חושבים על זה, כשאנחנו מוציאים אותו לקהילה.
• בין אם זה שהם ימשיכו לעשות Fine-tuning למודל, בין אם זה “שישחקו איתו” ויעשו איתו דברים.
• לרוב יש לאנשים GPU אחד - זה לא ה-Resource-ים שיש לנו, שאנחנו מחזיקים בחברה.
• זה גם כמובן נלקח בחשבון.
• ול-Jamba שלנו גם הוספנו MOE - שזה נקרא Mixture of Experts, שזה גם מושג לאחרונה ששומעים אותו הרבה.
• שזה בעצם מה שרציתי להגיד לגבי ה-Active Params שאמרתי מקודם, וכמות הפרמטרים “האמיתית” של המודל.
• אז מה שקורה זה שכל שכבה שנייה . . . . Mixture of Experts זה לא משהו שאנחנו המצאנו, זה משהו שהגיע מבחוץ.
• אנחנו פשוט שילבנו את זה כחלק מה-Jamba, בצורה שהייתה נראית לנו נכונה, טובה, והכי יעילה לדברים שאנחנו רצינו להשיג.
• בכללי, מה הרעיון אומר? הרעיון אומר שאם יש לנו את השכבה הליניארית שבה אנחנו עושים הטלה שנמצאת בין כל הבלוקים של ה-Mamba וה-Attention.
• בין כל בלוק כזה, יש בעצם שכבה שנקראת MLP, שזו שכבה ליניארית שרובנו מכירים - היא עוד “מהרשתות הקלאסיות” . . . 

(רן) אם אי פעם ראיתם רשת ניורונים - זה זה . . . “עיגולים מחוברים בקווים, שמחוברים לעיגולים בשכבה הבאה” - זהמה שנקרא MLP. 

• (חופית) נכון, זה ה-MLP.
• אז בגדול, לנו, עד עכשיו כל המודלים הרווחים שהיו בחוץ היו בעצם שכבת MLP אחת בין כל Attention, בין כל

בלוק Attention.

• וה-Mixture of Experts בא ואומר שאנחנו יכולים בעצם להחזיק, למשל, בשכבה אחת, במקום להחזיק שכבת MLP אחת כזאת, אנחנו נחזיק - אנחנו, לפחות במודל של Jamba, שמנו 16 בלוקים כאלה, של MLP.
• ולפי ה-Token שמגיע - מגיעה הסדרה של Token-ים, ולכל Token יש איזשהו Router, 
• כשה-Router מחליט - זה Router נלמד כמובן, כמו כל הפרמטרים - שהוא מחליט לאיזה Expert ה-Token הזה מתאים.
• ואז אתה לא מנצל את כל ה-Expert-ים, זאת אומרת - ה-Active Params שלך, הפרמטרים שכרגע אתה משתמש בהם, הם של Expert אחד.
• כי אתה מחליט שה-Token הזה הולך ל-Expert הזה.
• אבל כל ה-Expert-ים האלה נלמדים במהלך האימון - כי כל Token ילך ל-Expert שונה.

(רן) אני אנסה רגע להסביר את זה בדרכי שלי, “הציורית” - נניח שאתם יודעים לדבר חמש שפות, ועכשיו אתם שומעים משהו בצרפתית, אז זה הולך לאיזור אחד במוח. אתם שומעים אחר כך משהו בערבית, אז זה הולך לאזור אחר של  המוח. אבל אתם אף פעם לא משתמשים בו-זמנית, בכל חמשת השפות, או שסביר להניח שלא תשתמשו בו-זמנית - ולכן חלק מהמוח שלכם כל הזמן ”במנוחה". אוקיי, אז Mixture of Experts הוא למעשה “ה-Router” שמחליט “אה, זה צרפתית! זה הולך לאזור הזה של המוח, ולכן כל השאר יכול לנוח”.איך מרוויחים מזה, בחומרה? מה זה עוזר לנו בעצם? אז למעשה, אנחנו לא צריכים להשתמש בו זמנית בכל הפרמטרים, שזה אומר אפשר לחסוך - תקני אותי אם אני טועה - אפשר לחסוך בזיכרון, אפשר לחסוך ב-Cycle-ים של GPU בזמן ה-Inference - ולמעשה, המודל, פוטנציאלית, הוא אולי 50 מיליארד פרמטרים, אבל למעשה, אני יכול להתייחס אליו, מבחינת “המשקל שלו”, כ-12 מיליארד פרמטרים.(אורי) בהנחה שאנחנו "נפספס” איזה משהו - שתלוי “בחוכמה” של ה-Router. (רן) אם ה-Router טועה, אז כן - “אכלנו אותה” . . . 

• (חופית) אז ה-Router - הוא נלמד לאורך המון המון צעדים, אז הוא לרוב לא טועה, הוא אכן מגיע למקומות שאכן צריך להגיע אליהם. 
• אני כן אדייק פה לגבי זיכרון - כל המודל יושב בזיכרון, כל ה-50 מיליארד פרמטרים, זה אומר שחיסכון בזיכרון אין.
• אבל מבחינת Latency, כמות ה-FLOP-ים והאופרציות שה-Token הזה יעבור לאורך הרשת, תהיה כמו מודל בגודל 12B, ולא כמו מודל בגודל 50B, 50 מיליארד.

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

• (חופית) כן.

(רן) אז ה-Mixture of Experts למעשה נמצא בין כל אחת מהשכבות שלכם?

• (חופית) אז בין כל שכבה שנייה. לא כל שכבה, אלא בכל שכבה שנייה שמנו אותו. 
• שוב, זה עניין של . . .  בסוף אנחנו מחזיקים המון המון גם בזיכרון, והמטרה הייתה לאפטם (To Optimize).
• המטרה ספציפית ב-Jamba הייתה לאפטם את זה שאנחנו יכולים להחזיק בזיכרון את כל המודל שלנו על GPU אחד, עד Context של 128K.
• אם היו לנו עד 256K, הוא דורש כבר יותר מ-GPU אחד, של 80GB.

(רן) כן. זיכרון . . . והגדלים באים בדרך כלל באופן סטנדרטי, ככה שיש את “המשבצת הנכונה” ל-80GB.
34:38 תרומה לקהילה(רן) הזכרת מקודם תרומה לקהילה, ואת זה שאתם רוצים שכל אחד בקהילה יוכל לריץ את המודל. אז מה זה אומר? המודל הזה הוא פתוח?

• (חופית) אז הוא Open Source -  הוא פתוח ב-Hugging Face, כן.
• אנשים יכולים לגשת לשחק איתו, להמשיך לאמן אותו גם.
• ממש “להיכנס לנבכי הארכיטקטורה” שלו.
• ובאמת שכל אחד מוזמן - זה רק יעזור לנו לקבל פידבקים.

(רן) אז כן, אז זה לידיעה כללית - יש לא מעט חברות שלהן יש מודלים חזקים ומאוד Capable, אבל מודלים סגורים. OpenAI אולי הידועה מבין כולם - אבל יש גם אחרות. ויש גם כאלה שמשחררות את המודלים שלהן בקוד פתוח או בקונפיגורציות שונות של Open Weights וכו'.אתם שיחרתם את Jamba, את הגרסה של - זה נקראת בעצם 50B או איך זה נקרא?

• (חופית) אז זה נקרא, זה 712B אפשר להגיד . . .  למה עברנו מ-7B? מה שעשינו, MOE, מה שהחלטנו לעשות ועוד כמה חברות עשו את זה כמובן, זה להחליט לא לקחת Expert אחד אלא לקחת שני Expert-ים לכל Token.
• להוסיף לו עוד אקספרסיביות (Expressiveness), עוד רמה של אקספרסיביות בעצם.
• מה שהפך את המודל בעצם להיות מאיזה 7-8B פרמטרים, Active Params - ל-12 מיליארד Active Params.

(רן) כן, אז 7 כפול 12, זו התוצאה?

• (חופית) כן. זה 12 מיליארד פרמטרים - ו-50 מיליארד פרמטרים בסך הכל.

(רן) אוקיי, ואפשר לקחת - בהינתן GPU מספיק גדול, וכאלה כן קיימים, כלומר כן אפשר לשלם עליהם ולקבל אותם - ואפשר לרוץ ולהשתמש במודל. אם אורך Context מאוד מאוד ארוך חשוב -  אם זה לשיחת -Chat פשוטה, אתם לא צריכים את ה-Context הזה, אבל אם זה “תקרא את כל הקוד שלי ותגיד לי איזו פונקציה אני צריך לכתוב” או “תציע לי Completion לפונקציה” או אם זה “תקרא את כל ההיסטוריה הרפואית ותן לי אנליזה” או “תראה את הסרט הזה” -  לא דיברנו כל כך על Medim-ים אחרים, אבל גם זה משהו שעובד - אז זה יכול בהחלט לעבוד עם מודל שכזה.דרך אגב - יש מודלים אחרים ששיחררתם  בקוד פתוח?

• (חופית) שיחררנו את זה ואת ה-Instruct שלו.
• אבל עוד לא - יש מודלים גדולים שמתבשלים בדרך, כן. “גדולים באמת”.

(אורי) אני גם שנייה שנייה חופר ב-GPU שלי - במבצע סבתא יש בחמישה Token-ים פחות מ-128K . . . (רן) יפה, אז אפשר אפשר להשלים את הסרט.(אורי) כן, לא כולל מוטי בננה.

• (חופית) באמת?
• (אורי) לא.

37:18 כתוביות(רן) טוב, וואו, מרתק. טוב, אני מקווה ש... כן אמרת בדרך אבלציות (Ablation) ורציתי להיכנס לשם, אבל מספיק עד כאן.אז היה מרתק, תודה רבה!

• (חופית) תודה רבה לכם - היה ממש מעניין, ומקווה שזה יפתח לאנשים את הראש.

(אורי) יפתח לאנשים את המודל . . . (רן) . . . . מוזמנים להיכנס ל-Hugging Face, להוריד משם - ולהתנסות. האזנה נעימה ותודה רבה לעופר פורר על התמלול!