#кейсы

Часто в компаниях функции 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 -- это что-то новенькое 😁

Middle AI Engineer (NLP)
от 4 000 $/месяц
Удаленка, Фултайм

Компания Americor ищет Applied AI Engineer для развития системы автоматизации общения пользователей с компанией. Мы стремимся покрыть различные каналы связи, включая чат и звонки, с целью улучшения взаимодействия с пользователями на всех этапах…(читать далее)

#кейсы #ML

Про внедрения на железки заказчика в закрытые контура.
Знаете, в чем одно из преимуществ линейных моделей?
В том что их внедрить можно хоть формулой в запросе!
Вроде

select 0.1234 * feature1 + 0.5678 * feature2 + 0.2 * feature3_woe as score

и такой логрег вполне себе месяцев 9 крутился пока вокруг настраивали интеграции и готовили инфру для витрин и инференса моделей посложнее.
Итого: затраты на MLOps: 0, мониторинг: отсутствует, контроль версий: отсутствует, метаинформация: не хранится, код обучения и треки экспериментов: с моделью не связаны. В общем жить с тысячей таких моделей врагу не пожелаешь, а внедриться разово, пока идет бюрократический процесс -- вполне.

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

#корпжиза

Про KPI
Под одним из недавних прошлых постов был комментарий

а ак-то подетальнее можно про kpi сотрудника между манагерами? и вообще про правильную и неправильную декомпозицию целей, задач и kpi.

В один пост ответ не умещу, давайте начнем с самих KPI, а в следующем посте будет про цели и декомпозицию
Так как цель любого KPI – замотивировать сотрудника двигаться в нужном менеджменту направлении, то и смотреть на KPI стоит глазами мотивируемых.

Как вообще KPI влияют на жизнь сотрудника? здесь возможны варианты:
• Невыполнение KPI ведет к увольнению, перевыполнение – к баллам, которые как материализовать собственник еще не придумал (одна малазийская компания с русскими корнями, известная единовременным массовым увольнением через видеозвонок по наводке якобы “модели”)
• KPI влияет на годовой бонус, составляющий 50+ процентов годового дохода (да, в декабре приходит денег больше чем за 11 предыдущих месяцев в сумме). Скажем, если у вас три KPI с равным весом, то невыполнение одного из них будет эквивалентно потере 16.7% годового дохода – то есть два месяца в году вы поработали забесплатно. (один очень крупный банк когда-то)
• KPI влияет на полугодовой бонус, который составляет около 6% годового дохода, если не выполнить – потеряете менее 2% годового дохода
• KPI нет, как и безопасных уровней, идет соревнование – кто наберет больше продаж, баллов за проекты, etc. 10% худших увольняем, 10% лучших оставляем (небольшие компании где до власти дорвались HR, начитавшиеся псевдоманагерской макулатуры).
• У сотрудника три типа KPI – один от проектного руководителя (бладельца бюджета, который нанимает / увольняет / повышает), KPI от компании (на который сотрудник не влияет), KPI от функционального руководителя (свадебный генерал с совещательным голосом).
• KPI есть только у манагеров, а уж как они замотивируют сотрудников – их забота.
наверное, вариантов сильно больше, но степень ожесточенности или пофигизма в достижении KPI прослеживается, верно?

Лично я не ставлю сотрудникам KPI совсем (даже когда на мне стоят финансовые):
• Не хочу чтобы работа свелась к формальному закрытию KPI, да и нет KPI, который невозможно хакнуть
• Что-то может пойти не так, может влететь горячая задача с самого верха – и сотрудник будет перед выбором: либо подвести меня, либо пожертвовать своим доходом
• Мы обсуждаем направление движения, приоритеты задач, их влияние и зависимости друг от друга, влияние на компетенции команды и возможности, которые открывают реализованные проекты (а мы часто строим новые на результатах сделанных)
• KPI, как это ни странно звучит, не увеличивает ответственность сотрудника, а уменьшает (ему не надо думать о смежных вещах, думать за пользователя, за бизнес и тд)
• Меньше ответственность -> меньше инициативы и самостоятельности -> меньше вовлеченности -> хуже результат вдолгую

to be continued…

#кейсы #ML

Раз уж пошло про KPI – вот безобидный прием против вредного манагера. Прием для настоящих каналий!

Если вразумлять и просвещать манагера на метрики регресии, распределения остатков и прочее сил уж больше нет, то могу предположить что каналья-манагер не знает разницу между MAPE и MDAPE (и наверняка про MASE, eB, варианты SMAPE, WAPE и тд).

Так что ничего не стоит вам выдать MDAPE за MAPE (и только если спросят – сказать что M это, совершенно очевидно, медиана, разве можно было предположить иначе?!).
В примере ниже мы не будем оптимизировать MAPE напрямую (хотя это не то чтобы сложно – один из методов – взвесить наблюдения на таргет), а просто посмотрите выигрыш (не повторяйте это дома!!!):

import numpy as np
from sklearn.datasets import make_regression
from sklearn.model_selection import train_test_split
x, y = make_regression(n_samples=10_000, n_features=10, n_informative=8, noise=5, shuffle=True, random_state=42)
x_train , x_test, y_train, y_test = train_test_split(x, y, test_size = 0.35, random_state = 42)
import xgboost as xgb
regressor=xgb.XGBRegressor(eval_metric='rmse')
regressor.fit(x_train, y_train)
preds = regressor.predict(x_test)
residuals = preds - y_test
r_mape = np.mean(abs(residuals) / abs(y_test))
r_mdape = np.median(abs(residuals) / abs(y_test))
print(f'MAPE {r_mape:.2f}')
print(f'MDAPE {r_mdape:.2f}')
>>> MAPE 3.74
>>> MDAPE 0.16

а вообще, если интересна тема метрик регрессии -- то лучше всего она освещена в неизданной книге Александра Дьконова