Как вы мониторите дрейф данных (data drift) для RAG?

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

Мониторинг дрейфа данных (data drift) в RAG — это процесс отслеживания изменений в распределении входных данных (запросы пользователей) и внутренних представлений (эмбеддинги документов), которые могут ухудшить качество retrieval'а и финального ответа. Ключевая идея — автоматизировать сравнение статистических распределений эмбеддингов и метрик retrieval (hit rate, recall) с эталонными значениями, а при обнаружении значимого отклонения запускать переиндексацию или дообучение модели эмбеддингов.

1. Термин: Data Drift (дрейф данных) и его опасность для RAG

Data drift — это изменение распределения входных данных модели после её развёртывания. В контексте RAG дрейф может проявляться в двух местах:

• Дрейф запросов (query drift) — пользователи начинают задавать вопросы на темы, отсутствовавшие в обучающей выборке, или используют новый сленг/терминологию.
• Дрейф документов (document drift) — изменяется сам корпус документов (например, обновляется база знаний, добавляются новые статьи, устаревают старые).

Если не мониторить дрейф, RAG-система может незаметно для пользователя начать возвращать нерелевантные документы или ухудшить качество ответов. Это критично для production-среды, где требования к стабильности высоки.

Термин «Ретрайвер» (retriever) — компонент RAG, отвечающий за поиск релевантных документов в векторной базе данных.

2. Отслеживание изменения эмбеддингов (embedding distribution)

Самый прямой способ обнаружить дрейф — сравнивать распределения эмбеддингов, которые генерирует модель для запросов и документов. Для этого используются статистические метрики расстояния (statistical distance):

• KL-дивергенция (Kullback–Leibler divergence) — мера того, насколько одно распределение отличается от другого. Высокое значение говорит о сильном дрейфе.
• Расстояние Вассерштейна (Wasserstein distance) — более устойчивая метрика, работает даже для распределений с непересекающимися носителями.
• Maximum Mean Discrepancy (MMD) — непараметрический критерий, часто применяемый для сравнения эмбеддингов.

На практике:

• Собираем «эталонное» распределение эмбеддингов запросов и документов (например, за первую неделю после деплоя).
• Каждую неделю запускаем скрипт, который загружает эмбеддинги новых запросов и документов, вычисляет расстояние между эталоном и текущей выборкой.
• Если расстояние превышает порог (например, Wasserstein > 0.1), считается, что дрейф обнаружен.

Формула Wasserstein (для 1D случая):

W(p, q) = ∫|F^(-[[1. Как бы вы спроектировали RAG-систему для 10 000 документов с разной структурой|1]])(x) - G^(-[[1. Как бы вы спроектировали RAG-систему для 10 000 документов с разной структурой|1]])(x)| dx

где F и G — функции распределения эталона и текущей выборки.

3. Метрики запросов: изменилось ли распределение вопросов

Помимо эмбеддингов, можно анализировать поверхностные метрики запросов:

• Средняя длина запроса (в токенах) — если резко выросла, пользователи начали задавать более сложные вопросы.
• Частота ключевых слов / тем (topic distribution) — используем LDA или BERTopic для выделения тем, сравниваем их доли с эталоном.
• Доля запросов, не находящих ни одного документа (zero-hit rate) — рост этой метрики может указывать на дрейф, хотя не обязательно.

Пример скрипта (Python, с использованием scipy и scikit-learn):

import numpy as np
from scipy.stats import wasserstein_distance
from sklearn.feature_extraction.text import TfidfVectorizer

def monitor_query_drift(reference_queries, new_queries, threshold=0.1):
    # Преобразуем тексты в TF-IDF векторы (низкоразмерные признаки)
    vectorizer = TfidfVectorizer(max_features=1000)
    ref_vecs = vectorizer.fit_transform(reference_queries).toarray()
    new_vecs = vectorizer.transform(new_queries).toarray()
    
    # Сравниваем распределения по первому признаку (можно усреднить по всем)
    distance = wasserstein_distance(ref_vecs[:, 0], new_vecs[:, 0])
    if distance > threshold:
        print(f"Дрейф обнаружен: Wasserstein distance = {distance:.3f}")
    else:
        print(f"Норма: расстояние = {distance:.3f}")
    return distance

4. Метрики retrieval: hit rate и recall как индикаторы дрейфа

Самый надёжный сигнал — падение оффлайн-метрик поиска.

• Hit Rate (HR@k) — доля запросов, для которых ретрайвер нашёл хотя бы один релевантный документ в top-k.
• Recall@k — доля всех релевантных документов, попавших в top-k.
• Mean Reciprocal Rank (MRR) — средняя арифметическая обратных рангов первого релевантного результата.

Для мониторинга нужно регулярно прогонять тестовый набор запросов с размеченной релевантностью (gold standard). Если HR@10 упал с 0.85 до 0.72 за неделю — почти наверняка произошёл дрейф.

Порог срабатывания (alert):

• Падение HR@k или Recall@k более чем на 10% от эталонного значения (среднее за последние 7 дней).
• Падение MRR ниже 0.5.
• Рост zero-hit rate выше 15%.

Пример расчёта для мониторинга (псевдокод):

baseline = {'hr10': 0.85, 'recall10': 0.70, 'mrr': 0.65}
current = compute_metrics(test_queries, retriever, gold_standard)

for metric, baseline_val in baseline.items():
    if current[metric] < baseline_val * 0.9:   # падение на 10%
        trigger_alert(metric, baseline_val, current[metric])

5. Alert: пороги и действия

Система оповещения должна быть многоуровневой:

Термин «Переиндексация» (reindexing) — процесс повторного создания векторного индекса по обновлённому корпусу документов (например, с новыми чанками или пересчитанными эмбеддингами).

6. Действие: переобучение embedding модели или переиндексация

Если дрейф подтверждён, возможны два основных действия:

1. Переиндексация (reindexing) — если изменился корпус документов или модель эмбеддингов осталась прежней, но старые эмбеддинги больше не соответствуют новым запросам. Нужно заново прогнать все документы через модель и перестроить индекс (например, FAISS или Pinecone).

2. Дообучение (fine-tuning) модели эмбеддингов — если распределение запросов сильно изменилось, может потребоваться адаптировать саму модель (например, используя контрастивное обучение на новых парах запрос-документ). Это более дорогая операция, поэтому её запускают только после анализа причин дрейфа.

Алгоритм принятия решения:

• Если дрейф обнаружен по эмбеддингам документов (документы изменились) -> переиндексация.
• Если дрейф по запросам (запросы ушли в другую область) -> дообучение модели эмбеддингов.
• Если оба -> сначала дообучение, затем переиндексация.

7. Инструменты для мониторинга дрейфа

• Evidently AI — библиотека с готовыми отчётами по data drift, включая эмбеддинги. Поддерживает RAGAS-подобные метрики.
• WhyLabs — облачный мониторинг для ML-моделей, умеет отслеживать дрейф эмбеддингов через WhyLogs.
• MLflow — с версии 2.0 есть возможность логировать распределения эмбеддингов и строить дашборды.
• Custom скрипт (см. пример выше) — наиболее гибкий вариант, может быть интегрирован в Apache Airflow или Prefect для автоматического запуска раз в неделю.

Рекомендация: начать с Evidently AI — он даёт визуализации (гистограммы распределений, временные ряды метрик) и прост в интеграции с Python.

8. Пример автоматического пайплайна мониторинга

# schedule: каждый понедельник в 8:00
# pipeline.py

from evidently.report import Report
from evidently.metrics import EmbeddingDriftMetric, ColumnDriftMetric
import pandas as pd

def run_monitoring_pipeline():
    # 1. Загружаем эталонные эмбеддинги (например, из parquet)
    ref_embeddings = pd.read_parquet('reference_embeddings.parquet')
    # 2. Получаем новые эмбеддинги запросов за неделю
    new_embeddings = get_embeddings_from_logs(last_7_days=True)
    
    # 3. Формируем отчёт Evidently
    drift_report = Report(metrics=[
        EmbeddingDriftMetric('embedding_drift', threshold=0.1),
        ColumnDriftMetric('query_length'),
    ])
    drift_report.run(reference_data=ref_embeddings, current_data=new_embeddings)
    
    # 4. Проверяем результат
    result = drift_report.as_dict()
    if result['metrics'][0]['result']['drift_score'] > 0.1:
        send_alert('Critical drift detected')
        trigger_reindexing()

# Запуск по cron или Airflow

9. Различие между data drift, concept drift и model drift в RAG

Для RAG особенно важен data drift, так как retrieval напрямую зависит от распределения эмбеддингов. Concept drift можно обнаружить через метрики retrieval (hit rate падает, хотя эмбеддинги не изменились).

10. Практические советы по автоматизации

• Частота: достаточно раз в неделю, если объём запросов стабилен. Для высоконагруженных систем — раз в день.
• Хранение эталонов: сохраняйте снимок эмбеддингов запросов и документов сразу после деплоя, а также после каждого обновления модели.
• A/B тестирование: перед переиндексацией или дообучением проверяйте, что новая версия действительно лучше, на отложенной выборке (см. вопрос 70 о A/B тестировании).
• Логирование: обязательно сохраняйте все запросы и эмбеддинги в логи (например, в S3 или БД) — это позволит в любой момент вернуться к анализу.

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

Задача: Реализовать систему мониторинга дрейфа для RAG-бота на основе FAQ-корпуса (например, вопросы про Python).

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

• Python, scipy, sklearn, Evidently AI (или только scipy для начала)
• FAISS (или chromadb) для построения векторного индекса
• Библиотека sentence-transformers для генерации эмбеддингов
• Apache Airflow (можно заменить на cron + Bash)

Шаги:

1. Соберите корпус FAQ (200–500 вопросов-ответов) и синтезируйте эталонные запросы.
2. Обучите простой ретрайвер (cosine similarity по эмбеддингам sentence-transformers).
3. Разделите данные на две эпохи: "старые" запросы (эталон) и "новые" (симулируйте дрейф, добавив вопросы на другую тему, например, про Rust вместо Python).
4. Реализуйте скрипт, который считает Wasserstein между распределениями эмбеддингов старых и новых запросов, а также HR@5 для старого и нового набора.
5. Настройте алерт (например, вывод в консоль) при падении HR@5 более чем на 10%.
6. Добавьте автоматическую переиндексацию: при срабатывании алерта пересчитывайте эмбеддинги документов уже с новой моделью (или просто обновляйте индекс).

Ожидаемый результат: Скрипт, запускаемый по расписанию, который при симуляции дрейфа выдаёт предупреждение и автоматически запускает переиндексацию, после чего метрики возвращаются к норме.

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

Навигация

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