Почему «новее» ещё не значит «лучше для вашего процесса»

Локальный помощник уже отвечает на вопросы сотрудников или готовит черновики для CRM. Выходит новая модель: в карточке красивее результаты тестов, а в календаре руководителя появляется соблазн заменить файл весов и вернуться к делам. Но рабочий сценарий — это не один общий балл. Новая модель может лучше писать общие тексты и хуже распознавать артикул, соблюдать формат JSON или признавать нехватку данных. Внутрик уже несёт обновление к серверу; человеку стоит сперва проверить, что вместе с ним не меняется качество обслуживания клиентов.

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

Что именно меняется

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

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

Сначала одинаковые задачи, потом живой трафик

Соберите 30–100 обезличенных примеров из реального процесса, а не только демонстрационные вопросы. Число здесь — рабочий ориентир для первого пилота, не статистическая гарантия. В наборе должны быть частые простые запросы, редкие дорогие ошибки, отсутствие ответа в базе, конфликтующие документы, длинные карточки, пустые поля и попытки вызвать неподходящий инструмент. Для каждого примера задайте ожидаемое решение или критерий проверки: точные поля, допустимые источники, обязательный отказ или передачу человеку.

Запустите старую и новую версии на одинаковых входах. Сравнивайте не только «понравился ли текст», но и долю принятых оператором результатов, ошибки по критическим полям, неправильные вызовы инструментов, долю запросов с эскалацией и время ручной правки. Для свободного текста выделите выборку для слепой проверки сотрудником; автоматический оценщик полезен, но не должен единолично подтверждать деловые факты. Инструменты вроде Promptfoo позволяют прогонять одни тестовые случаи по нескольким моделям с формальными проверками, однако сами критерии должны отражать ваш процесс.

Перед подачей новой модели пользователям можно устроить «теневой» прогон: копировать ей часть запросов, но показывать сотруднику ответ старой версии. Теневой ответ нельзя отправлять клиенту, записывать в CRM или запускать по нему реальные инструменты — иначе тест незаметно станет вторым исполнителем. Не копируйте чувствительные данные в новый контур, пока не проверены его размещение и правила хранения. Внутрик может очень старательно подготовить два письма вместо одного; отправлять оба ему никто не разрешал.

Маленькая канарейка и понятный откат

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

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

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

Сколько стоит осторожность

Параллельное обслуживание может потребовать второй GPU, дополнительной памяти или временной аренды. Для малого бизнеса это не всегда оправдано. Если сервер один, допустим последовательный тест в выделенном окне с сохранённым старым окружением и быстрым возвратом, но его нельзя выдавать за одновременный канареечный выпуск: сравнение на живом трафике будет слабее, а риск простоя выше. Ещё вариант — теневой прогон на отобранных обезличенных запросах в отдельное время без реальных действий. Выбор зависит от цены ошибки, объёма обращений и допустимого простоя.

Посчитайте стоимость обновления через дополнительные часы инфраструктуры, работу по тестам, ручную проверку и ожидаемую экономию времени оператора. Модельный пример: если новый вариант экономит 20 секунд на 2 000 принятых задачах в месяц, это около 11 часов; из результата нужно вычесть время исправлений и цену параллельного запуска. Допущения здесь явные: 2 000 сопоставимых задач, 20 секунд чистой экономии на принятой задаче, без учёта непрошедших проверку ответов. Это не результат какой-либо компании.

Практический старт

Выберите один внутренний сценарий без автоматической записи. Заморозьте старый контур, сохраните его конфигурацию и подготовьте набор эталонных задач с владельцем каждого критерия. Сравните версии офлайн, затем в теневом режиме; только после этого откройте новой версии ограниченный низкорисковый поток. Если приемлемое качество и работающий откат не подтверждены, не переключайте всю компанию. Цель обновления — не поставить «самую свежую» модель, а улучшить конкретный процесс без неприятного сюрприза утром понедельника.