Вместо подготовки к сессии ребята из вышки и других вузов в субботу (!) пришли на ML-тренировку Kaggle, которую ведёт самый солнечный и открытый DS которого я знаю — тим лид МТС Аналитики Саша Киреев.

Прошел год как мы с ВШЭ запустили эту активность, и тренировки вели , кроме Саши, еще 2 GM и 3 мастера , участники уже завоевывали и бронзу и серебро (!) в соревнованиях.

Так что велком — будем рады вас видеть , анонсы публикуем здесь https://t.iss.one/+RWc7IMQxR5djZmNi

#кейсы

Часто в компаниях функции Data Science и управление данными разделены.
К чему это приводит? DS вынуждены либо обосновывать и “заказывать” поставки, либо смириться и работать с тем, что есть (а про это мы поговорили в посте с пандой).

По поводу заказывать – самая драматичная история у меня была когда я полгода связывал бухгалтерские полупроводки в реплике одной большой системы – ибо в одной крупной компании коллеги, которые отвечали за репликацию данных, решили что связочная таблица не “бизнес-значима” и вычеркнули ее из заявки на поставку 3000+ таблиц той системы (видимо сэкономив оч много денег 🤡), скромно об этом никому не сказав. Самое печальное в этой истории, что больше трех лет ушло чтобы донести канальям-манагерам зачем нужна связочная таблица, а потом еще два года, чтобы она попала в очередь на поставку.

Второй подход, часто встречающийся в российских компаниях – (ceo)vp-feature-engineering. Классическое “жираф большой, ему видней” на каких фичах DS-ам модели строить 🤡. Приводит к тем самым каунтам в широких витринах, часто еще в каком-нибудь гениальном разрезе – типа числа продаж ватных палочек в штуках помесячно в ЦФО.

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

#кейсы #ML
Хотел рассказать вам о кейсе когда я очень долго смотрел в одну точку, а Senior, который перепутал последовательность фичей модели на инференсе (все мы бунтовали против пандаса и старались стать поближе к нампаю), думал в этот момент стоит или нет вызывать мне психиатричку.
Но поделившись этой историей с парой приятелей-ds выяснил, что и у них такое бывало.

итак, 58/42 в пользу людей против роботов ) что ж, придется несколько постов с ошибками чуть посложнее сделать )

Раз уж зашла речь об экономии. Экономить память -- хорошо, экономить на спичках -- плохо. Один молодой DS ставил модель в пром и искренне пытался экономить. Одна из фичей у него была -- размер баннера, и он для нее выбрал тип

np.uint8

Как думаете, что произошло с баннером высотой 400 пикселов? 🙈
Кстати

np.uint8(400)

может кинуть ворнинг, а может и нет, а вот

np.array(400).astype(np.uint8)

точно отработает.
PS: с мидлами такие оказии тоже бывают, а заметить такую ошибку со стороны непросто.

#кейсы

Печально, когда среды разработки и прода различаются, в таком случае когда есть тест-среда, аналогичная проду, становится хотя бы можно поймать ошибку. Тестировал я как-то свою модель разметки транзакций по классам, обычный xgboost, запускаю в spark.

На 1 млрд размеченных транзакций 16 млн (1,6%) расхождений со средой разработки. Версии спарков вроде не отличаются, версии питонячьих библиотек нет, да и парсель вроде одинаковый. Имеет длиииинное название со сложной версией в конце вроде /opt/cloudera/parcels/………/spark_2.3_prod_a_v9.
В итоге достаточно оказалось сделать

ls -al

чтобы увидеть что spark_2.3_prod_a_v9 это симлинка, которая на одной среде ведет на spark_2.3_prod_a_v9_p02, а на второй на spark_2.3_prod_a_v9_p13. Очень хотелось кричать 😱

Указание спарку вместо симлинки хардового пути оказалось спасением.
Но, как выяснилось позже, весьма обманчивым – перезапустив модель на 15 млрд транзакций оказалось около полумиллиона расхождений!

В препроцессинге применялись регулярки, хранившиеся в словарях, а кто сказал что по ним можно итерироваться?! Последовательное применение регулярок если порядок не гарантируется – не гарантирует стабильный результат, и этому учат на первом уроке по python.
Чудес в ml не бывает.
Хотя вру, и об этом будет следующая история, которую прислал подписчик. Кстати, если знаете релевантные истории — велком! Авторство ваше конечно же укажу

В четверг проводим вебинар перед запуском курса ML в бизнесе. В курсе разбираем с Виктором топ 7 задач по экономическому эффекту от ML для бизнеса

#кейсы #ML

История от подписчика @oneiros396:

Хочу поделиться с тобой интересной историей. Ошибка при сборке датасета привела к счастливому исходу (первое место в соревновании)
https://www.kaggle.com/competitions/womens-machine-learning-competition-2018/discussion/53597
Возможно, история немного украсит один из постов в твоём канале
Ошибки при работе с данными, сборке пространства признаков почти всегда приводят к негативным последствиям.

В истории Data Science встречаются lukky errors. Надеюсь, ошибка, которую вы совершите, будет иметь такие же последствия

Суть: парень взял первое место на соревновании Google Cloud & NCAA® ML Competition 2018-Women's сделав сразу две ошибки:
— Сабмит готовил моделью, которую тренил на аналогичном соревновании мужчин — просто перепутал
— Забыл в трейн включить файл с 2017ым годом

Могу пожелать только чтобы в наступающем году ошибки шли вам только на пользу!

Все-таки есть своя прелесть в том чтобы исследовать где модель ошибается, в регрессии так вообще, анализ регрессионных остатков – центральная часть моделирования.
Но сегодня поговорим про LLM.

Есть масса способов сделать рабочий прототип решения не вникая во внутрянку LLM и их тюнинга – можно использовать API Open AI (экстремально дешево) или API Hugging Face (вообще бесплатно, но надо будет выбрать модель).

Но что если вы обычный аналитик, а заказчик требует “вчера” сделать прототип на развернутой локально опенсорсной модели? С чего начать и как выбрать модель для прототипа? Чего стоит опасаться и на какие ошибки обратить внимание?

А если вы обычный менеджер по продажам и эта задача внезапно упала на вас?
Да-да, сейчас бизнес избегает сразу звать MLE за 100500 денег, которые будут час рассказывать о LLM arena, MERA и прочих бенчмарках в генерации и связанных задачах, но из слов которых не получить быстрого ответа – поможет ли LLM в моем конкретном кейсе?

Дима @frolovdmn – DS из нашей команды, подготовил небольшой туториал на эту тему на примере простой но более чем реальной задачи. Туториал оказался весьма популярен, не могу не поделиться с вами.

#кейсы #ML

Раз уж зашла речь про хотелки манагеров.
Однажды (году примерно в 20м) с нашей подачи (а мы с Андреем @andtm тогда развивали эту тему) два больших босса договорились пропилотировать QA (вопросно-ответную систему) по базе знаний клиентской службы. Чтобы когда клиент звонит в колл-центр, оператор не ходил искал вручную по > 20 000 архивных и действующих регламентов в PDF (хоть и связанных между собой ссылками), а сразу на свой запрос получал фактоидый ответ.

Это сейчас школьники в 9м классе RAGи крутят, а тогда казалось (и не только нам), что строить онтологии, наполнять и эмбеддить Knowledge Graphs – более осязаемый путь к reading comprehension. Для тех, кому интересно – статья Михаила Галкина (самый известный русскоязычный эксперт в области) с ICLR’24 .

Но сейчас не об этом. Комедия в двух актах
Акт 1
Приходим к подчиненным биг босса.
Мы: давайте пилот делать!
Коллеги: А у нас ресурсов нет ваши модели крутить, а данные секретные и наружу не отдадим – идите гуляйте!
Акт 2
Нашли сервера (правда, лютый оверкилл).
Мы: нашли два голых сервера – вот их ID. Забирайте, ставьте любую ось, видюхи там есть, мы сами все настроим, главное в свой контур включите.
CTO того бизнес-юнита: не-не-не, вы же не обеспечите утилизацию 90+ процентов!! А у меня на этот год в каждом квартале ППР (KPI) на нее! Не-не-не, катитесь со своими серверами.
Занавес, аплодисменты.

Чудесно, когда бизнес и их ИТ в разных вертикалях?
Да и функциональное управление – когда KPI сотрудника поделены между разными манагерами – не отстает.
Мы – команда! Правда же?

AI engineer -- это что-то новенькое 😁