Please open Telegram to view this post
VIEW IN TELEGRAM
Статьи про типичные ошибки в DS / ML реально такие
Forwarded from птенец
This media is not supported in your browser
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from ODS #jobs
AI engineer
200 000 – 800 000 ₽/месяц
Офис, Фултайм
Ищем опытного специалиста в области AI и Machine Learning для работы над передовыми технологиями в области крупных языковых моделей, оптимизации и ускорения вычислений…(читать далее)
200 000 – 800 000 ₽/месяц
Офис, Фултайм
Ищем опытного специалиста в области AI и Machine Learning для работы над передовыми технологиями в области крупных языковых моделей, оптимизации и ускорения вычислений…(читать далее)
Please open Telegram to view this post
VIEW IN TELEGRAM
Кто должен был быть в первых рядах приемки модели предыдущего кандидата и задавать ему каверзные вопросы?
Верно, речь пойдет про аналитиков
Несколько лет назад меня пригласили прочитать лекцию правлению одного крупного промышленного банка дружественной республики бывшего союза.
Задача была в духе как наладить дата-функцию так чтобы побыстрее с этого заработать, основной упор на кейсы, причем, кроме рисковых и бизнесовых, обсудили даже комплаенс и казну.
В банках вообще есть где развернуться в плане ML )
Много было вопросов по кейсам, но особенно живой интерес возник когда я сказал что аналитики им не нужны – мол, все равно вы не умеете ими пользоваться – что поделать, люблю чуть-чуть набросить 🤓.
Как я вижу работу дата-аналитика:
▪️ дизайн экспериментов / пост-эксперименты (блокинг, матчинг, каузальные выводы)
▪️ кейс-менеджмент
▪️ построение дерева метрик, исследование взаимного влияния метрик друг на друга
▪️ поиск прокси-метрик и прокси-событий
▪️ фин. модели для отмахивания от финансистов и аудиторов
Истории с прототипированием витрин, проверками данных, визуализации, первичную бизнес-валидацию – оставляю за DS, это обязательная и очень большая часть его работы
Истории с сегментацией / кластеризацией клиентской базы – свое отношение к таким “задачам” я в одном из первых постов высказал.
Как чаще всего используют аналитиков в компаниях, в которых продуктовая культура, скажем так, не особенно вызрела?
▪️ черная работа, которую не хочет делать DS / MLE / PO и остальные.
▪️ ad-hoc по велению левой пятки PO / CPO / любого другого манагера / канальи из соседнего отдела / управления / блока / департамента и пр. И суету создает и ЧСВ манагера растит.
И вот последнее отнимает 90-95% времени аналитиков.
Как с этим бороться? Обычно просто частотные запросы оформляют в дэш и берут на поддержку.
Еще были попытки text2sql, но тогда контекста моделей не хватало (да ис. бизнес-глоссариями было не так ровно как хотелось бы)
А как еще? (здесь каюсь, хорошая мысля приходит опосля – хоть я и боролся с ad-hoc, формализовать догадался только лишь потом):
▪️ Требовать дерево решений: вот насчитаю вам, уважаемый заказчик, требуемые показатели. Какие управленческие решения при каких значениях показателей вы сможете принять? Или просто посмотрите и огорчитесь?
▪️ Выдавать доступы к песочницам почти всем – дать им в руки BI с конструктором
Достаточно долго я так жил и работал, пока не так давно не возник следующий диалог с камрадом:
“
– Вы сколько на моделях в этом крупном направлении за год заработали?
– Ну, xxx млн.
– А у нас (компания Y) аналитики (!) за месяц столько же
– ???
“
Итак, суть кейса:
аналитики как обычно генерили свои смешные гипотезы, и в результате проверки одной из них выяснилось следующее: пару лет назад компания Y привлекала клиентов, предлагая им трехмесячную скидку. Аналитики выяснили что разрабы накосячили и скидки не отключились через 3 мес (!). То есть все такие клиенты до сих получают услуги по тем льготным тарифам. Дальше они взяли скоры от модели оттока и начали самым лояльным по этим скорам скидку отменять. Потихоньку, не сразу все базу.
Конечно, без DS они не обошлись (модель оттока все-таки наша), но сам факт!
В итоге мнение о дата-аналитиках и их полезности я сильно поменял. ☺️
Если у вас прикольные кейсы файндингов дата-аналитиков -- не держите в себе, поделитесь, пожалуйста в комментариях
Верно, речь пойдет про аналитиков
Несколько лет назад меня пригласили прочитать лекцию правлению одного крупного промышленного банка дружественной республики бывшего союза.
Задача была в духе как наладить дата-функцию так чтобы побыстрее с этого заработать, основной упор на кейсы, причем, кроме рисковых и бизнесовых, обсудили даже комплаенс и казну.
В банках вообще есть где развернуться в плане ML )
Много было вопросов по кейсам, но особенно живой интерес возник когда я сказал что аналитики им не нужны – мол, все равно вы не умеете ими пользоваться – что поделать, люблю чуть-чуть набросить 🤓.
Как я вижу работу дата-аналитика:
▪️ дизайн экспериментов / пост-эксперименты (блокинг, матчинг, каузальные выводы)
▪️ кейс-менеджмент
▪️ построение дерева метрик, исследование взаимного влияния метрик друг на друга
▪️ поиск прокси-метрик и прокси-событий
▪️ фин. модели для отмахивания от финансистов и аудиторов
Истории с прототипированием витрин, проверками данных, визуализации, первичную бизнес-валидацию – оставляю за DS, это обязательная и очень большая часть его работы
Истории с сегментацией / кластеризацией клиентской базы – свое отношение к таким “задачам” я в одном из первых постов высказал.
Как чаще всего используют аналитиков в компаниях, в которых продуктовая культура, скажем так, не особенно вызрела?
▪️ черная работа, которую не хочет делать DS / MLE / PO и остальные.
▪️ ad-hoc по велению левой пятки PO / CPO / любого другого манагера / канальи из соседнего отдела / управления / блока / департамента и пр. И суету создает и ЧСВ манагера растит.
И вот последнее отнимает 90-95% времени аналитиков.
Как с этим бороться? Обычно просто частотные запросы оформляют в дэш и берут на поддержку.
Еще были попытки text2sql, но тогда контекста моделей не хватало (да ис. бизнес-глоссариями было не так ровно как хотелось бы)
А как еще? (здесь каюсь, хорошая мысля приходит опосля – хоть я и боролся с ad-hoc, формализовать догадался только лишь потом):
▪️ Требовать дерево решений: вот насчитаю вам, уважаемый заказчик, требуемые показатели. Какие управленческие решения при каких значениях показателей вы сможете принять? Или просто посмотрите и огорчитесь?
▪️ Выдавать доступы к песочницам почти всем – дать им в руки BI с конструктором
Достаточно долго я так жил и работал, пока не так давно не возник следующий диалог с камрадом:
“
– Вы сколько на моделях в этом крупном направлении за год заработали?
– Ну, xxx млн.
– А у нас (компания Y) аналитики (!) за месяц столько же
– ???
“
Итак, суть кейса:
аналитики как обычно генерили свои смешные гипотезы, и в результате проверки одной из них выяснилось следующее: пару лет назад компания Y привлекала клиентов, предлагая им трехмесячную скидку. Аналитики выяснили что разрабы накосячили и скидки не отключились через 3 мес (!). То есть все такие клиенты до сих получают услуги по тем льготным тарифам. Дальше они взяли скоры от модели оттока и начали самым лояльным по этим скорам скидку отменять. Потихоньку, не сразу все базу.
Конечно, без DS они не обошлись (модель оттока все-таки наша), но сам факт!
В итоге мнение о дата-аналитиках и их полезности я сильно поменял. ☺️
Если у вас прикольные кейсы файндингов дата-аналитиков -- не держите в себе, поделитесь, пожалуйста в комментариях
ого, сегодня разоблачили крупную организацию каналий-иллюминатов-разрабов. Хм, что если все мои истории не случайны, и в DS/ ML она тоже есть? 🤔
PS: isDisabled() напомнило про криворуких проектировщиков таблиц с клиентами, которые заводят колонки "sex" или "gender" а потом ты гадаешь что значат {-1; 0; 1; 2}.
Крайне редко увидишь нормальное название -- is_male
PS: isDisabled() напомнило про криворуких проектировщиков таблиц с клиентами, которые заводят колонки "sex" или "gender" а потом ты гадаешь что значат {-1; 0; 1; 2}.
Крайне редко увидишь нормальное название -- is_male
Хабр
Заговор разработчиков против корпораций
Речь пойдет о тайной, сугубо анонимной организации, следы которой начал замечать еще в 2018-ом, работая в Яндексе. О целях и мотивах организации можно только догадываться: некоторые считают это...
Не могу не согласиться с автором вчерашней статьи, которую цитировал в посте в том что такая организация существует.
И вот эта картинка из нее – главная улика.
Встречали когда-нибудь в python ровно 8 😵 вложенных циклов for?
А мы с товарищем пару лет назад встретили 😆 Питонист, который не слышал про itertools.product это ж мистер Джон Ланкастер Пек.
А лет за пять до этого я реально встретил результат саботажа от такого же агента.
Искал я в одной из систем Transact SM Retail – для любознательных и знающих о какой компании речь – табличку с родственниками заемщиков.
Ничего не предвещало беды и таблица такая была – называлась Relatives.
Поля вот только в ней назывались:
И даже это не было страшно, ибо под рукой была расшифровка в excel (о нем мы еще поговорим), и там было прекрасное:
За номера в названиях колонок могу путаться, но описание именно такое
Да-да, 56 полей для 14 родственников, по каждому из которых хранится максимум 4 значения – и это если кто-то в анкете на кредит всех 14 указал (такие правда были, не знаю как фамилии в текстовое поле влезли правда).
Такой подход к формам нормализации оставил неизгладимое впечатление конечно.
И только сейчас я понял в чем же было дело …
И вот эта картинка из нее – главная улика.
Встречали когда-нибудь в python ровно 8 😵 вложенных циклов for?
А мы с товарищем пару лет назад встретили 😆 Питонист, который не слышал про itertools.product это ж мистер Джон Ланкастер Пек.
А лет за пять до этого я реально встретил результат саботажа от такого же агента.
Искал я в одной из систем
Ничего не предвещало беды и таблица такая была – называлась Relatives.
Поля вот только в ней назывались:
r268
r348
r6025
r452
…
И даже это не было страшно, ибо под рукой была расшифровка в excel (о нем мы еще поговорим), и там было прекрасное:
r268: dob родственника 1
r348: имя родственника 1
r6025: фамилия родственника 1
r452: отчество родственника 1
…
...
r281: имя родственника 14
r361: name of relative 14
r6038: фамилия родственника 14
r464: отчество родственника14
За номера в названиях колонок могу путаться, но описание именно такое
Да-да, 56 полей для 14 родственников, по каждому из которых хранится максимум 4 значения – и это если кто-то в анкете на кредит всех 14 указал (такие правда были, не знаю как фамилии в текстовое поле влезли правда).
Такой подход к формам нормализации оставил неизгладимое впечатление конечно.
И только сейчас я понял в чем же было дело …
Наброс-вопрос про DS в “продуктовых компаниях”.
Буду осознанно сгущать краски, представим что мир черно-белый
Никогда не понимал вот это вот “продуктовая компания”, “все является продуктом” (реально скрам уже в бухгалтерию внедрили) и как в этом всем должен работать и развиваться DS, строить карьеру, расти в ML. Это же анекдот – знания DS получают на каггле, при подготовке к собеседованиям и на халтурках (когда сам с нуля за мелкий прайс).
Вообще кстати на фразу “относись к продукту как к своему бизнесу” реагирую просто – participation in success есть? Нет? Ну тогда уже бегу, ага. Но сейчас все же про DS
Особенно часто DS работает где-нибудь в change, по условному scrum – там где много унижений и микроменеджмента (чего только ежедневные стендапы стоят – привет, столыпинский вагон; только представьте чтобы совет директоров или правление стоя совещалось – и почасовые оценки задач грумингом), а на выходе минимум 20% времени команды уходит на всякие “церемонии”, фасилитаторов и на переключение между встречами. Хотя и без меня на эту тему написано прилично
И вот бесконечный бег, который поделен на “спринты” и “супер-спринты” – фичу за фичей. А чтобы получить промоушен надо решить технически сложную задачу!
Погодите, а разве развитие продукта не про максимально эффективные решения? Типа вместо двух моделей сделаем одну, вместо модели сделаем бизнес-правило и пр. – если метрики на A/B почти одинаковые? Не каждое стат. значимое изменение метрики приводит к росту прибыли – и вроде как задача продакта вести хозяйство разумно. А что если в продукте нет сложных ML-задач? То есть ты делаешь все супер, но задачи “недостаточно сложные” чтобы тебя повысить?
И другой поинт – если ты живешь спринтами и задачами по 4 часа что ты там сложное решишь?
Явно такие мысли не только у меня – от мотивированных именно на ML стажеров и кандидатов частый запрос – а можно куда-нибудь в RnD? И не то чтобы эти ребята мечтают о карьере академиков и писать статьи, им просто не в кайф быть крысой в колесе.
И их можно понять.
Особенно когда они выгорают, а им предлагают максимум “ротацию” в аналогичного уровня сложности продукт – то есть шило на мыло. (Хотя инструмент ротации я очень люблю – он позволяет создавать конкуренцию между продактами за DS и работает на повышение окладов)
Где-то слышал (мб вранье) что скрам придумали для бадишопов – чтобы клиенты получали иллюзию максимального контроля за своими деньгами.
Еще стоит подумать что бывает когда продукт закрывают как неперспективный. Увольняться из компании? А если компания нравится?
Итак, что делать если ты в продуктовой компании, хочешь расти по карьере, но в ML а не в продакта? (а случаи когда DS был вынужден перейти в PO у меня перед глазами)
Свой ответ напишу в сл посте
Если кто знает правильный ответ -- велкам в каменты
Буду осознанно сгущать краски, представим что мир черно-белый
Никогда не понимал вот это вот “продуктовая компания”, “все является продуктом” (реально скрам уже в бухгалтерию внедрили) и как в этом всем должен работать и развиваться DS, строить карьеру, расти в ML. Это же анекдот – знания DS получают на каггле, при подготовке к собеседованиям и на халтурках (когда сам с нуля за мелкий прайс).
Вообще кстати на фразу “относись к продукту как к своему бизнесу” реагирую просто – participation in success есть? Нет? Ну тогда уже бегу, ага. Но сейчас все же про DS
Особенно часто DS работает где-нибудь в change, по условному scrum – там где много унижений и микроменеджмента (чего только ежедневные стендапы стоят – привет, столыпинский вагон; только представьте чтобы совет директоров или правление стоя совещалось – и почасовые оценки задач грумингом), а на выходе минимум 20% времени команды уходит на всякие “церемонии”, фасилитаторов и на переключение между встречами. Хотя и без меня на эту тему написано прилично
И вот бесконечный бег, который поделен на “спринты” и “супер-спринты” – фичу за фичей. А чтобы получить промоушен надо решить технически сложную задачу!
Погодите, а разве развитие продукта не про максимально эффективные решения? Типа вместо двух моделей сделаем одну, вместо модели сделаем бизнес-правило и пр. – если метрики на A/B почти одинаковые? Не каждое стат. значимое изменение метрики приводит к росту прибыли – и вроде как задача продакта вести хозяйство разумно. А что если в продукте нет сложных ML-задач? То есть ты делаешь все супер, но задачи “недостаточно сложные” чтобы тебя повысить?
И другой поинт – если ты живешь спринтами и задачами по 4 часа что ты там сложное решишь?
Явно такие мысли не только у меня – от мотивированных именно на ML стажеров и кандидатов частый запрос – а можно куда-нибудь в RnD? И не то чтобы эти ребята мечтают о карьере академиков и писать статьи, им просто не в кайф быть крысой в колесе.
И их можно понять.
Особенно когда они выгорают, а им предлагают максимум “ротацию” в аналогичного уровня сложности продукт – то есть шило на мыло.
Где-то слышал (мб вранье) что скрам придумали для бадишопов – чтобы клиенты получали иллюзию максимального контроля за своими деньгами.
Еще стоит подумать что бывает когда продукт закрывают как неперспективный. Увольняться из компании? А если компания нравится?
Итак, что делать если ты в продуктовой компании, хочешь расти по карьере, но в ML а не в продакта? (а случаи когда DS был вынужден перейти в PO у меня перед глазами)
Свой ответ напишу в сл посте
Если кто знает правильный ответ -- велкам в каменты
Please open Telegram to view this post
VIEW IN TELEGRAM
(2/2)
И необходимость такой структуры – такой же закон физики как невозможность встать со стула, не подавшись корпусом вперед – попробуйте, кстати.
Отсюда следует вывод 2: кому-то в компании тоже должен быть нужен ваш рост, не только вам
И этим кем-то может выступать не только матричный руководитель, но и CPO / PO!
Когда такое бывает? Когда его продукт растет и внутри выделяются продукты помельче, туда надо нанимать команды, и это ваш шанс вырасти из синьора в лида и из тимлида в руководителя направления (CDO, например) или заняться RnD для такого крупного продукта.
Вывод 3: выбирать продукт относясь к нему как к инвестиции собственного времени, – выбирать тот, который вырастет, где возможно открытие новых бизнес-линий.
И вот этот способ (расти вместе с правильно выбранным продуктом) самый простой – прилив поднимает все лодки.
Остальные потребуют либо смену продукта – а это не очень-то и отличается от смены работы, либо вовлечение матричных руководителей и целеполагание уже от них (а с двумя руководителями работать сложнее чем с одним).
Здесь кому что нравится – кому-то нравится в продукте сидеть, мне нравится проектная работа с понятным результатом в понятный срок.
И необходимость такой структуры – такой же закон физики как невозможность встать со стула, не подавшись корпусом вперед – попробуйте, кстати.
Отсюда следует вывод 2: кому-то в компании тоже должен быть нужен ваш рост, не только вам
И этим кем-то может выступать не только матричный руководитель, но и CPO / PO!
Когда такое бывает? Когда его продукт растет и внутри выделяются продукты помельче, туда надо нанимать команды, и это ваш шанс вырасти из синьора в лида и из тимлида в руководителя направления (CDO, например) или заняться RnD для такого крупного продукта.
Вывод 3: выбирать продукт относясь к нему как к инвестиции собственного времени, – выбирать тот, который вырастет, где возможно открытие новых бизнес-линий.
И вот этот способ (расти вместе с правильно выбранным продуктом) самый простой – прилив поднимает все лодки.
Остальные потребуют либо смену продукта – а это не очень-то и отличается от смены работы, либо вовлечение матричных руководителей и целеполагание уже от них (а с двумя руководителями работать сложнее чем с одним).
Здесь кому что нравится – кому-то нравится в продукте сидеть, мне нравится проектная работа с понятным результатом в понятный срок.
почему статья про обезьянку до сих пор актуальна, поясняет опытный работник:
Telegram
Дата канальи — про «специалистов» в данных / ML / AI
По мотивам обсуждения в прошлом посте -- статья из HBR 2004 1974 года менеджер и его время (которая про обезьянку)
Forwarded from мы вам перезвоним
This media is not supported in your browser
VIEW IN TELEGRAM
Сотрудница поделилась секретной техникой, которая способна убрать все правки и лишние задачи от твоего босса вмиг.
Пользуемся.
Пользуемся.
В комментариях к этому посту попросили поделиться ссылками на антифрод, их есть у меня
Прям в цельную картинку вместе они собраны в курсе ML в бизнесе, но здесь поделюсь кусочками, из которых она состоит.
А для совсем начинающих – хендбук
Как вообще устроен антифрод (на примере фин. мониторинга):
1. Правила (известные схемы, например из профильных обнальных тг-чатов -- для обнала: распыление, слом назначения платежа, вексели, слом ндс, транзит и пр) и экспертные модели (регрессии на известных фичах -- доли контрагентов, коэффициента налоговой нагрузки, корп карты, учредитель - подставное лицо и пр.). Известные фичи "ломаются" уже со стороны нарушителя -- например, КНН можно увеличить отправляя ошибочные платежки в налоговую и получая возвраты
2. Модели (supervised модели, построенные по отловленным правилами и руками кейсам). Здесь тоже работает PseudoLabelling. Но и фродеры не стоят на месте, на это намекал в самом первом посте
3. Кейс-менеджмент и эксперты (разбор найденных примеров, новых схем, мотивированное суждение). Разбор кейса может занимать, например, 2 недели, включая запрос документов от клиента
4. Exploration -- unsupervised -- outlier detection -- наша задача найти несколько десятков примеров, передать их на разбор, сделать supervised модель
5. Мониторинг качества работы и схем и отдельных фичей, симуляции новых схем атак
Мониторинг мошеннических заявок на кредит, определение компаний, искажающих финансовую отчетность -- все это тоже про антифрод.
На Forex вообще фродовыми считаются клиенты, которые выживают и выводят деньги.
Таргетом может быть как компания / физик так и конкретная сомнительная транзакция.
Итак, сами материалы
Поиск аномалий в табличках (для того чтобы быстро разные алгоритмы перебрать):
1. PYOD – база, даже вариационный автоэнкодер включили (вообще автоэкнодеры в разных формах полезны в этих задачах)
2. PYTOD – ускоренная версия (за счет использования GPU) – вообще большинство классических алгоритмов редко применяют из-за того что они очень медленные, мне нравится Isolation Forest из всех, но перебирать всегда приходится несколько
Здесь важно сделать отступление – что для многих классических алгоритмов придется как-то умозрительно задать ожидаемую долю аномалий, что не очень удобно. По факту нам интереснее ранжирование на более аномальные и менее – а дальше сколько мы возьмем будет зависеть от цены ошибки в каждом кейсе и мощности офицеров чтобы эти кейсы руками разобрать и подтвердить.
Поиск аномалий на транзакциях:
1. PYGOD– смотрим на задачу как на поиск аномалий в графах (и то, насколько аномалия должна быть более структурной чем контекстной – необучаемый параметр в лоссе), здесь в основном графовые автоэнкодеры
Но это прям затравочка, тема популярная, плюс графы меняются по времени (и структура и свойства вершин / ребер), даже на последнем NIPS (а это декабрь) показали новый алгоритм поиска аномалий на графах UniGAD. И еще на KDD’24 (сам еще не успел прочесть читал, но denoising диффузионка звучит как что-то интересное)
Подборка актуальных статей по теме
2. PTLS от Sber AI лабы сначала ssl-эмбеддим транзакции, потом закидываем в табличные методы
Если уже нашли и даже добились какой-то разметки, но единичек не очень много сотни), то помогает pseudolabelling– строите график того как метрика (обычно recall) зависит от того, с какого порога предикты единичек первой моделью досыпать в трейн второй. Выбираете порог, максимизирующий recall -- не панацея конечно, но до +10% полноты получалось выжимать.
Ну и supervised – здесь относительно понятно, кроме того на какой event rate калиброваться, да и надо ли )
Прям в цельную картинку вместе они собраны в курсе ML в бизнесе, но здесь поделюсь кусочками, из которых она состоит.
А для совсем начинающих – хендбук
Как вообще устроен антифрод (на примере фин. мониторинга):
1. Правила (известные схемы, например из профильных обнальных тг-чатов -- для обнала: распыление, слом назначения платежа, вексели, слом ндс, транзит и пр) и экспертные модели (регрессии на известных фичах -- доли контрагентов, коэффициента налоговой нагрузки, корп карты, учредитель - подставное лицо и пр.). Известные фичи "ломаются" уже со стороны нарушителя -- например, КНН можно увеличить отправляя ошибочные платежки в налоговую и получая возвраты
2. Модели (supervised модели, построенные по отловленным правилами и руками кейсам). Здесь тоже работает PseudoLabelling. Но и фродеры не стоят на месте, на это намекал в самом первом посте
3. Кейс-менеджмент и эксперты (разбор найденных примеров, новых схем, мотивированное суждение). Разбор кейса может занимать, например, 2 недели, включая запрос документов от клиента
4. Exploration -- unsupervised -- outlier detection -- наша задача найти несколько десятков примеров, передать их на разбор, сделать supervised модель
5. Мониторинг качества работы и схем и отдельных фичей, симуляции новых схем атак
Мониторинг мошеннических заявок на кредит, определение компаний, искажающих финансовую отчетность -- все это тоже про антифрод.
На Forex вообще фродовыми считаются клиенты, которые выживают и выводят деньги.
Таргетом может быть как компания / физик так и конкретная сомнительная транзакция.
Итак, сами материалы
Поиск аномалий в табличках (для того чтобы быстро разные алгоритмы перебрать):
1. PYOD – база, даже вариационный автоэнкодер включили (вообще автоэкнодеры в разных формах полезны в этих задачах)
2. PYTOD – ускоренная версия (за счет использования GPU) – вообще большинство классических алгоритмов редко применяют из-за того что они очень медленные, мне нравится Isolation Forest из всех, но перебирать всегда приходится несколько
Здесь важно сделать отступление – что для многих классических алгоритмов придется как-то умозрительно задать ожидаемую долю аномалий, что не очень удобно. По факту нам интереснее ранжирование на более аномальные и менее – а дальше сколько мы возьмем будет зависеть от цены ошибки в каждом кейсе и мощности офицеров чтобы эти кейсы руками разобрать и подтвердить.
Поиск аномалий на транзакциях:
1. PYGOD– смотрим на задачу как на поиск аномалий в графах (и то, насколько аномалия должна быть более структурной чем контекстной – необучаемый параметр в лоссе), здесь в основном графовые автоэнкодеры
Но это прям затравочка, тема популярная, плюс графы меняются по времени (и структура и свойства вершин / ребер), даже на последнем NIPS (а это декабрь) показали новый алгоритм поиска аномалий на графах UniGAD. И еще на KDD’24 (сам еще не успел прочесть читал, но denoising диффузионка звучит как что-то интересное)
Подборка актуальных статей по теме
2. PTLS от Sber AI лабы сначала ssl-эмбеддим транзакции, потом закидываем в табличные методы
Если уже нашли и даже добились какой-то разметки, но единичек не очень много сотни), то помогает pseudolabelling– строите график того как метрика (обычно recall) зависит от того, с какого порога предикты единичек первой моделью досыпать в трейн второй. Выбираете порог, максимизирующий recall -- не панацея конечно, но до +10% полноты получалось выжимать.
Ну и supervised – здесь относительно понятно, кроме того на какой event rate калиброваться, да и надо ли )
Кейс про два стула для кластер-лида
Вызывает как-то шеф к себе — говорит:
«
— Надо сделать модель рекомендации кредитной ставки, выбери кто делать будут — К или Ш (два крупных подразделения)
— А чего мы сами не сделаем, фин эффект себе не запишем?
— А я уже им пообещал
— А кому ты пообещал?
— И тем и тем, ты уж как-нибудь разберись и выбери одних 🤡👏»
Мало того что если выбрать кого-то из этих двух структур, другая к тебе повернется отнюдь не лицом и на существенный срок – все из-за дележки фин эффектов. Причем подкузьмить могут недурно обе башни – через Ш вводятся ставки, а через финансистов (братьев К) защищаются эффекты.
Естественно они ни в какую не хотели данными делиться ни с кем — у одних были данные по нормативной валовой марже по отраслям, по кредитным договорам — а у других реальные финансовые потоки, модель досрочного гашения кредита и всякое полезное иное.
Попытка предложить им сделать две модели и объединить результаты тоже была принята в штыки, посыпались звонки шефу от уважаемых вице-президентов.
Ну тогда по заветам известной байки про Шваба с куском мела договариваемся что в пром ставим ту модель где ошибка на тесте меньше. И в срок 2 мес нужны предикты на тестовый период, мол, метрики мы сами насчитаем – для объективности. Каждая команда уходит строить модель на своих данных.
Проходит 4 месяца и команды возвращаются. До конца года осталось не то чтобы сильно много. Снова предлагаю объединить скоры – шум, гам, обозвали волюнтаристом 🤥. Ну ок, у нас есть дисперсия каждой модели на тесте, давайте попробуем хоть на пальцах прикинуть сколько будет A/B идти. Заодно-таки построим самую примитивную общую модель – с весами сложить предикты команд. В чем суть A/B (на самом деле A/B/C): мы рекомендуем ставку кредита клиентщику для переговоров (давая текстовое описание почему она именно такая), если в группе удается маржу хотя бы на 0.1% в среднем поднять то это сотни миллионов дохода, но сравниваемся мы не только с теми, кому рекомендацию модели не показываем, но и с теми, кому показываем рандомные +0.1% – 0.5% накинуть к нормативной марже.
Считаем с поправками, подбираем сиды везде где только можно, и выходим на нужные числа (сработали не хуже Росстата): если модели не объединять (используя нашу в тч) то до конца года не успеем провести тест и защитить эффект.
Пришлось модели все-таки объединить и эффект на три подразделения делить поровну (ага, и мы кусочек получили) 😝. То же не без битвы -- "а давайте по человеко-часам считать", "а давайте пропорционально аплифту к метрике на тесте" и т.д. Но когда в доме пожар, обсуждение чья очередь мыть посуду не то что бы сильно затягивается 🤓
Поэтому как менеджер не верю я в "великих переговорщиков" и достижимость win-win по-джентельменски, на берегу -- если вопрос действительно чувствительный и интерес вполне себе корыстный, то в корпорации скорее закон джунглей действует, а окно для того чтобы договориться по-человечески появится когда уже совсем деваться некуда будет. Важен только момент времени и критичность ситуации.
Вызывает как-то шеф к себе — говорит:
«
— Надо сделать модель рекомендации кредитной ставки, выбери кто делать будут — К или Ш (два крупных подразделения)
— А чего мы сами не сделаем, фин эффект себе не запишем?
— А я уже им пообещал
— А кому ты пообещал?
— И тем и тем, ты уж как-нибудь разберись и выбери одних 🤡👏»
Мало того что если выбрать кого-то из этих двух структур, другая к тебе повернется отнюдь не лицом и на существенный срок – все из-за дележки фин эффектов. Причем подкузьмить могут недурно обе башни – через Ш вводятся ставки, а через финансистов (братьев К) защищаются эффекты.
Естественно они ни в какую не хотели данными делиться ни с кем — у одних были данные по нормативной валовой марже по отраслям, по кредитным договорам — а у других реальные финансовые потоки, модель досрочного гашения кредита и всякое полезное иное.
Попытка предложить им сделать две модели и объединить результаты тоже была принята в штыки, посыпались звонки шефу от уважаемых вице-президентов.
Ну тогда по заветам известной байки про Шваба с куском мела договариваемся что в пром ставим ту модель где ошибка на тесте меньше. И в срок 2 мес нужны предикты на тестовый период, мол, метрики мы сами насчитаем – для объективности. Каждая команда уходит строить модель на своих данных.
Проходит 4 месяца и команды возвращаются. До конца года осталось не то чтобы сильно много. Снова предлагаю объединить скоры – шум, гам, обозвали волюнтаристом 🤥. Ну ок, у нас есть дисперсия каждой модели на тесте, давайте попробуем хоть на пальцах прикинуть сколько будет A/B идти. Заодно-таки построим самую примитивную общую модель – с весами сложить предикты команд. В чем суть A/B (на самом деле A/B/C): мы рекомендуем ставку кредита клиентщику для переговоров (давая текстовое описание почему она именно такая), если в группе удается маржу хотя бы на 0.1% в среднем поднять то это сотни миллионов дохода, но сравниваемся мы не только с теми, кому рекомендацию модели не показываем, но и с теми, кому показываем рандомные +0.1% – 0.5% накинуть к нормативной марже.
Считаем с поправками, подбираем сиды везде где только можно, и выходим на нужные числа (сработали не хуже Росстата): если модели не объединять (используя нашу в тч) то до конца года не успеем провести тест и защитить эффект.
Пришлось модели все-таки объединить и эффект на три подразделения делить поровну (ага, и мы кусочек получили) 😝. То же не без битвы -- "а давайте по человеко-часам считать", "а давайте пропорционально аплифту к метрике на тесте" и т.д. Но когда в доме пожар, обсуждение чья очередь мыть посуду не то что бы сильно затягивается 🤓
Поэтому как менеджер не верю я в "великих переговорщиков" и достижимость win-win по-джентельменски, на берегу -- если вопрос действительно чувствительный и интерес вполне себе корыстный, то в корпорации скорее закон джунглей действует, а окно для того чтобы договориться по-человечески появится когда уже совсем деваться некуда будет. Важен только момент времени и критичность ситуации.
Очередной пост не вмещался в тг, опубликовал его на хабре и нахватал минусов в карму 😄 upd: а нет, все хорошо
Хабр
Зачем в Look-a-like pseudolabelling (или самый простой метод PU-learning на службе у рекламщиков)
Готовил семинар студентам и почему-то нигде не могу найти этот простой и действенный способ именно в контектсе Look-a-Like (если не прав -- поделитесь, пожалуйста, в комментариях ссылкой)....
Интересная в Яндексе в ecom культура — требовать от сотрудников личную телегу показывать, хорошо пока на конюшне барин не порет.
Как он так умудрился выстроить коммуникации с командой, что у каждого десятки непонятных p2p запросов в день вообще неясно. Могу погадать что там нет либо закрепленных зон ответственности, либо документации, либо всего вместе.
В любом случае лезть в личные телефоны сотрудников -- это неадекват
Как он так умудрился выстроить коммуникации с командой, что у каждого десятки непонятных p2p запросов в день вообще неясно. Могу погадать что там нет либо закрепленных зон ответственности, либо документации, либо всего вместе.
В любом случае лезть в личные телефоны сотрудников -- это неадекват
Forwarded from Media Rare
Крик души - почему столько людей позволяют на работе не отвечать другим в тот же день и просто оставлять непрочитанные?
Сталкиваюсь с этим даже в своей команде, когда просишь показать людей телеграмм и там видно, как десятки входящих даже в личку, а не чатах..просто...игнорируются.. А ведь хороший менеджер все равно потом проэскалирует наверх, партнер найдет личный контакт генерального директора, а контрагент еще и позвонит.. И все это потому что кому-то просто было лень за 15 секунд прочитать входящеее и форвраднуть быстро куда следует.
Тут уже делал гайд, как исправиться :) Недавно на встрече прямых по очереди попросил открыть свои телеги и показать unread - в шоке увидел, что половина людей не соблюдает 0inbox >_<
@media_rare
Сталкиваюсь с этим даже в своей команде, когда просишь показать людей телеграмм и там видно, как десятки входящих даже в личку, а не чатах..просто...игнорируются.. А ведь хороший менеджер все равно потом проэскалирует наверх, партнер найдет личный контакт генерального директора, а контрагент еще и позвонит.. И все это потому что кому-то просто было лень за 15 секунд прочитать входящеее и форвраднуть быстро куда следует.
Тут уже делал гайд, как исправиться :) Недавно на встрече прямых по очереди попросил открыть свои телеги и показать unread - в шоке увидел, что половина людей не соблюдает 0inbox >_<
@media_rare
Telegram
Media Rare
#менеджмент #лайфхаки
0 inbox и как этого добиться
У меня много лет непреложное правило, что минимум 2 раза в день есть 0 inbox во всех мессенджерах и корпоративной почте. Утром - пока сидишь ⡆⢐ ⠴⠌⠦⠚⠙⠌⡰, пьешь кофе, собираешься на работу и приводишь мысли…
0 inbox и как этого добиться
У меня много лет непреложное правило, что минимум 2 раза в день есть 0 inbox во всех мессенджерах и корпоративной почте. Утром - пока сидишь ⡆⢐ ⠴⠌⠦⠚⠙⠌⡰, пьешь кофе, собираешься на работу и приводишь мысли…
В тему каналий-манагеров и их компетенций.
Если с организационными способностями и операционным управлением все на поверхности – достаточно одного показательного поста, то как насчет других компетенций?
Возьмем крайний случай – “умение разбираться в людях”.
Всегда недоумевал – как за получасовую / часовую встречу сделать хоть сколько-нибудь точный прогноз вроде того будет ли человек вообще работать, надежный ли он, интересно ли ему то, чем он занимается, будет ли он развиваться в этой области и много-много других выводов.
К счастью, я больше не встречаю у HR в заметках после собеседований “лапуля нормис”, но вот длинные трактаты далекоидущими выводами с часовой встречи, на которым был еще и продакт, а hr задала всего пару вопросов – регулярно. И это прям устоявшаяся мировая практика, целые курсы продают как на такие вопросы отвечать. Осенью я даже потратил пару вечеров чтобы запилит англоязычного бота-тренера который сэмплит тебе вопрос (по которому можно подсказку посмотреть), ты голосовым надиктовываешь ответ, а он дает фидбек – что хорошо, что улучшить – а где красные флаги. Если интересно – ставьте палец вверх, скину в одном из следующих постов.
И вот на днях друг и говорит – “А чему ты удивляешься? Ты вот ml ботал и инженерию всякую, а другие ботали как за 5 секунд понять кто перед тобой и получали в этом опыт”. В тот момент я крепко задумался. Честно говоря, к книгам вроде творчества Алана Пиза я относился примерно как к гомеопатии и заряжанию банок, но мб я просто слишком буквально все воспринимаю?
Помню был сериал “Lie to me” c Тимом Ротом – но будем честны, разве средняя hr по зуму повторяет все приемы-фокусы оттуда?
Поделитесь, пожалуйста, что вы и ваши знакомые используют чтобы понять стоит с человеком работать / связываться / иметь дело или нет?
Это можно заботать? Есть какие-то прям учебники на базе исследований? Какие-то тесты?
Если с организационными способностями и операционным управлением все на поверхности – достаточно одного показательного поста, то как насчет других компетенций?
Возьмем крайний случай – “умение разбираться в людях”.
Всегда недоумевал – как за получасовую / часовую встречу сделать хоть сколько-нибудь точный прогноз вроде того будет ли человек вообще работать, надежный ли он, интересно ли ему то, чем он занимается, будет ли он развиваться в этой области и много-много других выводов.
К счастью, я больше не встречаю у HR в заметках после собеседований “лапуля нормис”, но вот длинные трактаты далекоидущими выводами с часовой встречи, на которым был еще и продакт, а hr задала всего пару вопросов – регулярно. И это прям устоявшаяся мировая практика, целые курсы продают как на такие вопросы отвечать.
И вот на днях друг и говорит – “А чему ты удивляешься? Ты вот ml ботал и инженерию всякую, а другие ботали как за 5 секунд понять кто перед тобой и получали в этом опыт”. В тот момент я крепко задумался. Честно говоря, к книгам вроде творчества Алана Пиза я относился примерно как к гомеопатии и заряжанию банок, но мб я просто слишком буквально все воспринимаю?
Помню был сериал “Lie to me” c Тимом Ротом – но будем честны, разве средняя hr по зуму повторяет все приемы-фокусы оттуда?
Поделитесь, пожалуйста, что вы и ваши знакомые используют чтобы понять стоит с человеком работать / связываться / иметь дело или нет?
Это можно заботать? Есть какие-то прям учебники на базе исследований? Какие-то тесты?