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

Maud Nalpas

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

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

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

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

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

מה המשמעות של "מודלים גדולים יותר של שפה (LLM)"?

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

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

איפה משתמשים במודלים גדולים יותר של שפה (LLM)?

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

אני רוצה לנסות

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

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

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

למשל:

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

בדוגמה הראשונה השתמשנו בהנחיות משרשרת מחשבה, לכן הפלט כלל גם ניתוח וגם דירוג, ואנחנו צריכים לנתח באופן ידני את הדירוג. כמו כן, שימו לב לפורמט לא עקבי בפלט של הקטע הקודם: לפעמים המודל יוצר 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 של Mind

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

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

המגבלות של אסימון Mind

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

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

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

התאמה של אומדני הזמנים

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

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

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

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

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

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