Eval לפני Production: איך יודעים שהסוכן השתפר

הבעיה: בלי evals, כל שיפור הוא אמונה

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

שלב 1: Golden Dataset — קטן, אמיתי, binary

• אוספים 50 (עד 200 בהמשך) מקרים אמיתיים — במיוחד כישלונות אמיתיים מהלוגים. הכישלונות של היום הם סט הבדיקה של מחר.
• כל מקרה: קלט + התוצאה הצפויה + קריטריון מספק/לא מספק שנקבע מראש. Binary. לא ציון 1–10 — זה רעש, לא מדד.
• מגדירים מה מודדים: שיעור הצלחה למשימה, עלות, latency — ולסוכנים גם trajectory: האם הכלים שנבחרו היו הנכונים, האם המסלול היה קוהרנטי, האם הסוכן התאושר מכשל בדרך.

שלב 2: מריצים, משווים, שומרים baseline

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

שלב 3: LLM-as-Judge — אבל מכיילים אותו

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

1. מומחה אנושי (אתם) מדרג את כל המקרים בסט הקטן — עבר/נכשל, עם הסבר קצר.
2. מריצים את השופט על אותם מקרים ובודקים אחוז הסכמה מולכם.
3. מחדדים את פרומפט השופט עד שההסכמה יציבה וגבוהה. רק אז מרחיבים.

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

שלב 4: CI — כל PR עובר eval

כל pull request שנוגע בפרומפט, במודל או ב-retrieval מריץ אוטומטית את הסט. רגרסיה נחסמת לפני merge, לא אחרי שהלקוחות מוצאים אותה. לפני deploy לפרודקשן רצים על סט מלא יותר (מאות מקרים), ובפרודקשן עצמו — online evals עם טראפיק אמיתי, כי המקרים החדשים שהמשתמשים ממציאים תמיד שונים ממה שתכננתם.

סימנים שעשיתם את זה נכון

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

מתי לא להשקיע בזה עדיין

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