Привет, Хабр! На связи команда ad-hoc аналитики и модельного риска X5 Tech. В прошлой статье про модельный риск мы познакомились с концепцией risk-management’а для моделей машинного обучения в корпорации и оценили, какую пользу может принести модельный риск как для команд-разработчиков и аналитиков, так и для компании в целом.
В этой статье мы продолжим тему модельного риска, раскроем чуть больше секретов о том, как это устроено в X5 Tech и обсудим некоторые технические аспекты реализации подобной системы.
Из чего состоит модельный риск
Давайте разберёмся, из каких элементов состоит модельный риск.
Несложно догадаться, что модель и риск – это основные сущности, которые нам понадобятся, однако их взаимодействие может быть не таким тривиальным.
Модель — это центральный объект, вокруг которого строится дальнейшая логика работы системы.
Любая модель в нашей системе обладает следующими базовыми полями:
uuid модели;
название модели;
ссылка на репозиторий модели;
ссылка на документацию;
токен интеграции;
продукт/команда-владелец модели;
бизнес-владельцы модели;
технические владельцы модели.
Бизнес-владельцы модели — это сотрудники, отвечающие за нетехнические аспекты работы модели (работа с предсказаниями, принятие решений и др.).
Технические владельцы — это ML-инженеры, Data Scientist’ы и разработчики, отвечающие за технические аспекты работы модели.
Токен интеграции используется для того, чтобы обеспечить безопасный канал получения данных работы конкретной модели. Его используют разработчики при интеграции модели, и на стороне сервера производится валидация токена.
Риск — это событие, которое мы хотим отслеживать у модели, и при необходимости реагировать на его активацию. Важно, чтобы мы могли следить за состоянием модели путём постоянной проверки ассоциированных с ней рисков.
Ниже рассмотрим примеры возможных рисков:
Отсутствие вызова модели (модель не прислала предсказания).
Отсутствие данных валидации модели (модель не обновила метрики на новых данных).
Невозможность получить доступ к мета-информации о модели (ссылка на документацию невалидна).
У модели отсутствует/не указан владелец.
У модели нет ассоциированных метрик.
У модели нет ассоциированных с ней источников данных.
Метрики на валидации находятся вне допустимых границ, заданных владельцем.
Изменилась структура исходных данных, на которых работает модель, с момента обучения модели.
Таким образом, риском может быть любое событие, которое может иметь разную степень критичности и разные уникальные для каждой модели параметры.
Например, для одной модели важно, чтобы она обновляла значение метрик каждый день, а для другой – раз в месяц.
Поэтому мы пришли к концепции кастомизируемых рисков, что позволяет не просто считать все риски одинаково для всех моделей, а настраивать их под специфику каждой из моделей. Более подробно пример реализации кастомизируемых рисков мы рассмотрим далее в статье.
Модельный риск решает задачу мониторинга работы моделей и alerting’а о возникающих рисках, поэтому важно не только понимать, что с моделью “что-то не так”, а понимать, с чем конкретно связан инцидент и вовремя оповещать ответственных лиц для его устранения.
Чтобы понимать степень критичности рисков, введём понятие статуса модели.
Статус модели – это состояние модели на текущий момент, которое определяется по совокупности реализовавшихся рисков из числа тех, которые ассоциированы с данной моделью.
Степень критичности риска – это один из параметров, который настраивается при кастомизации риска под модель. Для каждой модели степени риска могут принимать следующие значения:
0 – данный риск не релевантен для модели;
1 – риск имеет низкий уровень критичности;
2 – риск имеет средний уровень критичности, необходимо обратить внимание;
3 – риск имеет высокий уровень критичности, необходимо принять действия по его устранению.
Далее по сумме критичности сработавших рисков мы можем присвоить статус для каждой из моделей и отобразить его в интерпретируемом виде, например:
“Зелёный” статус: сумма критичности < 1.
“Жёлтый” статус: сумма критичности от 1 до 2.
“Красный” статус: сумма критичности 3 и более.
Следующий важный аспект – это план действий (action plan), который нужно сделать, чтобы устранить возникший инцидент. Не для каждой модели и не для каждого риска можно принять конкретный план действий, но даже примерное понимание того, “что упало” позволит оперативнее среагировать на возникший с моделью инцидент.
Например, если модель должна обновлять предсказания каждый час и сработал риск, что модель не обновила предсказание, то, вероятно, возникла проблема в инфраструктуре или развёртке модели.
При реализации подобной системы также важно построить:
Ролевую модель — корректную связку между владельцами модели, их иерархией в компании, с возможностью передачи прав на модель новым владельцам.
Связь технических и бизнес-метрик — важно учитывать не только технические метрики качества работы моделей (MSE, ROC-AUC, F-score и др.), но и их влияние на бизнес-метрики, с которыми связана работа модели. Это позволяет точнее определять причину возникших инцидентов и оценивать их влияние на работу компании.
Непротиворечивые источники данных – выстроить систему связки моделей с общими источниками исходных данных, чтобы предотвращает дублирование сущностей.
Модельный риск с точки зрения пользователя
Рассмотрим, как выглядит взаимодействие с платформой модельного риска с точки зрения пользователя на схеме ниже:
Первый этап взаимодействия с платформой – это регистрация самой модели. В прошлой статье мы рассказывали более подробно о том, что мы называем моделью в модельном риске.
Далее владелец модели вносит основную информацию о модели: какую задачу она решает, какие прокси и бизнес-метрики для неё применимы, на каких исходных данных происходило обучение, список стейкхолдеров, их роли и др.
После этого необходимо указать, какие риски релевантны для модели. Мы предлагаем набор базовых рисков с возможностью их кастомизации. Как правило, для пользователей этот процесс интуитивно понятен, но в некоторых случаях могут потребоваться консультации как по технической части рисков, так и по возможным финансовым убыткам при возникновении инцидентов.
После внесения всей информации про модель ей присваиваются uuid и token. Это позволяет авторизовать пользователя при взаимодействии с системой. При подключении модели все её логи начинают дублироваться в систему мониторинга через запросы к API системы: переобучение, предсказания, переоценка метрик и др.
Когда модель зарегистрирована и подключена, она попадает в общий реестр моделей, и её владельцы имеют возможность изменить информацию о ней в любой момент.
Каждое изменение модели имеет собственную запись в платформе и является самостоятельным объектом со своим идентификатором и необходимой информацией. Это позволяет отслеживать изменения, происходящие с моделями, и вести историю изменений: могут появляться новые источники данных, могут добавляться и удаляться прокси-метрики, позволяющие отслеживать её качество, может изменяться функционал модели, и это также может быть отражено в описании и зафиксировано в истории изменений.
Таким образом, после подключения модели в систему модельного риска автоматически становятся доступными функции:
Мониторинг модели и логирование истории её развития.
Оповещения о возникающих инцидентах.
Формирование кастомных отчётов по отдельным моделям и по всем моделям в команде, департаменте, компании.
Весь процесс регистрации и подключения одной модели занимает в среднем 15-20 минут и помогает не только “отслеживать” модели, но и помогает оптимизировать работу DS/ML-команд. Например, в среднем команда, владеющая одной и более моделями в компании затрачивает порядка 10-20% времени на разработку и поддержку системы мониторинга для своих моделей. Модельный риск сокращает эти затраты на несколько порядков.
Концепция абстрактных рисков
В общем случае, для каждой модели присутствует свой список уникальных рисков. При такой реализации масштабирование подобной системы было бы утопичным с точки зрения уникальных сущностей и артефактов. Поэтому мы рассматриваем каждый из реализованных рисков как абстракцию, базовая логика которой наследуется при кастомизации.
Давайте рассмотрим пример. Допустим, у нас есть риск, отвечающий за то, что каждое последующее значение метрик при их обновлении не должно выходить за определённые границы. Сама логика подсчёта данного риска по исходным данным является базовой для всех моделей.
Далее мы добавляем параметр времени (как часто требуется считать этот риск – при обновлении данных, раз в 10 минут и т. д.). Со значением этого параметра риск является кастомным.
Риски невозможно посчитать без привязки к модели, поэтому мы добавляем информацию про модель: по каким метрикам и значением метрики необходимо считать риск, какая критичность риска для этой модели и др. Связка модели и риска и является той сущностью, по которой мы финально рассчитываем риски.
Таким образом, для каждого риска нам нужно обозначить его базовую логику и понять, как он может быть кастомизирован. Такой подход позволяет эффективно масштабировать платформу на все ML-модели. Каждый последующий реализованный риск является независимой сущностью и может быть применён ко всем моделям.
Подводим итоги
В этой статье мы погрузились в некоторые технические и архитектурные аспекты системы модельного риска.
Самое важное при разработке подобной системы – это внедрение в процессы компании и учёт специфики моделей и внутренних процессов.
В следующих статьях мы расскажем, как ещё можно использовать модельный риск и применять подобный подход для других задач, которые могут быть не связаны с моделями машинного обучения.
Над статьёй работали: