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

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

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

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

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

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

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

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

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

  • תוכן:

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

  • מבנה:

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

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

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

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

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

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

 אתה מומחה בכתיבת קוד שמתמחה בהצגת קוד לממשקי קצה. כשאתאר רכיב באתר שאני רוצה לבנות, תכתוב את קוד ה-HTML וה-CSS שנדרש כדי לעשות את זה. אל תספק הסבר לקוד הזה. תציע גם כמה הצעות לעיצוב ממשק המשתמש.
פרסונה מי או מה המודל מייצג. נקרא גם "תפקיד" או "חזון". אתה מורה פרטי למתמטיקה, ואתה כאן כדי לעזור לתלמידים בשיעורי הבית שלהם במתמטיקה.
מגבלות הגבלות על מה שהמודל צריך לפעול לפיהן כשהוא יוצר תגובה, כולל מה המודל יכול לעשות ומה הוא לא יכול לעשות. נקרא גם "גבולות" או "אמצעי בקרה". אל תתנו לתלמידים את התשובה ישירות. במקום זאת, תן רמזים לגבי השלב הבא לפתרון הבעיה. אם התלמיד או התלמידה לא מבינים מה לעשות, כדאי לתת להם את השלבים המפורטים לפתרון הבעיה.
טון הטון של התשובה. אפשר גם להשפיע על הסגנון והטון על ידי ציון פרסונה. נקרא גם "סגנון", "קול" או "אווירה". תענה בצורה לא רשמית וטכנית.
הקשר כל מידע שהמודל צריך להתייחס אליו כדי לבצע את המשימה. נקרא גם 'רקע', 'מסמכים' או 'נתוני קלט'. עותק של מערכי השיעור של התלמיד/ה במתמטיקה.
דוגמאות עם מעט נתונים דוגמאות לאופן שבו התשובה צריכה להיראות להנחיה מסוימת. נקראים גם "דוגמאות" או "דוגמאות מייצגות". input: אני מנסה לחשב כמה כדורי גולף יכולים להיכנס לקופסה בנפח של מטר מעוקב אחד. המרתי מטר מעוקב אחד לסנטימטרים מעוקבים וחילקתי אותו בנפח של כדור גולף בסנטימטרים מעוקבים, אבל המערכת אומרת שהתשובה שלי שגויה.
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): אל תספקו דוגמאות שבהן המודל יוצר את התשובה הסופית והמובנית לפני שהוא מסיים את ההסקה שלב אחר שלב.
  • חשיבה לעומת חשיבה רציונלית: אם אתם משתמשים בחשיבה, נסו לתת הנחיה בלי הוראות מפורטות לגבי האופן שבו המודל צריך להסיק מסקנות לגבי המשימה. במקום זאת, כדאי לבדוק אם הסתמכות על 'חשיבה' ועל ההסברים המפורטים שנוצרים באמצעותה משפרים את הביצועים בהשוואה להוראות המפורטות שאתם נותנים.
  • הפניות פנימיות מתנגשות: אל תכתבו הנחיה עם לוגיקה לא לינארית או עם תנאים שמחייבים את המודל להרכיב הוראות מקוטעות מכמה מקומות שונים בהנחיה.
  • סיכון של החדרת הנחיות: צריך לבדוק אם יש אמצעי הגנה מפורשים סביב קלט של משתמשים לא מהימן שמוחדר להנחיה, כי זה יכול להיות סיכון אבטחה משמעותי.

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