#кейсы #ML
Сегодня 31 декабря.
Поэтому расскажу кейс о работе 31 декабря много лет назад. Горел флагманский и достаточно сложный и в плане бизнеса и плане инфры (первое внедрение в пром на спарке за историю банка, причем на паре десятков источников и с кучей моделей и модулей) проект.
Всем отделом, вне зависимости от грейда, 31 декабря часов до 11 вечера сидели на работе – все ковыряли данные и пилили модели, причем это ровно тот случай, когда в комнате чувствуешь себя самым тупым. Наш отдел реально знали и уважали ☺️
И вот примерно за что: сидит очень синьорный DS (наверное самый синьорный, которого я встречал вживую) и в реплике источника с ODS (operational data store, а не тот который был слаке) в таблице на 100+ млрд записей нашел 14 😱 записей, которые менялись при перезапуске скрипта сразными параметрами спарка.
Как была устроена реплика: если запись в источнике изменялась / удалялась / добавлялась, то в реплике писалась дата до десятой секунды, и тип операции – ‘I/U/D’. То есть чтобы собрать данные на дату в прошлое (чтобы потом сделать фичи) надо было написать что-то вроде:
Заменив row_number() на rank() он нашел что у одной и той же записи могут быть изменения, которые совпали с точностью до десятой доли секунды! И вот он ковырял пока не нашел незадокументированное поле ods_seq, которое хранило какой-то локальный номер операции. Добавил в сортировку оконной функции и дождался пересчета всех тестов на этой огромной таблице.
14 записей на 100+ млрд! И для него это был как песок в часах – недопустимое расхождение, которое вызывало зуд и зубовный скрежет.
Другой (начальник отдела, кстати) до победного калибровал свою модель. И мы работали полный день и второго января и третьего и так до самой сдачи проекта (только 8 марта случился следующий выходной).
Не столько из-за дедлайна (его мы просрочили месяцев на 5 в итоге), сколько из-за качества – не то чтобы мы боялись не пройти валидацию, нет, нас увлекал сам процесс сделать модели на совесть.
И вот я искренне желаю вам в Новом Году оказаться в таком коллективе, где люди сильнее вас, умнее вас, и увлечены как минимум не меньше вас; на таком проекте где от вашей работы и внимания к деталям зависит действительно очень много, чтобы у вас была здоровая гордость за свою работу!
Моя мечта чтобы быть DS / MLE было не менее почетно чем врачом 👨🔬 или адвокатом 👨⚖️, чтобы мы с вами работали не потому что “продакт - бэклог - фича - жира” 🤮, а потому что делаем важное и очень классное дело, и на этих данных в этой области мы действительно первооткрыватели, нас драйвят файндинги и эффект на бизнес, на конечного пользователя. Нас драйвит изящество и скорость алгоритмов, красивые подходы, решенные задачи.
Новых знаний вам! Новых свершений! С наступающим Новым 2025 годом!
🍾🎄 🥂🔔 ☃️ 🎄 🥳
Сегодня 31 декабря.
Поэтому расскажу кейс о работе 31 декабря много лет назад. Горел флагманский и достаточно сложный и в плане бизнеса и плане инфры (первое внедрение в пром на спарке за историю банка, причем на паре десятков источников и с кучей моделей и модулей) проект.
Всем отделом, вне зависимости от грейда, 31 декабря часов до 11 вечера сидели на работе – все ковыряли данные и пилили модели, причем это ровно тот случай, когда в комнате чувствуешь себя самым тупым. Наш отдел реально знали и уважали ☺️
И вот примерно за что: сидит очень синьорный DS (наверное самый синьорный, которого я встречал вживую) и в реплике источника с ODS (operational data store, а не тот который был слаке) в таблице на 100+ млрд записей нашел 14 😱 записей, которые менялись при перезапуске скрипта сразными параметрами спарка.
Как была устроена реплика: если запись в источнике изменялась / удалялась / добавлялась, то в реплике писалась дата до десятой секунды, и тип операции – ‘I/U/D’. То есть чтобы собрать данные на дату в прошлое (чтобы потом сделать фичи) надо было написать что-то вроде:
select a.*
from
(
select
*
, row_number() over (partition by smth order by ods_dt desc) as rn
from table
where ods_date < our_date
) a
where (a.rn = 1) and (a.ods_type <> ‘D’)
Заменив row_number() на rank() он нашел что у одной и той же записи могут быть изменения, которые совпали с точностью до десятой доли секунды! И вот он ковырял пока не нашел незадокументированное поле ods_seq, которое хранило какой-то локальный номер операции. Добавил в сортировку оконной функции и дождался пересчета всех тестов на этой огромной таблице.
14 записей на 100+ млрд! И для него это был как песок в часах – недопустимое расхождение, которое вызывало зуд и зубовный скрежет.
Другой (начальник отдела, кстати) до победного калибровал свою модель. И мы работали полный день и второго января и третьего и так до самой сдачи проекта (только 8 марта случился следующий выходной).
Не столько из-за дедлайна (его мы просрочили месяцев на 5 в итоге), сколько из-за качества – не то чтобы мы боялись не пройти валидацию, нет, нас увлекал сам процесс сделать модели на совесть.
И вот я искренне желаю вам в Новом Году оказаться в таком коллективе, где люди сильнее вас, умнее вас, и увлечены как минимум не меньше вас; на таком проекте где от вашей работы и внимания к деталям зависит действительно очень много, чтобы у вас была здоровая гордость за свою работу!
Моя мечта чтобы быть DS / MLE было не менее почетно чем врачом 👨🔬 или адвокатом 👨⚖️, чтобы мы с вами работали не потому что “продакт - бэклог - фича - жира” 🤮, а потому что делаем важное и очень классное дело, и на этих данных в этой области мы действительно первооткрыватели, нас драйвят файндинги и эффект на бизнес, на конечного пользователя. Нас драйвит изящество и скорость алгоритмов, красивые подходы, решенные задачи.
Новых знаний вам! Новых свершений! С наступающим Новым 2025 годом!
🍾
Please open Telegram to view this post
VIEW IN TELEGRAM
❤60🎄31🔥6🤡4🤯2👍1🗿1🆒1😎1
В канинкулы постараюсь воздержаться от лонгридов, но мимо забавного пройти не могу.
Все же писали курсовую / диплом / диссер?
Сразу после обоснования задачи идет лит. обзор -- кстати сам по себе часто очень полезная штука (особенно если лекцию студентам прочитать или понять что вообще в этой задаче люди делают).
Survey papers еще и достаточно цитируемы — можно и хирш порастить 🏆.
Так вот, последние пару лет стал замечать, что даже в обзоры вставляют такую картинку, типа методологию 🤓
Мб так и правильнее, но чет смеюсь 😂
Все же писали курсовую / диплом / диссер?
Сразу после обоснования задачи идет лит. обзор -- кстати сам по себе часто очень полезная штука (особенно если лекцию студентам прочитать или понять что вообще в этой задаче люди делают).
Survey papers еще и достаточно цитируемы — можно и хирш порастить 🏆.
Так вот, последние пару лет стал замечать, что даже в обзоры вставляют такую картинку, типа методологию 🤓
Мб так и правильнее, но чет смеюсь 😂
🔥6🤔3😁2
#ML
Не все 31 декабря резали оливьешку и чистили мандаринки.
Фанаты мультиагентных систем из HF выпустили новую библиотеку SmolAgents:
https://huggingface.co/blog/smolagents
https://github.com/huggingface/smolagents
Кто баловался с langraph / langchain помнит что с opensource LLM не ко всем моделям работали bindы
(хотя год назад статья на HF вполне себе обнадеживала https://huggingface.co/blog/open-source-llms-as-agents).
Сейчас же утверждается что SmolAgents будет работать с любой LLM, которая есть на HF.
Когда же еще пробовать как не новогодних каникулах?
Не все 31 декабря резали оливьешку и чистили мандаринки.
Фанаты мультиагентных систем из HF выпустили новую библиотеку SmolAgents:
https://huggingface.co/blog/smolagents
https://github.com/huggingface/smolagents
Кто баловался с langraph / langchain помнит что с opensource LLM не ко всем моделям работали bindы
(хотя год назад статья на HF вполне себе обнадеживала https://huggingface.co/blog/open-source-llms-as-agents).
Сейчас же утверждается что SmolAgents будет работать с любой LLM, которая есть на HF.
Когда же еще пробовать как не новогодних каникулах?
huggingface.co
Introducing smolagents: simple agents that write actions in code.
We’re on a journey to advance and democratize artificial intelligence through open source and open science.
🔥5💯3❤2
Developing-Multi-Agent-Systems-with-JADE.pdf
3.3 MB
#ML
Вот вам просто для сравнения -- как строили MAS в начале 00х, тогда были популярны 2 фреймворка -- MACE и JADE, вот интро по JADE (а статей с ним к тому времени было уже прилично)
Вот вам просто для сравнения -- как строили MAS в начале 00х, тогда были популярны 2 фреймворка -- MACE и JADE, вот интро по JADE (а статей с ним к тому времени было уже прилично)
🔥4
Дата канальи — про «специалистов» в данных / ML / AI
В канинкулы постараюсь воздержаться от лонгридов, но мимо забавного пройти не могу. Все же писали курсовую / диплом / диссер? Сразу после обоснования задачи идет лит. обзор -- кстати сам по себе часто очень полезная штука (особенно если лекцию студентам…
#ML
получил коммент -- а что заставило смеяться? Конкретно для меня целая схема по гуглингу статей выглядит очень забавно. Могу показать какие схемы мне нравятся: обзор 2023 по темпоральным графовым сеткам или SoK: Certified Robustness for
Deep Neural Networks. Я читаю обзоры чтобы понять ландшафт, какие подходы есть в крупную клетку и когда их применять и ожидаю картинки про это, а не картинку про отбор статей на всю страницу)
получил коммент -- а что заставило смеяться? Конкретно для меня целая схема по гуглингу статей выглядит очень забавно. Могу показать какие схемы мне нравятся: обзор 2023 по темпоральным графовым сеткам или SoK: Certified Robustness for
Deep Neural Networks. Я читаю обзоры чтобы понять ландшафт, какие подходы есть в крупную клетку и когда их применять и ожидаю картинки про это, а не картинку про отбор статей на всю страницу)
🔥5🤓4👍2❤1
#кейсы
Кейс про 71 или нет KPI, который нельзя взломать
В карьере каналий-манагеров бывают взлеты и падения.
Вот и героиня этой истории попала в организации в волну дебоссинга и очнулась на чужом пляже на пару грейдов ниже. В новом подразделении особой характерной чертой была высокая текучка руководителей – сменилось 7 за три года ☠️.
А все из-за KPI – надо было настроить реплики (обновляемые копии структур данных) 71 одной системе в хадуп к концу года.
Большинство конечно были оракловые, но встречались и DB2 и SAP и прочий зоопарк.
К слову тогда лицензия на коннектор оракл-хадуп стоила 1 млрд рублей, но обосновать ее покупку канальи не смогли, ели кактус.
Как только изворачивалось это подразделение чтобы не работать – а давайте сначала спросим бизнес а какие таблицы точно нужны – так к слову, потеряли кучу связочных. А давайте по регионам разобьем. И хотя мелкие гадости прокатывали, а роадмеп все сдвигался и сдвигался вправо, чем дальше тем меньше было понятно до конца какого именно года удастся настроить реплики.
Так вот героиня истории оказалась очень креативной – а давайте считать системы не по названиям и бизнес-логике а по КЭ (конфигурационным элементам) – бюрократической сущности, в которой вели учет инфры. Например, сервер с отчетами – 1 КЭ, бэкап-сервер – второй и тд. В среднем на одну систему 20 КЭ – в итоге вместо репликации 71 системы достаточно сделать 3,5. Протокольной службе действительно хватило 71 ID!! 😂
После такого оглушительного успеха грейд героине восстановили конечно) 💪👏
Но спустя полгода появился супер-топ-манагер из 🇺🇸. Поглядел своим опытным взглядом и сказал – зачем вы вообще на такое соглашаетесь. Пусть за реплики отвечает бизнес, а мы будем инструмент пилить (то что в мире таких ETL полно оставим за скобками). Признаюсь, идея ответственности бизнеса за ИТ меня впечатлила 😍😍😍
Высший пилотаж!
Но оглядевшись, понял что так в жизни много где – ответственность за здоровье на пациенте а не враче, ответственность за безопасность и образование детей на родителях, а не на школе. Так что действительно – почему бы KPI на заказчика / клиента не перекладывать? Давайте-таки продавать лопаты а не копать!
Кейс про 71 или нет KPI, который нельзя взломать
В карьере каналий-манагеров бывают взлеты и падения.
Вот и героиня этой истории попала в организации в волну дебоссинга и очнулась на чужом пляже на пару грейдов ниже. В новом подразделении особой характерной чертой была высокая текучка руководителей – сменилось 7 за три года ☠️.
А все из-за KPI – надо было настроить реплики (обновляемые копии структур данных) 71 одной системе в хадуп к концу года.
Большинство конечно были оракловые, но встречались и DB2 и SAP и прочий зоопарк.
К слову тогда лицензия на коннектор оракл-хадуп стоила 1 млрд рублей, но обосновать ее покупку канальи не смогли, ели кактус.
Как только изворачивалось это подразделение чтобы не работать – а давайте сначала спросим бизнес а какие таблицы точно нужны – так к слову, потеряли кучу связочных. А давайте по регионам разобьем. И хотя мелкие гадости прокатывали, а роадмеп все сдвигался и сдвигался вправо, чем дальше тем меньше было понятно до конца какого именно года удастся настроить реплики.
Так вот героиня истории оказалась очень креативной – а давайте считать системы не по названиям и бизнес-логике а по КЭ (конфигурационным элементам) – бюрократической сущности, в которой вели учет инфры. Например, сервер с отчетами – 1 КЭ, бэкап-сервер – второй и тд. В среднем на одну систему 20 КЭ – в итоге вместо репликации 71 системы достаточно сделать 3,5. Протокольной службе действительно хватило 71 ID!! 😂
После такого оглушительного успеха грейд героине восстановили конечно) 💪👏
Но спустя полгода появился супер-топ-манагер из 🇺🇸. Поглядел своим опытным взглядом и сказал – зачем вы вообще на такое соглашаетесь. Пусть за реплики отвечает бизнес, а мы будем инструмент пилить (то что в мире таких ETL полно оставим за скобками). Признаюсь, идея ответственности бизнеса за ИТ меня впечатлила 😍😍😍
Высший пилотаж!
Но оглядевшись, понял что так в жизни много где – ответственность за здоровье на пациенте а не враче, ответственность за безопасность и образование детей на родителях, а не на школе. Так что действительно – почему бы KPI на заказчика / клиента не перекладывать? Давайте-таки продавать лопаты а не копать!
😁10❤4🤔1
Про что рассказать в завтрашнем посте?
Anonymous Poll
44%
Кейс каналья-менеджмента 🤥
56%
Кейс про модельную архитектуру со схемой подмоделей и описанием работы 🤓
#кейсы #ML
Итак, победил (пусть и не абсолютно) кейс с модельной архитектурой.
Полностью и исключительно вымышленный, естественно, просто плод воображения.
Когда застройщик обращается в банк за кредитом для планируемого строительства жилых корпусов, залоговой службе нужно оценить насколько проект в целом интересный — то есть посчитать будущий денежный поток. Для этого надо понять когда и по какой цене квартиры распродадут (а еще неплохо и парковки и коммерческую недвижимость если есть). Причем тк деньги имеют свою цену — еще и поквартально.
То есть в этом квартале продадут x кв метров при средней цене y рублей, в следующем тоже прогноз и так до тех пор пока не распродадут все.
В руках у нас только даты старта строительства, старта продаж и параметры объекта, который хотят построить — какие есть квартиры, какой площади, с отделкой или без, сколько этажей и прочее.
Понятно что в ЖК может быть несколько корпусов с разными датами ввода и пр (привет, GroupKFold).
Мб и было бы здорово сразу прогнозировать денежный поток одной моделькой, но увы и ах, залоговики хотят знать как выбирались объекты аналоги (которые рядом и похожи на искомый), насколько модель в своем ответе уверена, насколько вообще объект ликвиден, плюс иметь возможность закладывать разные макропрогнозы (инфляция, ключевая ставка, льготные программы в регионе и пр.), поэтому моделей сильно больше одной вышло).
Сбор датасета невероятное чутдо (например, часть объектов с эксроу, часть без), найти где-то реальные данные о темпах и ценах продаж (не из объявлений же брать), нормализовать адреса и между собой перематчить — а они по объекту могли меняться в процессе, добавить POI, и только тогда приступить к построению моделей.
Чтобы сократить объем поста, приложу схему и отвечу на наиболее популярные вопросы:
- Откуда цены —проектные декларации, выписки из Росреестра, ипотечные договора физиков
- Объекты-аналоги — с одной стороны реликт ручного процесса, с другой стороны в своей стоимости и ее динамике несут какую-то инфо о локации.
Модель цены предиктит попарно для каждого ОА, затем предикты усредняются
- Ликвидность — про то какая доля будет продана к условно-готовой стадии
- Почему уверенность а не доверительный интервал? — потому как человеку проще объяснить одним числом где модель применять вообще не следует, плюс в этих моделях использовались фичи, которые просто беггингом (см. RMSEWithUncertaincy) не поймаешь
- В продажах есть сезонность — однозначно
- Киллер-фича по темпам — ликвидность, затем сам застройщик, степень готовности, остатки площадей, ср. площадь квартир
- Макро правда влияет на цену — более того, накопленная инфляция учитывается в применении к объектам-аналогам.
Напоминаю, что все это исключительно плод чьего-то больного воображения.
Итак, победил (пусть и не абсолютно) кейс с модельной архитектурой.
Полностью и исключительно вымышленный, естественно, просто плод воображения.
Когда застройщик обращается в банк за кредитом для планируемого строительства жилых корпусов, залоговой службе нужно оценить насколько проект в целом интересный — то есть посчитать будущий денежный поток. Для этого надо понять когда и по какой цене квартиры распродадут (а еще неплохо и парковки и коммерческую недвижимость если есть). Причем тк деньги имеют свою цену — еще и поквартально.
То есть в этом квартале продадут x кв метров при средней цене y рублей, в следующем тоже прогноз и так до тех пор пока не распродадут все.
В руках у нас только даты старта строительства, старта продаж и параметры объекта, который хотят построить — какие есть квартиры, какой площади, с отделкой или без, сколько этажей и прочее.
Понятно что в ЖК может быть несколько корпусов с разными датами ввода и пр (привет, GroupKFold).
Мб и было бы здорово сразу прогнозировать денежный поток одной моделькой, но увы и ах, залоговики хотят знать как выбирались объекты аналоги (которые рядом и похожи на искомый), насколько модель в своем ответе уверена, насколько вообще объект ликвиден, плюс иметь возможность закладывать разные макропрогнозы (инфляция, ключевая ставка, льготные программы в регионе и пр.), поэтому моделей сильно больше одной вышло).
Сбор датасета невероятное чутдо (например, часть объектов с эксроу, часть без), найти где-то реальные данные о темпах и ценах продаж (не из объявлений же брать), нормализовать адреса и между собой перематчить — а они по объекту могли меняться в процессе, добавить POI, и только тогда приступить к построению моделей.
Чтобы сократить объем поста, приложу схему и отвечу на наиболее популярные вопросы:
- Откуда цены —проектные декларации, выписки из Росреестра, ипотечные договора физиков
- Объекты-аналоги — с одной стороны реликт ручного процесса, с другой стороны в своей стоимости и ее динамике несут какую-то инфо о локации.
Модель цены предиктит попарно для каждого ОА, затем предикты усредняются
- Ликвидность — про то какая доля будет продана к условно-готовой стадии
- Почему уверенность а не доверительный интервал? — потому как человеку проще объяснить одним числом где модель применять вообще не следует, плюс в этих моделях использовались фичи, которые просто беггингом (см. RMSEWithUncertaincy) не поймаешь
- В продажах есть сезонность — однозначно
- Киллер-фича по темпам — ликвидность, затем сам застройщик, степень готовности, остатки площадей, ср. площадь квартир
- Макро правда влияет на цену — более того, накопленная инфляция учитывается в применении к объектам-аналогам.
Напоминаю, что все это исключительно плод чьего-то больного воображения.
❤19👍10🔥7
Есть гипотезы, почему google translate настолько разные результаты выдает в чуть разных окошках? Вряд ли две разных модели. Или типа на главной такой alignment чтоб без мата? Вообще я хотел просто охладить траханье (с)
🤣6
#ML
К посту выше — по совету Артема попробовал сделать то же самое в режиме инкогнито и с включенным VPN, результат тот же.
У меня несколько предположений как на главной избегают мата:
◦ Словарь замен применяется к выходу к t2t модели-переводчика
◦ Другая моделька, которая применяется к выходу к t2t модели-переводчика
◦ На главной используется другая модель, которая элайнится на этику
Кстати, про alignment из обзоров не нашел ничего свежее июльского https://arxiv.org/pdf/2407.16216 , сажусь разбирать.
К посту выше — по совету Артема попробовал сделать то же самое в режиме инкогнито и с включенным VPN, результат тот же.
У меня несколько предположений как на главной избегают мата:
◦ Словарь замен применяется к выходу к t2t модели-переводчика
◦ Другая моделька, которая применяется к выходу к t2t модели-переводчика
◦ На главной используется другая модель, которая элайнится на этику
Кстати, про alignment из обзоров не нашел ничего свежее июльского https://arxiv.org/pdf/2407.16216 , сажусь разбирать.
👍6
#кейсы #ML
Аксиома — когда выходишь на новую работу, от тебя ждут квик-винов.
Что бы тебе не втирали про стратегию, трансформацию, процессы, рисование планов и презентаций — твой кредит доверия это квик-вины.
Есть у меня история как я в первую неделю после выхода окупил свою годовую зп с большим запасом.
Была команда, человек 15, из них пяток DS и несколько DA, относительно молодая — основной состав вместе работал год-полтора.
И был у них главный регулярный KPI на качество модели скоринга — чтоб они эту модель улучшали значит все время. Не будем сейчас о разумности таких KPI (хотя если хотите кейсы про KPI DS-командам — можете сердечко поставить), история о другом.
Ища те самые квик-вины я прикинул что с одним DS и одним DA за полгода можно собрать витрины связей и ребятам графовые сетки сделать, оттестить и поставить в прод.
Какой-никакой аплифт по Gini получится.
Забегая вперед скажу — что так и вышло, только вот не за полгода) Но сейчас не об этом.
Чтобы что-то построить дополняющее неплохо бы сделать свой baseline, для этого надо таргетов собрать.
Команда работает полтора года, табличка с таргетами готова и тащательно вылизана — 3 года, примерно по 5-7 тыс единичек в году. На миллионы ноликов.
Чет маловато единичек, не?
Смотрю как собирается: есть две таблички — Clients и Contracts (кредитные договоры).
Вроде все ясно, джойнятся по client_id, потому что в Clients указан msisdn (телефон), к которому уже можно вязать витрины фичей (они про тот client_id не знают ничего).
Если телефон в Clients не указан — в таргеты такая строчка не попадает.
Все бы ничего, но рядом есть третья табличка — Applications (заявки на кредит), а там поле телефон обязательное!
Вот сджойнить c Applications и воткнуть COALESCE чтобы заполнить пропущенные телефоны хватило для того чтобы нарастить число единичек в 3.5-4 раза в каждый из годов. Что произошло после этого с моделью довольно очевидно)
Так что стратегия в любой задаче начинать со сбора и определения таргета оказалась вполне рабочей, да и кейс этот потом не раз выручал во внутренних дискуссиях.
Аксиома — когда выходишь на новую работу, от тебя ждут квик-винов.
Что бы тебе не втирали про стратегию, трансформацию, процессы, рисование планов и презентаций — твой кредит доверия это квик-вины.
Есть у меня история как я в первую неделю после выхода окупил свою годовую зп с большим запасом.
Была команда, человек 15, из них пяток DS и несколько DA, относительно молодая — основной состав вместе работал год-полтора.
И был у них главный регулярный KPI на качество модели скоринга — чтоб они эту модель улучшали значит все время. Не будем сейчас о разумности таких KPI (хотя если хотите кейсы про KPI DS-командам — можете сердечко поставить), история о другом.
Ища те самые квик-вины я прикинул что с одним DS и одним DA за полгода можно собрать витрины связей и ребятам графовые сетки сделать, оттестить и поставить в прод.
Какой-никакой аплифт по Gini получится.
Забегая вперед скажу — что так и вышло, только вот не за полгода) Но сейчас не об этом.
Чтобы что-то построить дополняющее неплохо бы сделать свой baseline, для этого надо таргетов собрать.
Команда работает полтора года, табличка с таргетами готова и тащательно вылизана — 3 года, примерно по 5-7 тыс единичек в году. На миллионы ноликов.
Чет маловато единичек, не?
Смотрю как собирается: есть две таблички — Clients и Contracts (кредитные договоры).
Вроде все ясно, джойнятся по client_id, потому что в Clients указан msisdn (телефон), к которому уже можно вязать витрины фичей (они про тот client_id не знают ничего).
Если телефон в Clients не указан — в таргеты такая строчка не попадает.
Все бы ничего, но рядом есть третья табличка — Applications (заявки на кредит), а там поле телефон обязательное!
Вот сджойнить c Applications и воткнуть COALESCE чтобы заполнить пропущенные телефоны хватило для того чтобы нарастить число единичек в 3.5-4 раза в каждый из годов. Что произошло после этого с моделью довольно очевидно)
Так что стратегия в любой задаче начинать со сбора и определения таргета оказалась вполне рабочей, да и кейс этот потом не раз выручал во внутренних дискуссиях.
❤57👍13🥴6🔥4💔1
Дата канальи — про «специалистов» в данных / ML / AI
Есть гипотезы, почему google translate настолько разные результаты выдает в чуть разных окошках? Вряд ли две разных модели. Или типа на главной такой alignment чтоб без мата? Вообще я хотел просто охладить траханье (с)
#кейсы #ML
после того поста вспомнился кейс когда нормальное отношение к мату помогло спасти денег -- учредитель засветился в юр связях с примерно таким ликвидированным ООО (в 2021 создано, в 2023 ликвидировано). прочитайте название наоборот .
Словарь названий фирм-однодневок вполне себе неплохая фича в AML (борьбе с отмываем денег) -- если учредитель ООО, которое пришло у вас открывать счет, до этого открывал "Тензоры" и "Векторы", то ошибиться тяжело. И не надо думать что это боян из 90х. Вот ООО в 2018 открыли. А вот в 2021 Оманид. А вот еще в 2020 Аквалабиан. Вот еще 2017 ООО. А вот ООО Луник из 2022. Вот 2023й -- ООО Кодик.
А первую часть поста про встреченные мной KPI DS-команд выложу ближе к вечеру
после того поста вспомнился кейс когда нормальное отношение к мату помогло спасти денег -- учредитель засветился в юр связях с примерно таким ликвидированным ООО (в 2021 создано, в 2023 ликвидировано).
Словарь названий фирм-однодневок вполне себе неплохая фича в AML (борьбе с отмываем денег) -- если учредитель ООО, которое пришло у вас открывать счет, до этого открывал "Тензоры" и "Векторы", то ошибиться тяжело. И не надо думать что это боян из 90х. Вот ООО в 2018 открыли. А вот в 2021 Оманид. А вот еще в 2020 Аквалабиан. Вот еще 2017 ООО. А вот ООО Луник из 2022. Вот 2023й -- ООО Кодик.
А первую часть поста про встреченные мной KPI DS-команд выложу ближе к вечеру
www.rusprofile.ru
ООО "Лабеан"
Ключевые сведения о ООО "Лабеан" из официальных источников.
😁13🔥11❤2🤝2
#корпжиза
Про KPI у DS. Часть 1.
Реальный диалог:
“-- тимлид, че у вас модели говно?
– от нас требуют в прод по 4 модели в квартал на одного DS выводить”
😵
Так сложилось, что достаточно часто KPI на DS каскадируют канальи, у которых ни одной модели в проме нет. Часто такой трек идет в паре с любовью к количественным KPI (хотя логичнее называть их численными) и особенно к измерению “производительности DS” 🤬.
Вот что я встречал в качестве численных KPI для DS и их тимлидов:
▪️ “производительность” – число моделей в проме на 1 DS в квартал
▪️ число проведенных A/B в квартал на 1 DS
▪️ доля процессов с AI в ПРОМе
▪️ фин эффект в рублях в расчете на 1 DS
▪️ доля моделей с качеством выше AutoML baseline
▪️ доля моделей в проме на автомониторинге
▪️ доля моделей в проме с автовалидацией
▪️ доля процессов на единых AI-платформах
▪️ доля моделей, внедренных на целевых / пром средах
▪️ Т2М моделей – время от непонятно чего (заведения модели в учетную систему) до внедрения в пром
▪️ доля моделей, внедренных после A/B
▪️ число статей / выступдений на конференциях
И незабываемые качественные по конкретным моделям:
▪️ модель должна быть лучше эксперта по мнению самого эсперта (которого сократят если модель будет лучше)
▪️ модель должна быть лучше бейзлайна, но есть нюансы
▪️ модель должна прогнозировать на 3 месяца с качеством которое сейчас у отдела прогнозирования на 5 днях в будущее
и т.д.
Иногда из других компаний приходят с запросом: “Хотим чтобы DS работали эффективнее”.
А на вопрос “А как вы оцениваете их работу?” пожимают плечами и говорят “ну, по бизнес-метрикам”.
Короче, видимо зуд у каналий-манагеров на тему "не филонят ли наши DS" есть, их же на курсах учат что "не измеряешь -- не управляешь". Так и представляю себе партизанский отряд Фиделя Кастро с ежедневными отчетами по выпущенным патронам и A/B-тестам поражения целей 😂
Во второй части поделюсь своим имхо как этот зуд снимать. И заодно расскажу каких принципов придерживаюсь сам.
Про KPI у DS. Часть 1.
Реальный диалог:
“-- тимлид, че у вас модели говно?
– от нас требуют в прод по 4 модели в квартал на одного DS выводить”
😵
Так сложилось, что достаточно часто KPI на DS каскадируют канальи, у которых ни одной модели в проме нет. Часто такой трек идет в паре с любовью к количественным KPI (хотя логичнее называть их численными) и особенно к измерению “производительности DS” 🤬.
Вот что я встречал в качестве численных KPI для DS и их тимлидов:
▪️ “производительность” – число моделей в проме на 1 DS в квартал
▪️ число проведенных A/B в квартал на 1 DS
▪️ доля процессов с AI в ПРОМе
▪️ фин эффект в рублях в расчете на 1 DS
▪️ доля моделей с качеством выше AutoML baseline
▪️ доля моделей в проме на автомониторинге
▪️ доля моделей в проме с автовалидацией
▪️ доля процессов на единых AI-платформах
▪️ доля моделей, внедренных на целевых / пром средах
▪️ Т2М моделей – время от непонятно чего (заведения модели в учетную систему) до внедрения в пром
▪️ доля моделей, внедренных после A/B
▪️ число статей / выступдений на конференциях
И незабываемые качественные по конкретным моделям:
▪️ модель должна быть лучше эксперта по мнению самого эсперта (которого сократят если модель будет лучше)
▪️ модель должна быть лучше бейзлайна, но есть нюансы
▪️ модель должна прогнозировать на 3 месяца с качеством которое сейчас у отдела прогнозирования на 5 днях в будущее
и т.д.
Иногда из других компаний приходят с запросом: “Хотим чтобы DS работали эффективнее”.
А на вопрос “А как вы оцениваете их работу?” пожимают плечами и говорят “ну, по бизнес-метрикам”.
Короче, видимо зуд у каналий-манагеров на тему "не филонят ли наши DS" есть, их же на курсах учат что "не измеряешь -- не управляешь". Так и представляю себе партизанский отряд Фиделя Кастро с ежедневными отчетами по выпущенным патронам и A/B-тестам поражения целей 😂
Во второй части поделюсь своим имхо как этот зуд снимать. И заодно расскажу каких принципов придерживаюсь сам.
👍23🔥11😁7❤2🤣1
#корпжиза
Про KPI у DS. Часть 2.
Картинка выше намекает)
Задавались ли вы вопросом почему разработчикам не приходится доказывать свою эффективность финансистам и прочим?
Почему DSов зачастую оценивают по влиянию на бизнес-метрики?
Давайте посмотрим как вообще оценивают разрабов – по сложности задач и скорости их выполнения. То есть продакт на основе исследований (в тч общения с реальными пользователями) или чуйки приоритезирует функционал, тех лид пилит на задачи, сам или коллективным разумом оценивает их,, и задача поступает разработчику (если повезет – в промежутке еще и аналитик будет, который аккуратно распишет что именно нужно сделать).
Почему так происходит? Есть много соображений:
▪️ Логика софта детерменирована и потому понятна обывателю
▪️ CTO это C-Level и способен продать позицию что он предоставляет ресурсы и инструменты, а зарабатывать денег – задача бизнеса
▪️ Результат принципиально достижим и сроки управляемы – задачу в конце концов можно заутстаффить
▪️ Любые, даже самые идиотские, требования реализуемы – вопрос ресурсов и сроков
▪️ Развита инфраструктура самих решений – языков, фреймворков / библиотек – а тех. поддержку можно купить у вендора
▪️ Разработка меньше привязана к домену, чем DS (но все-таки привязана – embedded, crypto, hft – все разная специфика)
▪️ Проектирование приложений укладывается в принципы и паттерны
▪️ В ходе code review можно оценить качество кода
▪️ Можно страховаться покрытием автотестами, нагрузочным, интеграционным и функциональным тестированием
В противоположность в DS:
▪️ Обыватель не понимает статистику, концепцию случайной величины и случайных процессов. Максимум образования это A/B. Про то, что у A/B тоже не стопроцентная точность, или хотя бы про A/A или A/B/n обыватель не знает точно. Весь ноябрь и декабрь пол-страны гадало по недельной (!!!) инфляции повысит или нет ЦБ ставку.
Кстати, почему DS в рисках мерит качество моделей в Gini а не в ROCAUC? Потому что модуль Gini стартует от 0 и ренж от 0 до 100 проще объяснить заказчику.
▪️ CDS это часто CEO-2 или даже ниже – над ним либо CTO, либо CDO, либо CDTO
▪️ На конкретном датасете всегда есть максимальный предел точности – более того, чем ближе к нему подойти тем возможно менее стабильным будет решение
▪️ Чтобы декомпозировать задачи DSу и делать предположения какие офлайн-метрики тюнить, нужен другой DS поопытнее с такой же узкой специализацией. Декомпозиция не делает сроки предсказуемыми – пока не придумаешь и не сделаешь на данных тесты на консистентность, не поймешь, можно ли хоть какую-то модель построить
▪️ Внедрением часто занимаются совсем другие люди
▪️ Даже в банках отделы валидации берут достаточно большой срок чтобы оценить качество построения модели, при этом они не оценивают корректно ли собран таргет, фичи и пр. Полноценный review построенной модели не менее трудоемок чем построение модели с нуля включая сбор данных.
▪️ В конце концов непонятно чего эти кнопкодавы там делают, руками не потрогать! Здесь неизменный восторг каналий-манагеров вызывают интерактивные демо (например, отзывы разметить или суммаризировать) и недоумение классные модели, на которых эффекты получаются. Чем дальше от розницы или рекламы тем больше “ну A/B-тест A/B-тестом, но продал же продажник а не модель”. Занавес.
Лично я и сам избегаю и сотрудникам никогда не ставлю численные KPI. Ибо любой числовой KPI хакается (или задрачивать будут только его в ущерб остальному).
В тч от фин эффектов тоже отбиваюсь.
Про KPI у DS. Часть 2.
Картинка выше намекает)
Задавались ли вы вопросом почему разработчикам не приходится доказывать свою эффективность финансистам и прочим?
Почему DSов зачастую оценивают по влиянию на бизнес-метрики?
Давайте посмотрим как вообще оценивают разрабов – по сложности задач и скорости их выполнения. То есть продакт на основе исследований (в тч общения с реальными пользователями) или чуйки приоритезирует функционал, тех лид пилит на задачи, сам или коллективным разумом оценивает их,, и задача поступает разработчику (если повезет – в промежутке еще и аналитик будет, который аккуратно распишет что именно нужно сделать).
Почему так происходит? Есть много соображений:
▪️ Логика софта детерменирована и потому понятна обывателю
▪️ CTO это C-Level и способен продать позицию что он предоставляет ресурсы и инструменты, а зарабатывать денег – задача бизнеса
▪️ Результат принципиально достижим и сроки управляемы – задачу в конце концов можно заутстаффить
▪️ Любые, даже самые идиотские, требования реализуемы – вопрос ресурсов и сроков
▪️ Развита инфраструктура самих решений – языков, фреймворков / библиотек – а тех. поддержку можно купить у вендора
▪️ Разработка меньше привязана к домену, чем DS (но все-таки привязана – embedded, crypto, hft – все разная специфика)
▪️ Проектирование приложений укладывается в принципы и паттерны
▪️ В ходе code review можно оценить качество кода
▪️ Можно страховаться покрытием автотестами, нагрузочным, интеграционным и функциональным тестированием
В противоположность в DS:
▪️ Обыватель не понимает статистику, концепцию случайной величины и случайных процессов. Максимум образования это A/B. Про то, что у A/B тоже не стопроцентная точность, или хотя бы про A/A или A/B/n обыватель не знает точно. Весь ноябрь и декабрь пол-страны гадало по недельной (!!!) инфляции повысит или нет ЦБ ставку.
Кстати, почему DS в рисках мерит качество моделей в Gini а не в ROCAUC? Потому что модуль Gini стартует от 0 и ренж от 0 до 100 проще объяснить заказчику.
▪️ CDS это часто CEO-2 или даже ниже – над ним либо CTO, либо CDO, либо CDTO
▪️ На конкретном датасете всегда есть максимальный предел точности – более того, чем ближе к нему подойти тем возможно менее стабильным будет решение
▪️ Чтобы декомпозировать задачи DSу и делать предположения какие офлайн-метрики тюнить, нужен другой DS поопытнее с такой же узкой специализацией. Декомпозиция не делает сроки предсказуемыми – пока не придумаешь и не сделаешь на данных тесты на консистентность, не поймешь, можно ли хоть какую-то модель построить
▪️ Внедрением часто занимаются совсем другие люди
▪️ Даже в банках отделы валидации берут достаточно большой срок чтобы оценить качество построения модели, при этом они не оценивают корректно ли собран таргет, фичи и пр. Полноценный review построенной модели не менее трудоемок чем построение модели с нуля включая сбор данных.
▪️ В конце концов непонятно чего эти кнопкодавы там делают, руками не потрогать! Здесь неизменный восторг каналий-манагеров вызывают интерактивные демо (например, отзывы разметить или суммаризировать) и недоумение классные модели, на которых эффекты получаются. Чем дальше от розницы или рекламы тем больше “ну A/B-тест A/B-тестом, но продал же продажник а не модель”. Занавес.
Лично я и сам избегаю и сотрудникам никогда не ставлю численные KPI. Ибо любой числовой KPI хакается (или задрачивать будут только его в ущерб остальному).
В тч от фин эффектов тоже отбиваюсь.
🔥14👍12❤2😱1
#корпжиза
Как устроено у нас в части DS (про ML-платформы отдельный разговор):
Матричная структура – DS числятся в центре компетенций, но работают на продуктах (другой вопрос что команды в центре компетенций я нарезал чтобы они максимально с продуктами бились).
В продукте по решению самой команды бывает мотивация:
▪️ продуктовая (повышенные бонусы за достижения бизнес-результата – цели одинаковые у всей команды – продакта, DE, Dev, DS, DA, тестеров, DevOps и пр.)
▪️ непродуктовая – индивидуальные качественные цели которые сбивают тим. лид и продакт (как правило достаточно гибкие, а если уж эти двое не могут договориться – то сл раунд мой и CPO).
▪️ Даже если вся команда на продуктовой, но DS очень не хочет – есть возможность перевести его на ставку с непродуктовой мотивацией или ротировать его в другой продукт с обычной мотивацией.
В целом я фанат мультиагентных систем и переношу это в управление.
Главная задача – нанять или вырастить мотивированных компетентных людей, верно их проинформировать и направить, создать условия, помогать если обращаются или долго буксуют.
Детальный KPI, в тч численный, частые статусы и мелконарезанные задачи (любимый в agile микроменеджмент) – это все инструменты лечения патологии, то есть когда что-то идет плохо и надо влезть внутрь и разобраться – это ошибка целеполагания, процессов и условий или ошибка найма.
Последнее, кстати, далеко не всегда про увольнение – горжусь кейсом когда с достаточно средним DS поговорили и выяснили что python ему нравится больше чем все эти модели; и вуаля – после обучения появился специалист MLOps, который и сам круто вырос и команду себе собрал и вырастил и очень классно у нас все выстроил. После известных событий работает в Европе, в компании с рабочим английским.
Как устроено у нас в части DS (про ML-платформы отдельный разговор):
Матричная структура – DS числятся в центре компетенций, но работают на продуктах (другой вопрос что команды в центре компетенций я нарезал чтобы они максимально с продуктами бились).
В продукте по решению самой команды бывает мотивация:
▪️ продуктовая (повышенные бонусы за достижения бизнес-результата – цели одинаковые у всей команды – продакта, DE, Dev, DS, DA, тестеров, DevOps и пр.)
▪️ непродуктовая – индивидуальные качественные цели которые сбивают тим. лид и продакт (как правило достаточно гибкие, а если уж эти двое не могут договориться – то сл раунд мой и CPO).
▪️ Даже если вся команда на продуктовой, но DS очень не хочет – есть возможность перевести его на ставку с непродуктовой мотивацией или ротировать его в другой продукт с обычной мотивацией.
В целом я фанат мультиагентных систем и переношу это в управление.
Главная задача – нанять или вырастить мотивированных компетентных людей, верно их проинформировать и направить, создать условия, помогать если обращаются или долго буксуют.
Детальный KPI, в тч численный, частые статусы и мелконарезанные задачи (любимый в agile микроменеджмент) – это все инструменты лечения патологии, то есть когда что-то идет плохо и надо влезть внутрь и разобраться – это ошибка целеполагания, процессов и условий или ошибка найма.
Последнее, кстати, далеко не всегда про увольнение – горжусь кейсом когда с достаточно средним DS поговорили и выяснили что python ему нравится больше чем все эти модели; и вуаля – после обучения появился специалист MLOps, который и сам круто вырос и команду себе собрал и вырастил и очень классно у нас все выстроил. После известных событий работает в Европе, в компании с рабочим английским.
👍19🔥9❤6
#ML
Узнал тут про калибровку двумя изотониками -- Venn-ABERS, еще и на мультикласс расширяется, прикольно
Узнал тут про калибровку двумя изотониками -- Venn-ABERS, еще и на мультикласс расширяется, прикольно
Kaggle
Classifier calibration using Venn-ABERS
Explore and run machine learning code with Kaggle Notebooks | Using data from Spaceship Titanic ...in all probability!
👍10🔥4
#кейсы #ML
Не может список кейсов быть полным без кейсов чайка-менеджмента, ввиду остутсвия смайлов далее обозначим такую каналью курицей 🐓. Для тех, кто не в курсе – этот стиль менеджмента c девизом “veni defeci avolavi” и ортогонален Цезарю с его “veni vidi vici”.
Все мы гордимся когда наши модели в проме и долго приносят пользу.
Вот и я так же)
Однажды узнал что мою старинную графовую модель отключили потому что она якобы “не работала”, а каналья-манагер 🤡, не успев проработать на должности и года, улетела в другой банк, где, наверное, мечты сбываются. Чайка, в худшем проявлении.
Но мне интересно стало – что значит не работает 🤷♂️.
А работала модель так – если связей у ЮЛ нет, оставляла standalone score, если связи есть – то модель дает новый скор. Связи пересчитывались раз в неделю с учетом истории – как минимум изменяются доли владения, вносятся уточнения, экономические связи так вообще не так устойчивы.
Расследование вывело меня на веселых ребят из управления, которое занимается данными 🧑🤝🧑. Веселые ребята совершенно случайно (!) в проме (!) снесли ¾ источника данных по юр лицам, включая финансовую отчетность Росстата, схемы владения, данные по управляющим и пр.
Заметили ребята из рисков, тоже случайно, примерно через месяц.
В итоге источник починили, дозагрузили на прод, а вот модель не включили – каналья, которая ее отключила, уже💩 в другом месте.
Будем надеяться, что рано или поздно чайки соберутся вместе и будут наслаждаться работой друг с другом 😂.
Отсюда совет – будьте внимательны на собеседованиях, особенно если чувствуете что ваш предполагаемый шеф настроен лишь “немного пересидеть” до следующего полета. Можно оказаться в нездоровом месте и потом за ним много всего разгребать.
Не может список кейсов быть полным без кейсов чайка-менеджмента, ввиду остутсвия смайлов далее обозначим такую каналью курицей 🐓. Для тех, кто не в курсе – этот стиль менеджмента c девизом “veni defeci avolavi” и ортогонален Цезарю с его “veni vidi vici”.
Все мы гордимся когда наши модели в проме и долго приносят пользу.
Вот и я так же)
Однажды узнал что мою старинную графовую модель отключили потому что она якобы “не работала”, а каналья-манагер 🤡, не успев проработать на должности и года, улетела в другой банк, где, наверное, мечты сбываются. Чайка, в худшем проявлении.
Но мне интересно стало – что значит не работает 🤷♂️.
А работала модель так – если связей у ЮЛ нет, оставляла standalone score, если связи есть – то модель дает новый скор. Связи пересчитывались раз в неделю с учетом истории – как минимум изменяются доли владения, вносятся уточнения, экономические связи так вообще не так устойчивы.
Расследование вывело меня на веселых ребят из управления, которое занимается данными 🧑🤝🧑. Веселые ребята совершенно случайно (!) в проме (!) снесли ¾ источника данных по юр лицам, включая финансовую отчетность Росстата, схемы владения, данные по управляющим и пр.
Заметили ребята из рисков, тоже случайно, примерно через месяц.
В итоге источник починили, дозагрузили на прод, а вот модель не включили – каналья, которая ее отключила, уже
Будем надеяться, что рано или поздно чайки соберутся вместе и будут наслаждаться работой друг с другом 😂.
Отсюда совет – будьте внимательны на собеседованиях, особенно если чувствуете что ваш предполагаемый шеф настроен лишь “немного пересидеть” до следующего полета. Можно оказаться в нездоровом месте и потом за ним много всего разгребать.
Please open Telegram to view this post
VIEW IN TELEGRAM
😁13🔥5❤1🕊1
#кейсы #ML
Картинка про то как я познакомился с бутстрапом и ЦПТ, на фото два будущих сотрудника AI-управления крупного (очень) банка
Основной инструмент инженерной сейсморазведки – кувалда. Кувалдой стучат по металлической болванке и сейсмоприемниками регистрируют отраженные, преломленные и всякие другие волны, которые в него приходят. Так как на поверхности рыхлый чернозем, то сигнал получается достаточно слабый.
В учебниках по сейсморазведке подводится теоретическая база – эргодические процессы, осреднения по реализациям, нормально распределенный шум (хотя с чего бы) и прочая высокая (нет) наука. Все сводится к тому что если на одной и той же точке долбить N раз, то шум ослабнет в sqrt(N) раз.
В итоге в плохом случае делаешь по 3-5 тыс. ударов кувалдой в день (по 30-50 на каждой точке) и картинка в ноутбуке с сейсмограммами со станции и правда становится четче.
Зато ЦПТ и бутстрап теперь не забыть, а на том ML и стоит.
PS: кого-нибудь спрашивали на собеседованиях про ЦПТ / бутстрап / сэмплирование? Ставьте 👍если да.
Картинка про то как я познакомился с бутстрапом и ЦПТ, на фото два будущих сотрудника AI-управления крупного (очень) банка
Основной инструмент инженерной сейсморазведки – кувалда. Кувалдой стучат по металлической болванке и сейсмоприемниками регистрируют отраженные, преломленные и всякие другие волны, которые в него приходят. Так как на поверхности рыхлый чернозем, то сигнал получается достаточно слабый.
В учебниках по сейсморазведке подводится теоретическая база – эргодические процессы, осреднения по реализациям, нормально распределенный шум (хотя с чего бы) и прочая высокая (нет) наука. Все сводится к тому что если на одной и той же точке долбить N раз, то шум ослабнет в sqrt(N) раз.
В итоге в плохом случае делаешь по 3-5 тыс. ударов кувалдой в день (по 30-50 на каждой точке) и картинка в ноутбуке с сейсмограммами со станции и правда становится четче.
Зато ЦПТ и бутстрап теперь не забыть, а на том ML и стоит.
PS: кого-нибудь спрашивали на собеседованиях про ЦПТ / бутстрап / сэмплирование? Ставьте 👍если да.
❤19👍13🔥12👏3
Из комментов под предыдущим постом — не могу не репостнуть Сашин пост, вопросы к собеседованию по NLP