Что такое «canary testing» для агентов (10% трафика на новую версию)?

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

Canary testing (deployment|канареечное тестирование) — это стратегия постепенного развёртывания новой версии AI-агента (или любого компонента системы) с контролем ключевых метрик и автоматическим откатом при обнаружении проблем. В контексте агентов (RAG|Agentic RAG) это позволяет безопасно вносить изменения — например, менять LLM, prompt, retrieval pipeline или логику вызова инструментов — без риска испортить опыт всех пользователей. Типичная схема: направить 1% трафика на новую версию, затем 5%, 10%, 50% и, наконец, 100%, каждый раз проверяя quality gates.

1. Термин «Canary testing»: происхождение и суть

Название пришло из шахтёрского дела: в прошлом шахтёры брали с собой клетку с канарейкой, потому что птицы были очень чувствительны к угарному газу. Если канарейка переставала петь или погибала — шахтёры знали, что нужно срочно подниматься. В IT-сфере canary deployment означает, что сначала новую версию получает небольшая группа пользователей («канарейка»), а если с ней всё в порядке — развёртывание расширяется.

Для AI-агентов deployment|канареечное тестирование особенно критично, потому что:

• Недетерминизм LLM: один и тот же prompt может дать разный ответ в зависимости от температуры, версии модели или случайного seed.
• Многошаговость: агент может совершить несколько вызовов инструментов, каждый из которых может дать сбой.
• Сложность офлайн-валидации: автономные метрики faithfulness и answer relevance не всегда точно отражают поведение в реальном мире.
• Стоимость ошибки: неверный ответ финансового или медицинского агента может привести к серьёзным последствиям.

2. Архитектура canary-деплоя для агента

Чтобы проводить canary testing, нужна инфраструктура, которая позволяет разделять трафик между двумя версиями агента:

flowchart LR
    A[Пользовательский запрос] --> B[Роутер / Feature Flag]
    B --> C[Стабильная версия агента v1]
    B --> D[Канареечная версия агента v2]
    C --> E[Сбор метрик v1]
    D --> F[Сбор метрик v2]
    E & F --> G[Система мониторинга]
    G --> H{Качество gates?}
    H -- pass --> I[Увеличить долю v2]
    H -- fail --> J[Auto-rollback на v1]

Ключевые компоненты

• Роутер — может быть реализован через feature flags (например, LaunchDarkly, Split, самописный) или на уровне API-шлюза (NGINX, Envoy).
• Два инстанса агента — v1 (стабильная) и v2 (канареечная). Часто разворачиваются в отдельных контейнерах/pods с разными тегами.
• Система мониторинга — агрегирует метрики с обеих версий и сравнивает их в реальном времени.

3. Фазы развёртывания (progress stages)

Типовой план выкатки (может варьироваться в зависимости от критичности агента):

Каждый этап требует анализа метрик и явного одобрения (или автоматического перехода, если quality gates пройдены).

4. Мониторинг — что измерять

Для canary testing агента необходимо отслеживать как технические, так и качественные метрики.

4.1 Технические метрики

4.2 Качественные метрики (агентные)

4.3 Пользовательские метрики

• User feedback (лайки/дизлайки) — если есть интерфейс.
• Повторные запросы — пользователь переспрашивает один и тот же вопрос → возможно, агент не понят.
• Churn rate — уходы пользователей (долгосрочная метрика, для canary обычно не берётся).

5. Quality gates и условия автоматического отката

Quality gate — это набор правил (thresholds), при нарушении которых запускается auto-rollback (автоматический возврат на стабильную версию).

Пример конфигурации в псевдокоде:

# Псевдокод для системы canary gates
def check_gates(v2_metrics, v1_baseline):
    if v2_metrics.error_rate > v1_baseline.error_rate + 0.01:
        return "ROLLBACK: error rate increased by more than 1%"
    if v2_metrics.p95_latency > v1_baseline.p95_latency * 1.2:
        return "ROLLBACK: p95 latency > 120% of baseline"
    if v2_metrics.faithfulness < v1_baseline.faithfulness - 0.02:
        return "ROLLBACK: faithfulness dropped by more than 2%"
    if v2_metrics.answer_relevance < v1_baseline.answer_relevance - 0.05:
        return "ROLLBACK: answer relevance dropped by more than 5%"
    return "PASS"

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

6. Инструменты для реализации canary testing агентов

Для небольших проектов можно реализовать canary «вручную»: запустить второй инстанс агента, направить часть запросов через feature flag (запись в Redis), и периодически сравнивать метрики.

7. Лучшие практики canary testing для агентов

1. Начинать с 1%, а не с 10% — вопрос подчёркивает 10%, но стандарт — начинать с минимального трафика, чтобы даже критическая ошибка затронула лишь единицы.
2. Использоватьstratified sampling** — если пользователи различаются по активности или региону, распределять их равномерно, чтобы не исказить метрики.
3. Включать холодный старт — дать время v2 на прогрев кэшей/моделей (первые минуты могут быть шумными).
4. Мониторить не только средние, но и процентили — p95 latency может быть высокой, даже если средняя норма.
5. Автоматизировать откат, но оставить возможность ручного вмешательства (kill switch).
6. Измерять влияние на downstream-системы — если агент вызывает внешние API, их нагрузка тоже может измениться.
7. Документировать каждый выкат: какое изменение, какие метрики, длительность фазы, решение.

8. Пример сценария: смена LLM с GPT-4 на GPT-4o-mini

Допустим, вы хотите снизить стоимость агента, заменив GPT-4 на GPT-4o-mini. Canary testing:

1. 1% трафика — развернуть v2 с новой моделью, собрать error rate и latency.
   • Результат: error rate = 0.5% (baseline 0.3%) → auto-rollback, если порог 1% → ok.
2. 5% — добавить faithfulness. RAGAS показывает faithfulness 0.91 vs baseline 0.94 → падение больше 2%? Если да, откат. Если нет, переходим.
3. 10% — проверка cost per user: снижение на 40%, answer relevance не хуже.
4. 50% — мониторинг user feedback (через лайки) — без изменений.
5. 100% — финальное утверждение.

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

Задача: Реализовать симуляцию canary-развёртывания для простого AI-агента (чат-бот на основе LLM) с автоматическим откатом.

Инструменты: Python (Flask или FastAPI для сервера), Redis (для хранения доли трафика), Docker (для двух версий), Prometheus + Grafana (локально через docker-compose), RAGAS (для метрик качества).

Шаги:

1. Разверните две версии агента: v1 (LLM llama-2-7b) и v2 (LLM mistral-7b). Каждая — микросервис с одним эндпоинтом /chat.
2. Создайте роутер (на Flask), который читает из Redis canary_percent и направляет соответствующий процент запросов на v2.
3. Настройте сбор метрик: error rate, latency, faithfulness (через вызов RAGAS на отложенном анализе 10% логов).
4. Напишите фоновый worker, который каждые 5 минут сравнивает метрики v2 с baseline v1. Если какая-то метрика ухудшилась — уменьшает canary_percent до 0 (откат).
5. Запустите нагрузочное тестирование (например, locust) с искусственным ухудшением v2 (добавьте случайные ошибки). Убедитесь, что откат срабатывает.

Ожидаемый результат: вы получите работающий прототип canary deployment, который демонстрирует:

• автоматическое повышение доли при хорошем качестве,
• откат при превышении порогов,
• лог всех принятых решений.

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

Canary testing тесно пересекается с A/B тестированием (вопрос 789), но в A/B тестировании обе версии живут одновременно долгое время для статистического сравнения гипотез, а canary — это процесс развёртывания с акцентом на безопасность.

Навигация

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