כיוונון עדין (Fine-Tuning) של מודל השפה Gemini (Google)

כשמודל הבסיס טועה: לשם מה נחוץ fine-tuning של Gemini

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

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

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

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

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

מה משתנה אחרי אימון נוסף: דיוק, פורמט, נפח הפרומפטים

אימון נוסף משנה לא את ה"אינטליגנציה הכללית" של המודל אלא את התנהגותו על מחלקה צרה של משימות.

את האפקט אנו מודדים על מדגם מושהה של פניות אמיתיות: שיעור התשובות הנכונות על ניסוחים בתחום עולה מ-60–70% ל-90% ומעלה, וכשלים אופייניים — החלפת מונחים, הסתייגויות מיותרות, סעיפים מומצאים — מצטמצמים למקרים בודדים.

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

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

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

דרכי התאמת המודל למשימה: השוואת גישות

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

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

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

שלבי העבודה על fine-tuning של Gemini: מביקורת נתונים ועד מסירה

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

1. ביקורת המשימה והנתונים. מפרקים אילו שגיאות של המודל קריטיות לעסק, ובודקים אם בכלל נדרשת ריצת אימון נוסף או שהמשימה נסגרת בהוראות ובחיפוש בבסיס הידע.
2. תכנית האימון הנוסף. מגדירים את מצב ההתאמה לפי היקף ואופי הנתונים, את פורמט הרשומות "שאילתה — תשובת ייחוס", את מטריקות הקבלה ואת כללי חלוקת הקורפוס.
3. הכנת סט הדוגמאות. מנקים כפילויות וסתירות, מאזנים את התיוג, מסירים נתונים אישיים. את המדגם המושהה יוצרים מראש ואינם מראים למודל באף אחד משלבי האימון.
4. אימון עם בקרת התאמת יתר. ברגע שהאיכות על חלק הבקרה מפסיקה לעלות, הריצה נעצרת ולא נדחקת עד השלמות על דוגמאות האימון — אחרת המודל מאבד גמישות.
5. בדיקה על מדגם מושהה. מחשבים מטריקות לפי מחלקות שגיאה ומשווים למודל הבסיס. בודקים לא רק את שיעור התשובות הנכונות, אלא גם את יציבות הניסוחים, שמירת הסגנון והיעדר עובדות מומצאות.
6. מסירה. מוסרים את המודל המכוונן, את תכנית החיבור שלו, את סט הבדיקות ואת הדוח עם המטריקות, כדי שהמהנדסים שלכם יוכלו לשחזר את הבדיקה בכוחות עצמם.
7. תקנון עדכון המודל. מתארים כיצד למלא את סט הדוגמאות מפניות אמיתיות, מתי להריץ מחדש את האימון וכיצד לחזור לגרסה קודמת אם האיכות ירדה.

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

ערכת המסירה: מערכי נתונים, הגדרות, תקנונים

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

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

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

מקרה בוחן: שיעור התשובות השגויות ירד מ-38% ל-6%

מה היה

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

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

מה שינו ומה קיבלו

אספנו מדגם אימון משיחות שנצברו ותייגנו אותו לפי תשובות ייחוס: בנפרד תקינות, בנפרד כאלה שנדחו בידי המפעילים. על נתונים אלה ביצענו אימון נוסף (fine-tuning) של המודל.

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

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

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

במה שונה אימון נוסף מהוראות בפרומפט ומבסיס ידע?

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

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

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

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

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

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

ספקות טכניים: נתונים, אבטחה, נסיגת גרסה

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

מי וכיצד מתייג את הדוגמאות?

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

כיצד מבודדים נתונים רגישים?

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

האם התוצאה משוחזרת וכיצד לחזור לגרסה קודמת?

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

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

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

• מטרה במונחי תוצאה: מה המודל צריך לעשות אחרת מאשר כעת, וכיצד אתם מודדים זאת — ידנית או בבדיקה אוטומטית.
• 50–200 דוגמאות חיות "קלט → תשובה מצופה" בדיוק בצורה שבה הן מגיעות מהמערכת שלכם.
• מקור הנתונים: האם יש תיוג, מי מחברו, כיצד נפתרת התנגשות בין כניסות זהות עם תשובות שונות.
• התצורה הנוכחית: איזה ענף של Gemini בשימוש, עם אילו פרמטרי יצירה ותיאור מערכת של ההתנהגות.
• מגבלות על הפלט: שדות חובה בתשובה, ניסוחים אסורים, דרישות לשפה ולטון.
• תרחיש הקבלה: סט הדוגמאות שתקבלו עליו את העבודה ושיעור השגיאות המותר עליו.
• תנאי ההפעלה: היכן המודל עובד, איזה נפח פניות מחזיק והאם יש דרישות לזמן התשובה.

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