Иллюзия 99% F1 в Time Series: как искажаются метрики в детекции аномалий и что показывает реальный тест 14 архитектур

Я занимаюсь внедрением ML в промышленности, поэтому задача детекции аномалий во временных рядах для меня близка и имеет огромную важность. В рамках исследовательского проекта мы искали адекватное SOTA-решение для мониторинга телеметрии (водоочистка, турбины, химические установки).

Изучая свежие работы с конференций уровня A*, я обратил внимание на статью про Sub-Adjacent Transformer (SAT). В аннотации авторы заявляли метрику F1 в районе 99%.

Для задачи поиска аномалий на реальных датасетах такие цифры всегда вызывают здоровый скепсис. Тем не менее, мы решили проверить модель: взяли оригинальный код и пересчитали метрики, отключив один специфический протокол оценки (о котором пойдет речь ниже). Как и ожидалось, магии не случилось: 99% превратились в 63-84% (в зависимости от датасета), а на некоторых датасетах разрыв составил 50 процентных пунктов.

Как выяснилось, общепринятые бенчмарки для временных рядов имеют серьезный методологический изъян. В этой статье мы разберем, за счет чего возникает иллюзия высоких показателей, и обсудим результаты нашего бенчмаркинга 14 популярных архитектур. Спойлер: при честной оценке простые базовые модели нередко обходят тяжелые SOTA-решения.

---

1. Зачем нейросети и Специфика многомерных временных рядов

Возникает логичный вопрос о целесообразности: зачем тянуть в продакшен тяжелые трансформеры? Почему нельзя ограничиться классическим пороговым контролем вида if (sensor_value > MAX) или проверенными статистическими методами, вроде Z-score, ARIMA и Isolation Forest?

Многомерный временной ряд (Multivariate Time Series, или просто MVTS) удобнее всего представить в виде огромной таблицы или матрицы. Строки в ней — это отсчеты времени (таймстемпы), а столбцы — конкретные датчики. На реальном заводе это сотни каналов, синхронно пишущих данные каждую секунду или даже миллисекунду.

Если аномалия — это банальный и резкий выброс температуры за пределы допустимого (так называемая Point Anomaly), то машинное обучение здесь действительно не нужно. Для таких случаев с головой хватит классической жесткой уставки (min/max порога) на контроллере.

Но главная боль промышленности — это контекстные и коллективные аномалии. В MVTS каналы связаны законами физики.

Простой пример: Представьте электродвигатель на заводском конвейере. На нем стоят два датчика: Потребляемый ток (норма 0…100 А) и Скорость вращения вала (норма 0…3000 об/мин).

1. Ток 0 А, скорость 0 об/мин — норма (двигатель выключен).

2. Ток 80 А, скорость 2800 об/мин — норма (двигатель под нагрузкой).

3. Ток 95 А, скорость 0 об/мин — АВАРИЯ (вал заклинило, мотор горит)!

Заметьте: во время аварии значение тока (95 А) не превышает максимально допустимые 100 А. Значение скорости (0 об/мин) — это тоже абсолютно легальное число. Аномалия кроется исключительно в разорванной связи между датчиками.

Здесь опытный инженер резонно заметит: «Так напишите if (current > 80 && speed == 0) и можно обойтись без сложных нейросетей»

И для двух датчиков он будет абсолютно прав.

Но проблема в масштабе. На реальном промышленном турбогенераторе стоит 500+ датчиков. Температура подшипника зависит от оборотов ротора, давления масла, расхода охлаждающей жидкости и температуры в цехе. Зависимости там нелинейные, с временными лагами.

Чтобы написать if/else для всех возможных комбинаций 500 датчиков, вам понадобится бесконечное количество времени. А строить строгие математические физические модели («цифровые двойники») для каждого агрегата — слишком долго и безумно дорого.

«А как же классическая статистика?»

Почему бы не применить к этим 500 датчикам метод главных компонент (PCA), расстояние Махаланобиса или векторную авторегрессию (VAR)? Использовать их в качестве базового решения (baseline) можно, но они быстро упираются в математические ограничения:

Игнорирование временного контекста (IID). Большинство методов (PCA, Isolation Forest, расстояние Махаланобиса) оценивают каждый отсчет времени в отрыве от предыдущих. Но физические процессы инерционны: обороты ротора выросли сейчас, а температура подшипника поднимется только через 5 минут. Без учета этих лагов статистика будет сыпать ложными тревогами при любом переходном режиме.

Проклятие нелинейности. Классические подходы ищут линейные связи. Однако термодинамика и гидродинамика на реальном производстве нелинейны. Линейная модель либо пропустит сложную аномалию, либо будет ложно срабатывать при плановой смене режима работы.

Параметрический взрыв. Попытка построить честную временную статистику (например, модель VAR) на 500 каналах с глубиной памяти всего в 10 секунд потребует расчета параметров. Модель мгновенно переобучится на технологическом шуме.

Именно поэтому в индустрии используют Data-Driven подход и сложные нейросети: графовые модели сами выучивают нелинейную топологию завода, а модели вроде MSCRED анализируют скользящие матрицы корреляций. Алгоритм переваривает окно из сотен датчиков разом и выдает единый Anomaly Score.

И именно на этапе превращения этого хитрого Score в бизнес-метрику начинается главное академическое жульничество.

2. Анатомия обмана: откуда берутся 99%

Главный спонсор красивых цифр в статьях последних лет — протокол оценки под названием Point Adjustment (PA).

Авторы метрики не были злодеями. PA придумывали из логичного соображения: на практике авария — это не конкретная секунда, это интервал. Если атака на сервер длится час, а модель забила тревогу через 5 минут после ее начала — это все равно победа. Оператору важно узнать о событии.

Как работает PA математически: если модель нашла хотя бы одну аномальную точку внутри размеченного интервала, весь интервал задним числом засчитывается как идеально найденный (True Positive).

В чем проблема для бизнеса: Представьте промышленную установку. Начинается опасный режим, который длится 2 часа. Ваша модель из-за случайного шума в данных выдает сигнал тревоги ровно на 1 секунду где-то в середине этого отрезка.

По метрике PA ваш Recall = 100%, а F1 стремится к 99%. Но в реальности в диспетчерской на секунду моргнула лампочка и погасла. Оператор этого даже не заметит.

Вторая проблема — Oracle Threshold. Многие статьи подбирают порог отсечения (threshold) прямо на тестовой выборке, подгоняя его под максимальный F1. Но в продакшене машины времени нет — порог нужно фиксировать строго до теста, на чистой валидации.

Ожидание vs Реальность (на примере SAT)

Чтобы показать масштаб проблемы, мы взяли результаты модели SAT из их же Appendix (где честно приведены сырые цифры) и сравнили с тем, что заявлено в их аннотации:

Падение метрики почти в два раза на датасете SMD! Это не статистическая погрешность. Это иллюзия работающей системы. Стало ясно: сравнивать алгоритмы по табличкам из статей бессмысленно. Нам нужен свой, честный протокол.

3. Event-level F1 и честный Benchmark

Мы отказались от PA и ввели Event-level F1. Логика простая и суровая: событие считается найденным, только если «окно тревоги», выданное моделью, пересеклось с реальным интервалом аномалии. Никаких искусственных дорисовываний True Positive на весь отрезок.

Посмотрите на разницу интуитивно:

Истинная авария:      [--------------------------------------]Модель А (из статьи):                [X]Модель Б (наш прод):  [XXXXXXXXX]

Для классического Point-level с протоколом PA обе модели одинаково идеальны (обе получат Recall = 100%). Но для инженера в диспетчерской полезна только Модель Б, которая стабильно держит сигнал во время аварии, а не моргнула на одну секунду.

Математически мы формализовали это так. Вместо поточечного подсчета, Precision и Recall вычисляются на уровне событий:

Event-level Precision (): доля предсказанных моделью аномальных окон, которые пересекаются хотя бы с одной реальной аномалией.

Event-level Recall (): доля реальных интервалов аномалий, которые были успешно перекрыты сигналами тревоги от модели.

Протокол фиксации порогов (Анти-Oracle)

Чтобы полностью исключить эффект подглядывания в тестовую выборку (Oracle Threshold), мы жестко разделили данные. Все базовые гиперпараметры и сами пороги отсечения (thresholds) настраивались исключительно на изолированной валидационной выборке. На тестовый датасет модели заходили с уже намертво «прибитыми» значениями. Никакого подбора констант по ходу теста — все строго в условиях, имитирующих реальное развертывание.

Важная оговорка: Не стоит путать академический Oracle Threshold с легальными динамическими (адаптивными) порогами. В продакшене вы вполне можете пересчитывать порог «на лету» (например, через методы теории экстремальных значений — EVT, или скользящие квантили), подстраиваясь под дрейф оборудования или смену сезонов.

Но ключевое инженерное требование здесь — делать это causal (причинно), то есть опираясь исключительно на прошлые исторические данные из скользящего окна. Академический же изъян, который мы убрали, заключается в вычислении порога задним числом, зная разметку всего тестового датасета целиком.

С этой честной метрикой и строгим протоколом валидации мы прогнали 14 популярных архитектур через 7 наборов данных.

И здесь мы пошли на сознательный шаг: мы не ограничились стандартными академическими бенчмарками (вроде SMD или урезанного SWaT), которые кочуют из статьи в статью. Чтобы проверить модели на прочность, мы добавили в тест два уникальных проприетарных датасета из реальной тяжелой промышленности:

• Turbine Dataset (Паровая турбина): Реальный лог деградации узлов турбины от стабильного состояния до полного отказа (всего 70 физических параметров, дискретизация — 1 минута). Датасет разделен долгой 80-дневной остановкой на два операционных периода, содержит кучу аномальных пропусков в данных из-за мелких сбоев, а общая доля аномалий составляет всего ~0.9%. Модели обучались строго на нормальных интервалах, а тестировались на предвыборном контексте и самом отрезке финальной аварии.

• NPPs Turbogenerator (Турбогенераторы АЭС): Массивный датасет, содержащий логи шести многомерных инцидентов (C1–C6) на ядерных турбогенераторах общей длительностью 445 дней (из них 65 дней — подтвержденные аварийные режимы). Главный вызов здесь — колоссальная разреженность данных (от 50.1% до 81.2% пропусков в столбцах «из коробки») и поздние точки изменения режима (медиана на 92.3% длины последовательности). Все данные были ресемплированы нами к 1-минутному интервалу (всего более 641 тысячи точек), а длинный кейс C1 был принудительно обрезан до первых 10 дней, чтобы экстремальная аномалия не искажала обучение.

Именно эта «грязная» промышленная практика и расставила все по своим местам.

4. Наши результаты: почему универсальной модели не существует

Изначально рабочая гипотеза была стандартной: определить пул явных лидеров (например, на базе спектрального TimesNet или современных графовых архитектур) и зафиксировать их как универсальный каркас для большинства индустриальных задач.

Однако честный бенчмарк эту гипотезу полностью опроверг — никакой «модели-победительницы» не оказалось.

Давайте посмотрим на фрагмент нашей сводной таблицы результатов (честный Event-level F1):

Здесь произошло самое интересное:

1. Спектральный анализ пасует перед апериодическими трендами. TimesNet, идеальный для цикличной работы насосов на академических стендах, провалился на реальной турбине. Тяжелые промышленные агрегаты живут в условиях монотонной деградации металла, долгосрочных остановов и случайных сдвигов фаз. Быстрое преобразование Фурье (FFT), лежащее в основе модели, с такими непериодическими процессами не справляется.

2. Классическая реконструкция стабильнее «хайпа». Простой и якобы устаревший LSTM–VAE на реальных объектах уверенно обошел тяжелые SOTA-трансформеры. Сжатие многомерного сигнала в компактный латентный вектор помогло ему успешно переварить и сильную разреженность данных, и десятки сильно связанных параметров деградации.

3. Графовые сети выигрывают на «грязной» телеметрии. Прямые графовые архитектуры (GBAD) чувствительны к аддитивному шуму, но гибриды с механизмами внимания (STGAT–MAD) отлично держат удар. За счет выученной топологии связей они компенсируют выпадение датчиков, что стало спасением на реальных объектах, где пропуски в каналах достигали 81%.

4. Normalizing Flows боятся раскалибровки приборов. Модели плотности (типа GANF) хороши на стерильной статике. Но стоит добавить легкий логарифмический дрейф (имитация естественного износа датчиков), как их метрики рушатся. А жесткая фиксация выученного графа (DAG) и вовсе повышает чувствительность к дрейфу в 8 раз, уводя систему в режим непрерывных ложных тревог.

Через несколько месяцев прогонов стало кристально ясно: выбор архитектуры зависит исключительно от физики процесса, характера аномалий и качества предобработки телеметрии.

5. Stress Suite и инсайт на 54%

Чистые академические датасеты — это тепличные условия. В проде всегда есть дрейф калибровки датчиков (drift), шум (noise) и умирающие каналы. Поэтому мы добавили к бенчмарку модуль Stress Suite.

Например, изящная модель GANF (оценивает плотность вероятности через потоки) на чистом SWaT дает F1 = 0.80. Но стоит нам добавить легкий логарифмический дрейф (имитация медленного износа установки), как F1 падает почти до нуля. Модели на базе Normalizing Flows критически зависят от стационарности.

Влияние зашумленных каналов и архитектурные различия

В ходе стресс-тестирования на реальном объекте мы столкнулись с классической проблемой «грязной» телеметрии. Для локализации проблемного канала мы использовали стандартный метод последовательного исключения (zero-channel probing), поочередно зануляя датчики на инференсе.

Результаты этого теста наглядно подсветили фундаментальную разницу между семействами моделей:

Архитектуры на основе реконструкции (LSTM-VAE, USAD): оказались наиболее уязвимы. В архитектурах этого типа латентное пространство пытается сжать и восстановить весь вектор состояния целиком. Стоит одному датчику начать выдавать некорректный сигнал (например, из-за локальной наводки по питанию), как ошибка реконструкции мгновенно «размазывается» по соседним, абсолютно здоровым каналам. Модель начинает генерировать ложные тревоги по всей системе. Исключение всего одного такого зашумленного датчика на реальной турбине подняло Event-level F1 для LSTM-VAE с 0.38 до 0.58.

Графовые и прогнозирующие модели (GDN, STGAT-MAD): проявили гораздо большую робастность. Поскольку графовые сети явно выучивают топологию связей и пытаются прогнозировать значения каждого датчика на основе его соседей, они локализуют аномалию. Аномальный шум на одном датчике приводил к локальному всплеску ошибки только на нем самом, не ломая предсказания по остальным узлам графа.

Этот эксперимент в очередной раз подтвердил: перед выбором тяжелой архитектуры критически важно провести базовый аудит данных. Иногда ручная фильтрация или исключение одного нестабильного прибора из схемы дает больший прирост к метрикам, чем недели подбора гиперпараметров.

6. Design Rules: Чек-лист для продакшена

Опираясь на сотни экспериментов, мы составили матрицу применимости моделей.

Чего НЕ делать (Анти-рекомендации)

1. Есть монотонный дрейф? Не используйте GANF и любые Normalizing Flows. Они коллапсируют.

2. Мало данных на старте? Забудьте про тяжелые графовые трансформеры, они просто выучат шум. Берите LSTM-VAE.

3. Модель плохо учится? Не меняйте архитектуру сразу. Сделайте zero-channel test — возможно, у вас есть один сломанный датчик, который сводит Loss с ума.

Заключение

При анализе публикаций по теме многомерных временных рядов (MVTS) важно сохранять критический взгляд на сверхвысокие метрики. Заявленные показатели в подавляющем большинстве случаев обусловлены применением протокола Point Adjustment, который маскирует реальную неспособность модели держать стабильный сигнал тревоги на протяжении всего аномального интервала.

В условиях промышленной эксплуатации способ валидации, понимание физики процессов и качество предобработки данных (включая аудит зашумленных каналов) определяют итоговую эффективность системы сильнее, чем выбор конкретной SOTA-архитектуры.

Честная оценка на уровне событий (Event-level F1) и стресс-тестирование на дрейф сигналов показывают, что универсального решения не существует: спектральные методы хороши в строгой периодике, графовые сети защищают от выпадения датчиков, а классическая реконструкция на базе LSTM-VAE остается стабильным базовым решением, если данные очищены от локальных наводок.

Подробное описание методологии нашего бенчмаркинга 14 архитектур и полные таблицы результатов доступны в нашей статье на arXiv.

---

В процессе бенчмаркинга мы глубоко погрузились в математику и внутреннее устройство портированных моделей. Семейства алгоритмов фундаментально отличаются: например, GANF оценивает плотность вероятности через нормализующие потоки, LSTM-VAE ищет аномалии через ошибку реконструкции, а MSCRED анализирует междоменные сбои в скользящих матрицах корреляций.

Если у сообщества будет интерес к детальному разбору этих подходов с примерами кода, архитектурными нюансами и математикой «на пальцах» — пишите в комментариях, и я подготовлю отдельный подробный разбор этих трех семейств.