Как организовать feature store для AI (Feast, Hopsworks)?

Краткий тезис

Feature store — централизованное хранилище признаков (features) для ML и AI-систем, которое обеспечивает консистентность между обучением (training) и инференсом (inference) и поддерживает как пакетную (batch), так и потоковую (streaming) подачу признаков. Для LLM-агентов и RAG|Agentic RAG feature store хранит пользовательские эмбеддинги, историю запросов, контекстные признаки и позволяет выдавать их в реальном времени. Feast и Hopsworks — два ведущих open-source решения, различающиеся архитектурой, моделями обслуживания и экосистемой.

1. Термин: Feature store — что это и зачем в AI

Feature store — это система, которая управляет жизненным циклом признаков: их созданием, хранением, версионированием, обслуживанием (serving) и мониторингом. В контексте AI (особенно LLM и RAG|Agentic RAG) feature store решает две ключевые проблемы:

• Train-serve skew — расхождение между признаками, использованными при обучении, и теми, что подаются на инференс. Feature store гарантирует, что для онлайн-запроса выдаётся тот же самый признак, что был сгенерирован для исторической точки.
• Feature reuse — один и тот же признак (например, эмбеддинг пользователя за последние 24 часа) нужен множеству моделей (LLM‑ассистент, рекомендательная система, скоринг лидов). Feature store выступает единой точкой доступа, предотвращая дублирование кода и инференса.

Для AI-агентов feature store особенно важен, так как они работают в реальном времени и требуют контекстных признаков (последние N запросов, текущее состояние диалога, поведенческие профили).

2. Архитектура feature store: offline, online, point-in-time correctness

Архитектура любого зрелого feature store состоит из трёх слоёв:

• Offline store — хранилище исторических признаков, обычно Parquet-файлы в S3/ADLS/GCS или таблицы в Spark/Databricks. Используется для пакетного вычисления обучения (training).
• Online store — хранилище для низколатентного (единицы миллисекунд) обслуживания признаков в реальном времени. Чаще всего — Redis, DynamoDB, Aerospike или RocksDB. Для каждого ключа (например, user_id) хранится последнее значение признака.
• Feature registry — центральный каталог метаданных: какие признаки существуют, их типы, источник, версия, описание. Registry позволяет искать и документально оформлять признаки.

Point-in-time correctness (корректность момента времени) — механизм, гарантирующий, что для обучения модели берутся только те признаки, которые были известны на момент наступления события, а не будущие. Реализуется через timestamp join: исторический запрос датасета «обогащается» признаками из offline store с учётом временной метки строки.

# Пример концепции point-in-time запроса в Feast
from datetime import datetime

# Для каждой транзакции (entity) берём признаки пользователя,
# актуальные на момент транзакции (строго до или в тот же момент)
features = store.get_historical_features(
    entity_df=sales_transactions,
    features=[
        "user_features:last_7d_avg_spent",
        "user_features:user_embedding_v2",
    ],
    full_feature_names=True
).to_df()

3. Ключевые компоненты и workflow

Независимо от конкретного решения, workflow с feature store включает следующие этапы:

1. Ingestion — загрузка признаков из сырых данных (stream / batch). Обычно через Spark Streaming, Kafka → feature store, или через пакетные ETL‑пайплайны.
2. Storage — сохранение в offline и online store с автоматической синхронизацией (или ручной). Для online store признаки материализуются из последнего снэпшота offline store.
3. Serving — выдача признаков:
   • get_online_features — для инференса (ключ → последние значения).
   • get_historical_features — для обучения (временной срез).
4. Monitoring — отслежичение дрейфа признаков, латентности serving, доли пропущенных значений.

4. Feast: особенности и код для AI

Feast (Feature Store) — лёгкое open-source решение, разработанное GoDataDriven и теперь под эгидой LF AI & Data. Основные характеристики:

• Declarative config: вся конфигурация через YAML / Python (feature repo).
• Provider-agnostic: pluggable offline (BigQuery, Snowflake, Spark, Athena) и online (Redis, PostgreSQL, DynamoDB, Firestore) stores.
• Версионирование признаков через feature views и migrations.
• Интеграция с LLM: можно хранить user embedding как признак (float vector), обновляемый раз в сутки (batch) или в реальном времени через streaming source.

Пример для LLM-агента

Предположим, у нас есть эмбеддинг последних 10 запросов пользователя. Мы определяем Feature View с источником из Kafka:

# defs.py (feast feature repo)
from feast import FeatureView, Field, KafkaSource
from feast.types import Float32, String
from datetime import timedelta

user_query_embedding = FeatureView(
    name="user_query_embedding",
    entities=["user"],
    schema=[
        Field(name="embedding", dtype=Array(Float32)),  # 768‑мерный вектор
        Field(name="last_query_timestamp", dtype=UnixTimestamp),
    ],
    source=KafkaSource(
        name="user_query_events",
        kafka_bootstrap_servers="broker:9092",
        topic="user_queries",
        message_format="avro",
        watermark_delay=timedelta(seconds=30),
    ),
    online=True,
    ttl=timedelta(days=1),
)

Сервинг для инференса:

from feast import FeatureStore
import numpy as np

store = FeatureStore(repo_path="feature_repo")

# Выдача признака для конкретного пользователя
features = store.get_online_features(
    features=[
        "user_query_embedding:embedding",
        "user_query_embedding:last_query_timestamp",
    ],
    entity_rows=[{"user_id": "user_123"}]
).to_dict()

embedding = np.array(features["embedding"][0])
print(f"Embedding shape: {embedding.shape}")

5. Hopsworks: отличия и возможности

Hopsworks — более тяжёлая платформа, включающая не только feature store, но и всю MLOps‑инфраструктуру: Feature Store, Training Datasets, Model Registry, Feature Monitoring. Отличительные черты:

• Feature Groups — логическая группировка признаков по источнику; внутри группы хранится версионированная таблица.
• Training Dataset — снапшот данных на конкретную дату, который автоматически создаётся из feature groups с point-in-time join.
• Online Store на основе RonDB (Apache HBase + MySQL) или MySQL Cluster с транзакционной поддержкой.
• Streaming — нативный Kafka connector, поддержка Spark Structured Streaming и Flink.
• Enterprise — встроенные RBAC, линковка экспериментов, MLflow интеграция.

Пример создания feature group в Hopsworks (Python API):

import hopsworks

project = hopsworks.login()
fs = project.get_feature_store()

# Определяем feature group
user_behavior_fg = fs.create_feature_group(
    name="user_behavior",
    version=1,
    description="User interactions with assistant",
    primary_key=["user_id"],
    event_time="created_at",
    online_enabled=True,
)

# Вставка данных
user_behavior_fg.insert(df)  # df — Spark или Pandas DataFrame

Сервинг для LLM‑агента

# Получение векторного признака
feature_vector = fs.get_online_feature_vector(
    feature_group_name="user_behavior",
    feature_names=["embedding", "last_query"],
    entry={"user_id": "user_123"},
)

6. Сравнение Feast vs Hopsworks

Когда выбрать Feast: вам нужна лёгкая, гибкая интеграция с существующим стеком; вы стартап или средние ML‑нагрузки; вы хотите использовать свой Redis/DynamoDB.

Когда выбрать Hopsworks: вам нужна готовая MLOps‑платформа «всё в одном»; большой Enterprise с требованиями к compliance; вам нужно управлять feature lineage и мониторингом дрифта.

7. Интеграция feature store с Agentic RAG

В Agentic RAG агент использует feature store как память для динамических признаков. Примеры:

• User embedding — обновляется после каждого диалога; агент использует его для персонализации retrieval релевантных документов.
• Recent queries — список последних запросов (как признак) помогает агентам не повторяться и учитывать контекст.
• Conversation state — текущая тема, намерение (intent), настроение (sentiment) — может вычисляться на лету (streaming feature) и подаваться в LLM как дополнительный контекст.

Архитектурная схема:

Пользователь -> LLM Agent -> [Вызов Action / Function Calling]
                                    |
                                    v
                            Feature Store Client
                                    |
                            +------+--------+
                            |               |
                     Online Store      Offline Store
                     (Redis)           (S3+Parquet)
                            |
                    Feature Vector:
                    [embedding, intent, last_topic, ...]

Когда агент принимает запрос, он сначала извлекает онлайн‑признаки пользователя, добавляет их в системный промпт, затем производит retrieval из векторной БД, и только затем генерирует ответ.

8. Best practices при организации feature store для AI

• Документируйте каждое поле через feature registry. Используйте описание, тип, единицы измерения, источник.
• Версионируйте признаки (v1, v2) и модели — модель, обученная на v1, должна получить v1 во время инференса, пока её не переобучат.
• Материализуйте online store максимально быстро (цель — латентность <10 мс, включая десериализацию).
• Мониторьте качество признаков: проценты пропусков, стабильность распределения (drift), задержки обновления.
• Используйте backfill для исторических данных — при добавлении нового признака вычислите его ретроспективно для всех тренировочных датасетов.
• Не храните признаки, которые можно вычислить на лету (например, количество символов в запросе) — они слишком изменчивы и загрязняют store.

9. Проблемы и их решения

10. Пет-проект для закрепления

Задача: Разработать минимальный feature store для LLM‑ассистента, который хранит эмбеддинги пользователей и историю их последних 5 запросов.

Инструменты:

• Feast (локально) или запасной вариант: Hopsworks Community Edition (ограничение 10 млн записей).
• Redis (online store) — через Docker.
• Мини‑LLM: FastAPI‑обёртка для эмбеддинга (например, sentence-transformers/all-MiniLM-L6-v2).
• Источник данных: простая Python‑симуляция запросов (10 пользователей, 100 событий).

Шаги:

1. Установить Feast: pip install feast[redis].
2. Создать feature_repo с YAML‑конфигом (Redis address, offline store — файл Parquet для теста).
3. Определить entity user_id, затем feature view user_embeddings со схемой (embedding как Array(Float32)).
4. Написать Python‑скрипт для ingestion: сгенерировать DataFrame с user_id, embedding (768‑мерный float), event_time; записать в offline store; материализовать в Redis.
5. Написать сервис для инференса: FastAPI endpoint GET /features?user_id=xxx → store.get_online_features.
6. Подключить к LLM‑агенту (например, через LangChain Tool для получения контекста пользователя).

Ожидаемый результат: Вы сможете в реальном времени (через секунды) получать эмбеддинг пользователя, который меняется при каждом новом событии. При этом обучение модели на историческом датасете будет использовать те же признаки, но с учётом их ретроспективного состояния (point‑in‑time).

11. Связь с другими вопросами

12. Навигация

• Предыдущий: 852
• Следующий: 854
• Индекс: 00. Индекс разборов

Навигация

• Предыдущий: 852
• Следующий: 854
• Индекс: 00. Индекс разборов