רוב האנשים לומדים הנדסת פרומפטים הפוך. משננים רשימה של טכניקות, zero-shot, few-shot, chain-of-thought, בלי להבין למה כל אחת קיימת ומתי כדאי להשתמש בה. ככה מגיעים לספריית פרומפטים מלאה בטריקים שאף אחד לא משתמש בהם.
הנה הגרסה המעשית: מה כל טכניקה עושה, מתי היא מצדיקה את המקום שלה בפרומפט, ומה באמת משפר את איכות התוצאה.
הנדסת פרומפטים היא עיצוב הקלט למודל AI כך שהפלט יתאים למה שבאמת צריך, בניסיון הראשון ולא בחמישי. אין בזה שום דבר מיסטי. פרומפט מעורפל מקבל תשובה מעורפלת. פרומפט ספציפי לא.
חלש: "להסביר Python."
חזק: "להסביר Python למתחילים גמורים, עם 3 דוגמאות קוד קצרות שאפשר להריץ מיד."
אותה שאלה, פלט שונה לגמרי. ההבדל הוא הקשר ומגבלות, לא תחכום.
פרומפט בנוי טוב מצמצם הזיות, שומר על פלט עקבי בין הרצות וחוסך לנסח מחדש חמש פעמים עד שמקבלים משהו שמיש. מי שבונה תהליך AI כלשהו, פס ייצור תוכן, צ'אטבוט, כלי פנימי, צריך לדעת שהפרומפט עושה יותר עבודה מבחירת המודל.
כמעט כל פרומפט שמצליח כולל את אותם חמישה חלקים:
דוגמה: "תפקיד: אנליסט נתונים בכיר. משימה: להסביר JOIN ב-SQL לקהל מתחילים. שפה פשוטה, דוגמה אחת לכל סוג JOIN, ובסוף טבלת השוואה." יש כאן תפקיד, משימה, קהל ופורמט פלט. ארבעה חלקים שעושים את העבודה של עשר פסקאות הסבר מעורפל.
Zero-shot זה לשאול ישירות, בלי דוגמאות. עובד טוב לתרגום, סיכום, או כל דבר שהמודל ראה אלף פעם באימון. "לתרגם את זה לצרפתית" לא צריך הדגמה.
One-shot נותן דוגמה אחת קודם. שימושי כשהפורמט חשוב יותר ממה שהמודל יכול להבין מההוראה לבד: טון מסוים, מבנה מסוים.
Few-shot נותן כמה דוגמאות לפני המשימה האמיתית. זו הטכניקה שבאמת מעלה דיוק במשימות סיווג וזיהוי דפוסים. שלוש או ארבע דוגמאות מתויגות ("חיובי: מוצר מעולה. שלילי: חוויה גרועה.") מלמדות את המודל את הדפוס המדויק, מהר יותר מכל כמות של הסברים.
כלל אצבע: אם מסבירים את הפורמט במילים, כדאי לנסות להראות אותו בדוגמה.
לבקש מהמודל "להתנהג כמו מהנדס בכיר" או "להתנהג כמו עורך דין" זה לא רק תיבול. זה משנה את אוצר המילים, את העומק ואת ההנחות שהמודל עובד איתן. תשובה ממסגרת של רופא ותשובה לקהל הרחב על אותה שאלה רפואית נקראות אחרת לגמרי. משתמשים בהגדרת תפקיד כשצריך עדשה מסוימת, לא רק קול אחר.
לבקש מהמודל "לפתור את זה שלב אחרי שלב לפני התשובה הסופית" משפר תוצאות באופן מדיד במתמטיקה, לוגיקה, דיבאגינג וניתוח מרובה חלקים. כשהמודל חושב בקול, הוא תופס את הטעויות של עצמו לפני שהוא מתחייב לתשובה. בשאלות פשוטות מדלגים על זה. שם זה רק מוסיף רעש.
פרומפט ענק אחד שמנסה לבנות מתווה, לכתוב ולסכם מאמר במעבר אחד בדרך כלל עושה את שלושתם גרוע. שרשור מפצל את זה: קודם מתווה, אחר כך טיוטה, אחר כך סיכום, ואז פוסט לרשתות, כשכל שלב מזין את הבא. זה איטי יותר, אבל קל יותר לבדוק ולתקן כל פלט בנפרד, וקל יותר לאתר תקלה כשמשהו משתבש.
ה-system prompt קובע את הכללים שהמודל עובד לפיהם לאורך כל השיחה. בדרך כלל המשתמש לא רואה אותו, והוא בעדיפות גבוהה יותר מכל מה שנאמר אחריו. ה-user prompt הוא הבקשה עצמה: גלוי, בעדיפות נמוכה יותר, ויכול להשתנות בכל הודעה.
מי שבונה משהו עם API, צ'אטבוט, כלי פנימי, אוטומציה, צריך לשים את הסטנדרטים ב-system prompt. כותבים את כללי ההתנהגות שם פעם אחת, לא בכל הודעה.
שום דבר מזה לא דורש תואר במדעי המחשב. זה דורש להתייחס לפרומפט כמו למפרט, לא כמו להצעה.