Навчання моделі детекції аномалій на даних без розмітки

Чому навчання моделі детекції аномалій ламається без розмітки

Розмітка дефектів вручну виглядає робочим рішенням, доки не порахуєш обсяг роботи. Оператор переглядає години записів із датчиків, щоб знайти поодинокі відхилення: частка браку — частки відсотка, іноді один випадок на десятки тисяч циклів. На виході — багато прикладів норми й одиниці аномалій, на яких стійкий класифікатор не будується.

Дисбаланс класів перетворює навчання на пастку. Модель, яку штрафують за кожну помилку, найшвидше знижує втрати, якщо оголошує нормою все підряд: формально висока точність за нульової користі.

Пропуск рідкісних відмов у середніх метриках не видно — їх розмивають тисячі правильних відповідей на нормальних даних.

Зсув порогу вирішує одну проблему й створює іншу. Знижуємо чутливість — хибні спрацювання детектора йдуть потоком, оператор звикає ігнорувати сигнали й губить справжню відмову серед шуму. Підвищуємо — зростає пропуск рідкісних відмов, ціна якого на порядок вища за зайву тривогу.

Сама розмітка теж нестабільна: межі аномалії розмиті, два інженери розмічають одну ділянку по-різному, а частина типів дефектів узагалі не трапляється в зібраних даних — їх нема чим показати моделі.

Саме тому детекція аномалій без розмітки будується не на підборі міток, а на описі нормальної поведінки й пошуку відхилень від неї. Нижче розбираємо, як це закривається.

Ефект від впровадження: час реакції та зниклий клас відмов

Порогові правила ловлять лише те, що описано заздалегідь: перевищення температури, вихід за діапазон тиску. Навчання на даних без розмітки знімає це обмеження — модель будує профіль нормальної поведінки й вважає відхиленням стійке розходження з ним.

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, тому порівняння методів на ваших даних займає години, а не тижні.

Якщо розмітка неповна, робоча схема — спочатку детекція відхилень на нерозмічених даних, потім донавчання на спрацюваннях, підтверджених експертом. Порівняння методів тоді йде за одним показником: скільки реальних збоїв спіймано за прийнятної частки хибних.

Технічні сумніви: хибні спрацювання та дрейф даних

Хибні спрацювання та дрейф даних — два сумніви, які виникають перед запуском детекції аномалій на нерозміченому потоці.

Метрика на відкладеній вибірці тут мало про що говорить: вона не показує, скільки тривог доведеться розбирати черговому і як поводитиметься модель після зміни режиму роботи. Тому рішення про запуск ми приймаємо за поведінкою моделі на живих даних, а не за однією цифрою у звіті.

Що робити, коли дані змінюються з часом?

Порівнюємо розподіл ознак на ковзному вікні з еталонним періодом і заводимо оповіщення на розходження — воно спрацьовує раніше, ніж якість почне падати в очах замовника.

Перенавчання запускаємо за цим тригером, а не за календарем: у стабільні місяці модель не чіпаємо, при зміні режиму — донавчаємо на накопиченому зворотному зв’язку.

Скільки історичних даних потрібно на старті?

Розмітка аномалій не потрібна — потрібен чистий фон нормальної роботи, що покриває всі штатні режими: будні й вихідні, сезонні піки, планові роботи. Якщо в історії є підписані інциденти, використовуємо їх для перевірки, але не для навчання. Відсутні режими добираємо на перших тижнях спостереження.

Чи можна розгорнути рішення на нашому обладнанні?

Так, модель і весь контур обробки розгортаємо у вашому периметрі: дані не залишають вашу інфраструктуру, доступ до них залишається у вашої команди. Вимоги до ресурсів рахуємо за обсягом потоку й закладаємо запас на пікові періоди. Оновлення моделей іде за регламентом, з можливістю відкату до попередньої робочої версії.

Обговоримо задачу й повернемося з оцінкою та планом

Для старту обговорення не потрібен підготовлений набір даних або розмічений корпус — достатньо того, що вже збирається в системі.

Надішліть вивантаження телеметрії або логів за типовий і за аномальний період, перелік об’єктів і ознак, які вважаєте значущими, та один-два описи випадків, які детектор зобов’язаний спіймати.

Розмітка при навчанні без учителя не потрібна: рідкісні та «дивні» ділянки історії — це і є навчальний сигнал.

• Дані для старту: сирі записи за кілька тижнів спостережень, включно з викидами, простоями та сезонними коливаннями, а не лише «чисті» доби.
• Опис процесу: де фіксуються події, які ознаки доступні постійно, а які надходять із затримкою або пропусками.
• Критерій успіху: що вважаємо аномалією, яка частка пропусків допустима, хто на боці замовника розбирає спрацювання.
• Середовище експлуатації: де буде працювати детектор — у вашому контурі чи в нас, які обмеження за доступами та глибиною зберігання історії.
• Склад робіт: які етапи ви готові закрити своїми силами, а які передаєте нам — збір даних, налаштування, супровід.

У відповідь надсилаємо схему рішення, склад робіт за етапами з точками приймання та оцінку й план робіт. Опишіть задачу у вільній формі — повернемося з оцінкою та планом.