Централизованное , единое для обучения и онлайн-инференса.
Ключевые тезисы
- Решает проблему training/serving skew.
- Офлайн-хранилище для обучения, онлайн — для низких задержек.
- Feast и Tecton — типовые реализации.
Какую задачу решает
Одни и те же нужны дважды: при обучении — за исторический период по всей выборке, при — прямо сейчас для одного объекта, за миллисекунды. Естественным образом это приводит к двум реализациям одной логики: батчевый SQL для обучения и код на Python в сервисе. Расхождение между ними — самая частая причина того, что модель в проде работает хуже, чем на валидации.
решает проблему, делая определение единственным: он описывается один раз, а система обеспечивает и историческую выборку с корректной привязкой ко времени, и быстрый доступ онлайн. Побочные выгоды — переиспользование признаков между командами и централизованный контроль качества.
«средний чек клиента за 30 дней». Для обучения на событии от 1 марта нужно значение, посчитанное по данным до 1 марта. Наивный запрос «посчитать средний чек по всей истории и приджойнить» подставит значение, включающее покупки после 1 марта, — то есть будущее, которого в предсказания не было. Модель обучится на нём, метрика будет прекрасной, прод провалится. Именно эту привязку ко времени делает автоматически — и это его главная ценность, важнее скорости доступа.
Подробный разбор
для обучения считает аналитик в SQL, а в проде их пересчитывает бэкенд на другом языке. Расхождение в одной формуле — и модель в проде получает не те данные, на которых училась.
- Офлайн-хранилище отдаёт исторические значения «на времени» (point-in-time correctness).
- Онлайн-хранилище отдаёт актуальные значения за миллисекунды.
- Определение описывается один раз и используется обоими путями.
— тяжёлая инфраструктура. Для одной-двух моделей достаточно общей библиотеки расчёта , вызываемой и в обучении, и в сервисе.
| Ситуация | Решение |
|---|---|
| 1–2 модели, одна команда | общий модуль расчёта |
| много моделей, общие | |
| нужны онлайн-признаки с низкой задержкой | с онлайн-хранилищем |
| только батч-скоринг | обычное хранилище и витрины |
Где применяется
- Онлайн-инференс с историческими агрегатамиАнтифрод и рекомендации: нужны агрегаты по клиенту за окна времени, и нужны быстро.
- Несколько моделей на общих Одно определение вместо копий в каждом проекте.
- Устранение расхожденийКогда разрыв офлайн и прода уже проявился и его источник — .
- Аудит и контроль качестваЦентрализованные проверки и происхождение .
Плюсы, минусы и альтернативы
Плюсы
- Одно определение устраняет целый класс ошибок.
- Корректная историческая выборка предотвращает утечку из будущего.
- переиспользуются между моделями и командами.
- и контроль качества встроены в одно место.
Минусы
- Серьёзная инфраструктура: для одной модели избыточна.
- Дополнительная и точка отказа в проде.
- Требует дисциплины в определениях, иначе превращается в свалку.
- Стоимость эксплуатации заметна.
Брать, если
- Несколько моделей используют общие .
- Нужен онлайн-инференс с историческими агрегатами.
- Расхождение обучения и прода уже становилось причиной инцидентов.
Не брать, если
- Одна модель с батчевым — обычного достаточно.
- вычисляются прямо из запроса и истории не требуют.
- Команда небольшая: стоимость эксплуатации не окупится.
Чем заменяют
Видеолекции
Тайм-кода именно на эту тему в записях нет. Но глава «MLOps» разобрана в курсах целиком — с той оговоркой, что место в записи придётся искать самому.
Связанные темы
Надёжность данных · Признаки в реальном времени · Признаки: создание, отбор, важность
Change Data Capture98%
Захват изменений (CDC) · Инженерия данныхЧтение журнала изменений базы вместо периодических полных выгрузок.
Feature engineering96%
Конструирование признаков · ДанныеСоздание признаков, в которых закономерность становится линейно отделимой или просто более заметной для модели.
Feature engineering96%
Работа с признаками · Практика MLНа табличных данных грамотные признаки дают больший прирост, чем смена модели.
Data Quality85%
Качество данных · Инженерия данныхАвтоматические проверки, которые ловят поломку источника раньше, чем она попадёт в модель.
Data Contracts85%
Контракты данных · Инженерия данныхЯвная договорённость между источником и потребителем: какие поля, каких типов и с какими гарантиями.
Idempotency & Exactly-once85%
Идемпотентность и гарантии доставки · Инженерия данныхЧто происходит при повторной обработке события и как не задвоить данные.
Data leakage85%
Утечка данных · ДанныеСитуация, когда в обучении присутствует информация, недоступная в момент реального предсказания. Главная причина «слишком хороших» метрик.
Data leakage85%
Утечка данных · Практика MLСамая дорогая ошибка в ML: модель отлично работает офлайн и разваливается в проде.
Data preprocessing85%
Предобработка данных · ДанныеПриведение сырых данных к виду, пригодному для обучения: типы, форматы, дубликаты, согласованность единиц измерения.
Online and Offline Features85%
Онлайн- и офлайн-признаки · Системный дизайн ML-сервисовЧасть признаков считается заранее, часть — в момент запроса. Расхождение между ними — главный источник инцидентов.
Batch and Streaming85%
Батч и стриминг · Инженерия данныхОбработка по расписанию против непрерывной обработки событий. Разные задержки, разные гарантии, разная стоимость.
Encoding70%
Кодирование категорий · ДанныеПеревод категориальных признаков в числа: one-hot, ordinal, target encoding, хеширование, эмбеддинги.
Feature selection70%
Отбор признаков · ДанныеУбираем шумные и избыточные признаки, чтобы снизить переобучение, ускорить инференс и упростить интерпретацию.
Feature importance70%
Важность признаков · Интерпретируемость моделейОценка вклада признаков в предсказания модели — первый шаг к пониманию её логики.
Permutation Importance70%
Перестановочная важность · Интерпретируемость моделейПризнак перемешивается, и измеряется падение качества модели — модельно-независимый и честный подход.
Topological features70%
Топологические признаки · Топологический анализ данныхВекторизация топологии: энтропия персистентности, суммарная длина жизни, числа Бетти, persistence images.
Всё, что названо в описании, разобрано здесь же или в соседней теме — переходы под каждым определением.
Онлайн и офлайн хранилища
Быстрый доступ по ключу для и колоночное хранилище истории для обучения.
Разбор ниже: Training/serving skewРасхождение train/serving
Разные вычисления одного в обучении и в проде. Основная проблема, ради которой всё строится.
Разбор ниже: Training/serving skewPoint-in-time correctness
Историческая выборка должна отражать значение на события, а не текущее. Иначе — утечка из будущего.
Разбор ниже: Когда feature store действительно нуженПереиспользование
, определённый один раз, доступен всем командам и моделям.
Разбор ниже: Когда feature store действительно нуженПрофильная компетенция для ролей: Data Engineer, MLOps-инженер, Инженер рекомендаций.
Усиливает профиль: ML Engineer.
Спрашивают на собеседовании: Яндекс — RecSys, Сбер — Рекомендации и персонализация, Т-Банк — Рекомендации и персонализация, Т-Банк — ML-инженерия и продакшен, VK — Лента и рекомендации, Ozon — Поиск и рекомендации, ВТБ — Данные и витрины, Спортмастер — Рекомендации и омниканальность, Arenadata — ML на платформе данных.
Тема встречается в тестах по направлениям — ошибки приведут обратно на эту страницу.
Разбор архитектуры, где эта тема — один из кирпичей: требования, развилки, цифры и режимы отказа.
Глава «MLOps» последний раз правилась . Нашли ошибку — напишите.