Альфа-банк

Привет! Новый год новые митапы.

Уже через неделю мы проведём два первых в этом году митапа, первый из которых будет полезен тестировщикам, а второй iOS-разработчикам. Спикеры будут из Альфа-Банка, а вот участники круглого стола по теме из Сбера, Тинькофф и Райффайзенбанка.

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

Программа под катом

21 января, 19.00 МСК QAчественное общение

В программе 3 доклада от Альфа-Банка и викторина с призами. Мы постараемся сделать эти пару часов максимально полезными для всех собравшихся.

Чтобы принять участие в митапе, обязательно зарегистрируйтесь. Мы отправим вам напоминание и ссылку на трансляцию.

19:05-19:40, Дмитрий Гадеев, Kubernetes. Жизнь ДО и ПОСЛЕ

Руководитель направления сопровождения инфраструктурных сервисов, Альфа-Банк

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

19:40-20:10, Ксения Коломиец, Сайт-конструктор. Тестирование без боли

Старший специалист по тестированию, Альфа-Банк

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

20:10-20:40, Александр Долинский, Тестирование API в большой команде

Руководитель группы тестирования, Альфа-Банк

Пройдем по истории развития тестирования мобильного банка. Соберем некоторые грабли большого проекта.

20:40-21:00, Викторина в Kahoot с розыгрышем призов

Страница регистрации

22 января, 19.00 МСК Mobile Talks

19:05-19:40, Василий Пономарев, Техническая сторона UI-компонентов

iOS-разработчик, Альфа-Банк

Василий расскажет о реализации UI-компонентов, принятых на вооружение архитектурных решениях. А также покажет пример из практики и разберет преимущества и недостатки данного подхода.

19:40-20:15, Евгений Онуфрейчик, Новый разработчик. От старта до выхода на орбиту

iOS-разработчик, Альфа-Банк

Женя расскажет о процессе погружения нового разработчика в проект мобильного приложения Альфа-Банка, о сложностях адаптации и как мы с ними справляемся. Объяснит, как выглядит процесс со стороны новичка что он ощущает и как понимает происходящее. А также расскажет, какова в этом роль и зоны ответственности наставника.

20:15-20:35, Викторина в Kahoot с розыгрышем призов

20:35-21:35, Круглый стол Качество vs скорость разработки как найти баланс?

• Сергей Нанаев, Head of iOS, Альфа-Банк

• Роман Голофаев, Mobile Community Lead, Райффайзенбанк

• Александр Поломодов, Руководитель управления разработки цифровых экосистем, Тинькофф

• Иван Бубнов, Руководитель направления мобильной разработки, Сбер

Страница регистрации.

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

Давайте разберемся на простом жизненном примере, почему важно не копить техдолг?

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

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

В этот момент вы вспоминаете: Почему я не выполнил сразу работы по ремонту, а отложил их подальше?!

Вот и с техдолгом похожая ситуация.

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

• Снежный ком документов

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

• Отсутствие экспертизы для будущих поколений

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

• Время разбора дефектов увеличивается

Наташ, мы все уронили!

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

• Негатив от команды

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

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

Что мы сделали?

1. Собрали рабочую группу, в которую включили аналитиков от каждого направления из центра компетенций аналитики удаленных каналов доступа (Альфа-Мобайл, Сайт, Интернет-банк и др);

2. Определили, что такое техдолг, и как выбирать приоритеты;

3. Расписали процесс ведения, включения задач по техдолгу в бэклог, ответственных;

4. Сформулировали ситуации, сигнализирующие, что техдолг растет, и определили, что делать в таких случаях;

5. Собрали задачи по техдолгу в рамках направлений.

Что такое техдолг и как выбирать приоритеты?

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

Как завести задачу по техдолгу в backlog?

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

Добавить задачу по техдолгу аналитики может любой член команды или сопровождение. За выполнением задач по техдолгу следит техлид аналитиков.

Правила ведения задач в jira

В качестве инструкции и отчета в первой версии создали статью в Confluence с содержанием:

• Что такое техдолг

• Почему важно закрывать техдолг

• Ответственность

  • Кто добавляет задачи

  • Как задача попадает в техдолг

• Процесс работы с техдолгом

• Как ведем задачи в Jira

  • Кто закрывает техдолг

  • Кто следит за выполнением

• Список задач

  • Срез задач на 2 квартал 2021

Список задач собрали автоматически с помощью макроса Jira и настроили возможность фильтрации с помощью макроса Фильтр таблиц. Для визуального отображение использовали макрос Jira круговая диаграмма

Что делать, если техдолг растет

Ситуация 1 растет тех.долг

Решение: Бери задачи по техдолгу в работу в sprint.

Ситуация 2 увеличилось время разборов дефектов из-за отсутствия документации

Решение: Выполняй задачи по техдолгу.

Ситуация 3 хочешь повысить оценку компетенций для продвижения по карьерной лестнице

Решение: Помогай другим направлениям закрывать их техдолг.

Как закрывать техдолг, а не копить

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

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

• создал задачи в JIRA по текущему техдолгу;

• написал статью по шаблону. Пример статьи был выше;

• обсудил с аналитиками из своего направления, кто какие задачи возьмет в работу в следующем квартале;

• рассказал аналитикам из своего направления, какие правила заведения задач по техдолгу.

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

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

Следующим шагом будет настройка dashboard для мониторинга прироста задач по техдолгу.

Предупрежден значит вооружен.

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

Тыбудешь наставником! Новый сотрудник выходит завтра именно так начинается история прото, как ястала наставником. Уновенького наставника рождается масса вопросов: Смогули я? Счего начать? Как преподнести информацию иничего незабыть?

При этом я в Екатеринбурге, а новый сотрудник в Москве. Страх, испуг и непонимание.

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

Что мы сделали

1. Придумали формат общения руководителя и наставника.

2. Подготовили памятку для наставника.

3. Создали обучение для новых наставников.

4. Разработали процесс онбординга с шаблонами планов на 100 дней (испытательный срок).

Формат общения руководителя и наставника

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

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

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

За неделю до выхода новичка руководитель передает всю информацию наставнику в формате:

• ФИО

• Мобильный телефон

• Адрес офиса

• Формат работы (удаленно или рабочее место)

• Дата выхода

• Команда и контакты product owner/project manager

• Дополнительная информация

За неделю наставник успевает подготовиться к выходу сотрудника.

Памятка для наставника

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

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

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

• Желание передавать опыт. Поставьте себя на место новичка и поймите, как важно передавать накопленный у наставника опыт

• Способность мотивировать. Мотивирующий наставник - это как топливо для двигателя, пока есть мотивация для новичка, двигатель работает и выполняет поставленные задачи

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

Еще в памятке мы описали шаги на каждый день испытательного срока.

До выхода новичка

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

За 2-3 дня до выхода наставник

• Отправляет новичку SMS :

Привет! Меня зовут , ятвой наставник вАльфа-Банке. Твое рабочее место икартинку спояснением, как найти это место. Сейчас наставники работают удаленно, анекоторым новичкам приходится приехать впервый день вофис.

• Проверяет, подготовлено ли рабочее место.

• Отправляет приветственное письмо с полезными ссылками на первый день.

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

День первый (выход новичка)

Вот он, день Х. Наставник в ожидании, уточняет у новичка, удалось ли ему найти рабочее место, получилось ли зайти в учетную запись на ПК.

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

• проводит установочную встречу (созвон) не более 30 минут. На этой встрече рассказывает верхнеуровнево, как все устроено в команде, что примерно предстоит делать;

• добавляет новичка в каналы коммуникации и знакомит с командой

• добавляет в обязательные встречи;

• создает план на испытательный срок по шаблону;

• добавляет задачи в jira для прохождения обязательных курсов и испытательного срока;

• создает обязательные встречи 45 дней, 90 дней прохождение испытательного срока.

День второй

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

Наставник во второй день проводит встречу (не более часа), на которой рассказывает:

• как устроена система, которой будет заниматься новичок ;

• как будет проходить испытательный срок;

• знакомит новичка с планом на испытательный срок и критериями его прохождения (это важно, чтобы новичок не нервничал);

• рассказывает о организационной структуре компании (отдела);

• показывает задачи в jira;

• находит бизнес задачу с product owner команды на испытательный срок.

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

3-4 дни

Новичок знакомится с информацией в плане на 100 дней, а у наставника есть время заняться своими командными задачами и поставить еженедельную встречу 1-to-1 (не более 30 минут)

На встречах 1-to-1 наставник и новичок обсуждают вопросы по плану 100 дней, закрывают задачки из него. Также наставник интересуется, нравится он новичку или нет, так как наставник = друг. Эти встречи рассказывать информацию порционно. Новичок при этом чувствует поддержку и нет ситуации "Меня бросили и плыви как хочешь". Регулярность встреч поначалу 1-2 в неделю, потом уменьшается спустя месяц до 1-2 раз в неделю..

45-й день

Экватор, половина испытательного срока.

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

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

90-й день

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

Презентация состоит из трех частей:

• слушаем нового сотрудника;

• наставник показывает итоги опроса, подсвечивает зоны роста, плюсы и минусы;

• техлид и product owner команды дают обратную связь.

В день Х все собираются (наставник, руководитель, новичок и команда).

Встреча проходит по формату:

• Говорит новичок что удалось сделать за испытательный срок, что понравилось, а что нет.

• Руководитель и команда дает обратную связь.

• Наставник показывает план 100 дней и презентацию с итогами прохождения.

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

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

Обучение наставников

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

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

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

Сталкивались ли вы с подобным, когда впервые были наставниками?

Привет Хабр! Раз в неделю я рассказываю о крупнейших событиях в отрасли в России и мире.Оригинальный роликна YouTube, ниже расшифровка.

Меньшинства для NASDAQ

Самое громкое событие, которое случилось это новая идея NASDAQ. Американская биржа отправила в американское правительство предложение о том, что теперь в каждой публичной компании, в совете директоров должна быть одна женщина и один представитель меньшинств. Это пока только предложение. Это пока не указ, не закон, не правило. Но тренды такие, что скорее всего в похожей форме оно будет принято. Если не сейчас, так через год. Тренды.

Если считать что примут именно то, что написали, то правила такие: в совете директоров должна быть одна женщина, не менее одной женщины, и в совете директоров должен быть один представитель меньшинства. Либо сексуального (любого), либо расового по американским понятием (либо латинос, либо афро-американец, либо индеец, либо гаваец, азиат и еще несколько групп). В принципе, эти меньшинства это уже 40% населения США, а если еще и сексуальные меньшинства, то одного человека из них достойного найти не является проблемой. Квота, но довольно мягкая квота.

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

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

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

Salesforce покупает Slack

Salesforce объявил о том, что покупает Slack. Сумма сделки примерно 28 млрд. долларов. Это не рекорд, но очень много. На бирже акции Salesforce немедленно упали. В капитализации компания потеряла примерно те же 28 млрд. долларов. То есть, биржа посчитала, что деньги не потрачены на приобретение крутой компании, а просто выброшены в пропасть. Было на 28 млрд. долларов больше, стало на 28 млрд. долларов меньше.

Почему так случилось? Первая причина арифметическая. Salesforce торгуется исходя из своей прибыли и выручки. Выручка в результате покупки почти не увеличится. Прибыль даже уменьшится, потому что Slack убыточный. Slack торгуется исходя из каких-то своих будущих великих перспектив,но не настоящего. Конечно, через 5-10 лет перспективы Slack они реализуются. Выручка и прибыль появятся и тогда-то Salesforce всем покажет. Но кто ж хочет ждать эти 5 или 10 лет. Вот сейчас оно упадет. И инвесторы не дожидаются этого момента, выходят из компании и цена падает.

Вторая причина, она философская, а не арифметическая. Многим кажется, что две совсем разные компании, на совсем разных стадиях развития в сумме будут управляться хуже, чем одна. Когда вместо гениального основателя Slack появится безымянный менеджер из Salesforce, он все это изгадит, он компанию испортит, то есть зря покупаем, зря тратим деньги. Вот и надо продавать, вот и надо выходить. Ну и на все это истерика. Salesforce начал падать, поэтому надо продавать, поэтому падает еще сильнее, поэтому надо продавать. Вот такой тяжелый M&A.

Эволюция Альфа-Потока

Альфа-Поток объявил, что его акционеры рядом с самим Альфа-Потоком создают фонд Поток Первый, который будет давать деньги в займ через площадку Альфа-Потока. То есть, Альфа-Поток одна из первых и, наверно, крупнейших платформ крауд-кредитования в России, теперь, по сути, сама еще и будет кредитовать без всякого крауда. Деньги будут часто свои или частично свои. По сути, превращается в МФО или банк. Пока она только начала, то есть пока фонд дает часть денег, а не все деньги. Но эволюция забавна.

Сбер выкупает Сбермаркет

Сбер объявил о том, что покупает мажоритарную долю Сбермаркета. Это сервис доставки продуктов из магазинов, он когда-то был независим и назвался Инстамарт, потом Сбер в него инвестировал и свою долю положил в совместное предприятие Mail.ru Group. А теперь он его выкупает из этого совместного предприятия и будет развивать в одиночку. Сумма, которая прозвучала, это 12 млрд. рублей. Часть была потрачена на выкуп, часть будет положена внутрь компании на будущее развитие. Стоимость компании не очень понятна: она и не звучала, и не вычисляется.

Что интересно, на той же конференции был озвучен оборот Сбермаркета это 3 млрд. рублей в месяц, то есть 36 в год, если просто умножить. В 2019 году 35 млрд. рублей это был весь рынок продажи онлайн продуктов питания. То есть, сейчас один сервис больше, чем весь рынок в прошлом году. Ну, спасибо, COVID.

Альфа-банк плюс Моргенштерн

Альфа-банк снял рекламу с Моргенштерн. Моргенштерн, если вы не знаете, это очень популярный среди молодежи российский рэпер. Ролик называется Клип за 10 лямов, типа Альфа-банк за него заплатил 10 млн. Может быть, кстати, и больше. И разыгрывает лотерею среди новых клиентов, каждый из них может выиграть 100 тыс. рублей. Длится ролик 4 минуты. Очень советую посмотреть, получите представление о современном искусстве. Ну это полезно. Ролик очень успешный, 8,5 млн. просмотров, дикое количество обсуждения везде, включая меня. Очень много критики о том, что вот, Альфа-банк был серьезным бизнесом для серьезных людей, а тут какой-то Моргенштерн советует подросткам попросить папу зарегистрировать кредитку. Ну позор, я с такими не буду на одной поляне. Но пришло такое время, что ютьюбер имеет охват, как Первый канал. И этим охватом надо пользоваться. Вот Альфа-банк и воспользовался. 8,5 млн. просмотром пришли сами по себе и, наверняка, огромное количество кредиток зарегистрировано благодаря этому. Успех. Не Альфа-банк виноват, мир виноват. Мир теперь такой.

Продолжение через неделю.

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

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

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

Описание данных

Участникам соревнования был предоставлен датасет по 1.5 миллионам выдач кредитных продуктов. К каждому объекту выборки было подтянуто признаковое описание в виде истории клиентских транзакций глубиной в год. Дополнительно был представлен тип выданного продукта. Обучающая выборка состоит из выдач за период в N дней, тестовая выборка содержит выдачи за последующий период в K дней. Всего в датасете содержалось 450 миллионов транзакций, объемом порядка 6 гигабайт в формате parquet. Понимая, что такой объем данных может стать серьезным порогом для входа, мы разбили датасет на 120 файлов и реализовали методы пакетной предобработки данных, что позволило решать задачу соревнования с личного ноутбука.

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

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

Базовый подход к решению задачи

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

В случае категориальных признаков можно использовать счетчики вхождений каждого значения каждой категориальной переменной или пойти дальше и использовать вектора из матричных разложений или основанных на них методах: LDA, BigARTM. Последний из которых позволяет получить векторное представление сразу для всех категориальных признаков за счет поддержи мультимодальности. Признаки можно отобрать на основе важности, полученной популярным методом permutaion importance или менее популярным target permutation. С базовым подходом, приносящим 0.752 AUC ROC на public LB, можно ознакомиться на git.

Архитектура нейронной сети

Решать задачу классификации многомерных временных рядов можно методами, используемыми в классификации текстов, если мысленно заменить каждое слово текста набором категориальных признаков. В области обработки естественного языка принято ставить каждому слову в соответствие числовой вектор, размерности сильно меньше, чем размера словаря. Обычно вектора слов предобучают на огромном корпусе текстовых документов методами обучения без учителя: word2vec, FastText, BERT, GPT-3. Основной мотивацией предобучения являются огромное количество параметров, которое нужно выучить в виду большого размера словаря и обычно небольшого размеченного датасета для решения прикладной задачи. В данной задаче ситуация обратная: менее 200 уникальных значений для каждой категориальной переменной и большой размеченный датасет.

Резюмируя вышесказанное, векторного представление для каждого категориального признака можно получить, используя стандартный Embedding Layer, работающий по следующему алгоритму: в начале задается желаемый размер векторного представления, затем инициализируется LookUp матрица из некоторого распределения, далее ее веса учатся вместе с остальной сетью методом backpropagation. Размер эмбеддинга обычно выбирается равным или меньше половины числа уникальных значений категориального признака. Любой вещественный признак можно перевести в категориальный операцией бинаризации. Вектор для каждой транзакции получается из конкатенации эмбеддингов, соответствующих значениям ее категориальных признаков.

Далее последовательность векторов транзакций отправим в BiLSTM для моделирования временных зависимостей. Затем избавимся от пространственной размерности при помощи конкатенации GlobalMaxPool1D и GlobalAveragePool1D для последовательностей векторов из рекуррентного и эмбеддинг-слоев. В итоге, предварительно пропустив полученный вектор через промежуточный полносвязный слой, остается добавить полносвязный слой с sigmoid для решения задачи бинарной классификации.

Обучение нейронной сети

Рассмотрим архитектуру нейронной сети, предложенную участникам соревнования в качестве продвинутого бейзлайна. Она несущественно отличается от вышеописанной и содержит сотни тысяч обучаемых параметров. Тяжелые модели склонны переобучаться, запоминая обучающую выборку и показывая низкое качество на новых объектах. На курсах по машинному обучению учат использовать L1 и L2 регуляризацию в контексте логистической регрессии для борьбы с переобучением, будем использовать это знание и установим коэффициенты регуляризации для всех параметров нейронной сети. Не забудем использовать Dropout перед полносвязным слоем и SpatialDropout1D после эмбеддинг-слоя, также стоит помнить что всегда можно облегчить сеть, уменьшив размеры скрытых слоев.

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

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

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

1. Cyclical Learning Rate благодаря стратегии изменения LR позволяет не переобучаться на первой эпохе за счет низкого базового LR и не застревать в локальных минимумах за счет пилообразной-затухающей стратегии. Гиперпараметры base_lr и max_lr можно задать при помощи алгоритма LRFinder. Дополнительно стоит обратить внимание на One Cycle Policy и Super-Convergence.

   

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

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

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

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

Продакшн

Транзакции в hadoop обновляются раз в день, поэтому online-обработка не требуется, в худшем случае нужно успевать прогонять pipeline за 24 часа. Pipeline реализован в виде DAG на airflow, состоящем из следующих этапов:

1. Дозагрузка и агрегация новых данных на pyspasrk. В модели используется история транзакции по каждому пользователю за предыдущий год. Оптимальным сценарием является поддержание исторических предобработанных данных на момент предыдущего запуска модели с добавлением новых данных. На выходе: относительно-компактный parquet-датафрейм.

2. Предсказание на python с использованием одного из фреймворка: tensorfow, pytorch. На выходе: tsv-таблица, содержащая id и множество полей с предсказаниями моделей.

3. Выгрузка предсказаний в hadoop и на вход финальной модели.

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

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

Полезные ссылки и материалы