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

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

Drift retrieval-качества — это ухудшение точности поиска релевантных документов, вызванное изменениями в корпусе документов или распределении пользовательских запросов. Основной подход — мониторинг оффлайн-метрик (hit rate, MRR) на фиксированном тестовом наборе запросов. Если метрики падают более чем на 10% за неделю, система генерирует алерт. Дополнительно отслеживают дрейф эмбеддингов документов и запросов с помощью статистических тестов (PSI, KL-дивергенция). Это позволяет вовремя обнаружить деградацию retrieval и принять меры: переиндексацию, ретренинг эмбеддингов или адаптацию стратегии поиска.

1. Термин: Drift (дрейф) в контексте RAG

Drift (дрейф) — это изменение распределения данных или целевой переменной со временем, которое приводит к снижению производительности модели. В RAG выделяют два основных типа дрейфа:

• Data drift — изменение распределения входных данных (документов или запросов). Например, в корпус добавили новые документы с другой тематикой, или пользователи стали задавать вопросы на новом сленге.
• Concept drift — изменение связи между входом и выходом. В retrieval это означает, что ранее релевантные документы перестали быть релевантными для тех же запросов из-за изменения контекста или обновления знаний.

Для retrieval-качества критичен data drift, так как документы и запросы напрямую влияют на результаты поиска.

2. Почему документы меняются и как это влияет на retrieval

Документы в RAG-системе могут меняться по разным причинам:

• Добавление новых документов — расширение базы знаний.
• Удаление устаревших документов — чистка неактуальной информации.
• Обновление содержимого — исправление ошибок, дополнение фактов.
• Изменение структуры — переразбивка на чанки, смена эмбеддинговой модели.

Каждое изменение может сместить распределение эмбеддингов документов в векторном пространстве. В результате для фиксированного набора запросов меняется ранжирование: ранее релевантные чанки могут опуститься в выдаче, а нерелевантные — подняться. Это и есть drift retrieval-качества.

3. Метрики для обнаружения дрейфа

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

3.1 Hit Rate (HR@k)

Доля запросов, для которых хотя бы один релевантный документ попал в top-k. Чувствителен к полной потере релевантных документов.

HR@k = (число запросов с релевантным документом в top-k) / (общее число запросов)

3.2 Mean Reciprocal Rank (MRR)

Среднее обратных рангов первого релевантного документа. Отражает, насколько высоко в выдаче находится первый хороший результат.

MRR = (1/N) * Σ (1 / rank_i)

3.3 Recall@k

Доля всех релевантных документов, попавших в top-k. Полезна, когда на запрос есть несколько релевантных чанков.

3.4 Normalized Discounted Cumulative Gain (NDCG)

Учитывает graded relevance (частичную релевантность) и штрафует за низкие позиции релевантных документов. Более точная, но требует разметки с несколькими уровнями релевантности.

Сравнение метрик для мониторинга дрейфа

4. Фиксированный тестовый набор запросов (Gold Standard)

Чтобы измерять дрейф, нужен статический датасет запросов с размеченными релевантными документами (gold standard). Он не меняется со временем. Важно:

• Репрезентативность — запросы должны покрывать типичные сценарии использования.
• Стабильность — разметка релевантности не пересматривается (иначе мы будем измерять изменение разметки, а не дрейф).
• Регулярный прогон — каждую неделю (или день) запускаем retrieval на текущем корпусе документов и считаем метрики по этому набору.

Пример структуры gold standard (JSON):

[
  {
    "query": "Как работает attention в трансформерах?",
    "relevant_doc_ids": ["doc_123", "doc_456"]
  },
  ...
]

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

Типовой подход: если метрика упала более чем на 10% за неделю (или на 3 стандартных отклонения от скользящего среднего), отправляется алерт. Порог зависит от бизнес-требований:

• Для критичных систем (медицина, финансы) — 5%.
• Для информационных систем — 10-15%.
• Для экспериментальных — 20%.

Алерт может быть в виде email, сообщения в Slack или триггера на автоматический откат изменений.

6. Причины дрейфа

Понимание причины помогает выбрать правильное действие.

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

Помимо метрик retrieval, полезно отслеживать дрейф эмбеддингов — распределение векторов документов и запросов.

7.1 Population Stability Index (PSI)

PSI измеряет, насколько распределение эмбеддингов в текущем корпусе отличается от эталонного (например, на момент последней успешной индексации).

PSI = Σ (p_i - q_i) * ln(p_i / q_i)

где p_i — доля эмбеддингов в i-м бине эталонного распределения, q_i — текущего. PSI > 0.2 сигнализирует о значительном дрейфе.

7.2 KL-дивергенция

Аналогична PSI, но не симметрична. Используется для сравнения распределения запросов.

7.3 Мониторинг косинусного сходства

Если среднее косинусное сходство между запросами и их top-1 документами падает, это может указывать на дрейф.

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

• Evidently AI — open-source библиотека для мониторинга ML-моделей, умеет считать PSI, дрейф эмбеддингов, метрики качества.
• WhyLabs — SaaS платформа, интегрируется с MLflow, автоматически детектит дрейф.
• MLflow — встроенные возможности логирования метрик и сравнения по времени.
• Custom скрипты — на Python с использованием scipy.stats.ks_2samp (тест Колмогорова-Смирнова) для сравнения распределений.

Пример простого мониторинга на Python:

import numpy as np
from evidently.metrics import EmbeddingDriftMetric
from evidently.report import Report

# Эталонные эмбеддинги документов (например, при первом деплое)
reference_embeddings = np.load("reference_embeddings.npy")
# Текущие эмбеддинги
current_embeddings = np.load("current_embeddings.npy")

report = Report(metrics=[EmbeddingDriftMetric()])
report.run(reference_data=reference_embeddings, current_data=current_embeddings)
report.save_html("drift_report.html")

9. Как реагировать на дрейф

Обнаружив дрейф, нужно принять меры:

1. Переиндексация — пересчитать эмбеддинги для всех документов, если изменилась модель эмбеддингов или стратегия chunking.
2. Ретрейнинг эмбеддинговой модели — если дрейф вызван изменением семантики запросов, можно дообучить модель на новых данных.
3. Адаптация запросов — использовать query rewriting или гибридный поиск (sparse + dense), чтобы компенсировать дрейф.
4. Откат изменений — если дрейф вызван неудачным обновлением корпуса, вернуть предыдущую версию.
5. Уведомление команды — алерт должен содержать информацию о magnitude дрейфа и вероятной причине.

10. Пример кода: мониторинг hit rate с алертом

import pandas as pd
from datetime import datetime, timedelta

# Функция вычисления hit rate на gold standard
def compute_hit_rate(retriever, gold_standard, k=5):
    hits = 0
    for item in gold_standard:
        query = item["query"]
        relevant_ids = set(item["relevant_doc_ids"])
        retrieved_ids = [doc.id for doc in retriever.retrieve(query, top_k=k)]
        if relevant_ids & set(retrieved_ids):
            hits += 1
    return hits / len(gold_standard)

# Мониторинг
history = []  # список (timestamp, hit_rate)
threshold = 0.1  # 10% падение

while True:
    current_hr = compute_hit_rate(retriever, gold_standard, k=5)
    history.append((datetime.now(), current_hr))
    
    # Сравниваем со средним за последние 7 дней
    if len(history) >= 7:
        recent = [hr for ts, hr in history[-7:]]
        mean_hr = np.mean(recent)
        if current_hr < mean_hr * (1 - threshold):
            send_alert(f"Hit rate упал с {mean_hr:.3f} до {current_hr:.3f}")
    
    time.sleep(86400)  # раз в день

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

Задача Создать дашборд для мониторинга дрейфа retrieval-качества в RAG-системе, которая индексирует новости. Документы обновляются ежедневно.

Инструменты

• Python, Streamlit, Evidently AI, FAISS (векторная БД), Sentence-Transformers.
• Фиксированный gold standard из 50 запросов с разметкой.

Шаги:

1. Соберите датасет новостей (например, RSS-ленты) и разбейте на чанки.
2. Постройте gold standard: для 50 запросов вручную отметьте релевантные чанки.
3. Реализуйте retrieval (dense + FAISS) и функцию вычисления HR@5 и MRR.
4. Каждый день запускайте скрипт, который:
   • загружает текущие документы,
   • пересчитывает эмбеддинги,
   • вычисляет метрики на gold standard,
   • логирует результаты в CSV.
5. Используйте Evidently AI для отслеживания дрейфа эмбеддингов документов.
6. В Streamlit визуализируйте временные ряды метрик, PSI, и выводите алерты при падении >10%.

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

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

Навигация

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