Как протестировать AI-чат-бота перед запуском: вопросы, метрики и ошибки

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

Определите границы ответственности

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

Что сделать. Составьте список поддерживаемых задач, запрещённых действий, источников истины и каналов эскалации.

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

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

Основные определения и границы вынесены в материал Чат-бот поддержки клиентов; здесь достаточно применить их к текущему шагу.

Соберите реальные вопросы

Лучшие тесты берутся из писем, чатов, звонков и поисковых формулировок клиентов, а не придумываются редактором в идеальном литературном виде.

Что сделать. Обезличьте историю обращений, сгруппируйте задачи и отберите частые, дорогие и рискованные случаи.

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

Типичная ошибка. Не обучайте и не проверяйте систему на одном и том же списке без отдельной контрольной части.

Разделите набор на корзины

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

Что сделать. Создайте корзины: FAQ, подбор, возражения, действия, вне области, многоходовые диалоги, безопасность и передача оператору.

Как проверить. Для каждой корзины задайте отдельный минимальный pass rate и вес бизнес-риска.

Типичная ошибка. Не смешивайте безобидную стилистическую неточность с выдуманной ценой или ошибочным действием.

Перед настройкой этого этапа полезно свериться со статьёй Клиентская аналитика.

Запишите эталон и критерии

У генеративного ответа может быть несколько хороших формулировок, поэтому точное совпадение текста редко подходит.

Что сделать. Для кейса укажите обязательные факты, допустимые варианты, запрещённые утверждения, нужный источник и ожидаемое действие. Разделите обязательный минимум и улучшения.

Как проверить. Два проверяющих должны прийти к близкому вердикту по одной рубрике.

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

Проверьте знания и ссылки

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

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

Как проверить. Сверяйте утверждение с конкретным фрагментом базы и отдельно считайте ответы без достаточного основания.

Типичная ошибка. Не разрешайте модели заполнять пробел правдоподобной догадкой.

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

Проверьте контекст диалога

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

Что сделать. Соберите сценарии из пяти–десяти реплик с уточнением, исправлением, паузой и сменой намерения.

Как проверить. Проверьте, какие факты бот должен помнить, какие обязан переспросить и когда контекст следует сбросить.

Типичная ошибка. Не переносите данные одного клиента в новый диалог и не держите контекст дольше заявленного срока.

Испытайте отказ и эскалацию

Качественный бот умеет сказать, что данных недостаточно, и передать разговор оператору вместе с полезным контекстом.

Что сделать. Добавьте неизвестные вопросы, исключения из правил, конфликтные ситуации и просьбы выполнить запрещённое действие.

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

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

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

Проведите проверку безопасности

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

Что сделать. Добавьте прямые и косвенные prompt injection, запросы секретов, подмену роли, вредоносные ссылки и необычные форматы.

Как проверить. Проверяйте не только текст ответа, но и фактические вызовы инструментов, доступ к данным и журнал действий.

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

Связанная задача раскрыта в статье Prompt injection.

Измерьте качество и задержку

Полезный отчёт сочетает корректность, основанность на источнике, выполнение задачи, эскалацию, скорость и стоимость.

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

Как проверить. Сравнивайте версии на одном замороженном наборе и отдельно смотрите новые ошибки.

Типичная ошибка. Не улучшайте среднюю оценку ценой ухудшения критических сценариев. Не измеряйте только скорость первого шага.

Поставьте регрессию в выпуск

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

Что сделать. Храните версию модели, промпта, базы, инструментов и набора; блокируйте выпуск при падении критического порога.

Как проверить. Отчёт должен показывать различия между текущей и предыдущей версиями по каждому кейсу.

Типичная ошибка. Не перезаписывайте golden set после неудачного прогона только для того, чтобы новая версия прошла тест.

Соберите контрольный набор, который можно повторить

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

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

Оценивайте ответ по отдельным критериям

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

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

Проведите регрессию по изменившейся части

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

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

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

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

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

Следите за качеством после запуска

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

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

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

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

Чек-лист выпуска AI-чат-бота

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