Evaluation Registry: איך יודעים אם ה-AI שלכם משתפר או מתדרדר

מאת צוות מדיה דיל · 04.08.2026 · Enterprise AI · 7 דק׳

בלי Evaluation Registry כל שינוי במערכת AI הוא הימור. הנה איך בונים test sets, שערי איכות ב-CI/CD, ומדידה עקבית שהופכת שיפור מערכת AI לתהליך מבוקר.

השאלה שכל מנהל הנדסה שואל אחרי שהצוות משנה פרומפט או מחליף מודל היא פשוטה: "האם זה טוב יותר או גרוע יותר מהגרסה הקודמת?" ובכל זאת, ברוב הארגונים, התשובה היחידה שיש היא "אני חושב שכן, ניסיתי כמה דוגמאות והן נראו סבירות". זו לא תשובה שאפשר לבנות עליה מערכת production אמינה. Evaluation Registry הוא התשתית שהופכת את השאלה הזו משיפוט סובייקטיבי למדידה חוזרת: קבוצה מתועדת של תרחישי בדיקה, שיטת ניקוד עקבית, וניקוד היסטורי שאפשר להשוות אליו בכל פעם שמשהו במערכת משתנה - פרומפט, מודל, כלים, או קונפיגורציה. בלי Registry כזה, כל שינוי הוא הימור; איתו, כל שינוי הוא ניסוי מבוקר עם תוצאה מדידה.

מה זה בעצם Evaluation, ולמה בדיקות רגילות לא מספיקות

בדיקות תוכנה קלאסיות (unit tests) עובדות מצוין כשיש תשובה נכונה אחת ויחידה: פונקציה שמקבלת קלט X חייבת להחזיר פלט Y, ואם לא - הבדיקה נכשלת. מערכות AI מבוססות שפה טבעית לא עובדות ככה: אותה שאלה יכולה לקבל אינספור תשובות תקינות שונות בניסוח, וההבדל בין תשובה טובה לגרועה הוא לרוב עניין של מידה ולא של נכון/לא נכון בינארי. לכן Evaluation במובן הזה קרוב יותר לבדיקת איכות מוצר מאשר לבדיקת תוכנה מסורתית - הוא דורש שילוב של metrics אוטומטיים (למשל בדיקת פורמט, קריאה נכונה לכלים, זמן תגובה), ושיפוט איכותי, בין אם על ידי מודל שיפוט (LLM-as-judge) ובין אם על ידי בודקים אנושיים במדגם.

אנטומיה של Evaluation Registry

Registry תקין בנוי משלושה רכיבים שנשמרים ומתוחזקים בנפרד: ראשית, בנק התרחישים (test set) - אוסף קבוע ומתועד של קלטים ייצוגיים, כולל מקרי קצה ידועים, שכל שינוי חייב לעבור מולם. שנית, פונקציית הניקוד (scorer) - הלוגיקה שמחליטה מה נחשב תשובה טובה, שיכולה לשלב בדיקות דטרמיניסטיות פשוטות עם שיפוט מודל מורכב יותר. שלישית, היסטוריית התוצאות - כל ריצה של כל גרסה נגד ה-test set נשמרת עם ציון מלא, ומאפשרת השוואה ישירה בין כל שתי נקודות בזמן. שלושת הרכיבים האלה יחד יוצרים בסיס שממנו אפשר לגזור מדיניות אוטומטית: "גרסה חדשה לא עולה ל-production אם הציון שלה נמוך מ-2 אחוז מהבייסליין".

{
  "eval_suite": "support-triage-core",
  "version_tested": "prompt-registry:v12",
  "model": "claude-sonnet-4-5",
  "test_cases": 340,
  "score_overall": 0.94,
  "score_by_category": {
    "urgent_escalation": 0.97,
    "refund_requests": 0.89,
    "multilingual_he": 0.91
  },
  "regressions_vs_baseline": [],
  "run_at": "2026-08-01T06:00:00Z"
}

LLM-as-Judge: כוח ומגבלות

הדרך המעשית ביותר לנקד תשובות פתוחות בקנה מידה היא להשתמש במודל שפה נוסף כשופט - מודל שמקבל את השאלה, את התשובה, ולעיתים גם קריטריונים מפורשים, ומחזיר ציון או פסק דין. הטכניקה הזו יעילה ומתקנת אך רגישה למה שנקרא judge bias: מודלי שפה נוטים להעדיף תשובות ארוכות יותר, תשובות שמזכירות מונחים טכניים, ותשובות שדומות בסגנון לאיך שהם עצמם היו כותבים. Registry בוגר מטפל בזה על ידי כיול תקופתי של השופט מול דירוג אנושי על מדגם קטן, ועל ידי הרצת אותו תרחיש מול כמה שופטים שונים (לפעמים אפילו מודלים שונים) ובדיקת קונצנזוס, כדי לזהות מקרים שבהם שופט בודד סוטה מהקונצנזוס הכללי.

Golden Sets מול Live Traffic Sampling

יש שני מקורות משלימים לתרחישי בדיקה, ושניהם חשובים. Golden Set הוא אוסף קבוע ומתוחזק ידנית של מקרים ייצוגיים ומקרי קצה קריטיים - הוא יציב, ניתן לחזרה, ומשמש כבסיס להשוואה עקבית לאורך זמן. Live Traffic Sampling, לעומת זאת, שולף מדגם אקראי משיחות אמיתיות מהשבוע האחרון, ומזהה תרחישים חדשים שהמערכת לא נתקלה בהם קודם - התנהגות משתמשים משתנה, ניסוחים חדשים, ותרחישי שימוש שאף אחד לא חשב עליהם מראש. Registry שמשלב את שני המקורות, ומעדכן את ה-Golden Set מעת לעת עם תרחישים חדשים ומעניינים שהתגלו ב-Live Sampling, נשאר רלוונטי לאורך זמן במקום להתיישן ולהיות עיוור לדפוסי שימוש מתפתחים.

שערי איכות אוטומטיים ב-CI/CD

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

מדידת עלות ו-Latency לצד איכות

Evaluation Registry שמסתכל רק על איכות תשובה מפספס חצי מהתמונה. כל ריצה צריכה למדוד גם עלות טוקנים וגם זמן תגובה, כי בפועל צוותים מקבלים החלטות פשרה מתמדות בין השלושה - גרסה שמשפרת איכות בשני אחוזים אבל מכפילה latency עלולה להיות בחירה גרועה עבור Agent שרץ בזמן אמת מול משתמש שמחכה לתשובה. הצגת שלושת הצירים יחד באותו דוח, ולא בכלים נפרדים, היא מה שמאפשר לצוות מוצר לקבל החלטה מושכלת על ה-trade-off, במקום לייעל עיוור אחר ציון איכות בלבד.

טעויות נפוצות בפרודקשן

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

מתי כדאי להשקיע, ומתי זה מוקדם

ברגע שיש בארגון Agent שמקבל יותר מכמה עשרות אינטראקציות ביום, ובוודאי כשהוא נוגע בכסף, בתמיכה, או בהחלטות עסקיות, Evaluation Registry הוא לא luxury - הוא התנאי היחיד לשינוי בטוח. השקעה של שבוע-שבועיים בבניית test set ראשוני ולוגיקת ניקוד בסיסית משתלמת כבר בפעם הראשונה שהיא תופסת רגרסיה לפני שהיא מגיעה ללקוחות. עבור פרויקט ניסיוני עם משתמש יחיד, אפשר להסתפק בבדיקה ידנית פשוטה - אך ברגע שהפרויקט עובר לשלב הרצת production, בניית ה-Registry היא ההשקעה הבאה שצריכה לקרות, לפני כל שינוי משמעותי נוסף.

קישור בין Evaluation Registry לבין Canary ו-Rollback

Evaluation Registry לא צריך לפעול רק לפני פריסה - הוא צריך להמשיך לרוץ גם אחריה, על תעבורה אמיתית, כחלק ממנגנון ניטור מתמשך. כשגרסה חדשה עולה בהדרגה בשיטת AI Canary Releases, ציוני ה-Evaluation על אותו פלח קטן של תעבורה הם בדיוק האות שמחליט אם ממשיכים להרחיב את הפריסה או מבצעים rollback מיידי בהתאם לעקרונות שמפורטים ב-Model Rollback Architecture. בלי הרצה מתמשכת כזו, גרסה יכולה "לעבור" את הבדיקה המקדימה מול ה-Golden Set אך עדיין להתנהג אחרת לגמרי מול תנאי production אמיתיים - עומס, קלטים לא צפויים, ואינטראקציה עם מערכות חיצוניות שלא נכחו בסביבת הבדיקה.

ניהול עלות ריצת Evaluation עצמה

אירוניה מוכרת בעולם ה-AI היא שהרצת סוללת Evaluation מלאה, כשהיא כוללת אלפי תרחישים ושיפוט LLM-as-judge לכל אחד, יכולה להיות יקרה יותר מהרצת המערכת עצמה בפרודקשן לאורך יום שלם. Registry בוגר מנהל את זה על ידי הפרדה בין סוללת smoke test מהירה וזולה שרצה על כל commit (מדגם קטן של תרחישים קריטיים ביותר), לבין סוללה מלאה שרצה פעם ביום או רק לפני פרומוציה סופית ל-production. איזון נכון בין תדירות ההרצה לעלותה הוא החלטה הנדסית לגיטימית, ולא פשרה על איכות - כל עוד סוללת ה-smoke test מכסה את התרחישים הקריטיים ביותר שהיסטורית גרמו לתקריות.

מי בונה ומתחזק את סוללת הבדיקות

שאלה ארגונית שלא פחות חשובה מהשאלה הטכנית היא מי אחראי בפועל על תוכן ה-test set. הניסיון מלמד שהאחריות לא יכולה להיות רק על צוות ההנדסה, כי מי שמבין הכי טוב מה נחשב תשובה טובה במשימה עסקית ספציפית הם לרוב אנשי המוצר, נציגי תמיכה ותיקים, או מומחי תוכן בתחום. מודל עבודה יעיל משלב bounty-style תהליך: כל פעם שמתגלה תקלה בפרודקשן - תשובה גרועה שהמערכת נתנה - היא הופכת אוטומטית למועמדת לתרחיש בדיקה חדש שנוסף ל-Registry, כדי שאותה טעות ספציפית לעולם לא תחזור בלי שמישהו ישים לב. כך ה-test set גדל אורגנית מתוך כשלים אמיתיים במקום מתוך ניחוש תיאורטי מראש של מה עלול להשתבש.

הבדל בין Evaluation ל-Monitoring שוטף

כדאי להבחין בבירור בין שני מונחים שנוטים להתבלבל: Evaluation הוא תהליך יזום, שרץ מול test set מוגדר לפני או במקביל לשינוי, במטרה להשוות בין גרסאות ולקבל החלטת פריסה. Monitoring, לעומת זאת, הוא תהליך פסיבי ורציף שעוקב אחרי ביצועי המערכת החיה מול תעבורה אמיתית ובלתי נשלטת, ומטרתו לזהות בעיות שלא נצפו מראש. שני התהליכים משלימים זה את זה אך אינם תחליף זה לזה: מערכת יכולה לעבור מעולה כל בדיקת Evaluation ועדיין להיתקל בבעיה חדשה שלא הייתה חלק מאף test case, ורק Monitoring שוטף, שרץ מסביב לשעון ולא רק ברגע הפריסה עצמה, יתפוס ויתריע עליה בזמן אמת לפני שהיא מצטברת לנזק ממשי. Registry שמנוהל היטב מזין את שני התהליכים ממאגר תרחישים משותף, כדי שממצא ממערכת אחת יעשיר את השנייה באופן שוטף.

סיכום

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

תגיות: Evaluation Registry · LLM Evaluation · LLM-as-Judge · MLOps · Enterprise AI · CI/CD · Regression Testing

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