Вы выкатываете новую модель или меняете промпт, и через час саппорт пишет: «бот стал хуже отвечать в длинных диалогах». По инфраструктуре все зелёное: 5xx не выросли, latency почти не изменилась. Но качество уже просело, пользователи недовольны, а команда спорит, откатывать ли релиз.
Это типичный сбой AI-релизов. Для таких изменений мало классического canary по uptime и error rate. Нужен rollout, где есть quality gates, заранее определённые пороги stop/continue/rollback и понятный владелец решения.
Почему обычный canary не спасает AI-релизы
В классическом backend-релизе вы чаще всего ловите деградацию через технические метрики: ошибки, таймауты, потребление ресурсов. Для AI-функций эти сигналы важны, но недостаточны.
Что меняется в AI-фиче
Когда вы релизите AI, меняется не только код:
- версия модели;
- системный промпт и цепочка инструкций;
- набор инструментов (retrieval, функции, MCP/tool calls);
- маршрутизация между моделями и fallback-логика.
Если менять всё сразу, деградацию трудно атрибутировать. В результате даже после отката непонятно, что именно сломалось.
Какие регрессии остаются невидимыми
Наиболее опасные деградации:
- Ответ формально приходит, но хуже решает задачу пользователя.
- Растёт доля fallback-сценариев («не могу помочь», «передано оператору»).
- Латентность слегка растёт, но критично растёт стоимость на запрос.
- Проседает качество только в определённых сегментах: длинные диалоги, конкретный язык, тип клиента.
Если у вас нет AI-метрик в canary, такие регрессии доходят до 100% трафика.
Дизайн rollout: как разложить релиз на управляемые этапы
Рабочая схема для большинства команд: 1% -> 5% -> 25% -> 50% -> 100%. Переход между этапами происходит только по заранее описанным гейтам.
Что считать единицей релиза
Сначала зафиксируйте release unit. Практичное правило: в один rollout включать только один тип изменения.
- Только модель (без изменения промпта).
- Только промпт (без смены модели и tools).
- Только toolchain/маршрутизацию.
Так вы точно понимаете причину деградации и ускоряете rollback.
Базовый набор quality gates
Ниже пример таблицы, которую удобно использовать как чеклист на каждом этапе:
Метрика Что измеряет Типичный stop-порог Зачем нужна Task pass rate Доля запросов, где ответ решает задачу Падение > 3 п.п. от baseline Прямой контроль качества Fallback rate Как часто срабатывает деградационный путь Рост > 20% от baseline Ранний индикатор «модель не тянет» Hand-off to human Доля эскалаций на оператора Рост > 15% Оценивает реальную нагрузку на команду p95 latency Время ответа Рост > 25% Защищает UX и SLO Cost per request Цена обслуживания одного запроса Рост > 15% Защищает экономику фичи
Важно: пороги задаются до запуска этапа, а не после первой тревоги.
Как долго держать этап
Частая ошибка: «подержим на 5% пару дней, там посмотрим». Это создает бесконечный canary без решения.
Для каждого этапа задайте:
- минимальный объём данных (например, N диалогов по ключевым сегментам);
- timebox (например, 2-4 часа на высоком трафике или сутки на низком);
- правило выхода: pass, stop или rollback.
Если данных недостаточно, этап не завершается и не эскалируется до следующего процента.
Реальный сценарий: деградация длинных диалогов на 5% canary
Сценарий из практики ботов поддержки: команда ввела новую маршрутизацию между быстрой и «умной» моделью. На коротких диалогах всё выглядело лучше, но длинные разговоры стали чаще уходить в fallback.
Что заметили в метриках
На 1% этап прошёл чисто. На 5% появились сигналы:
- общий error rate без изменений;
- p95 latency +8% (в пределах допуска);
- fallback rate в сегменте длинных диалогов +37%;
- hand-off to human +18% в том же сегменте.
Без сегментации это выглядело бы как «релиз нормальный». С сегментацией команда остановила rollout до 25% и откатила маршрут.
Почему rollback был быстрым
Откат занял минуты, потому что заранее были:
- feature flag с мгновенным переключением на предыдущий маршрут;
- владелец решения (on-call техлид), который имеет право отката;
- формальный триггер rollback по fallback rate в критичном сегменте.
Итог: деградация не дошла до 100% трафика, а команда получила чистый postmortem с конкретной причиной.
Rollback policy: что должно быть зафиксировано заранее
Rollback в AI-релизах нельзя оставлять на устные договоренности. Нужен документ на одну страницу, который команда реально применяет.
Минимальный шаблон policy
Поле Что фиксируем Trigger Точные условия отката (метрика + порог + окно времени) Owner Кто принимает решение об откате Timebox Максимум времени до полного отката Mechanism Чем откатываем: флаг, роутер, конфиг, версия промпта Communication Кого уведомляем и в каком канале Postmortem Где и когда фиксируем причины и действия
Практичное правило: если триггер сработал дважды подряд в одном этапе, rollout прекращается до разборов.
Короткий пример policy в виде конфигурации
rollout_stage: 5%
trigger:
- metric: fallback_rate.long_dialogs
condition: "> baseline * 1.20 for 15m"
owner: "oncall-techlead"
timebox_to_full_rollback: "10m"
rollback_action: "feature_flag.ai_router=v1"
Код здесь не цель. Важен сам принцип: решение заранее формализовано и исполнимо без совещания.
Частые ошибки, из-за которых canary теряет смысл
Ошибка 1: смотреть только на 5xx и latency
Если команда не меряет качество ответа, она замечает проблему слишком поздно. AI может «отвечать стабильно», но хуже решать задачу.
Ошибка 2: смешивать модель, промпт и toolchain в одном релизе
Такой релиз невозможно нормально отлаживать. Любой rollback превращается в гадание.
Ошибка 3: нет владельца отката
Когда критерии сработали, а решение принимает «вся команда», откат запаздывает. Нужен конкретный owner на смену.
Ошибка 4: нет срезов по типам запросов
Средние значения скрывают деградации. Минимум: короткие/длинные диалоги, язык, клиентский сегмент, тип сценария.
Ошибка 5: canary без дедлайна
Если не задан timebox, команда неделями живет в промежуточном состоянии и теряет темп релизов.
Как встроить это в текущий процесс разработки
Не нужно строить отдельную платформу с нуля. Начните с трёх практических шагов.
Шаг 1: единый реестр релизных параметров
В одном месте храните:
- feature_flag;
- версию модели;
- версию системного промпта;
- версию toolchain/маршрутизатора.
Это ваш single source of truth для расследований.
Шаг 2: preflight-чек перед этапом
Перед каждым повышением процента задавайте один и тот же вопрос: «какие критерии pass/stop/rollback для этого этапа?». Если критерии не выписаны, переход запрещён.
Шаг 3: обязательный postmortem даже при успешном rollout
Успешный rollout тоже даёт сигналы: какие сегменты были рискованными, какие метрики оказались бесполезными, где были ложные тревоги. Без этого процесс не улучшается.
Как применять это через ИИ
Эта тема естественно ложится на автоматизацию через ИИ, но только если ИИ не принимает финальное решение об откате сам.
Где ИИ действительно полезен
- Собирать разрозненные сигналы canary в единый отчёт по этапу.
- Подсвечивать аномалии по сегментам (например, только длинные диалоги на конкретном языке).
- Генерировать черновик рекомендации: continue, hold, rollback с привязкой к порогам.
- Готовить шаблон postmortem из фактов и таймлайна.
Где ИИ лучше не делегировать решение
- Финальный rollback/continue в проде.
- Изменение порогов «на лету» без owner-аппрува.
- Интерпретацию метрик без проверки контекста трафика.
Надежная схема: ИИ готовит выводы, человек с ролью owner принимает действие.
Практический чеклист перед выходом на 100%
Вопрос Да/Нет Изменение изолировано (модель или промпт или toolchain) Пороги stop/rollback заданы до старта этапа Есть owner rollback-решения на текущую смену Метрики качества и инфраструктуры смотрятся вместе Есть обязательные срезы по сегментам запросов Timebox этапа зафиксирован Откат можно выполнить за минуты через флаг/конфиг
Если хотя бы один пункт пустой, переход к большему проценту лучше отложить.
Что важно запомнить
Feature flags и canary для AI работают только тогда, когда вы относитесь к качеству как к первому классу метрик, а не к «дополнению к uptime». Хороший rollout - это не про смелость, а про управляемый риск: изолированное изменение, понятные гейты, быстрый откат и дисциплина по этапам.
Тогда релизы становятся предсказуемыми: вы быстрее внедряете улучшения и реже чините последствия массовых регрессий.