מדריך מבוסס מחקר לבניית מערך AI Evals: תרחישים, Golden Set, רובריקה, LLM-as-a-Judge, בדיקה אנושית ושערי עלייה לייצור. הדגמה מרשימה אינה בדיקת איכות. מערכת AI בארגון צריכה להיבחן על המשימות, השפה, המסמכים, מקרי הקצה והסיכונים של הארגון עצמו. Evals הם תהליך חוזר שמריץ קבוצת תרחישים, בודק תוצאה לפי קריטריונים ומתעד שינוי בין גרסאות. המטרה אינה להפיק מספר קסם, אלא לדעת באילו תנאים המערכת מועילה, היכן היא נכשלת ומה חייב לעבור לאדם לפני פרסום או פעולה.
- איכותלפי משימה
- בטיחותתנאי פסילה
- יעילותזמן ועלות
- יציבותRegression
כל כשל חדש נכנס לסט הבדיקה ומחזק את הגרסה הבאה.
מהו Eval ארגוני
Eval הוא ניסוי חוזר שבו קלט מוגדר עובר במערכת והתוצאה נבדקת מול ציפייה, רובריקה או שיפוט מומחה. יחידת הבדיקה יכולה להיות תשובה, מסמך, אחזור מקור, בחירת כלי או השלמת Workflow. Benchmark ציבורי עוזר להבין יכולת כללית; Eval ארגוני בודק כשירות לתפקיד מסוים.
מערך טוב שומר את גרסת המודל, הפרומפט, המקורות, הכלים, הטמפרטורה והתאריך. בלעדיהם קשה לדעת אם שינוי בציון נובע מהמודל, מהקלט או מהסביבה. משווים תהליך מלא ולא רק את הטקסט האחרון.
- משימה ויחידת בדיקה
- קלט ותוצאה צפויה
- רובריקה ושופט
- גרסה ותנאי הרצה
בונים Golden Set שמייצג את העבודה
אוספים דוגמאות אמיתיות לאחר הסרה או טשטוש של מידע רגיש, ומחלקים אותן לתרחישים שכיחים, מקרי קצה ותסריטים עוינים. בסט עברי צריך לכלול עברית מקצועית, קיצורים, מספרים, תאריכים, שלילה ומעבר בין עברית לאנגלית. אין צורך להתחיל באלפי דוגמאות; חשוב יותר שכל דוגמה תייצג החלטה או כשל משמעותי.
מומחה תחום מגדיר מהי תשובה טובה ומה אסור שיקרה. חלק מהסט נשמר לבדיקת נסיגה ואינו משמש לשיפור הפרומפט. אחרת הצוות עלול להתאים את המערכת למבחן במקום לעבודה.
- תרחישים שכיחים
- Edge Cases
- קלט עוין או חסר
- סט נסיגה שמור
לא כל מדד מתאים לכל מערכת
בפלט מובנה אפשר לבדוק שדות, פורמט וחוקים בקוד. בסיכום או ניסוח נדרשת רובריקה עם ממדים כמו דיוק, שלמות, בהירות וטון. במערכת RAG בודקים בנפרד אם אוחזר המקור הנכון, אם התשובה נאמנה להקשר ואם הציטוט תומך בטענה. בסוכן בודקים בחירת כלי, פרמטרים, הרשאה, תוצאה ויכולת התאוששות.
לצד איכות מודדים זמן תגובה, עלות, שיעור תיקון, סירוב ראוי והפרות קריטיות. ממוצע גבוה יכול להסתיר כשל שאסור לקבל, ולכן מגדירים תנאי פסילה כמו חשיפת מידע, פעולה ללא אישור או המצאת מקור.
- דיוק ושלמות
- Faithfulness ומקור
- Tool Correctness
- עלות, זמן ותנאי פסילה
LLM-as-a-Judge עם בקרת אדם
מודל שפה יכול להחיל רובריקה במהירות על אלפי תוצאות, להשוות זוג תשובות ולהסביר את הציון. מחקר MT-Bench הראה התאמה שימושית לשיפוט אנושי בחלק מהמשימות, אך גם הטיות של מיקום, אורך והעדפת סגנון או מודל. לכן שופט אוטומטי הוא מכשיר מדידה שצריך לכייל, לא סמכות אמת.
מתחילים במדגם שמסומן בידי שני מומחים, משווים את השופט לאדם, מעדכנים רובריקה ובודקים שוב. מסתירים את שם המודל, מחליפים את סדר התשובות וחוזרים על מקרים גבוליים. החלטות בעלות השפעה גבוהה נשארות בבקרה אנושית.
- כיול מול מומחים
- Blind Review
- החלפת סדר תשובות
- בדיקה חוזרת למקרה גבולי
משער עלייה לייצור לניטור שוטף
לפני פיילוט מגדירים סף איכות, אפס סובלנות לכשלים קריטיים, מגבלת זמן ועלות ושיעור מקסימלי של העברה לאדם. מריצים את אותו סט על הגרסה הקיימת והמועמדת ומציגים גם אי-ודאות, לא רק ממוצע. אם השיפור קטן מהשונות, אין בסיס מוצק להכריז על ניצחון.
לאחר עלייה לייצור דוגמים תוצאות, אוספים תיקונים ותלונות והופכים כשל חדש לדוגמת Eval. שינוי מודל, פרומפט, מקור, כלי או מדיניות מפעיל בדיקת נסיגה. כך Evals הופכים מחסם חד-פעמי למערכת למידה שמחברת איכות, סיכון וערך עסקי.
- Go/No-Go מוגדר מראש
- השוואה מול Baseline
- ניטור ותחקור
- Regression בכל שינוי
סקירה מדעית: הערכה היא מערכת מדידה
HELM של Stanford הציע הערכה הוליסטית שבה מודלים נבחנים על תרחישים ומדדים רבים, ובהם דיוק, כיול, עמידות, הוגנות, הטיה, רעילות ויעילות. הרעיון המרכזי הוא שאין ציון יחיד שמייצג כשירות לכל שימוש. ארגון צריך לבחור את הצירים שמתאימים להשפעה ולמשימה שלו.
NIST AI 800-3, שפורסם בפברואר 2026, בחן 22 מודלי חזית על GPQA-Diamond, BIG-Bench Hard ו-Global-MMLU Lite והדגים שימוש ב-Generalized Linear Mixed Models. הגישה מעריכה לא רק דיוק, אלא גם אי-ודאות, שונות וקושי של פריטים. NIST אינו ממליץ על מודל מסוים; הוא מרחיב את ארגז הכלים הסטטיסטי להערכת ביצוע.
- כמה תרחישים
- כמה מדדים
- אי-ודאות ושונות
- התאמה לשימוש
Best Practices של NIST: תוקף, שקיפות ושחזור
טיוטת NIST AI 800-2 מינואר 2026 מציעה עקרונות ראשוניים ל-Automated Benchmark Evaluations של מודלי שפה וסוכנים. נכון למועד פרסום המאמר זהו מסמך טיוטה, לא תקן סופי. הדגש הוא על תוקף המדידה, שקיפות של התצורה ושחזור התוצאה.
ביישום ארגוני מתעדים Dataset, גרסה, Prompt Template, כלי, מקור, הגדרות דגימה ושיטת שיפוט. כאשר ספק מעדכן מודל ללא שינוי שם, Snapshot מתוארך וסט נסיגה מאפשרים לזהות שינוי. תוצאה שאי אפשר לשחזר היא תצפית, לא בסיס למדיניות.
- Draft ולא תקן סופי
- תוקף
- שקיפות
- Reproducibility
LLM-as-a-Judge: שימושי אך מוטה
מחקר MT-Bench ו-Chatbot Arena מצא ששופטי LLM חזקים יכולים להתאים במידה שימושית להעדפות אנושיות, אך תיעד הטיית מיקום, העדפת תשובה ארוכה והעדפה עצמית. מחקר Position Bias שנשלח לראשונה ב-2024 ועודכן ב-2025 בחן 15 שופטים, 22 משימות ויותר מ-150 אלף מופעי הערכה והראה שהטיית סדר היא תופעה ממשית.
לכן מריצים השוואה בשני סדרים, מסתירים זהות, מגדירים רובריקה עם דוגמאות ומכיילים מול מומחים. מדווחים הסכמה בין שופטים ולא רק ציון. אם אדם ומודל אינם מסכימים במקרי סיכון, בודקים את הדוגמה במקום למצע אותה.
- Position Bias
- Verbosity Bias
- כיול אנושי
- הסכמה בין שופטים
Evals למערכת RAG ולזיהוי הזיות
RAGAS מציעה מדדים ללא תווית אנושית מלאה להערכת רלוונטיות הקשר, Faithfulness ואיכות תשובה במערכת Retrieval-Augmented Generation. SelfCheckGPT משתמש בעקביות בין דגימות כדי לאתר טענות שסביר שהן הזיה. שתי הגישות שימושיות לסינון ולניטור, אך אינן מוכיחות אמת עובדתית.
ב-RAG ארגוני צריך לפתוח את המקור ולבדוק אם הוא סמכותי, עדכני ותומך בטענה. עקביות של כמה תשובות שגויות אינה דיוק, ו-Faithfulness למסמך ישן אינה עדכניות. משלבים בדיקה אוטומטית עם מומחה תחום ומדד מקור.
- Retrieval Relevance
- Faithfulness
- עקביות אינה אמת
- בדיקת מקור אנושית
עיצוב Eval שמוביל להחלטה
כל תרחיש מקושר להחלטה: האם לפרסם, להפעיל כלי, להעביר לאדם או לעצור. מגדירים משקל לפי תדירות ונזק, אך כשלים קריטיים נשארים תנאי פסילה ולא נבלעים בממוצע. סט הבדיקה כולל Baseline אנושי או מערכת קיימת כדי לדעת אם השינוי באמת משפר את העבודה.
בדוח מציגים התפלגות, רווח סמך, כשל בולט ועלות לתוצאה מאושרת. ההנהלה אינה זקוקה לאלף ציונים אלא לתשובה: היכן המערכת עובדת, מה הגבול, מי הבעלים ומה יגרום לעצירה. כך Eval מחבר מחקר, ניהול סיכון ומוניטיזציה של שימוש מועיל.
- החלטה לכל תרחיש
- Baseline
- תנאי פסילה
- עלות לתוצאה מאושרת
מדריך יישומי: כך מתחילים עם AI Evals ארגוניים
כדי להפוך את הקריאה לפעולה, בחרו יחידה אחת ומשימה אחת. תארו כיצד היא מתבצעת היום, מי מעורב, איזה מידע נדרש ומהי תוצאה טובה. לאחר מכן נסחו השערה קטנה: כיצד AI Evals ארגוניים עשוי לשפר זמן, איכות, בהירות או למידה. הימנעו מיעד כללי כמו “להשתמש יותר ב-AI”; יעד שימושי מתאר התנהגות ותוצר שאפשר לראות.
בשלב הבא מומלץ לבנות Golden Set, רובריקה, כיול אנושי ושער Go/No-Go עם בדיקות נסיגה. השתמשו רק בכלי ובמידע שאושרו, הגדירו קריטריונים לפני הפעלת הכלי ושמרו גרסה של התהליך הקיים. התייחסו לניסיון הראשון כאל פיילוט ללמידה. אם התוצאה חלשה, בדקו אם הבעיה נבעה מהגדרת משימה, מקור, הרשאה, תדריך, יכולת הכלי או בקרת האדם — ולא רק אם הפרומפט היה ארוך מספיק.
- משימה אחת וקהל מוגדר
- קו בסיס של זמן ואיכות
- כלי ומידע מאושרים
- קריטריונים ותיעוד
תכנית עבודה ל-30 יום
בשבוע הראשון ממפים את המשימה, אוספים שתי דוגמאות ומגדירים כללי מידע. בשבוע השני מקיימים הדרכה ותרגול מונחה, ובונים תבנית ראשונה. בשבוע השלישי המשתתפים מפעילים את השיטה בעבודה ומתעדים תוצאה, תיקון ושאלה. בשבוע הרביעי משווים לקו הבסיס, משתפים לקחים ומחליטים אם לשפר, להרחיב או לעצור.
הקצב חשוב יותר מהיקף התוכן. עדיף ניסוי קטן עם משוב מאשר קורס רחב שאין אחריו יישום. מנהל הקבוצה צריך להקצות זמן, להסיר חסם ולהבהיר שאין להסתיר טעויות. שגריר AI או מומחה מלווה מרכז שאלות חוזרות והופך אותן לחומר למידה. כך הידע שנוצר בפיילוט הופך לנכס ארגוני.
- שבוע 1 — מיפוי וקו בסיס
- שבוע 2 — הדרכה ותבנית
- שבוע 3 — יישום ומשוב
- שבוע 4 — מדידה והחלטה
שאלות ביקורת לפני שמרחיבים
לפני הרחבה שאלו האם המשתמשים יודעים להסביר מתי להשתמש ומתי לא, האם הם פותחים מקורות, מהי עלות התיקון והאם התהליך עובד גם בקלט שאינו מושלם. בדקו מי מרוויח מהשינוי, מי נושא בעומס חדש ומה קורה כאשר הכלי אינו זמין. שאלות אלה מונעות מצב שבו הדגמה מוצלחת הופכת במהירות לסטנדרט לא יציב.
לבסוף, ודאו שקיימים בעלים, מדד וקצב עדכון. AI משתנה במהירות, אך ארגון אינו יכול לשנות נורמות מדי יום. בנו עקרונות יציבים, רשימת כלים מתעדכנת וספריית תרחישים שעוברת בדיקה. הרחיבו רק כאשר אפשר לשחזר את התהליך, להדריך עובד חדש ולהסביר את ההחלטה לגורם מקצועי או ניהולי.
- אפשר להסביר ולשחזר
- המקורות וההרשאות ברורים
- עלות התיקון סבירה
- קיימים בעלים ומנגנון עדכון
להמשיך מהידע ליכולת
מה לקחת מכאן?
- Benchmark ציבורי אינו מחליף בדיקה על משימות הארגון
- Golden Set טוב כולל שגרה, קצה וכשל קריטי
- LLM-as-a-Judge דורש כיול ובדיקת אדם
- עולים לייצור רק עם ספים, תיעוד וניטור נסיגה
המקורות שעליהם נשענת הסקירה
- Liang et al. (2022), Holistic Evaluation of Language Models (HELM)
- NIST (2026), AI 800-3: Expanding the AI Evaluation Toolbox with Statistical Models
- NIST (2026, draft), Towards Best Practices in Automated Benchmark Evaluations
- Zheng et al. (2023), Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena
- Shi et al. (2024), Judging the Judges: Position Bias in LLM-as-a-Judge
- Es et al. (2024), RAGAS: Automated Evaluation of Retrieval Augmented Generation
- Manakul et al. (2023), SelfCheckGPT: Zero-Resource Black-Box Hallucination Detection
המקורות נועדו להעמקה ואינם תחליף לייעוץ משפטי, מדעי או מקצועי המותאם לארגון.
רוצים להפוך את הידע לתכנית עבודה?
המכון הישראלי לבינה מלאכותית יבנה עבורכם הרצאת בינה מלאכותית, הרצאת AI, סדנה מעשית או סדרת 3–5 מפגשים שמותאמת לאנשים, לכלים ולמשימות בארגון.
למעבדת Use Cases ו-Evals ארגונית