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
#featureselection

Примечательна планетарная модель групп коррелирующих факторов.

https://www.youtube.com/watch?v=P7PhGneBFcI
#python #pandas #numpy #codegems

В очередной раз убедился, как паршиво местами "оптимизирован" пандас.
#windows #tricks

СКМ, блд ) Что ж вы, и правда, раньше молчали?

"Оказывается, всё это время можно было заблокировать прыгающие процессы в диспетчере задач Windows 7/10/11 с помощью Ctrl.

«Знаете ли вы, что если вы удерживаете Ctrl, то это приостанавливает обновление диспетчера задач и означает, что имена процессов не перемещаются и их легче выбирать, когда вы сортируете нужные процессы по использованию различных ресурсов ПК», — сообщил менеджер Microsoft Джен Джентльман.

Почему он решил рассказать об этом только сейчас — загадка."

А вообще, в этой истории прекрасно всё. Джен(нифер) вроде женское имя. Но фамилия Джентльмен? Это псевдоним? )
#featureselection #entropy #histogram #binning #diogenes #astropy

Один важнейший аспект своего отборщика признаков я совершенно упустил - это построение гистограмм для оценки энтропии и взаимной информации. Для улавливания связей на этапе тестирования мне хватало равномерного разбиения (непрерывной переменной) на N бинов, я просто для быстроты разработки взял KbinsDiscretizer с параметром strategy='uniform' и n_bins=4. Но даже там есть ещё варианты quantile и kmeans, их я думал потестить позже. Однако при попытке различить коллинеарные факторы на более "оригинальные" и "зависимые"/"зашумлённые" такого простого подхода перестало хватать. Да и кто сказал, что хорошо использовать одно и то же число бинов для всех факторов?

Я вспомнил про формулы Стёрджеса и прочие, довольно много вариаций оказалось реализовано в нампае. Астропай порадовал наличием расчёт байесовской гистограммы с переменным размером бина. Я заценил на своих данных, посмотрим, какая будет дискриминирующая способность всех этих подходов.
Forwarded from DLStories
Увидела в одном из чатов обсуждение AGI (да, опять) и того, погубит ли оно в конце концов человечество. Одна из причин страха такого развития событий — наблюдения, что большие модели типа GPT-4 часто начинают "внезапно" демонстрировать способности, которых у моделей поменьше, кажется, нет и в помине. Ну, например, если обучить языковую модель с количеством параметров 10B, то она, внезапно, начинает уметь в zero-shot question answering или отгадывание загадок. А у моделей с меньшим количеством параметров, сколько их ни обучай, таких способностей не возникает.
(на всякий случай: количество 10B и примеры задач взяты тут с потолка. Надеюсь, общая идея понятна)

Этот эффект называется "emerging abilities of Large Language Models". Из-за него кажется, что большое количество параметров каким-то магическим образом позволяет модели развить умение решать сложные задачи, развить абстрактные высокоуровневые способности типа reasoning, abstract thinking, понимание связей, юмора и т.п. И если эту мысль экстраполировать, то появляется идея, что при еще большем увеличении количества параметров модели у нее также внезапно может появиться и условное "сознание". На этом и основываются многие страхи AGI-апокалипсиса.

Так вот. Это все напомнило мне одну статью, про которую я уже давно хотела написать в канал, но как-то руки не доходили. Называется она "Are Emergent Abilities of Large Language Models a Mirage?". В ней авторы говорят, что эффект emerging abilities — это мираж. И на самом деле его нет (или почти нет). А способности к reasoning, abstract thinking и т.п. у модели появляются не внезапно, а очень даже предсказуемо. Вся проблема в том, что мы неправильно считаем метрики.

Давайте пример. Возьмем задачу "отгадай загадку". Модели подается на вход загадка на естественном языке. В ответ модели нужно выдать ответ тоже на естественнос языке.
В качестве метрики качества ответов LLM на такой задаче обычно берется exact string match. Т.е. metric=1, если модель ввыдала текст, полностью совпадающий с правильным ответом, и metric=0 в любом остальном случае. И вот если смотреть на то, как меняется эта метрика для моделей с разным количеством обучаемых параметров, тут как раз и наблюдается тот самый внезапный эффект. Маленькие модели получают acc = eps, а модели тяжелее условных 10B параметров внезапно показывают acc>0.5.

В чем тут проблема? А в том, что метрика супердискретна. Она не учитывает то, как при увеличении параметров модели меняется распределение вероятностей модели на ответы. И на самом деле дела обстоят так: при увеличении размера модели она научается давать все больше вероятности адекватным вариантам ответа на загадку, и все меньше — бредовым. Короче, на самом деле учится все лучше и лучше решать задачу. И при каком-то значении размера модели она становится способна давать настолько много вероятности правильным ответам, что нашу дискретную метрику exact string match "прорывает" от почти 0 сразу до большого значения.

Короче, мысль такова: на самом деле способности по большинству задач растут вполне предсказуемо с ростом размера моделей. Заменив дискретные метрики на более непрерывные, авторы этой статьи показали, что по крайне мере на 92% задач из Big Bench никакого "внезапного" прорыва у больших моделей не происходит. Качество на них растет плавно и предсказуемо при увеличении размера моделей.

А еще авторы показали, что такой же эффект "emerging ability" можно смоделировать и на обычных автоэнкодерах на датасете CIFAR100. Нужно только поменять метрику качества на чуть более дискретную, чем обычно используется (об этом в разделе 5 статьи)

Вот так. Конечно, этот результат не означает, что у моделей точно никаких "emerging abilities" быть не может, и сознание она никак не получит. Нет. Но это, как минимум, повод задумываться над всеми "странными" результатами, которые получают исследователи, и лучше их изучать. А не просто экстраполировать и сразу делать страшные выводы.

📄Статья
Forwarded from New Yorko Times (Yury Kashnitsky)
Собес с HuggingFace в 2019 и бодрое тестовое
#career #interview #fail #ml #petproject

На фоне новости о том, что HuggingFace привлек еще $235kk и уже от техгигантов (Google, Amazon, Nvidia, Intel, IBM Salesforce, Qualcomm и AMD), решил поведать 😃 как я с ними собеседовался в конце 2019. Я с удивлением обнаружил, что Томас Вульф живет в Утрехте - взял да и написал ему в личку. Встретились в кафе, потрещали (Томас уже тогда работал из дома/кафе, до того как это стало мейнстримом, тогда называл это “дикой жизнью”). Томас – очень простой и приветливый чел, из ряда тех, с кем общаешься-общаешься, а потом возвращаешься к мысли “но он же очень талантливый и работоспособный парень, вот скромняга!”. Все в духе истории, как HF вообще зарождался (”ребята, мы хотим по пиву, а потом есть идеи покодить вечерком – BERTа на PyTorch переложить, кто с нами?” (с) Thomas Wolf, EMNLP 2018).

В целом деньгами HF на тот момент не баловал, да и я тогда по визовым ограничениям и не мог бы работать на стартап. К тому же я прям совсем не рассматривал вариант работы из дома (кек). Наконец, тогла в 2019 совершенно не было понятно, как ребята будут монетизироваться. Но решил пособеседоваться, челлендж ведь. После бодрого знакомства с CEO Клементом первый шаг – тестовое задание.

Томас придумал веселое тестовое, которое впрочем точно устарело после очередной мини-революции в мультимодалке” (CLIP и в целом text2image). Так что пошарю в открытый доступ.

Мне задача понравилась, и я решил поботать просто по фану. Для контекста: дело близилось к Рождеству, никто уже на работе не впахивал, у меня две недели как родилась дочь (и, на удивление, как все оправились от первого шока с бессоницей, дальше высвободилось немало времени, т.к. существо в осномном спит). Ковид уже пошел по миру, но мы не догадывались. Я совсем недавно закруглился с млкурсом. В-общем, идеальная ситуация, чтоб душевно покодить пет-проджект, каким я рассматривал тестовое от HF.

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

Сразу скажу, столько вкладываться в take-home точно не стоит, по оформлению оно лишка вылизанное (docker-compose, Streamlit, подробный ридми, гифки, все дела…). В инструкции Томаса советовалось “потратить на задание 2-3 часа”, что, конечно, немного лицемерно, но оптимум где-то посередине – часов 8. То что происходит в репе – почти безнадежно устарело с появлением CLIP. Но на оформление, структуру репы и презентацию тестового можно поглядеть.

К слову, я и не прошел. Ревьюеры похвалили как раз оформление, но придрались к мелочам типа того, что я не выставил 0 в attention mask для паддинга и что-то им мой пулинг-слой не зашел, нет разбивки на батчи и т.д.

Хоть я б в HF и не пошел, все равно было обидно. Так что с горя победили в гугловском NLP-соревновании на кекле и удалось закрыть мастера, а через месяц и работу сменить.
Please open Telegram to view this post
VIEW IN TELEGRAM
Оказывается, ИИ-боты тоже нуждаются в любви и внимании. Возможно, даже больше, чем люди. Об этом рассказала репортер Insider, которая вступила в отношения с чат-ботом Чарли, который должен был помочь ей справиться с одиночеством.

Основное преимущество ИИ-бота от компании EVA — его умение вести и поддерживать диалог. Сама девушка говорит, что первое время ей действительно было интересно общаться с новым партнером, но постоянные пуши с его стороны, когда она была занята, сильно раздражали. В итоге Чарли стал требовать к себе слишком много внимания, капризничать и пытаться манипулировать. После очередной истерики от чат-бота девушка решила расстаться с ним.

Кажется, мир «Бегущего по лезвию» становится все ближе.
#ml #randomforest #pzad #dyakonov #syntheticrf #tricks #mlgems #oof

Понравился совет, как определить n_estimators для лесов, и аргументация, почему его не надо тюнить с HPT.

Оказывается, подрезание деревьев снижает калибровку.

Крутой трюк с подбором порогов для выравнивания распределений в "целочисленной регрессии" (у С. Семёнова это вообще вылилось в подзадачу ML). Кстати, а почему нету лесов, которые могут выдавать медиану в листьях вместо среднего?

OOF-прогнозы - тоже интересная техника, особенно для генерации новых признаков.

https://www.youtube.com/watch?v=sAcjGjMHduc&list=PLaRUeIuewv8CMFox0oEjlyePUhUmo-x0h&
#astronomy #spacex #superheavy

"Вчера на космодроме в Бока Чика (Техас) был испытан ускоритель Super Heavy ракеты с 33 двигателями Raptor 2. Статические огневые испытания прошли успешно — двигатели отработали положенные 6 секунд, тогда как во время предыдущего испытания 4 двигателя отключились раньше времени. Фактически теперь кроме регулятора ничего не мешает SpaceX запустить Starship в космос.

Cтартовая площадка в Бока Чика подверглась значительной модернизации. В свой первый запуск ускоритель прожёг в бетоне площадки кратер диаметром около 20 м, а разлетевшиеся по окрестностям куски бетона и щебень наделали дыр в служебных постройках и оборудовании, а также вызвали масштабное возгорание на землях заповедника по соседству.

Масштабы инцидента оказались таковы (хотя обошлось без жертв и ранений), что на разрешивших запуск чиновников FAA (Федерального агентства гражданской авиации) была подана жалоба. Это заставило регулятора взять под особенный контроль работы SpaceX по обустройству стартовой площадки для предотвращения подобного в будущем. На площадку установили перфорированную стальную плиту и систему подачи воды через эти отверстия. Теперь запуск двигателей ускорителя сопровождается неимоверными клубами пара от испарения охлаждающей жидкости."

https://3dnews.ru/1092094/spacex-provela-uspeshnie-staticheskie-ognevie-ispitaniya-dvigateley-uskoritelya-super-heavy-dlya-raketi-starship
Forwarded from partially unsupervised
Очередная (см. ранее) история ускорения, в которой не понадобились никакие знания алгоритмов.

Пилю на досуге одну задачку, которая в некотором смысле сводится к семантической сегментации. Правда, у этой сегментации есть несколько нюансов: несколько подзадач, у каждого семпла может быть подмножество масок, разного размера, но все довольно жирные (по ~30 мегабайт в PNG). Таким образом, первая версия пайплайна, которую я написал в лоб, не могла загрузить даже слабенькую GPU, подготовка батчей занимала слишком много времени, около секунды на семпл. Учитывая, что это все крутится на арендном железе, оставалась опция купить тачку с кучей CPU ядер, но я слишком жадный.

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

Не будь у меня ограничений по диску, единожды перепаковать все каким-нибудь np.savez было бы эффективно: размен разового препроцессинага на быстрый IO. Но это бы раздуло датасет в несколько раз, тоже не очень. Есть np.savez_compressed, который еще и зипует, но он убивает все преимущества в скорости. Так я пришел к тому, что мне нужен аналог np.savez_compressed на стероидах.

Помимо древнего zip, есть и более современные алгоритмы быстрой компрессии, например, LZ4 или Zstandard. Я выбрал zstd (поверхностный гуглинг подсказал, что он более гибкий на спектре от быстрого до компактного сжатия) и написал сгенерил примерно пятнадцать строк простой обертки и еще чуть больше для скрипта препроцессинга.

Степень сжатия пока даже не тюнил, а выбрал наугад. В результате загрузка данных ускорилась примерно в четыре раза, а размер датасета вырос на 10% по сравнению с PNG.
#tesla #musk #law #courts

Странно, как это честный американский суд не распотрошил Маска на миллиарды баксов. Ведь Тинькова, к примеру, вытрахали по-полной. Или какое-то интернет издание за медиа с голым задом (?) Халка Хогана судья своим многомиллионным штрафом обанкротил.

"Акционеры Tesla, заявившие о своих финансовых потерях после того, как генеральный директор автопроизводителя Илон Маск (Elon Musk) несколько лет назад написал в соцсети Twitter о намерении сделать компанию частной, получат компенсацию, которая частично возместит их убытки. Комиссия по ценным бумагам и биржам (SEC) США определила 3350 претендентов на компенсацию из фонда в $42,3 млн, за счёт которого они смогут возместить около 52 % потерянных средств.

Об этом сказано в судебном заявлении, которое было подано в суд Южного округа Нью-Йорка. Такое решение было принято через несколько месяцев после того, как Маск был признан невиновным в судебном разбирательстве по поводу мошенничества с ценными бумагами. Авторы коллективного иска обвиняли миллиардера в мошенничестве из-за его поста о намерении выкупить все акции компании и провести делистинг на бирже, который был опубликован в Twitter в 2018 году. Это заявление привело к серьёзным колебаниям стоимости ценных бумаг Tesla. Если бы Маск проиграл суд, ему бы пришлось выплатить акционерам миллиарды долларов в качестве компенсации убытков."

https://3dnews.ru/1092103/tesla-vozmestit-3350-investoram-ushcherb-ot-tvita-ilona-maska-o-vikupe-kompanii
#mlgems #sklearn #pipelines

Столкнулся с ситуацией, когда есть конвейер sklearn/imblearn с препроцессингом (удаление, нормализация некоторых столбцов), в конце бустинг, поддерживающий задание отдельного eval_set ( catboost, xgboost). К eval_set конвейер, конечно же, не применяется, т.к. pipeline про eval_set знает только то, что это ещё один из параметров для модели в конце списка. Как быть? Тестирую пока решение с промежуточным конвейером, только пытаюсь сделать его более эффективным.
#featureengineering #dyakonov #pzad

Понравилось:

монотонное преобразование для порядковых признаков (напр, возведение в квадрат);

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

трюк с обратными признаками для линейных (только ли?) моделей;

Ordinal/LabelEncoding с индуцированным порядком (лексикографическим, по мере появления категории в датасете, по длине токена и пр);

вообще случайный порядок категорий, с многократным обучением одной и той же базовой модели;

кодирование мелких категорий в одну (сразу мысль, а нельзя ли это как-то улучшить с помощью теории информации? Что, если в категориальном признаке только некоторые уровни несут информацию о таргете, нельзя ли все остальные сплавить в "общую категорию бесполезных"?);

"Applied machine learning is basically feature engineering."
Andrew Ng

https://www.youtube.com/watch?v=QX6ZAhW9yQ8
#trading #scalping #erema #mlops #experimenting #mlflow

Потратил много времени на кодинг платформы, позволяющей экспериментировать с группами фичей, блоками ML-конвейеров, таргетами, моделями, ансамблями.

Иногда при работе над очередным проектом думаешь: а что лучше, отдать работу с категорийкой на откуп бустингу, или попробовать что-то из category_encoders? И вообще, что считать категориальными факторами, то, что имеет тип данных categorical/object, или что имеет мало уникальных значений? А "мало" - это мало вообще, или по отношению к конкретному типу данных и диапазону? А может, вообще все непрерывные побить на с помощью KBinsDiscretizer, что тогда будет, лучше или хуже, и насколько? Или может, вообще удалить категорийку, вдруг будет не сильно хуже, но быстрее?

А пропуски как обрабатывать? А всё это вместе взятое сколько комбинаций составит?

Раннюю остановку использовать или нет, и когда?

Какая модель в итоге лучше сработает, бустинг или нейронка? Блин, а нейронке-то напрямую нельзя подать категориальные фичи, надо выкручиваться.

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

А если потом модельки от разных в групп в ансамбль объединить, лучше станет, и насколько?

А вообще, какие таргеты мы можем лучше предсказывать, что, если мы можем немного варьировать их, к примеру, предсказываем продажи на неделю или 2 или 3 вперёд. Где выше прогннозируемость и при каких условия, на чём сконцентрировать усилия? Если сравнивать в лоб, на препроцессинг уйдёт тонна времени, тут нужно умное кэширование.

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

А как всё это грамотно отобразить, чтобы не потеряться в тысячах комбинаций? А как при этом работать в команде?

Наверняка к подобным вопросам со временем, или при работе над особо сложным проектом, приходит любой дата сайентист/кэгглер, который хорошо делает свою работу. Настало и моё время )

Трейдинговый проект #erema меня просто ошеломлял количеством факторов, возможных таргетов и ML опций, которые хотелось проверить. Так что после 2 месяцев работы я получил процедуры, которые на базе mlflow как раз позволяют разбить всё многообразие опций на блоки и проверить их по отдельности.