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

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

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

תהליך העבודה של הנדסת פרומפטים

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

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

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

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

• תוכן:

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

• מבנה:

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

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

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

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

תבנית לדוגמה לפרומפט

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

      <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>
    

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

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

• הקפידו לתת הוראות ברורות וספציפיות
• הוספת דוגמאות של פרומפט עם כמה דוגמאות (few-shot)
• הוספת מידע לפי הקשר
• שימוש בהוראות מערכת
• הנחיות ליצירת מבנה
• הנחיית המודל להסביר את הרציונל שלו
• פירוק משימות מורכבות
• ניסוי עם ערכי פרמטרים
• אסטרטגיות לשיפור הנחיות

רשימת משימות לבדיקת תקינות של פרומפט

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

בעיות בכתיבה

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

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

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

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

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

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

• כדי ללמוד איך לשפר את ההנחיות לשימוש במודלים של Google, אפשר להשתמש בכלי לשיפור הנחיות ב-Gemini Enterprise Agent Platform (גרסת Preview).
• מידע על שיטות מומלצות לאתיקה של בינה מלאכותית ועל מסנני הבטיחות של Agent Platform