Как вы проектируете feature store для ML фичей, используемых LLM?

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

Feature store — это централизованное хранилище признаков (фичей), которое обеспечивает единую точку доступа для online (latency|низкая задержка) и offline (обучение) сценариев. Для LLM feature store хранит как контекстные фичи (тенор пользователя, подписка), так и эмбеддинги (user_embedding). Ключевые требования: point-in-time correctness (фичи на момент запроса), low-latency serving (Redis, <5ms) и бесшовная интеграция с пайплайнами retrieval и генерации.

1. Термин: Feature store (хранилище признаков)

Feature store — это платформа для управления, хранения и подачи ML-фичей. Она решает проблемы:

• Дублирование — одна фича используется в нескольких моделях.
• Несогласованность — фичи для обучения и инференса считаются по-разному.
• Point-in-time correctness — фичи должны браться на момент запроса, а не на текущее время.

Основные компоненты

• Offline store — для хранения исторических фичей (обычно Parquet в S3, BigQuery).
• Online store — для low-latency serving (Redis, DynamoDB, Cassandra).
• Feature registry — каталог фичей с метаданными (тип, источник, owner).
• Serving API — gRPC/REST для получения фичей в реальном времени.

Популярные инструменты

• Feast (open-source, Kubernetes-native)
• Hopsworks (с integrated feature engineering)
• Tecton (enterprise, Databricks-совместимый)

2. Зачем feature store для LLM?

LLM в RAG-системах используют фичи на нескольких этапах:

Без feature store эти фичи размазаны по разным базам, коду и не синхронизированы между обучением и инференсом.

3. Архитектура feature store для LLM

3.1 Offline pipeline (обучение и анализ)

• Источники Kafka (streaming), S3 (batch), PostgreSQL (transactional).
• Трансформации Spark или Pandas — вычисление фичей (например, агрегация действий пользователя за 7 дней).
• Хранение Parquet в S3 с партиционированием по дате.
• Point-in-time join Для каждого training sample фичи берутся на момент запроса (не future data).

3.2 Online pipeline (инференс)

• Materialization Периодическая выгрузка фичей из offline store в online store (Redis).
• Serving API возвращает фичи за <5ms.
• Обновление Streaming-фичи (из Kafka) пишутся напрямую в Redis с TTL.

[Kafka] → [Streaming Job] → [Redis (online store)]
                              ↑
[Batch Job (Spark)] → [S3 (offline store)] → [Materialization Job] → [Redis]

4. Типы фичей для LLM

4.1 Эмбеддинги (user_embedding, item_embedding)

• Хранение Векторная БД (Pinecone, Qdrant) или Redis с модулем Redisearch.
• Обновление Раз в сутки или при изменении профиля пользователя.
• Использование Retrieval похожих пользователей/документов.

4.2 Контекстные фичи (user_tenure, subscription_tier)

• Хранение Redis (key-value).
• Обновление Real-time (из Kafka) или batch (раз в час).
• Использование Вставляются в промпт: "Пользователь с нами 2 года, тариф Premium".

4.3 Real-time признаки (last_click, session_duration)

• Хранение Redis с TTL (например, 1 час).
• Обновление Streaming из Kafka (каждое действие пользователя).
• Использование Адаптация ответа под текущую сессию.

5. Point-in-time correctness

Проблема Если фичи для обучения берутся на текущее время, а для инференса — на момент запроса, модель учится использовать "будущие" данные.

Решение При создании training dataset фичи джойнятся по временной метке запроса (timestamp). Feast и Hopsworks поддерживают point-in-time joins автоматически.

# Пример с Feast
from feast import FeatureStore

store = FeatureStore(repo_path=".")
# Получить фичи на момент времени 2024-01-01 12:00:00
features = store.get_online_features(
    features=["user_features:tenure", "user_features:embedding"],
    entity_rows=[{"user_id": 42, "event_timestamp": "2024-01-01 12:00:00"}]
).to_dict()

6. Выбор инструмента: Feast vs Hopsworks vs Tecton

Рекомендация Для старта — Feast (бесплатно, гибко). Для enterprise с streaming — Tecton (дорого, но меньше DevOps).

7. Интеграция с LLM (retrieval + prompt)

7.1 Retrieval через эмбеддинги

# Получаем user_embedding из feature store
user_embedding = store.get_online_features(
    features=["user_embeddings:vector"],
    entity_rows=[{"user_id": 42}]
).to_dict()["user_embeddings:vector"][0]

# Ищем похожих пользователей в векторной БД
similar_users = vector_db.query(user_embedding, top_k=5)

7.2 Контекстные фичи в промпт

context = store.get_online_features(
    features=["user_features:tenure", "user_features:tier"],
    entity_rows=[{"user_id": 42}]
).to_dict()

prompt = f"""
Пользователь с нами {context['tenure'][0]} лет, тариф {context['tier'][0]}.
Ответь на вопрос: {question}
"""

8. Мониторинг и версионирование

• Мониторинг фичей Дрейф распределения (PSI, KS-test), пропуски, задержки обновления.
• Версионирование Каждая фича имеет версию (feature_view в Feast). При изменении логики — новая версия.
• Alerting Если latency online serving >10ms или accuracy retrieval падает.

9. Масштабирование и latency

• Online store: Redis Cluster (шардирование по user_id) — latency <5ms.
• Offline store: S3 + Athena/Spark — для больших датасетов.
• Кэширование В LLM-сервисе кэш фичей на 1 минуту (если допустимо).
• Batch materialization Запускать каждые 15 минут (не чаще, чтобы не перегружать Redis).

10. Пример кода: настройка Feast для LLM-фичей

# feature_store.yaml
project: llm_features
provider: local
registry: data/registry.db
online_store:
    type: redis
    connection_string: localhost:6379
offline_store:
    type: file

# features/user_features.py
from feast import Entity, FeatureView, Field, ValueType
from feast.types import Float32, Int64, String

user = Entity(name="user_id", value_type=ValueType.INT64)

user_features = FeatureView(
    name="user_features",
    entities=[user],
    ttl=timedelta(days=1),
    schema=[
        Field(name="tenure", dtype=Int64),
        Field(name="tier", dtype=String),
        Field(name="embedding", dtype=Float32, shape=(768,)),
    ],
    source=...  # batch source from Parquet
)

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

Задача Создать feature store для персонального LLM-ассистента (например, рекомендации фильмов).

Инструменты Feast (local), Redis (Docker), Python, Kafka (опционально).

Шаги:

1. Установить Feast и запустить Redis в Docker.
2. Определить Entity user_id и FeatureView user_features (tenure, genre_preference_embedding).
3. Загрузить исторические данные (CSV с user_id, tenure, embedding).
4. Настроить materialization в Redis.
5. Написать FastAPI-сервис, который получает фичи из Feast и использует их в промпте LLM (OpenAI API).
6. Добавить real-time фичу (последний просмотренный фильм) через Kafka → Redis.

Ожидаемый результат Работающий сервис, который при запросе "порекомендуй фильм" подставляет в промпт тенор пользователя и его эмбеддинг, а retrieval находит похожих пользователей.

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

Навигация

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