Production Drift — זיהוי ירידה הדרגתית באיכות הסוכן

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

למה סוכן AI מתדרדר בהדרגה גם בלי שינוי קוד או מודל, ואיך מודדים Input/Knowledge/Prompt Drift עם PSI ו-KL Divergence לפני שלקוחות מרגישים את זה.

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

שלושה מקורות Drift שלא קשורים לקוד או למודל

המקור הראשון הוא Input Drift — התפלגות הבקשות שמגיעות מהמשתמשים משתנה עם הזמן: פיצ'ר חדש במוצר מביא סוג שאלות חדש שהסוכן לא נבדק עליו טוב, או שקהל המשתמשים עצמו משתנה (למשל אחרי כניסה לשוק חדש עם ניסוחים ותרבות שונים). המקור השני הוא Knowledge Drift — אם הסוכן מבוסס RAG ושולף מידע ממסמכים או ממאגר ידע, תוכן המקור עצמו יכול להתיישן או להשתנות בלי שאיש בדק את ההשפעה על איכות התשובות. המקור השלישי, והכי ערמומי, הוא Prompt Drift — הצטברות תיקונים קטנים לפרומפט המערכת לאורך זמן, שכל אחד מהם נראה תמים ופתר בעיה נקודתית, אבל יחד יצרו פרומפט ארוך, סותר לפעמים, ופחות יעיל מהגרסה המקורית הנקייה.

שלושת המקורות האלה חולקים תכונה משותפת: אף אחד מהם לא מופיע ב-git diff רגיל של קוד הסוכן, ולכן Regression Testing שמשווה גרסת קוד לגרסת קוד לא תופס אותם — צריך מתודולוגיה נפרדת שמתמקדת בזמן, לא בגרסה, כפי שמפורט במדריך זיהוי Regression ב-AI.

מדידת Drift: השוואה לחלון זמן, לא לגרסה

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

מעבר לציון Eval הכולל, שני מדדים סטטיסטיים שאולים מ-ML Monitoring קלאסי שימושיים כאן: Population Stability Index (PSI) להשוואת התפלגות סוגי הבקשות הנכנסות בין חלון זמן לחלון זמן (מזהה Input Drift), ו-KL Divergence בין התפלגות ציוני האיכות בשני חלונות זמן (מזהה שינוי כללי באיכות התשובות, גם כשהציון הממוצע נראה יציב אך הפיזור השתנה). שני המדדים האלה מספקים אזהרה מוקדמת הרבה לפני שהירידה מגיעה לגודל שמורגש בתלונות לקוחות.

שורש הבעיה: לחפש בכיוון הנכון

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

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

מניעה: תהליך "ניקוי" תקופתי לפרומפט ולידע

הדרך היעילה ביותר להתמודד עם Drift היא לא רק לזהות אותו אחרי שקרה, אלא לבנות תהליך תקופתי שמונע הצטברות. לגבי Prompt Drift: סקירה רבעונית של הפרומפט המלא עם שאלה מפורשת "האם כל שורה כאן עדיין נחוצה", ולא רק הוספה מתמשכת בלי הסרה מקבילה. לגבי Knowledge Drift: תהליך רענון ובדיקת תוקף למקורות ה-RAG, עם Eval ייעודי שמוודא שהמידע שנשלף עדיין תואם את המציאות העדכנית. לגבי Input Drift: דגימה מחודשת של תעבורת פרודקשן לתוך golden dataset באופן שוטף, כמתואר במסגרת הרחבה יותר של בניית סוויטות בדיקה, כדי שהסוויטה עצמה לא תלך ותתיישן ביחס למה שמשתמשים אמיתיים שולחים היום.

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

מי אחראי על Drift: הבעיה הארגונית שמסתתרת מאחורי הטכנית

מעבר לכלים ולמדדים, יש שאלה ארגונית שקל להתעלם ממנה: כשאין שינוי קוד בודד וברור, קשה להצביע על בעל אחריות טבעי לתקן את הבעיה. מפתח שמוסיף פיצ'ר לא מרגיש בעלים של "האם הפרומפט עדיין נקי", וצוות התוכן שמעדכן מסמכי RAG לא בהכרח יודע שהעדכון שלו משפיע על ציוני Eval. לכן, מעבר לתשתית המדידה, נדרשת בעלות ארגונית מפורשת — מישהו שמקבל דוח Drift שבועי ובודק אותו בפועל, לא רק Dashboard שקיים אבל לא נצפה.

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

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

תגיות: Production Drift · Model Monitoring · PSI · AI Quality · Prompt Drift

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