הנדסת פרומפטים

במודול בנושא AI גנרטיבי למדתם שמרחב הקלט של מודלים של AI גנרטיבי הוא כמעט בלתי מוגבל. כדי ליצור פלט שתואם לציפיות של המשתמשים, צריך לכתוב הנחיות. הנחיה היא חוזה מובנה בין האפליקציה שלכם לבין המודל.

הנחיה כתובה היטב:

• מציינת איך מודל ה-LLM צריך לבנות את התשובה שלו.
• הפתרון מורכב מכמה רכיבים שאפשר ליצור להם גרסאות, לבדוק אותם ולשפר אותם לאורך זמן.
• יכול לשמש כארטיפקט משותף לשיתוף פעולה בין צוותים.

במודול הזה תלמדו איך לכתוב הנחיות יעילות. אנחנו מסבירים איך בנויה הנחיה ואיך הרכיבים שלה מחולקים בין המערכת לבין משתמש הקצה. תלמדו גם טכניקות בסיסיות לכתיבת הנחיות ותרחישים שבהם כדאי להשתמש בכל אחת מהן.

במהלך המודול הזה נשתמש בדוגמה משותפת: BlogBuddy, עוזר כתיבה מבוסס-AI, בהשראת השימוש של CyberAgent ב-Prompt API.

חוזרים למודול של ה-AI הגנרטיבי בתוכנית האב של מערכת BlogBuddy.

רכיבי הנחיה

לכל רכיב בהנחיה יש תפקיד ספציפי בהכוונת התנהגות המודל.

• הקשר: מגדיר את התפקיד והתחום של המודל, כדי שהוא יבין איך להתנהג.
• הוראה: הקצאת משימה ספציפית למודל.
• משתני קלט: הקשר ספציפי למצב, שמסופק על ידי האפליקציה בזמן אמת.
• פורמט הפלט: הגדרה של מבנה הפלט הצפוי. לדוגמה, יכול להיות שתרצו פלט JSON.
• דוגמאות: הדגמה של אופן ביצוע המשימה עבור קלט אחד או יותר.
• אילוצים: הגדירו מגבלות ברורות כדי שהתוצאה תהיה עקבית, בטוחה ותואמת למותג.

יכול להיות שההנחיה תכלול חלק מהרכיבים האלה או את כולם. בדוגמה הבאה מוצגים הרכיבים האלה בתכונה של BlogBuddy, שמשמשת כעוזר כתיבה.

### Context

You are a writing assistant for blog authors.
Your job is to generate helpful, concise, and engaging content.

### Instruction

Generate 3 alternative titles for the user's blog post with a given style.

### Input variables

Here is the content of the blog post:
${blogPostContent}

Here is the desired style:
${titleStyle}

### Output format

Return valid JSON ONLY, in the following exact structure:
{
  "titles": ["Title option 1", "Title option 2", "Title option 3"]
}

### Examples

Example input:
{
  "blogPostContent": "I finally visited the small neighborhood café I've been eyeing for months...",
  "titleStyle": "friendly"
}

Example output:
{
  "titles": [
    "A First Visit to the Neighborhood Café",
    "Trying the Café I've Wanted to Visit for Months",
    "My Experience at a Long-Awaited Local Spot"
  ]
}
### Constraints

- Each title must be under 128 characters.
- Titles must be original, not copied verbatim from the draft.
- Keep the tone natural and human. Avoid emojis unless explicitly requested.
- Avoid sensationalism or clickbait.
- If the draft includes multiple topics, choose the most prominent topic.

בהנחיות הראשונות, כדאי להתחיל עם הדברים הבסיסיים: ההוראה ופורמט הפלט. לאחר מכן, מוסיפים עוד רכיבים באופן איטרטיבי תוך כדי ניתוח התוצאות וקביעה אילו אמצעי בקרה מדויקים יותר נדרשים להצלחה.

הנחיות מערכת לעומת הנחיות משתמש

חלק מרכיבי ההנחיה מקודדים באופן קשיח, ואחרים יכולים להיות מסופקים על ידי משתמש הקצה:

• ההנחיה למערכת מסופקת על ידי מפתחי האפליקציה ומגדירה את ההתנהגות הכוללת של המודל. אפשר להגדיר את התפקיד של המודל, את הטון הרצוי, את פורמט הפלט (למשל, סכימת JSON מדויקת) ואילוצים גלובליים. בהנחיית המערכת מקודדים גם את דרישות הבטיחות והאחריות. הוא נשאר עקבי בכל הבקשות ומספק בסיס יציב להתנהגות של המודל.

• ההנחיה למשתמש מכילה את הבקשה המיידית שמובילה לפלט. המשתמש מבקש לבצע משימה ספציפית, שיכולה לכלול משתנים ספציפיים. לדוגמה, "תציג שלוש כותרות לפוסט הזה", "תמשיך את הפסקה הזו" או "תנסח את הטקסט הזה בצורה רשמית יותר".

ברוב ממשקי ה-API של AI גנרטיבי אפשר לבנות הנחיה כמערך של הודעות, שלכל אחת מהן יש תפקיד (מערכת או משתמש) ותוכן. כך קל יותר להפריד בין הוראות יציבות וגלובליות לבין קלט דינמי לכל בקשה.

איך מחליטים אילו רכיבים צריכים להיות בהנחיית המערכת ואילו רכיבים צריך להשאיר למשתמש להגדרה? התשובה תלויה במידת הגמישות של חוויית המשתמש ובמידת היכולת של המודל.

תרחישי שימוש מוגבלים

בתרחישי שימוש ספציפיים מאוד, אפשר להגדיר מראש את רוב ההנחיה בהנחיית המערכת. לדוגמה, ב-BlogBuddy, המשתמשים יכולים ללחוץ על הצגת כותרות כדי לראות רשימה של הצעות לכותרות שנוצרו לטיוטה שלהם.

המשימה תוקנה, פורמט הפלט ידוע והמשתמש לא צריך לספק הקשר נוסף כדי לקבל את התוצאה הרצויה. במקרה הזה, אתם מציבים את כל הכללים היציבים, ההנחיות לגבי הטון, סכימות הפלט והדוגמאות בהנחיית המערכת.

כדי ליצור את זה באמצעות Prompt API, נשתמש ב-initialPrompts כדי להגדיר התנהגות ברמת המערכת לכל הסשן:

// Defines stable behavior for the entire session
const session = await LanguageModel.create({
  initialPrompts: [
    {
      role: "system",
      content: `You are a blog-writing assistant.
      Your task is to generate high-quality titles for blog posts.
      Always respond in concise, friendly language.
      Return exactly 3 alternative titles.
      Produce valid JSON with a "titles" array of strings.`
    }
  ]
});

כשהמשתמש לוחץ על הצגת כתוביות, ההצעה לפעולה מופעלת עבור התוכן הנוכחי:

// The only variable input is the blog content
const result = await session.prompt(blogContent);

עם הזמן, יכול להיות שהמשתמשים יבקשו יותר גמישות ושליטה. במקרה כזה, אפשר להעביר רכיבים מסוימים להנחיית המשתמש, באמצעות פקדים של הממשק. לדוגמה, תפריט נפתח עם מפרטים של סגנון או טון.

עם זאת, יותר מדי פעולות מובְנות עלולות להעמיס על חוויית המשתמש. במקרה כזה, כדאי לעבור לעיצוב פתוח יותר שמאפשר למשתמשים לציין בעצמם את רוב ההנחיות. מידע נוסף על אופטימיזציה של העיצוב הזה זמין במודול על תבניות UX.

משימות גמישות מסתמכות על הנחיות מפורטות מהמשתמשים

חוויה אינטראקטיבית עם אפשרויות פתוחות שעוזרת למשתמשים לכתוב פוסטים בבלוג מאפס, ומציעה למשתמשים גמישות רבה יותר. הם יכולים לבקש רעיונות, תקצירים, ניסוחים מחדש, שינויים בטון או סיעור מוחות, או לציין בדיוק איך לבצע משימה. בסוג כזה של אפליקציה, סביר להניח שתצטרכו מודל חזק יותר בצד השרת.

במשימות גמישות, המשתמש צריך לציין יותר מידע, כי טווח האפשרויות האפשריות רחב יותר. ההנחיה המערכתית עדיין קובעת את ההתנהגות הכוללת.

השיטות המומלצות הן:

• הנחיות המערכת צריכות לכלול כללים, מבנה ודוגמאות יציבים. כדאי להוסיף הנחיות למשתמש עם תוכן דינמי ובקשות ספציפיות למשימות.
• ככל שחוויית המשתמש יותר פתוחה, כך ההנחיה למשתמש צריכה להיות גמישה יותר כדי להתאים לקלט בלתי צפוי.
• ככל שההנחיה למשתמש צריכה לעשות יותר עבודה, כך המודל צריך להיות בעל יכולות גבוהות יותר, כי הוא צריך להתמודד עם וריאציות רבות יותר עם פחות מבנה מובנה.

אתם יכולים להשתמש בכללים האלה כדי לשפר בהדרגה את האיזון בין שליטה לגמישות של המשתמשים בהקשר של המוצר שלכם. חשוב לעקוב אחרי ההעדפות וההתנהגויות של המשתמשים. גמישות רבה יותר לא תמיד מתורגמת לערך בפועל. בנוסף, המשתמשים צריכים את הזמן, הכישורים והיכולת הקוגניטיבית ליצור הנחיות מפורטות יותר.

טכניקות נפוצות לכתיבת הנחיות

מפתחים בדרך כלל מנסים כמה טכניקות של הנחיות כדי למצוא את מה שהכי מתאים לתרחיש לדוגמה ולמודל שלהם.

מתן הנחיות בשיטת zero-shot

אתם מתארים למודל את המשימה ומקווים לטוב. לדוגמה:

"What is the capital of France?"

הנחיה ללא דוגמאות היא בסיס יעיל למשימות רבות של AI. במקרים של בקשות לא מורכבות, כמו שאילתות לגבי ידע אנציקלופדי, כדאי להשתמש בטכניקה הזו. עם זאת, ברוב היישומים בעולם האמיתי, צריך להרחיב את ההנחיה עם תנאים ולוגיקה נוספים.

הנחיה עם כמה דוגמאות (Few-shot)

בשיטת ה-few-shot prompting, מספקים דוגמאות כדי להמחיש את ההתנהגות הנכונה, הסגנון, המבנה ומשתנים חשובים אחרים. דוגמה להנחיה לסיווג סנטימנט:

You classify user messages into one of the following categories:
- "positive"
- "negative"
- "neutral"
Here are examples to guide your classifications:
Input: "I love this product! It works perfectly."
Output: { "label": "positive" }

Input: "This is terrible. I want a refund."
Output: { "label": "negative" }

הנחיה עם כמה דוגמאות (Few-shot) שימושית למשימות מהסוג הזה של חיזוי פסאודו. אפשר להשתמש בו גם למשימות שמתבססות על מבנה מוכר, כמו יצירת כותרת באיור 1.

אם מרחב הפלט רחב מאוד, למשל תוכן פתוח או תוכן ארוך, סביר להניח שהנחיה עם כמה דוגמאות היא לא הטכניקה הכי טובה. קשה או אפילו בלתי אפשרי לספק דוגמאות שמכסות את המרחב בצורה משמעותית.

הנחיות בטכניקת שרשור מחשבות

אתם מעודדים את המודל לנמק שלב אחר שלב לפני שהוא מייצר תשובה. אפשר לתאר את השלבים באופן מפורש, או להשאיר את ההגדרה שלהם למודל. לדוגמה:

"Think step-by-step to identify the main idea of this paragraph. Then produce a
short heading under 60 characters."

השיטה 'שרשרת מחשבות' מתאימה במיוחד למשימות שדורשות הסקת מסקנות וביצוע בכמה שלבים, כמו יצירת תקציר לפוסט בבלוג או תמיכה בהחלטות מורכבות. זו הטכניקה העיקרית שמאחורי מה שנקרא מודלים של נימוקים.

הפעולה הזו יכולה להיות יקרה. יצירת עקבות של נימוקים מפורטים מגדילה את השימוש במחשוב, את העלות ואת זמן האחזור. כדאי להשתמש בו רק כשצריך נימוקים ותכנון מורכבים בתרחיש השימוש.

הנחיות לעידוד רפלקציה עצמית

אחרי היצירה הראשונית, אתם מבקשים מהמודל לבקר את הפלט שלו ולשנות אותו. לדוגמה:

"Review your previous output.
Identify unclear phrasing and rewrite it more concisely."

ההשתקפות העצמית שימושית במיוחד למשימות שמועילות משיפור איטרטיבי, כמו עריכה או כתיבה מחדש של כלים. קל ליישם אותו והוא יכול לשפר משמעותית את איכות התוכן. אחרי שההנחיה מניבה תוצאות טובות, כדאי להשתמש בלולאת חשיבה על 'איך המרגש?'. קודם כול, אפשר לשפר את הפלט כדי שיהיה ברור יותר או כדי להוסיף הנאה למשתמש.

התובנות שלכם

במודול הזה למדתם איך הנחיות בנויות מרכיבים מובנים. בפועל, הנדסת פרומפטים היא תהליך ניסיוני מאוד. הבהירות והאמינות מתקבלות רק אחרי כמה סבבים של שיפורים.

במודול הבא נסביר על פיתוח הנחיות שמבוסס על הערכה. השיטה הזו עוזרת לשפר באופן שיטתי את ההנחיות ולהגיע להנחיות שהכי מתאימות למוצר ולמשתמשים שלכם.

משאבים

לכל אחת מהטכניקות האלה יש וריאציות ושיטות מומלצות משלה. יש מגוון רחב של מקורות מידע חיצוניים מפורטים, למשל:

• מדריך למהנדסי הנחיות של Google Cloud
• מדריך הנדסת ההנחיות של DAIR
• הנחיות פשוטות מאת Janna Lipenkova
• כדאי לקרוא את פרק 6 בספר The Art of AI Product Development (אומנות פיתוח מוצרים מבוססי-AI).

כדאי לעיין בתיעוד של המודל שבחרתם, כי יכול להיות שיש בו עצות ספציפיות שיעזרו לכם להפיק את התוצאות הכי טובות.

בדיקת ההבנה