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

Maud Nalpas

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

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

הדבר נכון גם לגבי מודלים בגדלים שונים.

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

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

מה המשמעות של 'מודעות LLM קטנות יותר'?

הגדרת הגדלים של מודלים גדולים של שפה (LLM) היא מורכבת, והיוצרים לא תמיד חושפים אותם.

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

איפה משתמשים במודלים קטנים יותר של LLM?

• AI גנרטיבי במכשיר או בדפדפן, לדוגמה, אם אתם משתמשים ב-Gemma 2B עם MediaPipe's LLM Inference API (מתאים גם למכשירים עם מעבד בלבד) או ב-DistilBert בדפדפן עם Transformers.js. אפשר להוריד מודל ולהריץ את ההסקה במכשיר של המשתמש רק באמצעות מודלים קטנים יותר של LLM, כדי שההורדות מהאינטרנט יהיו סבירות וייתאימו למגבלות הזיכרון ולמגבלות של המעבדים הגרפיים והמעבדים המרכזיים במכשיר.
• AI גנרטיבי מותאם אישית בצד השרת. מודלים קטנים בעלי משקל פתוח, כמו Gemma 2B,‏ Gemma 7B או Gemma 27B, זמינים להרצה בשרת שלכם (וניתן לשפר אותם לפי הצורך).

שנתחיל?

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

לספק הקשר והוראות פורמט מדויקות

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

לדוגמה:

Based on a user review, provide a product rating as an integer between 1 and 5. \n
Only output the integer.

Review: "${review}"
Rating:

ב-Gemini 1.5 הפלט הרצוי מתקבל באמצעות ההנחיה הפשוטה הזו, אבל הפלט של Gemma לא מספק:

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

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

לדוגמה:

`Analyze a product review, and then based on your analysis give me the
corresponding rating (integer). The rating should be an integer between 1 and
5. 1 is the worst rating, and 5 is the best rating. A strongly dissatisfied
review that only mentions issues should have a rating of 1 (worst). A strongly
satisfied review that only mentions positives and upsides should have a rating
of 5 (best). Be opinionated. Use the full range of possible ratings (1 to
5). \n\n
    \n\n
    Here are some examples of reviews and their corresponding analyses and
    ratings:
    \n\n
    Review: 'Stylish and functional. Not sure how it'll handle rugged outdoor
    use, but it's perfect for urban exploring.'
    Analysis: The reviewer appreciates the product's style and basic
    functionality. They express some uncertainty about its ruggedness but
    overall find it suitable for their intended use, resulting in a positive,
    but not top-tier rating.
    Rating (integer): 4
    \n\n
    Review: 'It's a solid backpack at a decent price. Does the job, but nothing
    particularly amazing about it.'
    Analysis: This reflects an average opinion. The backpack is functional and
    fulfills its essential purpose. However, the reviewer finds it unremarkable
    and lacking any standout features deserving of higher praise.
    Rating (integer): 3
    \n\n
    Review: 'The waist belt broke on my first trip! Customer service was unresponsive too. Would not recommend.'
    Analysis: A serious product defect and poor customer service experience naturally warrants the lowest possible rating. The reviewer is extremely unsatisfied with both the product and the company.
    Rating (integer): 1
    \n\n
    Review: 'Love how many pockets and compartments it has. Keeps everything organized on long trips. Durable too!'
    Analysis: The enthusiastic review highlights specific features the user loves (organization and durability), indicating great satisfaction with the product. This justifies the highest rating.
    Rating (integer): 5
    \n\n
    Review: 'The straps are a bit flimsy, and they started digging into my shoulders under heavy loads.'
    Analysis: While not a totally negative review, a significant comfort issue leads the reviewer to rate the product poorly. The straps are a key component of a backpack, and their failure to perform well under load is a major flaw.
    Rating (integer): 1
    \n\n
    Now, here is the review you need to assess:
    \n
    Review: "${review}" \n`;

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

ציפייה לניתוח ידני של הפלט

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

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

// Use try/catch to catch (parsing) errors
try {
  // Parse the output for a rating
  const int = /[1-5]/;
  const ratingAsString = llmOutput.match(int)[0];
  // Parse as int
  const ratingAsInt = parseInt(ratingAsString);
  // `checkRating` checks the rating is a number between 1 and 5, since the
  // regEx may catch a number like "100"
  const finalRating = checkRating(ratingAsInt);
} catch (e) {
  console.error('Error', e);
}

ההבדלים בין Mind API

ממשקי API בענן של מודלים גדולים של שפה (LLM), כמו Gemini API או OpenAI, הם בדרך כלל נקודת הכניסה למודלים גדולים יותר של LLM, ומציעים תכונות שימושיות של הנחיות. לדוגמה, ב-Gemini 1.5 Pro יש הוראות מערכת ומצב JSON.

בשלב זה, התכונות האלה לא תמיד זמינות לשימוש במודלים מותאמים אישית, או ל-LLMs קטנים יותר שאפשר לגשת אליהם באמצעות ממשקי AI בדפדפן, כמו MediaPipe LLM Inference API או Transformers.js. זו לא בהכרח הגבלה טכנית, אבל ממשקי API של AI בדפדפן נוטים להיות מצומצמים יותר.

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

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

בנוסף, במודלים קטנים יותר יש מגבלה קטנה יותר על אסימוני הקלט. לדוגמה, ל-Gemini 1.5 Pro יש מגבלה של מיליון אסימוני קלט, ולמודלים של Gemma יש חלון הקשר של 8,000 אסימונים.

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

שינוי זמן ההערכה

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

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

הנדסת הנחיות לעומת כוונון עדין?

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

כדאי להשתמש בשיפור נוסף במקרים הבאים:

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