#ML
Как же у меня все-таки горит с собесов по ML System Design — например, с такого https://telegra.ph/ML-System-Design-Framework-12-29
Интервьюеры, начитавших выжимок из книжек, почему-то ожидают (и в цитируемом сообщении и в опыте прохождения не в рф) что loss ты выберешь раньше чем оффлайн-метрики. А иногда, как здесь -- и модель тоже.
Але, гараж!
Я лосс выбираю / модифицирую / взвешиваю под оффлайн метрики и данные конечно, а не наоборот. Если у меня регрессия и оценивать меня будут по MAPE — я и буду оптимизировать MAPE (например, через взвешенный MSE — хотя можно и напрямую сам MAPE -- с масштабами просто аккуратно надо). В учебном коде для градиента в SGD это выглядело бы так:
PS: Иногда меня мучает вопрос — вот учим мы студентов и в вузах и на курсах, а на собеседованиях они часто попадают к лиду, который лид потому что всех пересидел 🤡.
И вот будет говорить студент правильные вещи — про выбор сначала метрики, потом уже босса или что мультиколлинеарность сильно аффектит бустинги, или что для того чтобы убрать рамку с изображения не нужна сетка, а лид впитывал мифы и подсматривал методички а не разбирался сам — и будет ребят реджектить.
Учить нормально — медвежья услуга, получается? Как думаете?
Как же у меня все-таки горит с собесов по ML System Design — например, с такого https://telegra.ph/ML-System-Design-Framework-12-29
Интервьюеры, начитавших выжимок из книжек, почему-то ожидают (и в цитируемом сообщении и в опыте прохождения не в рф) что loss ты выберешь раньше чем оффлайн-метрики. А иногда, как здесь -- и модель тоже.
Але, гараж!
Я лосс выбираю / модифицирую / взвешиваю под оффлайн метрики и данные конечно, а не наоборот. Если у меня регрессия и оценивать меня будут по MAPE — я и буду оптимизировать MAPE (например, через взвешенный MSE — хотя можно и напрямую сам MAPE -- с масштабами просто аккуратно надо). В учебном коде для градиента в SGD это выглядело бы так:
def _der_loss(self, x, y, weight = 1):
if self.loss in ['MSE', 'MSE_weighted']:
return -(y - self._f(x)) * x * weight
elif self.loss == 'MAPE':
return -np.sign(y - self._f(x)) * x * weight
PS: Иногда меня мучает вопрос — вот учим мы студентов и в вузах и на курсах, а на собеседованиях они часто попадают к лиду, который лид потому что всех пересидел 🤡.
И вот будет говорить студент правильные вещи — про выбор сначала метрики, потом уже босса или что мультиколлинеарность сильно аффектит бустинги, или что для того чтобы убрать рамку с изображения не нужна сетка, а лид впитывал мифы и подсматривал методички а не разбирался сам — и будет ребят реджектить.
Учить нормально — медвежья услуга, получается? Как думаете?
Telegraph
ML System Design Framework
migrated to: https://alekseyen.notion.site/ml-system-desing-interview-fraemwork?pvs=4
👍17❤1
Дата канальи — про «специалистов» в данных / ML / AI pinned «#кейсы #ML Раз уж пошло про KPI – вот безобидный прием против вредного манагера. Прием для настоящих каналий! Если вразумлять и просвещать манагера на метрики регресии, распределения остатков и прочее сил уж больше нет, то могу предположить что каналья-манагер…»
#ML
В комментариях под предыдущим постом про лоссы Саша Ледовский (тимлид топовой high load ml-команды Авито) поддержал тезисы поста и привел пример своих кейсов когда даже бизнес-метрики на собеседовании были бы далеко не очевидны, не говоря уже и про лоссы.
Приведу другой пример — представим, что несчастный получил задачу на рекомендашки, и, согласно методичке, до всяких офлайн-метрик бодро выбрал модель назвал WARP-loss. Тут же получит:
- почему именно такой?
- а почему лосс именно ранжирующий? Почему не BCE на L2? ты еще не определил релевантность
- почему не BPR-loss? Какие между ними возможны трейдоффы? По качеству и перфомансу?
- а сколько надо рекомендовать?
- а под что такая модель обучится? вдруг это контентные рекомендации и там лютый popbias?
...
Короче, вот точно бы не туда дискуссия пошла -- даже если бы интервьюер промолчал, пришлось бы к этому вопросу возвращаться с поздних этапов.
Модель -- это инструмент, выбор лосса -- настройка инструмента. Онлайн метрика -- цель, офллайн -- прокси на нее.
PS: кстати, Саша давно ведет свой, наполненный оптимизмом и абсолютно личным опытом канал
PPS: а еще Саша — классный коллега, работали пару лет в соседних структурах одной организации
В комментариях под предыдущим постом про лоссы Саша Ледовский (тимлид топовой high load ml-команды Авито) поддержал тезисы поста и привел пример своих кейсов когда даже бизнес-метрики на собеседовании были бы далеко не очевидны, не говоря уже и про лоссы.
Приведу другой пример — представим, что несчастный получил задачу на рекомендашки, и, согласно методичке, до всяких офлайн-метрик бодро выбрал модель назвал WARP-loss. Тут же получит:
- почему именно такой?
- а почему лосс именно ранжирующий? Почему не BCE на L2? ты еще не определил релевантность
- почему не BPR-loss? Какие между ними возможны трейдоффы? По качеству и перфомансу?
- а сколько надо рекомендовать?
- а под что такая модель обучится? вдруг это контентные рекомендации и там лютый popbias?
...
Короче, вот точно бы не туда дискуссия пошла -- даже если бы интервьюер промолчал, пришлось бы к этому вопросу возвращаться с поздних этапов.
Модель -- это инструмент, выбор лосса -- настройка инструмента. Онлайн метрика -- цель, офллайн -- прокси на нее.
PS: кстати, Саша давно ведет свой, наполненный оптимизмом и абсолютно личным опытом канал
PPS: а еще Саша — классный коллега, работали пару лет в соседних структурах одной организации
👍12🔥4🙏3
#кейсы #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🤡3🤯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) не поймаешь
- В продажах есть сезонность — однозначно
- Киллер-фича по темпам — ликвидность, затем сам застройщик, степень готовности, остатки площадей, ср. площадь квартир
- Макро правда влияет на цену — более того, накопленная инфляция учитывается в применении к объектам-аналогам.
Напоминаю, что все это исключительно плод чьего-то больного воображения.
❤17👍10🔥6
Есть гипотезы, почему google translate настолько разные результаты выдает в чуть разных окошках? Вряд ли две разных модели. Или типа на главной такой alignment чтоб без мата? Вообще я хотел просто охладить траханье (с)
🤣5
#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🥴5🔥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, который и сам круто вырос и команду себе собрал и вырастил и очень классно у нас все выстроил. После известных событий работает в Европе, в компании с рабочим английским.
👍18🔥9❤6