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

Maud Nalpas

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

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

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

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

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

מה הכוונה במונח 'מודלים קטנים יותר של LLM'?

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

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

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

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

שנתחיל?

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

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

כדי לקבל תוצאות אופטימליות ממודלים קטנים של 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`;

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

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

תמיד צריך לנקות ולפרש את הפלט של מודל 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);
}

הבדלים בין ממשקי API

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

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

שימו לב למגבלות הטוקנים

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

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

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

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

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

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

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

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

כדאי להשתמש בכוונון עדין כשרוצים:

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