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