פרומפט אנג'ינירינג הוא השם שניתן לעבודה של ניסוח, ארגון ושיפור ההוראות שניתנות למודל שפה, כדי לקבל ממנו תוצאה מדויקת, עקבית ושימושית יותר. בתיעוד הרשמי של AWS המונח מוגדר כפרקטיקה של אופטימיזציה של קלט טקסטואלי למודל שפה גדול, כדי להשיג את התגובה הרצויה. גם Microsoft מציגה אותו כדרך לארגן הוראות, הקשר ודוגמאות כך שהמודל יבצע את המשימה בצורה טובה יותר.
במילים פשוטות, מדובר לא רק ב"לשאול שאלה". מדובר בבנייה מכוונת של ההקשר שבו המודל עובד. כאשר כותבים פרומפט, קובעים מה המודל אמור לעשות, על מה להתמקד, ממה להתעלם, באיזה סגנון לענות, ומהי בדיוק התוצאה שמצפים לקבל. לכן פרומפט אנג'ינירינג אינו רק ניסוח יפה יותר, אלא דרך להשפיע על אופן הפירוש של המשימה.
החשיבות של המונח גדלה במיוחד עם השימוש במודלי שפה למשימות שאינן רק שיחה כללית אלא גם סיכום, סיווג, חילוץ מידע, כתיבת קוד, עיבוד מסמכים והפעלה של סוכנים. ככל שהמודל נדרש לעשות יותר, כך גם עולה החשיבות של האופן שבו מנסחים לו את המסגרת. מסמכי OpenAI על אופטימיזציית מודלים מדגישים שהנדסת פרומפטים היא לעיתים כל מה שנדרש כדי להשיג תוצאות טובות מאוד, לפני שעוברים בכלל לכיוונון עמוק יותר של המודל.
לכן, אם צריך לנסח את זה בצורה בהירה, אפשר לומר כך Prompt Engineering הוא תכנון מכוון של הוראות למודל שפה, במטרה לשלוט טוב יותר באופן שבו הוא מפרש משימה ומייצר תוצאה. זהו מונח שמתאר לא רק את הטקסט שנכתב למודל, אלא את החשיבה שמאחורי הכתיבה הזו.
התפתחות המונח
הרעיון של עבודה מכוונת עם פרומפטים קיים למעשה מאז שמודלים ג'נרטיביים החלו לפעול דרך קלט טקסטואלי, אך המונח Prompt Engineering התבסס כמונח מקצועי בעיקר עם העלייה של מודלי השפה הגדולים בתחילת 2020. כיום הוא מופיע באופן מפורש בתיעוד הרשמי של מודלי שפה LLM ובהפך למושג מקובל בעולם.
הסיבה לכך היסטורית די ברורה. כאשר התברר שאותה משימה יכולה להניב תוצאות שונות מאוד רק בגלל שינוי בניסוח ההוראה, מפתחים, חוקרים ואנשי מוצר הבינו שהפרומפט עצמו הוא חלק מהותי מהמערכת. לא מדובר רק בפקודה טכנית, אלא ברכיב שמשפיע על איכות הביצוע. ככל שמודלים נעשו חזקים יותר, וככל שהם הוטמעו בתוך מערכות אמיתיות, כך גם גברה ההבנה שנדרש תחום עבודה מסודר סביב ניסוח, בדיקה ושיפור של פרומפטים.
המונח לא צמח כדיסציפלינה אקדמית ותיקה כמו תורת הארגון או הגישה הסוציו־טכנית, אלא מתוך הפרקטיקה של עבודה עם מודלים. קודם הופיעה הבעיה, ורק אחר כך התייצב המונח. ככל שגדל השימוש במודלים לצורכי עבודה, שירות, תפעול ופיתוח, כך גם הנדסת פרומפטים הפך משם נוח למשהו שאנשים מתייחסים אליו כאל מיומנות ממשית.
השכבות של כתיבת הפרומפט
כאשר מסתכלים על פרומפט בצורה רצינית, רואים שהוא מורכב מכמה שכבות. השכבה הראשונה היא שכבת התפקיד. כאן מגדירים למודל מי הוא בתוך המשימה. האם הוא מסכם מידע, מסווג מסמכים, בודק תקינות, מציע צעד הבא או רק עונה על שאלה.
השכבה השנייה היא שכבת ההקשר. כאן נותנים למודל את המידע שהוא צריך כדי להבין את המשימה: רקע, מטרת השימוש, נתונים רלוונטיים, מסמך מקור, או תיאור של המצב.
השכבה השלישית היא שכבת ההנחיה המבנית. כאן מגדירים למודל איך לענות. למשל, האם עליו להחזיר טבלה, רשימה, סיכום קצר, תשובה רשמית, או ניתוח בכמה שלבים. זו שכבה חשובה מאוד מפני שמודל יכול להבין את המשימה באופן כללי, אבל עדיין להחזיר פלט שאינו מתאים לשימוש. לכן חלק משמעותי מפרומפט אנג'ינירינג הוא לא רק "מה לעשות" אלא איך להציג את התוצאה.
השכבה הרביעית היא שכבת הגבול. זו אולי השכבה החשובה ביותר במערכות אמיתיות. כאן אומרים למודל מה לא לעשות, מתי לעצור, מה לעשות כאשר חסר מידע, ומה לעשות כאשר יש עמימות. במסמכי מיקרוסופט מודגש במפורש הצורך להוסיף מדיניות של מה לעשות מתי שההנחיה לא ברורה כלומר להנחות את המודל איך לנהוג כאשר הבקשה עמומה, חסרה או מחוץ לתחום. זו כבר לא רק שכבת איכות, אלא שכבת בקרה.
אם מחברים את כל זה, רואים שפרומפט טוב אינו משפט אחד אלא מבנה. הוא כולל תפקיד, הקשר, הנחיה מבנית וגבולות פעולה. זו בדיוק הסיבה שהמונח "הנדסה" מתאים כאן. לא מפני שמדובר בהנדסה במובן הקלאסי, אלא מפני שיש כאן תכנון שיטתי של רכיבים שמשפיעים יחד על התוצאה.
חשיבות הפרומפט במערכות ציבוריות
החשיבות של פרומפט אנג'ינירינג במערכות ציבוריות גדולה במיוחד, כי שם הפלט של המודל אינו נשאר תמיד בגבולות של ניסוח. הוא עלול להשפיע על טיפול בבקשות, סיווג פניות, קדימות תפעולית והעברת מידע בין יחידות. במערכות כאלה, פרומפט אינו רק דרך להוציא תשובה טובה יותר. הוא הופך בפועל לחלק מן ההיגיון שמפעיל את התהליך.
נניח, למשל, מערכת עירונית שקולטת פניות תושבים על מפגעים במרחב הציבורי. אם המודל מקבל פרומפט כללי מדי כמו "זהה פניות דחופות", הוא עלול לייחס משקל עודף לניסוחים רגשיים או למילים כמו "דחוף" ו"מיידי", גם כאשר אין בפנייה עצמה אינדיקציה ממשית לסיכון. לעומת זאת, אם הפרומפט מגדיר בבירור מה נחשב דחוף, על אילו סימנים להסתמך, ומה לעשות כאשר חסרים פרטים, אפשר לכוון את המודל לפעולה אחראית יותר. כאן רואים היטב שהפרומפט אינו רק ניסוח. הוא מסגרת של שיקול דעת.
אפשר לחשוב גם על מערכת ציבורית שבודקת בקשות להנחה בארנונה. אם המודל נדרש לסכם מסמכים ולסמן מה חסר, הפרומפט צריך להגדיר לו שהוא אינו קובע זכאות, שהוא נשען על נתונים מאומתים בלבד, ושכאשר קיימת סתירה בין טקסט חופשי לבין מסמך רשמי עליו לסמן זאת במקום להכריע. בלי שכבת גבול כזו, המודל עלול להישמע בטוח מדי גם במקום שבו אסור לו להחליט. זו בדיוק הסיבה שארגונים לא יכולים להסתפק בפרומפטים "חכמים", אלא צריכים פרומפטים ברורים. בסופו של דבר הפרומפט חשוב כי הוא יושב בנקודה שבה שפה הופכת למנגנון הפעלה. הוא התחיל כמונח מעשי בעולם מודלי השפה והפך מהר מאוד לחלק מרכזי בתכנון מערכות מבוססות בינה מלאכותית. ככל שמודלים מעורבים יותר בתהליכים אמיתיים, כך מתברר שהאופן שבו כותבים להם אינו פרט שולי, אלא חלק מן הארכיטקטורה של המערכת עצמה.