Чтобы проверить маршрутизацию заявок нейросетью, заранее назначьте правильный отдел каждому письму из контрольного набора. Затем сравните этот эталон с выбором модели и отдельно разберите ошибки между отделами. Метка «оплата» ещё не определяет ответственного: вопрос о цене нового заказа и двойное списание требуют разных исполнителей.
Первую проверку проводите без реального переназначения заявок. Ниже описан порядок приёмки, а не испытание работающей интеграции. Все письма и числа в примере вымышлены.
Сначала решите, кто принимает заявку
Составьте таблицу ответственности вместе с руководителями отделов. У каждой ситуации должен быть первый получатель и правило для спорного случая. Нейросеть не может разрешить организационную неопределённость, которую сотрудники ещё не согласовали.
Для условной компании таблица может выглядеть так:
| Ситуация в письме | Первый получатель | Граница ответственности |
|---|---|---|
| Новый заказ, расчёт цены, запрос предложения | Продажи | Даже если клиент спрашивает о способе оплаты будущего заказа |
| Ошибочное списание по оформленному заказу, документы об оплате | Расчёты | Наличие слова «счёт» без контекста недостаточно |
| Не работает полученный товар или доступ к уже купленной услуге | Поддержка | Вопрос о покупке ещё одной услуги остаётся у продаж |
| Несколько самостоятельных вопросов или не хватает сведений | Ручной разбор | Сотрудник выбирает первого получателя по согласованному правилу |
Это учебное разделение. В вашей компании оплатой может заниматься поддержка, а документы выдавать менеджер. Подставьте реальные роли и названия очередей. За ручной разбор также назначьте ответственного: «прочее» без исполнителя оставляет обращение без движения.
Отдельно договоритесь, что делать со смешанным письмом. Для первого запуска можно направлять его человеку целиком. Если позже захотите разделять его на несколько задач, потребуется отдельная проверка: все вопросы должны сохраниться, а ответы разных отделов не должны противоречить друг другу.
Если из формы уже приходит достоверный код отдела и его достаточно для назначения, используйте обычное правило. Нейросеть имеет смысл проверять там, где маршрут зависит от смысла свободного текста.
Подготовьте эталон до ответа модели
Возьмите разрешённую копию обращений, для начала такую, которую сможете проверить полностью. Состав передаваемых данных согласуйте по правилам использования ИИ в компании. Для учебной проверки подойдут вымышленные письма; они не заменяют проверку на характерных рабочих формулировках.
По каждому письму сохраните номер, текст и ожидаемого первого получателя. Если проверяющие не согласны, сначала уточните таблицу ответственности. Такие строки не стоит выдавать за однозначный эталон.
Добавьте не только очевидные заявки, но и пары с похожими словами и разными маршрутами:
- «Пришлите счёт на новую поставку» и «В счёте по оплаченному заказу неверные реквизиты»;
- «Не могу выбрать тариф для покупки» и «Купленный тариф не включился»;
- письмо с двумя вопросами к разным отделам;
- короткое «Помогите разобраться» без описания ситуации;
- ответ в длинной переписке, где новое требование отличается от старой темы.
Сохраните часть писем отдельно от примеров, на которых настраиваете задание модели. Иначе вы проверите, насколько хорошо настройка подогнана под уже известные случаи. После изменения правил повторяйте весь контрольный набор. Документация n8n о проверке ИИ-сценариев описывает сравнение выходов с контрольными примерами, в том числе после изменений модели или задания.
Задание исполнителю интеграции можно сформулировать так:
Проверяем выбор первого отдела по утверждённой таблице ответственности.
Верните для каждого номера письма предложенную очередь
и краткое основание из текста.
Не назначайте сотрудника и не меняйте заявку в рабочей системе.
Смешанные и недостаточно понятные письма направляйте на ручной разбор.
Допустимы только очереди из переданного списка.
Сохраните результаты и ошибки обработки по всем входным номерам.Эта инструкция задаёт ожидаемое поведение. Технический запрет на запись в рабочую систему настройте отдельно: текст поручения не ограничивает права подключения.
Смотрите, какие отделы нейросеть путает
Общий процент совпадений может скрывать опасное направление ошибки. Поэтому разложите результаты по двум осям: кто должен был получить заявку и кого предложила модель.
Ниже намеренно составленная таблица ошибок для 12 вымышленных писем. Это иллюстрация подсчёта, не результат вызова нейросети и не оценка какого-либо сервиса. Каждая строка означает ожидаемого получателя, каждый столбец означает предложенного.
| Должно быть → предложено | Продажи | Расчёты | Поддержка | Ручной разбор | Всего |
|---|---|---|---|---|---|
| Продажи | 3 | 1 | 0 | 0 | 4 |
| Расчёты | 0 | 2 | 1 | 0 | 3 |
| Поддержка | 0 | 0 | 3 | 0 | 3 |
| Ручной разбор | 1 | 0 | 0 | 1 | 2 |
| Всего | 4 | 3 | 4 | 1 | 12 |
На пересечении одинаковых очередей стоят совпадения: 3 + 2 + 3 + 1 = 9. Итого 9 из 12, или 75%. Остальные три письма ушли не туда: одно из продаж в расчёты, одно из расчётов в поддержку и одно спорное письмо в продажи.
Последняя ошибка особенно важна для этого примера: модель выбрала отдел там, где по правилам должен был решить человек. При этом все три письма поддержки направлены верно. Одно общее число не показывает эту разницу.
Для собственного набора посчитайте и зафиксируйте:
- Сколько писем каждого ожидаемого маршрута пришло на вход.
- Сколько предложений совпало с эталоном.
- Между какими конкретно очередями произошли ошибки.
- Сколько спорных писем модель направила в отдел без ручного решения.
- Сколько понятных писем излишне отправлено на ручной разбор.
Последние два случая имеют разные последствия: неверное назначение и дополнительная работа человека. Допустимые границы согласуйте с владельцем процесса до испытания. Универсального проходного процента здесь нет. В маленьком учебном наборе 75% не служат основанием подключать реальные заявки.
Проверьте настройки веток и ошибки обработки
Попросите исполнителя показать, какой участок выбирает категорию, а какой назначает отдел. Проверьте соответствие кодов: даже правильное решение модели может попасть в чужую очередь из-за неверного соединения веток.
Например, в Text Classifier n8n категории имеют название и описание. Настройка Allow Multiple Classes To Be True разрешает несколько категорий. Для схемы с одним первым получателем проверьте режим и поведение на смешанном письме. Отключение нескольких категорий само по себе не учит модель направлять спорное письмо человеку.
Есть и отдельная развилка для отсутствия подходящей категории: When No Clear Match. По документации, вариант Discard Item по умолчанию отбрасывает запись; Output on Extra, 'Other' Branch выдаёт её в отдельную ветку Other. Для приёмки маршрутизации проверьте, что эта ветка подключена к наблюдаемому ручному разбору. Неопределённость по смыслу и техническая ошибка обработки должны оставлять отдельные видимые статусы.
На копии сценария проверьте неподходящую категорию, неизвестный код очереди, пустой ответ и недоступность модели. Для каждого входного номера должно быть видно одно из состояний: предложен маршрут, нужен ручной разбор, обработка завершилась ошибкой. Сверяйте этот список с входным набором, чтобы найти исчезнувшие письма.
В n8n для сбоев выполнения есть отдельный сценарий обработки ошибок. Его наличие не доказывает, что он поймает неверный смысловой выбор или запись, которую классификатор штатно отбросил. Эти случаи проверьте отдельно по результатам прохождения веток.
Выбранная очередь ещё не означает, что заявку действительно приняли. Доставку, историю и ожидание ответа проверяйте отдельным этапом по инструкции о передаче клиента оператору.
Что принять перед включением назначения
Сохраните таблицу ответственности, контрольные письма с эталоном, версию задания и модели, фактические ответы, таблицу ошибок и решение руководителя по каждому незакрытому случаю. Попросите отдельно показать, как ветки соответствуют реальным очередям.
Начните с режима, в котором модель лишь предлагает отдел, а сотрудник подтверждает назначение. Ошибочные и спорные письма добавляйте в контрольный набор. После изменения названий отделов, правил, модели или задания повторяйте проверку и сравнивайте конкретные направления ошибок.
Если нужна сводка частых проблем за месяц, это другая задача: для неё есть разбор анализа архива обращений. Здесь результат приёмки конкретнее: вы знаете, какие письма система направляет правильно, где путает получателей и что остаётся человеку.