[СТАТЬЯ] Покоряем гору временных рядов: делаем прогноз для 200+ рядов с библиотекой Etna

У Магнит OMNI ❤ 19 января вышел туториал для новичков по временным рядам с использование библиотеки ETNA

Ниже короткий разбор, что в ней есть 👇

1. В статье начали с наивных прогнозов последним значением, а далее начали применять библиотеку ETNA
2. Сравнивали несколько моделей по WAPE (абсолютной взвешенной ошибке)
3. Показали как применить пользовательские преобразования (в примере — создание линейного тренда для модели линейной регрессии) ✏️
4. Выделили блок про стандартизацию данных для оценки временных рядов (в целом, это нужно для соразмерности сравнения ошибок между моделями).
5. Уделили время аномалиям (что они влияют на прогноз и как фреймворк может их обнаруживать).
6. Какими значениями можно заменять аномалии (в примере — предыдущее значение).
7. Далее указали, что проблема может быть в точках изменения тренда.

Новичкам, которые работают с временными рядами, зайдёт. Это скорее инструкция по возможностям библиотеки и типовым проблемам: аномалии, точки перегиба, оценка качества и т.д.

Сам сталкивался с проблемами аномалий и точек перегиба — в статье это подсвечено.

Если вдруг будет интересно, можно попробовать собрать пару постов по прогнозу временных рядов, если увижу много 📈 (давайте попробуем 150+).

Можно для интереса залезть в комменты, там один из комментаторов говорит про фильтр Калмана (по пропуску пропущенных значений) и ссылается на статью, в которой сравнивают с простыми методами замены пропусков (при линейной динамике показывает меньшую ошибку восстановления пропусков).

А как у вас дела с временными рядами? Успели с ними поработать и что-то спрогнозировать? Делитесь в комментариях

@zasql_python

Что ж, всех с понедельником! Календарь забит важными встречами, просьба не отвлекать по всякой ерунде 😂

А как планируете провести эту неделю? И этот день?

Я:

— Хочу отлично поработать и закрыть задачи спринта с фулл-фокусом. Посмотрим, на мое состояние в пятницу 👀
— Написать пару постов на неделю
— Сходить в тренажерный зал, делал перерыв. Чувствую, что без него, стало тяжелее жить
— Порешать задачи на Степике, кстати, планировал выпустить второй пост с подборкой курсов, ставьте 🐳
— Пересмотреть записи лекций и семинаров с учебы в магистратуре. Надеюсь, там будет еще что-то полезное.

А у вас как по плану? Работа, сияние или сразу царственно отдыхать? 😌

@zasql_python

Проблемы с фокусом во время работы — это не лень

Вы погружены в задачу, хочется ее решить.
Голова работает.
Но...

1️⃣ Вас выдергивают на важные встречи.
2️⃣ Вам спамят личку и спрашивают, какой статус по задаче
3️⃣ Вы думаете, что задачу нужно отдать идеально
4️⃣ Вы переключились на другую вкладку и в итоге забыли, зачем открывали
5️⃣ Параллельно вы начали делать другую задачу

И под конец рабочего дня задача не сделана, вы устали, чувствуете вину

Фокус ломается не из-за лени, а из-за среды и когнитивной перегрузки. Это проблема неправильной организации внимания.

🟢 Должен быть четкий объект фокуса. Нужно себе ответить на вопрос, над чем сейчас работаешь, чтобы явно себе понять, на чем нужно сфокусироваться.
🟢 Отключить ненужные уведомления. Нам кажется, что мы постоянно должны впитывать любую информацию. Но любая информация — это потеря фокуса на основных задачах 🔕
🟢 Выбрать оптимальную технику для фокуса. Это может быть Pomodoro, Deep Work, Pomodoro 2.0 даже. Техники бывают разные, в Яндексе я старался работать по Deep Work и это было эффективно. Сейчас выбираю для себя Pomodoro 🍅
🟢 Убрать мелкие выборы. Иногда себя ловлю на мысли о том, а какую вкладку нужно открыть (особенно, когда их много). Ранее слышал, что любое принятие решение тратит когнитивные силы, поэтому убираем 🤔
🟢 Фиксировать момент потери фокуса. Вы отвлеклись на другое дело? Это важно, потому что фокус теряется не случайно.

📺 Кстати, у Андрея было классное видео про то, как он вернул себе фокус на задачах

Еще из прикольного: там говорится о разгрузке мозга с помощью любого текстового документа, физическую активность...

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

А как у вас с фокусом? Теряетесь или все в порядке? Ставьте 🐳, если пост понравился, делитесь с теми, у кого проблемы с фокусом

@zasql_python

😁 Нашел себе занятие на выходные... на ближайшие N месяцев

💻 Забрал сегодня предзаказ книги Валеры Бабушкина и Арсения Кравченко по машинному обучению на русском языке.

Буду периодически закидывать сюда свои мысли по прочитанным материалам, формировать конспекты.

Если вам интересно, отреагируйте на пост реакциями или комментами 🐳

Кто-то успел ее уже прочитать на английском языке? Как ваши впечатления? Делитесь 🍪🍪

@zasql_python

🟡 ROC-AUC кривая. Метрика оценки качества модели классификации в машинном обучении

Да чего там делать пост, берешь sklearn, делаешь импорт из metrics и погнал. Чем ближе к 1, тем лучше => выбираем. Но давайте разбираться более детальною.

❓ ROC-AUC — это вероятность того, что наши положительные классы получили больший скор, чем отрицательные.

🔽 Пример: предположим, у нас есть следующая таблица.

| object | score value | y |
|--------|-------------|---|
| A      | 0.92        | 1 |
| B      | 0.81        | 1 |
| C      | 0.74        | 0 |
| D      | 0.63        | 1 |
| E      | 0.41        | 0 |
| F      | 0.27        | 0 |
| G      | 0.18        | 0 |
| H      | 0.05        | 1 |

✏️ Для каждого порога (в таблице значения) в отсортированной по скору таблице вычислим по строкам значения:

Для 1 строки считаем какие объекты попадают в score >= 0.92 — это один положительный класс. Среди всех положительных (4) => TPR = 1/4. При этом мы рассмотрели только один объект положительного класса => FPR = 0.

Для 2 строки считаем уже два объекта A, B. Это оба положительных класса. Среди всех положительных (4) => TPR = 2/4 = 1/2. Пока что объектов с классом 0 не попалось.

Для 3 строки считаем уже три объекта A, B, C. Смотрим на объект со скором >= 0.74. TPR по-прежнему = 1/2, а вот FPR увеличился, так как залетел новый объект с меткой 0. Среди всех отрицательных классов (4) => FPR = 1/4.

Далее считаем TPR, FPR для каждой из строк (Сколько объектов мы отнесли к положительному классу из всех возможных объектов класса).

По сути, мы отвечаем на вопрос: В скольких случаях скор, полученный по модели для положительных классов выше, чем для отрицательных.

Графически это выглядит как ступеньки (по оси X — FPR, по оси Y — TPR). При движении по трешхолдам для отнесения к классам смотрим как меняются значения TPR и FPR, кстати еще есть значения трешхолдов в самой библиотеке sklearn.

🧠 Чтобы посчитать вручную само значение:

Нужно взять все сочетания положительных и негативных классов и сравнить в каких случаях выше. Для нашего случая это:

1. A > C, A > E, A > F, A > G (пол.)
2. B > C, B > E, B > F, B > G (пол.)
3. C > D, C > H (нег.)
4. D > E, D > F, D > G (пол.)
5. E > H (нег.)
6. F > H (нег.)
6. G > H (нег.).

Считаем количество всех сочетаний: 16
Считаем количество правильных среди положительных: 11
ROC-AUC = 11/16 = 0.6875

✋ Ограничения в ML

1. Не учитывает цену ошибок (FP = FN по важности)
2. Не даёт порог для принятия решения
3. Ломается при сильном дисбалансе
4. Игнорирует калибровку вероятностей
5. Одно число скрывает локальные ошибки

🐍 Как можно применять для аналитики

1. Если есть модель и мы хотим определить есть ли сигнал в данных (ROC-AUC > 0.5). То есть позволяют ли наши признаки сделать модель такую, чтобы она была лучше случайности.

2. Понять, какие фичи улучшают разделение между TP и FP. Например, при добавлении фичи ROC-AUC увеличился => появился новый сигнал.

3. Проверка эвристики против модели. Оправдано ли применение ML-модели в принципе или достаточно эвристику.

4. Сравнение сегментов / источников сигнала. Задача: понять, где модель работает.

5. Оценка классификации по неделям. Понимаем, что ROC-AUC по неделям деградирует => нужно добавить больше признаков для обобщения.

6. Сравнение разных таргетов. Один таргет лучше отделяется => он более предсказуем и устойчив

Если коротко: ROC-AUC отвечает на вопрос есть ли сигнал, а не как принимать решение

Понравился пост? Ставьте 🐳, пишите комментарии!

@zasql_python

Перед запуском проекта привлекайте всех заинтересованных лиц (ну или почти всех)

Это касается не только аналитиков, но и продактов, дизайнеров, разработчиков. Худшее, что может случиться с проектом — ты узнаёшь о процессе после продакшена и пытаешься понять, что вообще происходит.

1. Расширение бизнес-контекста. Круто, когда все в синке по продуктовым изменениям. На общих встречах понимать друг друга, кто куда движется и какие есть ограничения у систем при раскатке. Например, почему нельзя сразу катнуть на всех: лимиты инфраструктуры, неготовая аналитика, риск убить ключевую метрику — и это важно проговорить заранее, а не в разгар инцидента.

Практически любой человек, который работает в продукте должен его понимать, в том числе бизнесово

2. Возможность переложить бизнес-контекст на "свой" язык до фактической раскатки. Продумывая систему можно обрисовать примерный план действий. Аналитику нужно настроить систему алертинга, рассчитать метрики, придумать заранее срезы. Разработчику понять, что все события корректно логируется и сервис получает и отдает, что нужно. Потому что после раскатки начинается пожар: всё падает, метрик нет, логов не хватает, а отвечать нужно уже сейчас 🐸

Придумать план действий, задизайнить систему с заинтересованными лицами, понять сколько нужно делать шагов для нормально функционирования

3. Понятный список обязанностей на проекте. Казалось бы, что может здесь пойти не так. У дизайнеров свой вайб, у разработчиков и аналитиков тоже. Но есть часть задач, которые находятся на пересечении. Стоит это заранее обсудить перед запуском, так как возникнут сложности, либо несколько людей будут делать одну и ту же работу.

Если несколько человек делают одну и ту же задачу без договорённостей — это почти гарантированные расхождения и потеря времени

🥺

4. Меньше мисскоммуникации. Случается так, что между заинтересованными лицами случается следующее: делаем это, хотя нужно сделать вот это. Если продолжается часто, нужно задуматься над тем, а что вообще происходит и можно ли это пофиксить. Например, собрать общий синк и обсудить.

А у вас было такое, что вы узнавали о ключевом процессе уже после продакшена? Чем это закончилось — спасли или тушили пожар? Ставьте 🐳, пишите комментарии!

@zasql_python