מהנדס פרומפטים: האם התפקיד עדיין קיים ואת מי מגייסים במקומו

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

מהנדס פרומפטים: מה קרה לתפקיד שכולם דיברו עליו

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

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

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

מהנחיות להנדסת הקשר

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

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

סטים של בדיקות: מה שמבדיל מקצוען מחובב

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

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

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

כותבים מול מהנדסים: שני פרופילים לאותה כותרת

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

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

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

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

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

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

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

למה לגייס דרך AI האנטרס

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

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

שאלות שחוזרות בגיוס הזה

האם עדיין יש טעם לפתוח משרה בשם מהנדס פרומפטים?

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

מה ההבדל בין מהנדס פרומפטים ל-Context Engineer?

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

האם התפקיד דורש רקע בתכנות?

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

כמה עולה לגייס מהנדס פרומפטים דרככם?

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

איך בודקים מועמד בלי לחשוף את המוצר או את הנתונים?

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