Разделы

ИТ в банках

Павел Николаев, банк «Открытие», в интервью CNews — об опыте настройки общебанковской MLops-платформы

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

«Внедрение платформы моделирования IRIS, построенной на принципах MLops, стало для банка значимым технологическим шагом вперед»

CNews: Павел, давайте для начала напомним, каким целям служит общебанковская платформа моделирования и что она из себя представляет.

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

Павел Николаев, банк «Открытие»: Крупные банки используют аналитику в различных областях своей деятельности

Внедрение платформы моделирования IRIS, построенной на принципах MLops, стало для банка значимым технологическим шагом вперед. Банк централизовал процессы разработки и внедрения моделей и перевел их в единую промышленную платформу. Платформа полностью построена на OpenSource стеке технологий по принципу CI/CD (continuous integration / continuous delivery): изменение скриптов разрабатываемых моделей версионируется в GitLab, автоматизирован пайплайн доставки модели из среды разработки в среду применения (Jenkins, MlFlow, Airflow). Вся платформа — и среда разработки, и среда применения моделей — построены на принципах микросервисной архитектуры (Kubernetes). Среда применения моделей интегрирована со всеми пятью банковскими системами принятия решения (СПР): двумя розничными (для онлайн и оффлайн кредитных процессов), кредитными конвейерами КИБ, МСБ и кредитным конвейером нового блока Автобизнес. Таким образом, любая разработанная на платформе онлайн модель принятия решения может быть перенесена из среды разработки в среду применения всего за пару кликов: платформа автоматически перенесет модель и развернет ее как REST-сервис. Конечно, даже при имеющейся интеграции с системами принятия решений, для внедрения новой модели потребуются небольшие доработки на стороне СПР. Чтобы СПР передала модели нужный вектор факторов из бизнес-процесса. Но, как показывает практика, такие доработки занимают всего около недели.

До создания платформы внедрение моделей принятия решения занимало несколько месяцев: разработчикам моделей требовалось написать бизнес требования (БТ) на внедрение модели и заявить задачу в бэклог другой команды, развивающей СПР; дождаться анализа, принятия в работу, реализации и окончания тестирования данной задачи. Модель переписывалась технологами СПР по написанному БТ на другой язык (обычно диалекты Java). В результате могли возникать проблемы в тестировании модели: технологи СПР не занимались моделированием и программировали модель «технически» по БТ, иногда допуская ошибки; разработчики моделей не знали языка, на котором была закодирована модель, и тестировали внедренную модель как «черный ящик». К сожалению, из-за этих особенностей процесса иногда происходили ошибки при внедрении моделей. А внедрение сложных моделей (ансамблевые модели, нейросети) старым методом в СПР было просто невозможно.

Таким образом, возможность разрабатывать и внедрять онлайн и оффлайн модели машинного обучения на одной промышленной платформе значимо сократили time-to-market (TTM) моделей банка (на 2-3 месяца) и снизили риск их операционного внедрения. Платформа введена в промышленную эксплуатацию и отказоустойчива. Это значит, что в случае возникновения проблемы с серверами основного контура она автоматически переключается на резервный, функционирующие в платформе модели этого просто «не замечают».

За 8 месяцев активной эксплуатации платформы не зафиксировано ни одного значимого сбоя

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

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

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

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

CNews: На решение каких коммерческих задач нацелена новая платформа? И какими средствами она помогает их решить?

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

Чтобы модели правильно работали, за ними нужно пристально «следить»: тестировать их при запуске в эксплуатацию и производить мониторинг после внедрения. Цель мониторинга — отслеживать возникающие при работе моделей ошибки и контролировать соответствие параметров качества работы модели, заложенным при ее разработке.

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

Строго соблюдаются правила тестирования онлайн-модели при ее вводе в промышленную эксплуатацию. Модель со среды разработки переносится в dev-среду, на которой отлаживается. И далее переносится в preprod контур, полностью копирующий по своему окружению prod-контур. На preprod контуре модель некоторое время функционирует в ветке бизнес-процесса без принятия решения. Таким образом, в «боевых» условиях симулируется реальная работа модели и выявляются потенциальные ошибки. Также платформа предоставляет возможность проведения A/B тестирования, когда один поток клиентов может обрабатываться по различным правилам и моделям (например, на небольшой доле потока тестируется новый продукт).

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

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

«Если два или более человека отвечают за какой-то этап внедрения модели, то, как показывает практика, в итоге не отвечает никто»

CNews: Как проходила настройка процесса тестирования моделей?

Павел Николаев: Есть у нас в анамнезе, к сожалению, случаи реализации операционных рисков, знаем, где что может болеть при внедрении модели. Много работали над релизным циклом модели на новой платформе, чтобы покрыть риски инструментарием и зонами ответственности. Если два или более человека отвечают за какой-то этап внедрения модели, то, как показывает практика, в итоге не отвечает никто. Это можно сравнить с конвейером на заводе, где на каждом этапе технический контроль возглавляет только один человек. За ИТ-тестирование должен отвечать айтишник, за тестирование правильности расчетов факторов для модели — риск-технологи, методологи и помогающие им дата-инженеры (поэтапно, каждый за свой этап), а за модель в целом — ее владелец.

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

CNews: В чем заключается проблема управления вычислительными ресурсами платформы. И какое для нее найдено решение?

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

Мы исходили из разного профиля использования вычислительных ресурсов разными типами моделей. Есть критичные онлайн-модели с высокой нагрузкой — розничные модели и модели МСБ. Они должны в течение миллисекунд отдавать ответ, потому что на них непрерывно приходит поток заявок.

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

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

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

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

Для проведения «тяжелых» расчетов в среде разработки моделей выделена отдельная нода. На ней обучаются сложные алгоритмы или проводится работа с big data, с терабайтами данных. Нодой для «тяжелых» расчетов пользуется один разработчик, она выделяется по расписанию и букируется заранее. Благодаря этому «тяжелый» процесс не мешает большому количеству более «легких» процессов обучения моделей.

CNews: Система гибкая, требования пользователей — разные. Как правильно настроить платформу для всех команд data scientists?

Павел Николаев: Это основная проблема, можно сказать, философская. Изначально мы позиционировали платформу как максимально гибкую, чтобы пользователям было выгодно на нее переходить с локальных машин. Наши пользователи — datascientist’ы или разработчики моделей и дата инженеры — это программисты и математики в одном лице, использующие множество специализированных библиотек для построения тех или иных моделей. У каждой библиотеки есть большое количество версий. Скрипты моделей, работающие с одной версией библиотеки, могут не работать с другой. Поэтому для каждой DS-команды создается свое индивидуальное окружение, состоящее из 600-800 библиотек определенных версий.

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

CNews: Как выстраивался процесс поддержки и управления изменениями платформы?

Павел Николаев: Сейчас мы пришли к этапу зрелости платформы. Главное, чтобы все, что сделано, не ломалось и было удобно в поддержке, а все, что вновь привносится, ложилось в уже имеющуюся структуру. Именно поэтому мы разрабатываем большое количество шаблонов как для приема новых заявок, так и для коммуникации с пользователями. Чтобы поддержка понимала, при каких случаях неработоспособности либо даже подозрении на снижение работоспособности контура должны уведомляться пользователи. Также выстраиваем процесс взаимодействия второй и третье линий поддержки платформы. Поддержка должна четко понимать, какой запрос более приоритетен, какой менее, какой вообще не стоит брать в работу, как в принципе работать с инцидентами и ошибками. Система интегрирована с большим количеством других банковских систем (5 систем принятия решения, Hadoop, корпоративное хранилище и т.д), на нее завязана большая доля критичных процессов банка (как минимум, все процессы кредитования). Специалисты поддержки должны правильно определять и локализовывать ошибки, чтобы они не отразились на всех других пользователях контура.

Краткая биография

Павел Николаев

«Новая реальность пока не оказала существенного влияния на планы по развитию нашей платформы»

CNews: С какими вызовами столкнулись после 24 февраля? Удается ли с ними справляться?

Павел Николаев: Конечно, после начала спецоперации ситуация резко осложнилась. Слава богу, платформа разработана на open source стеке технологий. То есть у нас нет лицензионного ПО, все оно фриварное и общедоступное. Поэтому проблем с отзывом лицензий западными поставщиками у нас не было.

Но были другие проблемы. В версиях OpenSource библиотек для пользователей России и Белоруссии, созданных после 24 февраля, может содержаться вредоносный код. Соответственно, если раньше обновления библиотек совершались по сути на лету (библиотеки автоматически обновлялись из внешних репозиториев, пересборка образов происходила автоматически), то теперь мы поставили «стену» между банком и внешним миром. Обновляемую библиотеку требуется сперва загрузить во внутренний репозиторий, проверить ее безопасность и только после этого добавлять в сборку нового образа. В итоге сильно осложнился процесс обновления ПО и библиотек. Старое работает хорошо, а вот чтобы собрать новое, нужно изрядно «попотеть». Тем не менее, сейчас мы планируем автоматизацию уже нового, «защищенного» процесса обновления ПО, после которого, думаю, проблема будет устранена.

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

Также у нас в планах — автоматизация жизненного цикла управления моделями и создание общебанковского Feature Store для подготовки данных для моделирования. Чтобы по аналогии с подходом MLops, привнесенным в банк платформой IRIS, в части подготовки данных для моделирования мы перешли на схожий по концепции подход DataOps и существенно сократили бы за счет него time-to-market для моделей.

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