Канареечный выпуск модели: трафик, стоп-метрики, откат

Почему новый релиз ломает больше, чем кажется

Один удачный тест на выборке почти ничего не гарантирует. Когда команда переводит на новую модель весь поток, меняется не только качество ответа. Меняются задержка, цена запроса, длина ответа, формат данных и поведение всей цепочки вокруг модели.

На 100% трафика обычно ломаются не самые заметные вещи. Чат отвечает чуть медленнее, парсер получает не тот JSON, биллинг уходит выше плана. Пользователь видит только "странный ответ", а команда потом часами ищет, где именно сбой.

Чаще всего проблемы выглядят так:

• модель пишет лишний текст вокруг JSON, и интеграция не может его разобрать
• время ответа растет на 400-800 мс, и очередь запросов быстро увеличивается
• средняя цена запроса подскакивает из-за более длинных ответов
• на редких сценариях модель ошибается чаще, хотя средняя оценка выглядит нормально

Средняя метрика особенно коварна. Если смотреть только на общий pass rate или одну усредненную оценку, легко пропустить провал на отдельной группе запросов. Например, 95% диалогов идут нормально, но обращения с таблицами, адресами или юридическими формулировками новая модель обрабатывает хуже. На дашборде все зеленое, а в проде уже горят тикеты от одной, но важной функции.

Тихий провал обычно приходит с трех сторон: задержка, цена и формат ответа. Текст может стать лучше, но бизнесу от этого мало пользы, если SLA просел, бюджет вырос, а downstream-сервис перестал понимать структуру ответа. Для команд, которые гонят запросы через единый endpoint, как в AI Router, риск выше по одной причине: сменить модель слишком легко. Один base_url и один флаг не заменяют проверку на реальном трафике.

Еще одна частая ошибка - начинать спорить об откате уже во время инцидента. Один инженер смотрит на качество, другой на стоимость, третий просит "еще 15 минут данных". Пока команда спорит, пользователи получают плохие ответы. Канареечный выпуск работает только тогда, когда правила остановки известны заранее: кто принимает решение, какие метрики ставят релиз на паузу и при каком пороге команда возвращает старую модель без обсуждений.

Что подготовить до первого процента

До старта нужен не список надежд, а нормальная точка отсчета. Сначала закрепите текущую модель как baseline: ту же версию, те же параметры, тот же шаблон промпта и те же лимиты. Иначе через день никто не поймет, новая модель дала сбой или команда случайно поменяла половину контура сразу.

Сравнение работает только на одном и том же наборе сценариев. Возьмите короткий, но живой пакет запросов: частые вопросы пользователей, длинные диалоги, редкие сложные кейсы и проблемные промпты из прошлых инцидентов. Обе модели должны пройти через одинаковые входные данные. Иначе цифры будут красивыми, но бесполезными.

У релиза должен быть один владелец. Он решает, когда дать 1%, когда остановиться и кто подтверждает рост трафика. Рядом нужен отдельный человек на откат. Лучше, если он не спорит о качестве ответов, а просто возвращает старую модель по заранее согласованной команде.

Перед запуском убедитесь, что команда видит в одном месте логи запросов, ошибки и стоимость. Если новый маршрут отвечает чуть лучше, но цена на тысячу запросов выросла вдвое, это уже проблема. Для LLM-релизов деньги утекают тихо, особенно когда растет длина ответа или модель чаще уходит в повторные вызовы.

Минимальная проверка перед первым процентом простая:

• старая модель закреплена как baseline
• набор тестовых сценариев одинаков для обеих моделей
• назначены владелец релиза и человек на откат
• видны latency, ошибки, доля пустых или обрезанных ответов и стоимость
• откат делается одним понятным действием

Сам откат не должен требовать получасового созвона. Если вы используете единый LLM-шлюз и меняете только маршрут или имя модели, возврат к прошлой версии занимает минуты. Если для отката нужно править код, пересобирать сервис и ждать деплой, к 1% трафика вы еще не готовы.

И еще одна мелочь, которую часто забывают: предупредите поддержку, дежурного инженера и продуктовую команду, что релиз начинается. Тогда первые жалобы не потеряются в общем шуме. Обычно хватает короткого сообщения: когда стартуем, что меняем, кто принимает решение, по какой фразе останавливаем выпуск и кто жмет откат.

Как поднимать проценты трафика

Не отдавайте новой модели заметную долю запросов в первый час. Для старта почти всегда хватает 1%. На этом этапе лучше брать обычные, повторяющиеся сценарии: частые обращения в поддержку, простые вопросы, типовые задачи извлечения данных. Редкие и спорные кейсы в начале только мешают увидеть реальную картину.

Этот 1% держат не меньше одного окна наблюдения. Длина окна зависит не от календаря, а от формы вашего трафика. Если поток ровный и большой, иногда хватает часа. Если утром, днем и вечером запросы ведут себя по-разному, ждите полный цикл. Иначе модель может выглядеть нормально на спокойном отрезке и просесть в пике.

Дальше трафик лучше поднимать ступенями: 1%, потом 5%, 10%, 25%, 50% и только потом 100%. Такой темп кажется медленным, но почти всегда обходится дешевле, чем спешка. Когда команда прыгает с 1% сразу на 25%, она часто пропускает момент, где качество уже ушло вниз, а проблема еще не стала громкой.

На каждом шаге ждите сопоставимый объем запросов. Если на первом этапе вы собрали около 800 типовых обращений, на 5% и 10% стоит дождаться близкой по размеру и составу выборки. Иначе вы сравниваете разные часы, разную аудиторию и разный размер выборки.

Не меняйте в один день регион, канал и модель. Если вы включили новую модель только для веб-чата в одном регионе, команда быстро поймет, что именно изменилось. Если в тот же день добавить мобильный канал, другой регион и новую маршрутизацию, причина сбоя растворится в деталях.

Если команда выпускает модель через AI Router или другой OpenAI-совместимый слой, лучше оставить все вокруг без изменений: тот же base_url, те же SDK, те же промпты и те же лимиты. Тогда вы проверяете именно модель, а не весь стек сразу. Это особенно помогает при откате.

Какие метрики ставят выпуск на паузу

Рост трафика останавливают не по ощущению, а по порогам, которые команда согласовала до релиза. Разовый всплеск не повод паниковать. Серия плохих минут - уже повод нажать паузу.

Первый сигнал - ошибки выше базы. Смотрите не только на 5xx и таймауты, но и на пустые ответы, отказы без причины, обрывы стрима и невалидные tool calls. Если доля таких сбоев заметно выше обычного уровня и держится 10-15 минут, процент трафика не увеличивают.

Второй сигнал - задержка. Для LLM это часто больнее, чем кажется: ответ формально пришел, но пользователь уже ушел. Поэтому следят не за средним временем, а за p95 или p99. Если ваш SLO для ответа 5 секунд, а канарейка стабильно дает 7-8 секунд, выпуск лучше заморозить сразу.

Третий сигнал - цена ответа. Новая модель может писать длиннее, чаще вызывать инструменты или хуже работать с кешем. На малом трафике это выглядит терпимо, а на 20% запросов уже бьет по бюджету. Полезно держать жесткий лимит на среднюю стоимость ответа или на 1000 запросов.

Четвертый сигнал - поломка нужного формата. Если продукт ждет JSON, таблицу полей или строгий шаблон для оператора, даже хороший текст без структуры бесполезен. Когда доля ответов, которые не проходят схему или требуют ручной правки, заметно растет, канарейку лучше не расширять.

Обычно хватает таких стоп-правил:

• ошибки выше базы на 20-30% и держатся 10-15 минут
• p95 задержки вышел за SLO два окна подряд
• средняя цена ответа превысила лимит команды
• доля ответов вне схемы заметно выше текущей модели
• ручная проверка показала риск в чувствительных сценариях

Ручная проверка нужна там, где ошибка дорогая или опасная. В поддержке банка, например, стоит отдельно просматривать ответы про блокировку карты, спорные списания и персональные данные. Автоматика такие вещи часто пропускает, а человек замечает их за десять минут.

Если трафик идет через AI Router, команде проще сверять цену, задержку и аудит-логи в одной точке и быстро ограничить рост через rate-limits на уровне ключа. Это не спасает от плохой модели, но заметно ускоряет паузу и откат.

План выпуска по шагам

Канареечный выпуск работает только тогда, когда вы сравниваете одинаковые срезы трафика, а не впечатления команды. Сначала снимите базовые числа по старой модели за тот же день недели, тот же час и те же сценарии. Если старая версия обрабатывает ночные короткие запросы, а новая попала на дневной поток со сложными диалогами, выводы будут ложными.

Обычно хватает простой лесенки роста:

1. Снимите базу на старой модели: долю ошибок, задержку, стоимость на 1000 запросов, долю ручных эскалаций и продуктовый сигнал, который важен именно вам.
2. Включите 1% трафика на новую модель и оставьте только одинаковые сценарии для сравнения.
3. Проверьте метрики через заранее заданное окно, например 30 или 60 минут, и зафиксируйте решение: растем, держим долю или откатываем.
4. Поднимите долю до 5%, потом до 10%, если новая модель держит уровень по качеству, задержке и цене.
5. Дальше идите крупнее, например 25% и 50%, но только если два последних окна прошли без стоп-сигналов.

После каждого шага нужна запись в журнале релиза. Достаточно одной строки: время, процент трафика, какие метрики посмотрели, кто принял решение и почему. Это сильно экономит время, когда через два часа нужно понять, на каком шаге все пошло не так.

Не поднимайте долю во время инцидента, деградации провайдера или пика нагрузки. В такие часы шум в данных слишком высокий, и команда часто принимает плохие решения из спешки. Если вы выпускаете модель через шлюз, особенно важно не менять маршрут и процент одновременно.

Если два стоп-сигнала подряд сработали в соседних окнах наблюдения, откатывайте сразу. Не ждите "еще 15 минут". В релизе модели лишняя надежда обычно обходится дороже, чем быстрый возврат на старую версию.

Как вести отчет, чтобы быстро откатить решение

Отчет по канарейке нужен не для архива. Его задача проста: за 2-3 минуты показать, продолжаете вы выпуск или возвращаете старую модель.

Верх отчета лучше держать коротким: дата, владелец выпуска, старая модель, новая модель, сервис, где идет трафик, и текущее решение. Если релиз идет через единый шлюз вроде AI Router, полезно сразу записать model id, провайдера и версию конфигурации. Иначе потом легко перепутать, что именно вы сравнивали.

Что должно быть в отчете

Одна таблица почти всегда работает лучше длинного текста. В ней видно каждый шаг роста трафика, сколько вы наблюдали систему и что именно пошло не так.

Ставьте рядом четыре вещи: ошибки, задержку, стоимость и качество. Если разнести их по разным дашбордам, команда начнет спорить вместо решения. Когда все в одной строке, картина понятна сразу.

После таблицы добавьте 3-5 проваленных запросов. Не пересказывайте их общими словами. Лучше использовать один и тот же формат:

• входной запрос
• ответ старой модели
• ответ новой модели
• что именно не так

Хватает коротких примеров. Один запрос ушел в отказ без причины, второй дал опасную фактическую ошибку, третий ответил слишком длинно и сорвал SLA. Такой блок помогает принять решение без лишних обсуждений.

В конце отчета должна быть одна строка с одним выбором: "идем дальше", "держим" или "откатываем". Рядом - причина в одном предложении. Например: "Откатываем: на 10% трафика P95 вырос выше лимита, а доля ошибок почти удвоилась".

Если после чтения отчета команде все еще нужен длинный созвон, отчет слишком расплывчатый.

Пример: чат поддержки банка

Банк не пустил новую модель во весь чат поддержки сразу. Команда выбрала только простые обращения: "какой у меня лимит по карте", "где ближайший банкомат", "как узнать статус доставки карты". Все, что касалось блокировки карты, спорных списаний и условий кредита, осталось на старой модели.

Такой подход заметно снижает риск. Если новая версия начнет отвечать странно, она затронет только узкий набор диалогов, а не всю поддержку.

Утром новой модели дали 5% дневного трафика по этим сценариям. Маршрутизацию включили на один час и сравнили старую и новую версии по трем метрикам: цене на диалог, доле ответов по шаблону и числу переводов на оператора.

Через 60 минут картина стала неприятной, но ясной. Средняя цена диалога выросла на 26%, потому что модель отвечала длиннее и чаще просила уточнения. Доля ответов вне утвержденного шаблона поднялась с 1,8% до 6,4%. Переводы на оператора тоже пошли вверх: клиенты чаще переспрашивали после расплывчатых ответов.

Что увидела команда

Один диалог показал проблему лучше любой сводки. Клиент спросил, готова ли карта к выдаче. Старая модель выдавала короткий ответ по внутреннему шаблону и предлагала проверить статус в приложении. Новая модель добавила лишний текст, предположила причину задержки и использовала формулировку, которой не было в согласованном сценарии.

Команда не стала спорить, насколько это критично. Пороги сработали, значит релиз надо откатывать. В тот же день они вернули старую модель для всего потока и зафиксировали причину остановки.

Что попало в отчет

В отчет вошли пять вещей:

• какой набор сценариев попал в канарейку
• какая доля трафика шла на новую модель и сколько длилось окно
• базовые и новые значения цены, шаблонности и эскалаций
• примеры 3-5 неудачных ответов
• решение команды и дата нового запуска

На второй запуск банк пошел осторожнее. Команда сократила набор сценариев до двух самых простых, снизила допустимый рост цены и подняла требование к ответам по шаблону. Это заняло меньше дня, зато следующий тест дал чистый сигнал: проблема была не в самой модели, а в слишком широком первом наборе запросов.

Ошибки, которые срывают канарейку

Чаще всего канарейка ломается не из-за самой модели, а из-за дисциплины релиза. Команда хочет ускориться и меняет сразу несколько вещей. Потом растет доля ошибок, но никто не может сказать, что именно их вызвало.

Типичные срывы обычно такие:

• в одном релизе меняют модель, системный промпт, роутинг и лимиты
• команда смотрит только на средние цифры и не режет данные по типам запросов
• выборка слишком маленькая, но трафик уже повышают
• причину остановки не фиксируют сразу
• откат существует только в презентации, а не в реальном процессе

Средние числа особенно обманывают в поддержке и в банке. На 1% трафика все выглядит спокойно, потому что туда попали простые запросы по балансу. На 5% приходят диалоги с длинным контекстом и проверками личности, и новая версия резко теряет качество.

Хорошая привычка проста: перед ростом трафика команда отвечает на два вопроса. Что именно мы поменяли? Как откатим это за несколько минут? Если ответ расплывчатый, выпуск рано расширять.

Если откат занимает 20 минут, требует три созвона и ручной поиск прошлой конфигурации, это не откат. Это надежда.

Короткий чек-лист перед ростом трафика

Перед тем как поднимать долю трафика, полезно сделать короткую паузу и проверить базовые вещи. Канарейка чаще ломается не на первом проценте, а на переходе с малого объема на заметный.

Если команда смотрит на одни и те же числа и понимает, кто нажимает стоп, риск падает сразу. Если один человек судит по жалобам в чате, а другой по дашборду, проблемы обычно тянутся дольше, чем должны.

• Порог остановки уже записан и виден всем. Не в голове у одного инженера, а в общем документе или канале.
• Старая модель готова к возврату в ту же минуту. Маршрут, версия и настройки лежат рядом с новой, а не в архиве прошлых задач.
• Дашборд показывает разницу, а не только общие графики. Старая и новая модель должны быть рядом.
• Есть отдельная выборка для ручной проверки, особенно для чувствительных сценариев.
• Отчет по прошлому шагу уже заполнен.

Если хотя бы один пункт не готов, трафик лучше не повышать. Лишние 30 минут проверки обычно обходятся спокойнее, чем быстрый откат после жалоб и ночного разбора логов.

Что делать дальше

Если такой порядок сработал хотя бы раз, закрепите его как стандарт для следующих релизов. Не держите проценты трафика, стоп-метрики и порядок отката в голове одного инженера. Короткий шаблон снимает лишние споры и помогает действовать спокойно, когда новая модель ведет себя странно.

В шаблоне обычно хватает нескольких полей: версия старой и новой модели, доля трафика на каждом шаге, пороги остановки, имя того, кто принимает решение, время проверки и итог. Через несколько выпусков история начинает работать на команду. По записям видно, где релиз шел ровно, а где ломался: на 5% трафика, после вечернего пика или при длинных диалогах.

Сохраняйте не только проблемы. Записывайте и удачные шаги: какой системный промпт оставили без изменений, сколько ждали между этапами, какой лимит на запросы помог удержать нагрузку, кто дал добро на рост трафика. Тогда команда не гадает, почему прошлый релиз прошел спокойно.

Откат стоит тренировать так же регулярно, как и сам выпуск. Многие команды умеют перевести 1% трафика на новую модель, но теряют время, когда нужно быстро вернуться назад. Полезно иногда делать учебный откат и замерять простой результат: сколько минут ушло на переключение, когда исчезли ошибки и все ли алерты пришли вовремя.

Если команда работает через единый OpenAI-совместимый шлюз, такой процесс проще держать под контролем. Например, в AI Router на airouter.kz можно менять base_url на api.airouter.kz и оставлять существующие SDK, код и промпты без изменений. Для канарейки это удобно: меньше мест, где можно ошибиться в спешке, и проще вернуть прошлую модель тем же способом.

После каждого релиза оставляйте короткую запись в одном формате: какая доля трафика дошла до продакшена, где сработал стоп, кто принял решение и сколько занял откат или рост. Когда эти ответы лежат рядом, следующий выпуск проходит быстрее и спокойнее.