Вася Сизов | grok ML

Team Lead Conf 2024

Буквально вчера закончилась самая большая конференция для тим лидов. Сейчас я расскажу, а что же там было интересного, а самое главное - что я вынес для себя.

Конференция проходила в кампусе Сколково (да, да, именно в этом месте руководители проходят программу MBA). И на этой огромной площадке целых два дня проходили активности по трем основным направлениям: Team Lead Conf для тимлидов, Tech Lead Conf для техлидов и Knowledge conf для людей, которые хотят разобраться в теме управления знаний.

Лично я шел туда разобраться с управлением знаний. Например:
- Зачем вообще нужна база знаний;
- Как построить внутреннюю базу знаний;
- Как "продать" идею базы знаний в своей компании;
- Как другие лиды и руководители запускали данные процессы и что у них получилось.

В итоге, я не только закрыл свои "боли" по базам знаний, но и получил кучу идей и мотивации по своим навыкам и процессам в команде (такая "тимлидовская база"). Просто представьте, как сотрудник Яндекса рассказывает о том, как он менял процессы, когда команда кратно росла. Или как сотрудник Т-банка вывозил миграции в 80 командах (в банках вообще все не просто, для такой задачи нужны огромные усилия).

Еще запомнился доклад о том, а как растить команду на рутине. Мне кажется, что это вообще очень редкая и ценная практика: в команде стагнация, задачи одни и те же, а нужно сделать так, чтобы команда не только не разбежалась, а еще и нашла точки для роста.

В общем, мне очень зашло, так как зачастую в докладах описывали именно мои боли как тим лида.

Важное замечание: в отличие от других конференций на доклад выделяется целый час, чтобы максимально раскрыть тему за 50 минут, а 10 минут оставляют на вопросы. Также доклады очень тщательно отбираются комиссией, чтобы не было воды. Из-за этого некоторые доклады были такие концентрированные, что уже дома, делая заметки, у меня получалось 3-4 страницы мыслей, идей для улучшения моих личных навыков и процессов в моей текущей команде.

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

Чем наша команда занимается в ВТБ?

Всем привет! В это посте я расскажу, какие модели строит наша команда "Моделирование для жизненного цикла клиента".

Наша команда очень тесно переплетена с бизнесом. Система монетизации клиентской базы включает следующие задачи:
🔵 Привлечение - выделение организаций, склонных оформления договора с банком
🔵 Активация - аналитическое выявление причин неактивности клиентов
🔵 Кросс-продажи - подбор наилучшего предложения клиенту на основе склонности приобретения и доходности для банка
🔵 Удержание - предсказываем время до наступления оттока и пытаемся его предотвратить
🔵 Реактивация - реактивируем "замершего" клиента, либо возвращаем шедшего клиента

Уже исходя из этих общих задач можно выделить следующие модельные задачи:
🟢 Модели склонности - хотим получить вероятность склонности клиента к приобретению того или иного продукта. Это классические look-alike модели. Если регулярно проводятся маркетинговые кампании, то можно пробовать строить response и uplift модели. Если много продуктов и много откликов, то можно строить рекомендательные модели.
🟢 Модели оттока - хотим получить вероятность того, что клиент уйдет в отток через какое-то время. Здесь можно перевести задачу в классификацию, а можно использовать подходы из анализа выживаемости, что является более правильным.
🟢 Модели next best offer/nest best action - пытаемся определить лучшее следующее действие/предложение для клиента.

И это только базовая часть задач, которые мы решаем. А что же еще?
🟢 Анализ звонков клиентских менеджеров (audio, nlp)
🟢 Анализ жалоб и обращений (nlp)
🟢 Моделирование CLTV
🟢 Определение потенциала доходности
🟢 Моделирование выручки или кредитовых/дебетовых оборотов
🟢 и т.д.

А теперь представьте, что весь этот зоопарк моделей может быть построен в разрезе продуктов и сегментов.
Да, моделей много. Задач еще больше! Именно этим мы и занимаемся)

Data quality или качество данных

Существует такой знаменитый принцип - «Garbage in, garbage out», или «Мусор на входе - мусор на выходе». Я в банке занимаюсь построением моделей машинного обучения, а для моделей очень важны данные. Фактически, этот принцип для меня означает следующее: даже если я построю идеальную модель, то плохие данные на входе модели все испортят. И модель просто не будет работать!

Поэтому очень важно следить за качеством данных.

В больших компаниях данные проходят через разные слои, прежде чем попасть в конечную витрину для аналитики: RAW -> ODS -> DDS -> CDM. Обычно именно CDM-слой используется для аналитики и построения витрин с факторами для модели.

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

В общем, я наткнулся на интересную реализацию компонента Data quality от MTS: https://www.youtube.com/watch?v=nFNF4Esk9D8&ab_channel=ODSAIRu.

А посыл поста очень простой - DS должен не только модельки строить, а в первую очередь задумываться о данных, которые потребляет!

Зачем ml - специалисту навыки разработчика

Когда я только устраивался ml-специалистом, то имел представление только о Kaggle. Думал, что буду целый день крутить данные и делать модели. А пользу для бизнеса они уже сами как нибудь принесут. Но реальность оказалась совсем другой.

Оказалось, что модель должна быть в ПРОДе. Код применения модели необходимо покрыть тестами, добавить типизацию, прогнать линтеры и так далее. Далее код необходимо положить в гит. И не просто положить, а по определенным правилам и в определенную ветку, чтобы CI/CD процесс его подхватил и понес дальше на ПРОД или ПРЕПРОД.

Ок, кажется, что такое могут делать, например, MLOPS, адаптируя код ml-специалиста и отправляя его в прод (в крупных компаниях так и организовано). Где же нужна разработка при обучении моделей? Честно сказать, кажется, что везде!

Когда-то Евгений Соколов сказал: в классическом ML все "танцы с бубном" вокруг создания факторов, а в DL - вокруг инженерии (а все потому, что постоянно что-то не заводится или не запускается). Вот и первый пример - DL. Действительно, завести какую-нибудь нейронку со своими данными бывает ой как не просто.

Какие еще примеры?
🔵 Создание библиотек - тут паттерны проектирования, сборка библиотеки
🔵 Переиспользование кода - создали, например, скрипт сбора факторов. Конечно лучше его оформить, сделать универсальным и выложить для всей команды
🔵 Передача модели на внедрение - если batch модель, то нужно передать окружение и код, например, в py файлах. А вот если онлайн модель - то там и сервис нужно написать, и system design применить
🔵 И т.д.

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

В итоге, закончу известной в некоторых кругах фразой: разработчика обучить ML относительно просто, а вот ml-специалиста обучить разработке ...! PS: Подставь свое))

Партиционирование и Spark

Буквально только что сидел и «крутил» данные на работе. Данные у нас хранятся в Hadoop, а обрабатываем их мы с помощью Spark (в частности, используем pyspark).

И естественно, все таблицы у нас партиционированы. Грубо говоря - данные в Hadoop благодаря партиционированию хранятся в директориях. Если партиционировать, например, по report_date, то данные за январь хранятся в одной папке, данные за февраль в другой и так далее.

Так вот, я написал запрос

SELECT * FROM NAME_TABLE LIMIT 5,

чтобы просто посмотреть на рандомные пять строк из таблицы. И … такой запрос работал минут 15. Это произошло потому, что Spark сначала просканировал всю таблицу (а там она весит под 1 Tb и строк несколько сотен миллионов) и только потом вывел результат.

Причем же здесь партиционирование? А притом, что нужно было дописать всего одно условие:

WHERE report_date = “2023-01-01”.

Такой скрипт отработал за 10 секунд! Так произошло потому, что Spark уже не заходил во все директории, а знал конкретно куда идти и что сканировать. В итоге, просканировал немного данных и быстро вывел результат.

Посмотреть партиции в таблице можно командой SHOW PARTITIONS NAME_TABLE.

А дальше уже можно для тестирования писать более сложные запросы и накручивать более сложный код.

Вообще оптимизация запросов в БД (или конкретно в Spark) довольно обширная тема, но об этом в другой раз.

Где можно изучить классический ML?

За все время работы в области Data Science я прошел через десятки различных источников. Также меня постоянно спрашивали про вводные материалы по ML. Год от года я рекомендовал абсолютно разные материалы.

Но как-то раз на Coursera наткнулся на специализацию «От статистики до нейронных сетей». По моему мнению - это лучшая специализация, которую я проходил по ML за все время.

Потом Coursera стала недоступна, а сами курсы переехали на openedu.

Курс по классическому ML читает Евгений Соколов. Самый большой плюс курса в том, что Евгений сначала рассказывает «интуицию», идеи алгоритмов на простых примерах, а только потом переходит к строгим формулам.

В общем, всем рекомендую, ссылки ниже!

«Основы машинного обучения»: https://openedu.ru/course/hse/INTRML/?session=2022
«Продвинутые методы машинного обучения»: https://openedu.ru/course/hse/DEEPLEARNINGADVANCED/?session=2023

Как я в PWC не попал

Далекий сентябрь 2018, 6 курс университета, а я только узнал о data science из открытой лекции PWC. И я решил туда попасть на работу.

На тот момент я ничего не знал о python, были не очень хорошие знания по статистике, знаний ML не было вообще. И я пошел учить теорию: посмотрел курс по Python от Хирьянова на ютубе, посмотрел специализацию по ML на курсере от мфти. Также почитал про логические задачки в консалтинге: например, «оцените количество красных машин в Москве».

С этим багажом знаний я подался на самую стартовую позицию. Резюме мое одобрили. А дальше пошли этапы отбора.

Сначала был онлайн тест по английскому. Его я прошел.

Далее тестовое задание. В нем были данные сотовых вышек и нужно было придумать какой-то алгоритм на основе этих данных (сейчас уже не помню какой). Точно помню, что я придумал много эвристик, но сам алгоритм не написал (python на тот момент я учил только 2 месяца, но очень помогало техническое образование). В итоге, по тестовому заданию я прошел дальше.

Следующий этап - собеседование с hr. Этот этап мне очень сильно помог в будущем. На этой части меня очень сильно поменторили, рассказали, как лучше составить рассказ о себе, как лучше продать свои навыки. Даже дали задание составить рассказ о себе на 1-2 минуты без белых пятен в карьере. И потом проверили этот рассказ по телефону.

И после этого уже был финальный этап с руководителем data science направления PWC. Мне задавали в основном не очень сложные технические вопросы, но тогда они мне казались диалектом эльфийского (учил я ml на тот момент всего 3 месяца и никак не ожидал вопроса про ядра SVM). Также была и логическая консалтинговая задача.

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

Где машинное обучение в банке?

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

Я бы выделил два основных сегмента:

● Физические лица
● Юридические лица и ИП (наша команда работает как раз в этом сегменте)

Обычно в каждом из сегментов выделяется два крупных блока:

● Риски: самый стандартный пример - задача кредитного скоринга. Здесь как раз хотим оценить риски от того, что клиент не отдаст кредит. Это более строгое направление, так как если клиент не отдаст кредит, то банк понесет прямые потери
● Бизнес-моделирование: здесь может быть все что угодно - рекомендательные системы, LLM, computer vision (например, распознавание сканов документов), look-alike/uplift модели и так далее. Это не такое строгое направление, так как если модель вдруг перестанет работать хорошо, то потери будут небольшие (наша команда как раз работает в этом направлении)
● Дополнительный блок RnD: здесь все стандартно - занимаемся исследованиями, изучаем передовые подходы, разрабатываем свои алгоритмы

Сами проекты могут быть:

● Внутренние для заказчика. Это стандартные проекты для физических лиц, юридических лиц или ИП
● Внутренние «без заказчика». Это может быть сервис перевода звонка в текст и его суммаризация. Таким сервисом может пользоваться любой сотрудник банка
● Внешние проекты. Это может быть консалтинг от банка или коллаборация с каким-то институтом (например, МГУ). Внешний проект так называется потому, что в таком проекте часто не используются данные банка. Также здесь разрабатываются какие-то новые алгоритмы (как раз RnD)

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

#о_себе
Всем привет! Хочется начать с поста-знакомства.

Можно сказать, что я «перекатившийся» айтишник, так как основное образование - стартовые ракетные комплексы. Если коротко - инженер конструктор. И я вообще никогда не хотел заниматься программированием.

Я успел поработать инженером: в основном готовил чертежи в программе «Компас» на российских заводах, но не сложилось.

На 6 курсе универа мне порекомендовали IT-консалтинг. Я изучил все консалтинговые компании и решил сходить на лекцию от PWC. В итоге, всю лекцию они рассказывали о Data Science. Я тогда вообще мало что понял, но очень заинтересовался.

И вот, спустя почти 7 лет я работаю лидом CRM DS-команды в ВТБ!

Channel created