Модельный риск: как увеличить эффективность работы ML моделей в большой компании
Привет, Хабр! В этой статье мы — Святослав Орешин и Александр Сахнов — попытались разобрать достаточно специфичную для классического Data Science и критически важную для бизнеса тему — модельный риск или risk management для машинного обучения.
Расскажем о том, как можно сделать машинное обучение в компании более эффективным, какие бывают риски у ML моделей и как на них реагировать, а также делимся своим опытом, как мы построили систему по модельному риску в X5 Tech — компании с сотнями ML моделей в production.
В современных компаниях машинное обучение используется повсеместно — начиная от предсказания ключевых для бизнеса показателей, до голосовых помощников на основе языковых моделей. При разработке и обучении новой модели обычно основное внимание уделяется данным, метриками, архитектуре и решаемой задачи, и только в редких случаях команда задумывается о поддержке и управлении моделями в будущем.
А в чем, собственно, проблема?
Чтобы лучше понять, откуда возникает потребность в модельном риске, давайте сначала разберем этапы развития компании.
Вы запускаете стартап со своими друзьями. Вы можете общаться и синхронизировать свои задачи каждый день, у вас есть четкое разделение обязанностей. Как только ваш стартап стал расти, вы нанимаете уже несколько десятков сотрудников, и у вас естественным образом возникает потребность в построении иерархии, в HR отделе, project manager«ах и в системе по управлению персоналом в целом.
Такая аналогия применима и для систем хранения данных: когда их невозможно хранить в отдельных Excel таблицах, возникает потребность в базах данных. А в ситуации, когда компания накапливает и обрабатывает терабайты данных ежедневно, возникает потребность в платформах и инструментах для обработки больших данных, таких как Hadoop и Spark.
Проведем подобную аналогию с DS. Представьте, что вы решаете DS задачу и обучаете модель на одной относительно небольшой таблице. После деплоя модели может возникнуть множество проблем, связанных с поддержкой актуальности входящих данных, и необходимость периодически переобучать модель и отслеживать метрики. В большой компании всё усложняется тем, что параллельно работают несколько десятков DS команд, обрабатываются тысячи таблиц с разными источниками данных и разной логикой их обновления. В этот момент возникает естественная потребность в централизованной системе по учету, мониторингу, алертингу и управлению реестром всех ML моделей, ведь модель — это «наконечник» данных.
Таким образом, потребность в работе с модельными рисками возникает с ростом количества моделей и DS команд в компании. Однако, потребность в мониторинге — это лишь вершина айсберга. Зачастую, гораздо более критичный момент — это поддержка и актуализация работы и метрик моделей, что приводит к значительным финансовым убыткам и нецелевым тратам бюджета.
Что такое модельный риск и какие бывают риски
Для того, чтобы формализовать понятие риска, давайте рассмотрим общий процесс жизненного цикла модели и выделим основные проблемы на каждом из этапов:
По схеме видно, что самые частые проблемы в каждом из циклов модели достаточно общие, а причины их возникновения могут довольно сильно отличаться.
Поэтому мы решили выделить основные категории рисков, чтобы можно было не только говорить что «всё плохо», но и предлагать действия для корректного реагирования на каждый из рисков. У нас получилось выделить 4 основные категории рисков, давайте рассмотрим их с примерами возможных маркеров.
Риски, связанные с состоянием модели
Риски, связанные с исходными данными
Изменилась структура исходных данных модели.
Исходные данные не обновлялись n дней.
В исходных данных значимо изменились распределения.
Риски, связанные с информацией о модели / bus factor модели
Не заполнена актуальная информация о документации модели, метриках, владельцах, стейкхолдерах и решаемой задачи.
Pipeline обучения модели не воспроизводим.
Другие риски
Значение метрики или количество предсказаний в единицу времени значительно изменились.
Обратная связь от пользователей модели о необычном поведении.
Baseline решение превышает последнее значение целевой метрики.
Важно учесть, что конкретные риски и значение параметра n зависят от конкретной модели и могут иметь разную степень критичности. Мы привели лишь несколько примеров возможных рисков, в реальности их может быть сильно больше и они могут быть специфичнее. При ассоциации каждой конкретной модели с рисками важно учитывать как специфику самой модели и решаемой задачи, так и важность модели для бизнеса и ее финансовые эффекты.
Попытка оценить убытки от рисков, связанных с моделями
Посчитать даже примерные убытки, которые несет компания из-за отсутствия системы по управлению модельными рисками, — задача достаточно сложная, но мы попробуем получить примерную финансовую оценку возможных убытков.
Представим, что у нас есть модель Х, стоимость разработки и поддержки которой составляет примерно 10 млн рублей в год. Для простоты расчетов предположим, что все модели приносят компании одинаковое количество выручки.
Оценим все возможные риски, которые могут возникнуть у модели.
Пусть риски и, соответственно, убытки распределены нормально. Получим примерно такое распределение:
Таким образом, оценив среднее влияния рисков с одной модели, получим, что при оптимистичном сценарии мы несем около 20% убытков (от целевого бюджета), а при пессимистичном — более 50% убытков.
Получается, что если в компании есть 50 моделей со средней стоимостью 10 млн рублей в год на каждую, то компания терпит от 100 до 250 млн рублей убытков каждый год из-за реализации модельных рисков.
Мы рассматривали сценарий, при котором модельные риски приводят только к нецелевому расходованию бюджета, но в реальности компания терпит дополнительные убытки, т. к. часто предсказания моделей переиспользуются в разных процессах, и убытки могут суммироваться и приводить к дополнительной нагрузке на персонал.
Модельный риск в X5 Group
На рынке есть решения, которые позволяют выстроить систему по мониторингу модельных рисков и управлению моделями (например, MLFlow), однако в нашем случае они покрывают лишь незначительную часть решаемых проблем, достаточно плохо масштабируются и адаптируются под конкретные модели и задачи. Поэтому мы разрабатываем собственное решение, которое позволит связать бизнес и разработчиков модели, вести реестр моделей компании, своевременно оповещать и реагировать на возникающие риски.
В этой статье мы не будем вдаваться в технические подробности реализации модельного риска в X5. В общем случае логика работы системы выглядит следующим образом:
Разработчик регистрирует модель в системе и вносит основную информацию о модели и решаемой задаче.
Модель подключается к системе и начинает дублировать все входящие и исходящие запросы к ней.
Система периодически производит расчет и оценку возможных рисков.
В случае возникновения рисков производится оповещение ключевых сотрудников о рисках и предлагаются действия по реагированию.
Актуальное состояние и показатели по каждой модели отображаются на дашборде.
Для внедрения модельного риска в процессы компании важно определить понятие модели. В нашем случае понятие модель в модельном риске (как и в DS в целом) достаточно формально. Мы выделили основные критерии, по которым мы определяем, можно ли использовать модель в нашей системе:
Модель выполняет определенную бизнес-логику.
За моделью закреплен ее владелец (или несколько владельцев).
Модель работает в production-среде.
Имеет одну и более прокси-метрик.
Таким образом, мы связываем сущность модели с конечной решаемой задачей. Например, если у вас есть модель XGBoost, в которой изменились значения гиперпараметров или feature engineering, то для нас это та же самая модель новой версии. Однако, если у модели изменился таргет, но сохранилась архитектура, то в нашем случае мы считаем, что это новая модель.
Такую систему и логику работы с моделями можно использовать не только для «классических» ML моделей. Например, в качестве модели в модельном риске мы можем использовать службу поддержки магазинов, а в качестве метрик — основные показатели по решаемым запросам:
Внедрение модельного риска требует изменения процессов в компании, а также проведения внутренних PR-кампаний как среди DS команд, так и среди стейкхолдеров из бизнеса. В X5 Tech уделяется особое внимание оценки эффективности внутренних продуктов и инициатив, и модельный риск — это лишь один из способов оценить эффективность работы того или иного продукта. Для содействия DS командам в интеграции моделей мы привлекаем специалистов из ad-hoc команды, внедряем продукт в имеющиеся процессы по поддержке моделей, и самое главное — не нагружаем разработчиков дополнительной формальной работой, а помогаем им увеличить эффективность их работы и постоянно дорабатываем функциональность продукта под их запросы.
Как понять, что вам нужен модельный риск
Подобная система по модельному риску требует отдельной команды по разработке и внедрение в процессы. Поэтому мы выделили основные критерии, по которым можно оценить целесообразность разработки и внедрения подобной системы:
Сложность моделей — необходим контроль из-за сложности pipeline«ов и трудности интерпретации.
Критичность решений — высокая степень критичности решений, основанных на предсказаниях модели.
Динамичность данных — частые изменения и вариативность исходных данных.
Регулятивные требования — строгие стандарты для моделей машинного обучения.
История ошибок — уже возникшие проблемы с работой и валидацией моделей.
Систематизация — множество моделей, приводящее к дублированию и удлинению разработки.
Сложно оценить равнозначность критериев, однако если в вашей компании есть хотя бы половина из них, то это хороший повод задуматься о модельном риске.
Подведение итогов и дальнейшие планы
В этой статье мы затронули лишь небольшую часть из того, что на самом деле представляет из себя модельный риск. В дальнейших статьях мы планируем рассмотреть технические аспекты и архитектуру, а также конкретные примеры, когда модельный риск позволил обнаружить и среагировать на достаточно неочевидные, но критичные риски.
Развитие системы модельного риска может быть как «вширь» — расширение usecase«ов применения и подключения большего количества возможных моделей, так в «вглубь» — реализация логики более специфичных рисков и адаптация функционала под интеграцию для более сложных моделей и pipeline«ов.
При правильном продуктовом подходе каждая последующую модель в модельном риске позволяет переосмыслить систему и накопить больше данные, и таким образом лучше оценить эффекты от внедрения, оценить связь прокси-метрик модели с бизнес-метриками, обнаружить и реализовать логику подсчета новых рисков и масштабировать эту логику на все модели в системе.
Над статьей работали:
Орешин Святослав
Александр Сахнов
Йокша Дмитрий
Максим Попов
Николай Назаров
