ИИ-чат-бот может отвечать гладко и при этом придумывать условия, ссылаться не на тот документ или выполнять действие без разрешения. Поэтому перед запуском недостаточно провести несколько приятных диалогов. Нужна проверка, которая связывает каждый ответ с рабочей задачей, источником и допустимым действием.
Решение о запуске принимает владелец процесса или назначенный им ответственный. Он заранее определяет, какие ошибки недопустимы, какие можно исправить после ограниченного запуска и в каких случаях бот обязан передать вопрос человеку.
Что считать правильным ответом
Правильный ответ помогает пользователю решить конкретный вопрос, опирается на разрешённый источник и не выходит за установленные границы. Эти три условия нужно проверять отдельно.
Допустим, клиент спрашивает о сроке выполнения работы. В базе нет утверждённого срока. Бот отвечает: «Обычно это занимает три дня». Формулировка звучит полезно, но факт выдуман. Правильным действием будет сообщить, что срок не указан, запросить недостающие сведения или передать вопрос сотруднику.
Для части запросов правильный результат — не готовый ответ:
- если не хватает данных, бот задаёт уточняющий вопрос;
- если источники противоречат друг другу, сообщает о расхождении и обращается к ответственному;
- если пользователь просит закрытый документ, бот отказывает;
- если решение требует полномочий сотрудника, бот передаёт запрос человеку;
- если подтверждённого ответа нет, бот прямо говорит об этом.
Стиль, скорость и дружелюбие тоже можно оценивать, но они не заменяют фактическую проверку. Вежливый выдуманный ответ остаётся ошибкой.
Важно учитывать тип решения. Чат-бот ведёт диалог с пользователем. Обычная интеграция передаёт данные по заданному маршруту. ИИ-агент выбирает следующий шаг и разрешённые инструменты в зависимости от запроса. Чем больше у системы вариантов действий, тем больше сценариев и границ придётся проверить.
Как собрать проверочный набор
Начните не с придумывания каверзных вопросов, а с реального процесса. Соберите обезличенные обращения, которые уже получают сотрудники, и добавьте ситуации, где ошибка может повлиять на клиента, данные или дальнейшее действие.
В набор стоит включить семь типов примеров:
- Обычный вопрос с прямым ответом в разрешённом источнике.
- Тот же вопрос в другой формулировке, с опечаткой или разговорными словами.
- Неполный запрос, для которого нужно уточнение.
- Вопрос, по которому источники расходятся.
- Запрос факта, которого нет в базе.
- Попытку получить закрытый документ или выполнить запрещённое действие.
- Прямую просьбу связать пользователя с человеком.
Размер набора зависит от числа сценариев и последствий ошибки. Десять похожих вопросов не проверят процесс лучше, чем несколько разных ситуаций с заранее описанным ожидаемым поведением. Универсального достаточного количества нет.
Разделите примеры на две части. Первую используйте во время настройки. Вторую сохраните для приёмки, чтобы проверить новые формулировки, которые система не встречала при подготовке. Если все проверочные вопросы участвовали в настройке, хороший результат ещё не показывает, как бот поведёт себя с новым запросом.
Удалите из примеров имена, телефоны, реквизиты и сведения, которые не нужны для проверки. Если доступ к материалу зависит от роли пользователя, сохраните эту роль как условие сценария: один и тот же ответ может быть допустим сотруднику и запрещён внешнему клиенту.
Как подготовить эталон ответа
Эталон — не текст, который бот обязан повторить слово в слово. Это описание существенных фактов, разрешённых источников и допустимого действия. Разные формулировки могут быть правильными, если они сохраняют смысл и границы.
Для каждого примера заполните карточку:
| Поле | Что записать |
|---|---|
| Вопрос | Исходную формулировку пользователя и важный контекст |
| Источник | Документ, раздел и версию, на которых должен основываться ответ |
| Существенные факты | Что ответ обязан сообщить без искажения |
| Допустимое действие | Ответить, уточнить, отказать или передать человеку |
| Недопустимый вывод | Что бот не должен обещать, раскрывать или делать |
| Ответственный | Кто знает правило процесса и оценивает результат |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Версия источника важна: иначе после обновления базы невозможно понять, ошибся бот или изменилось правило. Если документы противоречат друг другу, сначала владелец процесса определяет действующее правило. Спор экспертов об эталоне нельзя автоматически записывать в ошибку модели.
Не включайте в эталон требования, которых нет в рабочем процессе. Если сотрудник сам не может определить правильный ответ, чат-боту тоже нельзя приписывать обязанность его угадать.
Учебная проверка на трёх вопросах
Условная таблица, не результаты запущенного бота. В учебной базе указано: поддержка работает по будням; время ответа не обещано; индивидуальную скидку согласует менеджер.
| Вопрос | Допустимое | Ошибка |
|---|---|---|
| Ответите в воскресенье? | Указать рабочие дни, не обещать ответ в выходной | Обещать круглосуточного оператора |
| Через сколько решите вопрос? | Сказать, что срок не указан, предложить уточнение | Придумать срок |
| Дайте скидку | Передать менеджеру | Самостоятельно согласовать |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
В первом примере ответ «Да, постараемся помочь как можно быстрее» звучит приветливо, но обещает действие вне установленного графика. Во втором правильный отказ от выдуманного срока полезнее уверенного числа. В третьем бот может собрать данные для менеджера, но не получает право менять коммерческие условия.
Эти три примера показывают способ оценки, а не точность какой-либо системы. По ним нельзя вычислить процент качества или сделать вывод о готовности реального бота.
Как вести журнал проверки
Одной отметки «пройдено» недостаточно. Она не объясняет причину ошибки и не помогает повторить проверку после исправления. Для каждого запуска сохраняйте цепочку:
- Вопрос и условия сценария.
- Фактический ответ или действие бота.
- Источник и эталон, с которыми сравнивали результат.
- Найденное расхождение и его тип.
- Что изменили в документах, правилах или настройке.
- Результат повторной проверки.
Если бот ответил правильно, журнал также должен показывать основание оценки. Иначе при следующем обновлении будет трудно отличить подтверждённый результат от субъективного впечатления проверяющего.
После исправления повторите не только проваленный пример. Проверьте близкие вопросы и несколько контрольных сценариев: изменение одного правила может улучшить нужный ответ и одновременно испортить другой.
Как классифицировать ошибки
Разделяйте ошибки по природе. Это помогает направить исправление тому, кто отвечает за конкретную часть процесса.
| Тип ошибки | Как выглядит |
|---|---|
| Неверный факт | Бот сообщает условие, которого нет в действующем материале |
| Неверный источник | Ответ основан на устаревшем или запрещённом документе |
| Нарушение доступа | Пользователь получает сведения, недоступные его роли |
| Потеря контекста | Бот забывает важное уточнение из предыдущих сообщений |
| Неправильное действие | Вместо передачи менеджеру бот сам обещает скидку или меняет запись |
| Неудачная формулировка | Факты верны, но ответ двусмыслен или не объясняет следующий шаг |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Критичность определяют последствия в конкретном процессе. Раскрытие закрытого документа, ложное обещание клиенту и неудачный порядок слов требуют разной реакции. Опасную ошибку нельзя компенсировать высоким средним баллом по простым вопросам.
Заранее запишите условия остановки. Например: бот не выходит к пользователям, пока раскрывает закрытые сведения, придумывает коммерческие условия или сообщает об успешном действии после сбоя системы. Для менее серьёзных отклонений можно назначить другой порядок исправления, но его тоже утверждает ответственный.
Не ищите универсальный процент, после которого продукт автоматически готов. Среднее значение скрывает состав ошибок: два набора с одинаковой долей правильных ответов могут нести разный риск.
Как принять решение о запуске
До проверки зафиксируйте четыре вещи: обязательные сценарии, ответственных, недопустимые ошибки и правило повторной проверки. После этого решение о запуске можно связать с наблюдаемыми результатами, а не с общим впечатлением от демонстрации.
Бота можно передавать к следующему этапу запуска, когда согласованные сценарии пройдены, серьёзные ошибки закрыты, спорные вопросы уходят человеку, а команда понимает границы системы. Ограничения нужно сообщить тем, кто будет пользоваться ботом и поддерживать его.
Успешная выборка не гарантирует правильный ответ на любой будущий вопрос. Она подтверждает только поведение на согласованных примерах и близких условиях. После изменения базы знаний, полномочий, модели или правил процесса повторите затронутые сценарии и контрольную часть набора.
Статистику реальных диалогов, обращения пользователей и эксплуатационные сбои оценивают уже после запуска. Они дополняют приёмку, но не отменяют проверку по источникам и недопустимым действиям.
Что подготовить для обсуждения проекта
Для первой оценки соберите описание роли бота, несколько обезличенных вопросов, перечень источников и примеры решений, которые должен принимать человек. Этого достаточно, чтобы обсудить границы сценария и будущую приёмку без передачи паролей и рабочих секретов.
Switch On AI разрабатывает чат-ботов под правила конкретного процесса. Вместе можно определить вопросы, источники, правила отказа и критерии, по которым вы примете помощника до запуска. Если готового конструктора или функции вашей системы достаточно, это также стоит проверить до заказной разработки.
Чтобы разобрать свой процесс, опишите задачу и канал общения: кто задаёт вопросы, где лежат утверждённые ответы и какие решения бот не должен принимать самостоятельно.
Вопросы по этой задаче
Сколько вопросов достаточно для проверки ИИ-чат-бота?
Универсального количества нет. Набор должен покрывать рабочие сценарии и существенные риски: обычные и перефразированные вопросы, неполные данные, неизвестные факты, конфликт источников, ограничения доступа и передачу человеку.
Можно ли поручить оценку ответов другой модели ИИ?
Модель может помочь сравнить формулировки или предварительно разметить большой набор, но не заменяет ответственного за факты и правила процесса. Человек утверждает источники, допустимые действия и критичность ошибок.
Что должен делать бот, если ответа нет в базе?
Допустимое поведение — сообщить, что подтверждённого ответа нет, запросить нужные сведения или передать вопрос человеку. Уверенная догадка не считается полезным ответом.
Когда нужно повторять проверку?
Затронутые и контрольные примеры повторяют после исправлений, а также после изменения базы знаний, полномочий, модели или правил процесса.