Обновилась модель ИИ: какие тесты повторить до рабочего запуска

Сохраните контрольный набор

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

Microsoft Copilot Studio описывает повторные прогоны набора тестов и сравнение результатов. Этот принцип применим независимо от выбранной платформы: одинаковые случаи показывают, что изменилось после обновления.

Сравните больше, чем качество текста

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

Выпускайте с возвратом

Сначала включите версию на ограниченном потоке или только в режиме черновиков. Запишите её идентификатор, дату, изменения инструкции и набора документов. У команды должен быть способ вернуть прежнюю конфигурацию без потери уже принятых задач. После выпуска проверяйте реальные ошибки и добавляйте новые обезличенные случаи в регрессионный набор.

Тест внешнего действия

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

Сравнивайте версии честно

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

После выпуска

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

Кто утверждает обновление

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

Сколько наблюдать после переключения

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