Почему ML-команды постоянно перестраивают одни и те же пайплайны
Скрытая стоимость машинного обучения в масштабе - не модели, а дублированная работа по инжинирингу признаков, которую каждая команда делает независимо. Что такое feature store и нужен ли он вам.
Когда компания запускает больше одной-двух ML-моделей в продакшене, проявляется паттерн, который никто не планировал. Каждая команда, строящая модель, также строит пайплайн для вычисления входных данных - признаков, - которые нужны модели. Модель оттока вычисляет количество дней с последней покупки. Модель ценообразования вычисляет то же самое. Модель рекомендаций - тоже. Три команды, три пайплайна, три обязательства по поддержке, три места, где ошибка в исходных данных даёт три разных неверных ответа.
Это не граничный случай. Это один из наиболее устойчивых паттернов, который я вижу в компаниях, прошедших фазу пилотов и запускающих ML в реальном масштабе.
Почему это происходит
Инжиниринг признаков - преобразование сырых данных во входные данные для модели - это место, где живёт большая часть реальной работы в ML. Это также та часть, которая выглядит уникальной для каждого проекта и поэтому легко обосновывает пересборку.
На практике многие признаки используются сразу в нескольких моделях. Сигналы поведения клиентов - давность, частота, средний чек - появляются почти в каждой клиентоориентированной модели. Сигналы доступности и ценообразования появляются как в прогнозировании спроса, так и в моделях ценообразования. Общие сигналы, построенные независимо, со временем расходятся, потому что исходные данные меняются, а команды исправляют ошибки по собственным расписаниям.
Стоимость расхождения
Наиболее очевидная стоимость - поддержка. Три пайплайна для одного признака означают три места для обновления при изменении схемы источника.
Менее очевидная стоимость - несогласованность между обучением и обслуживанием. Модель обучается на исторических признаках, вычисленных одним способом. В продакшене тот же признак вычисляется пайплайном другой команды. Значения похожи, но не идентичны. Модель работает хуже, чем на оценке, и никто не может объяснить почему.
Это называется training-serving skew, и это одна из сложнейших проблем для диагностики в продакшн-ML, потому что она не производит ошибок - она производит тихо деградирующие предсказания.
Что такое feature store
Feature store - система, отделяющая вычисление признаков от обучения и обслуживания модели. Команды определяют признаки один раз в центральном реестре. Вычисление запускается по расписанию и сохраняет результаты в двух местах: исторический стор для обучения и низколатентный стор для обслуживания.
Модели разных команд могут использовать одни и те же признаки. Когда определение признака обновляется, каждая модель, использующая его, подхватывает изменение. Обучение и обслуживание читают из одного стора.
Это не новая идея - некоторые крупные технологические компании строили внутренние версии несколько лет назад. В 2017 году экосистема открытых инструментов ограничена, но концепцию можно реализовать с простой инфраструктурой: слой вычисления признаков, таблица в хранилище данных для исторических запросов и хранилище ключ-значение для онлайн-обслуживания.
Когда это реально нужно
Feature store оправдан, когда у вас несколько команд строят модели независимо, когда одни признаки используются в более чем одной модели и когда у вас бывают инциденты с training-serving skew, которые невозможно объяснить.
Он не оправдан, когда у вас одна-две модели, одна команда данных и относительно стабильные признаки. Накладные расходы на обслуживание общего реестра реальны, и они добавляют координационные издержки, которые небольшой команде не нужны.
Практический минимум
Если вы не готовы к полноценному feature store, более простая версия дисциплины всё равно полезна: ведите центральный документ или заметку с каноническим определением общих признаков - как каждый вычисляется, из какого источника, на каком уровне детализации. Когда две команды собираются независимо вычислять один и тот же признак, направьте их к общему определению и сделайте пайплайн одной команды источником.
Это не устраняет все проблемы, но ловит наиболее дорогостоящие: расходящиеся определения и необнаруженное дублирование. Формальный инструментарий придёт позже, когда вы поймёте, какие признаки реально общие и насколько болезнен текущий подход в операционном плане.