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

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

התפקיד בשורה אחת: אינטגרציה, לא אימון

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

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

RAG בפועל: איפה זה נשבר

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

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

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

מערכי הערכה: איך יודעים שהשינוי שיפר

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

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

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

הנדסת הקשר, לא "ניסוח הנחיות"

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

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

גרדריילים, הזרקת הנחיות ומה אסור שיזלוג

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

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

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

תקציב טוקנים ותקציב זמן תגובה

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

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

בחירת ספק ומודל בלי להתאהב

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

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

90 הימים הראשונים בתפקיד

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

שכר בישראל - הערכת שוק

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

שלב בקריירה	ותק	טווח ברוטו לחודש (הערכת שוק)
ג'וניור	0-2 שנים	20,000-28,000 ש"ח (הערכת שוק)
ביניים	2-5 שנים	29,000-44,000 ש"ח (הערכת שוק)
בכיר	5+ שנים	45,000-62,000 ש"ח (הערכת שוק)

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

איך נכנסים, ומה פתוח כרגע

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

מבחינת היקף השוק: בשדה הקטגוריות של הלוח מסווגות 88 משרות תחת בינה מלאכותית ו-3 תחת הנדסת GenAI. אפשר להתחיל מ-365 משרות שמזכירות Python ומ-377 משרות פיתוח ומחקר. אם מעניין אתכם דווקא הצד של אימון מודלים ותשתית אימון, ראו את מדריך הקריירה למפתח ML.

שאלות נפוצות

צריך רקע במתמטיקה?

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

מה ההבדל בין התפקיד לבין מפתח ML?

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

האם כוונון עדין נדרש בדרך כלל?

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

איך מתמודדים עם הזיות?

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

כמה זמן לוקח להיכנס ממפתח backend?

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

האם הכותרת הזו תישאר בעוד שלוש שנים?

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

מה שווה לשאול את המראיין?

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