מה זה Prompt Engineering? הסבר + משרות בישראל

Prompt Engineering הוא תכנון ההנחיה שניתנת למודל שפה כדי לקבל ממנו פלט אמין, בפורמט קבוע וניתן לבדיקה. זו עבודה הנדסית ולא ניסוח יפה: מגדירים משימה, מספקים הקשר, קובעים מבנה פלט ובודקים מול סט מקרים. בלוח HiTakeJob פתוחות כרגע 8 משרות שמזכירות LangChain ו-365 שמזכירות Python.

למה ניסוח ההנחיה משנה בכלל

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

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

מה באמת עובד - ומה רק נשמע טוב

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

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

איך נראית הנחיה מקצועית

הנחיה שמשולבת במערכת אמיתית בנויה מחלקים קבועים:

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

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

איך יודעים שההנחיה עובדת?

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

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

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

איך מנהלים הנחיות כשיש יותר מאחת

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

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

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

עלות וזמן תגובה - מה שמשפיע על העיצוב

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

האם זה תפקיד בפני עצמו?

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

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

מה שווה לדעת לפני שמשלבים את זה במוצר

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

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

שאלות נפוצות

צריך לדעת לתכנת כדי לעסוק בזה?

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

מה ההבדל בין prompt engineering לכוונון עדין?

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

כמה משרות AI יש בישראל כרגע?

המאגר אינו מתייג AI כטכנולוגיה אחת. 8 משרות מזכירות LangChain ו-27 מזכירות PyTorch מתוך 1,952 משרות פעילות, אך רוב התפקידים היישומיים מפורסמים כמשרות פיתוח רגילות עם דרישה להיכרות עם מודלים.

איך מתרגלים את זה ברצינות?

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

מה ההבדל בין הנחיית מערכת להנחיית משתמש?

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

האם המיומנות הזו תישאר רלוונטית?

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