LLM Evals — איך באמת מודדים איכות של מערכת AI

מאת צוות מדיה דיל · 09.08.2026 · AI · 6 דק׳

בלי בדיקות אוטומטיות, כל שינוי בפרומפט או במודל הוא הימור. מדריך מעשי לבניית Evals: סוגי מדדים, LLM-as-judge, סטים שקטים, ואיך לתפוס רגרסיות לפני הלקוחות.

צוות משנה נוסח ב-System Prompt כדי לתקן בעיה ספציפית שדווחה, מעלה לפרודקשן, ומגלה שבועיים אחר כך שהשינוי שיפר תרחיש אחד אבל פגע בחמישה תרחישים אחרים שאף אחד לא בדק. בלי דרך שיטתית למדוד איכות, כל שינוי במערכת AI — פרומפט, מודל, כלי חדש — הוא הימור. LLM Evals הם תשובת ההנדסה לבעיה: סט בדיקות אוטומטיות שמודדות איכות בצורה עקבית, ומאפשרות להשוות גרסאות לפני שהן פוגשות משתמשים אמיתיים.

למה בדיקות רגילות (unit tests) לא מספיקות

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

מי כותב את ה-Rubric ואיך הוא נשמר עקבי

כשמשתמשים ב-LLM-as-Judge, איכות ה-rubric (הקריטריונים שלפיהם השופט מעריך) קובעת את אמינות כל מערכת ה-Evals. Rubric עמום ("תשובה טובה") ייתן ציונים לא עקביים; rubric מפורט עם דוגמאות לתשובה טובה וגרועה ייתן שיפוט הרבה יותר אמין. מומלץ לכתוב את ה-rubric כרשימת קריטריונים ברורים ומדידים (לא "האם התשובה טובה" אלא "האם התשובה מזכירה את מדיניות ההחזרות הנכונה, לא מבטיחה יותר ממה שקיים, ובטון מקצועי"), ולבחון את הרובריק עצמו על תשובות ידועות מראש כדי לוודא שהשופט מדרג אותן כצפוי לפני שסומכים עליו על תשובות חדשות.

שני סוגי מדדים: דטרמיניסטיים ו-LLM-as-Judge

• מדדים דטרמיניסטיים — בדיקות שאפשר לחשב באופן מכני: האם הפלט תקין כ-JSON, האם נעשה שימוש בכלי הנכון, האם התשובה מכילה מילת מפתח נדרשת, האם אורך התשובה בטווח סביר. מהירים, זולים ואמינים לחלוטין — אבל מוגבלים למה שניתן לבדוק בכללים פשוטים.
• LLM-as-Judge — שימוש במודל שפה נוסף כדי לשפוט את איכות התשובה מול קריטריונים (נכונות, רלוונטיות, טון). מאפשר להעריך היבטים סובייקטיביים שקשה לתפוס בכללים, אך מוסיף עלות, latency, ורעש — השופט עצמו לא תמיד עקבי, ודורש כיול וניסוח קפדני של ה-rubric שהוא שופט לפיו.

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

eval_case = {
  "input": "מה מדיניות ההחזרות שלכם?",
  "checks": [
    {"type": "must_contain", "value": "30 יום"},
    {"type": "tool_called", "value": "get_return_policy"},
    {"type": "llm_judge", "rubric": "התשובה מדויקת, אדיבה, ולא מבטיחה דבר שלא באמת קיים במדיניות"}
  ]
}

מדידת עקביות (Consistency) לא רק דיוק

מעבר לשאלה "האם התשובה נכונה", יש שאלה חשובה לא פחות: "האם המערכת עונה באופן דומה לשאלות דומות". חוסר עקביות — שבו אותה שאלה בניסוח שונה מעט מקבלת תשובות סותרות — פוגע באמון המשתמשים גם כשכל תשובה בנפרד "נכונה" טכנית. Evals לעקביות בודקים זאת במפורש: מריצים כמה ניסוחים שונים של אותה שאלה עצמה ובודקים שהתשובות מתואמות זו לזו, לא רק שכל אחת עומדת בקריטריון עצמאי. זו בעיה שמחמירה ככל שההקשר גדל ומורכב יותר, ומתקשרת ישירות לאיכות ה-Context Engineering של המערכת.

בניית Golden Dataset

ליבת מערכת Evals היא סט תרחישים ("golden dataset") שמייצג את השימושים האמיתיים במערכת — כולל מקרי קצה, לא רק תרחישים "שמחים". מקורות טובים לבניית הסט: שיחות אמיתיות מפרודקשן שסומנו כבעייתיות (כדי לוודא שבעיה שתוקנה לא חוזרת), תרחישים שידועים כקשים למודל (עמימות, מידע חסר, בקשות סותרות), ומקרי גבול שנוגעים במדיניות רגישה. סט שמכיל רק תרחישים קלים ייתן ביטחון שווא — הוא לא יתפוס את הבעיות שבאמת קורות בשטח.

Regression Testing: תפיסת שינוי לרעה לפני שהוא יוצא

אחד השימושים החשובים ביותר ב-Evals הוא לא בדיקת איכות מוחלטת, אלא בדיקת רגרסיה יחסית: האם השינוי החדש (בפרומפט, במודל, בכלים) שיפר או פגע ביחס לגרסה הקודמת. זה דורש להריץ את אותו סט תרחישים על שתי הגרסאות ולהשוות ציונים אחד מול השני, לא רק לבדוק שכל גרסה "עברה" סף מסוים. שיטה זו חושפת trade-offs נסתרים — למשל שינוי שמשפר תרחיש נפוץ אחד אבל פוגע בעשרה תרחישי קצה נדירים, מה שקל מאוד לפספס בבדיקה ידנית ממוקדת רק בבעיה שהניעה את השינוי מלכתחילה.

מתי מריצים Evals: CI, Pre-deploy, וניטור שוטף

Evals לא רצים פעם אחת — הם צריכים להיות חלק מתהליך העבודה השוטף: בזמן פיתוח כדי לבדוק מהר אם שינוי בפרומפט משפר או פוגע; לפני דיפלוי כשער איכות שחוסם שחרור אם ציון ירד מתחת לסף; ובאופן שוטף על תעבורה חיה — מדגם קבוע מבקשות אמיתיות שנבדק ברקע כדי לתפוס התדרדרות הדרגתית שלא קשורה לשינוי קוד (למשל שינוי בהתנהגות מודל בגרסה חדשה מהספק). ראו CI/CD מותאם AI וLLM Observability.

מדדים ברמת המערכת מול ברמת השלב

במערכת אגנטית עם כמה שלבים (שליפת מידע, קריאה לכלי, ניסוח תשובה), אפשר למדוד איכות בשתי רמות: End-to-End — האם התוצאה הסופית נכונה, בלי קשר איך הגיעו אליה; וברמת השלב (component-level) — האם כל שלב בנפרד ביצע נכון (האם השליפה החזירה מסמכים רלוונטיים, האם הכלי הנכון נבחר). מדידה End-to-End בלבד מקשה לאתר איפה בדיוק השרשרת נכשלה כשהתוצאה הסופית שגויה — האם הבעיה בשליפה, בבחירת כלי, או בניסוח. מדידה ברמת שלב מאפשרת לנפות שגיאות הרבה יותר מהר, אך דורשת בניית evals נפרדים לכל שלב, מה שמכפיל את מאמץ הבנייה הראשוני.

Trade-offs מרכזיים

• כיסוי מול עלות — סט evals גדול יותר תופס יותר תרחישים אך עולה יותר להריץ (במיוחד עם LLM-as-Judge); צריך לאזן בין ביטחון לעלות ריצה.
• אוטומציה מול שיפוט אנושי — evals אוטומטיים מהירים וניתנים להרצה תדירה, אך לא מחליפים לגמרי סקירה אנושית תקופתית, שתופסת ניואנסים שקשה לתאם ל-rubric.
• ספציפיות מול כלליות — מדד ספציפי מדי (בדיקת מילת מפתח מדויקת) שביר לשינויי ניסוח לגיטימיים; מדד כללי מדי (LLM-as-Judge בלי rubric ברור) לא עקבי מספיק. המפתח הוא rubric מפורט ומדויק.

דוגמה מהשטח

צוות שהריץ Agent לשירות לקוחות בלי evals גילה בעיה רק אחרי שלקוחות התלוננו: שינוי קטן במודל שהמערכת השתמשה בו (שדרוג גרסה) גרם לירידה בדיוק בזיהוי מתי להסלים פנייה לנציג אנושי. הקמת סט evals עם 40 תרחישי הסלמה קלאסיים אפשרה לתפוס ירידה כזו באופן אוטומטי בכל פעם שמעדכנים מודל או פרומפט, לפני שהיא מגיעה למשתמשים — והפכה שדרוגי מודל עתידיים לתהליך הרבה פחות מסוכן.

שאלות נפוצות

כמה תרחישים צריך בסט Evals כדי שיהיה אמין?

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

האם LLM-as-Judge אמין מספיק?

כשה-rubric מנוסח היטב וממוקד, כן, ברמה שימושית להרבה מקרים. חשוב לבדוק את עקביות השופט עצמו (להריץ אותה בדיקה כמה פעמים ולבדוק שהציון יציב) ולהתייחס לתוצאותיו כאינדיקציה חזקה, לא כאמת מוחלטת.

איך Evals שונים מ-A/B Testing?

Evals רצים על סט תרחישים קבוע ומבוקר, לפני שינוי מגיע למשתמשים אמיתיים. A/B Testing בודק ביצועים בפועל מול משתמשים חיים. שניהם משלימים: evals כשער איכות מוקדם, A/B כאימות סופי בעולם האמיתי.

מי בצוות אמור לכתוב את תרחישי ה-Evals?

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

האם Evals מחליפים בדיקות ידניות לגמרי?

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

כמה עולה להריץ Evals בקנה מידה גדול?

תלוי בכמות התרחישים ובשימוש ב-LLM-as-Judge — כל בדיקה שמערבת קריאת מודל נוספת עולה כסף. עלות זו בדרך כלל זניחה ביחס לעלות תקלה בפרודקשן שלא נתפסה, אבל שווה לתכנן תדירות הרצה (על כל commit, פעם ביום, רק לפני דיפלוי) בהתאם לתקציב.

בניית מערכות AI שעומדות בעומס אמיתי דורשת יותר מהבנה תיאורטית — היא דורשת ניסיון בהרצת סוכנים בפרודקשן. בצוות מדיה דיל אנחנו מלווים חברות בתכנון וביישום של ארכיטקטורות AI, מ-פתרונות AI מותאמים ועד תשתית פרודקשן יציבה. רוצים לדבר על המערכת שלכם? דברו איתנו ב-וואטסאפ.

תגיות: LLM Evals · AI Quality · LLM as Judge · Golden Dataset · Regression Testing · AI Testing

← חזרה לבלוג · צור קשר