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

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, כדי שההורדות באינטרנט יהיו סבירות וכדי להתאים למגבלות הזיכרון ומעבדי ה-GPU או המעבד (CPU) של המכשיר.
• 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, שעשויים לספק תוצאות פחות מבריקות ועשויים לדרוש הנחיות לגבי רצף המחשבות.

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

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

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

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

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

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

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

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

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

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

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

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

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

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