מפתח/ת ML בישראל: מה התפקיד עושה, שכר, ואיך נכנסים

מפתח/ת ML הוא מהנדס תוכנה שהמוצר שלו הוא מודל שרץ בייצור: הוא בונה את צינור האימון, את שכבת הפיצ'רים, את שירות ההסקה ואת הניטור שמזהה מתי המודל מתחיל לטעות. בלוח HiTakeJob פתוחות כרגע 365 משרות שמזכירות Python ו-27 שמזכירות PyTorch.

איפה עובר הגבול מול Data Scientist

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

נושא	Data Scientist	ML Engineer
תוצר עיקרי	ניתוח, מחברת, מודל ניסיוני	שירות שרץ בייצור
מדד הצלחה	דיוק המודל	דיוק + זמן תגובה + עלות + יציבות
שליטה בקוד	מחברות, סקריפטים	קוד נבדק, מכולות, CI
נגיעה בתשתית	מועטה	יומיומית
כאב עיקרי	נתונים חסרים	הפרש בין אימון להסקה

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

צינור האימון: מה באמת בונים

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

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

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

Feature store והסכנה של פער אימון-הסקה

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

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

זמן תגובה, קצב ועלות של שירות מודל

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

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

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

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

ניטור סחיפה, ומתי לאמן מחדש

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

סוג שינוי	מה זז	סימן מעשי
סחיפת נתונים	התפלגות הקלט	פיצ'ר שהממוצע שלו קפץ ב-30%
סחיפת מושג	הקשר בין קלט לתוצאה	דיוק יורד בלי שינוי בקלט
תקלת צנרת	שדה שהפסיק להגיע	שיעור ערכים חסרים שקפץ פתאום

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

שאלות שחוזרות בראיונות בישראל

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

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

טווחי שכר - הערכת שוק בלבד

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

דרג	שנות ניסיון	ברוטו חודשי משוער (הערכת שוק)
ג'וניור	0-2 שנים	22,000-30,000 ש"ח (הערכת שוק)
ביניים	2-5 שנים	31,000-45,000 ש"ח (הערכת שוק)
בכיר	5+ שנים	45,000-60,000 ש"ח (הערכת שוק)
ראש צוות ML	7+ שנים	55,000-75,000 ש"ח (הערכת שוק)

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

שני מסלולי כניסה, ואיזה מהם קצר יותר

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

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

בשני המסלולים כדאי לזכור שהכניסה לתחום כמעט תמיד עוברת דרך קוד: בשדה הקטגוריות של הלוח מסווגות 63 משרות תחת הנדסת למידת מכונה ו-16 תחת MLOps, אבל רק ל-4 משרות מופיע הצירוף ML Engineer בכותרת. הרוב מופיעות ככותרות פיתוח רגילות.

מה פתוח בלוח כרגע

אפשר להתחיל מ-365 משרות שמזכירות Python, מ-27 משרות שמזכירות PyTorch, או מהקטגוריה הרחבה של 377 משרות פיתוח ומחקר. אם אתם מתלבטים בין המסלול ההנדסי הזה לבין תפקיד שבנוי סביב מודלים של ספקים חיצוניים, ראו את מדריך הקריירה ל-AI Engineer - אלה שני תפקידים שונים למרות השם הדומה.

שאלות נפוצות

חייבים תואר שני?

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

PyTorch או TensorFlow?

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

כמה מהעבודה היא בכלל מודלים?

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

האם מודלים מוכנים מייתרים את התפקיד?

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

מה ההבדל מול MLOps?

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

איזה פרויקט אישי שווה משהו?

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

איך עוברים מחברה קטנה לגדולה?

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