Почему ML-команды переписывают одно и то же снова и снова
Feature store и управление признаками в машинном обучении: откуда берётся дублирование и как от него избавиться.
Когда компания запускает второй ML-проект после первого, почти неизбежно происходит одно и то же. Новая команда или тот же человек начинает писать код для подготовки данных. Потом выясняется, что значительная часть этой работы уже была сделана в прошлый раз. Код живёт в другом репозитории, в ноутбуке коллеги, или вовсе утерян после реорганизации.
Я называю это проблемой переписывания признаков. Признак в машинном обучении - это конкретная переменная, которую модель использует для прогноза: средний чек клиента за последние 90 дней, количество дней с последней покупки, доля отменённых заказов. Их вычисление требует обращения к данным, нормализации, агрегации. Это реальная работа. И она повторяется в каждом новом проекте.
Откуда берётся дублирование
Корень проблемы обычно организационный, а не технический. ML-проекты в компаниях чаще всего запускаются как отдельные инициативы с отдельными командами. Каждая команда решает задачу с нуля, включая подготовку данных.
Даже если технически можно взять код из предыдущего проекта, это часто не делается: другая версия библиотек, неизвестная логика, страх сломать что-то в чужом коде, просто быстрее написать заново. В итоге в компании существует пять версий вычисления "дохода клиента", три из которых считают по-разному.
Это создаёт не только технический долг. Когда разные модели используют разные версии одних и тех же признаков, результаты становятся несравнимыми. Бизнес теряет возможность понять, какая модель работает лучше и почему.
Что такое feature store
Feature store - это централизованное хранилище вычисленных признаков с версионированием и возможностью повторного использования. Идея простая: признак вычисляется один раз, описывается, сохраняется и доступен любой команде.
На практике это означает, что команда, которая строит модель оттока, может взять уже готовый признак "активность клиента за 30 дней" - тот же самый, что использует команда, которая строит рекомендательную систему. Логика вычисления единая, история хранится, результаты сопоставимы.
Это решение начали активно обсуждать и внедрять в больших технологических компаниях примерно с 2017-2018 года. Убер, Airbnb и другие публично описывали свои подходы. В 2019 году это перестаёт быть только темой для компаний уровня FAANG - вопрос становится актуальным для любой компании, которая запускает больше одного ML-проекта.
Как это связано с управлением данными
Feature store - это не инструмент для дата-сайентиста. Это инфраструктурное решение, которое требует участия на уровне архитектуры данных. Нужно решить, кто владеет признаками, кто их документирует, как они версионируются при изменении логики вычисления, как синхронизируются данные для обучения и для инференса в продакшне.
Последнее - отдельная тема. Классическая ошибка: признаки для обучения вычисляются в пакетном режиме на исторических данных, а в продакшне та же логика работает на потоке с задержками. Модель обучена на одном, работает на другом. Результаты хуже, чем ожидалось.
Практический ориентир
Если у вас в компании больше одного ML-проекта или вы планируете запускать следующий - стоит задать себе несколько вопросов:
- Где физически живёт логика вычисления признаков в каждом из проектов?
- Есть ли признаки, которые вычисляются в нескольких проектах независимо?
- Кто может ответить, как именно считается конкретный признак в продакшн-модели?
- Совпадает ли логика вычисления при обучении и при работе в бою?
Отсутствие ответов на эти вопросы - сигнал, что инфраструктурный долг уже накапливается. Решать его лучше до того, как количество проектов вырастет ещё в два раза.