ТЕХНИЧЕСКОЕ ЗАДАНИЕ: Настроить correlation метрик (граф зависимостей retrieval → generation latency)

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

Разработать систему мониторинга, которая строит граф зависимостей между временем выполнения компонента retrieval и задержкой генерации (generation latency) в RAG-пайплайне. Научиться выявлять, как изменения в retrieval (скорость поиска, размер результата) влияют на общую генерацию, и определять корневую причину (root cause) деградации latency.

Ключевой результат Граф корреляций в Grafana, позволяющий за <5 минут определить, какой именно этап (retrieval, embedding, контекстная подготовка) стал причиной роста latency генерации.

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

Перед началом необходимо иметь:

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

1. Развернуть RAG-пайплайн на локальной машине (например, на базе LangChain + Ollama + ChromaDB).
2. Создать нагрузочный тест с помощью locust или vegeta с разными параметрами retrieval (top_k от 3 до 20, разные embedding-модели).
3. Эмулировать изменение latency retrieval (например, принудительно добавить time.sleep(random.uniform(0.1, 1.0)) в метод search).
4. Собрать метрики latency в Prometheus через клиентскую библиотеку (prometheus_client) и трассировки через OpenTelemetry SDK.

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

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

Этап 1: Сбор метрик и трассировок (1–1.5 часа)

Действия

1. Инструментировать RAG-пайплайн OpenTelemetry

   • Установить opentelemetry-api, opentelemetry-sdk, opentelemetry-exporter-otlp.
   • В ключевых точках кода (вызов embedding, retrieval, контекстная сборка, запрос к LLM) создать spans с атрибутами: retrieval.latency_ms, generation.latency_ms, top_k, model_name.
   • Экспортировать трассы в Jaeger или Grafana Tempo.

2. Экспонировать метрики через Prometheus

   • Создать Histogram для latency retrieval (категории search, embedding) и для latency генерации (ttft, tpot).
   • Добавить Gauge для текущего top_k и количества документов в контексте.
   • Запустить Prometheus и настроить сбор.

3. Подготовить нагрузочный тест

   • Сценарий A: стабильная нагрузка, top_k=5.
   • Сценарий B: ступенчатое увеличение top_k от 3 до 20.
   • Сценарий C: внезапное увеличение latency retrieval (через time.sleep).

Ожидаемый результат этапа Prometheus содержит временные ряды retrieval_latency_seconds и generation_latency_seconds с одинаковыми метками (запрос → можно коррелировать).

Этап 2: Подготовка данных для корреляции (1 час)

Действия

1. Выгрузить метрики из Prometheus

   • Использовать Prometheus API (или PromQL) для получения временных рядов avg(rate(retrieval_latency_seconds_sum[1m]) / rate(retrieval_latency_seconds_count[1m])) и аналогично для generation.
   • Экспортировать в CSV через pandas + prometheus-api-client.

2. Агрегировать и выровнять по времени

   • Поскольку метрики могут собираться с разной частотой (scrape interval 15s), выполнить ресемплинг с шагом 1 минута.
   • Объединить оба временных ряда на временной метке (left join by timestamp).

3. Вычислить базовые статистики

   • Сдвиг между рядами (cross-correlation) для учёта задержки влияния.
   • Проверить стационарность (ADF test) — при необходимости взять разности.

Ожидаемый результат этапа Очищенный DataFrame с колонками timestamp, retrieval_latency, generation_latency.

Этап 3: Вычисление корреляций и построение графа зависимостей (1.5–2 часа)

Действия

1. Рассчитать корреляцию Пирсона и Спирмена

   • pearsonr (линейная зависимость) между retrieval_latency и generation_latency.
   • spearmanr (монотонная зависимость) — на случай нелинейных эффектов.
   • Интерпретация: если p-value < 0.05 и |r| > 0.5 — значимая корреляция.

2. Оценить лаговую корреляцию (cross-correlation):

   • Использовать scipy.signal.correlate или pandas.Series.autocorr со сдвигом от -10 до +10 минут.
   • Найти максимальный коэффициент и соответствующий лаг — это укажет, через какое время изменение retrieval сказывается на генерации.

3. Построить граф зависимостей

   • Узлы: Embedding, Search, Context Preparation, LLM call.
   • Рёбра: на основе корреляционных матриц, полученных из трассировок (можно вычислить корреляцию между spans разных этапов внутри одного запроса).
   • Использовать networkx для построения графа, визуализировать в виде дашборда Grafana Node Graph (потребуется экспорт в Prometheus в виде метрик графа).

4. Интегрировать граф в Grafana

   • Создать дашборд с панелью "Service Graph" (если используется Tempo) или "Node Graph" на основе кастомного data source.
   • Добавить временную шкалу для выбора окна анализа.

Ожидаемый результат этапа Интерактивный граф в Grafana, где толщина/цвет рёбер показывает силу корреляции между этапами.

Этап 4: Поиск корня (root cause) на основе графа (1 час)

Действия

1. Смоделировать инцидент

   • Запустить нагрузку с внезапным увеличением retrieval latency (например, сценарий C).
   • Наблюдать, как изменяются рёбра графа (корреляция с generation latency резко возрастает).

2. Определить аномальные узлы/рёбра

   • Настроить пороги: если корреляция между Search и LLM call > 0.8 при лаге < 30 секунд — помечать узел Search как потенциальную причину.
   • Использовать цветовую маркировку: зелёный – норма, жёлтый – предупреждение, красный – аномалия.

3. Сформулировать вывод

   • Найти узел, который имеет наибольший вклад в latency генерации (например, Search).
   • Зафиксировать root cause: "Увеличение времени поиска из-за фрагментации индекса привело к росту TTFT на 40%".

4. Написать отчёт

   • Краткое описание инцидента, скриншот графа, вывод по корреляции.

Ожидаемый результат этапа Идентифицированный root cause, подтверждённый данными корреляции и визуализацией.

Этап 5: Автоматизация проверки (опционально, 30 минут)

Действия

1. Написать скрипт на Python, который раз в N минут:

   • Получает свежие метрики из Prometheus.
   • Вычисляет корреляцию за последние 30 минут.
   • Если корреляция превышает порог (например, 0.7) и лаг меньше 1 минуты — отправляет alert в Alertmanager.

2. Добавить дашборд с мониторингом корреляции

   • Панель "Cross-correlation heatmap" (время на оси X, лаги на оси Y, цвет – сила корреляции).

Ожидаемый результат этапа Alert на случай, если retrieval latency начинает влиять на generation выше допустимого.

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

• В Grafana создан дашборд с графом зависимостей (минимум 3 узла: retrieval, context, generation).
• Граф отображает корреляцию между latency retrieval и generation latency (числовое значение и цвет).
• При нагрузочном тесте с изменением top_k или задержкой retrieval корреляция визуально меняется.
• Написан Python-скрипт, который вычисляет корреляцию Пирсона/Спирмена и выводит результат в консоль.
• Создан Prometheus alert для превышения порога корреляции > 0.7 с лагом < 30 секунд.
• Раздел "Root cause" в отчёте содержит однозначный вывод, какой компонент является узким местом.
• Время от запуска дашборда до нахождения корня по графу не превышает 2 минут.
• Трассировки (spans) доступны в Jaeger/Tempo и показывают соответствие метрик.

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

Основной артефакт

• Дашборд Grafana (JSON-модель), содержащий граф зависимостей (Node Graph) и панель с cross-correlation.

Сопроводительные артефакты

• Python-ноутбук (Jupyter) с расчётом корреляций и построением графа через networkx.
• Скрипт correlation_check.py для мониторинга и отправки alert.
• Отчёт (markdown) с описанием смоделированного инцидента и найденного корня.
• Конфигурация Prometheus (prometheus.yml) с правилами записи (recording rules) для агрегированных метрик.

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

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

Примечание: для первого выполнения (с нуля) может потребоваться до 8 часов из-за настройки OpenTelemetry и Prometheus. Если инфраструктура уже готова — 4 часа.

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

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

• Я развернул и настроил OpenTelemetry для всех ключевых этапов RAG-пайплайна.
• Я проверил, что метрики retrieval и generation latency имеют одинаковые метки (trace ID).
• Я выполнил ресемплинг и слияние временных рядов без потери данных.
• Я вычислил корреляцию Пирсона и Спирмена, получил статистически значимый результат (p < 0.05).
• Я построил граф зависимостей в Grafana и подтвердил, что при изменении retrieval latency граф визуально меняется.