פעם התייחסו ל-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 קובע מה אפשר לבדוק
הדרך הטובה להפחית chaos היא לעצב פלט שאפשר לבדוק. JSON schema. תשובה מחולקת ל-sections קבועים. yes/no כשזה מה שצריך. reference fields ברורים. citation slots.
פורמט טוב מקטין שטח פרשנות, גם למודל וגם לאנשים שבודקים אחר כך.