Русский
Русский
English
Статистика
Реклама

Alfa battle

27 июня, стрим-конференция Кодинг будущего

25.06.2020 14:15:14 | Автор: admin
Привет!

Если вы читали наши предыдущие посты, то уже знаете про Alfa Battle для Java-разработчиков. Послезавтра в прямом эфире можно будет посмотреть финал чемпионата, с 12.00 до 18.00.

Параллельно стриму с финалом мы запустим стрим-конференцию под названием Кодинг будущего, где с партнерами чемпионата (Билайн и X5 Retail Group) поговорим о футуристических прогнозах в IT. От компаний будут ведущие разработчики и топ-менеджеры.



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

Основных модулей стрим-конференции у нас получилось 6 штук:

  1. AI
  2. Web-банкинг
  3. Growth hacking
  4. Mobile banking
  5. Продуктовый дизайн
  6. Архитектуры Java-проектов

А вот сами доклады и спикеры.

Начнётся стрим в 12:00, вместе со стартом чемпионата Alfa Battle

12:05
Футуристический прогноз: российская IT-индустрия завтра

Михаил Тюрганов, Руководитель дирекции развития цифровых сервисов, Альфа-Банк
Павел Дерендяев, Руководитель центра компетенций Java, Альфа-Банк


Модуль #1. Java Alfa Digital


12:15
Технологии и инфраструктура Альфа-Мобайл
Максим Шатунов / Java Tech Lead, Альфа-Мобайл, Альфа-Банк

12:35
Эволюция корпоративного банка
Никита Хренов / Ведущий разработчик, Альфа-Банк

12:55
Внутреннее устройство сайта alfabank.ru
Максим Чернухин / Архитектор направления, Альфа-Банк

Модуль #2. AI Билайн


13:15
Интеллектуальная обработка звонков в реальном времени
Донат Фетисов / Head of Architecture and Infrastructure department, Билайн

Модуль #3. X5 Retail Group


13:40
Цифровизация помидора

Руслан Каймаков / Head of Web&Mobile Development, X5 Retail Group

14:05
От Java до Scala на грузовике Х5

Вадим Ануфриев, Senior Scala Developer, X5 Retail Group

Модуль #4. Кодинг будущего


14:30
Дискусcионная панель Кодинг будущего

Иван Пятков / Директор по цифровому бизнесу, член Правления Альфа-Банка
Донат Фетисов / Руководитель департамента по архитектуре и инфраструктуре данных, Билайн
Антон Вальков / Директор по IT, член правления X5 Retail Group


Модуль #5. Alfa Digital Products


15:15
Alfa Digital: Новый взгляд на банкинг

Дамир Баттулин / Head of Digital Channels, Альфа-Банк

15:30
Web-банкинг в эпоху Mobile 1st

Нина Красавина / Digital product owner, Альфа-Банк

15:40
Voice UX. Практическая магия

Владимир Китляр / Digital CPO, Альфа-Банк
Елена Грунтова / Руководитель продукта в ML сервисах Яндекс.Облака


16:00
Как мы делаем из Альфа-Мобайл лучший мобильный банк в стране

Евгений Тонкошкуров /СРО Альфа-Мобайла, Альфа-Банк

16:15
Роль лида дизайнеров цифровых продуктов

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

16:30
Дизайн нового Альфа-Мобайла

Вячеслав Киржаев / Lead Product Designer, Альфа-Банк

16:45
Про страшные ругательства: Growth Hacking и Dual-track Agile

Илья Кузнецов / CPO Digital Innovations, Альфа-Банк

Модуль #6. Alfa Digital Products


17:00
Финиш чемпионата Alfa Battle


17:15
Интервью с Владимиром Верхошинским

Главный управляющий директор, член Наблюдательного совета Альфа-Групп

17:45
Подведение итогов и награждение победителей

Владимир Верхошинский

Подробнее..

6 мифов о разработке в финтехе

19.06.2020 16:07:35 | Автор: admin
Привет!

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



Как обычно, всё немного не так, как кажется на первый взгляд. Под катом мы расскажем о 6 самых распространенных заблуждениях, о том, как всё работает у нас в Альфе, и причём тут Alfa Battle.

Миф #1. Банки используют только старые версии Java, 68


На восьмёрке мы стали писать примерно лет 5 назад, это была первая версия нашего интернет-банка, собранного на микросервисной инфраструктуре. И сейчас это минимально используемая версия, обычные будни же это 13 и 11.

В чем польза:

  • Получаем быстрый доступ к новым JEP и возможность использовать новые фичи сразу, без задержек при переходе на новую версию.
  • Оптимизируем работы в docker-контейнере.
  • Получаем более функциональные стримы с каждым релизом.

Чтобы разработчик не скучал в ожидании сборки проекта и мог заняться решением более интересных задач, для старта java-приложения мы используем jvm-параметры (например, *RAMPercentage), что позволяет быстро задавать размер памяти в процентах, отталкиваясь от памяти контейнера, и оптимизировать работу приложения в нем.

А ещё мы храним в распакованном виде JAR-архивы, чтобы закешировать часто используемые библиотеки, которые не применяются от сборки к сборке, и в целом ускорить запуск проекта. Раньше старт контейнера со Spring Boot занимал 40 секунд, теперь 15. Сейчас думаем попробовать JEP 351 ZGC Uncommit Unused Memory (Java 13), чтобы ещё больше оптимизировать работу сервисов.

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

Миф #2. Оркестраторы помнят доллар по 30


У нас Mesos Marathon и более 10 больших Mesos-кластеров под проекты банка, которых несколько сотен. И всё бы ничего, но современным требования разработки Mesos отвечает, прямо скажем, с трудом. Возможен ли переход в рамках банка на новый оркестратор?

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

Миф #3. Финтех это легаси


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

Поэтому частично монолитное легаси все еще с нами, но мы продолжаем расколупывать его на микросервисы. Понемногу, аккуратно и с напильником вместо перфоратора, но процесс идет. И опять же, это если говорить о возрастных и критичных проектах. Новые же проекты сразу пишутся на Java 11 и 13, Kotlin, SpringBoot 2, Kafka, Spring Reactor/WebFlux.

Миф #4. Финтех это корпоративная почта only и запрет других коммуникаций


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

Самый же рабочий с точки зрения активности канал в Альфа-Банке это Slack. Причем используем там почти всё, что только дает делать сервис: напоминания, уведомления, привязки к тестовым средам, алерты от мониторинга и многое другое. Это реально удобно.

Миф #5. Если мониторинг то вендорский и дорогой


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

Но ещё у нас есть Zabbix, например. Микросервисы же мониторятся с помощью Grafana, Micrometer и Prometheus. Последний, кстати, подкупил нас тем, что возможностей там уйма, а интеграция при этом довольно проста. Вообще, мониторинга много не бывает, и с помощью Prometheus мы мониторим почти всё, включая лаг синхронизации Kafka-кластеров через MirrorMaker.

Миф #6. Любая доставка на продакшн в банке это бюрократический ад


Судя по ситуации на рынке, это сильно зависит от банка. Мы пошли по пути пайплайнов на Jenkins и Bamboo. Когда процесс доставки в достаточной мере автоматизирован с помощью CI/CD, то почти никогда не нужны дополнительные письма, согласования, заявки и прочее добро. То есть, процесс выглядит примерно так:

  • Разработчик запускает процесс.
  • Проходят автоматические тесты.
  • Инженер саппорта одобряет раскатку на прод.
  • Новая функция улетает на ограниченное количество пользователей.

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

Alfa Battle


Как мы уже писали, скоро пройдёт Alfa Battle, онлайн-чемпионат по прикладному программированию на Java от нас и наших партнеров Билайн, X5 Retail Group и Jug.ru.

Если хотите присоединиться и попробовать свои силы вот страница регистрации. Отбор ещё идёт, до 25 июня.

Если же хочется просто посмотреть, то 27 июня будет стрим, с 12.00 до 18.00.
Подробнее..

Нейросетевой подход к моделированию карточных транзакций

19.04.2021 14:06:47 | Автор: admin

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

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

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

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

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

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

Признаки карточных транзакций

название признака

описание

Кол-во уникальных значений

currency

Идентификатор валюты транзакции

11

operation_kind

Идентификатор типа транзакции

7

card_type

Уникальный идентификатор типа карты

175

operation_type

Идентификатор типа операции по пластиковой карте

22

operation_type_group

Идентификатор группы карточных операций, например, дебетовая карта или кредитная карта

4

ecommerce_flag

Признак электронной коммерции

3

payment_system

Идентификатор типа платежной системы

7

income_flag

Признак списания/внесения денежных средств на карту

3

mcc

Уникальный идентификатор типа торговой точки

108

country

Идентификатор страны транзакции

24

city

Идентификатор города транзакции

163

mcc_category

Идентификатор категории магазина транзакции

28

day_of_week

День недели, когда транзакция была совершена

7

hour

Час, когда транзакция была совершена

24

days_before

Количество дней до даты выдачи кредита

23

weekofyear

Номер недели в году, когда транзакция была совершена

53

hour_diff

Количество часов с момента прошлой транзакции для данного клиента

10

amnt

Нормированная сумма транзакции. 0.0 - соответствует пропускам

inf

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

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

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

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

Подробнее..

Категории

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

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru