#featureengineering #supervisedlearning #standardpractice
Недавно был материал о стандартном подходе к решению ML-задач с разметкой (не хочется использовать термин "с учителем", нет там учителя/супервизора), хотелось бы подробнее остановиться на создании признаков.
Часто бывает, что в модельной задаче есть целые группы признаков, которые относятся к определённой сущности: пользователю, компании, активностям, внешней среде, локациям. Часть из них текстовые, часть графовые. Это всё ещё часто осложняется временной структурой, и надо думать об агрегатах этих всех признаков по некоторым скользящим окнам. Если всё это богатство слепить в одну таблицу, начинают буксовать любые алгоритмы, не говоря уже про требования к железу. Как не сойти с ума во время такой инженерии и добиться осмысленных результатов в рамках бюджета?
Пока я остановился на таком подходе.
1) определяем Cross-Validation schema и метрики
2) настраиваем библу для трекинга, типа neptune или mlflow
3) начинаем с DummyClassifier/Regressor (DummyLags, если у вас timeseries-задача) со всеми доступными strategy. Лучший по метрикам становится baseline-ом.
4) работаем индивидуально по группам, относящимся к отдельным классам сущностей (юзеры, компании, и т.п.), начиная с самых простых
5) также можно работать по признакам, объединённым типом данных, например, все текстовые. это позволит ещё и логично считать межпризнаковые связи, например, расстояния в разных пространствах.
6) на данной группе построенных признаков обучаемся, фиксируем CV метрики, делаем анализ важности признаков, фиксируем барчарт важностей и список как артефакт модели и фичерсета. важность признаков в группе позволяет понять, куда копать дальше, в какие дебри углубляться
7) если это временной ряд, надо строить окна. строим коррелограмму, ориентируемся на пики графика, начинаем с небольших окон.
8) когда все группы пройдены, анализируем важности признаков и принимаем решение о том, в какую сторону углубляться, повторяем цикл с более "тонкими" признаками
9) теперь объединяем группы, пробуем обучаться на всех сразу, и используя Feature Selector (по-прежнему на CV).
10) если остаётся время, пробуем отношения фичей из разных групп, их добавляем к основному датасету и прогоняем тоже через пункт 9
Теперь смотрим в свой трекинг, выбираем лучший вариант по соотношению сложность/качество. Страдает ли этот метод от подгонки? Конечно, ведь мы, принимая решения о новых фичах, заглядываем в метрики. Можно ли этого избежать? Не знаю. Но можно зарезервировать часть данных под OOS, и финальное решение принимать только по этому набору, это уменьшит смещение.
Недавно был материал о стандартном подходе к решению ML-задач с разметкой (не хочется использовать термин "с учителем", нет там учителя/супервизора), хотелось бы подробнее остановиться на создании признаков.
Часто бывает, что в модельной задаче есть целые группы признаков, которые относятся к определённой сущности: пользователю, компании, активностям, внешней среде, локациям. Часть из них текстовые, часть графовые. Это всё ещё часто осложняется временной структурой, и надо думать об агрегатах этих всех признаков по некоторым скользящим окнам. Если всё это богатство слепить в одну таблицу, начинают буксовать любые алгоритмы, не говоря уже про требования к железу. Как не сойти с ума во время такой инженерии и добиться осмысленных результатов в рамках бюджета?
Пока я остановился на таком подходе.
1) определяем Cross-Validation schema и метрики
2) настраиваем библу для трекинга, типа neptune или mlflow
3) начинаем с DummyClassifier/Regressor (DummyLags, если у вас timeseries-задача) со всеми доступными strategy. Лучший по метрикам становится baseline-ом.
4) работаем индивидуально по группам, относящимся к отдельным классам сущностей (юзеры, компании, и т.п.), начиная с самых простых
5) также можно работать по признакам, объединённым типом данных, например, все текстовые. это позволит ещё и логично считать межпризнаковые связи, например, расстояния в разных пространствах.
6) на данной группе построенных признаков обучаемся, фиксируем CV метрики, делаем анализ важности признаков, фиксируем барчарт важностей и список как артефакт модели и фичерсета. важность признаков в группе позволяет понять, куда копать дальше, в какие дебри углубляться
7) если это временной ряд, надо строить окна. строим коррелограмму, ориентируемся на пики графика, начинаем с небольших окон.
8) когда все группы пройдены, анализируем важности признаков и принимаем решение о том, в какую сторону углубляться, повторяем цикл с более "тонкими" признаками
9) теперь объединяем группы, пробуем обучаться на всех сразу, и используя Feature Selector (по-прежнему на CV).
10) если остаётся время, пробуем отношения фичей из разных групп, их добавляем к основному датасету и прогоняем тоже через пункт 9
Теперь смотрим в свой трекинг, выбираем лучший вариант по соотношению сложность/качество. Страдает ли этот метод от подгонки? Конечно, ведь мы, принимая решения о новых фичах, заглядываем в метрики. Можно ли этого избежать? Не знаю. Но можно зарезервировать часть данных под OOS, и финальное решение принимать только по этому набору, это уменьшит смещение.
Telegram
Aspiring Data Science
Мой фреймворк для проектов с DL-экспериментами
Начиная новый проект, я представляю, что вокруг меня прогружается мир в игре. Взаимодействуя с ним я лучше понимаю задачу и как хорошо я могу ее выполнить. И что вообще значит "хорошо"
👉🏻 Формулирую задачу…
Начиная новый проект, я представляю, что вокруг меня прогружается мир в игре. Взаимодействуя с ним я лучше понимаю задачу и как хорошо я могу ее выполнить. И что вообще значит "хорошо"
👉🏻 Формулирую задачу…
#featureengineering #hamilton
Новая библа для вдумчивого, покрытого тестами создания признаков. Каждый признак - функция. Драйвер выполняет функции в том числе на системах оркестрации типа prefect, airflow. Есть удобные декораторы метаданных, валидации. Наверное, это хорошо для энтерпрайза, где командная работа, и важно понимание, как что считается и кто за что в ответе. Также обещают масштабируемость (Ray, Dask, Spark).
https://www.youtube.com/watch?v=oQLEkjUNq0U&ab_channel=PyData
Новая библа для вдумчивого, покрытого тестами создания признаков. Каждый признак - функция. Драйвер выполняет функции в том числе на системах оркестрации типа prefect, airflow. Есть удобные декораторы метаданных, валидации. Наверное, это хорошо для энтерпрайза, где командная работа, и важно понимание, как что считается и кто за что в ответе. Также обещают масштабируемость (Ray, Dask, Spark).
https://www.youtube.com/watch?v=oQLEkjUNq0U&ab_channel=PyData
#fantasy #subwaytosally #kwerner #thecrowking
- Возьми вот, упругость тропок,
Возьми стынь и глубь колодцев,
И острый свет над покосами,
Закат – хлад излома дня.
- Не надо мне твоих тропок,
И крови сухих колодцев,
И окон, что в спину косятся,
Закатов, что тишь хранят.
Вороний король на троне
Из девятисот колосьев,
Из тысяч мышиных косточек
В степи ночной ждёт меня.
- Возьми тогда моё имя.
И будут – густые кроны,
Сыночки, что в доме возятся.
И счастье. И навсегда.
- Не нужно мне твоё имя,
И яблонь густые кроны,
И дети. Прозрачней воздуха
Кошмарное «навсегда».
В виски мои рвётся иней.
Вороний король в короне
Из сотни гадючьих хвостиков,
Не любит, не любит ждать.
***
А если захочешь свидеться,
Иди за гадючьим хвостиком,
Иди за мышиной косточкой,
За склёванным колоском.
За чёрной крылатой свитою
За криком, что всюду носится,
Над пашнями, над покосами,
Звенит между облаков.
Иди вслед за жуткой песенкой,
Его остроклювых пасынков –
Наследников;
Вдоль по просекам
Спеши же, пока тепло.
Смотри, как орут и бесятся,
Над выселками, над пасекой,
Пока в один миг ты просто так
Не встанешь сам на крыло.
Тогда-то мы сможем встретиться,
Тогда-то мы сможем свидеться,
В десятках мышиных косточек,
Да в склёванных колосках.
И будут сыны и доченьки,
И будет закат над гнёздышком,
И будет летать над просекой
Осипшее
наше
«кар».
К. Вернер
https://www.youtube.com/watch?v=49tMqYbNXWA&ab_channel=xXPayongXx
- Возьми вот, упругость тропок,
Возьми стынь и глубь колодцев,
И острый свет над покосами,
Закат – хлад излома дня.
- Не надо мне твоих тропок,
И крови сухих колодцев,
И окон, что в спину косятся,
Закатов, что тишь хранят.
Вороний король на троне
Из девятисот колосьев,
Из тысяч мышиных косточек
В степи ночной ждёт меня.
- Возьми тогда моё имя.
И будут – густые кроны,
Сыночки, что в доме возятся.
И счастье. И навсегда.
- Не нужно мне твоё имя,
И яблонь густые кроны,
И дети. Прозрачней воздуха
Кошмарное «навсегда».
В виски мои рвётся иней.
Вороний король в короне
Из сотни гадючьих хвостиков,
Не любит, не любит ждать.
***
А если захочешь свидеться,
Иди за гадючьим хвостиком,
Иди за мышиной косточкой,
За склёванным колоском.
За чёрной крылатой свитою
За криком, что всюду носится,
Над пашнями, над покосами,
Звенит между облаков.
Иди вслед за жуткой песенкой,
Его остроклювых пасынков –
Наследников;
Вдоль по просекам
Спеши же, пока тепло.
Смотри, как орут и бесятся,
Над выселками, над пасекой,
Пока в один миг ты просто так
Не встанешь сам на крыло.
Тогда-то мы сможем встретиться,
Тогда-то мы сможем свидеться,
В десятках мышиных косточек,
Да в склёванных колосках.
И будут сыны и доченьки,
И будет закат над гнёздышком,
И будет летать над просекой
Осипшее
наше
«кар».
К. Вернер
https://www.youtube.com/watch?v=49tMqYbNXWA&ab_channel=xXPayongXx
YouTube
Subway to Sally - Krähenkönig
Album: Kreuzfeuer
Einfach Genial ;)
All Rights at Subway to Sally
Einfach Genial ;)
All Rights at Subway to Sally
#chatgpt
"Как сообщает сайт Microsoft, более 1000 клиентов облачного сервиса уже подали заявки на использование наиболее передовых ИИ-моделей, включая Dall-E 2, GPT-3.5 и Codex. Использование вычислительных мощностей Azure, сообщает компания, обеспечивает подобным технологиям самые широкие перспективы.
Клиенты Azure OpenAI Service могут интегрировать ChatGPT в собственные приложения, предусмотрено даже наделение уже существующих ботов новыми способностями, возможно использование в колл-центрах и автоматизация обработки жалоб. Стоимость услуги составляет $0,002 за обработку 1 токена — это элементы, на которые разбивается текст при работе. Плата за использование начнёт взиматься с 13 марта."
https://servernews.ru/1083203
"Как сообщает сайт Microsoft, более 1000 клиентов облачного сервиса уже подали заявки на использование наиболее передовых ИИ-моделей, включая Dall-E 2, GPT-3.5 и Codex. Использование вычислительных мощностей Azure, сообщает компания, обеспечивает подобным технологиям самые широкие перспективы.
Клиенты Azure OpenAI Service могут интегрировать ChatGPT в собственные приложения, предусмотрено даже наделение уже существующих ботов новыми способностями, возможно использование в колл-центрах и автоматизация обработки жалоб. Стоимость услуги составляет $0,002 за обработку 1 токена — это элементы, на которые разбивается текст при работе. Плата за использование начнёт взиматься с 13 марта."
https://servernews.ru/1083203
ServerNews - все из мира больших мощностей
Доступ к ChatGPT появился в облачной службе Microsoft Azure OpenAI Service
Компания Microsoft анонсировала релиз превью-варианта интеграции чат-бота ChatGPT в службу Azure OpenAI Service. Как сообщает сайт Microsoft, более 1000 клиентов облачного сервиса уже подали заявки на использование наиболее передовых ИИ-моделей, включая Dall…
Многие модельки в sklearn не имеют возможности ранней остановки. Как часто Вы используете модели без early stopping?
Anonymous Poll
33%
Не вижу в этом проблемы. Авторы sklearn же не дураки, наверняка можно использовать без ES.
33%
Опасаюсь оверфита, использую только модели, поддерживающие early stoppping из коробки.
0%
Аналогично, только ещё заморачиваюсь с custom partial_fit, если early stoppping из коробки нет.
33%
То же, но использую не просто один validation split для early stopping, а целую mini-cv.
Forwarded from Техножрица 👩💻👩🏫👩🔧
Нашла отличное руководство о том, как избежать распространенных ошибок при обработке данных, оценке и сравнении ml моделей:
https://arxiv.org/abs/2108.02497
Написано, что гайд предназначен для исследователей, но на самом деле он выглядит полезным и для практиков.
Мне особенно понравилось то, что здесь разобрано много неочевидных сценариев того, как информация из тестового множества может протечь в тренировочное. Из всего перечисленного новым для меня был сценарий протекания информации через мозг того, кто делает модель (см. совет 2.2).
А совет 3.7 я бы ещё обобщила следующим образом: если в пайплайне используется более одной обучаемой сущности - например, если на данных сначала обучается одна модель, а потом фичи из ее латентного пространства либо её выход используются в другой, нужно следить за тем, чтобы ни одна обучаемая сущность в пайплайне не имела доступа к тестовым данным ни в каком виде (для мозга инженера придется ослабить это требование: ему всё-таки может потребоваться проверить, что данные в тесте выглядят адекватно, хотя лучше избежать соблазна слишком сильно в них всматриваться - см. п.2.2). В частности, для всех обучаемых моделей в пайплайне разбиение на трейн/тест/валидацию должно быть одинаковым.
Как-то раз у меня были очень неприятные протечки данных из-за того, что я не обратила на этот аспект достаточно внимания.
#учебные_материалы
https://arxiv.org/abs/2108.02497
Написано, что гайд предназначен для исследователей, но на самом деле он выглядит полезным и для практиков.
Мне особенно понравилось то, что здесь разобрано много неочевидных сценариев того, как информация из тестового множества может протечь в тренировочное. Из всего перечисленного новым для меня был сценарий протекания информации через мозг того, кто делает модель (см. совет 2.2).
А совет 3.7 я бы ещё обобщила следующим образом: если в пайплайне используется более одной обучаемой сущности - например, если на данных сначала обучается одна модель, а потом фичи из ее латентного пространства либо её выход используются в другой, нужно следить за тем, чтобы ни одна обучаемая сущность в пайплайне не имела доступа к тестовым данным ни в каком виде (для мозга инженера придется ослабить это требование: ему всё-таки может потребоваться проверить, что данные в тесте выглядят адекватно, хотя лучше избежать соблазна слишком сильно в них всматриваться - см. п.2.2). В частности, для всех обучаемых моделей в пайплайне разбиение на трейн/тест/валидацию должно быть одинаковым.
Как-то раз у меня были очень неприятные протечки данных из-за того, что я не обратила на этот аспект достаточно внимания.
#учебные_материалы
↑ Гениальная статья, каждый ML-щик должен это знать.
Я бы пункт "2.5 Do survey the literature" переделал. если, конечно, есть время, я специально ничего не читаю по данной проблеме, а пытаюсь решить, исходя из своих текущих знаний и опыта. а когда моё первое решение уже получено, читаю, что нашли до меня, и сравниваю перфу. как правило, решения получаются весьма разнородные, и я беру лучшее, или лучшие куски из каждого. ну или ансамблик пилю. Если сразу прочитаешь лучшие решения, будешь ограничен их рамками и не поймёшь полностью проблему. Но если время поджимает, конечно, надо брать известные решения. А если хочешь самое точное решение, изучение существующей литературы/решений надо отложить. Some variation of exploration-exploitation dilemma.
"4.2 Don’t do data augmentation before splitting your data", где по сути они говорят не использовать аугментацию на test сет, тоже спорный пункт. ну а почему бы не использовать, кому станет хуже, если проверим метрики не только на native test set, а и на augmented test set? Понятно, они будут зависимы, и их не надо суммировать, а лучше рассматривать по отдельности, но это же лучше, чем не оценивать совсем.
К "4.6 Don’t use accuracy with imbalanced data sets" я бы ещё добавил, смотрите на калибованность классификатора - Brier Score, Continuous Ranked Probability Score (если не используете веса классов, конечно). особенно если у вас настолько мало примеров некоторых классов, что точность/полноту едва можно посчитать и она пляшет.
К "4.7 Don’t ignore temporal dependencies in time series data" добавил бы совет посомтреть на параметр gap в TimeSeriesSplit. Он был добавлен (скорее всего) под влиянием книги DePrado с главой про embargoed TS CV.
"5.2 Do use statistical tests when comparing models" посоветовал бы дополнить или заменить статтесты на байесовский вывод (по причинам в т.ч. из "5.3 Do correct for multiple comparisons"), но сам пока ещё не взял эту тактику в работу, только мечтаю ) Более подробно тесты разобраны в книжке по ML от Peter Falach. Также добавлю, что есть направление мысли, согласно которому вообще не надо выбирать лучшую модель, а надо использовать ансамбль (но следить за некорелированностью участников ансамбля). Это нуждается в дописследовании, возможно, когда-нить такое сделаю. А, вот, покрыто в "5.5 Do consider combinations of models". И опять же, нет единого мнения, как лучше комбинировать ответы участников: blending( voting, weighting), meta-learning(stacking). С терминологией мог напутать, поправьте.
#ml #pitfalls #bestpractices
Я бы пункт "2.5 Do survey the literature" переделал. если, конечно, есть время, я специально ничего не читаю по данной проблеме, а пытаюсь решить, исходя из своих текущих знаний и опыта. а когда моё первое решение уже получено, читаю, что нашли до меня, и сравниваю перфу. как правило, решения получаются весьма разнородные, и я беру лучшее, или лучшие куски из каждого. ну или ансамблик пилю. Если сразу прочитаешь лучшие решения, будешь ограничен их рамками и не поймёшь полностью проблему. Но если время поджимает, конечно, надо брать известные решения. А если хочешь самое точное решение, изучение существующей литературы/решений надо отложить. Some variation of exploration-exploitation dilemma.
"4.2 Don’t do data augmentation before splitting your data", где по сути они говорят не использовать аугментацию на test сет, тоже спорный пункт. ну а почему бы не использовать, кому станет хуже, если проверим метрики не только на native test set, а и на augmented test set? Понятно, они будут зависимы, и их не надо суммировать, а лучше рассматривать по отдельности, но это же лучше, чем не оценивать совсем.
К "4.6 Don’t use accuracy with imbalanced data sets" я бы ещё добавил, смотрите на калибованность классификатора - Brier Score, Continuous Ranked Probability Score (если не используете веса классов, конечно). особенно если у вас настолько мало примеров некоторых классов, что точность/полноту едва можно посчитать и она пляшет.
К "4.7 Don’t ignore temporal dependencies in time series data" добавил бы совет посомтреть на параметр gap в TimeSeriesSplit. Он был добавлен (скорее всего) под влиянием книги DePrado с главой про embargoed TS CV.
"5.2 Do use statistical tests when comparing models" посоветовал бы дополнить или заменить статтесты на байесовский вывод (по причинам в т.ч. из "5.3 Do correct for multiple comparisons"), но сам пока ещё не взял эту тактику в работу, только мечтаю ) Более подробно тесты разобраны в книжке по ML от Peter Falach. Также добавлю, что есть направление мысли, согласно которому вообще не надо выбирать лучшую модель, а надо использовать ансамбль (но следить за некорелированностью участников ансамбля). Это нуждается в дописследовании, возможно, когда-нить такое сделаю. А, вот, покрыто в "5.5 Do consider combinations of models". И опять же, нет единого мнения, как лучше комбинировать ответы участников: blending( voting, weighting), meta-learning(stacking). С терминологией мог напутать, поправьте.
#ml #pitfalls #bestpractices
#politics #war
Хочется и смеяться, и плакать. Как пел Шевчук: что случилось с Родиной и с нами?
https://youtu.be/EDZrzxKCALI
Хочется и смеяться, и плакать. Как пел Шевчук: что случилось с Родиной и с нами?
https://youtu.be/EDZrzxKCALI
YouTube
Пригожин открывает филиалы в 42 городах! Набор 400 тысяч контрактников!
Второй канал: https://www.youtube.com/channel/UCihQbex-36nUl5KNMjC6Xxw
При создании ролика использовались информационные материалы из независимых СМИ, статьи публицистов и политологов.
При создании ролика использовались информационные материалы из независимых СМИ, статьи публицистов и политологов.
#trading #backtesting #walkforward #maestro
Ребят, как выяснилось, у нас некоторые подписчики интересуются торговлей на бирже.
Разбираем принцип работы бэктестера на живом примере )
https://youtu.be/tvetI09PcMc
Ребят, как выяснилось, у нас некоторые подписчики интересуются торговлей на бирже.
Разбираем принцип работы бэктестера на живом примере )
https://youtu.be/tvetI09PcMc
YouTube
Откровения маэстро трейдинга. Выпуск 5.
Обдуманная торговля на практике. Секреты безубыточного стабильного трейдинга.
Лучший брокер: https://www.tinkoff.ru/sl/KuwZ7ciqnm
Мой профиль: https://www.tinkoff.ru/invest/social/profile/Maestr/
Лучший брокер: https://www.tinkoff.ru/sl/KuwZ7ciqnm
Мой профиль: https://www.tinkoff.ru/invest/social/profile/Maestr/
#gpt4
"На следующей неделе OpenAI совместно с Microsoft представит большую языковую модель (LLM) нового поколения GPT-4 (Generative Pre-trained Transformer 4). Об этом сообщил технический директор немецкого подразделения Microsoft Андреас Браун (Andreas Braun). Как ожидается, GPT-4 будет значительно превосходить по функциональности предыдущую версию GPT-3.5, открывая новые возможности корпоративного использования генеративного ИИ. «Мы представим GPT-4 на следующей неделе, там у нас будут мультимодальные модели, которые предложат совершенно другие возможности — например, [генерацию] видео», — заявил Браун в ходе прошедшего в четверг мероприятия AI in Focus – Digital Kickoff. Он отметил, что использование больших языковых моделей привело к «изменению правил игры», поскольку они учат машины понимать естественный язык, что позволяет им понимать то, что ранее было доступно для понимания только человеку. Технология вышла на новый уровень и «работает на всех языках»: можно задать вопрос на немецком и получить ответ на итальянском. Благодаря мультимодальности Microsoft (совместно с OpenAI) «сделает модели всеобъемлющими», отметил Браун. Если GPT-3.5 позволяет пользователям взаимодействовать посредством ввода текста, то GPT-4 с мультимодальными возможностями, в идеале может обеспечить возможность взаимодействовать в нескольких режимах, включая текст, изображения и звуки."
https://3dnews.ru/1083235/gpt-4-launch
"На следующей неделе OpenAI совместно с Microsoft представит большую языковую модель (LLM) нового поколения GPT-4 (Generative Pre-trained Transformer 4). Об этом сообщил технический директор немецкого подразделения Microsoft Андреас Браун (Andreas Braun). Как ожидается, GPT-4 будет значительно превосходить по функциональности предыдущую версию GPT-3.5, открывая новые возможности корпоративного использования генеративного ИИ. «Мы представим GPT-4 на следующей неделе, там у нас будут мультимодальные модели, которые предложат совершенно другие возможности — например, [генерацию] видео», — заявил Браун в ходе прошедшего в четверг мероприятия AI in Focus – Digital Kickoff. Он отметил, что использование больших языковых моделей привело к «изменению правил игры», поскольку они учат машины понимать естественный язык, что позволяет им понимать то, что ранее было доступно для понимания только человеку. Технология вышла на новый уровень и «работает на всех языках»: можно задать вопрос на немецком и получить ответ на итальянском. Благодаря мультимодальности Microsoft (совместно с OpenAI) «сделает модели всеобъемлющими», отметил Браун. Если GPT-3.5 позволяет пользователям взаимодействовать посредством ввода текста, то GPT-4 с мультимодальными возможностями, в идеале может обеспечить возможность взаимодействовать в нескольких режимах, включая текст, изображения и звуки."
https://3dnews.ru/1083235/gpt-4-launch
3DNews - Daily Digital Digest
На следующей неделе выйдет GPT-4 — ИИ-модель с которой можно будет общаться текстом, картинками и видео
На следующей неделе OpenAI совместно с Microsoft представит большую языковую модель (LLM) нового поколения GPT-4 (Generative Pre-trained Transformer 4).
#shap #explainability #ml
Шок-контент, либа SHAP, оказывается, не поддерживается уже несколько лет. Может, автор умер, или просто забил, не знаю. А я-то думаю, чего она такая медленная, ужасный код, а тут ещё вчера выяснилось, что ошибки, всплывавшие ещё пару лет тому, до сих пор не исправлены, и issues висят открытые. Так что лучше полагайтесь на другие реализации, если найдёте. Вроде в Rapids/CuML что-то есть.
Шок-контент, либа SHAP, оказывается, не поддерживается уже несколько лет. Может, автор умер, или просто забил, не знаю. А я-то думаю, чего она такая медленная, ужасный код, а тут ещё вчера выяснилось, что ошибки, всплывавшие ещё пару лет тому, до сих пор не исправлены, и issues висят открытые. Так что лучше полагайтесь на другие реализации, если найдёте. Вроде в Rapids/CuML что-то есть.
Вы моделируете для клуба угловые в футболе. Разбили пространство у ворот на несколько зон, крутите стату. Из зон A и Б с углового атаковали по 1000 раз, забили 3.7% и 5.8%.
Anonymous Poll
0%
Я посоветую тренеру все угловые направлять в зону А, объясню почему в комментах
33%
Я посоветую тренеру все угловые направлять в зону Б, т.к. оттуда выше процент реализации
67%
Мне пока неясно, куда лучше напрвлять угловые, объясню почему в комментах
Forwarded from New Yorko Times (Yury Kashnitsky)
Командный пет-проект – шикарный опыт
#career #petproject
Зная, что конверсия из поста про MLOps-курс https://t.me/new_yorko_times/96 в упомянутую там статью на Хабре – около 1%, опишу выводы из той же статьи чуть подробнее. Будет полезно всем, кто хочет командой попилить проект, будь то любой пет (как с chatGPT так и без) или командный проект в рамках скоро стартующего курса по MLOps.
- Поработать в команде над интересным проектом – очень крутой опыт, он и сам по себе полезен, и “продавать” его тоже можно на собеседованиях. Это может сравниться с командной зарубой в Kaggle соревновании – тут можно многому научиться, как работе с GitHub, так и навыкам планирования
- Очень важно иметь дедлайн, скажем, конец соревнования на Kaggle или окончание курса. Иначе мотивация бодро фигачить начинает падать
- Оптимальный размер команды – от 3 до 5 человек. Недаром и на Kaggle к этому пришли. Сверх этого – уже есть риск нанять балласт вместо паравоза
- Хорошо бы довести пет-проект до красивой демки, на которую можно и в резюме сослаться и в любой ситуации хоть в лифте показать. Вот наша http://cryptobarometer.org - барометр, показывающий тональность новостей о крипте
- Немного “галеры” привнести в душевный пет-проект не помешает: если обозначить цели (можно в формате OKR) и настроить базовые Scrum-ритуалы, будет более четкое понимание, кто что делает и куда команда движется. Но надо аккуратно, все же пет-проджект – это больше про веселье и полет фантазии
- Здорово в начале сотрудничества побрейнстормить: собраться и накидать идей, обсудить и приоретизировать (сервисы типа https://easyretro.io хорошо для этого подходят)
- Очень помогает делать мини-демки внутри команды. Даже если встречаться всего на час в неделю, имеет смысл начать с 20-минутной демки кого-то из участников (например, продемонстрировать продвижения с фронтендом или сервисом LabelStudio), а потом уже обычный стендап с обсуждением текущих задач.
- Мне помогло разделение активности на треки – инженерный и исследовательский. Первый – про API, докеры и куберы, второй – про прикладной рисеч а-ля active learning, помогают ли аугментации данных и т.д. В целом как Delivery vs. Discovery в корпорациях
- Также помогло четко расписать роли в команде, у нас это был один ML-инженер, два Data Scientist-a/аналитика/ML-исследователя, один Data Engineer и тимлид
- Неочевидным, но, как кажется, верным решением было подождать, пока кто-то один (тимлид, конечно) накидает прототип решения, с мок-версиями всех компонентов (например, базовый круалер и tf-idf вместо берта) и прописанным в коде взаимодействием компонентов. Имея такой прототип, можно было уже намного эффективнее распараллелить задачи по совершенствованию каждого компонента (иначе – затыки а-ля краулер готов, а база еще нет, active learning вроде готов, но неоткуда разметку брать и т.д.).
#career #petproject
Зная, что конверсия из поста про MLOps-курс https://t.me/new_yorko_times/96 в упомянутую там статью на Хабре – около 1%, опишу выводы из той же статьи чуть подробнее. Будет полезно всем, кто хочет командой попилить проект, будь то любой пет (как с chatGPT так и без) или командный проект в рамках скоро стартующего курса по MLOps.
- Поработать в команде над интересным проектом – очень крутой опыт, он и сам по себе полезен, и “продавать” его тоже можно на собеседованиях. Это может сравниться с командной зарубой в Kaggle соревновании – тут можно многому научиться, как работе с GitHub, так и навыкам планирования
- Очень важно иметь дедлайн, скажем, конец соревнования на Kaggle или окончание курса. Иначе мотивация бодро фигачить начинает падать
- Оптимальный размер команды – от 3 до 5 человек. Недаром и на Kaggle к этому пришли. Сверх этого – уже есть риск нанять балласт вместо паравоза
- Хорошо бы довести пет-проект до красивой демки, на которую можно и в резюме сослаться и в любой ситуации хоть в лифте показать. Вот наша http://cryptobarometer.org - барометр, показывающий тональность новостей о крипте
- Немного “галеры” привнести в душевный пет-проект не помешает: если обозначить цели (можно в формате OKR) и настроить базовые Scrum-ритуалы, будет более четкое понимание, кто что делает и куда команда движется. Но надо аккуратно, все же пет-проджект – это больше про веселье и полет фантазии
- Здорово в начале сотрудничества побрейнстормить: собраться и накидать идей, обсудить и приоретизировать (сервисы типа https://easyretro.io хорошо для этого подходят)
- Очень помогает делать мини-демки внутри команды. Даже если встречаться всего на час в неделю, имеет смысл начать с 20-минутной демки кого-то из участников (например, продемонстрировать продвижения с фронтендом или сервисом LabelStudio), а потом уже обычный стендап с обсуждением текущих задач.
- Мне помогло разделение активности на треки – инженерный и исследовательский. Первый – про API, докеры и куберы, второй – про прикладной рисеч а-ля active learning, помогают ли аугментации данных и т.д. В целом как Delivery vs. Discovery в корпорациях
- Также помогло четко расписать роли в команде, у нас это был один ML-инженер, два Data Scientist-a/аналитика/ML-исследователя, один Data Engineer и тимлид
- Неочевидным, но, как кажется, верным решением было подождать, пока кто-то один (тимлид, конечно) накидает прототип решения, с мок-версиями всех компонентов (например, базовый круалер и tf-idf вместо берта) и прописанным в коде взаимодействием компонентов. Имея такой прототип, можно было уже намного эффективнее распараллелить задачи по совершенствованию каждого компонента (иначе – затыки а-ля краулер готов, а база еще нет, active learning вроде готов, но неоткуда разметку брать и т.д.).
Forwarded from Техножрица 👩💻👩🏫👩🔧
Решила поностальгировать над первым учебным пособием по нейросетям, которое я читала. Книжка вышла в 2007 году, а я ходила на спецкурс, который вели по ней то ли в 2014, то ли в 2015 году. В то время это был единственный курс по нейросетям на мехмате (to the best of my knowledge), и читал его сам автор книжки - пожилой уже профессор Голубев. К сожалению, я не нашла полной версии данного учебного материала в интернете, но вот сокращенная версия, которая дает почувствовать стиль изложения: https://www.mathnet.ru/links/0d06f1ed4abeaf72dccbe0fcd18cec74/fpm915.pdf .
Легко видеть, что такое изложение воспринимается намного труднее, чем современные учебные материалы по тем же темам. Также оно содержит много причудливых названий, которые не используются сейчас. И хотя сам профессор был доброжелательным, отвечал на все вопросы и старался, чтобы спецкурс был интересным, воспринимать его все равно было немного трудновато - даже на последнем курсе мехмата.
Тем не менее, именно оттуда я узнала про основы нейросетевых методов - как устроена полносвязная сеть, что такое градиентный спуск, обратное распространение ошибки...
Хорошо, что сейчас все то же самое научились излагать намного доступнее, понаделали хороших фреймворков (в те времена я знала только три варианта: Theano, Sklearn или "сделай сама" - например, в матлаб; Tensorflow, если и существовал, то в совершенно неиграбельном состоянии, а PyTorch ещё и не пахло), и теперь не только старшекурсники мехмата, но и люди с намного меньшим математическим бэкграундом (даже некоторые старшеклассники!) могут заниматься данной областью.
Ну а книжка, конечно, хоть к настоящему моменту и устарела (начинающим, конечно, я уже порекомендую начинать с более современных материалов), но я её все равно с любовью украсила наклейками и храню как память.
#учебные_материалы #учеба_на_мехмате
Легко видеть, что такое изложение воспринимается намного труднее, чем современные учебные материалы по тем же темам. Также оно содержит много причудливых названий, которые не используются сейчас. И хотя сам профессор был доброжелательным, отвечал на все вопросы и старался, чтобы спецкурс был интересным, воспринимать его все равно было немного трудновато - даже на последнем курсе мехмата.
Тем не менее, именно оттуда я узнала про основы нейросетевых методов - как устроена полносвязная сеть, что такое градиентный спуск, обратное распространение ошибки...
Хорошо, что сейчас все то же самое научились излагать намного доступнее, понаделали хороших фреймворков (в те времена я знала только три варианта: Theano, Sklearn или "сделай сама" - например, в матлаб; Tensorflow, если и существовал, то в совершенно неиграбельном состоянии, а PyTorch ещё и не пахло), и теперь не только старшекурсники мехмата, но и люди с намного меньшим математическим бэкграундом (даже некоторые старшеклассники!) могут заниматься данной областью.
Ну а книжка, конечно, хоть к настоящему моменту и устарела (начинающим, конечно, я уже порекомендую начинать с более современных материалов), но я её все равно с любовью украсила наклейками и храню как память.
#учебные_материалы #учеба_на_мехмате