השאלה המועילה הפסיקה להיות אם המודל נראה טוב בדמו. השאלה המועילה היא אם המערכת שורדת שינוי פרומפט, החלפת מודל ויום שלישי גרוע בלי להידרדר בשקט.
evals הם לא תחביב benchmark
יש עדיין צוותים שמדברים על evals כאילו זאת הרגלת מחקר אופציונלית. זה היה נסבל כשהמערכת הייתה פרומפט אחד ומודל אחד.
זה לא נסבל כשיש במוצר retrieval, כלים, policies, פורמטים שונים של תשובה, כמה מחלקות כשל, ואנשים שישימו לב כשהכול נשבר.
ההכוונה הנוכחית של OpenAI ברורה. evals הם הדרך להבין מערכות לא-דטרמיניסטיות בפרודקשן. Anthropic אומרים כמעט אותו דבר מזווית אחרת. ברגע שהמערכת פועלת בכמה צעדים, צריך דרך מסודרת להגדיר הצלחה. אחרת כל רגרסיה הופכת לאנקדוטה.
להתחיל מסט קטן שאפשר לסמוך עליו
הדאטהסט הכי שימושי ל-evals בדרך כלל קטן יותר ממה שנדמה, ובדוק יותר ממה שנוח לצוות.
אני אוהב להפריד בין שני סוגי נתונים:
Trusted set
זה הסט שאיתו מוכנים לקבל החלטות ריליז.
הוא צריך להיות:
- audited ביד
- מייצג עבודה אמיתית
- קטן מספיק כדי לתחזק אותו
- ברור מספיק כדי שבני אדם ו-graders יסכימו בדרך כלל
Monitoring set
הסט הזה רחב ורועש יותר, וקרוב יותר לתנועה אמיתית.
הוא טוב ל:
- זיהוי drift
- מציאת מחלקות כשל חדשות
- תפיסת side effects של פרומפטים או routing
- הערכת מה באמת השתנה בשטח
לא בהכרח מספיק נקי כדי לעצור ריליזים לבדו.
לדרג את מה שבאמת נכשל
ציון אחד מסודר. גם לעיתים קרובות לא מועיל.
עדיף graders לפי משימה.
במערכת RAG או legal QA, למשל, אני רוצה סיגנלים נפרדים עבור:
- נכונות התשובה
- איכות התמיכה
- שלמות provenance או ציטוט
- abstention
- עמידה בפורמט
- latency
ב-agent, גם OpenAI וגם Anthropic מצביעים על אותו כיוון: אם הכשל קורה באמצע ה-trace, לא מספיק לדרג רק את התשובה הסופית.
צריך לשאול:
- האם נבחר הכלי הנכון?
- האם הופעלו יותר מדי כלים?
- האם נחצה גבול approval בצורה שגויה?
- האם נשלפו ראיות נכונות אבל נעשה בהן שימוש שגוי?
LLM judges בטווח צר
judge models מועילים כשיש משימה פתוחה ורובריקה שאפשר לכתוב באופן ברור.
הם חלשים יותר כאשר הרובריקה עמומה, הפורמט היה אמור להיות דטרמיניסטי מלכתחילה, או עובדה אחת בתוך פרוזה טובה מספיקה כדי להטעות את המערכת.
הכלל המעשי. בדיקות קוד כשאפשר. model grading כשצריך. השכבה השנייה מכוונת מול הראשונה ומול בדיקה אנושית תקופתית.
סיגנלים תפעוליים שייכים לשיחת ה-evals
הרבה צוותים מודדים איכות תשובה ואז מוסיפים תפעול אחר כך. זה נראה מסודר על שקף. במערכת אמיתית זאת חלוקה מזויפת.
שינוי מודל ששומר לכאורה על איכות התשובה אבל מכפיל latency, מוריד abstention או מגדיל tool churn, שינה את המוצר.
לכן חבילת ה-production evals עוקבת גם אחרי TTFT, end-to-end latency, עלות טוקנים, שיעור refusal, שיעור escalation, מספר קריאות לכלים, אורך trace, שיעור retry.
לא צריך לסגוד לכל metric. צריך לדעת מה השתנה.
שערי ריליז משעממים
שער ריליז טוב ברור, לא מרשים פילוסופית.
בפועל:
- כישלון קשיח אם trusted-set accuracy יורד מתחת לסף
- כישלון קשיח אם פורמט נשבר
- כישלון קשיח אם מקרי refusal רגישים הידרדרו
- אזהרה אם latency או cost חצו את התקציב
- בדיקה ידנית של trace deltas כשהתנהגות ה-agent זזה מהותית
מספיק כדי לשמור על יושר בלי להקים דת סביב דשבורדים.
incidents נכנסים מהר ל-suite
הדרך המהירה ביותר לבנות תוכנית evals מיושנת היא להתייחס לדאטהסט כמו למוזיאון.
הלולאה הבריאה. משתמש או monitoring מוצאים כשל. הכשל הופך למקרה eval. המערכת המתוקנת חייבת לעבור אותו מאז והלאה.
שם נמצא הערך המצטבר. harness טוב נהיה שווה יותר עם כל באג מביך שהוא סופג.
לתוכנית ה-evals צריך owner
דשבורד משותף הוא לא בעלות. מישהו צריך להחליט אילו evals אמינים מספיק כדי לעצור ריליז, איזה כשל הוא אות ואיזה רעש, מתי משימה חדשה נכנסת ל-suite, מי מאשר שינוי ברובריקה.
גרסה ראשונה קטנה
אם הייתי צריך להעמיד evals למערכת פרודקשן מחר בבוקר:
- אוסף 30–50 דוגמאות trusted
- מפריד לפי מחלקות כשל
- מגדיר grader מבוסס קוד או מודל לכל מחלקה
- עוקב אחרי latency ו-refusal ליד האיכות
- עוצר ריליזים על הסט הקטן לפני שמנסים להרתיח את האוקיינוס
המערכת הראשונה לא צריכה להיות מרשימה. צריכה לתפוס את הכשלים שאתם באמת משחררים.