מדוע הערכת איכות LLM נשברת לאחר שחרור
מערכי דוגמאות אופליין והתעבורה האמיתית מתפצלים כמעט תמיד. במדגם סגור המדדים נראים יציבים, אבל בפרודקשן התפלגות השאילתות שונה: הבהרות קצרות, שפות מעורבות, קטעי הקשר, קבצים מצורפים.
הערכת איכות LLM לפי ציון ממוצע לא תופסת זאת — המודל עונה בביטחון במקום שבו בעבר אמר בכנות "לא יודע".
הגרוע מכל הוא שהשינויים מגיעים אחד-אחד. תיקון ניסוח בפרומפט המערכת, החלפת גרסת מודל, כלי חדש בשרשרת הקריאות — והרגרסיות לאחר עדכון הפרומפטים מופיעות לא בתרחיש שנגעתם בו, אלא בתרחיש סמוך. אף אחד לא בודק מחדש את כל מטריצת התרחישים לאחר כל תיקון כזה, לכן הזיות בפרודקשן צפות לאחר ימים.
הסחיפה בתשובות המודל מצטברת לאט יותר, אבל באותה מידה מבלי לשים לב: ספק חיצוני מעדכן את המודל בצד שלו, והניסוחים, פורמט התשובה, הנכונות לפעול לפי ההוראות משתנים בלי שום עריכה בצד שלנו.
בדיקות מדגמיות ידניות לא עוזרות כאן — מהנדס עובר פיזית על עשרות שיחות, בעוד שביממה יש אלפים, והמדגם מוטה לפניות שכבר נכתבו עליהן לתמיכה.
בסופו של דבר, הראשון שמבחין בתקלה הוא הלקוח. הוא מקבל קישור שגוי, מספר מומצא או סירוב במקום שבו קודם הייתה תשובה, ומאבד אמון במוצר כולו, ולא בתרחיש בודד. אנו מפרטים כיצד זה נסגר: באמצעות הערכה רציפה, שתופסת פערים לפני שהם מגיעים למשתמש.
הערכה אוטומטית של תשובות במקום ריצות ידניות
ריצות ידניות מתרחבות באופן ליניארי: לבדוק גרסה חדשה של פרומפט על מאתיים שיחות — זה יום עבודה של מומחה, ועד לרגע הניתוח חלק מהתשובות כבר לא מתאימות לקונפיגורציה הנוכחית.
מעגל בדיקות קבוע מסיר את הליניאריות הזו: חלק מההחלטות נלקחות על ידי האוטומציה, והאדם מנתח רק מקרים שנויים במחלוקת.
כמה עבודה ידנית יוצאת מהתהליך
אוטומציה של בדיקות תשובות מבוססת על קריטריונים חד-משמעיים: התשובה נשענת על המקור, אינה ממציאה עובדות, שומרת על הטון שהוגדר, אינה חושפת הוראות פנימיות. ברגע שנוסחו, הם מיושמים על כל ריצה באופן זהה — מומחים שונים מפסיקים לפרש נכונות באופן אישי.
הצמצום בתיוג הידני נעשה על ידי סינון מקרים ברורים: האוטומציה מסמנת בעצמה תשובות עם דמיון גבוה לתקן ומעלה למעלה את אלו שבהן הפער משמעותי. לבן אדם נשארת עשירית מהמדגם — שיחות גבוליות ושנויות במחלוקת.
תוך כמה זמן נתפסת רגרסיה
Braintrust שומר היסטוריית ריצות, לכן מערך תשובות חדש מושווה לקודם מיד לאחר ההרכבה: מדדים לפי קריטריונים אחידים של נכונות מחושבים אוטומטית, והנפילה נראית בדוח ללא השוואה ידנית.
מהירות גילוי הרגרסיות נמדדת בדקות: תיקון פרומפט או החלפת מודל מורצים על שיחות היסטוריות ונותנים תשובה לפני השחרור, ולא אחרי שבוע של שימוש. הפערים מתועדים לפי שיחות ספציפיות — סיבת הנסיגה נראית ללא חקירה חוזרת.
אפשרויות מעגל הבדיקות: השוואת גישות
מעגל בדיקות הוא מדדים, מערכי נתונים וכללי תיוג, שעונים על השאלה האם איכות התשובות השתפרה לאחר תיקון המודל או ניסוח השאילתה. מרכיבים אותו בשלוש דרכים, והבחירה תלויה לא בגודל הצוות, אלא בתדירות שבה משתנים התרחישים ובמי שמשתתף בתיוג.
| אפשרות | מתי מתאים | מגבלות |
|---|---|---|
| מעגל בהתאמה אישית על ספריות הערכה פתוחות | מדדים סטנדרטיים, תיוג על ידי הצוות | השוואת ריצות וגרסאות של מערכים חיה בסקריפטים עזר, התמיכה גדלה |
| פלטפורמה חיצונית להערכת תשובות | יש צורך בהיסטוריית ריצות, שחזור, עבודה משותפת | חלק מהנתונים עוברים למעגל חיצוני, יש צורך בייצוא מדדים בחזרה |
| סכימת בדיקות היברידית | אוטומציה בכמויות, תיוג מומחים נקודתי | דורש פורמט אחיד למערכי נתונים וגרסת כללים |
מתי ספריות פתוחות מספיקות
אם המשימות אחידות — סיווג, חילוץ שדות, בדיקת פורמט תשובה — ספריות פתוחות מספיקות. המדדים מחושבים מקומית, מערך הנתונים נמצא ליד הקוד, הריצה מופעלת על כל שינוי. המעגל שקוף: רואים איזו פונקציה מחשבת איזה מדד. הגבול מגיע במדגם השני המתויג, כאשר השוואת תוצאות של שתי ריצות ידנית כבר לא נוחה.
מתי נדרש מעגל חיצוני נפרד
מעגל נפרד נדרש כאשר חשובים שחזור ותיוג על ידי מספר אנשים. Braintrust שומר גרסאות של מערכי נתונים ומדדים, לכן הוויכוח "האם נעשה גרוע יותר או שזה נדמה" נסגר בהפניה לריצה ספציפית, ולא בהרצה חוזרת של סקריפטים.
ההיבריד מסיר את הפשרה: בדיקות אוטומטיות נשארות במאגר, והערכות מומחים והשוואת גרסאות — במעגל החיצוני.
שלבי הטמעה: מביקורת תרחישים ועד לתקנון
אנו בונים את מעגל הבדיקות כך שכל תיקון פרומפט או מודל יעבור את אותו מערך בדיקות והתוצאה תהיה ניתנת להשוואה לריצה הקודמת. להלן סדר העבודות: מניתוח תרחישים ועד לתקנון, שלפיו הלקוח ממשיך לעבוד בעצמו.
ביקורת והגדרת קריטריונים
מתחילים בביקורת תרחישים של העוזר: מייצאים שיחות אמיתיות ומתייגים היכן התשובה סטתה — אובדן הקשר, עובדות מומצאות, טון שגוי. מתוך רשימה זו גדלים קריטריונים לנכונות התשובה: עבור כל תרחיש מתעדים מה נחשב לנכון, מה לסטייה מותרת, ומה לפגם.
- מפרקים תרחישים ומסווגים שגיאות לפי סוגים — מקבלים רשימה של מה שצריך לבדוק בכלל.
- מנסחים קריטריונים לנכונות: עובדות חובה, ניסוחים מותרים, איסורים בתשובה.
- מרכיבים מערך בדיקות — שאלות עם תשובות תקן ובדיקות אוטומטיות לפורמט ובלוקים מחייבים.
בדיקה על נתונים היסטוריים והשקה
אי אפשר לקבל את מערך הבדיקות כמובן מאליו, לכן מריצים אותו על נתונים היסטוריים ומשווים לתיוג ידני. אם ההערכה האוטומטית חולקת על הערכת המומחה לעתים תכופות יותר מהחלק המוסכם של המקרים, אנו כותבים את הכלל מחדש.
- מריצים את המעגל על שיחות מצטברות ומשווים לתיוג ידני.
- מגדירים ריצות קבועות ב-Braintrust על כל שינוי בפרומפט או במודל; בדוח — דינמיקה לפי כל קריטריון.
- משיקים את מעגל הבדיקות למצב עבודה ומוסרים תקנון: כיצד להוסיף בדיקות, כיצד לקרוא את הדוח, באיזו נפילה לבטל שינוי.
מה מוסרים לידיים: בדיקות, סכמות, תקנונים
אנו מוסרים לא תיקייה עם הגדרות, אלא מעגל הערכת איכות עובד: מהנדס מפעיל ריצה וקורא את הדוח, בלי להתעמק בלוגיקה זרה. החבילה כוללת:
- מערכי בדיקות לפי תרחישים — שיחת תמיכה, סיכום, חילוץ שדות; לכל אחד מערך משלו של דוגמאות תקן ומדד שלפיו מחושבת האיכות.
- סכמת מעגל הבדיקות: היכן נמצאים התקנים, כיצד מתבצעת הריצה, כיצד התוצאות מגיעות לדוחות ואילו נתונים נדרשים לשם כך.
- כללי תיוג למקרים שנויים במחלוקת: מה נחשב לנכון בתשובה דו-משמעית, מי פותר קונפליקט בין מתייגים וכיצד ההחלטה מתועדת.
- דוחות והתראות על נפילת מדדים: ספים, ערוץ התראה, סדר פעולות התורן וסימן להתראת שווא.
- תקנון עדכון מודלים: ריצה מחייבת על מערך קבוע לפני החלפת גרסה, קריטריוני קבלה ותנאי נסיגה.
- מטריצת הרשאות ותפקידים: מי עורך את התקנים, מי — את כללי התיוג, מי רואה רק דוחות.
תיעוד וכללי תיוג
אנו מתארים את המעגל כך שמהנדס חדש ירכיב ריצה לפי ההוראות: ייעוד כל מערך, פורמט התקנים, ניתוח שגיאות אופייניות של המתייג. מקרים שנויים במחלוקת מרכזים בטבלה "מצב — החלטה — הנמקה": היא מסירה את רוב השאלות, בלי צורך לפנות אלינו.
מה כבר מוגדר במעגל שלכם
המעגל מורכב על Braintrust ומקושר למאגר שלכם: הריצה מופעלת מהענף, התוצאה מושווית לשחרור הקודם, ירידת מדד מתחת לסף עוברת לערוץ הצוות. תרחיש חדש מתווסף בקובץ תקנים אחד ורשומה אחת בקונפיגורציה — בלי עריכות בקוד הבדיקות.
מקרה בוחן: צמצום שגיאות בעוזר תמיכה
העוזר בקו הראשון השיב לפניות אופייניות לפי בסיס הידע והעביר מקרים מורכבים לנציג. ההוראות למודל והמודל עצמו התעדכנו מדי כמה שבועות, והאיכות נבדקה ידנית: נציגים קראו מדגם של שיחות והחליטו.
בהיקף הפניות זה הפסיק לעבוד — המדגם כיסה חלק קטן מהתרחישים, ותשובות שנויות במחלוקת הוערכו באופן שונה על ידי בודקים שונים.
מה היה לפני ההטמעה
שיעור התשובות השגויות עמד על כ-12%: העוזר התבלבל בתנאי החזרה, הפנה לסעיפים מיושנים בבסיס הידע והשיב בביטחון במקום שבו היה צורך בהעברה לנציג. בדיקה ידנית של שחרור ארכה 3-4 ימים — שיחות תקן הועברו בעיניים, והעדכון חיכה לפסיקה. ברבעון שתי רגרסיות עברו לפרודקשן: הן התגלו מתלונות, כשעלה שיעור ההסלמות לנציגים.
מה השתנה אחרי
הרכבנו מעגל בדיקות על Braintrust: מערך תקן של שיחות עם תיוג, הערכות אוטומטיות לפי קריטריונים — שלמות התשובה, עמידה על המקור, תקינות ההסלמה, היעדר תנאים מומצאים.
הריצה מופעלת על כל שינוי בהוראות או במודל, וסף האיכות חוסם שחרור אם ההערכה לפי קריטריון ירדה; לניתוח ידני מגיעים רק מקרים שבהם האוטומציה לא בטוחה.
שיעור התשובות השגויות ירד מ-12% ל-3%, בדיקת השחרור התקצרה מ-3-4 ימים ל-40 דקות, רגרסיות שהוחמצו ברבעון — אפס. בתמיכה זה הביא לפחות הסלמות ופינה לנציגים לפניות מורכבות: שאלות אופייניות העוזר סוגר בעצמו, והצוות רואה איזה קריטריון בדיוק מושך את האיכות למטה לאחר שינוי כזה או אחר.
במה שונה תיוג אופליין מבדיקות בפרודקשן
תיוג אופליין ובדיקות בפרודקשן עונים על שאלות שונות. מערך על נתונים היסטוריים מראה אם המודל השתפר במקרים מוכרים; תעבורה חיה — אם הוא לא נשבר על מה שלא היה במערך.
מערך מוכן על שיחות היסטוריות
כאן אוספים פניות אמיתיות, מתעדים תשובת תקן או סולם הערכה ומריצים דרך כל גרסת מודל. תכונת המערך — שחזור: אותם קלטים, אותה מתודולוגיה, לכן התוצאות ניתנות להשוואה בין הרכבות ורואים מה הביא לעלייה ומה הוריד את האיכות.
פלטפורמה כמו Braintrust מחזיקה מערכים כאלה יחד עם הערכות ומשווה אוטומטית ריצות, ומראה פערים לפי כל דוגמה.
השטח העיוור הוא בדיוק אחד: המערך משקף את התפלגות השאילתות בעבר. ניסוחים חדשים, נושאים ומקרי קצה לא נכנסים אליו עד שמוסיפים אותם ידנית.
בקרה על תעבורה חיה
בקרת איכות תשובות מקוונת עובדת על מה שמגיע עכשיו: שיעור הסירובים ושאלות חוזרות, ניתוח שיחות שבהן המשתמש עזב, איסוף משוב משתמשים ישירות בממשק. זו הדרך היחידה לראות שינוי בנושאים ותרחישים נדירים. אבל אין כאן תקן — ההערכה רועשת, תלויה בהתנהגות הקהל, וחלק מהמשוב פשוט לא מגיע.
ההבדל בין שיטות הבדיקה הוא שאופליין אחראי לרגרסיה, ואונליין — לגילוי. סכימת עבודה: מערך על שיחות היסטוריות עומד כשער לפני שחרור, וחריגות מהפרודקשן מנותחות והופכות לדוגמאות חדשות במערך.
שאלות טכניות נפוצות לפני אינטגרציה
לפני אינטגרציה צוותים הנדסיים שואלים כמעט את אותן שאלות — וכולן על איך הבדיקות מסתדרות עם מוצר שכבר עובד.
להלן תשובות לספקות אופייניים: מפערים בתיוג ועד לבחירה בין מעגל בדיקות משלכם לבין פלטפורמה חיצונית. העיקרון הכללי אחד: הבדיקות משתלבות בתהליך השחרור הנוכחי, בלי לעצור את השירות, ומתחילות בריצת אופליין על שאילתות היסטוריות.
מתייגים חלוקים בהערכות — אפשר להאמין לבדיקות?
מחשבים התאמה על החלק החופף של המדגם: דוגמאות שנויות במחלוקת עוברות לבוררות אצל מתייג בכיר, והכלל מתועד בהוראות. מדד ההתאמה נכנס לדוח לצד איכות המודל — אחרת רעש התיוג מתפרש כדעיכה.
המודל כבר בפרודקשן — יהיה צורך לעצור אותו?
לא. קודם ריצת צל על שאילתות היסטוריות, בלי השפעה על תשובות חיות. שינויים בבדיקות ובכללים משיקים מאחורי מתג, שמוסר בפעולה אחת, — הנסיגה אורכת דקות.
כמה נתונים היסטוריים דרושים להתחלה?
בדרך כלל כמה מאות דוגמאות מתויגות לתרחיש, שנאספו מזרם שאילתות אמיתי, — אז הספים אינם אקראיים. אם הנתונים מועטים, מתחילים בדוגמאות סינתטיות ומשלימים באופן פעיל מקרים שנויים במחלוקת.
כיצד לחבר תרחישים חדשים לבדיקות?
תרחיש חדש מקבל תשובות תקן וספים משלו, בדיקות כלליות (פורמט, שלמות, אבטחה) נעשות שימוש חוזר. לפני ההשקה חובה ריצה על מערכים ישנים — רגרסיות נראות לפני השחרור.
מעגל בדיקות משלכם או פלטפורמה חיצונית?
מעגל משלכם משאיר שאילתות רגישות בתוך ההיקף, אך דורש תמיכה באחסון וגרסאות של מערכים. פלטפורמה חיצונית מהירה יותר בהתחלה: ב-Braintrust תיוג וריצות נאספים במהירות. לעתים קרובות בוחרים בהיבריד — רגיש מקומית, השאר בחוץ.
נדון במשימה: אילו נתונים דרושים להתחלה
דיוק ההערכה תלוי לא בכלי, אלא במידה שבה מערך הבדיקות משקף את התרחישים האמיתיים שלכם. כדי להציע מעגל בדיקות עובד ב-Braintrust, ולא סכמה מופשטת, אנחנו צריכים לראות כיצד המערכת מתנהלת כעת והיכן בדיוק היא טועה.
- תיאור תרחישים: אילו משימות המודל פותר, מי המשתמש ומה נחשב לתשובה נכונה.
- 30–50 דוגמאות לתשובות מוצלחות — מהן נאסף התקן והבסיס לריצות חוזרות.
- דוגמאות לתשובות לא מוצלחות, כולל מקרי גבול: עובדות מומצאות, סירוב, פורמט שבור.
- מדדים נוכחיים ולוגים של פניות: שיעור שגיאות, זמן תגובה, תיוג ממשתמשים, אם מתבצע.
- מגבלות זמן: מתי נדרש התוצאה הראשונה ואילו שחרורים אסור לעצור.
- כללי עבודה עם נתונים: היכן מותר לעבד שאילתות, מה להפוך לאנונימי, האם נדרש מעגל מבודד.
- מי מצד הלקוח מאשר את קריטריוני האיכות ומנתח מקרים שנויים במחלוקת.
על בסיס נתונים אלה נרכיב תוכנית הטמעה של מעגל הבדיקות: מערכי בדיקות עם תקנים קבועים, ריצות אוטומטיות בכל שינוי בפרומפט או במודל, ספים שבהם השחרור נחסם, ודיווח על דינמיקת האיכות מגרסה לגרסה. תארו את המשימה ושלחו את מה שכבר קיים — נחזור עם הערכת לוחות זמנים, היקף העבודה ותוכנית הטמעה.