אימון מודל לזיהוי אנומליות על נתונים ללא תיוג

מדוע אימון מודל לזיהוי אנומליות נשבר בלי תיוג

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

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

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

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

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

האפקט מהטמעה: זמן תגובה ומחלקת תקלות שנעלמה

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

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

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

העומס על המפעיל יורד גם בזכות קיבוץ: התראות קשורות מתאחדות לאירוע אחד עם דירוג חשיבות, ולכן התורן רואה כמה סיפורים במקום מאה הודעות זהות. אזעקות שווא יורדות פי כמה — הסף נבחר על נתונים היסטוריים, ולא נקבע ידנית.

מצבי בקרה: השוואת גישות והמגבלות שלהן

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

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

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

שלבי הטמעה: מביקורת נתונים ועד מסירת המודל

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

1. ביקורת נתונים. בודקים מה באיזו תדירות נכנס, היכן יש חוסרים והפסקות קשר, איך המערכת מתנהגת לפי ימי שבוע ועונות. בנפרד לומדים את יומן האירועים הקודמים — הוא נותן נקודות ייחוס, אם כי אינו משמש כתיוג.
2. סכמת פתרון ובחירת מאפיינים. קובעים אילו אותות מתארים את התקין, באילו חלונות אנחנו מקבצים, מה מנרמלים ומה משליכים כרעש. הרכב המאפיינים מתאמים עם הצוות שלכם לפני האימון.
3. אימון על פרופיל תקין. המודל בונה תיאור של התנהגות אופיינית ומחשיב כסטייה כל מה שלא מתאים לו. אין צורך בתיוג — מספיק פרק זמן של עבודה יציבה.
4. כוונון ספים. את גבול ההתראה מתאימים למחיר הטעות: אירוע שהוחמץ מול יציאה מיותרת של המשמרת. את הסף מקבעים במספרים, כדי לשנותו במודע.
5. בדיקה על נתונים היסטוריים. מריצים את המודל על תקופות קודמות ומצליבים התראות עם אירועים ידועים. מחשבים את שיעור האירועים שנמצאו ואת מספר אזעקות השווא למשמרת.
6. הפעלה ניסיונית. מפעילים במצב תצפית, מנתחים כל התראה יחד עם משמרת התורנות, ומדייקים מאפיינים וספים לפי המצב בפועל.
7. מסירת המודל. מוסרים קונפיגורציה, סדר אימון מחדש, מדדי איכות והוראות למשמרת התורנות.

ערכת מסירה: קונפיגורציות, סכמות, נהלים

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

• קונפיגורציית הגלאי — פרופיל אימון עם ספי רגישות, חלון תצפית וכללי קיבוץ ציונים; הפרמטרים מופרדים ל״נוגעים באימון מחדש״ ול״משנים רק במודע״.
• סכמת זרימת נתונים — ממקור האירועים ועד רישום הציון: היכן מתבצעת ניקוי, היכן מחושב תיאור המאפיינים, היכן נשמרות גרסאות של מדגמי האימון.
• תיאור מאפיינים — טבלה «מאפיין → מקור → לוגיקת חישוב → התנהגות בעת חוסר», עם סימון אילו שדות קריטיים ואילו אפשר להסיר בלי לפגוע באיכות.
• נוהל אימון מחדש — טריגרים (שיעור התראות שנדחו, דריפט בנתוני הקלט, עדכון מתוכנן), סדר פריסה של גרסה חדשה וקריטריון חזרה לגרסה הקודמת.
• סדר ניתוח התראות — כיצד נרשמת הכרעה לכל אנומליה וכיצד התיוג הזה חוזר למדגם האימון הבא.
• הוראות לצוות — הפעלת אימון, בדיקת איכות על מדגם מוחזק, קריאת לוגים, תקלות אופייניות ומה לעשות בכל אחת.
• סכמת ניטור — אילו מדדי איכות ובאיזה מרווח בודקים, ובאילו ערכים מרימים התראה.
• יומן החלטות — מדוע נבחרה הארכיטקטורה הנוכחית של הגלאי ואילו חלופות נדחו, כדי שכעבור חצי שנה לא להתחיל את הניתוח מאפס.

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

מקרה בוחן: תקלות ציוד בייצור רציף

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

לפני ההטמעה הבקרה נשענה על ספים לפי אותות בודדים, שנקבעו «עם מרווח ביטחון». למשמרת הגיעו 25–30 אזעקות שווא, וכעבור שבוע המפעיל מפסיק להגיב אליהן — ו-6 מתוך 10 תקלות מוקדמות נותרו בלתי מזוהות והגיעו לעצירת חירום של הקו.

איך אימנו מודל לזיהוי אנומליות ללא תיוג

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

מדדים לפני ואחרי באותו קטע:

• החמצות תקלות: 6 מתוך 10 לפני — 1 מתוך 10 אחרי;
• אזעקות שווא: 25–30 למשמרת — 3–4, המפעיל שוב קורא כל אחת;
• זמן מהסטייה הראשונה עד התערבות: כ-40 דקות — 6–8 דקות;
• שיעור התקלות שנתפסו לפני נזק ליחידה: 15% — 70%.

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

במה שונה הגישה ללא תיוג מסיווג רגיל?

סיווג לפי דוגמאות לומד על זוגות «מאפיין — תווית» וזוכר את גבולות המחלקות שהראו לו. עבור תקלות ופסולים זה עובד גרוע: אירועים נדירים אינם מתוארים במלואם על ידי אף מחלקה, והמודל מתייג בביטחון רק את מה שכבר פגש.

זיהוי אנומליות נבנה מהכיוון ההפוך. המודל מתאר את התקין — התנהגות אופיינית של תהליך או ציוד — ואת הסטייה מהתקין הוא מסמן ככל מה שלא נכנס לתיאור הזה. אין צורך לתייג תקלות: מספיקה טלמטריה «בריאה» שנצברה, ובדרך כלל יש ממנה פי כמה יותר.

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

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

ספקות טכניים: אזעקות שווא ודריפט בנתונים

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

מה לעשות כשהנתונים משתנים עם הזמן?

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

כמה נתונים היסטוריים נדרשים בהתחלה?

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

אפשר לפרוס את הפתרון על הציוד שלנו?

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

נדון במשימה ונחזור עם הערכה ותוכנית

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

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

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