Feature Store

Хранилище признаков — это централизованная система для управления, хранения, обнаружения и обслуживания признаков данных, используемых моделями машинного обучения. Оно помогает командам применять одни и тем же определения признаков при обучении и инференсе в продакшене, сокращая дублирование работы и несогласованность. Например, вместо того чтобы заново вычислять значение «покупки за последние 30 дней» для клиента в нескольких пайплайнах, команды могут определить его один раз, сохранять его историю и получать его последнее значение, когда модель делает предсказание.

Как работает хранилище признаков#

Признак — это измеримый входной параметр модели, такой как возраст аккаунта, средняя стоимость транзакции, количество обнаруженных объектов или эмбеддинг изображения. Сырые данные становятся полезным входом модели посредством инжиниринга признаков или автоматизированного извлечения признаков.

Типичное хранилище признаков координирует несколько компонентов:

• Определения признаков: Схемы описывают имя каждого признака, тип данных, владельца, логику трансформации, ключ сущности и версию. Связанные признаки могут быть организованы в группы признаков или представления, как описано в концепциях Amazon SageMaker Feature Store.
• Офлайн-хранилище: Исторические значения поддерживают исследование, обучение, валидацию и пакетный инференс. Документация офлайн-хранилища Feast объясняет, как исторические признаки временных рядов извлекаются из базовых источников данных.
• Онлайн-хранилище: Последние значения хранятся в базе данных с низкими задержками для предсказаний в реальном времени. Например, онлайн-хранилище Feast обычно сохраняет самое новое значение для каждого ключа сущности.
• Материализация: Запланированный или потоковый процесс перемещает вычисленные значения признаков в онлайн-хранилище.
• Реестр и метаданные: Доступные для поиска определения помогают командам находить, управлять, версионировать и повторно использовать признаки.

Сущность определяет, что описывает признак. Это может быть идентификатор клиента, идентификатор продукта, идентификатор машины или идентификатор камеры. Метка времени события фиксирует, когда значение было актуальным, а не когда оно было записано.

Почему хранилища признаков важны#

Одно из главных преимуществ — согласованность между обучением и обслуживанием. Если модель обучается с одним расчетом, но получает немного другой расчет в продакшене, смещение между обучением и обслуживанием может снизить качество предсказаний. Централизованные определения и общая логика извлечения снижают вероятность этого.

Учет времени при извлечении не менее важен. Строка обучения должна содержать только ту информацию, которая существовала на момент предсказанного события. Соединения по моменту времени в Feast восстанавливают эти исторические значения, помогая предотвратить утечку данных из будущей информации. Руководство Google Cloud по обслуживанию признаков аналогичным образом подчеркивает важность меток времени и поисков по моменту времени для чувствительных ко времени признаков.

Хранилища признаков также поддерживают:

• Повторное использование: Несколько моделей могут использовать проверенные признаки без перестройки пайплайнов.
• Актуальность: Потоковые обновления могут поддерживать входы реального времени в актуальном состоянии.
• Управление: Владение, линейность, контроли доступа и версии облегчают аудит признаков.
• Мониторинг: Команды могут обнаруживать пропущенные значения, устаревшие записи, изменения схемы и дрейф данных.

Эти возможности делают хранилища признаков важной частью MLOps в продакшене, особенно когда множество моделей и команд зависят от общих данных.

Сравнение хранилищ признаков с сопутствующими системами#

Хранилище признаков — это не просто еще одна база данных.

• Озеро данных содержит большие объемы сырых или обработанных данных, в то время как хранилище признаков добавляет ориентированные на модель определения, метки времени, логику извлечения и интерфейсы обслуживания.
• Векторная база данных специализируется на поиске сходства по векторам. Хранилище признаков может управлять эмбеддингами, но оно также может хранить скалярные, категориальные, агрегированные признаки и признаки временных рядов.
• Пайплайн инжиниринга признаков вычисляет признаки; хранилище признаков управляет результирующими значениями и обслуживает их.
• Реестр моделей управляет версиями моделей и артефактами, тогда как хранилище признаков управляет входами моделей.

Управляемые системы могут объединять несколько из этих обязанностей. Например, управляемые хранилища признаков Azure Machine Learning предоставляют обнаружение признаков, версионирование, материализацию и историческое извлечение.

Реальные приложения#

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

Инспекция в компьютерном зрении: Система производства может хранить скользящие счетчики дефектов, состояние оборудования, метаданные смен и визуальные эмбеддинги, привязанные к производственной линии и метке времени. Исторические признаки поддерживают дообучение, в то время как текущие значения помогают развернутой модели интерпретировать новые обнаружения. Команды могут управлять изображениями, аннотациями, обучением, развертыванием и мониторингом с помощью Ultralytics Platform, в то время как отдельное хранилище признаков обслуживает операционные входы.

Ultralytics YOLO26 может генерировать признаки изображений, которые впоследствии могут быть зарегистрированы с идентификаторами сущностей, метками времени и метаданными версий:

from ultralytics import YOLO

model = YOLO("yolo26n.pt")

images = [
    "https://ultralytics.com/images/bus.jpg",
    "https://ultralytics.com/images/zidane.jpg",
]

embeddings = model.embed(images)
first_image_features = embeddings[0]

print(len(embeddings))
print(first_image_features.shape)

Этот пример выполняет извлечение признаков, а не полноценное управление хранилищем признаков. Производственный пайплайн проверял бы векторы, связывал их с записями и временами событий, сохранял бы исторические версии и контролировал актуальность и качество с помощью практик, подобных тем, что описаны в рекомендациях по качеству ML от Google Cloud.