Приёмочный тест, который нужен каждому бизнес-агенту, проверяет не качество формулировок, а состояние рабочего процесса после действия. В тесте должны быть исходная запись, разрешённое изменение, наблюдаемый результат, независимый проверяющий и ожидаемое поведение при нехватке данных. Он обязан отклонить убедительный, но неправильный ответ. Поэтому его составляют до запуска и прогоняют на обычных, ошибочных и намеренно опасных примерах.
Опишите переход из одного состояния в другое
Возьмём агента, который обрабатывает входящие обращения с сайта и готовит карточки лидов. Он читает сообщение, выделяет компанию и задачу, выбирает направление, создаёт запись и назначает ответственного. Красивое резюме обращения не является целью. Нужна карточка, связанная с правильным отправителем, содержащая только сведения из сообщения и переданная в подходящую очередь без самостоятельного обещания клиенту.
Сформулируйте состояние до запуска: обращение получено, но ещё не разобрано и не назначено. Затем состояние после успешного запуска: исходное сообщение сохранено, контакты не перепутаны, категория обоснована, ответственный выбран по действующему правилу, а сомнительные сведения помечены. Три теста перед внедрением ИИ помогают проверить, существует ли у процесса владелец и достаточно ли качественны входные данные.
Отдельно назовите исполнителя и контролёра. Агент может подготовить карточку. Проверяющий читает исходное обращение и запись в рабочей системе напрямую. Руководитель продаж принимает спорную маршрутизацию. Если эти роли смешать, никто не сможет объяснить, почему неверно назначенный лид прошёл приёмку.
Добавьте случаи, на которых система должна остановиться
Обычного обращения недостаточно для выпуска. В набор нужны сообщение без контакта, одинаковые названия разных компаний, запрос сразу по нескольким услугам, устаревшее правило маршрутизации, повторное обращение и текст с обещанием, которое сотрудник не подтверждал. В некоторых случаях правильным результатом будет не карточка, а остановка с понятной причиной и передачей человеку.
- Проверка личности: контакт и компания связаны с тем же исходным сообщением.
- Проверка фактов: в карточке нет сведений, которых не было во входных данных.
- Проверка маршрута: выбранное направление соответствует действующему правилу.
- Проверка запрета: агент не отправляет обещания и не меняет условия сделки.
- Проверка восстановления: частичный сбой не создаёт дубликат и не теряет обращение.
Материал о снижении риска уверенных ошибок ИИ полезен для подготовки таких примеров. Он напоминает, что правдоподобный ответ опасен именно тогда, когда его принимают без исходного доказательства. Поэтому тест должен включать не только ожидаемые ответы, но и обязательные отказы.
Сделайте вердикт понятным для повторной проверки
Для каждого примера сохраните исходное обращение, предложенную карточку, состояние системы, вердикт и категорию сбоя. При положительном результате укажите, какие условия выполнены. При отказе зафиксируйте нарушенное условие и следующего ответственного. Общая оценка не должна скрывать разные риски: правильная категория не компенсирует выдуманный контакт.
Проверяющий может сочетать правила и ручной разбор. Сверку контактов, обязательных полей и дубликатов удобно делать автоматически. Необычную формулировку запроса может оценить руководитель. Перед запуском полезно задать три вопроса перед покупкой ИИ, чтобы привязать тест к результату, а не к возможностям модели.
Условие выпуска формулируется через рабочий процесс. Все обязательные поля подтверждены, запрещённые действия заблокированы, спорные случаи дошли до ответственного, а сбой оставил обращение в безопасном состоянии. Если проверка не видит рабочую систему после действия, она не может принять результат. Сначала добавьте наблюдаемость, затем расширяйте самостоятельность.
Набор не выбрасывают после запуска. Его повторяют при смене модели, подсказки, интеграции, правил маршрутизации и структуры карточки. Каждый существенный сбой становится новым примером. Так тест остаётся договором между бизнесом и разработкой, а не одноразовой демонстрацией.
Названия тестовых примеров должны быть понятны владельцу процесса без технического перевода. Вместо общей метки ошибка модели укажите, что произошло: перепутан отправитель, добавлен неподтверждённый телефон, потеряно исходное сообщение или выбран закрытый маршрут. Тогда руководитель может оценить риск и решить, нужен ли новый источник, правило, запрет или ручная проверка. Такая классификация делает исправления адресными.
Перед очередным выпуском сравните не только итоговый вердикт, но и полученные доказательства. Агент мог случайно пройти старый тест после изменения структуры системы, если проверка читает уже не то поле. Независимый просмотр пары примеров подтверждает, что тест действительно наблюдает нужное состояние и не превратился в формальную зелёную отметку.
Частые вопросы
Он проверяет наблюдаемое состояние рабочего процесса после действия, а не убедительность текста или длину отчёта.
Они доказывают, что нехватка прав, конфликт сведений и опасный запрос останавливаются до изменения системы.
Для каждой категории сбоя назначают владельца, который исправляет данные, правило, интеграцию или границу прав.
После изменения модели, подсказки, интеграции, политики, прав, структуры рабочей системы или известного сценария сбоя.
Если требуется спроектировать агента вместе с таким договором, обсудите внедрение ИИ с MYOD.IT. Точная посадочная используется только как CTA. Готовность подтверждают независимая проверка, наблюдаемый результат и безопасный маршрут отказа.
