#кейсы #ML

Кстати про технические сложности
Вспомнился старый кейс, где я вовсю ощутил свой недостаток образования в Computer Science.

В далеком кризисе 2014 года меня приютила одна по доброте душевной (а там правда очень классные люди) компания, которая разрабатывала софт для нефтяной сейсмики. У Яндекса там была существенная доля и хорошее отношение – которое выражалось, например в том что компания называлась Яндекс.Терра, а сотрудники могли быть слушателями ШАД.

Разработка на C/ С++ это вот ни разу не python или Matlab (мой основной иснтрумент тогда), и я в нее не умел (о чем честно сказал на входе). А задачи были – писать модули для той большой системы, и на старте мне дали достаточно простые – одноканальная обработка сигналов, всякие фильтрации/свертки, немного со спектрами и кепстрами.

И как-то мне нужно было пройтись по спектру с шагом 0.1 Гц, что-то сделать, а затем к результату применить обратное Фурье. Только вот не всегда результат обратного преобразования Фурье будет вещественнозначным ) Поэтому делать надо было аккуратно, с первого раза в C не получилось. Списав все на свои кривые руки, решил сделать в матлабе. И там волшебным образом все заработало!

Несколько дней я потратил, пытаясь добиться того же результата в C – без шанса 🙈🤯.
В матлабе же не только индексация массивов отличается)
В итоге пошел на поклон к синьору и тут вскрылся мой недостаток образования на тот момент в CS. Что-то о свойствах вещественных чисел я знал (что на равенство сравнивать нельзя, ибо хранятся они в некотором приближении), но вот глубоко не копал – на чем и погорел.

В чем же была проблема?
Как это выглядело в Matlab:

d = 0;
for i = 1:10000
    d = d + 0.1;
end
fprintf('%.25f', d)
>>> 1000.0000000001588205122970976

Аналогично на python:

d = 0
for i in range(10_000):
    d += 0.1
print(d)
>>> 1000.0000000001588

И вот то же самое (на самом деле нет) на C:

  
   float d = 0;
   for (int i = 0; i < 10000; ++i)
   {
       d += 0.1;
   }
   printf("%.6f", d);
>>> 999.902893

Дело было в том что 0.1 в двоичном виде непредставима как конечная дробь, только как периодическая. А с ограничением точности (float против double, который по умолчанию в python) при суммировании ошибка накопилась и достигла настолько существенных величин, что обратное Фурье становилось комплексным 😱.

PS как-то у коллеги видел очень похожую ситуацию в python (только там он при чтении из файла во float сохранил), уже в 16м, подсказал – помогло.
А копать с тех пор стараюсь поглубже 🪆

#ML

в соседнем канале в качестве решения кейса предложили Kahan summation algorithm, интересная штука

#корпжиза

Очередной собес на лида, или как не стать лидом из синьора

На одном из крупных продуктов жил-был CDO, который хороводил и DS и аналитиков и DE. И в подмогу нужен был молодой лид / вчерашний синьор, который мог бы потихоньку начать разгружать 🤝. Ставка была лидовская, но рассматривали и синьоров, ибо CDO готов был вложиться в развитие.

И вот после пары этапов приходят HR что нужно подключиться на финальный собес с CDO, ибо есть у участников процесса сомнения “по его софтам”, что бы это ни значило. Как всегда на финальном собеседовании с лидами HR с нами, во встречу вложено резюме, глаз цепляется за “в подчинении команда из 2-х Junior DS” 🤴, ну ладно, мб формулировка неудачная.

Итак, цель встречи – понять, насколько кандидат самостоятелен сам и насколько способен организовать команду. За тройку месяцев до этого кандидат собесился к нам на синьора, но в процессе передумал и заявил HR что “рассматривает минимум позицию тимлида”. Ну ок, как раз позиция лида открылась.
.
Начинаем общаться с кандидатом и выясняем что “каждое утро я докладываю начальнику чем сегодня я и подчиненные DS будут заниматься и что сделали вчера, получаю новые вводные” 🤓.
Пытаемся выяснить все же какие решения принимал сам кандидат. Свелось к посещаемости офиса (можно отпустить сотрудника на конференцию на день если сам за него готов в случае чего эту задачу закрыть). Пытаемся выяснить как общение с заказчиком происходит, как со смежниками – ответ расстраивает. Какие планы расти на текущем месте? “-- Спрошу начальника…”.
Видно, собеседование не клеится, кандидатм расстраивается, нам тоже обидно, ну да ладно 😔. Даем какой-никакой фидбек (хоть и не просили), но лучше взять самостоятельного синьора чем несамостоятельного лида.

Так вот, кроме как уметь в problem solving, руководителю надо уметь быть самостоятельным (еще это называется лидерской позицией) – то есть иметь свою полноценную зону ответственности, свой план развития не только по карьере в целом, но и на конкретной позиции в конкретной компании, иметь план развития своего подразделения – куда мы идем, зачем, как выглядит успех.

Самый логичный и простой способ вырасти – наращивать свою зону ответственности – ту, где на вас полностью делегируют и спрашивают только за конечный результат. Чем меньше вам требуется одобрений и согласований, чем шире вы смотрите на задачу и чем шире используете арсенал средств для ее решения, тем больше шансов что команда у вас возникнет естественным путем без неловких разговоров 😐.

[пафос on] Менеджмент начинается с себя. [\пафос off]

PS А может это особеность культуры? 🤔 Хотеть аппрувов и бояться ответсвенности.

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

#корпжиза

По мотивам обсуждения в прошлом посте -- статья из HBR 2004 1974 года менеджер и его время (которая про обезьянку)

#кейсы #ML

Продолжая тему культуры аппрувов и самостоятельности
Часто она идет вкупе с уважением к авторитетам, и на сей счет есть кейс, который каждый год (аж два) рассказываю студентам на модуле графовых нейронок в магистратуре физтеха.

Когда опубликовали идею attention, ее сразу же начали пытаться добавлять всюду – и стороной не обошли и графовые свертки.

Итак, 30 октября на архив выкладывают короткую статью Graph Attention Networks. Все бы ничего, но в авторах есть сам великий Yoshua Bengio 🥸!!!

И реализацию статьи добавляют в прекрасный Pytorch Geometric под именем GATConv.

Все бы ничего, но работает эта штука не то чтобы очень.
А все почему? Attention реализовали в виде линейного слоя после линейного слоя 😆😆😆😆. Да, без нелинейности между ними 😂😂😂 А чему учат на первом занятии по DL? Тому что два линейных слоя подряд – снова линейный слой!

Лишь спустя 4 😱 года — в 2021 — на архив выкладывают статью с аккуратным названием How Attentive are Graph Attention Networks?, где ни в коем случае не утверждается что мэтр с командой ошиблись.

Только посмотрите на образец дипломатичной формулировки:

However, in this paper we show that GAT computes a very limited kind of attention: the ranking of the attention scores is unconditioned on the query node. We formally define this restricted kind of attention as static attention and distinguish it from a strictly more expressive dynamic attention

Опытные ребята! 🏆

Исправленную графовую свертку с вниманием назвали не мудрствуя лукаво GATv2Conv. 😄

И если на собесе забудете формулу KQV-attention (которое self), расскажите эту историю про другой механизм реализации идеи внимания, посмеетесь вместе с интервьюером 😁

Статьи про типичные ошибки в DS / ML реально такие

Даже не знаю как такие вакансии комментировать ...

Что мы ожидаем:
✅ Готовность работать в офисе, в СПб.
✅ Опыт работы с AI и глубоким обучением, понимание основ NLP, CV, ASR или TTS.
✅ Уверенные навыки работы с TensorFlow или PyTorch.
✅ Знание C++, Java, Scala и методов параллельных вычислений (CUDA, MPI).
✅ Английский на уровне для работы с документацией и общения.
✅ Приветствуется опыт в крупных технологических компаниях или участие в исследовательских проектах.

AI engineer
200 000 – 800 000 ₽/месяц
Офис, Фултайм

Ищем опытного специалиста в области AI и Machine Learning для работы над передовыми технологиями в области крупных языковых моделей, оптимизации и ускорения вычислений…(читать далее)

#кейсы #ML

Все же самостоятельность и ответственность не нужно путать с безнадзорностью 🤡

Очередное собеседование на лида
Приходит парень – уверенно держится 😎, лидит команду из 5-6 человек в мелкой конторке, делают скоринги (вроде в мфо или для мфо – в общем что-то такое).

Тогда еще не было выстроено какого-то процесса, в общем, это первое собеседование у кандидата в наш департамент.
И речь заходит про саму задачу, как модель используется в процессе, куда они с командой развиваются, как делают модели и такое всякое.
У лидов распространенная тактика на собеседованиях – уходить от технических вопросов, переходя в агрессивное наступление с тезисом а-ля “ты что сам не знаешь как модели строить? Зачем об этом говорить?” 😤 и выворачивая диалог в какую-то актуальную и потенциально выгодную себе сторону. Кто-то это делает наоборт по-панибратски, типо с подимигиванием "ну мы же тут начальнички над землекопами, чего нам в этом хламе ковыряться" 😉.

И вот здесь я услышал незабываемое “я ж не колхозник какой, по одной статье в неделю читаю и мы все внедряем” 🤔🙈.

Далее следует совсем нетарантиновский диалог:

– Реализация какой статьи дала наибольший эффект в вашей задаче?
– Название не помню, но мы фото заемщика добавили в модель и получили +5 Gini
– У вас же бустинги?
– Ну да, добавляет же.
– Мб вы какие-то свертки делали?
– Нет, мы взяли готовую сетку и ее добавили в бустинг.
– Предикты от нее?
– Ну да
– А на что учили?
– На тот же таргет
– А на что были в итоге похожи обученные фильтры? (мне прям дико было интересно что выучила модель – мб там на фото дефолтников вообще лиц не было?)
– Чо? Она джини добавляет, что непонятного?

В этот момент мне стало очень жаль ребят, которых он лидит 🥺🤯.

Поэтому внешний ассессмент действительно очень-очень важен – выступайте на митапах и конференциях, получайте развивающий фидбек, спршивайте в профильных чатах (а их буквально по одному на каждую задачу – например, @ods_recommender_systems, @speech_recognition_ru и пр.), участвуйте в разных проектах в разных командах.
Здесь конечно удобнее и приятнее быть в большой компании – и больше шансов эксперта найти, и больше шансов на ротацию.

Но, в конце концов, мы не на необитаемом острове 🏝 живем, чего-то не знать – не зазорно, зазорно – не спросить.

#кейсы #корпжиза

Кто должен был быть в первых рядах приемки модели предыдущего кандидата и задавать ему каверзные вопросы?

Верно, речь пойдет про аналитиков

Несколько лет назад меня пригласили прочитать лекцию правлению одного крупного промышленного банка дружественной республики бывшего союза.
Задача была в духе как наладить дата-функцию так чтобы побыстрее с этого заработать, основной упор на кейсы, причем, кроме рисковых и бизнесовых, обсудили даже комплаенс и казну.
В банках вообще есть где развернуться в плане 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

#кейсы #ML

Не могу не согласиться с автором вчерашней статьи, которую цитировал в посте в том что такая организация существует.
И вот эта картинка из нее – главная улика.

Встречали когда-нибудь в python ровно 8 😵 вложенных циклов for?

А мы с товарищем пару лет назад встретили 😆 Питонист, который не слышал про itertools.product это ж мистер Джон Ланкастер Пек.

А лет за пять до этого я реально встретил результат саботажа от такого же агента.
Искал я в одной из систем Transact SM Retail – для любознательных и знающих о какой компании речь – табличку с родственниками заемщиков.
Ничего не предвещало беды и таблица такая была – называлась 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 у меня перед глазами)

Свой ответ напишу в сл посте

Если кто знает правильный ответ -- велкам в каменты

#корпжиза
Напишу свой ответ на:

Итак, что делать если ты в продуктовой компании, хочешь расти по карьере, но в ML а не в продакта? (а случаи когда DS был вынужден перейти в PO у меня перед глазами)

Осторожно, длиннопост (1/2)

Но сначала – кейс с собеседования, который, кмк, очень показателен.
Приходит девушка, говорит что занимается антифродом. Тема мне очень интересна и сделать можно много всего – там есть место и unsupervised задачам – завести автоэнкодер (в тч и графовый) чтобы выявить нетипичные ноды, и semi-supervised (потому как разметки мало здесь вполне на практике работает pseudolabelling), и supervised задачи тоже не тривиальные, особенно, если схем фрода много, а емкость проверки / доразметки ограничена.

Про pseudolabbeling в антифроде видимо надо отдельно будет писать – для меня это был переломный момент моего отношению к кагглу, хорошо что в моей команде был мастер на тот момент – и вот его прямые руки заставили этот прием нам здорово помочь (Азат, привет).

И вот она говорит – ну мне давали выборку с фичами, давали таргеты, я делала фит-предикт и отдавала. Тем и жили.

Спрашиваю – ну ок, вы два года вроде как занимались антифродом как вы утверждаете, по факту фит-предикт потому как вы работаете не inhouse, а в конторе, которая делает такие модели на заказ. Но мб вы знаете как вообще задачи антифрода решаются? Какие есть проблемы и приемы?

Итогом стала жалоба в HR на меня за то что я “подверг сомнению компетенции”. Но неудивительно, ведь девушка и правда была о себе высокого мнения – успела пару месяцев где-то в Европе поработать (аж за 800 евро / мес).

Почему сложилась такая ситуация?
Потому что ее компания (а в случае корпорации это был бы “продукт”) не имел запроса что-то менять. Бизнес есть, он отлажен, бери больше, кидай дальше.
В таких условиях вряд ли стоит ожидать какого-то ресурса и искреннего интереса компании в RnD или тестировании сложных решений. Не сформулирована такая бизнес-потребность.

Итого, мы имеем:
▪️ задачи атомарные и однотипные, их трудоемкость можно точно оценить
▪️ требования к квалификации исполнителя никакие, поэтому запросы легко параллелятся (хоть для 10 заказчиков строй модель – просто запускай пайп подставляя свои данные)
▪️ это Run в конце концов!

Можно ли вырасти в ML в таком продукте, да еще и получить промо? Ответ очевиден. Да и не нужен здесь даже мидл.

Итак, вывод 1:
В монопродуктовой компании вы в своем росте ограничены уровнем компетенций, который требуется на этом продукте. Расти == менять продукт / компанию.

Что если это не единственный продукт в компании?
Надо менять продукт на тот где ваши компетенции б дут востребованы.
Только вот как? Откуда такой вот кандидат узнает про потребности того продукта? Поймет в какую сторону развиться чтобы там составить конкуренцию внешним соискателям (а переход между продуктами может как минимум включать в себя пару собеседований, а иногда и сопротивление отдающего канальи-манагера)?

И здесь внезапно выясняется что в чистом виде продуктовая компания не работает – требуется как минимум матричная структура, выравнивать компетенции, помогать специалистам развиваться и ротироваться, добавлять в продукты RnD и расширять им сознание vision. Из такой структуры заметят ваш возросший уровень тех компетенции и придумают как вас сохранить в компании по схеме вин-вин.
Даже в продуктовой компании может так выйти что работает гибридная модель – структура с DSами вынесена отдельно и делает для продуктов проекты с четким скоупом (и вы растете от проекта к проекту по уровню решаемых задач) или работает по сервисной модели, направляя ресурсы в приоритетные продукты – во всех этих случаях вас будет оценивать и растить DS-менеджер, у которого хватит компетенций вас оценить и выбрать вам интересные и релевантные развивающие задачи.

#корпжиза
(2/2)
И необходимость такой структуры – такой же закон физики как невозможность встать со стула, не подавшись корпусом вперед – попробуйте, кстати.

Отсюда следует вывод 2: кому-то в компании тоже должен быть нужен ваш рост, не только вам

И этим кем-то может выступать не только матричный руководитель, но и CPO / PO!
Когда такое бывает? Когда его продукт растет и внутри выделяются продукты помельче, туда надо нанимать команды, и это ваш шанс вырасти из синьора в лида и из тимлида в руководителя направления (CDO, например) или заняться RnD для такого крупного продукта.

Вывод 3: выбирать продукт относясь к нему как к инвестиции собственного времени, – выбирать тот, который вырастет, где возможно открытие новых бизнес-линий.

И вот этот способ (расти вместе с правильно выбранным продуктом) самый простой – прилив поднимает все лодки.

Остальные потребуют либо смену продукта – а это не очень-то и отличается от смены работы, либо вовлечение матричных руководителей и целеполагание уже от них (а с двумя руководителями работать сложнее чем с одним).

Здесь кому что нравится – кому-то нравится в продукте сидеть, мне нравится проектная работа с понятным результатом в понятный срок.

почему статья про обезьянку до сих пор актуальна, поясняет опытный работник:

Сотрудница поделилась секретной техникой, которая способна убрать все правки и лишние задачи от твоего босса вмиг.

Пользуемся.

#ML

В комментариях к этому посту попросили поделиться ссылками на антифрод, их есть у меня

Прям в цельную картинку вместе они собраны в курсе 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

Кейс про два стула для кластер-лида

Вызывает как-то шеф к себе — говорит:
«
— Надо сделать модель рекомендации кредитной ставки, выбери кто делать будут — К или Ш (два крупных подразделения)
— А чего мы сами не сделаем, фин эффект себе не запишем?
— А я уже им пообещал
— А кому ты пообещал?
— И тем и тем, ты уж как-нибудь разберись и выбери одних 🤡👏»


Мало того что если выбрать кого-то из этих двух структур, другая к тебе повернется отнюдь не лицом и на существенный срок – все из-за дележки фин эффектов. Причем подкузьмить могут недурно обе башни – через Ш вводятся ставки, а через финансистов (братьев К) защищаются эффекты.

Естественно они ни в какую не хотели данными делиться ни с кем — у одних были данные по нормативной валовой марже по отраслям, по кредитным договорам — а у других реальные финансовые потоки, модель досрочного гашения кредита и всякое полезное иное.

Попытка предложить им сделать две модели и объединить результаты тоже была принята в штыки, посыпались звонки шефу от уважаемых вице-президентов.

Ну тогда по заветам известной байки про Шваба с куском мела договариваемся что в пром ставим ту модель где ошибка на тесте меньше. И в срок 2 мес нужны предикты на тестовый период, мол, метрики мы сами насчитаем – для объективности. Каждая команда уходит строить модель на своих данных.

Проходит 4 месяца и команды возвращаются. До конца года осталось не то чтобы сильно много. Снова предлагаю объединить скоры – шум, гам, обозвали волюнтаристом 🤥. Ну ок, у нас есть дисперсия каждой модели на тесте, давайте попробуем хоть на пальцах прикинуть сколько будет A/B идти. Заодно-таки построим самую примитивную общую модель – с весами сложить предикты команд. В чем суть A/B (на самом деле A/B/C): мы рекомендуем ставку кредита клиентщику для переговоров (давая текстовое описание почему она именно такая), если в группе удается маржу хотя бы на 0.1% в среднем поднять то это сотни миллионов дохода, но сравниваемся мы не только с теми, кому рекомендацию модели не показываем, но и с теми, кому показываем рандомные +0.1% – 0.5% накинуть к нормативной марже.

Считаем с поправками, подбираем сиды везде где только можно, и выходим на нужные числа (сработали не хуже Росстата): если модели не объединять (используя нашу в тч) то до конца года не успеем провести тест и защитить эффект.

Пришлось модели все-таки объединить и эффект на три подразделения делить поровну (ага, и мы кусочек получили) 😝. То же не без битвы -- "а давайте по человеко-часам считать", "а давайте пропорционально аплифту к метрике на тесте" и т.д. Но когда в доме пожар, обсуждение чья очередь мыть посуду не то что бы сильно затягивается 🤓

Поэтому как менеджер не верю я в "великих переговорщиков" и достижимость win-win по-джентельменски, на берегу -- если вопрос действительно чувствительный и интерес вполне себе корыстный, то в корпорации скорее закон джунглей действует, а окно для того чтобы договориться по-человечески появится когда уже совсем деваться некуда будет. Важен только момент времени и критичность ситуации.

#ML

Очередной пост не вмещался в тг, опубликовал его на хабре и нахватал минусов в карму 😄 upd: а нет, все хорошо