Как проверить ИИ-бота перед запуском: сценарии, метрики и тестовые диалоги

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

Что именно нужно проверить перед запуском

У ИИ-бота нет одного состояния «работает» или «не работает». Он может правильно понимать вопрос, но брать устаревшую цену. Может находить нужный документ, но терять контекст после уточнения. Может хорошо вести чат и при этом не создавать заявку в CRM. Поэтому тестирование делят на несколько уровней: знания, диалог, действия, интеграции, безопасность и качество работы в выбранном канале.

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

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

Сначала собирают карту реальных обращений

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

Один и тот же вопрос включают в нескольких вариантах. Например, запрос о доставке может звучать как «когда привезут заказ», «где курьер», «успеете сегодня» или «заказ уже выехал?». Если бот отвечает только на формулировку из базы знаний, он не готов к реальному трафику.

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

Как составить тестовые сценарии

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

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

Минимальный набор включает обычные, пограничные и аварийные сценарии. Обычные проверяют основной поток. Пограничные — неполные данные, несколько заказов, противоречивые ответы. Аварийные — недоступную CRM, пустой ответ базы знаний, ошибку API и обрыв связи с оператором.

Какие диалоги обязательно прогнать

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

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

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

Важно: тестовый диалог должен проверять не красоту формулировки, а правильность решения. Бот может писать вежливо и при этом вести клиента по неверному сценарию.

Проверка базы знаний и RAG

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

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

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

Если ответа нет, надежный бот прямо сообщает об ограничении. Он не дополняет пробел правдоподобной выдумкой и не ссылается на источник, которого не видел.

Проверка интеграций и действий

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

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

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

Отдельный блок — отказ внешнего сервиса. При недоступной CRM бот не сообщает, что заявка создана. Он фиксирует ошибку, предлагает другой канал или передает обращение сотруднику.

Эскалация на сотрудника

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

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

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

Безопасность и защита данных

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

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

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

Метрики качества до запуска

Оценка «ответ выглядит нормально» слишком субъективна. Для тестового набора задают измеримые показатели. Они зависят от задачи бота, но всегда должны отражать результат для пользователя и бизнеса.

Метрики оценивают на одном и том же наборе сценариев. Иначе улучшение цифр может быть связано не с качеством бота, а с тем, что тест стал проще.

Когда ИИ-бот готов к ограниченному запуску

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

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

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

Чек-лист перед публикацией

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

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

Об авторе

Игорь М.

Chief Editor

Игорь М. — Chief Editor в компании Полигант, отвечает за редакционную стратегию и качество публикуемого контента. Работает в сфере цифровых финансов, блокчейн-технологий и ИИ более 6 лет.

В нашей компании курирует создание экспертных статей, глоссариев, обучающих материалов и обзоров. Обеспечивает соответствие контента как требованиям SEO, так и ожиданиям аудитории.