Feature Store и фичи для RecSys

Пользовательские, айтемные, контекстные фичи. Feast, онлайн/оффлайн фичи.

Feature Store — признаки для рекомендаций

Загрузка интерактивного виджета...

Модель ранжирования без признаков — как повар без ингредиентов. В рекомендациях признаки делятся на три группы: пользовательские (кто), айтемные (что) и контекстные (когда и где). Feature Store — централизованное хранилище, чтобы признаки были одинаковыми при обучении и на проде.

Архитектура Feature Store: источники → офлайн/онлайн хранилище → потребители — Feature Store гарантирует одинаковые признаки при обучении и на инференсе.

Три типа признаков в RecSys

Пользовательские: возраст, город, история покупок за 7/30/90 дней, средний чек
Айтемные: категория, цена, рейтинг, кол-во просмотров, дата добавления
Контекстные: время суток, день недели, устройство, геолокация
Кросс-признаки: CTR пользователя в этой категории, был ли айтем в корзине

Онлайн vs офлайн признаки

Офлайн — считаются раз в час/день пакетно (среднее за 30 дней, профиль пользователя). Онлайн — считаются в реальном времени (что кликнул 5 секунд назад, текущая сессия). Онлайн сильнее, но дороже в инфраструктуре.

Training-serving skew — проблема №1

При обучении считаешь признаки на исторических данных. На проде — в реальном времени. Если логика расчёта отличается хоть немного — модель работает хуже. Feature Store решает это: одна и та же трансформация для обучения и инференса.

Feature Store: Feast и альтернативы

Feast — опенсорсный Feature Store. Хранит определения признаков (feature definitions), офлайн данные в файлах/BigQuery, онлайн данные в Redis. Модель запрашивает нужные признаки по entity_id — Feast отдаёт актуальные значения.

from feast import FeatureStore
store = FeatureStore("feature_repo/")
# Получить признаки для пользователей 1, 2, 3
features = store.get_online_features(
    features=["user_stats:avg_order_7d", "user_stats:total_orders"],
    entity_rows=[{"user_id": 1}, {"user_id": 2}]
).to_dict()

Какие признаки дают максимум в RecSys

По опыту крупных RecSys — самые сильные признаки: 1) статистики взаимодействий пользователя за разные окна (7д, 30д, 90д), 2) CTR пользователя в категории, 3) «свежесть» айтема, 4) позиция при последнем показе.

Совет для system design

На собесе по проектированию RecSys обязательно расскажи про признаки. Типичный ответ: «используем эмбеддинги». Сильный ответ: «эмбеддинги + руками сгенерированные признаки из Feature Store: user-item кросс-статистики, временные окна, контекст».

🎯 Суть для собеса

• Зачем Feature Store? (единый источник фичей, переиспользование, consistency между train и serving) • Online vs Offline store? (online: Redis/DynamoDB, <10ms для real-time. Offline: Hive/S3 для batch training) • Feature freshness — почему важно? (stale фичи = train-serving skew → деградация модели) • Feast vs in-house? (Feast: open-source, быстрый старт. Крупные компании строят свои) • На практике: feature store — обязательная часть ML-платформы, спрашивают на system design

Материалы

What is a Feature Store — Feast

Зачем нужен Feature Store и как он работает.

Feature Store — Feast Documentation

Практический опыт Avito.

Sequential RecSys

Learning to Rank

Назад к программе