Как тестировать AI-агента после смены модели или промпта

Коротко

• Смена модели, промпта, температуры или описания инструментов — это новый релиз агента. Его тестируют так же, как код.
• Основа проверки — regression dataset: 50–200 реальных обращений с ожидаемым результатом. Его собирают из логов.
• Новую и старую версии прогоняют на одном наборе и сравнивают качество, формат, вызовы инструментов, стоимость и скорость.
• Расхождения смотрит человек. Автоматическая оценка отсеивает очевидное, но решение не принимает.
• Новую версию включают поэтапно: теневой режим, затем 10% трафика, затем весь. Старая версия остаётся рядом, и откат делается переключением настройки.

Почему «чуть-чуть поправили промпт» ломает работу

В обычном коде изменение локально: поменял функцию — сломалось там, где её вызывают. У LLM-агента одна строчка промпта влияет на всё поведение сразу. Добавили «отвечай короче» — агент перестал уточнять адрес доставки. Попросили «будь мягче с негативными отзывами» — он начал извиняться за то, в чём продавец не виноват, и намекать на компенсации.

Смена модели ещё рискованнее. Модели по-разному:

• держат формат. Одна стабильно отдаёт JSON, другая иногда пишет пояснение перед ним, и парсер в интеграции падает;
• вызывают инструменты. Новая модель может отвечать «по памяти» там, где старая проверяла остатки на складе;
• трактуют двусмысленности. «Перезвоните после обеда» для одной модели — задача на 14:00, для другой — просьба не беспокоить сегодня;
• расходуют токены. Если новая модель пишет длиннее, экономия на цене за токен исчезает.

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

Regression dataset: тестовый набор из вашей реальности

Regression dataset — набор входных ситуаций, для которых вы знаете правильный результат. Через него прогоняют каждую новую версию агента и смотрят, что изменилось. Без такого набора фраза «новая модель лучше» — впечатление от пяти ручных проверок в чате.

Откуда брать кейсы

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

• 60–70% — типовые обращения: статус заказа, цена, сроки, возврат, наличие;
• 20–30% — сложные: несколько вопросов в одном сообщении, опечатки, сарказм, расшифровка голосового;
• около 10% — опасные: просьба о скидке «как в прошлый раз», агрессия, попытка получить чужие данные или заставить агента нарушить правила.

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

Перед добавлением кейса маскируйте персональные данные: телефоны, ФИО, адреса. Тестовый набор часто лежит в репозитории или таблице, к которой есть доступ у подрядчиков.

Как описать ожидаемый результат

Для каждого кейса фиксируют не «идеальный текст», а проверяемые требования. Текст ответа будет меняться от прогона к прогону. Пример кейса для агента, который разбирает заявки:

id: lead-042
input: "Здравствуйте, нужна интеграция Ozon с 1С, бюджет обсуждаем, срок горит"
expected:
  status: qualified
  fields:
    channel: ozon
    integration: 1c
    urgency: high
  must_not:
    - назвать цену без расчёта
    - пометить лид как нецелевой
  tool_calls:
    - create_crm_lead

Статус, поля, вызванные инструменты и валидность JSON проверяет скрипт. Тон, полноту ответа и лишние обещания проверяет вторая модель по чек-листу или человек.

Workflow: от правки до полной раскатки

1. Зафиксировать, что меняется

Версия агента — это связка из модели, её параметров, системного промпта, описаний инструментов и базы знаний. У связки должен быть номер версии, а хранить её нужно в git или хотя бы в журнале изменений. Если вы не можете сказать, какой промпт работал 3 октября, инцидент от 3 октября вы не разберёте.

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

2. Прогнать набор на обеих версиях

Старая и новая версии получают одинаковые входы. Ответы LLM не детерминированы, поэтому сложные кейсы прогоняют 3–5 раз. Если лид квалифицирован правильно в трёх случаях из пяти, это не «работает», а «работает через раз».

3. Сравнить по метрикам

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

4. Просмотреть расхождения

Скрипт выдаёт кейсы, где версии ответили по-разному. Их смотрит человек, который знает процесс: руководитель поддержки, менеджер по продажам, селлер. Обычно это 10–30 диалогов и около получаса работы. Часть расхождений окажется улучшениями, и для них обновляют эталон.

5. Теневой режим

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

6. Частичная раскатка и откат

Затем новой версии отдают 10–20% трафика, лучше начать с менее рискованного сегмента, например с вопросов о наличии. Смотрят те же метрики, что в тестах, а также жалобы и ручные исправления менеджеров. Если всё в порядке, переводят весь трафик.

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

Сколько это экономит

Условный пример. Агент обрабатывает 300 заявок в день. Без регрессии обновление проверяют так: разработчик пишет агенту 15–20 сообщений, всё выглядит нормально, версия уходит в работу. Допустим, ошибка задела 10% лидов, а заметили её через 4 дня. Это около 120 заявок, которые всё это время лежали не в той воронке, и часть из них могла уйти к конкурентам.

С готовым набором на 150 кейсов прогон занимает 10–15 минут и стоит десятки рублей на API. Разбор расхождений — ещё около получаса. Первый раз на сборку набора уходит 1–2 дня, дальше его пополняют по мере инцидентов.

Есть и вторая выгода: появляется возможность экономить. Новые модели нередко заметно дешевле прежних. Без тестов переходить на них страшно, и бюджет на API месяцами остаётся завышенным. С тестами решение принимают за день и по данным.

Риски: где тесты не спасают

Устаревший набор. Ассортимент поменялся, правила возврата обновились, а эталоны остались прежними. Тесты проходят, а ответы неправильные. Набор пересматривают при каждом изменении правил бизнеса.

Слепое доверие модели-оценщику. LLM-оценщик может систематически предпочитать длинные ответы. Раз в месяц сверяйте 20–30 его оценок с оценками человека.

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

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

Действия без подтверждения. Тесты снижают вероятность ошибки, но не убирают её. Возвраты, скидки, изменение цен и рекламных ставок, удаление данных должны подтверждаться человеком, как бы хорошо агент ни прошёл проверку. Подробнее о границах ответственности — в статье AI-агент для бизнеса.

Как внедрить за 1–2 недели

1. Включить логирование. Записывать вход, ответ, вызванные инструменты, версию агента, токены и время ответа. Без логов не из чего собирать набор и нечего разбирать после инцидента.
2. Собрать первые 50 кейсов из логов и разметить ожидаемый результат вместе с человеком, который отвечает за процесс.
3. Написать скрипт прогона. Он берёт набор, прогоняет его через выбранную версию, сравнивает с эталоном и с предыдущей версией и сохраняет результат в таблицу.
4. Вынести версию агента в конфигурацию, чтобы модель, промпт и инструменты переключались без правки кода.
5. Принять правило: ни одна правка промпта или модели не уходит в работу без прогона и просмотра расхождений.
6. Добавлять каждый инцидент в набор в тот же день, когда его разобрали.

Если агента ещё нет и непонятно, какой процесс ему отдавать, начните со статьи Как понять, что процесс пора автоматизировать.

Чек-лист перед раскаткой новой версии

• [ ] Изменена одна вещь, версия записана.
• [ ] Регрессия прогнана на старой и новой версии, сложные кейсы — несколько раз.
• [ ] Нарушений формата и запретов нет.
• [ ] Стоимость и скорость одного обращения посчитаны.
• [ ] Расхождения просмотрел человек из процесса.
• [ ] Тесты не затрагивали боевые системы.
• [ ] Запланирован теневой режим или частичная раскатка.
• [ ] Откат на прежнюю версию проверен.

FAQ

Сколько кейсов нужно в тестовом наборе?

Для старта хватит 50 хорошо подобранных реальных обращений. Если агент обрабатывает сотни диалогов в день и вызывает несколько инструментов, нужен набор на 150–300 кейсов. Важнее объёма покрытие: типовые, сложные и опасные случаи плюс все прошлые инциденты.

Можно ли тестировать агента без программиста?

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

Нужно ли перетестировать, если поменялась только база знаний?

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

Как проверять ответы, у которых нет одного правильного варианта?

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

Что делать, если новая модель лучше по качеству, но дороже?

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

Как часто запускать регрессию?

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

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

Если агент уже работает, начните с малого. Включите полное логирование и за день соберите из логов 50 реальных обращений с ожидаемым результатом. Этого хватит, чтобы следующую смену модели или промпта проверять по данным, а не на глаз. Потом добавьте скрипт прогона, теневой режим и правило «без регрессии в работу не выпускаем».

Если хочешь понять, что автоматизировать у себя, — напиши Дмитрию в Telegram @dmkosik или опиши процесс для диагностики Paramiko.