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