← вся теориятеория к собесу · ML System Design

ML System Design: фичсторы и пайплайны

Зачем это спрашивают

Feature store - модное слово, за которым прячут два конкретных вопроса: как не считать одну фичу дважды по-разному и как не утечь в будущее при сборке трейна. Отвечаешь на них - отвечаешь на всё.

// Point-in-time join - термин, который стоит произнести: он маркирует понимание честного трейна.

Две боли, которые решает фичстор

Первая - переиспользование: фича «средний чек за 30 дней» нужна пяти командам, и без стора её пять раз напишут по-разному. Одно определение фичи - один источник правды.

Вторая - консистентность трейн/сервинг: offline store хранит историю фичей для обучения, online store - свежие значения с миллисекундным чтением (Redis-класс). Определение одно, разливка в оба.

// Две реализации одной фичи - SQL для трейна, сервис для прода - расползутся гарантированно. Не «может быть», а гарантированно.

offline / online store: история для трейна / свежие значения для сервинга

Point-in-time join: честный трейн

К каждому обучающему событию фичи джойнятся «какими они были на тот момент», не свежее. Джойн текущих значений к прошлым событиям - утечка будущего через фичстор: модель на трейне видит то, чего на сервинге не увидит.

Backfill - вторая половина честности: новую фичу нужно уметь посчитать на всю историю тем же кодом, что считает её вперёд. Иначе фича есть «с завтра», а трейн-истории нет.

// Фичи по способу расчёта: batch (ночные агрегаты), streaming (окна по событиям), on-demand (из контекста запроса) - у каждой свой путь и своя свежесть.

point-in-time join: фичи на момент события - против утечки будущего
backfill: пересчёт новой фичи на всю историю тем же кодом

Свежесть и lineage

Протухшая online-фича - тихая катастрофа: пайплайн сломался, стор отдаёт вчерашнее или NULL, модель молча ест дефолты. Мониторинг свежести фичей - обязательная строка дашборда.

Данные версионируются как код: снапшоты датасетов, lineage от сырья до фичи - без этого не воспроизвести эксперимент и не разобрать инцидент.

// NULL, молча превратившийся в дефолт, не оставляет следов в логах ошибок - только в качестве предсказаний.

lineage: происхождение данных: сырьё → трансформации → фича

Как отвечать: «Зачем нужен feature store и что будет без него?»

Он решает две боли. Консистентность трейн/сервинг: одно определение фичи разливается и в offline-историю для обучения, и в online-стор для инференса - без этого фичу пишут дважды, реализации расползаются, и получаем training-serving skew, который офлайн-метрики не видят. И честность трейна: point-in-time join отдаёт фичи «какими они были на момент события» - джойн текущих значений к прошлым событиям это утечка будущего. Без стора это всё возможно, но дисциплиной руками: единый код фичей, снапшоты, PIT-джойны - фичстор просто делает дисциплину инфраструктурой. Плюс мониторинг свежести: протухшая фича молча уходит в модель дефолтом.

Названы обе решаемые боли и честное «можно без него, но дисциплиной» - зрелый взгляд вместо карго-культа инструмента.

На чём валят

−Джойнить текущие фичи к трейн-событиям - утечка будущего через фичстор.
−Две реализации одной фичи (SQL трейн, сервис прод) - расползутся гарантированно.
−Не заложить backfill - фича есть «с завтра», трейн-истории нет.
−Игнорировать протухание online-фичей - NULL молча уходит дефолтом.

Проверьте себя

Пять вопросов из банка по этой подтеме. Всего их 9, остальные разбираются в тренажёре.

#feature_stores_pipelines1 / 5
Почему пайплайн «данные → фичи → трейн → деплой» должен быть воспроизводимым, и что для этого фиксируют?
A)Воспроизводимость реально нужна разве что для сугубо научных публикаций и академических статей
B)Достаточно просто сохранить финальный pickle-файл обученной модели
C)Воспроизводимость и так обеспечивается самим фактом использования языка Python
D)Иначе не сравнить модели и не откатиться; фиксируют данные, код, окружение
показать ответ и разбор
+D)Иначе не сравнить модели и не откатиться; фиксируют данные, код, окружение
// разбор: «Модель v2 хуже v1» — вопрос без ответа, если не зафиксировано, на каких данных и каком коде обе обучены. Минимальный стек соло/малой команды: git + DVC/lakeFS или снапшоты витрин, MLflow/W&B для запусков, Docker-образ окружения. Pickle без пайплайна — артефакт-сирота: препроцессинг не восстановишь.
#feature_stores_pipelines2 / 5
Что такое фича (feature) в машинном обучении?
A)Измеримый входной признак объекта, который модель использует для предсказания
B)Уже готовое итоговое предсказание, которое обученная модель выдаёт на выходе
C)Слой нейронной сети между входным и выходным слоями модели
D)Метрика качества, по которой оценивают уже обученную модель
показать ответ и разбор
+A)Измеримый входной признак объекта, который модель использует для предсказания
// разбор: Фича — измеримая характеристика объекта на входе модели (возраст клиента, число заказов за месяц, эмбеддинг текста). Качество модели во многом определяется набором и конструированием фич (feature engineering) — часто это важнее выбора алгоритма. Фичи же — источник training-serving skew и утечек.
#feature_stores_pipelines3 / 5
Фича сильна офлайн, но её онлайн-расчёт стоит 200 мс и требует джойна тяжёлой таблицы. Как решать?
A)Считать фичу онлайн по запросу — более сильная фича важнее добавленной латентности
B)Взвесить прирост качества против стоимости: предрассчитать/материализовать онлайн или отказаться, если не окупается
C)Выкинуть фичу без анализа, ведь онлайн-фича дороже ста миллисекунд недопустима в проде
D)Оставить как есть и надеяться, что под реальной нагрузкой эти 200 мс на фичу как-нибудь сами уложатся в SLA сервиса
показать ответ и разбор
+B)Взвесить прирост качества против стоимости: предрассчитать/материализовать онлайн или отказаться, если не окупается
// разбор: Онлайн-фича с латентностью и тяжёлым джойном — это инженерная цена, которую сопоставляют с приростом метрики. Варианты: предрассчитать и материализовать значения в быстрый онлайн-стор (ценой свежести), кэшировать, упростить расчёт — или отказаться от фичи, если прирост качества не окупает стоимость и риск. Слепо «считать любой ценой» или «выкинуть без анализа» — обе крайности неверны.
#feature_stores_pipelines4 / 5
Признак «число заказов юзера за последний час» в онлайн-фичсторе. Что критично контролировать помимо корректности?
A)Объём занимаемой этим признаком памяти в онлайн-хранилище — а скорость его обновления при этом не важна
B)Цвет дашборда, на котором признак отображается аналитику для ручной проверки его значений перед подачей их в модель
C)Свежесть (freshness): устаревший real-time признак врёт — нужен допустимый лаг обновления и его мониторинг
D)Число знаков после запятой при округлении значения признака — именно из-за него модель выдаёт разные ответы на один вход
показать ответ и разбор
+C)Свежесть (freshness): устаревший real-time признак врёт — нужен допустимый лаг обновления и его мониторинг
// разбор: Для признаков реального времени критична свежесть: «заказов за последний час», обновлённый с задержкой в час, описывает уже не то состояние и портит предсказание, хотя формально «корректен». Поэтому задают допустимый лаг обновления (SLA свежести), мониторят задержку конвейера фичей и алертят при устаревании. Память и оформление вторичны, а округление на суть не влияет.
#feature_stores_pipelines5 / 5
Что даёт вынесение фичей в общий feature store, если у команд свои пайплайны?
A)Переиспользование и единое определение фич: одна логика на train и serve, разные команды не переписывают одно и то же заново
B)Feature store просто хранит сырые данные вместо базы, и никакой пользы для согласованности самих фич он при этом не несёт вообще
C)Он заменяет собой обучение моделей: при наличии фичстора сама обученная модель уже не нужна, хватает и одних фич
D)Его функция — ускорять инференс за счёт сжатия признаков в меньший размер прямо на диске сервера
показать ответ и разбор
+A)Переиспользование и единое определение фич: одна логика на train и serve, разные команды не переписывают одно и то же заново
// разбор: Feature store даёт единое версионированное определение фичей и их переиспользование: одна и та же логика вычисления обслуживает обучение (offline) и прод (online), а разные команды/модели берут готовые фичи, не переписывая их и не расходясь в реализации. Это снижает дублирование, ошибки и training-serving skew. Он не заменяет модель, не «просто хранит сырьё» и не про сжатие на диске.

дальше

Теорию прочитали. Навык ставится повторением

В Сеньорчике эта подтема идёт в ежедневных сессиях: движок возвращает её, пока ответы не станут уверенными, и ведёт прогресс отдельно по каждой подтеме. Теория внутри тоже бесплатна, лимит только на количество вопросов в день.

Открыть тренажёр Вся тема: ML System Design