глаз задергался от этой рекламы агентов, а мб клин клином ? 🤔

кстати, про IFы

Есть у меня знакомый, очень талантливый парень из Ростова/Москвы, 10 лет работает лидом в большой и уважаемой ИТ-компании, отвечает за антифрод.

Раз в пару лет где-то как-то пересекаемся, спрашиваю что нового в науке антифрода.
Каждый раз он честно и серьезно отвечает что пишет SQL-запросы и логику на IF/CASE WHEN.

Но сейчас чуть другой сюжет.

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

Юр лицо, особенно крупное, это достаточно сложная сущность с единым исполнительным органом — например:

хозяином в ООО УРК (ИНН 6670534016)
, верховным атаманом (ИНН 7708364030, 7702376889 и 5036056729)
, предводителем (ИНН 3906081950 и ООО СИМПЛИМЭДЖИН ИНН 7714908584)
, верховным шаманом (ИНН 1701062776) — все ссылки на сайт ФНС, ищите должность на второй странице выписки ЕГРЮЛ.

Еще юр лица часто живут в группах (не только для дробления бизнеса по выручке для налоговой оптимизации), имеют сложные схемы владения (иногда вообще кольцевые), неочевидных бенефициаров, сложные аффилированности и экономические отношения, через некоторые идут миллионы транзакции в месяц, а по другим наоборот, никаких данных нет (а около 600 ЮЛ даже ИНН не имеют, как и код иностранного ЮЛ).

Как поступают в таких случаях?

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

Вопрос только в том какой скор подавать на вход графовой модели и вообще как объединять предикты моделей для конкретного ЮЛ в зависимости от того какие данные были доступны.

Итак, лет 10 назад, когда нейронки только переживали очередной расцвет после зимы, самое высокое начальство потребовало чтобы DS не городили огород а сделали уже одну большую нейронyю сеть, которая все данные скушает и откалиброванный скор выплюнет (заодно и резервы сама посчитает, что уж).

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

Как быть в ситуации когда:
⁃ нужна обязательно нейронка и это проверят
⁃ Которая пройдет строгую валидацию и статтесты в отдельном департаменте
⁃ Времени на разработку нет — сами витрины данных еще толком не появились в хадупе, про GPU и среды обучения нейронок инфраструктурщики даже по радио не слышали
?

Мы все учились понемногу, чему-нибудь и как-нибудь.
Как выглядит самая простая нейронная сеть с одним нейроном?

Правильно, это логистическая регрессия!

Итого, мы объединили скоры логрегом, на слайде для начальства гордо написали что модель выполнена в нейросетевой архитектуре — и все были довольны:
— риски получили хорошую понятную стабильную модель
— валидаторы дали зеленый свет и подтвердили архитектуру
— начальство уверенно вещало на страну про нейронную сеть

Так что часто в самых сложных и современных системах куча логики в портянках с IF / case when и это вполне нормально.

ODS умеет удивлять

утренний ребус тщеславия

оригинал

Из серии «подслушано у кулера»

— У нас в проектном офисе уже больше 50 человек!
— А почему из них только 3 проектных менеджера?

Я, честно говоря, путаюсь, когда одновременно в одном направлении работают:

— Product Owner
— Product Manager
— Project Manager

Что их вообще объединяет?

Вопрос с их собеседования «Как ты используешь ИИшечку в работе?»

И в ответ ожидают не рассказ про промтинг gpt, а чего-то поинтереснее.
Знакомую Senior Product давеча попросили мультиагентную систему построить на публичных MCP

Меня от «иишечки» коробит немного, но по сути помочь можем.
Как вы помните, мы с Максом ведем курс по AI-агентам на ФКН ВШЭ и ВШПИ МФТИ и выкладывал свою лекцию по RAG

Так вот, в этот раз мы собрали собратьев по агентам — топовых продактов из Авито, exYandex, Beeline Cloud, Typeform и МТС чтобы они показали и рассказали — как они решают свои day2day продуктовые задачи «иишечкой», почему это работает лучше простого промтинга, в каких кейсах вообще стоит эту «иишечку» использовать а в каких не совсем.

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

Встречайте — курс по AI-агентам для продактов от продактов. 7 живых онлайн-семинара в диалоге с предподавателями, раз в неделю, материалы целый год доступны после курса

PS Ну а если кто-то хочет поботать именно базу ML/AI, то вот N айтишниц в честь первого сентября отгрузили подборку материалов

#ML #корпшиза

Про регэкспы

В комментах к посту про IFы в проде вспомнили про регэкспы.
Есть у меня история и про них

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

Миллиард-два полупроводок в месяц, у каждой 100+ важных полей (не только же назначения платежа, десяток текстовых полей и еще больше категорийных и численных)
Опечатки, технические ошибки и 12 методистов рисков размечали 2 недели в эксельки на классы (которые потом несколько раз пришлось поменять).

Мне досталась уже готовая модель (с очень негативным фидбеком от заказчиков) + разметка в файлах s3.xls и s4.xls (искренне благодарен людям что они хотя бы .csv не использовали — таким посылаю лучи поноса, ибо встретить перенос строки или спецсимвол в назначении платежа — проще простого).

Я по при породе любопытен и спросил где s1 и s2, но сейчас не об этом

В те времена DSы еще помнили что такое стемминг.

И модель радостно использовала pymystem3. Который при попытке запустить его в закрытом контуре (где собственно модели и нужно было разрабатывать) радостно лез в интернет (cdn.yandex.net) и умирал, получая отказ. SnowballStemmer этих недостатков был лишен и тут же мною использован — и тогда я впервые понял что корпоративный арбитраж может быть не только злом (модель попала ко мне потому как шеф в результате агрессивных поступательных действий добился роспуска целого центра в соседнем блоке за профнепригодность).

Но, к сожалению, стеммер не лечит опечатки.

И вот автор той модели лечил их регулярками.

Тысячи строк вида:

r'\b\w\b' : 'xyz'

Которые применялись последовательно в цикле for через re.sub()

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

Тот, кто давно в канале, уже знает ответ

Все эти тысячи срок хранились в словаре (dict), который не гарантировал порядок ключей внутри (это изменилось только в Python 3.7), а паттерны опечаток частично перекрывались.

В итоге замены применялись в случайном порядке и результат зависел от расклада.
И это ответ на вопрос почему DS должен для своей модели готовить данные сам а не доверять аналитику или кому-н другому