פעם התייחסו ל-prompt engineering כאילו זאת קופירייטינג עם קפאין. בפועל זה קרוב יותר לעיצוב policy. להגדיר את המשימה, את הגבולות, את הדפוס הרצוי, ולבדוק את התוצאה מול המציאות. משפט הקסם לא הגיע.
prompt הוא לא שכבת הטקסט היחידה
כשצוות אומר "צריך לשפר את הפרומפט", לרוב הכוונה לאחד מאלה. לשנות פורמט תשובה. להוסיף few-shot examples. לשפר schema או validator. להחליף tool contract. לחזק policy. להוסיף evals.
כל אלה משפיעים על התוצאה לא פחות מהניסוח עצמו.
ניסוח בלי גבולות הוא חצי עבודה
פרומפט בריא מגדיר את המשימה, את הטווח, מתי להימנע, באיזה פורמט לצאת, ומה לעשות אם אין תמיכה מספיקה.
במערכות רציניות prompt שלא יודע להגיד "אין לי בסיס מספיק" הוא לא prompt שלם.
examples עובדים כשהם מבהירים דפוס
Few-shot examples מועילים כשהם מבהירים את צורת הפלט או את גבול ההתנהגות.
פחות מועילים כשמשתמשים בהם כקמיע. אם הדוגמה לא מתקשרת למחלקת כשל ממשית, היא רק עוד טקסט.
tools משנים את תפקיד הפרומפט
ברגע שיש tools, prompt engineering מפסיק להיות "איך לנסח שאלה יפה" והופך לתיאום בין מודל, tool contracts, state, policy ו-evals.
הפרומפט לא שולט במערכת לבד. הוא חלק ממכלול. הרבה "בעיות prompt" בעצם בעיות של חוזה כלי, retrieval או ציפייה לא ברורה.
format matters
הדרך הטובה להפחית chaos היא לעצב פלט שאפשר לבדוק. JSON schema. תשובה מחולקת ל-sections קבועים. yes/no כשזה מה שצריך. reference fields ברורים. citation slots.
פורמט טוב מקטין שטח פרשנות, גם למודל וגם לאנשים שבודקים אחר כך.
prompt review בתוך delivery
Prompt review בריא שואל. איזו מחלקת כשל זה אמור לתקן. איך נדע שזה עזר. אילו side effects זה עלול להכניס. האם הפרומפט הוא בכלל השכבה הנכונה לגעת בה.
עם השאלות האלה, הרבה "שינויי prompt" מתגלים כשינוי retrieval, schema או release gate בתחפושת.
evals סוגרים את המעגל
בלי evals, prompt engineering נשאר ויכוח בטעם.
עם evals אפשר לבדוק אם שינוי שיפר format compliance, הוריד unsupported claims, פגע ב-abstention, שינה latency, יצר regressions בכיתות כשל אחרות.
כאן prompt engineering מפסיק להיות craft עמום והופך להנדסה סבירה.
Prompt טוב לא נמדד בזה שהוא נשמע חכם. הוא נמדד בזה שהוא מייצר התנהגות שאפשר לצפות, לבדוק ולתחזק. פחות רומנטי. הרבה יותר שימושי.