Как встроить модель решений в маршрутизацию заявок: гайд без автопилота

Модель, которая выбирает категорию заявки, кажется простой автоматизацией. На практике она быстро становится источником скрытых ошибок: письмо уходит не тому человеку, срочный случай теряется в общей очереди, а оператор уже не понимает, почему был выбран маршрут. Этот гайд строит процесс так, чтобы ИИ оставался помощником для повторяемого решения, а не безымянным автопилотом.

Шаг 1. Сузьте задачу до одного решения

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

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

Шаг 2. Сделайте эталон до подключения модели

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

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

Шаг 3. Описывайте решение как данные

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

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

Шаг 4. Подберите порог на реальной очереди

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

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

Шаг 5. Заранее спроектируйте отказ

У сервиса может закончиться лимит, модель может вернуть невалидный объект, а вход — оказаться слишком длинным. Во всех трёх случаях заявка должна попасть в обычную очередь с понятной пометкой, а не исчезнуть в техническом логе. Не повторяйте запрос бесконечно: задайте число попыток, тайм-аут и владельца оповещения. Проверьте это специально, отключив тестовый ключ или подав некорректное поле.

Отдельно ограничьте действия агента. Если классификатор связан с инструментами, список команд и адресатов должен быть белым, а любое необратимое действие — требовать подтверждения. Это продолжение проверки границ агента, а не необязательная «безопасность на потом».

Шаг 6. Решите, выпускать ли пилот

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

FAQ

Сколько классов брать в первом запуске? Три-пять плюс «не знаю» обычно лучше десятка похожих вариантов. Нужна ли уверенность? Да, но она имеет смысл лишь после калибровки на вашей очереди. Можно ли обучаться на правках операторов? Можно, если есть правовое основание и разметка проверяется; не загружайте всё подряд. Когда разрешить автоматическую передачу? Когда ошибка обратима, маршрут ограничен и журнал позволяет её обнаружить. Нужна ли ручная проверка всегда? Нет, но она должна оставаться доступной по порогу и при любом техническом сбое.

Иллюстрация редакции: схема принятия решения с подтверждением; это не снимок рабочего продукта.