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

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

Feature store — это централизованное хранилище для фичей (признаков), используемых в ML-моделях. Для LLM feature store решает проблему доставки актуальных контекстных данных (например, эмбеддинги пользователя, агрегированная статистика, real-time признаки из Kafka) прямо в промпт. Ключевые инструменты — Feast или Hopsworks, а архитектура строится вокруг low-latency serving, версионирования фичей и бесшовной интеграции с пайплайном генерации ответа.

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

Feature store — это платформа, которая позволяет:

• Создавать и регистрировать фичи (определения).
• Вычислять фичи (batch, streaming).
• Хранить фичи в двух слоях: offline (для обучения) и online (для инференса).
• Сервить фичи с низкой задержкой (latency < 10 ms) для real-time приложений, включая LLM.

Зачем LLM feature store LLM сама по себе не знает о текущем состоянии пользователя, контексте сессии или бизнес-метриках. Feature store предоставляет эти данные в виде структурированных признаков, которые можно вставить в промпт (например, user_embedding, avg_session_time, last_purchase_category).

Термин «Фича» (Feature) — это числовое или категориальное значение, которое описывает объект (пользователя, товар, сессию) и используется моделью для предсказания. Для LLM фичи — это данные, которые обогащают контекст.

2. Архитектура Feature Store для LLM

Feature store для LLM состоит из нескольких ключевых компонентов:

Термин «Online Store» — это высокопроизводительное key-value хранилище (Redis, DynamoDB, Cassandra), которое хранит только последнее значение фичи для каждого ключа (например, user_id). Оно оптимизировано для чтения с низкой задержкой.

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

Фичи, используемые LLM, можно разделить на три категории:

3.1 User Embeddings (Эмбеддинги пользователей)

• Что это: Векторное представление пользователя, полученное из модели (например, Sentence-BERT или LLM-эмбеддер).
• Как используется Добавляется в промпт как контекст: User profile: [0.12, -0.45, ...]. LLM может интерпретировать этот вектор как описание интересов пользователя.
• Источник Batch-пайплайн, который раз в день пересчитывает эмбеддинги на основе истории действий.

3.2 Context Features (Контекстные признаки)

• Что это: Агрегированная статистика о текущей сессии или пользователе.
• Примеры
  • avg_session_time — среднее время на странице за последние 10 минут.
  • num_previous_queries — количество предыдущих запросов в этой сессии.
  • last_purchase_category — категория последней покупки.
• Как используется Вставляется в промпт: Session context: avg_session_time=45s, num_previous_queries=3.

3.3 Real-time признаки из Kafka

• Что это: Признаки, которые обновляются в реальном времени через стриминг.
• Примеры
  • current_page_id — ID страницы, на которой находится пользователь.
  • last_click_timestamp — время последнего клика.
  • realtime_sentiment — сентимент последнего сообщения пользователя (вычисляется через стриминговый ML-пайплайн).
• Как используется Позволяет LLM реагировать на текущее поведение пользователя: User just clicked on product X, recommend similar items.

4. Проектирование Feature Store: пошаговый подход

Шаг 1: Определение фичей

• Составьте список фичей, которые нужны LLM для ответа.
• Для каждой фичи укажите: имя, тип, источник (batch/streaming), частота обновления.
• Пример: user_embedding (float32[], batch, daily), last_click_category (string, streaming, real-time).

Шаг 2: Выбор инструмента

• Feast (Open Source): Легкий, хорошо интегрируется с Redis, BigQuery, Spark. Подходит для команд, которые хотят контролировать инфраструктуру.
• Hopsworks (Enterprise): Встроенный feature store, управление версиями, поддержка GPU для вычисления эмбеддингов. Подходит для крупных продакшн-систем.
• Tecton (Cloud): Полностью управляемый сервис, автоматическое управление точностью данных (point-in-time correctness). Дорогой, но минимизирует overhead.

Термин «Point-in-time correctness» — гарантия, что при обучении модели используются только те данные, которые были доступны на момент предсказания (избегаем data leakage).

Шаг 3: Настройка Online Store

• Выберите key-value store: Redis (low latency, in-memory), DynamoDB (managed, AWS), Cassandra (high availability).
• Определите ключ (например, user_id) и схему хранения (например, JSON или protobuf).
• Настройте TTL (time-to-live) для автоматического удаления устаревших фичей.

Шаг 4: Интеграция с LLM пайплайном

• LLM-сервис (например, FastAPI) перед генерацией ответа вызывает Serving API feature store.
• Полученные фичи форматируются в строку и вставляются в промпт.
• Пример кода:

import requests

def get_features(user_id: str) -> dict:
    response = requests.get(
        f"http://feature-store:6566/get-features",
        params={"entity_key": user_id, "feature_names": ["user_embedding", "last_click_category"]}
    )
    return response.json()

def build_prompt(user_id: str, query: str) -> str:
    features = get_features(user_id)
    return f"""
    User features: embedding={features['user_embedding'][:5]}..., last_click={features['last_click_category']}
    User query: {query}
    Answer:
    """

Шаг 5: Мониторинг и версионирование

• Логируйте latency запросов к feature store (цель: < 10 ms).
• Версионируйте фичи (например, user_embedding_v2) при изменении модели эмбеддинга.
• Используйте feature validation (проверка на NaN, выбросы) перед записью в online store.

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

Термин «Data staleness» — ситуация, когда фича в online store устарела (например, эмбеддинг пользователя не обновлялся неделю), что приводит к нерелевантным ответам LLM.

6. Пример: Feature Store для рекомендательного LLM-агента

Предположим, мы строим LLM-агента, который рекомендует товары в реальном времени.

Фичи

• user_embedding (batch, daily) — эмбеддинг интересов пользователя.
• session_products (streaming, real-time) — список товаров, просмотренных за последние 5 минут.
• avg_basket_value (batch, hourly) — средняя стоимость корзины пользователя.

Архитектура

1. Feast регистрирует фичи и хранит их определения.
2. Spark Streaming читает клики из Kafka, вычисляет session_products и пишет в Redis.
3. Batch-пайплайн (Airflow) раз в день пересчитывает user_embedding и avg_basket_value, записывает в Redis.
4. LLM-сервис при запросе пользователя вызывает Feast Serving API, получает фичи и вставляет в промпт:

User profile: [0.23, -0.56, ...]
Current session products: [product_A, product_B]
Average basket value: $45.00
User query: "Что мне купить?"
Recommend:

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

Задача Создать feature store для LLM-бота, который отвечает на вопросы о погоде, используя real-time данные.

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

Шаги:

1. Установите Feast и настройте Redis как online store.
2. Определите фичи: current_temperature (float, streaming), city (string, static), forecast_hourly (string, batch).
3. Напишите Python-скрипт, который каждые 5 минут получает данные из OpenWeatherMap API и пишет в Redis через Feast.
4. Создайте LLM-сервис (например, с помощью LangChain), который перед генерацией ответа запрашивает фичи из Feast и вставляет их в промпт.
5. Протестируйте: отправьте запрос "Какая погода в Москве?" и убедитесь, что LLM использует актуальную температуру.

Ожидаемый результат Работающий feature store, который обновляет фичи в реальном времени и передаёт их в LLM для генерации контекстно-зависимых ответов.

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

Навигация

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