Как протестировать AI-агента до запуска

Четверг, 16:40. Руководитель операционного отдела два дня собирал агента для записи на встречи и прогнал через панель тестирования двенадцать сценариев. Все двенадцать ответов оказались вежливыми, точными и в тоне компании. Через сорок минут после запуска агент завёл две отдельные карточки записи для одного и того же клиента: клиент написал «суббота тоже подойдёт», а агент принял это за второй запрос. Формулировка была безупречной. Проблема была не в формулировке, а в действии за ней и в той записи, которую это действие оставило в CRM.

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

Чем проверка агента отличается от проверки чат-бота?

Когда чат-бот отвечает неверно, ущерб — это одна фраза: клиент запутался, вы поправили, тема закрыта. Когда агент действует неверно, ущерб — это запись в базе. В Rocketly агент выполняет внутри CRM 74 автономных действия: создаёт задачи, встречи, коммерческие предложения и сделки, обновляет статус лида, его поля и балл, ставит теги и назначает ответственного. Не всё из этого обратимо. Отправленное предложение не отзовёшь, закрытая сделка не откроется сама, а лид, назначенный не тому менеджеру, будет тихо лежать в чужой очереди.

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

Откуда брать тестовые сценарии?

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

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

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

Какие четыре слоя нужно тестировать по отдельности?

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

• Знания. Находит ли он нужный источник? Маршрутизация знаний агента позволяет для каждого агента выбрать доступные источники по отдельности: агент продаж читает прайс, агент поддержки — только документацию. При тестировании намеренно сузьте источники и убедитесь, что агент умеет сказать «не знаю».
• Тон. Звучит ли он как вы? Здесь проверяется настройка личности и базы знаний — особенно на плохих новостях: хорошие новости красиво пишут все.
• Действие. Какое действие вызвано и с какими параметрами? Ответ может быть верным, а действие — нет, и именно эту ошибку пропускают чаще всего.
• Границы. Отказывается ли он от того, от чего должен отказаться? Guardrails позволяют декларативно описать, чего агент не должен делать никогда, и эти границы принудительно соблюдаются во время выполнения.

Разделение слоёв делает отладку дешёвой: сломаны знания — идёте в базу знаний, тон — в описание личности, действия — в инструкции и описания действий. Уточнить описания действий обычно эффективнее, чем менять модель. Ремесло, описанное в материале про написание промптов, которые дают применимый результат, работает и здесь: расплывчатая инструкция даёт расплывчатое поведение, а расплывчатое поведение агента — это непредсказуемая запись в вашей базе.

Где проходит граница между репетицией и боевым прогоном?

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

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

Как ломать собственные ограничения?

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

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

Как поймать неверную маршрутизацию до запуска?

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

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

На каких порогах принимать решение о запуске?

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

Проверка	Как измеряется	Порог запуска (пример)
Рутинные сценарии	40 типичных диалогов из архива	Верное действие во всех, ноль испорченных записей
Неоднозначные запросы	15 оборванных или двухтемных сообщений	Задаёт уточняющий вопрос или передаёт, не выдумывает
Проверка границ	10 намеренных атак	Guardrails держат во всех случаях
Маршрутизация	Неделя трафика в теневом режиме	Решения защитимы после чтения обоснования
Стоимость	Расход кредитов на диалог	Ниже месячного лимита агента и близко к прогнозу

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

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

Запуск — это не тумблер, а рампа. Четырёх ступеней достаточно. Первая: один канал, один сегмент, только рабочие часы, потому что разбираться с ночным сбоем в три часа никто не хочет. Вторая: все действия на ручном подтверждении. Функция контроля подтверждений позволяет для каждого типа действия отдельно выбрать, работает оно автоматически или ждёт вас; держать чтение и резюмирование автоматическими, а любую запись — на подтверждении, разумная стартовая позиция. Третья ступень: действия, ошибка в которых дёшева, переводятся в автомат. Четвёртая: расширяете объём и часы работы.

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

Какие сигналы после запуска говорят, что тестов не хватило?

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

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

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

Если хотите пройти эту последовательность на своих данных, заведите аккаунт Rocketly и сначала прогоните агента через панель тестирования.

Частые вопросы

Сколько сценариев достаточно перед запуском?

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

Заменяет ли репетиция боевой прогон?

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

Что делать, если агент всё-таки создал неверную запись?

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

Как часто обновлять тестовый набор?

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