Соревнование Data Fusion Contest 2023 в этом году состоялось во второй раз и собрало  сильнейшие индустриальные команды и отдельных любителей моделей алгоритмов машинного обучения. Кто-то участвовал впервые, а кто-то, уже умудрённый прошлым опытом был явно настроен только на победу.

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

Мы задали себе все эти вопросы и решили найти ответы на практике, подготовив для участников Data Fusion Contest 2023 очень нестандартное и по теме и по формату соревнование по Adversarial ML с атаками на модели машинного обучения, а также с их защитой.

Давайте разбираться, что из этого получилось по факту, и какие решения предложили участники, чтобы оказаться в рядах победителей!

Доброго времени суток, уважаемые читатели! Сегодня мы вновь рады приветствовать вас в увлекательном мире дата-сайентистов банка "Открытие". На связи Иван Кондраков, Константин Грушин и Станислав Арешин. Недавно мы поделились с вами нашим пайплайном разработки линейных моделей для решения задач бинарной классификации. Теперь же мы решили поведать о нашем опыте построения моделей градиентного бустинга. За последнее время команда проделала колоссальную работу: мы протестировали различные методы отбора факторов, нашли новые инсайты в данных, провели интересную (а, главное, полезную!) аналитическую работу и решили несколько Ad-hoc задач. Зовите всех к экранам, мы начинаем!

На связи команда по разработке риск-моделей для крупного корпоративного, а также малого и среднего бизнеса банка «Открытие» Андрей Бояренков и Кирилл Козлитин. Сегодня мы хотим поделиться с вами процессом разработки модели выявления связанных компаний на основании транзакционных данных. Пришли к нам заказчики и говорят: «Хотим по имеющимся транзакциям наших клиентов определять, кто из контрагентов является с ними связанным».

Привет! Я Василий Сизов, тим-лид команды «Модели управления Жизненным Циклом Клиента», и мы продолжаем нашу серию материалов о библиотеке autobinary.

Ранее мы рассказали вам о кросс-валидации в autobinary, которую можно использовать не только для расчета усредненной оценки модели или расчета усредненных важностей фичей, но и для подбора параметров модели, отбора фичей в модель и т.д.

В этой статье мы расскажем вам о том, как можно использовать библиотеку autobinary для подбора параметров с помощью Optuna, а также о том, как можно интерпретировать вклад фичей с помощью Shap и PDPbox. 

На связи команда по разработке риск-моделей для крупного корпоративного, а также малого и среднего бизнеса банка «Открытие» — Андрей Бояренков, Владимир Иванов и Иван Луговский. В этой статье мы расскажем про наш опыт улучшения показателей ранжирования моделей оценки вероятности дефолта заемщика/скоринговых моделей за счет использования различных источников данных и объединения их в отдельные модули.

Всем привет! Сегодня мы, риск-технологи банка «Открытие» Илья Мясников (@berrim0r) и Гевонд Асадян (@Gevond), расскажем, каким образом осуществляем тестирование моделей оценки кредитного риска перед выводом в прод. В прошлой статье про дублирующий проверочный скрипт мы рассказали о том, как мониторим корректность выведенной в прод модели. Но проверок же много не бывает! Перед выводом модели в прод нужно удостовериться, что выводимый функционал работает корректно.

Как проверить корректность расчета модели? Ну да, верно – скормить ей входные данные со строго определенными параметрами. Звучит не очень сложно, правда? А если факторов более полутора сотен? И часть из них оказывают влияние только при определенном взаимодействии с другими факторами? Такое количество вариантов входных данных вручную придется готовить не один день.

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

С ростом количества источников данных, методов генерации и извлечения признаков возникает вопрос: «А надо ли нам столько информации? Не ухудшит ли каждый новый фактор предсказательную силу модели?» И правда, для решения большинства задач нет необходимости использовать все доступные нам признаки в финальной модели, так как часть из них не несет в себе никакой информации и даже может запутать алгоритм. Для того, чтобы решить эту проблему и сократить признаковое пространство, были придуманы методы отбора факторов в задачах машинного обучения. О некоторых методах, которые мы внедрили в библиотеку Autobinary расскажем в этой статье.

Давным-давно, в далёкой-далёкой галактике 1 марта Хабр объявил начало сезона «Машинное обучение», и вот настало время подводить итоги. За чтением хардкорных конкурсных текстов месяц пролетел незаметно. Мы узнали много интересного о нейросетях и неочевидных способах взаимодействия с ними, пополнили свою коллекцию туториалов и в очередной раз убедились в актуальности темы Machine Learning для читателей Хабра.

Мы не получили ответ на главный вопрос Вселенной, жизни и всего такого, но зато нам известен лучший автор сезона ML. Впрочем, у него были достойные соперники, их тексты привлекли много внимания и породили холивары в комментариях. Под катом наградим победителя новым макбуком, познакомимся с участниками сезона, пофлудим о Machine Learning и обсудим перспективы этого направления. 

Рождение autobinary, как и многих других фреймворков, началось с автоматизации рутинных задач. На тот момент мы создавали много look-alike моделей (в основе - модель бинарной классификации) по разным продуктам банка. Одни и те же скрипты писать было скучно. Более того – накопилось много разрозненных скриптов, которые хотелось привести к единому формату.

Всем привет! С вами на связи дата-сайентисты банка "Открытие" Иван Кондраков и Константин Грушин. В прошлой статье мы рассказывали про решение, которое позволило повысить эффективность в проверке гипотез для моделей. Если вы успели с ней ознакомиться, то уже знаете, что наша команда занимается разработкой и развитием пула моделей принятия решений о выдаче кредитных продуктов и банковских гарантий для малого и среднего бизнеса. Сегодня настало время поговорить с вами про пайплайн, который используется для разработки таких моделей. Мы построили достаточно много моделей, так что нам точно есть чем поделиться. К тому же существенный вклад в развитие такого универсального алгоритма внес каждый член команды.

Привет! Меня зовут Вадим Казаченко, я лид фронта дизайн-системы ВТБ. Год назад устроился в банк и получил командную задачу — построить единую библиотеку компонентов, настолько универсальную, чтобы ее можно было использовать в любом продукте дизайн-системы банка, и при этом она не должна становиться «узким горлышком», как это обычно происходит с UI-китами в крупных компаниях. Дело в том, что в ВТБ существует множество дизайн-систем, над которыми работают десятки дизайнеров.

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

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

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

Вас приветствуют Гевонд Асадян и Илья Мясников. В банке «Открытие» в управлении риск-технологий мы занимаемся внедрением моделей оценки кредитного риска. В этой статье на примере большого и сложного процесса выдачи экспресс-кредитов мы расскажем, как нам удалось реализовать полноценный дубль процесса на стороне одного проверочного скрипта и ускорить процесс выдачи экспресс-кредитов с двух рабочих дней до семи минут.

Когда в коллегах согласья нет,
На лад проект их не пойдет,
И выйдет из него не profit, только cost.

Однажды Бэкендер, Фронтендер да Аналитик
Везти с тасками US взялись,
И вместе трое все в него впряглись;

Из кожи лезут вон, а US всё нет ходу!
Таски для них казались и легки:
Да Фронт рвется в Cloud-решения,
Бэк пятится назад, а Аналитик тянет в воду.

Кто виноват из них, кто прав, - судить не нам;
Да только UserStory и ныне там.

Уверен, многие узнали всем известную басню про трёх товарищей, которые пытаются затащить одну общую хотелку (некий воз). Только вот каждый тянет эту задачу в свою сторону, игнорируя усилия других. Сегодня я поделюсь с моими любимыми читателями примером, как сделать так, чтобы работа над задачей между тремя нашими героями шла дружно и эффективно.

Меня зовут Андрей Аврамчук, я старший продюсер спецпроектов в Хабре, принёс не ответ на главный вопрос, а пока только новый сезон на Хабре — «Машинное обучение», который мы проводим совместно с ВТБ с 1 по 31 марта. Будем искать вместе, и да поможет нам магия ML.

UPD. Сезон закончился, итоги можно посмотреть в этой статье.

Всем привет! На связи Иван Кондраков и Константин Грушин. В банке «Открытие» мы с командой занимаемся разработкой и развитием пула моделей для принятия решений о выдаче кредитных продуктов и банковских гарантий для малого и среднего бизнеса. Еще в 2020 году у нас было всего два дата‑сайентиста, один дата‑инженер, несколько моделей и факторы в объеме до двух тысяч штук. С каждым годом количество задач и обученных моделей росло. А вместе с ними росло и количество гипотез, которые нам хотелось проверять при построении моделей. А исходя из специфики области (ограничения на интерпретируемость моделей, используемые алгоритмы, подходы), немалая доля гипотез выражалась именно в работе с факторами, на которых обучаются наши модели. К тому же сложно переоценить важность данной работы, поскольку от того, насколько выверены факторы, напрямую зависит качество моделей. Проблема в рассчитанном факторе, будь то ошибка в логике расчета или утечка информации о целевой переменной (т. н. target leakage), приводит к невалидности полученных результатов. Хорошо, когда такие ошибки выявляются до начала разработки модели, а не в процессе ее промышленной эксплуатации.

И вот на дворе 2023 год, у нас уже восемь дата‑сайентистов, команда дата‑инженеров, больше чем несколько моделей и около 30 тысяч факторов, список которых до сих пор поддерживается вручную в Excel‑файлах.

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

Adversarial attacks — это злонамеренное манипулирование входными данными модели машинного обучения с целью заставить ее выдать неправильные предсказания.

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

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

Виды атак

Существует несколько типов Adversarial attacks, каждый из которых имеет свои уникальные характеристики и методологию.

Нет ещё в мире IT-вайтбука по MLOps. Нет вайтбука — нет однозначного способа «сделать хорошо, а плохо не делать». Время экспериментов и открытий.

Привет, я Юрий Карев. В ВТБ руковожу командой, которая занимается созданием процессов и стандартов моделирования машинного обучения. И, помимо прочего, работаю с командой как раз над таким экспериментом: мы создаём в ВТБ MLOps-конвейер. По сути, делаем ту самую инструкцию: как правильно реализовать MLOps на практике. Одну из множества: уверен, наши конкуренты всё делают по-своему и тоже получают уникальный ценный опыт. Но этот пост — о нас. О том, как мы подошли к теме MLOps, как продали её бизнесу, чего уже достигли, какие трудности у нас были и как мы их преодолевали. Интересно? Проходите под кат, не стесняйтесь.

Этим летом команда «ВТБ Онлайн» проводила много исследований для изучения сложившегося клиентского опыта и оптимизации сервиса. Обычно в этих процессах активно участвуют product owner, СJE и бизнес-аналитики. Но тут к product owner напрямую обратился разработчик команды «Мобильного банка» с просьбой подключить его к исследованиям и проектированию клиентских сценариев. 

Постепенно всё больше разработчиков, тестировщиков и системных аналитиков интересовались не только результатами исследований, но и самим процессом. Так начал складываться новый формат работы, который требовал внимания и организации. Меня зовут Вера Нещадина, я лид-исследователь платформы «ВТБ Онлайн». Подробнее в статье расскажу, как мы опробовали новый для себя вид работы в команде и помогли коллегам разобраться в исследованиях на системном уровне.

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

Меня зовут Мешкова Анна. Я руковожу стримом «Озеро данных» на Фабрике данных ВТБ. И этот текст о том, как мы в банке смогли выстроить унифицированный процесс загрузки данных, какие задачи себе ставили и что из этого получилось.

Наша команда входит в Фабрику данных банка ВТБ и отвечает за загрузку всех внешних и внутренних систем-источников в Datalake на базе Hadoop.