Как вы измеряете drift retrieval-качества в RAG (когда документы меняются)?

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

Drift retrieval-качества — это ухудшение способности поискового компонента RAG находить релевантные документы со временем. Измерение дрифта требует фиксированного тестового набора (golden dataset) из 200–500 запросов с размеченными gold-документами. Ежедневный расчёт метрик (hit rate, MRR, recall@k) и сравнение с baseline позволяет выявить падение качества. При падении hit rate более чем на 10% за неделю срабатывает алерт. Основные причины дрифта: изменение распределения пользовательских запросов, обновление/добавление документов и деградация эмбеддинг-модели]].

1. Термин: Drift retrieval-качества

Drift (дрейф) — это постепенное или резкое отклонение качества работы системы от эталонного уровня. В контексте RAG retrieval quality (качество поиска) — это способность retrieval-компонента находить документы, релевантные запросу пользователя. Дрифт может быть вызван изменениями в данных (документы, запросы) или в самой модели (эмбеддинги, индексация). Измерение дрифта необходимо для своевременного обнаружения проблем и принятия мер (переобучение эмбеддингов, переиндексация, корректировка чанкинга).

2. Фиксированный тестовый набор (Golden Dataset)

Для объективного измерения дрифта нужен статический тестовый набор, который не меняется со временем. Он состоит из:

• 200–500 запросов, репрезентативных для реального использования системы.
• Для каждого запроса вручную размечены gold-документы — один или несколько документов (чанков), которые считаются правильным ответом.
• Набор должен покрывать разные типы запросов: фактологические, обобщающие, с перефразированием, редкие и частые.

Как создавать

1. Собрать исторические логи запросов за длительный период.
2. Выбрать стратифицированную выборку по частоте, сложности, доменам.
3. Аннотировать релевантные документы с помощью экспертов или сильной LLM (GPT-4) с последующей проверкой.

Важно тестовый набор фиксируется версионированием (например, в Git или DVC). При изменении документов в продуктивной БД gold-документы не переразмечаются — они остаются эталоном. Это позволяет измерять, как изменилось качество поиска по новым документам относительно старых эталонов.

3. Метрики для мониторинга дрифта

Используются те же метрики, что и для оффлайн-оценки retrieval, но применяются ежедневно к фиксированному тестовому набору.

Рекомендуемый набор HR@5, MRR@10, Recall@10. Они покрывают основные аспекты: наличие, ранг, полноту.

Пример интерпретации

• Baseline: HR@5 = 0.85, MRR = 0.72, Recall@10 = 0.65.
• Через месяц: HR@5 = 0.78, MRR = 0.63, Recall@10 = 0.58 — падение на 8–12% — дрифт.

4. Процесс измерения: ежедневный запуск

Измерение должно быть автоматизировано и выполняться ежедневно (или чаще, если документы обновляются непрерывно).

Пайплайн

1. Загрузить текущую векторную БД (или снэпшот индекса).
2. Для каждого запроса из тестового набора выполнить retrieval (embedding + поиск).
3. Рассчитать метрики (HR, MRR, Recall) для текущего дня.
4. Сравнить с baseline (среднее за последние 7 дней или значение на момент деплоя).
5. Записать метрики в систему мониторинга (Prometheus, MLflow).
6. Если падение превышает порог — отправить алерт.

Пример кода на Python (упрощённый):

import numpy as np
from datetime import datetime, timedelta
from your_rag_system import retrieve

# Тестовый набор: список запросов и gold-документов (id)
test_queries = [
    {"query": "Как работает attention?", "gold_ids": {"doc_123", "doc_456"}},
    # ... 200-500 запросов
]

def compute_metrics(retriever, queries, k=5):
    hit = 0
    rr_sum = 0.0
    recall_sum = 0.0
    total_gold = 0
    for q in queries:
        results = retriever.retrieve(q["query"], top_k=k)
        result_ids = {doc.id for doc in results}
        gold = q["gold_ids"]
        # Hit Rate
        if result_ids & gold:
            hit += 1
        # MRR
        for rank, doc in enumerate(results, 1):
            if doc.id in gold:
                rr_sum += 1.0 / rank
                break
        # Recall
        recall_sum += len(result_ids & gold)
        total_gold += len(gold)
    n = len(queries)
    hr = hit / n
    mrr = rr_sum / n
    recall = recall_sum / total_gold if total_gold > 0 else 0.0
    return hr, mrr, recall

# Ежедневный запуск
today = datetime.now().date()
hr, mrr, recall = compute_metrics(current_retriever, test_queries, k=5)
log_metrics(today, hr, mrr, recall)

5. Пороги и алерты

Базовый порог если hit rate упал более чем на 10% за неделю (скользящее среднее за 7 дней по сравнению с предыдущими 7 днями) — алерт. Дополнительные пороги:

• MRR упал >15% за неделю.
• Recall@k упал >20% за месяц.

Типы алертов

• Slack/Telegram — для команды разработки.
• Email — для менеджера продукта.
• Автоматическое отключение (rollback) — если падение >30% за сутки (опасно для production).

Стратегия эскалации

1. Предупреждение (желтый уровень) — падение 5–10%.
2. Критический алерт (красный уровень) — падение >10% + подтверждение на двух последовательных измерениях.

6. Причины дрифта

7. Дополнительные методы обнаружения дрифта

Помимо метрик на тестовом наборе, полезно мониторить:

• Распределение эмбеддингов документов — рассчитывать Population Stability Index (PSI) между эмбеддингами текущего индекса и эталонного снэпшота. PSI > 0.1 указывает на значительный сдвиг.
• Логи запросов — отслеживать частоту появления новых n-грамм, которых не было в тестовом наборе.
• Метрики пользовательского поведения (онлайн-метрики): CTR на документы, время до ответа, количество повторных запросов. Падение этих метрик может коррелировать с дрифтом retrieval.

Инструменты

• Evidently AI — библиотека для мониторинга дрифта данных и моделей.
• WhyLabs — платформа для observability ML-систем.
• MLflow — для логирования метрик и версий моделей.
• Prometheus + Grafana — для сбора и визуализации временных рядов.

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

Задача Разработать систему мониторинга дрифта retrieval для RAG-системы, работающей с корпусом научных статей.

Инструменты

• Python (FAISS, sentence-transformers, pandas, numpy)
• Streamlit (дашборд)
• MLflow (логирование метрик)
• DVC (версионирование тестового набора)

Шаги:

1. Собрать корпус из 10 000 научных статей (например, ArXiv).
2. Создать тестовый набор из 200 запросов с gold-документами (можно сгенерировать с помощью LLM и вручную проверить).
3. Реализовать retrieval на базе FAISS и sentence-transformers (all-MiniLM-L6-v2).
4. Эмулировать дрифт:
   • Через неделю добавить 1000 новых статей по другой теме.
   • Ещё через неделю заменить эмбеддинг-модель на более старую (all-MiniLM-L12-v2).
5. Написать скрипт ежедневного расчёта метрик (HR@5, MRR, Recall@10) и логирования в MLflow.
6. Построить дашборд в Streamlit: графики метрик по дням, пороговые линии, индикаторы алертов.

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

• Дашборд, на котором видно, как hit rate падает после добавления новых статей (с 0.85 до 0.72) и после смены модели (до 0.60).
• Автоматические алерты при падении >10% за неделю.
• Возможность просмотра метрик по отдельным запросам для диагностики.

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

Навигация

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