Сортировка входящих сообщений с помощью нейросети в 2026
Стендфирст: практическая схема сортировки обращений для поддержки, продаж и офисной переписки с контролем ошибок и понятными метриками.
Входящие сообщения редко приходят в удобном порядке: рядом с вопросом о документах может оказаться жалоба на недоступный сервис, запрос коммерческого предложения или короткое «перезвоните срочно». Я рассматриваю нейросеть как первый фильтр, который раскладывает поток по понятным признакам, а решение по спорным случаям оставляет сотруднику.
Смысл подхода не в том, чтобы убрать человека из процесса. Задача первой автоматизированной сортировки уже, она помогает быстрее увидеть срочные обращения, отделить типовые вопросы от нестандартных и собрать очередь для разных специалистов. Перед запуском стоит описать категории, правила приоритета и способ проверки результата. Подробный разбор рабочих сценариев есть в статье о внедрении нейросетей в рабочие процессы.
Что именно сортирует нейросеть
В базовом сценарии нейросеть распределяет сообщение минимум по 4 признакам: тип запроса, срочность, стадия общения и требуемый следующий шаг. Чем точнее описаны эти признаки, тем меньше размытых ответов вроде «похоже на обращение клиента».
Я обычно начинаю с четырёх классов:
- срочное обращение, где есть риск простоя, финансовой потери или срыва обещанного срока;
- вопрос по действующему продукту, документу, оплате или настройке;
- коммерческий интерес, включая запрос цены, условий и демонстрации;
- прочие сообщения, которые требуют ручного просмотра.
Классы лучше называть так, чтобы сотрудник понял их без расшифровки. Формулировка «приоритет 1» слабее, чем «сервис недоступен». В первом варианте модель видит условный ярлык, во втором получает связь между текстом и действием.
Для сортировки офисной почты можно добавить признак адресата: бухгалтерия, юрист, отдел продаж, руководитель. Для поддержки полезнее выделить тему: вход в аккаунт, платёж, ошибка, возврат, запрос инструкции. Не стоит создавать 20 категорий на старте. При таком количестве границы между классами быстро становятся неясными, а проверка качества превращается в ручную сверку длинного списка.
Как устроен рабочий процесс
Практическая схема состоит из 5 шагов: получение текста, очистка, классификация, передача в нужную очередь и проверка спорных решений. Такой порядок помогает отделить ошибку исходных данных от ошибки самой нейросети.
Сначала уберите из сообщения повторяющиеся подписи, длинные цепочки цитат и технический мусор. Сохраните дату, тему письма и признак нового обращения, если эти данные доступны в вашей системе. Затем передайте нейросети инструкцию с описанием категорий, примерами границ и требуемым форматом ответа.
Удобный результат выглядит так:
категория: платёж
срочность: высокая
уверенность: 0,86
причина: клиент сообщает о списании средств без доступа к услуге
следующий шаг: передать специалисту по оплатам
Поле «причина» нужно для аудита, но его нельзя превращать в длинное сочинение. Достаточно 1 предложения, которое связывает решение с фрагментом сообщения. Если уверенность ниже заданного порога, обращение отправляется на ручную проверку. Порог 0,80 можно использовать как стартовую настройку в модельном тесте, затем изменить его по итогам разметки.
| Подход | Что происходит | Сильная сторона | Ограничение | Когда применять |
|---|---|---|---|---|
| Ручная сортировка | Сотрудник читает каждое сообщение и выбирает очередь | Понимание контекста | Скорость зависит от загрузки и внимания | Небольшой поток или сложные обращения |
| Правила по словам | Система ищет заданные слова и шаблоны | Предсказуемость и простой аудит | Плохо видит синонимы и скрытый смысл | Повторяемые технические сигналы |
| Нейросетевая классификация | Модель сопоставляет текст с описанными категориями | Обработка свободной формулировки | Возможны неверные выводы и смешение классов | Поток с разными формулировками |
| Гибридная схема | Правила ловят жёсткие сигналы, модель разбирает остальное | Баланс скорости и контроля | Нужно поддерживать два слоя логики | Поддержка, продажи и офисная почта |
В разборе задач нейросети для генерации текста я рекомендую тот же принцип: результат считается рабочим после проверки, а не сразу после генерации.
Как выделять срочные обращения
Для приоритизации достаточно 3 уровней: высокий, обычный и низкий, но для каждого уровня нужны наблюдаемые признаки. Слова «срочно» и «немедленно» сами по себе не доказывают критичность: клиент может использовать их в стандартном вопросе о сроках.
Высокий приоритет стоит связывать с конкретным последствием. Примеры сигналов: несколько пользователей не могут войти, платёж списан без ожидаемого результата, поставка остановлена, договорный срок заканчивается в тот же день. Обычный уровень подходит для вопросов по настройке и документам. Низкий, для предложений, общих консультаций и запросов, где нет ограничения по времени.
Модельный кейс: компания из сферы логистики, около 200 сотрудников, получает 180 входящих сообщений за рабочую смену. В инструкции можно задать правило: сообщения о полной остановке отгрузок отправлять в высокий приоритет, вопросы о статусе одной заявки оставлять в обычной очереди, а запросы на будущий расчёт переносить в низкую.
Полезно проверять два показателя отдельно. Точность показывает, какая доля сообщений с меткой «высокий приоритет» действительно срочная. Полнота показывает, сколько реальных срочных обращений удалось найти. Если повысить порог слишком сильно, ложных тревог станет меньше, но часть критичных сообщений останется в общей очереди.
Как распознавать типовые вопросы
Для типовых обращений достаточно каталога из 6–8 тем и короткого ответа для каждой темы, но финальный текст клиенту должен проходить проверку сотрудника. Сортировка и генерация ответа, разные операции: первая определяет маршрут, вторая формулирует сообщение.
В категорию «доступ» можно включить вопросы о входе, восстановлении и подтверждении адреса. В категорию «оплата», о списании, счёте, возврате и платёжном статусе. Если в одной теме смешаны действия с разными рисками, её лучше разделить. Возврат денег и запрос копии счёта могут относиться к оплате, но требуют разных исполнителей.
Я советую давать нейросети примеры на границе классов. Например, фраза «не могу войти после оплаты» одновременно содержит признаки доступа и платежа. В инструкции нужно указать, какой признак приоритетнее, или разрешить две метки. Для первой линии чаще удобнее одна основная категория и отдельное поле «нужна проверка».
Хорошая инструкция отвечает на 5 вопросов:
- какие категории доступны;
- чем они отличаются;
- какой признак имеет больший вес при конфликте;
- в каком формате вернуть результат;
- что делать при нехватке данных.
Практику составления таких инструкций разбирает материал об искусстве промптинга для нейросетей. В рабочем варианте я добавляю 10–15 размеченных сообщений, включая короткие, эмоциональные и двусмысленные формулировки.
Как измерить пользу для первой линии
Минимальный набор измерений включает 4 показателя: долю верных категорий, полноту поиска срочных обращений, медианное время до первого просмотра и число сообщений, ушедших на ручную проверку. Один показатель скорости не объяснит, стало ли обслуживание безопаснее.
Раз в неделю полезно брать случайную выборку из 50–100 сообщений и сравнивать решение модели с оценкой сотрудника. В таблице фиксируйте исходный текст, ожидаемую категорию, результат сортировки и причину расхождения. Через 3–4 таких цикла становится видно, где проблема системная: в пересекающихся категориях, коротких сообщениях или недостатке примеров.
Условный пример: из 100 проверенных сообщений нейросеть правильно определила 87 категорий, пропустила 2 из 10 срочных обращений, а 18 сообщений отправила на ручной просмотр из-за низкой уверенности. Такая картина подсказывает три направления работы: уточнить правила срочности, проверить спорные категории и решить, приемлема ли доля ручной проверки для текущей команды.
Считайте время отдельно для разных типов обращений. Вопрос по инструкции и жалоба на списание средств имеют разную цену задержки. Для первой линии разумно задать целевой срок просмотра, например 15 минут для высокой срочности и 4 часа для обычной. Это рабочие пороги для настройки процесса, а не универсальный отраслевой стандарт.
Как снизить риск ошибок
Надёжная схема требует 3 ограничений: запрета на самостоятельное решение рискованных вопросов, ручной проверки низкой уверенности и регулярного пересмотра категорий. Нейросеть может ошибиться из-за опечатки, сарказма, неполного контекста или противоречивых данных.
Не передавайте модели полномочия самостоятельно обещать возврат, менять условия договора или закрывать жалобу. Пусть она определяет маршрут и формирует объяснение для сотрудника. Решение остаётся у человека там, где ошибка затрагивает деньги, доступ к услуге, юридические сроки или персональные данные.
Перед тестом удалите лишние персональные сведения. Для проверки классификации обычно достаточно текста обращения, типа запроса и технического контекста без полного имени, номера телефона и платёжных реквизитов. Если эти поля нужны для маршрутизации, ограничьте круг людей, которые видят исходные данные.
Для спорных сообщений используйте отдельную очередь. Не заставляйте модель выбирать категорию любой ценой, если в тексте нет достаточных признаков. Ответ «недостаточно данных» полезнее уверенной, но неверной метки.
Как проверять инструкции в SoftChat
В SoftChat для такой отладки доступны веб-чат, переключение моделей внутри беседы и потоковая выдача ответа. Это позволяет сравнивать несколько вариантов инструкции на одинаковом наборе сообщений и видеть результат по мере формирования, не приписывая продукту функцию автоматической обработки почты.
Я бы проверял инструкцию сериями по 20 сообщений. В первой серии оставил бы ясные примеры, во второй добавил бы короткие и эмоциональные фразы, в третьей, смешанные обращения с двумя возможными категориями. После каждой серии фиксировал бы 3 вещи: неверную метку, пропущенный сигнал срочности и лишнее объяснение.
Если разные модели дают разные категории, проблема может быть в описании классов, а не в выборе конкретного варианта. Сначала сократите пересечения и добавьте правило приоритета. Затем повторите тест на тех же 20 сообщениях, чтобы сравнение оставалось честным. Подход к интеграции нейросети в ежедневные задачи дополнительно описан в статье о применении нейросетей в повседневных задачах.
Что бы я сделал на вашем месте
Я бы начал с одной очереди и 4 категорий, собрал 100 обезличенных сообщений и вручную разметил их до первого запуска. После этого проверил бы отдельно срочность, тип запроса и долю случаев, где модель просит ручной разбор.
Если точность категорий держится на приемлемом уровне, добавил бы маршрутизацию по отделам. Если ошибки повторяются, не расширял бы список до 20 тем, а сначала переписал определения и добавил примеры на границах классов. Такой порядок даёт понятную точку сравнения: видно, что изменилось после каждой правки, а первая линия получает очередь, которой можно доверять в пределах заданных правил.