Feature store: зачем и как

Когда десять моделей считают «средний чек за 30 дней» по-разному, наступает время feature store.

Feature store — централизованная система для вычисления, хранения и выдачи признаков, обеспечивающая их переиспользование и одинаковую логику в обучении и инференсе.

Проблема, которую решает feature store

Признаки (features) — это входы модели: «средний чек пользователя за 30 дней», «число заказов за неделю». В большой компании их сотни, и без центрального хранилища возникают три беды: команды считают один и тот же признак по-разному; дорогие вычисления дублируются; логика признака в обучении (на SQL по историческим данным) расходится с логикой в проде (на Python в реальном времени). Feature store устраняет всё это.

Два хранилища: офлайн и онлайн

Ключевая идея feature store — одно определение признака, но два хранилища под разные нагрузки:

При обучении модель забирает признаки из offline store за прошлые даты; в проде — из online store за миллисекунды по id пользователя. Логика расчёта при этом одна.

            +------------------------+
  сырые --> |  Определение признака  | --> материализация
  данные    |  (одна логика расчёта) |
            +-----------+------------+
                        |
          +-------------+--------------+
          v                            v
  +---------------+            +----------------+
  | Offline store |            |  Online store  |
  | (обучение)    |            |  (инференс)    |
  +---------------+            +----------------+

Point-in-time correctness

Самая хитрая часть — при сборке обучающей выборки взять значение признака на момент события, а не текущее. Если для заказа от 1 марта подставить «средний чек», посчитанный по данным до сегодня, в выборку утечёт будущее (data leakage), и метрика на обучении окажется лживо высокой. Feature store умеет делать point-in-time join — соединять события с признаками по правильной временной точке.

Переиспользование

Раз признак определён, его берут любые модели и команды. Новая модель не пишет расчёт «активность за 7 дней» заново — она подключает готовый признак. Это экономит труд и гарантирует единообразие.

Как работает под капотом

Инженер описывает признак декларативно: источник, ключ-сущность (например, user_id), окно агрегации, функция. Сервис материализации периодически считает признаки и раскладывает: историю — в offline store, свежие значения — в online store. При обучении SDK делает point-in-time join событий с offline store; при инференсе — мгновенный lookup в online store. Так одно определение обслуживает оба режима, что и убирает рассинхрон.

Частые ошибки

• Заводить feature store слишком рано. Для одной модели это оверинжиниринг; ценность появляется при множестве моделей и команд.
• Игнорировать point-in-time. Без него в выборку утекает будущее и метрики врут.
• Разная логика в offline и online. Если материализация в два хранилища считает по-разному, возвращается тот самый skew.

Итог

• Feature store централизует признаки, обеспечивая их переиспользование и единую логику расчёта.
• Offline store кормит обучение историей, online store кормит инференс быстрым lookup — из одного определения.
• Point-in-time join при сборке выборки предотвращает утечку будущего (data leakage).