יום ראשון, 18 במאי 2025

495 ML Democratization, Yuval from Voyantis

פרק מספר 495 של רברס עם פלטפורמה, שהוקלט ב-14 במאי 2025 - אורי ורן מארחים את יובל מחברת Voyantis כדי לדבר על איך עושים דמוקרטיה ב-Machine Learning. 🎗️


00:27 יובל ו-Voyantis

(רן)  קצת לפני זה - יובל: קצת עליך, קצת על החברה, לפני שנצלול פנימה.
  • (יובל) אז אני יובל - אני בן 29, נשוי לנועה, שאני מאוד מאוד אוהב, ובעצם בתחום הפיתוח כבר בקרוב ל-10 שנים האחרונות. 
  • ובתפקיד האחרון שלי, הנוכחי שלי, אני בעצם ראש צוות ה-ML Engineering ב-Voyantis.
    • עכשיו בגדול, לפעמים קשה קצת להבין אולי מה זה ML Engineering. אני אוהב להסתכל על זה כבעצם “ה-Engineers שמביאים את Machine Learning ל-Production”.
    • זאת אומרת, הרבה פעמים Data Scientist-ים עושים . . .  מאמנים מודלים, בונים דברים מאוד מאוד מסובכים במחברות ובכל אמצעי שעומד לרשותם - ובעצם אנחנו מביאים את זה ל-Production, מביאים את זה לשטח.
(אורי)  ב-Scale, ב-Durability, ב . . .
    • (יובל) . . . שומרים על זה מכל משמר, כמו שמערכת Production צריכה להיות. 
(רן) כן, היום הגבולות כבר אולי מטושטשים, אבל לפחות פעם הייתה את הסטיגמה ש-Data Scientist כותב למחברת ו-ML Engineer כותב למחלקה, כותב Class-ים . . . אז כמובן שהיום כולם עושים הכל וזה הגבולות שמטושטשים, אבל בכל אופן יש איזשהו ערך להתמחות הזאת. 
(אורי) אולי נשמע קצת על מה עושה Voyantis בימים אלה? זה יוסיף לנו Context . . .
  • (יובל)  זה יוסיף לנו Context, זה חשוב מאוד - עושים דברים מעניינים.
  • אז Voyantis - מה שאנחנו עושים זה בעצם עוזרים לחברות להתמקד ביוזרים הכי רווחיים שלהם, בכל נקודה במה שנקרא “User Life Cycle”.
  • עכשיו, אולי מילה על ה-User Life Cycle - אנחנו בעצם נוטים לחלק את זה לארבע תחנות, של יוזר בעצם בחברה, באפליקציה, בעצם במוצר.
    • אז השלב הראשון זה שלב ה-User Acquisition, שזה בעצם השלב שבו יוזרים מגיעים מקמפיינים ממומנים - מ-Meta, מ-Google - ובעצם נכנסים למערכת.
    • השלב השני הוא בעצם שלב האקטיבציה (Activation), שבעצם זה השלב שבו יוזר הופך להיות יוזר שהוא משלם.
    • השלב השלישי זה בעצם שלב ה-Upsell, fשבעצם אנחנו רוצים להציע ליוזר עוד שירותים - ולגבות עליהם עוד קצת כסף . . . 
      • (רן) . . .  למקסם את ה-Revenue . . . 
      • (יובל) בדיוק.
    • והשלב הרביעי זה Retention - כשבעצם היוזר מחליט לעזוב. 
  • עכשיו, אנחנו בעצם בכל אחת מהתחנות האלה עוזרים לחברות להתמקד ביוזרים הכי טובים והכי רווחיים עבורן - ואנחנו עושים את זה על ידי שימוש בדאטה של החברות עצמן.
    • זאת אומרת, אנחנו בעצם שואבים מתוך החברות, מתוך ה-Database-ים של החברות, דאטה אנונימי על היוזרים שלהן. 
    • את הדאטה הזה אנחנו מכניסים לתוך מערכות של Voyantis, לומדים על הדאטה הזה ובונים מודלים - ובעזרת המודלים מייצרים פרדיקציות (Predictions), ובעזרת הפרדיקציות האלה אנחנו עושים, אנחנו פועלים.
(רן) אז הקטגוריה אני מניח מוכרת, יש לא מעט חברות בתחום. אחת הבולטות זו Google , נגיד עם Google Analytics - מוצר מאוד מאוד ותיק, לא מתמחה באף אחד מהתחומים אבל הוא כן מוכר. Mixpanel . . . יש חברה שבה אני עבדתי, AppsFlyer, שהיא בתחום הזה ויש לא מעט אחרות.
אבל אתה אומר שבעצם הגישה שלכם, אולי בשונה מכל האחרות שהזכרתי עד עכשיו, זה לא להתחבר ל-App ולא להתחבר ל-website אלא להתחבר ל-Backend, זאת אומרת להתחבר . . . אפילו לא זה - אפילו ל-Database-ים, ולשאוב משם את האינפורמציה. ואחד האתגרים שקיימים שם זה שלכל חברה יש דאטה אחר, בסכימה (Scheme) אחרת, בסמנטיקה שונה . . . איך מפיקים מזה תובנות? על זה אנחנו בעצם נדבר היום.
  • (יובל) נכון. אז כמו שאתה אומר - זה באמת תחום שהוא סופר-קשה, ובאמת אנחנו החלטנו ככה “להיכנס לתוך השוחות” ולתאקל את הדבר הזה.
  • ואיך שאנחנו עושים את זה, זה בגדול על ידי צוותי Business שבעצם אחראים על לקוח.
  • זאת אומרת, מגיע איזשהו לקוח שרוצה לקבל את השירותים של Voyantis, אז יש צוותי Business, שזה בין היתר CSM למיניהם ובנוסף גם Data Analyst ו Data Scientist.
    • ובעזרת כל הצוותים האלה אנחנו בעצם מתחילים “להביא את הדאטה הביתה” - לעשות איתו עיבודים, להתחיל לייצר פרדיקציות ולהתחיל בעצם לפעול.
(רן) כן, אז מין סוג של Concierge - מגיע לקוח ומטפלים בו יפה יפה עד שהדאטה שלו מיושר ומהודק, וזה נשמע כמו הרבה עבודה . . .  זאת אומרת, אנחנו רוצים לראות שה-Unit Economy הוא רווחי, וזה אני מניח שאחד האתגרים. אז אם הייתם משתמשים ב-Google Analytics ו-Google פשוט אומרת לכם “פשוט תשים את ה-Script הזה באתר שלכם, אנחנו ניקח את זה מפה”, והם שמים, כנראה, אפס כוח אדם על הסיפור הזה, אז אצלכם יש לא מעט כוח אדם שצריך להתעסק ב-Onboarding של לקוח חדש -  ואני מניח שלא רק Onboarding. זאת אומרת, יש לו מוצרים חדשים, יש לו Usage Pattern משתנה . . . זאת אומרת, זו החזקת-ידיים שצריכה להימשך לכל אורך החיים של הלקוח.
  • (יובל) לגמרי. ובאמת, כל לקוח הוא באמת כל כך שונה מלקוח האחר שלצידו, וזה בעצם מה שהאתגר הגדול אצלנו
    • ואנחנו זיהינו באמת שהתהליך הזה לוקח המון המון זמן.
  • (יובל) אז עכשיו אולי רק מילה על תהליך ה-Onboarding בעצם של לקוח למערכת שלנו. אז בגדול, כל לקוח מתחיל בעצם באיזשהו תהליך של KYC, Know Your Customer, ששם אנחנו בעצם, צוותי ה-Business, שזה באופן ספציפי האנליסטים וה-CSM-ים - הם בעצם ככה לומדים את הלקוח, לומדים את הדאטה שלו, לומדים בעצם איך הדאטה . . . איך הוא נמצא בטבלאות, בכל טבלה, ובעצם מה יכולים למצוא שם.
(רן) כן -  ואני אזכיר שכל לקוח זה משהו אחר . . .  זאת אומרת, הם עושים מה שבא להם - אתם לא מכתיבים להם שום סכמה, שום דבר, כל לקוח . . . 
(אורי) זה לא רק שהסכמה שונה - ה-Business Logic הוא שונה . . . 
  • (יובל) וזה בעצם למה  . . . אני טיפה ארחיב על תפקיד האנליסט, כי אמרתי פה “אנליסט” ואני חושב שהרבה פעמים לאנשים יכולה לקפוץ איזושהי תמונה לראש . . . 
    • תפקיד האנליסט אצלנו הוא מורכב - הם צריכים להיות בעצם אנשים מאוד מאוד אנליטיים, ועם הבנה Business-ית מאוד גבוהה, כי בעצם בכל לקוח שמגיע הם צריכים להבין, בנוסף ללהבין את הדאטה שלו ואיפה הדאטה ממוקם, הם צריכים להבין מה ה-Pain-ים שלו, איך אנחנו הולכים להראות הלקוח הזה ערך, על פי מה שהלקוח הזה מודד אותנו . . . 
(רן) כן, למעשה אפשר לחשוב על האנליסטים שלכם כ”האנליסטים שלהם”, רק שאתם משלמים להם את המשכורת . . .
(אורי) זהו, כי מהיכרותי את העולם הזה של דאטה בחברה שהיא מורכבת, עם הרבה שנים, אתה יודע - עם Legacy, שלא משנה כמה אתה משדרג את ה-Backend ואת הסכמות ואת ה-Database-ים - המוצר, יש לו Legacy, ה-Business Logic - יש לו Legacy. ויש כמה מוצרים . . . בקיצור, זה מגיע הרבה פעמים למצב שאין בנאדם אחד או שניים בחברה עצמה, שהיא הלקוח שלך, שבאמת יודע מה עושה כל פיסת דאטה . . .
  • (יובל) זה באמת אחד האתגרים - שהרבה פעמים הלקוחות שמגיעים אלינו, ואנחנו שואלים אותם “אוקיי, אז איפה הדאטה הזה נמצא? ואיפה הדאטה של ה-Activity? איפה הדאטה של הטרנזקציות (Transactions)? איפה כל מיני דברים קורים?”.
    • והם לא כל כך בטוחים בעצמם . . . 
    • (רן) . . . “ לא יודע - אתה תגיד לי! בשביל מה הבאתי אותך?” . . . 
    • (יובל) בדיוק. כן, זה... 
    • (רן) האמת היא שאתה יודע, זאת אומרת, זה קורה הרבה. גם נגיד כשעבדתי ב-AppsFlyer, אנחנו חברה ש”החיים שלה זה דאטה”, ועדיין קשה מאוד לנו להכיר את הדאטה שלנו, כשהייתי שם. כן, אז מצד אחד זה נראה מגוחך, מצד שני ראיתי את זה קורה כל כך הרבה פעמים, שזה לא כזה מפתיע. 

09:27 תהליך ה-Onboarding ובניית המודל

(רן) אוקיי, אז האתגר שלכם זה שיש לכם לקוחות - לא בודדים, אני מניח שדי הרבה - ואתם רוצים לקבל עוד לקוחות, אבל כל אחד כזה דורש הרבה מאוד החזקת-ידיים. בכמה פחות או יותר מדובר? מה סדר הגודל של עבודה על Onboarding ללקוח חדש?
  • (יובל) במקרה-קיצון זה יכול להיות גם שבועות.
  • זה הרבה פעמים תלוי בעצם בסוג הלקוח - גם, כמו שדיברנו עכשיו, על איך הוא מכיר את הדאטה שלו בכלל.
  • בעצם, את תהליך ה-Onboarding גם אפשר לחלק לשני חלקים עיקריים - 
    • השלב הראשון - בעצם ההיכרות עם הדאטה עד השלב שבו אנחנו מנרמלים את הדאטה לתוך הסכמות המנורמלות אצלנו.
      • כי, זאת אומרת, כשאנחנו עובדים In House, בתוך החברה, אנחנו עובדים מול סכמה שבה כל הלקוחות סכמטית נראים אותו דבר.
      • אבל כמו שאמרת מקודם - סמנטית הם מאוד מאוד שונים. 
(רן) אז אתם מביאים . .  “שואבים” את הדאטה מהם, אבל מנרמלים אותו אצלכם לסכמה שנוחה לכם - אבל צריך לדעת לעשות את זה נכון? זאת אומרת, אחרת יצא לך Garbage In Garbage Out . . . 
  • (יובל) וזה בעצם למה התפקיד הזה כל כך מורכב. . .  אנחנו בעצם צריכים לוודא שאנחנו, שכל פיסת הדאטה מתנרמלת לאזור הנכון ו...
(רן) כן, אז אתה אומר זה סדר גודל של יכול להיות שבועות ולפחות בן אדם אחד שעובד על זה. אוקיי, אינטנסיבי . . .  בסדר. 
  • (יובל) אינטנסיבי - ורק דיברנו על הכנסת הדאטה לטבלאות המנורמלות. עוד לא דיברנו על המודל שעכשיו צריך להיבנות על גבי הדבר הזה.
  • אז בעצם, השלב השני מגיע כשמסתיימת נורמליזציה, אז מגיע Data Scientist שבעצם מקבל ככה hand over ללקוח הזה.
    • הוא מבין את ה-Pain-ים שלו, הוא מבין מה אנחנו בעצם רוצים לחזות.
    • ואז הוא בעצם בונה מעל הדבר הזה איזשהו קוד Python שעושה Feature Engineering וככה בונה לנו את הפיצ'רים, מאמן בעזרת הפיצ'רים האלה מודל, ומעלה את המודל הזה.
(רן) בואו נדבר על כמה Target-ים טיפוסיים שלקוחות בדרך כלל רוצים לחזות - נגיד, כמה זמן אותו משתמש יישאר, או כמה כסף הוא יוציא ב-30 יום הראשונים - על זה אנחנו מדברים?
  • (יובל) אנחנו מדברים בעיקר על פרדיקציות LTV, מה שנקרא.
  • זאת אומרת, אנחנו בעצם רוצים לחזות את ה-Lifetime Value של כל היוזרים לטווח רחוק . . . 
(רן) טווח של שנה, שנתיים? . . . 
  • (יובל) טיפה פחות - לפעמים 90 יום, 180 יום, זה מאוד משתנה בין לקוח ללקוח.
    • וגם לפעמים אנחנו לא רוצים באמת לחזות את ה-Lifetime value.
    • לפעמים אנחנו בעצם רוצים לחזות אולי כמות של טרנזקציות, אולי אנחנו רוצים לדעת לחזות בכלל האם לקוח יתקנוורט (Convert) בסוג מסוים של Use Cases.
(רן) כן, וזה כמובן ספציפי ללקוח - יש לקוחות שבהם רק כסף מעניין, יש לקוחות שבהם רק Engagement מעניין, ובהרבה מקרים זה איזשהו שילוב של כולם. 

12:20 איך משפרים תהליך Human Intensive

(רן) אוקיי, אז איך לוקחים תהליך שהוא כזה Human Intensive ומשפרים אותו? פה אתה נכנס לתמונה.
  • (יובל)  נכון. אז בעצם אנחנו הסתכלנו אחורה על הרבה תהליכי Onboarding שהיו לנו והבנו שהם יכולים להיות מאוד מאוד ארוכים - ושאנחנו רוצים לקצר אותם.
  • ואנחנו בחרנו להתמקד בעצם בשלב בניית המודל - כי בסופו של דבר אנחנו חושבים שהחזון של המוצר זה בסוף להיות חברת SaaS.
    • זאת אומרת, אנחנו לא רוצים . . . . כרגע, אנחנו כמו סוג קצת של Agency, ואנחנו רוצים להפוך להיות חברת SaaS.
    • אנחנו לא רוצים להיות בעצם במצב שכמות ה-Data Scientist-ים שלנו תהיה בעצם Bottleneck ל-Scaling, 
      • זאת אומרת, אנחנו לא רוצים שכמות הלקוחות שאנחנו נכניס לחברה תהיה מוגבלת על ידי מספר ה-Data Scientist-ים בחברה.
    • (אורי) . . . וגם שלא תהיה קורלציה בין שני המספרים האלה . . . 
    • (יובל) בדיוק, אנחנו לא רוצים את זה - אנחנו לא צריכים את זה ככה.
    • ויותר מזה - אנחנו רוצים לפנות את ה-Data Scientist-ים שיסתכלו קצת על דברים רחבים יותר, לאו דווקא על Feature Engineering קבוע.
  • ולכן החלטנו בעצם שגם ככה יש לנו אנליסטים מאוד חזקים וחריפים וחכמים - בוא ניתן להם את היכולת ואת הכלים להשפיע ישירות על הפיצ'רים ולהשפיע ישירות על איך שהמערכת שלנו בעצם מייצרת פרדיקציות.
(רן) כן, אוקיי - זאת אומרת: אני רוצה להיות מסוגל לשחרר אותם מהשלב הראשון, של להביא את הדאטה ולנרמל אותו, ולתת להם לעבוד יותר לשלב השני - ששם אתם רואים את הערך המוסף שלכם כחברה.
  • (יובל) לגמרי. 
(רן) אוקיי, אז יאללה - איך מהנדסים את זה? איך עושים את הסיפור הזה?
  • (יובל) אז זה היה סיפור מאוד מורכב, אבל בסופו של דבר אנחנו הבנו שאנחנו רוצים בעצם להעביר את התהליך, את כל התהליך, להיות SQL only.
  • כי בנוסף להיותם אנשים חכמים וחזקים - הם [האנליסטים] גם “דוברים SQL”.
    • הם מאוד חזקים באנליטיקות, הם יודעים . . .  בעצם, גם תהליך הנרמול של הדאטה, אנחנו עובדים עם דאטה טבלאי, אז הכל בעצם ב-SQL.
    • ואנחנו החלטנו שבעצם כל תהליך ה-Feature Engineering שלנו יהיה אוטומטי בעזרת SQL.
(רן)  זאת אומרת השלב של “הנרמול”, קראנו לו בהתחלה - זה ה-Feature Engineering?
  • (יובל) לא, השלב של הנרמול הוא נשאר כמו שהוא.
    • אנחנו, על גבי הנרמול, בעצם בונים איזשהו Feature Engineering, ועל הנרמול  . . . 
  • עכשיו, אנחנו בחזון שלנו - הנרמול הולך להכתיב לחלוטין את איך שהפיצ'רים בסופו של דבר הולכים להיראות.
(רן) כן, זאת אומרת מה שאמרת מקודם שזה ב-Python, אז עכשיו אנחנו מעבירים את זה ל-SQL - אבל על השלב הראשון עוד לא דיברנו, כלומר איך לוקחים את הדאטה של הלקוח ומנרמלים אותו לסכמה “שלנו”.
  • (יובל) אז זה כבר בעצם מוצר מוגמר אצלנו. זה בעצם תהליך שהוא כבר תהליך סדור, יש לנו מערכות פנימיות שהאנליסטים בעצם בונים ETL על גבי פלטפורמה שאנחנו נתנו להם, ובוא נגיד שזה כבר תהליך שהוא סדור.
  • עכשיו, האתגר האמיתי הוא איך בעצם לייתר את כל “הפיסות Python” והקוד Machine Learning ו-Data Science שיש לנו בעצם אחרי הטבלאות המנורמלות, ולהפוך את הכל לדבר באותה שפה.
(אורי) אבל תחשוב על זה - אתה מנסה להסתכל איפה יושבות העלויות הגבוהות? הן יושבות ב Data Scientists יותר מאשר ב-CSM-ים או אנליסטים. אז כאילו, תשבור קודם את היחידה הזאת, תשבור לה את הקורלציה לScale ו . . 
(רן)  כן. אוקיי, זאת אומרת, היה לכם שלב שבו לוקחים את הדאטה המנורמל ובונים ממנו פיצ'רים. עכשיו, אני מניח שיש פיצ'רים שמשותפים ללקוחות, בסדר? כן, זאת אומרת, לא כל אחד הוא Snowflake, אז זאת אומרת, אני מניח שיש פה איזשהו מקום ל-Reuse. אבל אתה אומר, אתם לא רוצים שזה יהיה Python-י - לפחות הממשק שאותו אתם חושפים לאנליסטים, שלא יהיה Python-י, שיהיה SQL-י - וזה משיקולי Skill, אני מניח, אוקיי?
ויחד עם זאת, יצא לי לעשות משהו כזה, ולהחליט שאנחנו עושים את זה דברים רק ב-SQL - וגם זה לא כל כך נעים . . . זאת אומרת, אתה רואה, יכול להיות שמישהו שמדמיין SQL, מדמיין איזושהי שורה פשוטה של Select * From, אבל SQL יכול להיות חיה אימתנית, שאותה רק אנליסטים מבינים, וגם פה יכולה להיווצר איזושהי בעיית תחזוקה ו-Scale, ואולי גם Performance, כי לא תמיד יש לך שליטה בדיוק איך ה-run time מבצע את ה-SQL שלך.
אז נגיד, איך אתם מתמודדים עם אתגרים כאלה?
  • (יובל) אז כל הדברים שתיארת עכשיו זה בעצם היו האתגרים הכי גדולים שלנו.
    • בעצם, איך אנחנו מצד אחד מאפשרים חופש מוחלט, ומצד שני שומרים על guardrails של cost ושאנחנו לא נתפזר עם הדבר הזה.
  •  אז את התהליך הזה לקח לנו כמה חודשים לפצח ובעצם אנחנו, הצוות ML, הסתכלנו על הדאטה, לקחנו את הפיצ'רים, לקחנו את המודלים ה-Python-יים שכרגע רצים לנו ב-Production
    • כמו שאמרת, יש כנראה פיצ'רים שהם נחלקים בין הלקוחות, זה היה חצי נכון . . . 
    • אבל בגדול, הסתכלנו עליהם והבנו איזה תהליכים ולצורך העניין איזה טבלאות מנורמלות “אצלנו בבית”  ומעניינות אותנו, ועל גבי הטבלאות האלה, אנחנו בעצם יצרנו Pipeline-ים עם כלי מגניב שנקרא dbt, שלרוב הוא בכלל מיועד ככה ל-Analytics.
      • זאת אומרת, בדרך כלל השימוש בו הוא על גבי Data lake, כדי לסדר את הדאטה יפה בשביל ה-Business, שה-Data Wearhouse יהיה נגיש וקריא.
    • ואנחנו אמרנו, אוקיי, בואו - אנחנו מומחים בכלי הזה, אנחנו עובדים איתו המון בתוך החברה, בואו ננסה לבנות פה טבלה שמכילה לנו את כל הפיצ'רים.
      • זאת אומרת, אנחנו בעצם לוקחים את כל הטבלאות המנורמלות שלנו בין הלקוחות.
      • על גבי כל טבלה כזאת, אנחנו גם מריצים איזשהו תהליך של Information Gains, אנחנו בוחרים את הפיצ'רים הכי טובים גם פר-לקוח, עושים כמה טריקים של SQL.
    • ובסופו של דבר מקבלים טבלה - טבלת Feature Store נקרא לזה - כש-Feature Store זה מונח קצת בעייתי לדבר הזה, אבל זו טבלה שמכילה לנו בעצם שורות ושכל שורה היא מצד אחד גם Sample לאימון ומצד שני גם Candidate ל־Inference ב-Production.
      • זאת אומרת, יש לנו טבלה אחת שמכילה פיצ'רים, היא Materialized, אפשר לתשאל אותה, והאנליסטים שבוחרים איך לנרמל את הדאטה שולטים ישירות באיך שהטבלה הזאת תיראה בסוף. 
(רן) כן, אז קודם כל, נרפרר (Reference) לפודקאסט קודם שעשינו על DBT עם חיים [455 DBT with Chaim Turkel] אם אני לא טועה, אז יש לנו פרק שלם על זה. לא יצא לי להשתמש בכלי, אבל נשמע אחלה כלי, ובוא רגע נחזור לנושא שלנו.

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

20:53 דאטה לא מייצג ותקלות אחרות

(רן) אז יכול להיות שאני לוקח אותך פה קצת את הצידה, אבל אני חייב לשאול, אני סקרן: נניח קיבלתם דאטה של חברה ואתם עושים לה Onboarding. קיבלתם דאטה של - לא יודע, חודש, שנה, שנתיים, לא יודע כמה אתם מקבלים בהתחלה.
קודם כל, איך אתה יודע שזה דאטה מייצג? זאת אומרת, יכול מאוד להיות שהחברה בזמן ה . . . לא מזמן, עשתה שינוי פעילות וקצת שינתה, לא יודע - עשתה איזשהו Promotion, הווציאה מוצר חדש . . .זאת אומרת, לא בטוח שכל הדאטה מהשנתיים האחרונות הוא באמת רלוונטי, אולי רק החודש האחרון הוא רלוונטי. אז זאת אומרת, השאלה בכללי זה, איך אתה יודע שהדאטה הוא מייצג? שתיים - מה קורה אם יש תקלות בדאטה? ותקלות תמיד יש בדאטה. לא יודע - חסר יום, חסר חודש, עשו שגיאה באפליקציה ופתאום הערכים הם פי מיליון ממה שהם היו אמורים להיות . . . דברים כאלה קורים כל הזמן ולא כל חברה הולכת ודואגת לתקן את הדאטה שלה בצורה היסטורית, אז אני בטוח שאתם מקבלים הרבה דברים כאלה. 
אז איך אתם מתמודדים איתם?
  • (יובל) אז לגבי הנקודה הראשונה - אתה אף פעם לא יודע אם הדאטה שאתה מקבל הוא מייצג או לא, וככל הנראה אתה צריך לסמוך על הלקוח שלך.
  • מה שאנחנו עושים בשביל לוודא את הדבר הזה זה שברגע שאנחנו מאמנים איזשהו מודל ומתחילים לייצר פרדיקציות, אנחנו במעקב.
    • אנחנו יודעים בעצם בכל פעם שהפרדיקציה מגיעה למה שנקרא ה-Horizon שלה - זאת אומרת, כשיש לנו Actual, יש לנו את הvalue שאנחנו חזינו אל מול הvalue האמיתי שקרה, אנחנו משווים.
    • ברגע שאנחנו רואים שהמודל פחות טוב או לא טוב מספיק, אנחנו הולכים ומאמנים מחדש.
(רן) כלומר, אוקיי - זאת אומרת, אתה אומר שהיה איזשהו Drift ב-Input Data . .  אוקיי, ומה אתם עושים? קודם כל, כמובן שיכולות להיות אנומליות אמיתיות כמו חג המולד או נובמבר וכאלה - אבל גם יש אנומליות של פשוט שגיאות, באגים. איך עולים על זה ואיך מתמודדים עם זה?
(אורי) גם יש לפעמים השפעה של המודל על ההתנהגות של המשתמשים שמשנה את הדאטה ו...
(רן) כן, כן, יש Feedback Loop.
  • (יובל) Feedback Loop, בדיוק . . .  אז את ענייני האנומליות בדאטה אנחנו בעצם מנטרים על גבי הדאטה - זאת אומרת, עוד לפני שאנחנו בכלל נותנים פרדיקציות.
  • אני רק אגיד שבעצם על ידי העובדה הזאת, שעשינו את התהליך שתיארתי, שבעצם אנחנו - we materialized our feature store - ובעצם יש לנו איזושהי טבלה שאנחנו יכולים לתשאל, אז אנחנו גם יכולים לעשות על הטבלה הזאת Monitoring.
    • ועכשיו Monitoring על פיצ'רים נהיה הרבה יותר קל.
    • זאת אומרת, לפני שאנחנו בכלל נותנים את הפרדיקציה, אנחנו יודעים שהדאטה מתנהג בצורה חריגה, ולכן אם הפרדיקציות שלנו יהיו חריגות, זה אולי לא יעלה לנו דגל אדום.

23:44 איך יותר קל וקומפקטי לעשות שטויות - SQL מול Python 

(רן)  כן, טוב, אז נחזור רגע לנושא ההנדסי-טכני של נגיד SQL מול Python. זה יכול להיות דיון גנרי, אבל במקרה הזה אנחנו מדברים על SQL מול Python.
אז אמרנו שחלק מהאתגרים זה באמת עלויות; חלק מהאתגרים זה אולי היכולת להיות קריאטיבי, זאת אומרת, נכון, אפשר לעשות המון דברים ב-SQL, אבל לפעמים יותר קל לעשות אותם ב-Python.
(אורי) . . .  אם אתה קריאטיבי . . .
(רן) . . .  כן, ולפעמים זה גם הפוך . . . אבל בכל אופן, זאת אומרת, זה לא one size fits all, יש בהחלט דברים שיותר קל יהיה לעשות את זה. נכון, יש פונקציות חלון ב-SQL, אבל צריך להיות אנליסט מאוד מתקדם כדי להבין אותן. אבל יש דברים שיותר קל לעשות ב-Python, ב-pandas, ב-NumPy. זאת אומרת, זה ספריות שנבנו לזה, ולפעמים זה יותר פשוט. והאתגר שקצת נגענו בו, אבל לא ממש דיברנו על איך פותרים, זה האתגר של העלות. זאת אומרת שכמובן שאתה יכול לעשות שטויות גם ב-Python ולבזבז CPU, אבל זה קצת יותר קל ויותר קומפקטי לעשות שטויות ב-SQL, והשאלה איך שומרים על הסיפור הזה?
לא יהיה זמן לטפל בהכל, אז תבחר מה אתה רוצה לענות.
  • (יובל) אז אולי אני אתחיל דווקא מהסוף - הטיפול שלנו ב-SQL.
  • אז החל מרגע של סיום הנורמליזציה, אין יותר כתיבת SQL, אלא ה-SQL נכתב אוטומטית על ידי ההגדרות שהאנליסטים נתנו.
    • ואנחנו כצוות Engineering שהוא Mindful מאוד ל-Cost, אנחנו בעצם גרמנו לכל ה-Queries להיבנות בצורה הכי יעילה שיש, כדי לא להשתמש ולא לבזבז יותר כסף ממה שצריך.
  • ולצורך העניין אני רגע אתלבש כבר על מה ששאלת מקודם, אז כשהיינו בעולם ה-Python-י יכולנו לעשות “הכל”. 
    • זאת אומרת, אנחנו עכשיו גם הקטנו מאוד את מרחב המשחק שלנו עם הפיצ'רים האפשריים שאנחנו יכולים לעשות, אז על גבי הטבלות המנורמלות, על גבי ה-Feature Store, אנחנו בינינו בעצם גם שכבות משלנו שאנחנו תמיד יכולים לעשות Enrichment לפיצ’רים, בלי שנזלוג בעצם . . . מה שנקרא “נראה את העתיד”, מה שנקרא Training Service Queue.
(רן) כן. זאת אומרת, אתה אומר נגיד, אני נותן לאנליסט את היכולת לבחור האם זה לקוח מסוג, לא יודע, מסוג תיירות או לקוח מסוג Gaming או לקוח מסוג אחר, ובהתאם לזה ול-Templates האלה, אתה כבר מייצר להם פיצ'רים בצורה אוטומטית - ואותם פיצ'רים, הם כבר נכתבו מראש ונבדקו ואתה יודע שהם סקיילביליים (Scalable) וזולים ויעילים.
  • (יובל) בדיוק.
(אורי) זה גם מאפשר לך . . . זאת אומרת, כל פיצ'ר הוא עמודה בטבלה?
  • (יובל) בסופו של דבר כל פיצ'ר הוא עמודה בטבלה - וזה למה אנחנו בעצם יכולים עכשיו גם לעשות הרבה מאוד דברים שלא עשינו בעבר.
  • זאת אומרת, אתה יכול להסתכל, אתה יכול לתת לאנליסט להסתכל על הדאטה ההיסטורי של הפיצ'רים שלך ובעצם להבין אם יש לך, כמו שתיארנו קודם, אם ה-Skew הוא בדאטה או Skew בפיצ'רים.
  • אני חושב שהחוזק הכי גדול פה זה העובדה שה-Feature Matrix של האימון שעליו אנחנו מתאמנים הוא בעצם איזשהו Subset של שורות מהטבלה של ה-Feature Store.
    • ואז בעצם נורא קל להסתכל אחורה, להבין רגע למה המודל שלי . . . למה המודל נתן לי פרדיקציות מוזרות?
    • בוא רגע נסתכל על הפיצ'רים - בוא נראה מה הפיצ'ר הכי חזק? מה הפיצ'ר שהכי משפיע על הפרדיקציה במודל?
      • ובוא נראה איך הוא השתנה עכשיו. 
(אורי) אבל אני בדרך כלל לא . . .  יש Domain-ים, שאני לא אוהב שדברים הם בעמודות - כי זה מאוד מאוד סטטי. וזה, אתה יודע, להוסיף פיצ'ר עכשיו זה להוסיף עמודה - ולהוסיף עמודה זה כואב. וזה אומר, לפי מה שאני מבין ממך, זה שעולם המודלים שלכם והפיצ'רים במודלים הוא מאוד מאוד סטטי. זאת אומרת, אתם לא מתכננים לשינויים דרמטיים בעולם הפיצ'רים שלכם, בשביל שמהצד השני אתה יודע אתה הולך ל... בין אם זה Deep Learning או כמויות של פיצ'רים הן הרבה מאוד פעמים דינמיות, בפיצ'רים.
  • (יובל) אז כן ולא - כי אנחנו יודעים להגדיר כבר עכשיו סט פיצ'רים שהוא מאוד מאוד חזק.
    • זאת אומרת, המודלים שלנו מתפקדים מאוד מאוד טוב - אבל הבעיה שאתה מתאר, כמובן שהיא עלתה לנו לראש.
    • וכבר עכשיו יש לנו דרך להרחיב את ה-Feature Store הזה - אבל בצורה תוכנתית.
  • עכשיו, איך אנחנו עושים את זה? כשהמודלים שלנו ניגשים בעצם ל-Feature Store, יש לך איזושהי נקודת גישה אחת - בין אם זה ל-Training ובין אם זה ל-Inference.
    • אתה יכול לתשאל את הפיצ'רים - ובעצם, כשאתה מביא אליך את הפיצ'רים עצמם, אנחנו יודעים גם להצמיד אליהם עוד פיצ'רים, שהם לא materialized, אבל הם יהיו קיימים, לצורך העניין, ב-Feature Matrix שאתה הולך לחזות. 
  • עכשיו, הפיצ'רים האלה זה פיצ'רים שבאמת אנחנו לא יכולים לתשאל בצורה הזאת, ב-SQL.
    • אבל אנחנו כרגע יודעים שכשיש לנו איזשהו “פיצ'ר מנצח” - זאת אומרת, אתה רוצה, יש לך איזה מקרה קצה אצל הלקוח עכשיו, אתה יודע שפיצ'ר מאוד חזק זה מספר הטרנזקציות מסוג X שעברו לפחות שלושה ימים מאז שהם קרו. 
    • אז לדבר הזה אנחנו גם נותנים לאנליסטים יכולת לכתוב איזשהו Template - כשאת ה-Template הזה אנחנו מצמידים ל-Query ב-Feature Store בזמן הריצה.
    • ואז הפיצ'ר הזה . . .  זאת אומרת, אנחנו לא צריכים עכשיו לעשות מיגרציה (Migration) לטבלה עצמה, אבל אנחנו בונים איזשהו view מעל זה שכן עושה לפיצ'ר הזה מטריאליזציה (Materialize) במובן שבו אתה יכול לתשאל אותו ולראות את הערכים שלו.
    • אז אנחנו גם יכולים לבנות המון פיצ'רים בגישה הזאת, ובעצם על ידי זה להרחיב את ה-Feature Store שלנו.
(רן) זאת אומרת שיש פה איזושהי Expansibility בעצם, זה מה שאתה רוצה . . .
  • (יובל) לגמרי . . .
(רן) . . . אבל אני חושב שבוא -  כאילו, עם יד על הלב, אי אפשר להתעלם גם מהאמירה של אורי, שככל שאתה מכניס יותר Frameworks וככל שאתה מכניס יותר סדר, אתה מכניס יותר סדר זה מצוין - אבל אתה גם . . .
  • (יובל) מוריד Complexity . . . 
(רן) . . . מוריד Complexity - ואתה גם מוריד את האפשרויות ליצור דברים שלא חשבת עליהם. אתה יוצא מתוך נקודות הנחה - וזה Tradeoff ידוע. זאת אומרת - זה בחירה שלך. 
(אורי) . . .א בל אחרי שנסגור את המיקרופונים, אני אלמד אותך איך עושים את זה קצת  . . . 


30:43 הגבינה שזזה והצד האנושי

(רן) אבל בוא רגע נדבר גם על הצד האנושי . . .  אוקיי, אז דיברת על אנליסטים, דיברת על ה-ML Engineers. בעצם, באתם עם איזשהו שינוי גישה, אוקיי? והשינוי גישה הזה מזיז להרבה אנשים את הגבינה. הם היו רגילים לעשות Onboarding של שבועיים-שלושה ללקוח, הם היו רגילים להסתכל ככה על דאטה, הם היו רגילים להשתמש ב-Python, הם היו רגילים לעשות הרבה דברים אחרים, ואתה בעצם בא ומשנה להם.
איך מנהלים תהליך כזה - ואני מתקל אותך גם - איזה הפתעות טובות ואיזה הפתעות רעות היו לך במהלך, בפן האנושי? זאת אומרת, איפה היה יותר קשה ואיפה היה יותר קשה ואולי, ככה, לא ציפית לזה?
  • (יובל) אז אני חושב שהחלק הכי קשה פה היה בהתחלה עבור ה-Data Scientist-ים, שבעצם עכשיו מבינים שאין יותר קוד Python, אין יותר את השליטה שהייתה עד עכשיו בעצם בדבר הזה.
  • אבל אני חושב שבסופו של דבר כולנו הבנו שזה בעצם מפנה אותם למשימות הרבה יותר רחבות והרבה יותר מעניינות.
    • אולי משימות פר-Vertical, זאת אומרת משימות SaaS, משימות Gaming, משימות בעצם הרבה יותר רחבות ומעניינות. 
(רן) כן - אבל יש את העקצוץ הראשוני של “היי רגע, לקחו לי את העבודה! אני הייתי עושה את זה”. היה לי פה איזשהו, נגיד את זה, Job Security, ופתאום מישהו מזיז לי ומפריע לי - ואולי גם עושה את זה פחות טוב. אתה יודע, יכול להיות שגם טעיתם פה ושם . . . אז איך מתמודדים עם כל זה?
  • (יובל) אז אנחנו עובדים גם על המון המון מוצרים אחרים - וזה בעצם מפנה אותם לעבוד ולהתמקד ב-Use Case-ים האלה. 
  • המוצר שאני בעצם תיארתי הוא משהו שיותר מתמקד באזורי ה-User Acquisition, החלק הראשון ב- User Life Cycle, וזה משחרר הרבה מאוד מה-Data Scientist-ים שלנו להתמקד עכשיו באזורים של Streaming.
    • עכשיו עושים Feature Engineering ב-Streaming, ושם הכל לחלוטין Python-י . . .
    • יש המון המון דברים אחרים מעניינים ומאתגרים - והם לא נעלמו לגמרי.
    • כי בעצם, כשיש בעיות מסובכות, כשיש מודלים שעדיין צריך לפצח . . . כאילו, לא הגענו עוד ל-Quality שאנחנו רוצים, אז מה עכשיו? 
    • תמיד יהיה מה לעשות באזורים האלה.
(רן) כן, אוקיי. ואיזה הפתעות טובות גילית פה בתהליך? בפן האנושי?
  • (יובל) בפן האנושי, אני חושב שאנליסטים מאוד מאוד אוהבים את הכיוון הזה.
    • זה גם חושף אותם ומקרב אותם לעולם שהוא אולי היה עוד פחות נגיש להם בעבר. 
    • אני רואה את זה ככה, וזה דבר ראשון.
  • דבר שני - הם גם רואים שזה בעצם זירז את תהליך ה-Onboarding בצורה משמעותית.
    • זאת אומרת, אם בעבר, בממוצע, התהליך של מבניית . . . מסוף הנורמליזציה ועד שיש לנו מודל ב-Production, זה היה בממוצע שבועיים וחצי, עכשיו תוך יום וחצי הם יכולים בעצם להביא מודל ל-Production בעצמם
      • כשהם יודעים מה הולך ולא צריכים לעשות יותר כלום.
(אורי) ולכמה זמן זה יהיה תקף? כאילו...
  • (יובל) למה הכוונה?
(אורי) אתה אומר “הם לא צריכים לעשות יותר כלום” . . . 
  • (יובל) עד שאנחנו מזהים שהמודל מחזיק... עד שיש אנומליה, עד שיש איזשהו Skew בדאטה או שהמודל מפסיק לתפקד טוב.
    • עד שקופצת לנו נורה אדומה ואומרת, “הלו!, בואו נחקור, בואו נראה מה קורה פה”.
(אורי) אבל בגדול, אם הכל מתנהל כמו שצריך - ה-Data Scientist לא ב-Loop. . .
  • (יובל) עוברים ללקוח הבא . . . אם אנחנו, עכשיו, יש לך מודלים שרצים, והלקוח מרוצה - אתה מראה לו value, אתה עושה את כל מה שאתה אמור לעשות כמוצר. If it works. . .
(אורי) אני חושב שהכוונה של אורי זה שאם לפני זה הם היו בלופ שבועיים-וחצי, היום הם בלופ יום-וחצי. הם עדיין בלופ . . .
  • (יובל) הם עדיין בלופ. אין ברירה. כן, אין ברירה. 
(רן) כן. תראה, אולי מתישהו גם... 
  • (יובל) אולי מתישהו - אנחנו עובדים גם על Report-ים שיעשו את העבודה הזו. 
(רן) אבל אני גם מבין - לבוא ונצל כישרון במקומות שבהם הוא באמת נדרש ולעשות אוטומציה במקומות אחרים.
(אורי) כן. אני מנסה לחשוב. נגיד, אנחנו פעם היינו מאמנים מודל, פעם בכמה זמן, בסדר? Data Scientist היה צריך לאמן את המודל הזה וזה. אחד הדברים שנראו לנו חשובים - כי יש המון תזוזה בדאטה - זה לאמן, להיות כמה שיותר Real-Time-י. הגענו ל... אנחנו מאמנים מודל כל חמש דקות. עכשיו, אתה לא יכול להושיב Data Scientist לאמן את זה כל חמש דקות, אז זה הכריח אותנו לבנות מערכת שיודעת לעשות את זה לבד. 
  • (יובל) Automatic retraining, כן. אנחנו גם שם, זה... אנחנו עוד לא שם לגמרי, אבל בעצם כרגע, כשיש נורה אדומה, מישהו לוחץ על כמה כפתורים ומודל מתאמן מחדש.
    • וכשאנחנו בעצם רואים, אוקיי, המודל הזה מספיק טוב ב-Production, אנחנו בדרך ליתר את התהליך הזה.
    • וכשהנורה האדומה קופצת, התהליך הזה יקרה אוטומטית, ויהיה לנו כבר מודל חדש. 
  • וגם צריך לזכור שבעצם אצלנו המודלים הם . . . זה המוצר.
    • בסופו של דבר, אני לא אגיד שזה המוצר, אבל זה ככה “ה-Core ”של מה שאנחנו בעצם, של ה-value שאנחנו נותנים ללקוחות שלנו. 
(אורי) זה קצת מלכודת, המשפט הזה . . . כי אתה אומר, “זה המוצר”, זה מה שאנחנו נותנים ללקוחות שלנו - אז לפעמים בבטן זה נותן לך הצדקה לשים על זה בן אדם, אפילו אם הוא יקר, אוקיי?
אבל אז מה אם זה המוצר שלך? אז מה אם זה ה-bread and butter של החברה? כאילו, אם אפשר לאטמט (Automate) את זה, בסוף, ב-Scale, זה המון כסף. אז כאילו, דווקא במקום ששמה זה המוצר, צריך להשקיע ולהכניס כמה שיותר אוטומציות. וזה גם הרבה יותר מעניין לאנשים - בסוף מהנדסים, חוקרים, מאוד אוהבים ליתר את עצמם.
  • (יובל) לגמרי. ושוב, כמו שאמרתי בהתחלה, החזון הוא מוצר SaaS-י לחלוטין, שבו בכלל לא יהיה לך מישהו בדרך.
    • החברה, שהלקוח שלנו יבוא, יעשה Onboarding לעצמו, הפיצ'רים ייווצרו, המודל ייווצר, המודל יתחיל ליצר פרדיקציות . . . 
    • כשהמודל יבין שהוא לא מספיק טוב, יהיה אימון מחדש על המודל, משהו יהיה, המטריקה (Metric) שמגדירה אם המודל הזה מספיק טוב, תגיד שהוא מספיק טוב, או שהמודל יוחלף. 


37:18 עוד קצת Voyantis

(רן) אוקיי, אנחנו כבר לקראת סיום. נחזור קצת לחברה עצמה, Voyantis. אז הבנו מה אתם עושים, תספר לנו קצת על החברה עצמה - איפה אתם יושבים, כמה עובדים בהנדסה? אם אתם מגייסים, אז מה אתם מחפשים?
  • (יובל) אז אנחנו יושבים בתל אביב, ככה ממש ליד עזריאלי.
  • כרגע אנחנו 90 איש בחברה, ואני חושב שעד סוף השנה מתכננים להיות כבר יותר קרוב ל-110-120.
  • מגייסים באמת להמון תפקידים - ה-R&D שלנו יחסית קטן, ואנחנו מנסים לשמור עליו ככה. 
    • אנחנו ככה, עם כל ההייפ הנוכחי, גייסנו לצידנו את כל כלי ה-AI הרלוונטיים, ואנחנו רואים ש... 
    • (אורי) אגב, אנחנו לקראת הסוף וזו פעם ראשונה שאמרנו “AI”. 
    • (יובל) “AI” ,כן. אף אחד לא אמר את זה, אז הרגשתי צורך.
    • אז באמת מגייסים להרבה תפקידים, גם ב-R&D. שכחתי מה אמרת . . .
    • (רן) לא, שאלתי מה מגייסים, סתם אם מישהו מעוניין שידע. 
    • (יובל) כן, דברו איתנו!
    • (רן) מעולה. בסדר, אז תוכלו כמובן למצוא את זה ב-show notes [שזה כאן, בגדול].

38:35 כנס Reversim Summit 2025

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

זה הכל. תודה רבה לך, יובל! - תודה רבה לכם - ובהצלחה עם כל ה-AI הזה שלך. להתראות.


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

אין תגובות:

הוסף רשומת תגובה

הירשם ל- תגובות לפרסום (Atom)