Система работала месяцами — и в один день ответы стали хуже: промпты не срабатывают, формат плывёт, факты путаются. Ничего не меняли? Меняли — вендор обновил модель. Тихие обновления — норма облачных ИИ-сервисов: версии меняются, старые отключаются, поведение сдвигается. Разберём, как поймать деградацию в первый день, что должно быть в договоре заранее и что делать, когда качество уже упало.
Почему модели меняются незаметно
Облачный ИИ-сервис — живой продукт, и вендор меняет его постоянно:
- Тихие обновления. Модель дообучается или заменяется без объявления, эндпоинт тот же — клиенты замечают по поведению.
- A/B-распределение. Часть вашего трафика уходит на новую версию для оценки: два одинаковых запроса дают разные по качеству ответы.
- Отключение старых версий. Вендор выводит версию из эксплуатации в оговорённый или короткий срок — миграция обязательна.
- Смена поведения после модерации и фильтров. Без новой модели ответы могут стать «осторожнее» и бесполезнее для вашей задачи.
- Изменение лимитов и тарифов. Деградация бывает не только качественной: ужесточение лимитов или рост цены ломает экономику процесса так же надёжно, как испортившиеся ответы.
- Сброс настроек по умолчанию. Обновление приносит новые параметры — температуру, системные промпты, форматы ответа; молча сброшенные настройки меняют поведение вашей интеграции.
Ни одно из этих изменений не считается инцидентом у вендора — это его продуктовый процесс. Инцидентом оно становится у вас, если бьёт по вашему процессу. Значит, обнаруживать его должны вы — и автоматически.
Эталонный набор задач: ваш детектор качества
Основной инструмент — эталонный набор (golden set): 50–200 реальных задач вашего процесса с примерами эталонных ответов или критериями их оценки. Как его собрать:
- Возьмите типовые и граничные случаи процесса: частые запросы, сложные формулировки, известные ловушки.
- Зафиксируйте для каждого критерий успеха: точное совпадение, обязательные пункты, структура ответа.
- Прогоняйте набор при каждом изменении и раз в неделю; сравнивайте долю успешных ответов.
- Падение на несколько процентных пунктов — сигнал; падение на десятки — инцидент.
Этот же набор — ваш главный аргумент в разговоре с вендором: «на моих задачах доля корректных ответов упала с 92 до 71 процента» звучит убедительнее «стало хуже». Как встроить такие прогоны в постоянный регламент — в гайде об eval-регламенте для чат-бота.
Фиксация версии: договор и API
Защита от тихих обновлений — явная фиксация того, на чём работает ваша система:
- Технически: используйте версии моделей с зафиксированным именем там, где API это позволяет; избегайте алиасов, которые вендор переключает сам.
- Договорно: уведомление о существенных изменениях модели и поведения заранее; окно поддержки прежней версии после анонса; порядок миграции.
- Организационно: владелец сервиса подписан на канал изменений вендора и раз в месяц сверяет журнал версий.
Это обычные условия SLA на ИИ-систему: качество меняется только по известным правилам. Вендоры, которые не дают зафиксировать версию, фактически продают услугу «как получится» — учитывайте это при выборе.
План реакции на деградацию: шесть шагов
Когда качество всё-таки упало, двигайтесь по плану, составленному заранее:
- Подтвердить. Прогнать эталонный набор, зафиксировать метрику до/после, снять даты и номера версий из ответов API.
- Оценить удар по процессу. Где деградация видна клиенту, а где только внутри; можно ли временно поднять долю ручной проверки.
- Запросить откат. Обратиться в поддержку с фактами: версия, метрики, запросы. Если откат предусмотрен — включить.
- Патч промптов. Часть потерь лечится адаптацией промптов и few-shot примеров под новое поведение — это быстрее ожидания отката.
- Переключение. Для критичных сценариев — резервная модель через шлюз: переключение занимает часы, а не недели.
- Разбор. После стабилизации — что сработало, чего не хватило в договоре, что добавить в эталонный набор.
Диверсификация: вторая модель как страховка
Единственный вендор в критичном процессе — концентрированный риск: обновление, отключение версии, изменение тарифа или банкротство останавливают вас одновременно. Рабочее решение — модельный шлюз с возможностью переключения:
- основная модель — по соотношению качества и цены;
- резервная — проверенная на эталонном наборе и подключённая за час;
- переключение — настройка маршрута, а не переписывание приложения.
Шлюз заодно решает смежные задачи: лимиты затрат, маршрутизацию задач по сложности, учёт по подразделениям. О рисках зависимости от одного вендора — материал что будет с ИИ при банкротстве вендора.
Резервную модель выбирают по тому же эталонному набору, что и основную: она должна проходить ваши задачи на приемлемом уровне, а не просто существовать в списке поддерживаемых. Проверка резерва — часть регулярного регламента: раз в квартал прогоните набор через запасную модель и убедитесь, что переключение живо. Непроверенный резерв — это не страховка, а успокоительное.
Всё вместе — эталонный набор, зафиксированные версии, шлюз с резервом и регламент реакции — составляет эксплуатационную зрелость ИИ-контура. Она не видна в демо, но именно она отличает систему, которая переживает обновления вендора без паники, от системы, которую каждый релиз ставит на грань остановки.
Кому доверить эксплуатацию
Прогоны эталонного набора, обновления промптов, переключения версий — это регулярная работа, а не разовый проект. Варианты: обучить свою команду (нужен внутренний владелец), отдать на сопровождение подрядчику или собрать минимальный внутренний контур самоконтроля. Типовые вилки (не оферта): аудит и настройка регламента качества — от 90 000 ₽, пилот со шлюзом и эталонным набором — 480 000 ₽, эксплуатация с мониторингом — от 690 000 ₽ по смете под задачу.
Как читать метрики качества в отчётах вендора
Вендорские отчёты о «улучшении модели» полезны, но читаются с оговоркой: бенчмарки считаются на универсальных задачах, ваш процесс — не универсальный. Правила чтения:
- Универсальный рост — не ваша гарантия. Модель стала лучше в среднем по общим задачам — и хуже именно на вашем узком домене. Верно и обратное.
- Смотрите на свои классы задач. Просите разбивку по типам задач, близким вашему процессу: суммаризация, извлечение данных, следование формату.
- Ваш эталонный набор — финальная инстанция. Единственная метрика, за которую отвечает ваша система, — доля успехов на ваших задачах. Остальное — контекст.
- Фиксируйте базовую линию. Занесите метрику текущей версии в таблицу до любых обновлений — без базовой линии спор о деградации не выиграть.
Отдельно про новые версии: анонсы «модель стала умнее» не заменяют регрессионное тестирование. План знакомства с новой версией тот же, что при первой интеграции: эталонный набор, метрика, решение о переключении. Как оценивать качество системно — в гайде об eval-регламенте.
Вывод
Деградация качества после обновления вендора — не катастроф, а эксплуатационная ситуация, если к ней готовились. Эталонный набор задач ловит падение в первый день, зафиксированная версия и договорные условия дают рычаг для отката, модельный шлюз превращает переключение моделей в рутину. Без этой базы остаётся спорить с поддержкой на языке «стало хуже» — и проигрывать его.