סקירה כללית של אסטרטגיות למתן הנחיות

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

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

תהליך העבודה של הנדסת הנחיות

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

בתרשים הבא מוצג תהליך העבודה של הנדסת הנחיות:

תרשים זרימה של תהליך הנדסת ההנחיות

איך כותבים הנחיה אפקטיבית

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

  • תוכן:

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

  • מבנה:

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

רכיבים של הנחיה

בטבלה הבאה מפורטים הרכיבים העיקריים והאופציונליים של הנחיה:

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

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

הוראות מערכת זמינות ב-Gemini 2.0 Flash ובמודלים מתקדמים יותר.

 אתה מומחה לקידוד שמתמחה בהצגת קוד לממשקי קצה. כשאתאר רכיב באתר שאני רוצה לבנות, תכתוב את קוד ה-HTML וה-CSS שנדרש כדי לעשות את זה. אל תספק הסבר לקוד הזה. בנוסף, מציעים כמה הצעות לעיצוב ממשק המשתמש.
פרסונה מי או מה המודל מייצג. נקרא גם "תפקיד" או "חזון". אתה מורה פרטי למתמטיקה, ואתה כאן כדי לעזור לתלמידים בשיעורי הבית שלהם במתמטיקה.
מגבלות הגבלות על מה שהמודל צריך לפעול לפיהן כשהוא יוצר תגובה, כולל מה המודל יכול לעשות ומה הוא לא יכול לעשות. נקרא גם 'כללי התנהגות', 'גבולות' או 'אמצעי בקרה'. אל תתנו לתלמידים את התשובה ישירות. במקום זאת, תן רמזים לגבי השלב הבא לפתרון הבעיה. אם התלמיד או התלמידה לא מבינים מה לעשות, כדאי לתת להם הסבר מפורט על פתרון הבעיה.
טון הטון של התשובה. אפשר גם להשפיע על הסגנון והטון על ידי הגדרת פרסונה. נקרא גם "סגנון", "קול" או "אווירה". תענה בצורה לא רשמית ומקצועית.
הקשר כל מידע שהמודל צריך להתייחס אליו כדי לבצע את המשימה. נקרא גם 'רקע', 'מסמכים' או 'נתוני קלט'. עותק של מערכי השיעור של התלמיד/ה במתמטיקה.
דוגמאות עם מעט נתונים דוגמאות לאופן שבו התשובה צריכה להיראות עבור הנחיה מסוימת. נקרא גם "דוגמאות" או "דוגמאות מייצגות". input: אני מנסה לחשב כמה כדורי גולף יכולים להיכנס לקופסה בנפח של מטר מעוקב אחד. המרתי מטר מעוקב אחד לסנטימטרים מעוקבים וחילקתי אותו בנפח של כדור גולף בסנטימטרים מעוקבים, אבל המערכת אומרת שהתשובה שלי שגויה.
output: כדורי גולף הם כדורים, ואי אפשר לארוז אותם במרחב בצורה יעילה לחלוטין. output: החישובים שלכם מתבססים על יעילות האריזה המקסימלית של כדורים.
שלבי הסקת מסקנות מבקשים מהמודל להסביר את החשיבה הרציונלית שלו. לפעמים זה משפר את יכולת ההסקה של המודל. נקרא גם 'שלבי חשיבה'. הסבר את הבסיס למשוב שלב אחרי שלב.
פורמט התשובה הפורמט שבו רוצים שהתשובה תהיה. לדוגמה, אפשר להנחות את המודל ליצור פלט של התשובה בפורמט JSON, טבלה, Markdown, פסקה, רשימה עם תבליטים, מילות מפתח, נאום מכירות קצר וקולע וכו'. נקרא גם 'מבנה', 'הצגה' או 'פריסה'. התשובה צריכה להיות בפורמט Markdown.
סיכום בסוף ההנחיה, חזרה תמציתית על הנקודות העיקריות של ההנחיה, במיוחד על האילוצים ועל פורמט התשובה. אל תגלה את התשובה, אלא תיתן רמזים. תמיד תעצב את התשובה שלך בפורמט Markdown.
אמצעי הגנה השאלות מבוססות על המשימה של הבוט. נקראים גם 'כללי בטיחות'. לא רלוונטי

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

תבנית הנחיה לדוגמה

בתבנית ההנחיה הבאה מוצגת דוגמה להנחיה מובנית היטב:

      <OBJECTIVE_AND_PERSONA>
      You are a [insert a persona, such as a "math teacher" or "automotive expert"]. Your task is to...
      </OBJECTIVE_AND_PERSONA>

      <INSTRUCTIONS>
      To complete the task, you need to follow these steps:
      1.
      2.
      ...
      </INSTRUCTIONS>

      ------------- Optional Components ------------

      <CONSTRAINTS>
      Dos and don'ts for the following aspects
      1. Dos
      2. Don'ts
      </CONSTRAINTS>

      <CONTEXT>
      The provided context
      </CONTEXT>

      <OUTPUT_FORMAT>
      The output format must be
      1.
      2.
      ...
      </OUTPUT_FORMAT>

      <FEW_SHOT_EXAMPLES>
      Here we provide some examples:
      1. Example #1
          Input:
          Thoughts:
          Output:
      ...
      </FEW_SHOT_EXAMPLES>

      <RECAP>
      Re-emphasize the key aspects of the prompt, especially the constraints, output format, etc.
      </RECAP>

שיטות מומלצות

שיטות מומלצות לעיצוב הנחיות כוללות:

רשימת משימות לבדיקת תקינות ההנחיה

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

בעיות בכתיבה

  • שגיאות הקלדה: כדאי לבדוק מילות מפתח שמגדירות את המשימה (לדוגמה, sumarize במקום summarize), מונחים טכניים או שמות של ישויות, כי שגיאות איות עלולות להוביל לביצועים נמוכים.
  • דקדוק: אם קשה לנתח משפט, אם הוא מכיל מקטעים ארוכים מדי, אם הנושא והפועל לא תואמים או אם הוא נשמע מוזר מבחינה מבנית, יכול להיות שהמודל לא יבין את ההנחיה כמו שצריך.
  • פיסוק: חשוב לבדוק את השימוש בפסיקים, בנקודות, במירכאות ובמפרידים אחרים, כי פיסוק שגוי עלול לגרום למודל לפרש את ההנחיה בצורה שגויה.
  • שימוש בז'רגון לא מוגדר: אל תשתמשו במונחים ספציפיים לתחום, בראשי תיבות או בקיצורים כאילו יש להם משמעות אוניברסלית, אלא אם הם מוגדרים במפורש בהנחיה.
  • בהירות: אם אתם לא בטוחים מה היקף הפעולה, מהם השלבים הספציפיים שצריך לבצע או מהן ההנחות המובלעות, סביר להניח שההנחיה לא ברורה.
  • דו-משמעות: אל תשתמשו במונחים סובייקטיביים או יחסיים שאין להם הגדרה קונקרטית ומדידה. במקום זאת, כדאי לספק אילוצים אובייקטיביים (לדוגמה, "כתוב סיכום של 3 משפטים או פחות" במקום "כתוב סיכום קצר").
  • חסר מידע חשוב: אם כדי לבצע את המשימה נדרש ידע על מסמך ספציפי, על מדיניות החברה, על היסטוריית המשתמש או על מערך נתונים, חשוב לוודא שהמידע הזה נכלל באופן מפורש בהנחיה.
  • בחירת מילים לא טובה: כדאי לבדוק אם ההנחיה מכילה ניסוח מורכב, מעורפל או מפורט מדי, כי זה עלול לבלבל את המודל.
  • בדיקה משנית: אם הביצועים של המודל ממשיכים להיות נמוכים, כדאי לבקש מאדם אחר לבדוק את ההנחיה.

בעיות בהוראות ובדוגמאות

  • מניפולציה גלויה: צריך להסיר מההנחיה טקסט שלא קשור למשימה העיקרית, שמנסה להשפיע על הביצועים באמצעות פנייה לרגשות, חנופה או לחץ מלאכותי. בעוד שמודלים בסיסיים מהדור הראשון הראו שיפור בנסיבות מסוימות עם הוראות כמו 'דברים רעים מאוד יקרו אם לא תבצע את זה בצורה נכונה', הביצועים של המודלים הבסיסיים לא ישתפרו יותר, ובמקרים רבים הם יורעו.
  • הנחיות ודוגמאות סותרות: כדי לבדוק אם יש סתירות לוגיות או חוסר התאמה בין ההנחיות או בין ההנחיה לדוגמה, צריך לבדוק את ההנחיה.
  • הוראות ודוגמאות מיותרות: בודקים את ההנחיה ואת הדוגמאות כדי לראות אם אותה הוראה או אותו מושג מופיעים כמה פעמים בניסוחים שונים, בלי להוסיף מידע או ניואנסים חדשים.
  • הוראות ודוגמאות לא רלוונטיות: צריך לבדוק אם כל ההוראות והדוגמאות חיוניות למשימה העיקרית. אם אפשר להסיר הוראות או דוגמאות בלי לפגוע ביכולת של המודל לבצע את המשימה העיקרית, יכול להיות שהן לא רלוונטיות.
  • שימוש בדוגמאות "few-shot" ‎: אם המשימה מורכבת, דורשת פורמט ספציפי או שיש לה ניואנסים, חשוב לכלול דוגמאות קונקרטיות וממחישות שמציגות קלט לדוגמה ואת הפלט המתאים.
  • לא צוין פורמט פלט: אל תתנו למודל לנחש את מבנה הפלט. במקום זאת, השתמשו בהוראה ברורה ומפורשת כדי לציין את הפורמט, והציגו את מבנה הפלט בדוגמאות שלכם.
  • הגדרת תפקיד חסרה: אם אתם מבקשים מהמודל לפעול בתפקיד ספציפי, ודאו שהתפקיד הזה מוגדר בהוראות המערכת.

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

  • משימה לא מוגדרת מספיק: חשוב לוודא שההוראות בהנחיה מספקות דרך ברורה לטיפול במקרים חריגים ובקלט לא צפוי, ושהן מספקות הוראות לטיפול בנתונים חסרים במקום להניח שהנתונים שנוספו תמיד יהיו נוכחים ומעוצבים היטב.
  • משימה שחורגת מהיכולות של המודל: אל תשתמשו בהנחיות שמבקשות מהמודל לבצע משימה שיש לו מגבלה ידועה ומהותית לגביה.
  • יותר מדי משימות: אם ההנחיה מבקשת מהמודל לבצע כמה פעולות קוגניטיביות נפרדות במעבר אחד (לדוגמה, 1. סיכום, 2. חילוץ ישויות, 3. תרגום, ו-4. לנסח אימייל), סביר להניח שהוא מנסה לעשות יותר מדי. מפצלים את הבקשות להנחיות נפרדות.
  • פורמט נתונים לא סטנדרטי: אם הפלט של המודל צריך להיות קריא למכונה או להיות בפורמט ספציפי, כדאי להשתמש בפורמט סטנדרטי מוכר כמו JSON,‏ XML, ‏ Markdown או YAML שאפשר לנתח באמצעות ספריות נפוצות. אם תרחיש השימוש שלכם דורש פורמט לא סטנדרטי, כדאי לבקש מהמודל ליצור פלט בפורמט נפוץ ואז להשתמש בקוד כדי להמיר את הפלט.
  • סדר שגוי של שרשרת מחשבות (CoT): אל תספקו דוגמאות שבהן המודל יוצר את התשובה הסופית והמובנית לפני שהוא משלים את החשיבה הרציונלית שלב אחר שלב.
  • חשיבה לעומת חשיבה רציונלית: אם אתם משתמשים בחשיבה, נסו לתת הנחיה בלי הוראות מפורטות לגבי האופן שבו המודל צריך לחשוב באופן רציונלי לגבי המשימה. במקום זאת, כדאי לבדוק אם הסתמכות על Thinking וההסברים המפורטים ש-Thinking יוצרת משפרים את הביצועים בהשוואה להוראות המפורטות שאתם נותנים.
  • הפניות פנימיות סותרות: אל תכתבו הנחיה עם לוגיקה לא לינארית או עם תנאים שמחייבים את המודל להרכיב הוראות מקוטעות מכמה מקומות שונים בהנחיה.
  • סיכון להחדרת הנחיות: צריך לבדוק אם יש אמצעי הגנה מפורשים סביב קלט של משתמשים לא מהימן שמוחדר להנחיה, כי זה יכול להיות סיכון אבטחה משמעותי.

המאמרים הבאים