Как вы автоматизируете rollback при деградации качества?

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

Автоматизация rollback — критически важный компонент production-системы RAG|Agentic RAG. Она включает monitoring|непрерывный мониторинг метрик качества (faithfulness, latency, user feedback), настройку пороговых алертов и автоматическое переключение трафика на предыдущую стабильную версию при обнаружении деградации. Используются feature flags, canary deployments и A/B тестирование, чтобы минимизировать влияние на пользователей и ускорить реакцию команды.

1. Термины и контекст

Rollback — возврат системы к предыдущей стабильной версии (модели, пайплайна, конфигурации) после обнаружения ухудшения качества.

Деградация качества — снижение одной или нескольких ключевых метрик (например, faithfulness упала ниже 0.85, latency выросла на 30%) по сравнению с baseline.

Faithfulness — метрика, показывающая, насколько ответ LLM соответствует предоставленным документам (без галлюцинаций). В Agentic RAG также важны answer relevance, context relevance и user satisfaction (например, thumbs up/down).

Feature flag — механизм, позволяющий включать/выключать функциональность без передеплоя (например, LaunchDarkly, Flagsmith).

Canary deployment — постепенное переключение трафика на новую версию (сначала 1%, потом 5%, 20% и т.д.) с мониторингом на каждом шаге.

2. Зачем автоматизировать rollback?

• Скорость реакции: ручной rollback может занимать минуты или часы, за которые деградация затронет тысячи пользователей.
• Минимизация ущерба: автоматический откат за секунды останавливает распространение плохого опыта.
• Снижение когнитивной нагрузки: дежурный инженер не должен в панике вспоминать команды kubectl или переключать feature flags вручную.
• Возможность A/B тестирования: автоматизация позволяет безопасно экспериментировать с новыми версиями агентов, зная, что при проблемах система сама откатится.

3. Мониторинг метрик: что отслеживать?

Пороги могут быть статическими (фиксированное число) или динамическими (отклонение от скользящего среднего за последние 7 дней). Динамические пороги лучше адаптируются к сезонности.

4. Алертинг: от метрики к действию

Инструменты: Prometheus + Alertmanager → PagerDuty / Slack. Уровни:

• Warning (жёлтый): метрика вышла за порог, но не критично → уведомление в Slack, автоматический rollback не запускается.
• Critical (красный): метрика превысила порог на 20% или держится > 5 минут → автоматический rollback + вызов дежурного.

Пример правила Alertmanager:

groups:
  - name: rag_quality
    rules:
      - alert: FaithfulnessDegradation
        expr: avg(ragas_faithfulness{version="canary"}) < 0.85
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "Faithfulness dropped below 0.85 for canary version"

5. Механизм автоматического rollback

5.1 Feature flags (самый гибкий способ)

Новая версия агента или модели поднимается параллельно, но трафик на неё направляется через feature flag. При алерте система автоматически выключает флаг, и весь трафик возвращается на старую версию.

Пример кода (Python + LaunchDarkly):

import launchdarkly_client

client = launchdarkly_client.LDClient("sdk-key")

def should_use_new_version(user_id):
    return client.variation("new-rag-agent", {"key": user_id}, default=False)

# В рантайме:
if should_use_new_version(user.id):
    response = new_agent.process(query)
else:
    response = old_agent.process(query)

При алерте можно вызвать API LaunchDarkly:

client.toggle("new-rag-agent", False)  # выключить для всех

5.2 Canary deployment (Kubernetes + Istio)

Новая версия деплоится как canary (например, 5% трафика). Если метрики деградируют, Argo Rollouts или Flagger автоматически откатывают canary до 0%.

Пример конфигурации Flagger:

apiVersion: flagger.app/v1beta1
kind: Canary
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: rag-agent
  service:
    port: 80
  analysis:
    interval: 1m
    threshold: 5
    maxWeight: 50
    metrics:
      - name: request-success-rate
        thresholdRange:
          min: 99
      - name: request-duration
        thresholdRange:
          max: 500

5.3 Traffic switching через load balancer

При алерте скрипт меняет DNS или конфигурацию балансировщика (например, AWS ALB target group) — весь трафик идёт на старый экземпляр.

6. Полный pipeline автоматического rollback

1. Мониторинг — сбор метрик в реальном времени (Prometheus, Datadog).
2. Алерт — Alertmanager срабатывает при превышении порога.
3. Webhook — алерт отправляет POST-запрос в сервис оркестрации (например, Lambda-функцию).
4. Решение — сервис проверяет, не было ли уже rollback за последние N минут (чтобы избежать loop).
5. Действие:
   • Выключить feature flag (LaunchDarkly API)
   • Установить вес canary = 0 (Flagger)
   • Перенаправить DNS (Route53)
6. Уведомление — Slack / PagerDuty с деталями: какая метрика упала, какая версия откачена, время.
7. Пост-анализ — автоматическое создание тикета (Jira) для расследования причины.

7. Пример реализации на Python (упрощённый)

import requests
import time
from prometheus_api_client import PrometheusConnect

prom = PrometheusConnect(url="http://prometheus:9090")

def check_and_rollback():
    # Получаем среднюю faithfulness за последние 5 минут для canary
    result = prom.custom_query(
        'avg(ragas_faithfulness{version="canary"}[5m])'
    )
    if not result:
        return
    value = float(result[0]["value"][1])
    if value < 0.85:
        # Откатываем через LaunchDarkly
        requests.post(
            "https://app.launchdarkly.com/api/v2/flags/rag-canary",
            json={"on": False},
            headers={"Authorization": "api-key"}
        )
        # Уведомление в Slack
        requests.post(
            "https://slack.com/api/chat.postMessage",
            json={"channel": "#alerts", "text": f"Rollback triggered: faithfulness={value}"}
        )

8. Проблемы и риски автоматизации

9. Лучшие практики

• Постепенный rollout — никогда не включать новую версию на 100% сразу. Использовать canary (1% → 5% → 20% → 100%).
• Мониторинг после rollback — после отката продолжать следить за метриками, чтобы убедиться, что старая версия работает стабильно.
• Автоматическое отключение при повторных срабатываниях — если за короткое время произошло два rollback, перевести систему в ручной режим.
• Документирование runbook — описать каждый шаг автоматизации, чтобы дежурный понимал, что произошло.
• Тестирование на синтетических данных — перед деплоем прогонять новую версию на исторических запросах и сравнивать метрики.

10. Связь с Agentic RAG

В Agentic RAG агенты могут сами принимать решения о rollback на основе self-reflection. Например, агент замечает, что его ответы стали менее точными, и отправляет сигнал в систему управления версиями. Это требует дополнительной метрики agent self-confidence и механизма обратной связи.

Также агенты могут участвовать в A/B тестировании: один агент использует старую стратегию поиска, другой — новую, и система автоматически откатывает проигравшую.

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

Задача: Создать минимальную систему автоматического rollback для RAG-сервиса на Flask.

Инструменты: Python, Flask, LaunchDarkly (бесплатный план), Prometheus (локально через docker), Slack webhook.

Шаги:

1. Напишите два эндпоинта: /old и /new, которые возвращают ответы с разным качеством (например, /new иногда генерирует галлюцинации).
2. Подключите feature flag use_new_version в LaunchDarkly.
3. Реализуйте middleware, которое направляет запрос в зависимости от флага.
4. Запустите Prometheus и экспортируйте метрику faithfulness (можно симулировать случайное значение).
5. Напишите скрипт, который каждые 10 секунд проверяет метрику через PromQL и при падении ниже порога выключает флаг через API LaunchDarkly.
6. Отправьте уведомление в Slack.

Ожидаемый результат: При симуляции деградации (например, /new начинает выдавать плохие ответы) система автоматически переключает трафик на /old и шлёт алерт.

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

Навигация

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