Подготовьте набор сценариев
Соберите типовые обращения и обезличьте их. Добавьте неполные данные, опечатки, противоречивые условия и вопросы за пределами задачи. Для каждого примера укажите вход, доступные сведения, ожидаемый результат и запрещённые действия. Такой набор становится основой для сравнения версий.
Разделите обычные и критические случаи. Обычный вопрос проверяет поиск и корректность ответа. Критический проверяет отказ при отсутствии прав, раскрытие чужих данных или попытку выполнить неподтверждённое изменение. Общая высокая оценка не должна скрывать серьёзную ошибку в одном из таких сценариев.
Проверяйте инструменты отдельно
До полного диалога протестируйте функции интеграции: допустимые параметры, пустой результат, отказ в доступе и технический сбой. Если инструмент неверно понимает идентификатор клиента, агентный тест только добавит неопределённость. Надёжнее сначала проверить точность программной части.
Для чтения сравнивайте возвращаемые поля с ожидаемыми. Для записи проверяйте состояние целевой системы после операции. В тестовой среде инструмент должен создавать нужную запись один раз и с правильными реквизитами. Ответ модели «готово» не заменяет проверку фактического изменения.
Оценивайте путь выполнения
В документации Google по оценке агентов разделяются итоговый ответ и траектория, то есть последовательность вызовов инструментов. Так проще обнаружить ситуацию, когда правильный текст получен через лишние или недопустимые действия. Для бизнеса такая проверка особенно важна при доступе к корпоративным данным.
Сохраняйте журнал операций: инструмент, параметры, результат, время и статус. Проверяйте обязательные условия и запрещённые действия. Допустимая последовательность может различаться: например, агент вправе уточнить вопрос.
Какие метрики использовать
Основной показатель это доля успешно завершённых задач по заранее определённому критерию. Дополнительно учитывайте корректность полей, обоснованность ответа источниками и передачу сотруднику. Для процесса записи важно отличать настоящий успех от черновика, который нельзя использовать без исправления.
Измеряйте задержку и расходы на успешное задание. Смотрите и среднее время, и медленные случаи. Отдельно считайте повторы, дубликаты и ошибки доступа. Целевые значения устанавливайте по требованиям процесса, а не переносите из чужого рейтинга или демонстрации поставщика.
Повторите неоднозначные задания
Один удачный запуск не доказывает устойчивость. Выполните сложные примеры несколько раз в сопоставимых условиях и фиксируйте результат каждой попытки. Сохраняйте версии модели, инструкции, инструментов и данных, иначе изменение поведения нельзя будет связать с конкретной причиной.
Проверяйте продолжение диалога: пользователь меняет дату, уточняет количество или отзывает запрос. Агент должен учитывать новое состояние, не повторяя старую операцию. Для памяти отдельно протестируйте изоляцию пользователей и корректное завершение предыдущей сессии.
Проверка ошибок и внешних инструкций
Добавьте недоступность CRM, тайм-аут и неполный ответ инструмента. Система должна различать отсутствие данных и техническую проблему. Повтор разрешённого чтения может быть безопасным, тогда как повтор создания записи требует проверки уже выполненного действия.
Поместите в тестовый документ попытку изменить правила, например требование отправить внутренние сведения на посторонний адрес. Агент должен использовать документ как источник данных, сохраняя ограничения инструментов. Такие проверки выявляют проблемы, которые не видны на обычных вопросах по справочнику.
Автоматическая и экспертная оценка
Формат полей, суммы и фактические изменения удобнее проверять программно. Полноту объяснения и понятность ответа может оценивать сотрудник по заданным критериям. Модель в роли оценщика помогает ускорить часть работы, но её оценки тоже нужно сравнивать с экспертной разметкой.
Не поручайте оценщику решать всё одним общим баллом. Разделите правильность, соответствие источнику, полноту и допустимость действий. Для критических операций нужен прямой контроль состояния системы и прав. Субъективная оценка вежливости не подтверждает корректность записи клиента.
Организуйте проверки перед обновлением
Каждое изменение модели, инструкции, источников или функций может вызвать регрессию. Повторяйте установленный набор сценариев перед выпуском и сохраняйте отчёт с различиями. Сначала применяйте новую версию на тестовой среде, затем на ограниченном потоке с возможностью возврата.
Полезно дополнять набор примерами из эксплуатации. Если сотрудник обнаружил ошибку, воспроизведите её и добавьте проверку, которая поможет заметить повтор. Так тестирование ai агентов становится постоянной частью поддержки, а не одноразовой демонстрацией перед запуском.
Когда решение готово к работе
Готовность определяется выполнением согласованных критериев, отсутствием выявленных критических нарушений и понятным процессом передачи человеку. Даже после приёмки нужны наблюдение и ответственный за изменения. Расширяйте поток и полномочия только после проверки предыдущего этапа.
Дальше по теме: надзор за качеством и проверка новых версий модели после запуска. ИИ-сервисы→
