אימון מחדש של LLM: כיצד לבצע מבחן A/B ולא לטעות

בדיקות A/B של LLM: היכן נשבר האימון המשלים

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

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

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

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

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

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

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

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

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

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

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

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

מדדי הערכה: דיוק, שלמות, יציבות

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

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

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

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

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

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

דרכים לביצוע A/B-בדיקה: השוואת גישות

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

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

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

כיצד לבחור בהתאם למשימה

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

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

שלבי הטמעת בדיקות LLM

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

כיצד בנויה העבודה

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

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

מה הלקוח מקבל לידיו

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

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

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

במה שונה בדיקה אופליין מבדיקת אונליין של LLM?

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

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

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

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

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

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

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

מקרה בוחן: כיצד הפחתנו את שיעור התשובות השגויות

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

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

מה שינינו

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

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

התוצאה במדדים

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

בואו נדון במשימת בדיקת ה-LLM שלכם

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

מה שכדאי להחזיק בהישג יד לקראת הפגישה הראשונה:

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

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

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