Aspiring Data Science – Telegram
Aspiring Data Science
385 subscribers
465 photos
12 videos
12 files
2.15K links
Заметки экономиста о программировании, прогнозировании и принятии решений, научном методе познания.
Контакт: @fingoldo

I call myself a data scientist because I know just enough math, economics & programming to be dangerous.
Download Telegram
ANNs timeline
1
Нашла отличное руководство о том, как избежать распространенных ошибок при обработке данных, оценке и сравнении ml моделей:

https://arxiv.org/abs/2108.02497

Написано, что гайд предназначен для исследователей, но на самом деле он выглядит полезным и для практиков.

Мне особенно понравилось то, что здесь разобрано много неочевидных сценариев того, как информация из тестового множества может протечь в тренировочное. Из всего перечисленного новым для меня был сценарий протекания информации через мозг того, кто делает модель (см. совет 2.2).
А совет 3.7 я бы ещё обобщила следующим образом: если в пайплайне используется более одной обучаемой сущности - например, если на данных сначала обучается одна модель, а потом фичи из ее латентного пространства либо её выход используются в другой, нужно следить за тем, чтобы ни одна обучаемая сущность в пайплайне не имела доступа к тестовым данным ни в каком виде (для мозга инженера придется ослабить это требование: ему всё-таки может потребоваться проверить, что данные в тесте выглядят адекватно, хотя лучше избежать соблазна слишком сильно в них всматриваться - см. п.2.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
👍21
#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
#shap #explainability #ml

Шок-контент, либа SHAP, оказывается, не поддерживается уже несколько лет. Может, автор умер, или просто забил, не знаю. А я-то думаю, чего она такая медленная, ужасный код, а тут ещё вчера выяснилось, что ошибки, всплывавшие ещё пару лет тому, до сих пор не исправлены, и issues висят открытые. Так что лучше полагайтесь на другие реализации, если найдёте. Вроде в Rapids/CuML что-то есть.
👍3😢1😨1
Вы моделируете для клуба угловые в футболе. Разбили пространство у ворот на несколько зон, крутите стату. Из зон A и Б с углового атаковали по 1000 раз, забили 3.7% и 5.8%.
Anonymous Poll
0%
Я посоветую тренеру все угловые направлять в зону А, объясню почему в комментах
33%
Я посоветую тренеру все угловые направлять в зону Б, т.к. оттуда выше процент реализации
67%
Мне пока неясно, куда лучше напрвлять угловые, объясню почему в комментах
Forwarded from New Yorko Times (Yury Kashnitsky)
Командный пет-проект шикарный опыт
#career #petproject

Зная, что конверсия из поста про MLOps-курс https://news.1rj.ru/str/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 вроде готов, но неоткуда разметку брать и т.д.).
Решила поностальгировать над первым учебным пособием по нейросетям, которое я читала. Книжка вышла в 2007 году, а я ходила на спецкурс, который вели по ней то ли в 2014, то ли в 2015 году. В то время это был единственный курс по нейросетям на мехмате (to the best of my knowledge), и читал его сам автор книжки - пожилой уже профессор Голубев. К сожалению, я не нашла полной версии данного учебного материала в интернете, но вот сокращенная версия, которая дает почувствовать стиль изложения: https://www.mathnet.ru/links/0d06f1ed4abeaf72dccbe0fcd18cec74/fpm915.pdf .
Легко видеть, что такое изложение воспринимается намного труднее, чем современные учебные материалы по тем же темам. Также оно содержит много причудливых названий, которые не используются сейчас. И хотя сам профессор был доброжелательным, отвечал на все вопросы и старался, чтобы спецкурс был интересным, воспринимать его все равно было немного трудновато - даже на последнем курсе мехмата.
Тем не менее, именно оттуда я узнала про основы нейросетевых методов - как устроена полносвязная сеть, что такое градиентный спуск, обратное распространение ошибки...
Хорошо, что сейчас все то же самое научились излагать намного доступнее, понаделали хороших фреймворков (в те времена я знала только три варианта: Theano, Sklearn или "сделай сама" - например, в матлаб; Tensorflow, если и существовал, то в совершенно неиграбельном состоянии, а PyTorch ещё и не пахло), и теперь не только старшекурсники мехмата, но и люди с намного меньшим математическим бэкграундом (даже некоторые старшеклассники!) могут заниматься данной областью.
Ну а книжка, конечно, хоть к настоящему моменту и устарела (начинающим, конечно, я уже порекомендую начинать с более современных материалов), но я её все равно с любовью украсила наклейками и храню как память.

#учебные_материалы #учеба_на_мехмате
#postgres #rdbms

Выбирают постгре-совместимую СУБД для распределённого хранения данных (на многих серверах), частично они состоят из временных рядов (неизменяемые, append-only) без первичного ключа (типа показаний сенсоров) , частично из записей с меткой времени, но всё же подверженных нечастому изменению, уже с первичным ключом. часть с json, часть нормализованная. Таблицы большие. Рассматриваю TimescaleDB vs Citus. Если есть опыт использования, отпишите впечатления в комменты, плиз.