ТЕХНИЧЕСКОЕ ЗАДАНИЕ: Настройка мониторинга дрейфа метрик faithfulness и recall

1. Цель задачи

Разработать и развернуть систему ежедневного мониторинга метрик faithfulness (фактологическая точность) и recall (полнота) для RAG-пайплайна. Система должна автоматически вычислять значения метрик по логам ответов, сохранять историю и отправлять алерт при отклонении текущего значения скользящего среднего за 7 дней от baseline более чем на 10%. Ключевой результат работающий дашборд с историей метрик и настроенный алерт, срабатывающий при значимом дрейфе.

2. Исходные данные

Если нет реального инструмента — симулируем:

1. Сгенерировать синтетические данные: создать файл logs_sample.json с 1000 записей за 30 дней. Каждая запись содержит поля: timestamp, question, answer, context, ground_truth, faithfulness, recall (метрики можно зашумлять для имитации дрейфа).
2. Использовать Python-скрипт для генерации: python generate_synthetic_logs.py --days 30 --records_per_day 50.
3. Результат сохранить в data/. В качестве baseline взять среднее за первые 7 дней.

3. Технологический стек

4. Этапы выполнения

Этап 1: Определение baseline и порогов (1 час)

Действия

1. Проанализировать имеющиеся логи или сгенерированные данные за первые 7 дней.
2. Рассчитать среднее (mean_bb) и стандартное отклонение (std_bb) для каждой метрики.
3. Определить absolute threshold = mean_bb * 1.1 (верхняя граница) и mean_bb * 0.9 (нижняя граница) — отклонение >10% относительное.
4. Сохранить baseline в файл config/baseline.json.

Пример кода:

import json
import pandas as pd

data = pd.read_json('data/logs_sample.json')
baseline = data[data['timestamp'] < '2024-01-07']  # первые 7 дней
baseline_metrics = {
    'faithfulness_mean': baseline['faithfulness'].mean(),
    'faithfulness_std': baseline['faithfulness'].std(),
    'recall_mean': baseline['recall'].mean(),
    'recall_std': baseline['recall'].std()
}
with open('config/baseline.json', 'w') as f:
    json.dump(baseline_metrics, f)

Ожидаемый результат этапа файл config/baseline.json с эталонными значениями.

Этап 2: Разработка скрипта ежедневного расчёта метрик (3 часа)

Действия

1. Написать Python-модуль daily_metrics.py.
2. Реализовать функцию load_logs(date) – загрузка записей за конкретный день (или за последние 24 часа).
3. Реализовать функцию compute_faithfulness(answers, contexts) – например, с помощью LLM-as-judge (если доступна модель) или упрощённо: проверка, сколько ключевых фактов из контекста присутствуют в ответе (по совпадению NER-сущностей).
   • Вариант: использовать nltk.sent_tokenize и проверить, что каждое предложение ответа подтверждается контекстом (логический вывод опускаем для простоты).
4. Реализовать функцию compute_recall(answers, ground_truths) – доля фактов из ground truth, которые есть в ответе.
5. Сохранять результат в таблицу metrics_history (БД) или в Parquet-файл.

Пример упрощённого вычисления:

import nltk
from collections import Counter

def compute_faithfulness(answer, context):
    # Примитивный пример: извлекаем все существительные (ключевые сущности)
    answer_tokens = set(nltk.word_tokenize(answer.lower()))
    context_tokens = set(nltk.word_tokenize(context.lower()))
    # Фильтр: только существительные (можно использовать pos_tag)
    # Считаем долю существительных ответа, присутствующих в контексте
    common = answer_tokens & context_tokens
    return len(common) / len(answer_tokens) if answer_tokens else 1.0

Ожидаемый результат этапа скрипт, который для заданной даты возвращает два числа: faithfulness_daily, recall_daily.

Этап 3: Настройка хранения метрик (1.5 часа)

Действия

1. Развернуть PostgreSQL (или SQLite для локальной отладки).
2. Создать таблицу:

CREATE TABLE metrics_history (
    date DATE PRIMARY KEY,
    faithfulness FLOAT NOT NULL,
    recall FLOAT NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

3. Написать функцию store_metrics(date, faithfulness, recall).
4. Написать функцию load_last_7_days() для вычисления скользящего среднего.
5. Реализовать скрипт update_metrics.py, который запускает daily_metrics.py за вчерашний день и сохраняет результаты.

Ожидаемый результат этапа таблица с данными за прошедшие дни, возможность запроса истории.

Этап 4: Реализация алертов (2 часа)

Действия

1. В скрипте update_metrics.py после записи считать скользящее среднее за последние 7 дней (включая текущий).
2. Сравнить новое значение с baseline (среднее за первые 7 дней).
3. Если абсолютное относительное отклонение превышает 10%:
   • Сформировать сообщение: "Alert: faithfulness dropped from {baseline_faithfulness:.2f} to {current_ma7_faithfulness:.2f} (delta {delta:.1%})".
   • Отправить в Slack через webhook или по email (smtplib).
4. Для теста добавить флаг --force-alert для имитации срабатывания.

Пример отправки в Slack:

import requests

def send_slack_alert(message):
    webhook_url = "https://hooks.slack.com/services/..."
    payload = {"text": message}
    requests.post(webhook_url, json=payload)

Ожидаемый результат этапа рабочее уведомление при превышении порога.

Этап 5: Деплой и тестирование (1.5 часа)

Действия

1. Настроить ежедневный запуск update_metrics.py через cron (например, в 02:00 AM):

   0 2 * * * /usr/bin/python3 /path/to/update_metrics.py
   

2. Провести тестирование:
   • Запустить скрипт вручную для нескольких дат, проверить корректность записи.
   • Сымитировать дрейф, подставив завышенные/заниженные значения метрик в последних записях, убедиться, что алерт приходит.
3. Подготовить дашборд (опционально): в Grafana или простой Jupyter notebook с plotly для визуализации тренда.

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

5. Критерии приемки (Definition of Done)

• Разработан и зафиксирован baseline на основе первых 7 дней данных.
• Скрипт daily_metrics.py вычисляет faithfulness и recall для одного дня.
• Метрики сохраняются в таблицу metrics_history с датой.
• Реализована функция расчёта скользящего среднего за 7 дней.
• При отклонении скользящего среднего от baseline более чем на 10% отправляется алерт.
• Алерт содержит информацию о метрике, baseline, текущем значении и величине отклонения.
• Весь код версионирован в Git, есть README с инструкцией по запуску.
• Настроен cron-запуск (или альтернативный шедулер).
• Тестирование подтверждает, что алерт не срабатывает при нормальном шуме, но срабатывает при сильном дрейфе.
• Логи работы скрипта записываются в файл metrics_updater.log с ротацией.

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

• Основной артефакт каталог monitoring/ с файлами:
  • daily_metrics.py – расчёт метрик.
  • update_metrics.py – главный скрипт (загрузка, расчёт, запись, алерт).
  • config/baseline.json – baseline.
  • requirements.txt – зависимости.
  • README.md – описание развёртывания.
• Дополнительно дашборд в Grafana или notebook dashboard.ipynb с графиками.
• Состояние системы ежедневно обновляемая таблица metrics_history, на почту или в Slack приходят уведомления о дрейфе.

7. Возможные сложности и их решение

8. Бюджет времени (оценка)

Примечание: при первом выполнении задачи возможно увеличение времени на 20–30% из-за незнакомства с инструментами.

9. Связанные вопросы из базы знаний

10. Чек-лист самопроверки

• Я определил корректный baseline и проверил его на ретроспективе.
• Мой скрипт расчёта метрик обрабатывает edge cases (пустой ответ, отсутствие контекста).
• Я протестировал алерт: сымитировал дрейф и убедился, что уведомление приходит.
• Код покрыт хотя бы минимальными unit-тестами для функций расчёта метрик.
• В документации описан процесс добавления нового источника логов и изменения порога.