benchmark הוא אוסף תרחישי הערכה שמופעלים אוטומטית מול pipeline. זהו הכלי למדידה אובייקטיבית של איכות agent ולגילוי רגרסיות לפני שהן מגיעות לפרודקשן.
מדוע
agent ש« נראה כאילו עובד » יכול לרגרס בשקט לאחר:
- שינוי משימה;
- שינוי מודל LLM;
- הוספת tool חדש.
ללא benchmark, מגלים זאת בפרודקשן. עם benchmark, רואים זאת בהרצה הבאה — לפני המשתמשים שלכם.
אנטומיה של תרחיש
תרחיש מכיל:
- גירוי — הקלט שה-pipeline מקבל (הודעה או רצף תורות, fixtures של נתונים).
- checks — אסרציות מפורשות המוערכות על כל תור: הפלט שיוצר, צורת התגובה, שרשרת קריאות ה-tools, עלות הפעולות.
קטלוג checks
| Check | בודק |
|---|---|
pipeline_output_match | מפתח בזרימת הפלט תואם לערך הצפוי (נתיב + אסרציה) |
response_shape | צורת התגובה של ה-agent (אורך, מבנה), נמדדת ללא שופט |
llm_rubric | תוכן התגובה, מדורג על-ידי שופט LLM לפי רובריקה של קריטריונים ניתנים לאימות |
tool_chain_analysis | רצף קריאות ה-tools תואם את האסטרטגיה הצפויה |
tool_cost | תקציב הפעולות: לכל קריאה יש עלות, הגעה ליעד מזכה בבונוס |
static / tests / diff_quality | checks ממוקדי קבצים וקוד (פלט של pipeline פיתוח) |
הקטלוג ניתן להרחבה בצד הפלטפורמה: כל check הוא plugin הרשום בצד השרת.
יצירת benchmark
- יישומים → הערכה → תרחישים.
- צרו את התרחישים (גירוי, checks, fixtures של נתונים); כל תרחיש מוקדש למודל אחד (ה-pipeline היעד). ה-fixtures מנוהלים בלשונית Fixtures.
ניתן גם ליצור או לשנות תרחיש באמצעות הצעה מתוך שרת ה-MCP (benchmark_create / benchmark_update), שנשארת בהמתנה עד לקבלתה.
benchmark טוב מכיל תמהיל: מקרה סטנדרטי, מקרי קצה, מקרים עוינים (ניסיונות מניפולציה, עמימות, נתונים חסרים).
הפעלת benchmark
מממשק הניהול, הפעילו הרצה: היא נכנסת לתור עמיד ואז מבוצעת על-ידי worker ייעודי, מחוץ לשרת ה-web. אם ה-worker הזה נעצר באמצע הרצה, ההרצה מסומנת כנכשלה בהפעלה מחדש (היא אינה מתחדשת אוטומטית): הפעילו אותה שוב. drawer מציג את הפירוט לכל תרחיש.
הדוח מציין:
- שיעור הצלחה לפי check
- התפתחות הציונים בין ההרצות (לשוניות היסטוריה ו-התפתחות)
- רשימת התרחישים שנכשלו, עם פירוט כל check
המלצות
- התחילו קטן — 5 תרחישים ממוקדים שווים יותר מ-50 תרחישים גסים.
- הריצו benchmark לפני כל פרסום, והשוו להרצה הקודמת לפני הדחיפה.
- גרסו את המשימות. לא רק pipelines: גם המשימות מתפתחות.
- שמרו על קריאות ה-checks. check שדורש 20 שורות הסבר כדי להבין אותו הוא check שצריך לפרק.