Как вы делаете canary analysis для новой LLM модели?

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

Canary analysis (канареечный анализ) — это техника безопасного развёртывания новой LLM-модели, при которой на небольшой процент трафика (обычно 5 %) отправляется кандидат, а остальные 95 % продолжают работать на старой модели (baseline). В течение заданного окна (чаще всего 24 часа) автоматически отслеживаются ключевые метрики: error rate, latency p95, faithfulness и user feedback. Если любая метрика выходит за допустимый порог (например, error_rate > baseline + 1 %), происходит автоматический откат на старую модель. При успешном прохождении этапа трафик постепенно увеличивается до 25 %, 50 % и 100 %. Все запросы, обработанные кандидатом, помечаются меткой canary:true для последующего анализа логов.

1. Термин «Canary» и его происхождение

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

В контексте LLM-систем канарейкой становится следующая модель (например, GPT‑4 вместо GPT‑3.5 или fine-tuned версия). Она проходит тот же цикл: минимальная экспозиция, мониторинг, автооткат (automatic rollback) при ухудшении ключевых метрик.

2. Зачем нужен canary analysis для LLM?

Риски при деплое новой модели без защиты:

• ухудшение качества ответов (loss of faithfulness);
• увеличение задержки (latency);
• неожиданное поведение на edge-случаях;
• деградация пользовательского опыта (UX).

Canary analysis позволяет обнаружить регрессию на раннем этапе, пока новый трафик мал, и откатить модель автоматически, не привлекая инженеров. Это критически важно для production-систем, где стоимость ошибки высока.

Отличие от A/B тестирования
A/B тестирование обычно длится дольше и направлено на статистическое сравнение метрик бизнеса (conversion, satisfaction). Canary analysis — это инженерное средство безопасности, которое быстро (часы) проверяет технические пороги и решает, жить новой модели или нет.

3. Этапы rollout (градуальная раскатка)

Процесс состоит из фаз, каждая из которых защищена мониторингом.

3.1 Фаза «5 % / 24 часа»

• Направляем 5 % входящих запросов на новую модель.
• Остальные 95 % обрабатываются baseline-моделью.
• Время наблюдения — минимум 24 часа, чтобы собрать статистику и выявить проблемы, возникающие только при определённой нагрузке.

3.2 Фаза «25 %» (при успешном прохождении первой)

• Трафик на canary увеличивается до 25 %.
• Окно наблюдения может быть короче (например, 6–12 часов), но метрики всё равно должны укладываться в пороги.

3.3 Фаза «50 %»

• Дальнейшее масштабирование до 50 %.
• Риск снижен, потому что предыдущие фазы уже отсеяли критические дефекты.

3.4 Фаза «100 %»

• Вся нагрузка переключается на новую модель.
• Старый baseline переводится в stand-by, ready for rollback.

Почему именно такие проценты
Это «правило большого пальца» из практики DevOps: 5 % достаточно, чтобы заметить аномалию при большом потоке запросов, но слишком мал, чтобы навредить большинству пользователей. Увеличение шагами (5→25→50→100) даёт постепенный рост уверенности. Можно выбирать и другие доли: 1 %, 10 %, 30 %, 100 % — важно, чтобы каждый этап давал статистическую значимость для ключевых метрик.

4. Ключевые метрики мониторинга

Для canary analysis недостаточно одной метрики, нужен набор, покрывающий разные аспекты качества.

4.1 Error rate (частота ошибок)

• Определение доля запросов, завершившихся с ошибкой (5xx, 4xx, таймаут, NULL-ответ).
• Порог error_rate canary не должен превышать error_rate baseline более чем на 1 % (абсолютный). Например, baseline = 0.5 % ⇒ canary допустимо ≤ 1.5 %.
• Почему LLM-модели могут «зависнуть», выдавать пустой ответ или падать с internal error. Это самая грубая метрика, но она немедленно сигналит о катастрофе.

4.2 Latency p95 (задержка 95-го перцентиля)

• Определение время ответа, которое не превышает 95 % запросов.
• Порог p95 canary не должен превышать p95 baseline более чем на +20 %. Если baseline — 500 ms, то canary ≤ 600 ms.
• Зачем новая модель может быть медленнее (например, из-за большего числа параметров или сложного препроцессинга). Задержка напрямую влияет на UX.

4.3 Faithfulness (фактологическая точность)

• Определение метрика из RAGAS (или аналогичная), оценивающая, насколько ответ LLM опирается на предоставленный контекст.
• Измерение берём случайную выборку логов canary, прогоняем через RAGAS Faithfulness (диапазон 0–1).
• Порог средняя faithfulness canary не ниже baseline на 0.05. Снижение больше 0.05 — повод для отката.
• Важно вычислять faithfulness можно только для RAG-сценариев; для свободной генерации подходят другие метрики (например, answer_relevancy).

4.4 User feedback (лайки / дизлайки)

• Определение агрегированная оценка пользователей, часто в виде кнопок «👍 / 👎» или звёздочного рейтинга.
• Порог доля дизлайков для canary не должна превышать baseline более чем на 1 % (абсолютный).
• Ограничение пользовательский фидбэк может отставать по времени, поэтому не стоит полагаться только на него — он дополнительный.

5. Автоматический откат (auto-rollback)

При нарушении любого порога срабатывает триггер:

def should_rollback(baseline, canary, threshold=0.01):
    """True, если canary хуже baseline более порога."""
    error_rate_diff = canary.error_rate - baseline.error_rate
    # абсолютная разница для error rate
    if error_rate_diff > threshold:
        return True
    # относительное превышение для latency
    if canary.p95_latency / baseline.p95_latency > 1.2:
        return True
    # faithfulness ниже baseline -0.05
    if (baseline.faithfulness - canary.faithfulness) > 0.05:
        return True
    # user feedback: доля дизлайков
    if (canary.dislike_ratio - baseline.dislike_ratio) > 0.01:
        return True
    return False

• Действие при откате весь трафик мгновенно перенаправляется на baseline, canary выключается, инженерам отправляется алерт.
• Логи: все запросы, попавшие на canary, сохраняются с меткой canary:true и флагом rollback_reason для пост-мортема.

6. Логирование и метка canary:true

Каждый запрос, обработанный канарейкой, должен иметь в логах поле canary:true. Это позволяет:

• выбирать данные для анализа faithfulness;
• фильтровать трафик при поиске причины ошибок;
• строить дашборды сравнения canary vs baseline в реальном времени.

Пример структуры лога

{
  "timestamp": "2025-10-01T12:34:56Z",
  "request_id": "abc123",
  "model": "gpt-4-canary-v3",
  "canary": true,
  "phase": "25%",
  "error_rate": 0.0,
  "latency_ms": 450,
  "user_feedback": null,
  "faithfulness": 0.92
}

7. Инструменты реализации

Canary analysis для LLM обычно встраивается в ML‑пайплайн или оркестратор инференса. Варианты:

Популярный подход — использовать feature flags (например, LaunchDarkly) или weighted routers библиотек (llama‑index, haystack).

8. Выбор baseline и статистическая значимость

Baseline — это стабильная модель, которая уже работает на 100 % трафика. Важно, чтобы метрики baseline были измерены на том же временном интервале, что и canary, чтобы исключить дневные/недельные колебания.

Статистическая значимость для метрик error_rate и latency достаточно порогов по абсолютной/относительной разнице (инженерное правило). Для faithfulness и user feedback можно использовать t-тест или ранговые критерии, если нужно строгое доказательство. Однако на практике в canary используют детерминированные пороги, потому что главная цель — скорость реакции, а не статистическая строгость.

9. Длительность canary – когда достаточно?

Стандартное окно — 24 часа. За это время набирается достаточный трафик (тысячи запросов при 5 %), проходятся разные нагрузки и возможные edge-случаи. Когда этого мало

• Новая модель требует проверки на редких паттернах (например, запросы на специфическом языке) – увеличить до 48 ч.
• После каждой фазы (25 %, 50 %) можно сокращать интервал до 6–12 ч, т.к. предыдущие фазы уже отфильтровали грубые ошибки.

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

Задача реализовать canary‑деплой для простого LLM-сервиса на FastAPI с двумя версиями модели (stub‑функции, возвращающие фиктивные ответы).

Инструменты

• Python (FastAPI, asyncio);
• prometheus_client для метрик;
• локальный файл с порогами;
• скрипт автоматического отката.

Шаги:

1. Создать эндпоинт /generate, который случайным образом (вероятность 5 %) выбирает canary‑модель.
2. Обернуть вызов модели в декоратор, логирующий canary:true, latency, error.
3. Запустить фоновый сервис, который каждые 10 секунд собирает метрики canary и baseline и сравнивает с порогами.
4. При нарушении порога переключать вероятность canary на 0, записывать rollback_reason.
5. Создать простую Grafana (через Prometheus) для визуализации.

Ожидаемый результат при имитации ошибок в canary‑модели (установка error=True в 2 % запросов) автооткат срабатывает в течение минуты. При нормальной работе можно постепенно увеличивать долю трафика через API.

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

12. Навигация

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

Навигация

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