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