Как тестировать ИИ-агента до запуска на клиентах

Сначала договоритесь, что считается ошибкой

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

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

Как собрать выборку, которая похожа на жизнь

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

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

Проверьте четыре слоя отдельно

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

Как считать результат без самообмана

Учитывайте долю корректных завершений, долю опасных ошибок, частоту передачи человеку и время ручного исправления. Метрику опасных ошибок смотрите отдельно: средняя точность 95% может быть неприемлемой, если оставшиеся 5% — неправильные цены или утечка данных. Порог качества определяет владелец процесса до просмотра результатов пилота.

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

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

Что сделать при провале теста

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

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

Пример записи одного тестового случая

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

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

Кто должен принимать результаты

Технический специалист проверяет интеграцию и логи; владелец процесса — соответствие бизнес-правилам; сотрудник, который потом будет пользоваться результатом, — достаточность контекста. Одного одобрения на красивом демо недостаточно. Зафиксируйте, кто вправе принять оставшийся риск и на каких условиях.

Матрица ошибок для руководителя

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

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

Тестируйте цепочку, а не только текст модели

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

Особенно важны отказы: CRM не отвечает, сеть прервалась после записи, одно событие пришло дважды, сотрудник отменил действие. У каждого отказа должен быть ожидаемый результат — очередь, повтор без дубля или сигнал человеку. Эти случаи редко встречаются на демо, но регулярно появляются в эксплуатации.

Как организовать повторные проверки

Храните проверенный набор случаев отдельно от текущих примеров разработки. Когда меняете инструкцию или модель, запускайте оба: набор известных ошибок и независимую контрольную выборку. Сравнивайте не только итоговую долю правильных ответов, но и распределение по категориям. Улучшение на обычных случаях не оправдывает ухудшение в рискованных.

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

Чек-лист перед включением реальных клиентов

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

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