"נראה לי טוב", לא מדד
כל מי שמשלב Claude באפליקציה מגיע לאותו רגע: מישהו בצוות שואל "אבל איך אנחנו יודעים שזה עובד?" ואתה עונה: "בדקנו ידנית ונראה לנו טוב". זה לא מדד, זה תחושה.
בלי מדידה מסודרת אי אפשר לדעת: האם שינוי ב-system prompt שיפר או פגע? האם גרסה חדשה של Claude טובה יותר לשימוש הספציפי שלך? באיזה קטגוריות המודל נכשל? Evaluation framework פותר את כל זה, ומאפשר לפתח AI בביטחון.
מה זה Eval Set ואיך בונים אותו
Eval Set הוא אוסף בדיקות מובנות שמייצגות את הטסק האמיתי שלך. כל מקרה בדיקה כולל:
- Input, הבקשה שנשלחת ל-Claude, כולל system prompt
- Expected criteria, מה מגדיר תשובה טובה (לא בהכרח מחרוזת מדויקת)
- Category, סוג המשימה, לניתוח ביצועים פר-קטגוריה
- Difficulty, קל / בינוני / קשה
לפי Anthropic, כדאי להתחיל עם 20-50 מקרים אמיתיים שנלקחו מכשלים ממשיים, לא מתרחישים דמיוניים. אחרי שהמערכת יציבה, מגדילים ל-100+.
שיטות הדירוג, מהירה עד מדויקת
| שיטה | מתי להשתמש | יתרון | חסרון |
|---|---|---|---|
| Exact match | סיווג, JSON schema, regex | הכי מהיר ואמין | לא מתאים לפלט פתוח |
| LLM-as-Judge | כתיבה, סיכום, שירות לקוחות | גמיש, ניתן לאוטומציה | לא דטרמיניסטי, עולה כסף |
| Human grading | קביעת baseline ראשוני | הכי איכותי | איטי ויקר, להימנע לניטור שוטף |
הכלל של Anthropic: "Prioritize volume over quality, more questions with slightly lower signal automated grading is better than fewer hand-graded evals." כלומר: 200 evals אוטומטיים עדיפים על 20 evals ידניים.
LLM-as-Judge בפועל, עקרונות לרוביק טוב
LLM-as-Judge הוא כשמודל שופט את איכות תשובת מודל אחר. מחקר Bloom של Anthropic (2025) מראה ש-Claude Opus 4.1 כשופט מגיע לקורלציה של 0.86 עם שפיטה אנושית, גבוה מאוד. שלושה עקרונות לרוביק אפקטיבי:
- קריטריונים ספציפיים: לא "תשובה טובה" אלא "חייב לציין מחיר, לא להכיל הבטחות לא מבוססות, לסיים ב-CTA"
- חשיבה לפני ציון: בקש מהשופט לחשוב בתגי thinking לפני ציון סופי, זה משפר מהימנות
- מודל שופט שונה ממודל נבדק: השתמש ב-Claude Haiku לדירוג אוטומטי כדי לחסוך עלות
pass@k לעומת pass^k, מדד לפיתוח ומדד ל-Production
שני המדדים עוסקים בריצת אותה משימה k פעמים, אבל מודדים שאלות שונות:
- pass@k, האם לפחות ניסיון אחד מתוך k הצליח? מדד לפיתוח: מראה עד כמה המודל מסוגל
- pass^k, האם כל k הניסיונות הצליחו? מדד לפרודקשן: רלוונטי כשלקוח לא מקבל שני סיכויים
דוגמה: chatbot של חברת ביטוח ישראלית. pass@5=90% נשמע טוב, אבל pass^3=40% אומר שב-60% מהמקרים לקוח שפנה שלוש פעמים ייכשל לפחות פעם אחת, לא מקובל.
טעויות נפוצות שמפתחים ישראלים עושים
טעות 1: בונים evals רק אחרי שמשהו נשבר. צוות סטארטאפ תל-אביבי שיפר system prompt מפעם לפעם, בכל שיחה של מנהל מוצר ומפתח. אחרי חודש אף אחד לא ידע אם גרסה נוכחית טובה יותר מהגרסה של חודשיים קודם. Eval harness שמורץ ב-CI/CD היה פותר את זה מהיום הראשון.
טעות 2: גרייד נוקשה שפוסל תשובות תקינות. לפי Anthropic: "Rigid grading that penalized valid solutions resulted in artificially low scores." כשמחפשים מחרוזת ספציפית, כל ניסוח שקול שבחר המודל נכשל. פתרון: LLM-judge עם קריטריונים, לא string match.
דוגמה ישראלית, Eval ל-HR Chatbot
חברת גיוס בת"א בנתה chatbot שעונה למועמדים על שאלות נפוצות (תנאים, תהליך, ציפיות). לאחר חודש ניסו לשנות system prompt כדי לשפר טון. איך ידעו שהשיפור לא פגע בדיוק?
הם בנו Eval Set של 40 שאלות ממועמדים אמיתיים, חילקו ל-3 קטגוריות (תנאים, תהליך, דחייה), והגדירו criteria לכל קטגוריה. Claude Haiku שיפט כשופט בקנה מידה של 1-5. לפני ואחרי כל שינוי הריצו run_eval_suite() ובדקו pass_rate. שינוי שהוריד accuracy בקטגוריית דחייה מ-82% ל-71% נתפס ונחסם לפני deploy.