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