#mlflow #bastards
Некоторые фреймворки поражают. В MLFlow в 2023 году НЕТ простой аутентификации. Разворачиваешь свой МЛ-сервер, желая сотрудничать с коллегами из других городов и стран? Будь готов, что твои эксперименты, модели, графики увидит весь мир, ведь парни из mlflow не смогли добавить простую функциональность даже типа логин/пароль. К тому же, если бэк хранится в СУБД, это ещё и прямая дорожка к SQL-иньекциям... Защитить сервер всё же можно, но это надо морочиться с установкой nginx, файлами конфига, документацией. Ну не мудаки ли? Хотя, с другой стороны, это же бесплатно, мудак тут скорее я.
Некоторые фреймворки поражают. В MLFlow в 2023 году НЕТ простой аутентификации. Разворачиваешь свой МЛ-сервер, желая сотрудничать с коллегами из других городов и стран? Будь готов, что твои эксперименты, модели, графики увидит весь мир, ведь парни из mlflow не смогли добавить простую функциональность даже типа логин/пароль. К тому же, если бэк хранится в СУБД, это ещё и прямая дорожка к SQL-иньекциям... Защитить сервер всё же можно, но это надо морочиться с установкой nginx, файлами конфига, документацией. Ну не мудаки ли? Хотя, с другой стороны, это же бесплатно, мудак тут скорее я.
#mlops #beeline #k8s #mlflow #argoworkflows #greatexpectations #cookiecutter #hadoop #spark
https://www.youtube.com/watch?v=iE0zA8hDbHY
https://www.youtube.com/watch?v=iE0zA8hDbHY
YouTube
Николай Безносов - MLOps в билайн: как катить машинное обучение в production без ML-инженеров
В докладе обсудим:
- Как были устроены наши MLOps процессы и инфраструктура, когда команда была небольшой
- Какие при этом были проблемы
- Что мы поменяли, чтобы сделать процесс вывода ML решений в production гибче и эффективнее
- Как мы адаптировали MLFlow…
- Как были устроены наши MLOps процессы и инфраструктура, когда команда была небольшой
- Какие при этом были проблемы
- Что мы поменяли, чтобы сделать процесс вывода ML решений в production гибче и эффективнее
- Как мы адаптировали MLFlow…
#mlops #mlflow
Продолжаю изучать mlflow. Очень понравилась, что по обученной модели можно быстро получить список метрик и значимостей признаков. А ещё можно даже настроить критерии приёмки модели в бой, абсолютные (точность не менее X%) и относительные (точность не менее Y% лучше чем DummyClassifier). Ложка дёгтя в том, что указанный в доке вызов
https://mlflow.org/docs/latest/models.html#model-validation
Продолжаю изучать mlflow. Очень понравилась, что по обученной модели можно быстро получить список метрик и значимостей признаков. А ещё можно даже настроить критерии приёмки модели в бой, абсолютные (точность не менее X%) и относительные (точность не менее Y% лучше чем DummyClassifier). Ложка дёгтя в том, что указанный в доке вызов
mlflow.models.list_evaluators() не работает.https://mlflow.org/docs/latest/models.html#model-validation
#mlops #tracking #mlflow
Несколько классных трюков для продуктивной работы с mlflow. Мне оч понравилась встройка кастомных веб-страничек и дочерние эксперименты (UI с прошлого года поддерживает многоуровневость).
По идее, в МЛ эксперимент может равняться фичерсету+таргету, а запуски (runs) могут соответствовать разным конвейерам обработки (с/без FS,RS,OR,ES,HPT).
Дочерние запуски нужны, если хотим логировать промежуточные модели, обученные на фолдах CV. Или если хотим на одних и тех же данных/конвейере сравнить несколько моделей разных классов (gbdt, ann). Или если включено HPT, тогда каждый запуск порождает N субмоделей с разными гиперпараметрами.
К сожалению, вложенными могут быть только запуски, но не эксперименты, хотя это вроде бы на поверхности. У нас же в рамках одного проекта может быть несколько датасетов, несколько задач, у каждой много таргетов. (+Желательны свои уровни допуска разным юзерам, но об этом умолчим). Сейчас пользователям MLFlow приходится, видимо, эту иерархию разворачивать в плоские структуры. Или как-то лепить в тэги.
https://towardsdatascience.com/5-tips-for-mlflow-experiment-tracking-c70ae117b03f
Несколько классных трюков для продуктивной работы с mlflow. Мне оч понравилась встройка кастомных веб-страничек и дочерние эксперименты (UI с прошлого года поддерживает многоуровневость).
По идее, в МЛ эксперимент может равняться фичерсету+таргету, а запуски (runs) могут соответствовать разным конвейерам обработки (с/без FS,RS,OR,ES,HPT).
Дочерние запуски нужны, если хотим логировать промежуточные модели, обученные на фолдах CV. Или если хотим на одних и тех же данных/конвейере сравнить несколько моделей разных классов (gbdt, ann). Или если включено HPT, тогда каждый запуск порождает N субмоделей с разными гиперпараметрами.
К сожалению, вложенными могут быть только запуски, но не эксперименты, хотя это вроде бы на поверхности. У нас же в рамках одного проекта может быть несколько датасетов, несколько задач, у каждой много таргетов. (+Желательны свои уровни допуска разным юзерам, но об этом умолчим). Сейчас пользователям MLFlow приходится, видимо, эту иерархию разворачивать в плоские структуры. Или как-то лепить в тэги.
https://towardsdatascience.com/5-tips-for-mlflow-experiment-tracking-c70ae117b03f
Medium
5 Tips for MLflow Experiment Tracking
Push MLflow to its limits: visualize, organize, alter and correct your mlflow runs
#ml #mlops #mlflow #me #metrics #multimodel
Очень срезонировало это выступление. Я сейчас разрабатываю как раз такую систему, с мультиметриками, несколькими моделями разных классов. Даже ещё добавляю сразу ансамбли. Про ME (Maximum Error) как обязательную regression-метрику кажется очень полезно, никогда раньше не слышал. От себя бы добавил в обязательные метрики классификации что-то калибрационное: MAE/std над бинами калибрационной кривой, к примеру.
https://www.youtube.com/watch?v=VJWrSTAlxEs
Очень срезонировало это выступление. Я сейчас разрабатываю как раз такую систему, с мультиметриками, несколькими моделями разных классов. Даже ещё добавляю сразу ансамбли. Про ME (Maximum Error) как обязательную regression-метрику кажется очень полезно, никогда раньше не слышал. От себя бы добавил в обязательные метрики классификации что-то калибрационное: MAE/std над бинами калибрационной кривой, к примеру.
https://www.youtube.com/watch?v=VJWrSTAlxEs
YouTube
Андрей Зубков - Без чего с ML в проде жизнь не мила
Data Fest 2023:
https://ods.ai/events/datafestonline2023
Трек "MLOps":
https://ods.ai/tracks/df23-mlops
Наши соц.сети:
Telegram: https://t.me/datafest
Вконтакте: https://vk.com/datafest
https://ods.ai/events/datafestonline2023
Трек "MLOps":
https://ods.ai/tracks/df23-mlops
Наши соц.сети:
Telegram: https://t.me/datafest
Вконтакте: https://vk.com/datafest
#trading #scalping #erema #mlops #experimenting #mlflow
Потратил много времени на кодинг платформы, позволяющей экспериментировать с группами фичей, блоками ML-конвейеров, таргетами, моделями, ансамблями.
Иногда при работе над очередным проектом думаешь: а что лучше, отдать работу с категорийкой на откуп бустингу, или попробовать что-то из category_encoders? И вообще, что считать категориальными факторами, то, что имеет тип данных categorical/object, или что имеет мало уникальных значений? А "мало" - это мало вообще, или по отношению к конкретному типу данных и диапазону? А может, вообще все непрерывные побить на с помощью KBinsDiscretizer, что тогда будет, лучше или хуже, и насколько? Или может, вообще удалить категорийку, вдруг будет не сильно хуже, но быстрее?
А пропуски как обрабатывать? А всё это вместе взятое сколько комбинаций составит?
Раннюю остановку использовать или нет, и когда?
Какая модель в итоге лучше сработает, бустинг или нейронка? Блин, а нейронке-то напрямую нельзя подать категориальные фичи, надо выкручиваться.
А если гиперпараметры тюнить? А фичи отбирать? А что, если вообще поработать с группами фичей по отдельности (например, рыночные, новостные, фундаментальные), какого результата каждая достигнет??
А если потом модельки от разных в групп в ансамбль объединить, лучше станет, и насколько?
А вообще, какие таргеты мы можем лучше предсказывать, что, если мы можем немного варьировать их, к примеру, предсказываем продажи на неделю или 2 или 3 вперёд. Где выше прогннозируемость и при каких условия, на чём сконцентрировать усилия? Если сравнивать в лоб, на препроцессинг уйдёт тонна времени, тут нужно умное кэширование.
А всё это же ещё надо на CV считать... А так как число комбинаций, которые хочется проверить, огромно, лучше считать на кластере или хотя бы на нескольких нодах, с централизованным хранением результатов (предсказаний, метрик, графиков).
А как всё это грамотно отобразить, чтобы не потеряться в тысячах комбинаций? А как при этом работать в команде?
Наверняка к подобным вопросам со временем, или при работе над особо сложным проектом, приходит любой дата сайентист/кэгглер, который хорошо делает свою работу. Настало и моё время )
Трейдинговый проект #erema меня просто ошеломлял количеством факторов, возможных таргетов и ML опций, которые хотелось проверить. Так что после 2 месяцев работы я получил процедуры, которые на базе mlflow как раз позволяют разбить всё многообразие опций на блоки и проверить их по отдельности.
Потратил много времени на кодинг платформы, позволяющей экспериментировать с группами фичей, блоками ML-конвейеров, таргетами, моделями, ансамблями.
Иногда при работе над очередным проектом думаешь: а что лучше, отдать работу с категорийкой на откуп бустингу, или попробовать что-то из category_encoders? И вообще, что считать категориальными факторами, то, что имеет тип данных categorical/object, или что имеет мало уникальных значений? А "мало" - это мало вообще, или по отношению к конкретному типу данных и диапазону? А может, вообще все непрерывные побить на с помощью KBinsDiscretizer, что тогда будет, лучше или хуже, и насколько? Или может, вообще удалить категорийку, вдруг будет не сильно хуже, но быстрее?
А пропуски как обрабатывать? А всё это вместе взятое сколько комбинаций составит?
Раннюю остановку использовать или нет, и когда?
Какая модель в итоге лучше сработает, бустинг или нейронка? Блин, а нейронке-то напрямую нельзя подать категориальные фичи, надо выкручиваться.
А если гиперпараметры тюнить? А фичи отбирать? А что, если вообще поработать с группами фичей по отдельности (например, рыночные, новостные, фундаментальные), какого результата каждая достигнет??
А если потом модельки от разных в групп в ансамбль объединить, лучше станет, и насколько?
А вообще, какие таргеты мы можем лучше предсказывать, что, если мы можем немного варьировать их, к примеру, предсказываем продажи на неделю или 2 или 3 вперёд. Где выше прогннозируемость и при каких условия, на чём сконцентрировать усилия? Если сравнивать в лоб, на препроцессинг уйдёт тонна времени, тут нужно умное кэширование.
А всё это же ещё надо на CV считать... А так как число комбинаций, которые хочется проверить, огромно, лучше считать на кластере или хотя бы на нескольких нодах, с централизованным хранением результатов (предсказаний, метрик, графиков).
А как всё это грамотно отобразить, чтобы не потеряться в тысячах комбинаций? А как при этом работать в команде?
Наверняка к подобным вопросам со временем, или при работе над особо сложным проектом, приходит любой дата сайентист/кэгглер, который хорошо делает свою работу. Настало и моё время )
Трейдинговый проект #erema меня просто ошеломлял количеством факторов, возможных таргетов и ML опций, которые хотелось проверить. Так что после 2 месяцев работы я получил процедуры, которые на базе mlflow как раз позволяют разбить всё многообразие опций на блоки и проверить их по отдельности.