Как вы отслеживаете data drift для распределения запросов к RAG?

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

Data drift – изменение статистических свойств входных данных со временем. Для RAG это означает, что распределение пользовательских запросов (их векторных представлений) смещается относительно выборки, на которой обучались эмбеддеры или настраивался retrieval. Отслеживание включает сбор эмбеддингов запросов, сравнение с референсным распределением (например, через KL-дивергенцию и расстояние Вассерштейна), установку порогов срабатывания алертов и запуск пайплайна переобучения или адаптации компонентов RAG.

1. Термин: Data Drift в контексте RAG

Data drift (дрейф данных) – это изменение распределения входных данных модели после развертывания. В RAG под data drift обычно понимают изменение тематики, стиля или семантики пользовательских запросов (вопросов). Это может происходить из-за смены аудитории, сезонности, новых продуктов или модных тем.

Почему это важно для RAG

• Retrieval (поиск релевантных документов) обучается или настраивается на определённом распределении эмбеддингов запросов.
• Если распределение смещается, топ-k документов могут перестать быть релевантными, даже если сами документы не менялись.
• LLM (генератор) может получать нерелевантный контекст → ответы становятся неверными или бесполезными.

Термины

• Embedding shift – смещение векторных представлений запросов в пространстве эмбеддингов.
• Covariate shift – изменение распределения входных признаков (здесь – эмбеддингов) при неизменном условном распределении ответов.
• Concept shift – изменение связи между запросами и релевантными документами (например, «лучший телефон» теперь означает другую категорию).

2. Почему data drift запросов критичен для RAG

Пример дрейфа

• Изначально RAG отвечал на вопросы о документации продукта.
• Через месяц 30% запросов стали касаться новой версии API, которой нет в документах.
• Эмбеддинги «старых» запросов группировались в одном кластере, «новые» – в другом.
• Без мониторинга это заметят только по ухудшению фидбека.

3. Мониторинг распределения эмбеддингов (основной метод)

Основной подход – векторизация запросов в эмбеддинги фиксированной размерности (обычно той же, что используется в векторной БД) и сравнение распределения этих векторов.

Процесс

1. Референсное распределение – эмбеддинги запросов из обучающей выборки (или первого месяца после деплоя).
2. Текущее окно – эмбеддинги последних N запросов (например, за день, неделю или 1000 запросов).
3. Сравнение – вычисление метрики расстояния между распределениями.
4. Alert – если метрика превышает порог → уведомление.

Техническая реализация

• Используется batch-процесс (раз в час/день) или streaming (онлайн-агрегация).
• Эмбеддинги можно сохранять в feature store (например, Feast) или просто в логах.

4. Статистические метрики сравнения распределений

4.1 KL-дивергенция (Kullback‑Leibler divergence)

• Измеряет «потерю информации» при аппроксимации одного распределения другим.
• Формула D_KL(P||Q) = Σ P(x) * log(P(x)/Q(x))
• Не является метрикой (несимметрична, не удовлетворяет неравенству треугольника).
• Требует оценки плотности P и Q (например, через гистограммы или ядерное оценивание).
• Интерпретация близка к 0 – распределения похожи, растёт – дрейф.

4.2 Расстояние Вассерштейна (Wasserstein distance, Earth Mover’s Distance)

• Минимальная «стоимость» переноса массы из одного распределения в другое.
• Формула (для 1D): W_1(P,Q) = ∫ |F_P(x) - F_Q(x)| dx, где F – кумулятивная функция.
• Симметрично и является метрикой.
• Более устойчиво к шуму и разреженным данным, чем KL.
• Интерпретация чем больше, тем сильнее дрейф.

4.3 Другие метрики

• Maximum Mean Discrepancy (MMD) – с помощью ядерного трюка.
• Jensen-Shannon divergence – симметричная версия KL.
• Energy distance – основана на расстояниях между точками.

Рекомендация для эмбеддингов (многомерные, до 1024) часто используют Wasserstein distance по каждой размерности с усреднением, или MMD с радиальным базисным ядром.

5. Практическая реализация: pipeline сбора и анализа

Компоненты

1. Логгер запросов – сохраняет текст запроса, timestamp, user_id, эмбеддинг (если возможно).
2. Хранилище эмбеддингов – временное хранилище (Redis, S3, Redshift).
3. Детектор дрифта – скрипт / Spark-задача, выполняющаяся по расписанию.
4. Alerting система – PagerDuty, Slack, email.
5. Action handler – запуск пайплайна переобучения.

Пример архитектуры (упрощённо):

User Queries → Embedding Model → Vector DB (поиск) + Logs (эмбеддинги + мета)
     ↑                                          |
     |                                    Daily batch: читает эмбеддинги
     |                                    за последние [[24. Какой размер датасета нужен для fine-tuning\|24]] часа
     +---------- Drift Detector ---------> Сравнивает с референсом
                                           Если drift > threshold → Alert

6. Alerting и пороговые значения

Выбор порога

• На основе базовой линии – вычислить метрику на валидационном наборе (который считается «чистым»).
• Использовать правила 3 сигм или перцентили (например, 99-й перцентиль baseline + запас).
• В production можно накапливать метрику и устанавливать порог, при котором качество retrieval падает на X%.

Пример правил

• Wasserstein distance > 0.5 → предупреждение (logging).
• Wasserstein distance > 1.0 → alert (Slack), запуск переобучения.
• KL > 0.2 → alert, требует ручного анализа.

Важно пороги зависят от размерности эмбеддингов, нормировки, семпла. Необходимо калибровать на исторических данных.

7. Действия при обнаружении drift

Термин: Hard negative mining – подбор документов, которые семантически похожи на запрос, но не релевантны; используется для улучшения разделимости в эмбеддинговом пространстве.

8. Инструменты и библиотеки для мониторинга дрифта

Рекомендация для старта – Evidently (бесплатно, простой API) + кастомный детектор на Wasserstein.

9. Различие между covariate shift и concept shift в контексте запросов

• Covariate shift: меняется распределение запросов (эмбеддингов), но связь «запрос → релевантный документ» остаётся прежней. Например, пришло много запросов про «экологию», хотя раньше их было мало. Эмбеддер может их правильно искать, если обучен на разнообразных данных.
• Concept shift: меняется значение терминов. Например, слово «Netflix» раньше ассоциировалось с DVD-дисками, теперь – с online streaming. Эмбеддер не знает этого, поэтому retrieval будет ошибочным.

Отслеживание covariate shift можно поймать по эмбеддингам. Concept shift требует дополнительно анализировать клики пользователей или рейтинги retrieval (мониторинг метрик качества, а не только распределения).

10. Пример кода на Python для отслеживания drift эмбеддингов

import numpy as np
from scipy.stats import wasserstein_distance, entropy
from sklearn.preprocessing import StandardScaler
import warnings

def compute_wasserstein_1d(reference, current, dim_reduction='mean'):
    """
    Approximate Wasserstein distance for multivariate embeddings.
    For simplicity, average across dimensions.
    """
    # reference, current: arrays of shape (n_ref, d), (n_curr, d)
    ref_1d = np.mean(reference, axis=1)      # collapse to 1D
    cur_1d = np.mean(current, axis=1)
    # можно использовать PCA, но для простоты так
    return wasserstein_distance(ref_1d, cur_1d)

def compute_kl_divergence(embeddings_ref, embeddings_curr, bins=50):
    """
    KL divergence via histogram. Works for 1D projections.
    """
    # projection on first principal component
    from sklearn.decomposition import PCA
    pca = PCA(n_components=1)
    pca.fit(embeddings_ref)
    ref_1d = pca.transform(embeddings_ref).flatten()
    cur_1d = pca.transform(embeddings_curr).flatten()

    min_val = min(ref_1d.min(), cur_1d.min())
    max_val = max(ref_1d.max(), cur_1d.max())
    hist_ref, bin_edges = np.histogram(ref_1d, bins=bins, range=(min_val, max_val), density=True)
    hist_cur, _ = np.histogram(cur_1d, bins=bin_edges, density=True)

    # handle zeros
    hist_ref = np.clip(hist_ref, 1e-10, None)
    hist_cur = np.clip(hist_cur, 1e-10, None)

    kl = entropy(hist_cur, hist_ref)   # D_KL(P_cur || P_ref)
    return kl

# Пример использования
np.random.seed(42)
ref_embeddings = np.random.randn(1000, 384)   # reference distribution
curr_embeddings = np.random.randn(1000, 384) + 0.5  # slight shift

wasser = compute_wasserstein_1d(ref_embeddings, curr_embeddings)
kl = compute_kl_divergence(ref_embeddings, curr_embeddings)
print(f"Wasserstein (mean projection): {wasser:.4f}")
print(f"KL divergence (PCA projection): {kl:.4f}")

Примечание в production следует использовать PCA или UMAP для редукции размерности, а затем многомерный Wasserstein (например, с помощью pot library).

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

Задача Реализовать систему мониторинга data drift для RAG с Vector DB (Chroma/FAISS) и кастомными оповещениями.

Инструменты

• Python (numpy, scipy, sklearn)
• Chroma DB (in-memory)
• HuggingFace Transformers (для эмбеддера, например all-MiniLM-L6-v2)
• Evidently AI (опционально) или Plotly
• Telegram Bot / Slack Webhook для алертов

Шаги:

1. Создать синтетические запросы (например, 500 «старых» и 500 «новых» с разной тематикой).
2. Получить эмбеддинги через sentence-transformers.
3. Вычислить референсное распределение (среднее и ковариационная матрица или эмпирическое распределение).
4. Написать функцию, которая в пакетном режиме (каждые 100 запросов) вычисляет Wasserstein distance.
5. Установить порог (например, 0.8 – на основе эксперимента).
6. При превышении порога отправлять сообщение в Telegram/Slack.
7. Добавить визуализацию: t-SNE проекция эмбеддингов с цветовой кодировкой «старые / новые», а также график изменения метрики во времени.

Ожидаемый результат

• Работающий скрипт, который при запуске симулирует поток запросов, детектирует момент, когда новые запросы начинают отличаться, и выдает алерт.
• Отчёт (HTML или notebook) с графиками дрейфа.

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

13. Навигация

Навигация

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