Разработка feature store для финансовых ML моделей: подходы к управлению признаками на стыке макро- и микроданных

В финансовой сфере машинное обучение достигло этапа, где главным вызовом для внедрения и расширения моделей является не столько разработка новых алгоритмов, сколько действенное управление данными, которые эти алгоритмы используют. Финансовые ML-модели, например системы оценки заемщиков, алгоритмы определения мошенничества, системы динамического ценообразования и торговые стратегии, имеют особенность: их успех зависит от возможности объединять и согласовывать данные разных уровней. С одной стороны, это микроданные – детальные, частые транзакции и действия определенного клиента или инструмента, которые показывают его личное поведение. С другой стороны, это макроданные – общие показатели состояния экономики (ключевая ставка, инфляция, изменение рынков), которые формируют общий контекст этого поведения. Традиционные способы подготовки признаков (feature engineering), когда каждая команда самостоятельно получает, преобразует и поддерживает свои наборы данных, становятся препятствием. Это ведет к повторению работы, несогласованности признаков между обучением и применением модели, потере возможности повторить эксперименты и, в итоге, к снижению качества и надежности моделей в работе. Решением этой проблемы является Feature Store (хранилище признаков) – центральное хранилище с контролем версий, предназначенное для предоставления актуальных и согласованных признаков как при обучении моделей, так и в реальном времени при прогнозировании. Но, разработка Feature Store для финансов имеет свои сложности, главная из которых – управление, преобразование и совместное использование признаков, полученных из разных макро- и микроданных.

Feature Store – это платформа, встроенная в ML-жизненный цикл, которая обеспечивает поток данных от источников до моделей, делающих прогнозы. Архитектура состоит из нескольких слоев. Слой источников объединяет разные данные: потоки транзакций (микроданные), базы данных клиентов, API-каналы с макроэкономической статистикой и рыночными данными в реальном времени, а также внешние источники новостей. Слой преобразования и инженерии признаков – это место, где определяются правила создания признаков. Важно, что эти правила (в основном в виде кода на SQL) хранятся в одном месте для повторного использования и контроля. Слой хранения делится на два сегмента: offline/store (хранилище исторических данных) и online/store (база данных с низкой задержкой с актуальными значениями признаков для онлайн-прогнозирования). Слой обслуживания предоставляет API для доступа к признакам в пакетном режиме для переобучения модели и в реальном времени для получения признаков по клиенту или сделке в момент запроса. Feature Store как эталон данных для признаков объединяет команды, ускоряет разработку и обеспечивает согласованность, что важно для надежного ML.

В финансах задача Feature Store усложняется из-за необходимости работать с данными разного типа. Микропризнаки, получаемые из транзакций и профилей, имеют высокую размерность и частоту обновления. Примером таких данных может быть скользящее среднее расходов клиента за 30 дней, частота обращений в поддержку, число отклоненных транзакций за неделю, процент использования кредитного лимита. Эти признаки связаны с конкретным клиентом или счетом и требуют сложных вычислений и обработки потоковых данных. Макропризнаки описывают внешнюю среду: ключевую ставку ЦБ, индекс волатильности, цену на нефть, отраслевые индексы. Они имеют низкую размерность, обновляются по расписанию и применимы ко всем: ключевая ставка – это признак для всех клиентов и моделей банка в данный момент.

Главная задача – правильно соединить эти два типа данных в одном пространстве признаков для обучения и прогнозирования. Для модели, которая прогнозирует вероятность невозврата кредита, набор признаков для клиента на определенную дату должен включать его личные показатели на эту дату и значения макропеременных на ту же дату. Это требует решения нескольких проблем. Во-первых, временное согласование. При обучении на прошлых данных нельзя использовать макростатистику, которая стала известна позже даты прогноза. Во-вторых, задержка данных. Макроданные публикуются с задержкой. Значение ВВП за квартал может стать известно через два месяца. При создании признака для онлайн-прогноза нужно решить, какое значение использовать: последнее известное или прогнозное. Это должно быть указано в правилах преобразования внутри Feature Store.

Для обработки этих зависимостей нужны подходы к организации вычислений. Один из них – многоуровневая материализация. Сначала вычисляются базовые агрегаты микроданных. На их основе строятся более сложные признаки. Макропризнаки создаются отдельно по своему расписанию. Последний шаг – это соединение данных на этапе создания набора данных для обучения или онлайн-запроса. Для обеспечения точности этих данных используется техника, которая для каждой временной метки микроданных находит последнее доступное значение макропеременной. В онлайн-режиме это соединение может быть заранее вычислено и сохранено. Другой способ – использование виртуализации признаков. Логика признака определяется, а его вычисление откладывается до момента запроса, при этом система автоматически строит оптимальный план выполнения, учитывая доступность данных и требования к задержке.

Финансовые модели часто контролируются. Это предъявляет требования к Feature Store в части управления. Нужен контроль версий не только кода моделей, но и кода преобразований признаков и самих данных. Должна быть возможность воспроизвести набор признаков, на котором была обучена модель, даже спустя годы. Это требует интеграции Feature Store с Git. Важен мониторинг изменений данных. Для макропризнаков нужно отслеживать выбросы или остановку потока данных. Для микропризнаков важен мониторинг распределений для выявления изменений в поведении клиентов. Feature Store должен предоставлять инструменты для такого мониторинга и отправлять уведомления при превышении пороговых значений.

Теоретические принципы, изложенные выше, были положены в основу проекта по созданию корпоративного Feature Store в банке. К моменту старта проекта были выделены классические проблемы масштабирования ML-практики: более 10 команд аналитиков из разных отделов использовали собственные пайплайны подготовки данных, что приводило к дублированию кода, несогласованности признаков в обучении, а также к сложности воспроизведения экспериментов. Особенно остро стояла проблема объединения микроданных (транзакции на 1 миллион клиентов) и макроданных (ключевая ставка, инфляция, отраслевые индексы), которые обновлялись с разной периодичностью.

Была разработана и внедрена Feature Store на базе платформы Hopsworks (впоследствии мигрировав на собственное решение, использующее ClickHouse для online store и HDFS для offline store). Ключевые архитектурные решения включали:

1. Двухуровневое хранение.
2. Offline Store (исторические данные) был реализован на базе HDFS и Spark. Сюда ежедневно выгружались срезы микроданных (транзакции, поведенческие признаки), обогащенные макропоказателями на соответствующую дату с учетом временных лагов публикации. Это обеспечило единую точку истины для обучения моделей.
3. Online Store (актуальные данные) был построен на ClickHouse, оптимизированном для низких задержек. Здесь хранятся текущие значения признаков для каждого клиента, готовые к выдаче в реальном времени.
4. Управление макропризнаками с учетом временных лагов. Был внедрен механизм point-in-time join, который автоматически учитывает задержки публикации макроданных. В спецификации каждого макропризнака добавились метаданные: источник (ЦБ, Росстат, биржа); периодичность обновления (ежедневно, ежемесячно); задержка публикации.
5. Версионирование и контроль качества. Все определения признаков (feature definitions) хранятся в виде Python-кода в Git-репозитории. Каждое изменение проходит код-ревью. Feature Store интегрирован с системой мониторинга: отслеживаются распределения ключевых микропризнаков и выбросы макропоказателей. При обнаружении аномалий срабатывают предупреждения и отправляются на почту разработчикам. 

Feature Store стал центральным компонентом ML-инфраструктуры банка. Интеграция была выполнена следующим образом:

1. Потоковые данные. Транзакции клиентов в реальном времени поступают из Kafka, агрегируются в окнах (с использованием Flink) и записываются в Online Store (ClickHouse) и в виде бэкапа в Offline Store.

2. Пакетные данные. Ежедневно из хранилища выгружаются витрины по клиентам и продуктам. Spark запускаются для вычисления сложных признаков (например, скоринговые баллы, кластеры поведения) и также записываются в оба хранилища.

3. Сервисный слой. Feature Store предоставляет два API:

• Batch API для DS-команд при обучении моделей.
• Online API для продуктовых систем. Когда клиент заходит в мобильное приложение или подает заявку на кредит, скоринговая система в реальном времени делает запрос к Online API, получая полный вектор признаков (микро + макро) за 30–50 мс.

Поскольку Online Store развернут в Kubernetes-кластере с динамическим масштабированием, все сервисы, потребляющие признаки, обращаются к Feature Store через внутренний балансировщик, который использует Consul для обнаружения доступных нод ClickHouse.

Внедрение Feature Store принесло как измеримый финансовый эффект, так и значительные операционные улучшения:

1. Ускорение time-to-market. Вывод новой модели в промышленную эксплуатацию сократился в среднем с 4-5 месяцев до 3-4 недель. DS-команды перестали тратить время на создание пайплайнов данных и просто используют готовые признаки из каталога.
2. Рост качества моделей. В частности, Gini скоринговой модели для потребительских кредитов вырос на 1.2 п.п., что напрямую транслируется в снижение потерь от дефолтов.
3. Снижение операционных затрат. За счет повторного использования признаков совокупные затраты CPU/GPU на вычисление признаков в масштабах банка сократились на 35%.
4. Совокупный экономический эффект. Суммарно за первый год эксплуатации, с учетом ускорения вывода моделей (и соответственно более раннего получения эффекта от них), повышения качества скоринга и экономии инфраструктурных ресурсов, эффект оценивается в 115 млн рублей.

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

Разработка Feature Store для финансовых ML-моделей – это создание важной инфраструктуры, которая является основой аналитической и прогнозной деятельности финансового института. Feature Store согласует данные об индивидуальных транзакциях с данными об экономике и превращает эти данные в согласованные и управляемые признаки. Это позволяет перейти к созданию масштабируемой экосистемы искусственного интеллекта, которая реагирует на изменения рынка и обеспечивает конкурентное преимущество в эпоху, когда данные и скорость их анализа важны.