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