Shadow Evaluation — בדיקת מודל חדש על תעבורת אמת ללא חשיפה למשתמש

מאת צוות מדיה דיל · 12.08.2026 · AI Evals · 5 דק׳

איך מריצים מודל חדש במקביל לקיים על תעבורת פרודקשן אמיתית מבלי לחשוף משתמשים לסיכון: ארכיטקטורת Fork, dry-run לכלים, והשוואת פערים.

לפני שמעבירים אחוז אחד מהתעבורה למודל חדש בתוכנית A/B רגילה, יש שאלה שקשה לענות עליה מראש: מה יקרה אם המודל החדש, על תעבורת אמת שהסוכן לא ראה בבדיקות, מתחיל לבצע פעולות מסוכנות בקצב נמוך אך לא אפסי? A/B Testing חושף את המשתמש לסיכון הזה, גם אם רק לאחוז קטן מהם. Shadow Evaluation פותר בדיוק את הבעיה הזו: מריצים את המודל החדש במקביל למודל הקיים על כל בקשה אמיתית שמגיעה, אבל רק תשובת המודל הקיים חוזרת למשתמש — תשובת המודל החדש נרשמת ומושווית בלי אף אחד מלבד הצוות שרואה אותה. זו הדרך היחידה לקבל נתוני אמת על ביצועי מודל חדש בלי לקחת שום סיכון תפעולי אמיתי.

איך Shadow Evaluation נבדל מ-A/B Testing

ב-A/B Testing, שתי הגרסאות נחשפות למשתמשים אמיתיים, וכל אחת מקבלת פלח תעבורה — מה שאומר שגרסה גרועה משפיעה על משתמשים אמיתיים, גם אם רק על 5 אחוז מהם. ב-Shadow Evaluation כל בקשה מטופלת פעמיים — פעם על ידי הגרסה הקיימת שהתשובה שלה נשלחת בפועל, ופעם על ידי הגרסה החדשה ב"צל" — כלומר באותו זמן אמת, על אותו קלט מדויק, אבל התוצאה שלה נשמרת ולא מוצגת. זה מבטל את סיכון החשיפה למשתמש לגמרי, במחיר של הכפלת עלות החישוב על כל בקשה בזמן ריצת ה-Shadow.

ההבדל הזה קריטי במיוחד לפעולות בלתי-הפיכות: ב-Shadow Evaluation, קריאה לכלי מסוג delete או charge שהמודל החדש "בחר" לבצע לא באמת מתבצעת — היא נרשמת כ-Intent בלבד (מה המודל היה עושה) ולא כפעולה אמיתית. זה מאפשר לבדוק בדיוק אילו פעולות מסוכנות מודל חדש היה מבצע על תעבורת אמת, בלי לגרום לנזק אמיתי אם התשובה שגויה.

ארכיטקטורת מימוש: Fork הבקשה בלי לעכב את המשתמש

המימוש הטכני דורש הפרדה ברורה בין הנתיב הראשי (Hot Path) לנתיב ה-Shadow. הבקשה הנכנסת מפוצלת מיד לאחר קבלתה — עותק אחד ממשיך לנתיב הרגיל ומחזיר תשובה למשתמש כרגיל, ועותק שני נשלח באופן אסינכרוני (fire-and-forget, לרוב דרך תור הודעות) למודל ה-Shadow. חשוב מאוד שהנתיב הראשי לא ימתין לתוצאת ה-Shadow בשום שלב — אם ריצת ה-Shadow איטית או נכשלת, זה לא אמור להשפיע על זמן התגובה או על התוצאה שהמשתמש מקבל בכלל.

async function handleRequest(req) {
  const response = await primaryAgent.run(req);
  shadowQueue.publish({ req, timestamp: Date.now() }); // אסינכרוני, לא חוסם
  return response;
}
// worker נפרד, לא בנתיב הבקשה:
async function shadowWorker(msg) {
  const shadowResult = await shadowAgent.run(msg.req, { dryRun: true });
  await compareAndStore(msg.req, shadowResult);
}

שימו לב לדגל dryRun — קריטי לוודא שכל קריאת כלי בעלת תופעת לוואי (side effect) נחסמת או מדומה בסביבת ה-Shadow, ולא רק שהתשובה הטקסטואלית לא מוצגת. יכולת כזו תלויה בתשתית תיעוד מסודרת לכל קריאת כלי, כמתואר במדריך LLM Observability. פספוס הנקודה הזו הוא הטעות הכי יקרה שאפשר לעשות במימוש Shadow Evaluation — היא הופכת בדיקה "בטוחה לחלוטין" לבדיקה שמבצעת פעולות אמיתיות בלי שאיש מתכוון לכך.

מה משווים בין שני הפלטים, ואיך קוראים תוצאה

ההשוואה בין תשובת ה-Primary לתשובת ה-Shadow לא צריכה להיות "זהה/שונה" בינארי — במערכת לא-דטרמיניסטית, שתי תשובות תקינות לגמרי יכולות להיות מנוסחות אחרת. במקום זאת, משתמשים באותה סוללת Evals שמשמשת לבדיקות רגילות: ציון איכות עצמאי לכל תשובה (לא רק השוואה ביניהן), Trajectory Comparison — האם ה-Shadow השתמש בכלים אחרים או במספר צעדים שונה, וסיווג פערים לפי קטגוריה — פער בטון, פער בעובדות, פער בבחירת כלי. הצטברות נתונים על אלפי בקשות אמיתיות נותנת תמונה הרבה יותר אמינה מכל Eval Suite סינתטי, כי הקלטים הם בדיוק מה שמשתמשים אמיתיים שולחים, כולל כל הניסוחים המוזרים שאף אחד לא חשב לכתוב כמקרה בדיקה.

קריטריון מעשי למעבר משלב Shadow למעבר מלא (או ל-A/B Testing חלקי) הוא לא "0 פערים" — זה לא ריאלי — אלא: אין אף רגרסיה בקטגוריית סיכון גבוה (בטיחות, פעולות בלתי-הפיכות), ושיעור השיפור הכולל מובהק סטטיסטית ולא רק חיובי בממוצע. אותה מתודולוגיית מובהקות סטטיסטית שמשמשת בהשוואת גרסאות מודל בכלל, שמפורטת במדריך Regression Testing לסוכני AI, חלה גם כאן במלואה.

מגבלות: מה Shadow Evaluation לא תופס

Shadow Evaluation מצוין לבדיקת איכות תשובה ובחירת כלים, אבל יש לו עיוורון מובנה אחד: הוא לא בודק את חוויית המשתמש בפועל, כי המשתמש לעולם לא רואה את תשובת ה-Shadow. אם המודל החדש טוב יותר בתוכן אבל איטי משמעותית, או משנה משהו בזרימת השיחה שרק ניסיון אמיתי של משתמש חי היה חושף (כמו שינוי בסגנון שמרגיש "קר" יותר), Shadow Evaluation לא יתפוס את זה — צריך שלב נוסף של A/B מוגבל אחריו. גם עלות: הרצה כפולה על כל בקשה משמעה תקציב חישוב כפול לתקופת הבדיקה, ולכן לרוב מריצים Shadow על תת-קבוצה מדגמית של התעבורה ולא על כולה, כדי לאזן בין כיסוי סטטיסטי לעלות.

למרות המגבלות, Shadow Evaluation הוא הצעד המומלץ ביותר לפני כל מעבר מודל משמעותי בסוכן שיש לו גישה לפעולות בעלות השלכה אמיתית — הוא מספק את היתרון הכפול של נתוני תעבורת אמת בלי סיכון חשיפה, מה שאף Eval אוטומטי או A/B Testing לא נותן בבת אחת.

שילוב עם ניטור Drift מתמשך

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

אותה תשתית Shadow, כשמריצים אותה לאורך זמן על המודל הראשי מול עצמו (גרסה נוכחית מול Snapshot של אתמול), משמשת גם לזיהוי סטייה הדרגתית באיכות שלא קשורה בכלל להחלפת מודל — נושא שמפורט במדריך Production Drift.

תגיות: Shadow Evaluation · AI Deployment · Model Migration · A/B Testing · AI Evals

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