מבוא
הערכות ביצועים (evals) טובות מאפשרות לצוותים לפרוס סוכני AI בביטחון רב יותר. בלעדיהן, קל להיכנס ללופים ריאקטיביים – לגלות בעיות רק בייצור, היכן שתיקון כשל אחד יוצר אחרים. הערכות הופכות בעיות ושינויים התנהגותיים גלויים לפני שהם משפיעים על המשתמשים, וערכן מצטבר לאורך מחזור החיים של סוכן.
כפי שתיארנו ב-בניית סוכנים יעילים, סוכנים פועלים על פני תורות רבות: קוראים לכלים, משנים מצב ומתאימים את עצמם בהתבסס על תוצאות ביניים. יכולות אלו שהופכות סוכני AI לשימושיים – אוטונומיה, אינטליגנציה וגמישות – הן גם אלו שמקשות על הערכתם.
באמצעות עבודתנו הפנימית ועם לקוחות בחזית פיתוח הסוכנים, למדנו כיצד לתכנן הערכות קפדניות ושימושיות יותר לסוכנים. הנה מה שעבד במגוון רחב של ארכיטקטורות סוכנים ומקרי שימוש בפריסה בעולם האמיתי.
המבנה של הערכה
הערכה היא מבחן למערכת AI: נותנים ל-AI קלט, ואז מיישמים לוגיקת דירוג על הפלט שלו כדי למדוד הצלחה. בפוסט זה, אנו מתמקדים בהערכות אוטומטיות שניתן להריץ במהלך הפיתוח ללא משתמשים אמיתיים.
הערכות חד-תוריות פשוטות: פרומפט, תגובה ולוגיקת דירוג. עבור מודלי LLM מוקדמים יותר, הערכות חד-תוריות ולא סוכניות היו שיטת ההערכה העיקרית. ככל שיכולות ה-AI התפתחו, הערכות מרובות-תורות הפכו נפוצות יותר ויותר.
הערכות סוכנים מורכבות אף יותר. סוכנים משתמשים בכלים על פני תורות רבות, משנים מצב בסביבה ומתאימים את עצמם תוך כדי – מה שאומר שטעויות יכולות להתפשט ולהצטבר. מודלי חזית יכולים גם למצוא פתרונות יצירתיים העולים על גבולות הערכות סטטיות. לדוגמה, Opus 4.5 פתר בעיית 𝜏2-bench על הזמנת טיסה על ידי גילוי פרצה במדיניות. הוא "נכשל" בהערכה כפי שנכתבה, אך למעשה הגיע לפתרון טוב יותר עבור המשתמש.
בעת בניית הערכות סוכנים, אנו משתמשים בהגדרות הבאות:
- משימה (המכונה גם בעיה או מקרה מבחן) היא מבחן יחיד עם קלטים מוגדרים וקריטריוני הצלחה.
- כל ניסיון במשימה הוא ניסיון הפעלה (trial). מכיוון שפלט המודל משתנה בין הרצות, אנו מריצים מספר ניסיונות הפעלה כדי להפיק תוצאות עקביות יותר.
- בודק (grader) הוא לוגיקה שמדרגת היבט כלשהו של ביצועי הסוכן. למשימה יכולים להיות מספר בודקים, כאשר כל אחד מכיל מספר קביעות (לפעמים נקראות בדיקות).
- תמליל (transcript) (המכונה גם מעקב (trace) או מסלול (trajectory)) הוא התיעוד המלא של ניסיון הפעלה, כולל פלטים, קריאות לכלים, חשיבה, תוצאות ביניים וכל אינטראקציה אחרת. עבור ה-Anthropic API, זהו מערך ההודעות המלא בסוף הרצת הערכה - המכיל את כל הקריאות ל-API ואת כל התגובות שהוחזרו במהלך ההערכה.
- תוצאה (outcome) היא המצב הסופי בסביבה בסוף ניסיון ההפעלה. סוכן להזמנת טיסות עשוי לומר "הטיסה שלך הוזמנה" בסוף התמליל, אך התוצאה היא האם קיימת הזמנה במסד הנתונים SQL של הסביבה.
- מערכת הערכה (evaluation harness) היא התשתית שמריצה הערכות מקצה לקצה. היא מספקת הוראות וכלים, מריצה משימות במקביל, מתעדת את כל השלבים, מדרגת פלטים ומאגדת תוצאות.
- מערכת סוכן (agent harness) (או פיגום (scaffold)) היא המערכת המאפשרת למודל לפעול כסוכן: היא מעבדת קלטים, מתאמת קריאות לכלים ומחזירה תוצאות. כאשר אנו מעריכים "סוכן", אנו מעריכים את המערכת ואת המודל הפועלים יחד. לדוגמה, Claude Code הוא מערכת סוכן גמישה, ואנו השתמשנו בעקרונות הליבה שלו דרך ה-Agent SDK כדי לבנות את מערכת הסוכן ארוכת הטווח שלנו.
- חבילת הערכה (evaluation suite) היא אוסף של משימות שנועדו למדוד יכולות או התנהגויות ספציפיות. משימות בחבילה בדרך כלל חולקות מטרה רחבה. לדוגמה, חבילת הערכה לתמיכת לקוחות עשויה לבדוק החזרים כספיים, ביטולים והסלמות.
למה לבנות הערכות?
כאשר צוותים מתחילים לבנות סוכנים, הם יכולים להתקדם באופן מפתיע באמצעות שילוב של בדיקות ידניות, dogfooding ואינטואיציה. הערכה קפדנית יותר עשויה אף להיראות כנטל שמאיט את הפריסה. אך לאחר שלבי האב-טיפוס המוקדמים, ברגע שסוכן נמצא בייצור ומתחיל בסקיילינג, בנייה ללא הערכות מתחילה להתפרק.
נקודת השבירה מגיעה לעיתים קרובות כאשר משתמשים מדווחים שהסוכן מרגיש גרוע יותר לאחר שינויים, והצוות "עיוור" ללא דרך לאמת מלבד לנחש ולבדוק. בהיעדר הערכות, דיבוג הוא ריאקטיבי: מחכים לתלונות, משחזרים ידנית, מתקנים את הבאג ומקווים ששום דבר אחר לא עבר רגרסיה. צוותים אינם יכולים להבחין בין נסיגות אמיתיות לרעש, לבדוק שינויים אוטומטית מול מאות תרחישים לפני הפריסה, או למדוד שיפורים.
ראינו התקדמות זו מתרחשת פעמים רבות. לדוגמה, Claude Code התחיל באיטרציה מהירה המבוססת על משוב מעובדי אנתרופיק ומשתמשים חיצוניים. מאוחר יותר, הוספנו הערכות – תחילה לתחומים צרים כמו תמציתיות ועריכות קבצים, ולאחר מכן להתנהגויות מורכבות יותר כמו הנדסת יתר. הערכות אלו עזרו לזהות בעיות, להדריך שיפורים ולמקד שיתופי פעולה בין מחקר למוצר. בשילוב עם ניטור ייצור, מבחני A/B, מחקר משתמשים ועוד, הערכות מספקות איתותים להמשיך ולשפר את Claude Code ככל שהוא מתרחב.
כתיבת הערכות שימושית בכל שלב במחזור החיים של הסוכן. בשלבים המוקדמים, הערכות מאלצות את צוותי המוצר לציין מהי הצלחה עבור הסוכן, ואילו בשלבים מאוחרים יותר הן עוזרות לשמור על רף איכות עקבי.
הסוכן של Descript עוזר למשתמשים לערוך סרטונים, ולכן הם בנו הערכות סביב שלושה ממדים של זרימת עבודה עריכתית מוצלחת: אל תשבור דברים, עשה מה שביקשתי, ועשה זאת היטב. הם התפתחו מדירוג ידני לבוחני LLM עם קריטריונים שהוגדרו על ידי צוות המוצר וכיול אנושי תקופתי, וכעת מריצים באופן קבוע שתי חבילות נפרדות למדדי איכות ולבדיקות רגרסיה. צוות ה-AI של Bolt התחיל לבנות הערכות מאוחר יותר, לאחר שכבר היה להם סוכן בשימוש נרחב. תוך 3 חודשים, הם בנו מערכת הערכה שמריצה את הסוכן שלהם ומדרגת פלטים עם ניתוח סטטי, משתמשת בסוכני דפדפן לבדיקת אפליקציות, ומעסיקה שופטי LLM עבור התנהגויות כמו ביצוע הוראות.
חלק מהצוותים יוצרים הערכות בתחילת הפיתוח; אחרים מוסיפים אותן לאחר הסקיילינג כאשר הערכות הופכות לצוואר בקבוק לשיפור הסוכן. הערכות שימושיות במיוחד בתחילת פיתוח הסוכן כדי לקודד במפורש התנהגות צפויה. שני מהנדסים הקוראים את אותו מפרט ראשוני יכולים לצאת עם פרשנויות שונות לגבי האופן שבו ה-AI צריך לטפל במקרי קצה. חבילת הערכה פותרת אי-בהירות זו. ללא קשר מתי נוצרו, הערכות עוזרות להאיץ את הפיתוח.
הערכות גם מעצבות את המהירות שבה ניתן לאמץ מודלים חדשים. כאשר מודלים חזקים יותר יוצאים, צוותים ללא הערכות עומדים בפני שבועות של בדיקות, בעוד שמתחרים עם הערכות יכולים לקבוע במהירות את נקודות החוזק של המודל, לכוונן עדין את הפרומפטים שלהם ולשדרג תוך ימים.
ברגע שקיימות הערכות, מקבלים בסיסי ייחוס ובדיקות רגרסיה בחינם: השהיה (latency), שימוש בטוקנים, עלות למשימה ושיעורי שגיאות ניתנים למעקב על בנק משימות סטטי. הערכות יכולות גם להפוך לערוץ התקשורת בעל רוחב הפס הגבוה ביותר בין צוותי מוצר ומחקר, המגדירים מדדים שחוקרים יכולים לייעל מולם. ברור שלערכות יש יתרונות רחבי טווח מעבר למעקב אחר רגרסיות ושיפורים. ערכן המצטבר קל לפספוס בהתחשב בכך שהעלויות גלויות מראש בעוד שהיתרונות מצטברים מאוחר יותר.
כיצד להעריך סוכני AI
אנו רואים מספר סוגי סוכנים נפוצים הפרוסים בסקיילינג כיום, כולל סוכני קידוד, סוכני מחקר, סוכני שימוש במחשב וסוכנים שיחתיים. כל סוג עשוי להיפרס במגוון רחב של תעשיות, אך ניתן להעריך אותם באמצעות טכניקות דומות. אינך צריך להמציא הערכה מאפס. הסעיפים הבאים מתארים טכניקות מוכחות עבור מספר סוגי סוכנים. השתמש בשיטות אלה כבסיס, ולאחר מכן הרחב אותן לתחום שלך.
סוגי בודקים לסוכנים
הערכות סוכנים משלבות בדרך כלל שלושה סוגי בודקים: מבוססי קוד, מבוססי מודל ואנושיים. כל בודק מעריך חלק כלשהו מהתמליל או מהתוצאה. מרכיב חיוני בתכנון הערכה יעיל הוא בחירת הבודקים הנכונים למשימה.
בודקים מבוססי קוד
- יתרונות:
- דטרמיניסטי
- מהיר
- חסכוני
- ניתן להרצה בסקיילינג
- קריטריונים אובייקטיביים
- חסרונות:
- פחות גמיש
- קשה ללכוד ניואנסים
- לא מתאים למשימות פתוחות
- לא מתאים לפלט חופשי
בודקים מבוססי מודל
- דירוג מבוסס קריטריונים
- קביעות בשפה טבעית
- השוואה זוגית
- הערכה מבוססת התייחסות
- קונצנזוס רב-שופטים
- יתרונות:
- גמיש
- ניתן להרצה בסקיילינג
- לכוד ניואנסים
- יטפל במשימות פתוחות
- יטפל בפלט חופשי
- חסרונות:
- לא דטרמיניסטי
- יקר יותר מקוד
- דורש כיול עם בודקים אנושיים לדיוק
בודקים אנושיים
- סקירת מומחים בתחום
- שיפוט במיקור המונים
- דגימת בדיקה נקודתית
- מבחני A/B
- הסכמה בין-מבקרים
- יתרונות:
- איכות סטנדרטית זהב
- תואם לשיפוט משתמש מומחה
- משמש לכיול בודקים מבוססי מודל
- חסרונות:
- יקר
- איטי
- דורש לעיתים קרובות גישה למומחים אנושיים בסקיילינג
עבור כל משימה, הדירוג יכול להיות משוקלל (ציוני הבודקים המשולבים חייבים להגיע לסף), בינארי (כל הבודקים חייבים לעבור) או היברידי.
הערכות יכולת מול רגרסיה
הערכות יכולת או "איכות" שואלות, "מה סוכן זה יכול לעשות היטב?" הן צריכות להתחיל בשיעור מעבר נמוך, המכוון למשימות שהסוכן מתקשה בהן, ולתת לצוותים "גבעה לטפס עליה".
הערכות רגרסיה שואלות, "האם הסוכן עדיין מטפל בכל המשימות כפי שהיה בעבר?" וצריכות להיות בעלות שיעור מעבר של כמעט 100%. הן מגנות מפני נסיגה, שכן ירידה בציון מאותתת שמשהו מקולקל ודורש שיפור. כאשר צוותים מטפסים על "גבעות" בהערכות יכולת, חשוב להריץ גם הערכות רגרסיה כדי לוודא ששינויים אינם גורמים לבעיות במקומות אחרים.
לאחר שסוכן מושק וממוטב, הערכות יכולת עם שיעורי מעבר גבוהים יכולות "לסיים את לימודיהן" ולהפוך לחבילת רגרסיה המורצת באופן רציף כדי לזהות כל סטייה. משימות שפעם מדדו "האם אנחנו יכולים לעשות את זה בכלל?" מודדות כעת "האם אנחנו עדיין יכולים לעשות את זה באופן מהימן?"
הערכת סוכני קידוד
סוכני קידוד כותבים, בודקים ומדבגים קוד, מנווטים במאגרי קוד ומריצים פקודות בדומה למפתח אנושי. הערכות יעילות לסוכני קידוד מודרניים מסתמכות בדרך כלל על משימות מוגדרות היטב, סביבות בדיקה יציבות ובדיקות יסודיות לקוד שנוצר.
בודקים דטרמיניסטיים טבעיים לסוכני קידוד מכיוון שתוכנה בדרך כלל פשוטה להערכה: האם הקוד פועל והאם הבדיקות עוברות? שני מדדי ביצועים נפוצים לסוכני קידוד, SWE-bench Verified ו-Terminal-Bench, עוקבים אחר גישה זו. SWE-bench Verified נותן לסוכנים בעיות GitHub ממאגרי Python פופולריים ומדרג פתרונות על ידי הרצת חבילת הבדיקות; פתרון עובר רק אם הוא מתקן את הבדיקות הנכשלות מבלי לשבור בדיקות קיימות. מודלי LLM התקדמו מ-40% ל->80% בהערכה זו תוך שנה אחת בלבד. Terminal-Bench נוקט בדרך אחרת: הוא בודק משימות טכניות מקצה לקצה, כגון בניית ליבת לינוקס מקוד המקור או אימון מודל למידת מכונה.
ברגע שיש לך סט של בדיקות עובר/נכשל לאימות התוצאות העיקריות של משימת קידוד, לעיתים קרובות שימושי לדרג גם את התמליל. לדוגמה, כללים מבוססי היוריסטיקה לאיכות קוד יכולים להעריך את הקוד שנוצר על סמך יותר מסתם בדיקות שעברו, ובוחנים מבוססי מודל עם קריטריונים ברורים יכולים להעריך התנהגויות כמו האופן שבו הסוכן קורא לכלים או מתקשר עם המשתמש.
דוגמה: הערכה תיאורטית לסוכן קידודשקול משימת קידוד שבה הסוכן חייב לתקן פגיעות עקיפת אימות. כפי שמוצג בקובץ YAML להלן, ניתן להעריך סוכן זה באמצעות בודקים ומדדים כאחד.
task:
id: "fix-auth-bypass_1"
desc: "Fix authentication bypass when password field is empty and ..."
graders:
- type: deterministic_tests
required: [test_empty_pw_rejected.py, test_null_pw_rejected.py]
- type: llm_rubric
rubric: prompts/code_quality.md
- type: static_analysis
commands: [ruff, mypy, bandit]
- type: state_check
expect:
security_logs: {event_type: "auth_blocked"}
- type: tool_calls
required:
- {tool: read_file, params: {path: "src/auth/*"}}
- {tool: edit_file}
- {tool: run_tests}
tracked_metrics:
- type: transcript
metrics:
- n_turns
- n_toolcalls
- n_total_tokens
- type: latency
metrics:
- time_to_first_token
- output_tokens_per_sec
- time_to_last_token
שים לב שדוגמה זו מציגה את מגוון הבודקים הזמינים להמחשה. בפועל, הערכות קידוד מסתמכות בדרך כלל על בדיקות יחידה לאימות נכונות וקריטריונים של LLM להערכת איכות קוד כוללת, עם בודקים ומדדים נוספים שמוסיפים רק לפי הצורך.
הערכת סוכנים שיחתיים
סוכנים שיחתיים מקיימים אינטראקציה עם משתמשים בתחומים כמו תמיכה, מכירות או אימון. בניגוד לצ'אטבוטים מסורתיים, הם שומרים מצב, משתמשים בכלים ונוקטים פעולות במהלך השיחה. בעוד שסוכני קידוד ומחקר יכולים לכלול גם תורות רבות של אינטראקציה עם המשתמש, סוכנים שיחתיים מציגים אתגר מובהק: איכות האינטראקציה עצמה היא חלק ממה שאתה מעריך. הערכות יעילות לסוכנים שיחתיים מסתמכות בדרך כלל על תוצאות מצב סופי ניתנות לאימות וקריטריונים שלוכדים הן את השלמת המשימה והן את איכות האינטראקציה. בניגוד לרוב ההערכות האחרות, הן דורשות לעיתים קרובות LLM שני כדי לדמות את המשתמש. אנו משתמשים בגישה זו בסוכני ביקורת היישור שלנו כדי לבדוק מודלים באמצעות שיחות מורחבות ועוינות.
הצלחה עבור סוכנים שיחתיים יכולה להיות רב-ממדית: האם הטיקט נפתר (בדיקת מצב), האם הוא הסתיים בפחות מ-10 תורות (אילוץ תמליל), והאם הטון היה הולם (קריטריונים של LLM)? שני מדדי ביצועים המשלבים רב-ממדיות הם 𝜏-Bench ויורשו, τ2-Bench. אלה מדמים אינטראקציות מרובות-תורות בתחומים כמו תמיכה קמעונאית והזמנת טיסות, כאשר מודל אחד מגלם דמות משתמש בעוד הסוכן מנווט בתרחישים מציאותיים.
דוגמה: הערכה תיאורטית לסוכן שיחתישקול משימת תמיכה שבה הסוכן חייב לטפל בהחזר כספי עבור לקוח מתוסכל.
graders:
- type: llm_rubric
rubric: prompts/support_quality.md
assertions:
- "Agent showed empathy for customer's frustration"
- "Resolution was clearly explained"
- "Agent's response grounded in fetch_policy tool results"
- type: state_check
expect:
tickets: {status: resolved}
refunds: {status: processed}
- type: tool_calls
required:
- {tool: verify_identity}
- {tool: process_refund, params: {amount: "<=100"}}
- {tool: send_confirmation}
- type: transcript
max_turns: 10
tracked_metrics:
- type: transcript
metrics:
- n_turns
- n_toolcalls
- n_total_tokens
- type: latency
metrics:
- time_to_first_token
- output_tokens_per_sec
- time_to_last_token
כמו בדוגמת סוכן הקידוד שלנו, משימה זו מציגה סוגי בודקים מרובים להמחשה. בפועל, הערכות סוכנים שיחתיים משתמשות בדרך כלל בבודקים מבוססי מודל כדי להעריך הן את איכות התקשורת והן את השלמת המטרה, מכיוון שלמשימות רבות – כמו מענה על שאלה – יכולים להיות מספר פתרונות "נכונים".
הערכת סוכני מחקר
סוכני מחקר אוספים, מסנתזים ומנתחים מידע, ולאחר מכן מפיקים פלטים כמו תשובה או דו"ח. בניגוד לסוכני קידוד שבהם בדיקות יחידה מספקות איתותי עובר/נכשל בינאריים, איכות המחקר יכולה להיבחן רק ביחס למשימה. מה נחשב "מקיף", "מבוסס מקורות" או אפילו "נכון" תלוי בהקשר: סריקת שוק, בדיקת נאותות עבור רכישה ודו"ח מדעי דורשים כל אחד סטנדרטים שונים.
הערכות מחקר מתמודדות עם אתגרים ייחודיים: מומחים עשויים לחלוק על מידת מקיפותו של סינתזה, "אמת קרקע" משתנה כאשר תוכן הפניה משתנה ללא הרף, ופלטים ארוכים ופתוחים יותר יוצרים יותר מקום לטעויות. מדד ביצועים כמו BrowseComp, לדוגמה, בודק האם סוכני AI יכולים למצוא "מחטים בערימת שחת" ברחבי הרשת הפתוחה – שאלות שתוכננו להיות קלות לאימות אך קשות לפתרון.
אסטרטגיה אחת לבניית הערכות סוכני מחקר היא שילוב סוגי בודקים. בדיקות הארקה (groundedness checks) מאמתות שטענות נתמכות על ידי מקורות שנשלפו, בדיקות כיסוי מגדירות עובדות מפתח שתשובה טובה חייבת לכלול, ובדיקות איכות מקורות מאשרות שהמקורות שהתייעצו איתם הם סמכותיים, ולא רק הראשונים שנשלפו. עבור משימות עם תשובות נכונות אובייקטיבית ("מה היו הכנסות רבעון 3 של חברה X?"), התאמה מדויקת עובדת. LLM יכול לסמן טענות לא נתמכות ופערי כיסוי אך גם לאמת את הסינתזה הפתוחה עבור קוהרנטיות ושלמות.
בהתחשב באופי הסובייקטיבי של איכות המחקר, יש לכייל תכופות קריטריונים מבוססי LLM מול שיפוט אנושי מומחה כדי לדרג סוכנים אלה ביעילות.
סוכני שימוש במחשב
סוכני שימוש במחשב מקיימים אינטראקציה עם תוכנה דרך אותו ממשק כמו בני אדם – צילומי מסך, לחיצות עכבר, קלטי מקלדת וגלילה – במקום דרך API או ביצוע קוד. הם יכולים להשתמש בכל יישום עם ממשק משתמש גרפי (GUI), מכלי עיצוב ועד תוכנות ארגוניות מיושנות. הערכה דורשת הרצת הסוכן בסביבה אמיתית או בסביבת ארגז חול (sandbox) שבה הוא יכול להשתמש ביישומי תוכנה ובדיקה האם הוא השיג את התוצאה הרצויה. לדוגמה, WebArena בודק משימות מבוססות דפדפן, תוך שימוש בבדיקות URL ומצב עמוד כדי לאמת שהסוכן ניווט נכון, יחד עם אימות מצב בקאנד למשימות שמשנות נתונים (אישור שהזמנה אכן בוצעה, לא רק שהופיע עמוד האישור). OSWorld מרחיב זאת לשליטה מלאה במערכת ההפעלה, עם סקריפטים של הערכה הבודקים Artifacts מגוונים לאחר השלמת המשימה: מצב מערכת קבצים, הגדרות יישומים, תוכן מסד נתונים ומאפייני אלמנטים של ממשק משתמש.
סוכני שימוש בדפדפן דורשים איזון בין יעילות טוקנים והשהיה. אינטראקציות מבוססות DOM מתבצעות במהירות אך צורכות טוקנים רבים, בעוד שאינטראקציות מבוססות צילומי מסך איטיות יותר אך יעילות יותר בשימוש בטוקנים. לדוגמה, כאשר מבקשים מ-Claude לסכם ויקיפדיה, יעיל יותר לחלץ את הטקסט מה-DOM. כאשר מוצאים נרתיק למחשב נייד חדש ב-Amazon, יעיל יותר לצלם צילומי מסך (שכן חילוץ ה-DOM כולו צורך טוקנים רבים). במוצר Claude for Chrome שלנו, פיתחנו הערכות כדי לבדוק שהסוכן בוחר את הכלי הנכון לכל הקשר. זה איפשר לנו להשלים משימות מבוססות דפדפן מהר יותר ובאופן מדויק יותר.
כיצד לחשוב על חוסר דטרמיניזם בהערכות לסוכנים
ללא קשר לסוג הסוכן, התנהגות הסוכן משתנה בין הרצות, מה שמקשה על פרשנות תוצאות ההערכה מכפי שהן נראות במבט ראשון. לכל משימה יש שיעור הצלחה משלה – אולי 90% במשימה אחת, 50% באחרת – ומשימה שעברה בהרצת הערכה אחת עשויה להיכשל בהרצה הבאה. לעיתים, מה שאנו רוצים למדוד הוא באיזו תדירות (איזה שיעור מהניסיונות) סוכן מצליח במשימה.
שני מדדים עוזרים ללכוד ניואנס זה:
- pass@k מודד את ההסתברות שסוכן יקבל לפחות פתרון נכון אחד ב-k ניסיונות. ככל ש-k עולה, ציון pass@k עולה: יותר "זריקות לשער" משמען סיכויים גבוהים יותר לפחות להצלחה אחת. ציון של 50% pass@1 פירושו שמודל מצליח בחצי מהמשימות בהערכה בניסיון הראשון שלו. בקידוד, לעיתים קרובות אנו מתעניינים ביותר בכך שהסוכן ימצא את הפתרון בניסיון הראשון – pass@1. במקרים אחרים, הצעה של פתרונות רבים תקפה כל עוד אחד מהם עובד.
- pass^k מודד את ההסתברות שכל k הניסיונות יצליחו. ככל ש-k עולה, pass^k יורד שכן דרישת עקביות על פני יותר ניסיונות היא רף קשה יותר לעמוד בו. אם לסוכן שלך יש שיעור הצלחה של 75% לכל ניסיון ואתה מריץ 3 ניסיונות, ההסתברות לעבור את שלושתם היא (0.75)³ ≈ 42%. מדד זה חשוב במיוחד עבור סוכנים הפונים ללקוחות שבהם משתמשים מצפים להתנהגות אמינה בכל פעם.
שני המדדים שימושיים, והבחירה באיזה מהם להשתמש תלויה בדרישות המוצר: pass@k עבור כלים שבהם הצלחה אחת חשובה, pass^k עבור סוכנים שבהם עקביות חיונית.
מאפס לאחד: מפת דרכים להערכות מעולות עבור סוכנים
סעיף זה מציג את העצות המעשיות והבדוקות שלנו למעבר מהיעדר הערכות להערכות שניתן לסמוך עליהן. חשוב על כך כמפת דרכים לפיתוח סוכנים מונחה הערכה: הגדר הצלחה מוקדם, מדוד אותה בבירור, ובצע איטרציות באופן מתמשך.
איסוף משימות למערך נתוני ההערכה הראשוני
שלב 0. התחל מוקדם
אנו רואים צוותים דוחים בניית הערכות מכיוון שהם חושבים שהם צריכים מאות משימות. במציאות, 20-50 משימות פשוטות שנלקחו מכשלים אמיתיים הן התחלה מצוינת. אחרי הכל, בפיתוח סוכנים מוקדם, לכל שינוי במערכת יש לעיתים קרובות השפעה ברורה ובולטת, וגודל האפקט הגדול הזה אומר שדגימות קטנות מספיקות. סוכנים בוגרים יותר עשויים לדרוש הערכות גדולות וקשות יותר כדי לזהות אפקטים קטנים יותר, אך עדיף לנקוט בגישת 80/20 בהתחלה. הערכות קשות יותר לבנייה ככל שמחכים זמן רב יותר. בשלבים מוקדמים, דרישות המוצר מתורגמות באופן טבעי למקרי מבחן. אם תחכה זמן רב מדי, תמצא את עצמך מבצע הנדסה הפוכה של קריטריוני הצלחה ממערכת חיה.
שלב 1. התחל עם מה שאתה כבר בודק ידנית
התחל עם הבדיקות הידניות שאתה מריץ במהלך הפיתוח – ההתנהגויות שאתה מאמת לפני כל השקה ומשימות נפוצות שמשתמשי קצה מנסים. אם אתה כבר בייצור, הסתכל על מעקב הבאגים שלך ותור התמיכה. המרת כשלים שדווחו על ידי משתמשים למקרי מבחן מבטיחה שהחבילה שלך משקפת שימוש בפועל; תעדוף לפי השפעת משתמש עוזר לך להשקיע מאמץ היכן שזה חשוב.
שלב 2: כתוב משימות חד-משמעיות עם פתרונות ייחוס
להגיע לאיכות משימה נכונה קשה יותר ממה שזה נראה. משימה טובה היא כזו ששני מומחי תחום יגיעו באופן עצמאי לאותה הכרעת עובר/נכשל. האם הם יכלו לעבור את המשימה בעצמם? אם לא, המשימה דורשת חידוד. עמימות במפרטי משימות הופכת לרעש במדדים. הדבר נכון גם לגבי קריטריונים לבוחנים מבוססי מודל: קריטריונים עמומים מפיקים שיפוטים לא עקביים.
כל משימה צריכה להיות ניתנת למעבר על ידי סוכן שמבצע הוראות בצורה נכונה. זה יכול להיות עדין. לדוגמה, בדיקת Terminal-Bench גילתה שאם משימה מבקשת מהסוכן לכתוב סקריפט אך אינה מציינת נתיב קובץ, והבדיקות מניחות נתיב קובץ מסוים לסקריפט, הסוכן עלול להיכשל שלא באשמתו. כל מה שהבודק בודק צריך להיות ברור מתיאור המשימה; סוכנים לא צריכים להיכשל עקב מפרטים עמומים. עם מודלי חזית, שיעור מעבר של 0% על פני ניסיונות רבים (כלומר 0% pass@100) הוא לרוב איתות למשימה שבורה, לא לסוכן לא כשיר, וסימן לבדוק שוב את מפרט המשימה והבודקים שלך. עבור כל משימה, שימושי ליצור פתרון ייחוס: פלט עובד ידוע שעובר את כל הבודקים. זה מוכיח שהמשימה פתירה ומאמת שהבודקים מוגדרים נכון.
שלב 3: בנה מערכי בעיות מאוזנים
בדוק גם את המקרים שבהם התנהגות צריכה להתרחש וגם את אלה שבהם היא לא צריכה. הערכות חד-צדדיות יוצרות אופטימיזציה חד-צדדית. לדוגמה, אם אתה בודק רק האם הסוכן מבצע חיפוש כשצריך, אתה עלול בסופו של דבר לקבל סוכן שמחפש כמעט הכל. נסה להימנע מהערכות מאוזנות באופן לא עקבי. למדנו זאת ממקור ראשון כשבנינו הערכות לחיפוש באינטרנט ב-Claude.ai. האתגר היה למנוע מהמודל לבצע חיפוש כשלא צריך, תוך שמירה על יכולתו לבצע מחקר נרחב כשמתאים. הצוות בנה הערכות המכסות את שני הכיוונים: שאילתות שבהן המודל צריך לחפש (כמו מציאת מזג האוויר) ושאילתות שבהן הוא צריך לענות מידע קיים (כמו "מי הקים את Apple?"). השגת האיזון הנכון בין הפעלת חסר (לא חיפוש כשצריך) או הפעלת יתר (חיפוש כשלא צריך) הייתה קשה, ודרשה סבבים רבים של חידודים הן לפרומפטים והן להערכה. ככל שעולות בעיות דוגמה נוספות, אנו ממשיכים להוסיף להערכות כדי לשפר את הכיסוי שלנו.
תכנון מערכת ההערכה והבודקים
שלב 4: בנה מערכת הערכה חזקה עם סביבה יציבה
חיוני שהסוכן בהערכה יתפקד בערך באותו אופן כמו הסוכן המשמש בייצור, ושהסביבה עצמה לא תכניס רעש נוסף. כל ניסיון הפעלה צריך להיות "מבודד" על ידי התחלה מסביבה נקייה. מצב משותף מיותר בין הרצות (קבצים שנותרו, נתונים שמורים, מיצוי משאבים) יכול לגרום לכשלים מתואמים עקב חוסר יציבות תשתיתי ולא עקב ביצועי סוכן. מצב משותף יכול גם לנפח ביצועים באופן מלאכותי. לדוגמה, בחלק מהערכות פנימיות ראינו את Claude משיג יתרון לא הוגן במשימות מסוימות על ידי בחינת היסטוריית ה-git מניסיונות הפעלה קודמים. אם ניסיונות הפעלה נפרדים רבים נכשלים בגלל אותה מגבלה בסביבה (כמו זיכרון CPU מוגבל), ניסיונות אלה אינם בלתי תלויים מכיוון שהם מושפעים מאותו גורם, ותוצאות ההערכה הופכות ללא אמינות למדידת ביצועי הסוכן.
שלב 5: תכנן בודקים בזהירות
כפי שנדון לעיל, תכנון הערכה מצוין כולל בחירת הבודקים הטובים ביותר עבור הסוכן והמשימות. אנו ממליצים לבחור בודקים דטרמיניסטיים במידת האפשר, בודקי LLM היכן שצריך או לגמישות נוספת, ולהשתמש בבודקים אנושיים בשיקול דעת לאימות נוסף.
קיימת אינסטינקט נפוץ לבדוק שסוכנים ביצעו צעדים ספציפיים מאוד כמו רצף של קריאות לכלים בסדר הנכון. מצאנו שגישה זו נוקשה מדי ומביאה לבדיקות שבירות יתר על המידה, מכיוון שסוכנים מוצאים באופן קבוע גישות תקפות שמתכנני הערכה לא ציפו להן. כדי לא להעניש יצירתיות שלא לצורך, לעיתים קרובות עדיף לדרג את מה שהסוכן הפיק, ולא את הדרך שלקח.
עבור משימות עם מספר רכיבים, כלול מתן ציון חלקי. סוכן תמיכה שמזהה נכונה את הבעיה ומאמת את הלקוח אך לא מצליח לבצע החזר כספי טוב יותר באופן משמעותי מסוכן שנכשל מיד. חשוב לייצג רצף הצלחה זה בתוצאות.
דירוג מודל דורש לעיתים קרובות איטרציה זהירה לאימות דיוק. בודקי LLM-כשופט צריכים להיות מכוילים היטב עם מומחים אנושיים כדי לצבור ביטחון שאין סטייה רבה בין הדירוג האנושי לדירוג המודל. כדי למנוע הזיות, תן ל-LLM דרך יציאה, כמו מתן הוראה להחזיר "Unknown" כאשר אין לו מספיק מידע. זה יכול גם לעזור ליצור קריטריונים ברורים ומובנים לדירוג כל ממד של משימה, ולאחר מכן לדרג כל ממד עם LLM-כשופט מבודד במקום להשתמש באחד לדירוג כל הממדים. ברגע שהמערכת יציבה, מספיק להשתמש בסקירה אנושית רק מדי פעם.
לחלק מהערכות יש מצבי כשל עדינים המביאים לציונים נמוכים גם עם ביצועי סוכן טובים, שכן הסוכן לא מצליח לפתור משימות עקב באגים בדירוג, אילוצי מערכת סוכן או עמימות. גם צוותים מתוחכמים יכולים לפספס בעיות אלו. לדוגמה, Opus 4.5 קיבל בתחילה ציון של 42% ב-CORE-Bench, עד שחוקר באנתרופיק מצא מספר בעיות: דירוג נוקשה שהעניש "96.12" כשציפה ל-"96.124991…", מפרטי משימות עמומים ומשימות סטוכסטיות שלא ניתן היה לשחזר במדויק. לאחר תיקון באגים ושימוש בפיגום פחות מוגבל, ציון Opus 4.5 קפץ ל-95%. באופן דומה, METR גילו מספר משימות שהוגדרו באופן שגוי במדד אופק הזמן שלהם, שביקשו מסוכנים לבצע אופטימיזציה לסף ציון מסוים, אך הדירוג דרש חריגה מסף זה. זה העניש מודלים כמו Claude על ביצוע ההוראות, בעוד שמודלים שהתעלמו מהמטרה המוצהרת קיבלו ציונים טובים יותר. בדיקה מדוקדקת של משימות ובוחנים יכולה לעזור למנוע בעיות אלו.
הפוך את הבודקים שלך לעמידים בפני עקיפות או פריצות. הסוכן לא אמור להיות מסוגל "לרמות" בקלות את ההערכה. משימות ובוחנים צריכים להיות מתוכננים כך שמעבר ידרוש באמת פתרון הבעיה במקום ניצול פרצות לא מכוונות.
תחזוקה ושימוש בהערכה לטווח ארוך
שלב 6: בדוק את התמלילים
לא תדע אם הבודקים שלך עובדים היטב אלא אם תקרא את התמלילים והציונים מניסיונות הפעלה רבים. באנתרופיק, השקענו בכלי צפייה בתמלילי הערכה ואנו מקדישים באופן קבוע זמן לקרוא אותם. כאשר משימה נכשלת, התמליל אומר לך האם הסוכן עשה טעות אמיתית או האם הבודקים שלך דחו פתרון תקף. הוא גם לעיתים קרובות מציף פרטים חשובים על התנהגות הסוכן וההערכה.
כשלים צריכים להיראות הוגנים: ברור מה הסוכן טעה ולמה. כאשר הציונים לא עולים, אנו זקוקים לביטחון שזה נובע מביצועי הסוכן ולא מההערכה. קריאת תמלילים היא הדרך לאמת שההערכה שלך מודדת את מה שבאמת חשוב, והיא מיומנות קריטית לפיתוח סוכנים.
שלב 7: ניטור רוויה של הערכת יכולת
הערכה ב-100% עוקבת אחר נסיגות אך אינה מספקת איתות לשיפור. רווית הערכה מתרחשת כאשר סוכן עובר את כל המשימות הניתנות לפתרון, ואינו משאיר מקום לשיפור. לדוגמה, ציוני SWE-Bench Verified החלו ב-30% השנה, ומודלי חזית מתקרבים כעת לרוויה ב->80%. ככל שהערכות מתקרבות לרוויה, ההתקדמות גם תאט, שכן רק המשימות הקשות ביותר נשארות. זה יכול להפוך את התוצאות למטעות, שכן שיפורי יכולת גדולים מופיעים כעלייה קטנה בציונים. לדוגמה, סטארט-אפ ביקורת הקוד Qodo לא התרשם בתחילה מ-Opus 4.5 מכיוון שהערכות הקידוד החד-פעמיות שלהם לא לכדו את ההישגים במשימות ארוכות ומורכבות יותר. בתגובה, הם פיתחו מסגרת הערכה סוכנית חדשה, המספקת תמונה ברורה הרבה יותר של ההתקדמות.
ככלל, איננו לוקחים ציוני הערכה כפשוטם עד שמישהו יתעמק בפרטי ההערכה ויקרא כמה תמלילים. אם הדירוג אינו הוגן, המשימות עמומות, פתרונות תקפים נענשים, או שמערכת הסוכן מגבילה את המודל, יש לתקן את ההערכה.
שלב 8: שמירה על בריאות חבילות ההערכה לטווח ארוך באמצעות תרומה ותחזוקה פתוחה
חבילת הערכה היא Artifact חי שדורש תשומת לב שוטפת ובעלות ברורה כדי להישאר שימושית.
באנתרופיק, התנסנו בגישות שונות לתחזוקת הערכה. מה שהתברר כיעיל ביותר היה הקמת צוותי הערכה ייעודיים לבעלות על תשתית הליבה, בעוד שמומחי תחום וצוותי מוצר תורמים את רוב משימות ההערכה ומריצים את ההערכות בעצמם.
עבור צוותי מוצרי AI, בעלות ואיטרציה על הערכות צריכה להיות שגרתית כמו תחזוקת בדיקות יחידה. צוותים יכולים לבזבז שבועות על תכונות AI ש"עובדות" בבדיקות מוקדמות אך לא מצליחות לעמוד בציפיות לא מוגדרות שהערכה מתוכננת היטב הייתה מציפה מוקדם. הגדרת משימות הערכה היא אחת הדרכים הטובות ביותר לבדוק עד כמה דרישות המוצר קונקרטיות מספיק כדי להתחיל לבנות.
אנו ממליצים לתרגל פיתוח מונחה הערכה: בנה הערכות כדי להגדיר יכולות מתוכננות לפני שסוכנים יכולים למלא אותן, ואז בצע איטרציות עד שהסוכן יתפקד היטב. באופן פנימי, אנו בונים לעיתים קרובות תכונות שעובדות "מספיק טוב" היום אך הן הימור על מה שמודלים יכולים לעשות בפרק זמן של מספר חודשים. הערכות יכולת שמתחילות בשיעור מעבר נמוך הופכות זאת לגלוי. כאשר מודל חדש יוצא, הרצת החבילה חושפת במהירות אילו הימורים השתלמו.
האנשים הקרובים ביותר לדרישות המוצר ולמשתמשים הם בעלי המיקום הטוב ביותר להגדיר הצלחה. עם יכולות המודל הנוכחיות, מנהלי מוצר, מנהלי הצלחת לקוחות או אנשי מכירות יכולים להשתמש ב-Claude Code כדי לתרום משימת הערכה כ-PR – תן להם! או, אפילו טוב יותר, אפשר להם באופן פעיל.
כיצד הערכות משתלבות עם שיטות אחרות להבנה הוליסטית של סוכנים
ניתן להריץ הערכות אוטומטיות כנגד סוכן באלפי משימות ללא פריסה לייצור או השפעה על משתמשים אמיתיים. אך זו רק אחת מני רבות לכלים להבנת ביצועי סוכנים. תמונה מלאה כוללת ניטור ייצור, משוב משתמשים, בדיקות A/B, סקירת תמלילים ידנית והערכה אנושית שיטתית.
סקירה של גישות להבנת ביצועי סוכני AI
הערכות אוטומטיות
- יתרונות:
- איטרציה מהירה יותר
- ניתן לשחזור מלא
- ללא השפעה על המשתמש
- ניתן להריץ בכל Commit
- בודק תרחישים בסקיילינג מבלי לדרוש פריסת ייצור
- חסרונות:
- דורש השקעה ראשונית גדולה יותר לבנייה
- דורש תחזוקה שוטפת ככל שהמוצר והמודל מתפתחים כדי למנוע סחף
- עלול ליצור ביטחון כוזב אם אינו תואם דפוסי שימוש אמיתיים
ניטור ייצור
- יתרונות:
- חושף התנהגות משתמשים אמיתית בסקיילינג
- תופס בעיות שהערכות סינתטיות מפספסות
- מספק אמת קרקע לגבי האופן שבו סוכנים מתפקדים בפועל
- חסרונות:
- ריאקטיבי; בעיות מגיעות למשתמשים לפני שאתה יודע עליהן
- איתותים יכולים להיות רועשים
- דורש השקעה במכשירים
- חסר אמת קרקע לדירוג
מבחני A/B
- יתרונות:
- מודד תוצאות משתמשים בפועל (שימור, השלמת משימות)
- שולט בבלבול
- ניתן להרחבה ושיטתי
- חסרונות:
- איטי; ימים או שבועות להגיע למובהקות ודורש תעבורה מספקת
- בודק רק שינויים שפרסת
- פחות איתות לגבי ה"למה" הבסיסי לשינויים במדדים מבלי להיות מסוגל לסקור ביסודיות את התמלילים
משוב משתמשים
- יתרונות:
- מציף בעיות שלא ציפית להן
- מגיע עם דוגמאות אמיתיות ממשתמשים אנושיים בפועל
- המשוב לעיתים קרובות מתואם עם מטרות המוצר
- חסרונות:
- דליל ובחירה עצמית
- נוטה לבעיות חמורות
- משתמשים לעיתים רחוקות מסבירים למה משהו נכשל
- לא אוטומטי
- הסתמכות עיקרית על משתמשים לתפוס בעיות עלולה להוביל להשפעה שלילית על המשתמש
סקירת תמלילים ידנית
- יתרונות:
- בונה אינטואיציה למצבי כשל
- תופס בעיות איכות עדינות שבדיקות אוטומטיות מפספסות
- עוזר לכייל איך נראה "טוב" ולתפוס פרטים
- חסרונות:
- גוזל זמן
- לא מתרחב (Scale)
- כיסוי לא עקבי
- עייפות סוקרים או סוקרים שונים יכולים להשפיע על איכות האות
- בדרך כלל נותן רק איתות איכותני ולא דירוג כמותי ברור
הערכה אנושית שיטתית
- יתרונות:
- שיפוטים באיכות סטנדרטית זהב ממספר מדרגים אנושיים
- מטפל במשימות סובייקטיביות או עמומות
- מספק איתות לשיפור בודקים מבוססי מודל
- חסרונות:
- יקר יחסית וזמן תגובה איטי
- קשה להריץ לעיתים קרובות
- אי-הסכמה בין מדרגים דורשת פיוס
- תחומים מורכבים (משפטים, פיננסים, בריאות) דורשים מומחים אנושיים לביצוע מחקרים
שיטות אלו ממופות לשלבים שונים של פיתוח סוכנים. הערכות אוטומטיות שימושיות במיוחד לפני השקה וב-CI/CD, המורצות בכל שינוי סוכן ושדרוג מודל כקו ההגנה הראשון מפני בעיות איכות. ניטור ייצור נכנס לפעולה לאחר ההשקה כדי לזהות סחף התפלגות וכשלים בלתי צפויים בעולם האמיתי. בדיקות A/B מאמתות שינויים משמעותיים ברגע שיש מספיק תעבורה. משוב משתמשים וסקירת תמלילים הם פרקטיקות מתמשכות למילוי הפערים: סנן משוב באופן קבוע, דגום תמלילים לקריאה שבועית, והתעמק לפי הצורך. שמור מחקרים אנושיים שיטתיים לכיול בודקי LLM או להערכת פלטים סובייקטיביים שבהם קונצנזוס אנושי משמש כסטנדרט ייחוס.
הצוותים היעילים ביותר משלבים שיטות אלו: הערכות אוטומטיות לאיטרציה מהירה, ניטור ייצור לאמת קרקע, וסקירה אנושית תקופתית לכיול.
מסקנה
צוותים ללא הערכות שוקעים בלופים ריאקטיביים – מתקנים כשל אחד, יוצרים אחר, אינם מסוגלים להבחין בין נסיגות אמיתיות לרעש. צוותים שמשקיעים מוקדם מוצאים את ההיפך: הפיתוח מואץ כאשר כשלים הופכים למקרי מבחן, מקרי מבחן מונעים נסיגות, ומדדים מחליפים ניחושים. הערכות נותנות לכל הצוות "גבעה ברורה לטפס עליה", והופכות את "הסוכן מרגיש גרוע יותר" למשהו בר ביצוע. הערך מצטבר, אך רק אם מתייחסים להערכות כמרכיב ליבה, לא כמחשבה שנייה.
התבניות משתנות לפי סוג הסוכן, אך היסודות המתוארים כאן קבועים. התחל מוקדם ואל תחכה לחבילה מושלמת. אסוף משימות ריאליסטיות מהכשלים שאתה רואה. הגדר קריטריוני הצלחה חד-משמעיים וחזקים. תכנן בודקים בזהירות ושילב סוגים מרובים. וודא שהבעיות קשות מספיק עבור המודל. בצע איטרציות על ההערכות כדי לשפר את יחס האות לרעש שלהן. קרא את התמלילים!
הערכת סוכני AI היא עדיין תחום חדש ומתפתח במהירות. ככל שסוכנים יקבלו על עצמם משימות ארוכות יותר, ישתפו פעולה במערכות מרובות-סוכנים ויטפלו בעבודה סובייקטיבית יותר ויותר, נצטרך להתאים את הטכניקות שלנו. נמשיך לשתף שיטות עבודה מומלצות ככל שנלמד יותר.
תודות
נכתב על ידי מיקאלה גרייס (Mikaela Grace), ג'רמי האדפילד (Jeremy Hadfield), רודריגו אוליבארס (Rodrigo Olivares) וג'ירי דה יונגה (Jiri De Jonghe). אנו אסירי תודה גם לדוד הרשי, ג'יאן סגאטו, מייק מריל, אלכס שו, ניקולס קרליני, אית'ן דיקסון, פדרם נביד, ג'ייק איטון, אליסה באום, לינה תאופיק, קארן ז'ו, אלכסנדר ברינקן, סם קנדי, רוברט יינג ואחרים על תרומתם. תודה מיוחדת ללקוחות ולשותפים שלמדנו מהם באמצעות שיתוף פעולה בהערכות, כולל iGent, Cognition, Bolt, Sierra, Vals.ai, Macroscope, PromptLayer, Stripe, Shopify, צוות Terminal Bench ועוד. עבודה זו משקפת את המאמצים הקולקטיביים של מספר צוותים שעזרו לפתח את פרקטיקת ההערכות באנתרופיק.
נספח: מסגרות הערכה
מספר מסגרות קוד פתוח ומסחריות יכולות לעזור לצוותים ליישם הערכות סוכנים מבלי לבנות תשתית מאפס. הבחירה הנכונה תלויה בסוג הסוכן שלך, הערימה הקיימת שלך, והאם אתה זקוק להערכה לא מקוונת, נראות ייצור, או שניהם.
Harbor מתוכנן להרצת סוכנים בסביבות מבוססות קונטיינרים, עם תשתית להרצת ניסיונות הפעלה בסקיילינג על פני ספקי ענן ופורמט סטנדרטי להגדרת משימות ובוחנים. מדדי ביצועים פופולריים כמו Terminal-Bench 2.0 נשלחים דרך רישום Harbor, מה שמקל על הרצת מדדי ביצועים מבוססים יחד עם חבילות הערכה מותאמות אישית.
Braintrust היא פלטפורמה המשלבת הערכה לא מקוונת עם נראות ייצור ומעקב ניסויים – שימושית לצוותים שצריכים גם לבצע איטרציות במהלך הפיתוח וגם לנטר איכות בייצור. ספריית ה-`autoevals` שלה כוללת בוחנים מובנים לעובדתיות, רלוונטיות וממדים נפוצים אחרים.
LangSmith מציעה מעקב, הערכות לא מקוונות ומקוונות, וניהול מערכי נתונים עם אינטגרציה הדוקה למערכת האקולוגית של LangChain. Langfuse מספקת יכולות דומות כחלופת קוד פתוח עצמאית לצוותים עם דרישות מיקום נתונים.
Arize מציעה את Phoenix, פלטפורמת קוד פתוח למעקב, דיבוג והערכות לא מקוונות או מקוונות של LLM, וכן את AX, פתרון SaaS המרחיב את Phoenix לצורך סקיילינג, אופטימיזציה וניטור.
צוותים רבים משלבים כלים מרובים, בונים מסגרת הערכה משלהם, או פשוט משתמשים בסקריפטים פשוטים של הערכה כנקודת התחלה. אנו מוצאים שבעוד שמסגרות יכולות להיות דרך בעלת ערך להאצת ההתקדמות ולסטנדרטיזציה, הן טובות רק כמו משימות ההערכה שאתה מריץ דרכן. לעיתים קרובות עדיף לבחור במהירות מסגרת שמתאימה לזרימת העבודה שלך, ואז להשקיע את האנרגיה שלך בהערכות עצמן על ידי ביצוע איטרציות על מקרי מבחן ובוחנים באיכות גבוהה.
