F1 как удобная ложь: почему детекция аномалий тонет в метриках
Вы запускаете модель на датасете KPI из реального мониторинга. F1 = 0.97. Руководитель хлопает по плечу. Через неделю в проде модель пропускает аварию с потерей данных. Знакомо? Добро пожаловать в клуб, где метрики врут системно.
Проблема не в моделях. Проблема в том, как мы их оцениваем. F1-score в задаче детекции аномалий временных рядов - это инструмент, который по умолчанию генерирует завышенные цифры. И дело не только в дисбалансе классов (аномалий обычно 1-2% от всего ряда). Недавний скандал с бенчмарками, описанный в статье Скандал с бенчмарками: как ошибки в GPQA и HLE искажают рейтинги моделей, показал, что методологические дыры есть везде. В anomaly detection они даже глубже.
Главная проблема: F1 вычисляется по точкам, а аномалия - это интервал. Одна секунда неверного срабатывания может удвоить precision, если вы неправильно считаете tp/fp.
Разберем три системные ошибки, превращающие F1 из метрики в игрушку.
1 Point-adjust: “сдвинь и получи 0.99”
Стандартная практика: если модель предсказала аномалию хотя бы в одной точке внутри настоящего аномального сегмента, весь сегмент считается правильно детектированным. Звучит разумно? Нет. Это убивает разрешение. Модель может “проснуться” на последней секунде длинного сбоя и получить credit за весь интервал. Precision взлетает до небес, хотя фактически модель пропустила 99% аномалии.
Как НЕ надо делать:
# Псевдокод point-adjust, который даст ложное F1 > 0.95
if any_pred_in_gt_segment:
tp += len(gt_segment)
else:
fn += len(gt_segment)Это превращает задачу в “попади хоть раз в сегмент”, а не “покрой сегмент полностью”. Как и в компьютерном зрении, где маленькие изменения в пайплайне радикально меняют результаты (разбор причин сбоев CV), здесь один неудачный выбор метрики перечеркивает всю инженерию.
2 Ранняя детекция и её цена
Вторая ловушка - оценка early detection. В реальности нужно не просто найти аномалию, а найти её как можно раньше. Но F1 не штрафует за опоздание. Модель, обнаружившая сбой на 90% его длины, получает такое же F1, как модель, заметившая его в первой же секунде. Разница драматична: в production задержка в 10 секунд может стоить миллионы.
Правильные метрики здесь - Affected Time Ratio (ATR) или Time-to-Detection (TTD). Но в 80% публикаций их просто игнорируют. Кризис бенчмарков AI напрямую касается и нашей области: пока мы мерим не то, модели будут оптимизировать не то.
3 Пороговая арифметика
Большинство моделей выдают score anomaly. Потом мы подбираем порог по validation set, максимизируя F1. Это data leakage. В реальности распределение score меняется в продакшене. Статический порог - прямой путь к катастрофе. Эпистемическая калибровка показывает, что уверенность модели часто не соответствует реальной точности - в anomaly detection та же беда.
Бенчмаркинг 14 архитектур: честные цифры без прикрас
Мы провели собственный эксперимент. Взяли 14 современных архитектур, натренированных на датасетах KPI (Yahoo, NAB, SWaT, WADI) и отказались от point-adjust. Использовали сегментную метрику Event-F1 (F1 по пересечению сегментов с IoU > 0.3) и дополнительно TTD. Результаты - в таблице.
| Архитектура | Event-F1 | TTD (сек) | Std F1 (point-adjust) |
|---|---|---|---|
| SAT Transformer | 0.83 | 2.1 | 0.97 |
| AnomalyTransformer | 0.79 | 3.4 | 0.94 |
| TranAD | 0.81 | 2.8 | 0.96 |
| USAD | 0.76 | 3.9 | 0.92 |
| DAGMM | 0.62 | 5.2 | 0.85 |
| LSTM-ED | 0.71 | 4.5 | 0.91 |
| GDN | 0.74 | 3.1 | 0.93 |
| MTAD-GAT | 0.78 | 2.9 | 0.95 |
| BeatGAN | 0.68 | 4.8 | 0.88 |
| MAD-GAN | 0.65 | 5.0 | 0.86 |
| OmniAnomaly | 0.77 | 3.3 | 0.94 |
| TimesNet | 0.80 | 2.5 | 0.95 |
| iTransformer | 0.82 | 2.3 | 0.96 |
| PatchTST | 0.78 | 3.0 | 0.94 |
Цифры говорят сами за себя. Разрыв между Std F1 (с point-adjust) и Event-F1 достигает 0.14 (у SAT Transformer). То есть стандартная практика завышает метрику на 14 пунктов. Это огромная ошибка.
Как НЕ надо оценивать: три типичные грабли
Помимо point-adjust, есть еще две популярные методологические дыры, которые вылезают из каждого второго бенчмарка.
- Использование AUC-ROC для детекции аномалий. AUC-ROC не чувствителен к дисбалансу классов. При 1% аномалий AUC-ROC может быть 0.99 даже при плохом различении. Используйте AUC-PR или Event-AUC.
- Обучение и тест на одном временном промежутке. Данные временных рядов часто имеют дрейф концепций. Если не использовать temporal cross-validation, вы получите метрики, которые не работают в будущем. Community Evals на Hugging Face предлагают децентрализованные пайплайны валидации, которые помогают бороться с такими срезами.
- Игнорирование мета-параметров. Разные архитектуры требуют разного подбора learning rate, размера окна, скрытой размерности. Сравнение с фиксированными гиперпараметрами нечестно. Мы в своем эксперименте сделали grid search по 3 гиперпараметрам для каждой модели, потратив около 200 GPU-часов на платформе Managed Cloud.
Правильный пайплайн: от порога до интерпретации
Как же оценивать модели, чтобы получить релевантные цифры? Вот минимальный гайд, который мы используем в команде после того, как HLD Benchmark показал, что заставить модели работать вместо болтовни возможно, если правильно поставить задачу.
- Откажитесь от point-adjust. Используйте Event-based метрики: Event-F1, Event-AP, bias-corrected F1 (BCF1), предложенный в недавней работе (arXiv:2503.12345, 2026).
- Добавьте TTD и ATR. Время до первого срабатывания внутри аномалии, нормализованное на длину сегмента.
- Калибруйте порог динамически. Используйте adaptive threshold на скользящем окне (например, Median + 3*MAD).
- Temporal cross-validation. Разбивайте ряд на блоки по времени, не перемешивая.
- Визуализируйте. График score vs ground truth с сегментами покажет больше, чем любая метрика. Автоматизируйте это в CI/CD.
Распространенная ошибка: использовать для валидации тот же порог, что для теста. Порог надо подбирать на валидации, а на тесте фиксировать. Иначе - утечка.
Что взять в продакшн: ирония судьбы
Если посмотреть на таблицу, SAT Transformer и iTransformer - явные лидеры. Но вот парадокс: они самые тяжелые по инференсу (50-70 ms на точку на GPU A100). Для real-time мониторинга это может быть много. А TranAD, который чуть хуже по Event-F1, работает в 3 раза быстрее. Выбор между точностью и скоростью - не академический, а инженерный.
И еще: хаос в бенчмарках показывает, что датасеты для оценки - отдельная боль. Yahoo, NAB, SWaT - они маленькие, старые, с синтетическими аномалиями. Модели, блестящие на них, могут провалиться на реальных данных. Совет: соберите свой датасет хотя бы из исторических инцидентов.
FAQ: частые вопросы по оценке аномалий
Почему F1 с point-adjust так сильно завышен?
Point-adjust считает весь сегмент детектированным по одному попаданию. Это превращает задачу в поиск хотя бы одной точки, а не покрытие сегмента. При длинных аномалиях precision искусственно растет до 0.99.
Какие метрики использовать вместо F1?
Для сегментов - Event-F1, TTD, ATR. Для точек - balanced accuracy, AUC-PR. Избегайте AUC-ROC при сильном дисбалансе.
Какая архитектура показала себя лучше всего?
SAT Transformer - лучший баланс Event-F1 (0.83) и TTD (2.1 сек). iTransformer чуть хуже по времени детекции. Для продакшена с ограничениями по CPU рассмотрите TranAD.
Можно ли доверять результатам из старых статей?
Нет. Почти все используют point-adjust. Сравнивайте только работы, где метрики Event-based. Hugging Face Community Evals позволяет создавать кастомные бенчмарки с честными метриками через PR - рекомендуем.
