Классификация обращений нейросетью: срочность и отдел в 2026
Классификация обращений превращает поток сообщений в понятную очередь: категория, срочность, отдел и уверенность результата.
Когда в общую почту, чат или форму поддержки поступают десятки сообщений, менеджер сначала читает их, определяет тему, ищет признаки риска, выбирает отдел и только после этого начинает работу. На одно обращение может уйти 2–5 минут, а при потоке в 120 сообщений за смену первичный просмотр занимает от 4 до 10 часов. Нейросеть переносит эту сортировку на первый этап, но качество зависит от правил, примеров и проверки спорных случаев.
Для такой задачи я разделяю процесс на две части. Сначала система извлекает признаки из текста, затем применяет политику маршрутизации. Подробно о выборе задач для нейросетей я писал в материале «Нейросеть для генерации текста: задачи и проверка результата», потому что классификация требует такой же проверки, как подготовка черновика.
Что именно делает нейросеть с обращением
Нейросеть может обработать одно сообщение по 4 полям: теме, срочности, ответственному отделу и уверенности классификации. Эти поля превращают свободный текст в запись, с которой уже можно работать по регламенту.
Пример входного сообщения:
«Не получается оплатить счёт, платёж списался дважды, договор заканчивается 18 сентября».
Из него нужно извлечь несколько признаков:
- категория: оплата или биллинг;
- срочность: высокая, потому что указано повторное списание;
- отдел: финансовая поддержка;
- срок: 18 сентября;
- уверенность: число от 0 до 1, например 0,91.
Последнее поле нужно для контроля. Значение 0,91 можно трактовать как уверенную классификацию при заранее заданном пороге. Значение 0,54 означает, что сообщение лучше отправить на дополнительную проверку. Само число не доказывает правильность ответа, оно лишь показывает степень уверенности модели в выбранной метке.
Я советую фиксировать результат в структурированном виде, даже если исходные обращения приходят обычным текстом:
{
"category": "оплата",
"priority": "высокая",
"department": "финансовая поддержка",
"deadline": "18 сентября",
"confidence": 0.91
}
Такой формат упрощает фильтрацию. Например, правило может выбирать все записи с полем priority равным «высокая», а затем передавать их ответственному сотруднику. Для этого не требуется заставлять модель принимать решение о компенсации, возврате средств или нарушении договора. Она сортирует и объясняет признаки, а окончательное действие остаётся за человеком.
Как определить срочность обращения
Срочность лучше задавать через 3 уровня и измеримые признаки, а не через общее впечатление от текста. На практике я использую уровни «высокая», «обычная» и «низкая», после чего связываю их со сроком реакции.
К высокой срочности относятся признаки остановки процесса, финансового риска, угрозы безопасности или жёсткого срока. Формулировки «сервис недоступен 40 минут», «деньги списались дважды» и «отгрузка остановлена до 16:00» дают модели конкретные сигналы. Слово «срочно» само по себе слабее: его можно написать в теме любого письма, даже если вопрос спокойно ждёт 2 рабочих дня.
Обычная срочность подходит для запроса настройки, консультации или уточнения статуса. Низкая срочность характерна для предложений, отзывов, справочных вопросов и просьб, где нет ограничения по времени.
Готовую шкалу лучше описать таблицей.
| Уровень | Признаки в тексте | Рекомендуемый срок реакции | Действие при сомнении |
|---|---|---|---|
| Высокая | остановка услуги, повторное списание, риск пропуска срока | до 15 минут | передать дежурному сотруднику |
| Обычная | настройка, консультация, вопрос о статусе | до 4 часов | направить в профильный отдел |
| Низкая | отзыв, предложение, справочный запрос | до 1 рабочего дня | поставить в стандартную очередь |
Сроки в таблице являются примером политики, их нужно согласовать с вашим SLA. Для финансовых, медицинских и производственных процессов критерии должны пройти проверку специалиста. Нейросеть не должна самостоятельно расширять понятие аварии, просрочки или угрозы.
Полезные приёмы формулировки запросов для этой задачи разобраны в статье «Искусство промптинга: как правильно формулировать запросы для нейросетей». Там же удобно сверить структуру инструкции: цель, формат ответа, ограничения и примеры.
Как построить категории и отделы
Рабочая таксономия обычно начинается с 5–8 категорий, иначе похожие обращения начинают конкурировать между метками. Названия должны описывать предмет запроса, а отделы, куда попадает сообщение, задаются отдельно.
Модельный вариант для сервиса с оплатой и доставкой:
- оплата;
- техническая проблема;
- доставка;
- возврат;
- общий вопрос.
К каждой категории полезно добавить границы. Для метки «оплата» подходят вопросы о счёте, списании, реквизитах и закрывающих документах. Ошибка входа относится к технической проблеме, даже если пользователь пишет «не могу оплатить», потому что причина находится на этапе авторизации.
Один отдел может принимать несколько категорий. Финансовая команда обрабатывает оплату и возврат, техническая команда получает ошибки доступа и сбои, логистика отвечает за доставку. Поэтому сначала определяется смысл сообщения, затем выбирается маршрут. Если сразу смешать эти уровни, появятся правила вроде «всё про заказ отправлять в логистику», хотя вопрос о возврате относится к финансам.
Категорий не должно быть больше, чем команда способна поддерживать. При 30 метках потребуется следить за границами каждой, а при 6 метках проще увидеть, где модель ошибается. Хорошее правило допускает одну основную метку и одну дополнительную, но не заставляет выбирать пять равноправных вариантов.
Для примера: в компании из сферы логистики, примерно на 200 сотрудников, можно начать с 6 категорий и 3 уровней срочности. После обработки 100 обезличенных сообщений команда увидит, какие формулировки повторяются, где не хватает отдельной метки и какие обращения регулярно попадают не в тот отдел.
Как устроить маршрут спорных сообщений
Спорное обращение должно попадать на проверку при уверенности ниже 0,85 или при конфликте признаков. Это безопаснее, чем отправлять каждое сообщение в отдел автоматически и исправлять последствия вручную.
Я использую двухступенчатую схему. На первом шаге нейросеть возвращает категорию, срочность, отдел и короткое объяснение признаков. На втором этапе отдельное правило проверяет допустимость результата: существует ли такой отдел, разрешена ли выбранная категория и заполнен ли срок реакции.
Гипотетический пример: при уверенности 0,88 сообщение о двойном списании уходит в финансовую очередь, а при значении 0,62 и словах «не знаю, кому писать» попадает в очередь разбора. Если в тексте одновременно встречаются «доставка» и «возврат», система может поставить одну основную категорию, вторую сохранить как дополнительный признак и направить запись координатору.
Внутри процесса нужны минимум 4 технических поля контроля:
- исходный текст без изменений;
- результат классификации;
- дата и время обработки;
- причина ручного решения, если модель ошиблась.
Исходный текст нельзя заменять пересказом. Иначе при споре будет трудно понять, почему сработало правило. Временная отметка нужна для проверки SLA, а причина исправления помогает обновлять примеры. Если 7 из 20 исправлений связаны с различием между «возвратом» и «отменой», границу этих категорий нужно переписать.
В материале о внедрении нейросетей в рабочие процессы я подробно разбираю переход от разового эксперимента к повторяемому процессу. Для классификации особенно полезны этапы с владельцем правила и измерением результата.
Как проверить качество классификации
Качество нужно измерять минимум по 4 показателям: доле правильных категорий, точности определения высокой срочности, доле сообщений без маршрута и числу исправлений сотрудников.
Проверка начинается с эталонной выборки. Возьмите 100 обезличенных сообщений, разметьте их вручную и не показывайте эту разметку модели во время теста. Затем сравните её ответы с эталоном. Отдельно посчитайте ошибки высокой срочности: пропущенный аварийный запрос опаснее, чем перепутанные «общий вопрос» и «консультация».
Модельный кейс: если из 100 сообщений система правильно определила категорию в 86 случаях, это точность 86%. Если из 20 действительно срочных обращений она нашла 19, полнота по срочности составила 95%. Эти числа нельзя переносить на любую компанию, потому что результат меняют качество разметки, длина сообщений, число категорий и язык клиентов.
Полезно вести матрицу ошибок. В ней строки показывают настоящие категории, столбцы отражают предсказанные. Например, 12 сообщений о возврате могут попасть в «оплату», а 4 технических вопроса, наоборот, окажутся в «общих». Такая таблица показывает проблему точнее, чем единая оценка 86%.
Проверку нужно повторять после изменения таксономии, инструкции или порога уверенности. Для регулярного контроля подойдёт случайная выборка из 50 сообщений в неделю, если поток позволяет её собрать. При резком росте ошибок выборку расширяют до 100–200 сообщений, иначе редкие сбои останутся незаметными.
Статья «Как использовать нейросети и чат-боты для повседневных задач» полезна для оценки рутинных сценариев. Здесь подход тот же: сначала фиксируется повторяемая операция, потом задаётся критерий приемлемого результата.
Что выбрать для первичной сортировки
Для потока до 3 основных типов обращений достаточно правил, а при 6–8 категориях и свободных формулировках полезнее нейросетевой классификатор с порогом проверки. Универсального варианта нет: решение определяется стабильностью словаря и ценой ошибки.
| Подход | Подходит для | Сильная сторона | Ограничение |
|---|---|---|---|
| Ручная сортировка | до 30 сообщений в день или редкие исключения | сотрудник видит контекст и скрытый смысл | время растёт вместе с потоком |
| Ключевые слова и правила | 3–5 стабильных типов запросов | легко объяснить и проверить | плохо работают с синонимами и опечатками |
| Нейросетевая классификация | 6–8 категорий, свободный язык, повторяемый поток | учитывает смысл и контекст сообщения | требует эталонной выборки и контроля |
| Смешанная схема | высокая цена пропущенной срочности | автоматизация массовых случаев и проверка сомнений | нужно поддерживать пороги и журнал исправлений |
У SoftChat есть веб-чат с потоковой выдачей ответа и переключением моделей для разговора. Я могу использовать такой формат, чтобы подготовить инструкцию классификатора, проверить пограничные формулировки и получить несколько вариантов структуры запроса. Автоматическое направление обращений по отделам каталогом SoftChat не заявлено, поэтому сам маршрут нужно строить в вашей рабочей системе, скрипте или другом подключённом контуре.
Для предварительного разбора потребностей можно сравнить бытовые сценарии в статье «Алиса или нейросеть в браузере: что выбрать». Для сортировки обращений критерий строже: важны журнал решений, порог уверенности и возможность объяснить ошибку.
Как запустить сценарий без лишнего риска
Пилот можно построить за 4 этапа и проверить на 100 обезличенных сообщениях до подключения к рабочему потоку. Такой порядок снижает вероятность того, что неудачная метка сразу повлияет на клиентов.
Сначала зафиксируйте 5–8 категорий и 3 уровня срочности. Затем соберите примеры, где каждая метка имеет положительные и отрицательные границы. После этого задайте формат ответа с обязательными полями и добавьте проверку допустимых значений. На последнем этапе сравните результат с ручной разметкой и назначьте владельца изменений.
Условный пример: команда поддержки из 8 человек может начать с 2 категорий, 30 примеров на каждую и порога 0,85. Через неделю она проверяет 50 новых обращений, считает ошибки и решает, нужно ли добавлять третью категорию. Это план эксперимента, а не обещание определённого результата.
Я бы на вашем месте сначала автоматизировал сортировку по теме, а срочность оставил под более строгим контролем. В финансовых запросах, авариях и обращениях с персональными данными цена одной ошибки выше экономии нескольких минут. Когда эталонная выборка покажет стабильные результаты, можно расширять число отделов и добавлять сроки реакции.
Главное рабочее правило простое: нейросеть должна ускорять первичный просмотр, а не скрывать решение от команды. Если для каждой метки есть пример, порог и журнал исправлений, поток обращений становится измеримым. Если этих элементов нет, автоматизация лишь перемещает хаос из почты в новую очередь.