כיוונון LLM ב-DPO: יישור ללא RLHF

מדוע אימון DPO של LLM נתקע כבר בהרצה הראשונה

אימון DPO של LLM נכשל בדרך כלל לא בהרצה עצמה, אלא לפניה.

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

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

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

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

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

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

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

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

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

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

פורמטים של עבודה: מחזור מלא, ביקורת או ליווי LLM

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

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

השוואת מצבים

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

שלבי הטמעה: מביקורת נתונים ועד קבלת המודל

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

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

תוצרי היישור: מערך נתונים, קונפיגורציות, תקנונים

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

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

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

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

מקרה בוחן: יישור מודל תמיכה בלי עלייה בסירובים

לפני היישור

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

עוד 8% מהשיחות הוא סגר בתבנית "הבהר את השאלה" במקום אסקלציה, אף שהנושא היה באחריות הקו השני.

מה שינו

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

מטריקות לפני ואחרי

שיעור התשובות עם תנאים לא מהימנים: 11% → 0.4%. שיעור האסקלציות הנכונות לקו השני: 62% → 94%. זמן התשובה הראשונה לא עלה, האינפרנס נשאר על מודל אחד — לא נדרשה רשת שנייה להערכה.

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

איך להבדיל בין מערך נתונים חלש למודל שאומן מעט מדי?

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

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

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

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

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

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

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

האם באמת אפשר להחזיר גרסה אחרי יישור?

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

מה עם אבטחת השינויים והנתונים?

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

נדון במשימה: מה לשלוח ואיך נחזור עם הערכה

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

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

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