Как нейросеть сортирует обращения из почты и мессенджеров
Практическая схема превращает разрозненные сообщения в понятный маршрут для менеджера: тема, приоритет, следующий шаг и контроль качества.
Ручная сортировка обращений ломается в одном и том же месте: сотрудник читает письмо, открывает историю переписки, определяет срочность, ищет инструкцию и только потом передаёт задачу дальше. При потоке из почты, мессенджеров и форм эти действия повторяются десятки раз за день. Нейросеть может взять на себя первичный разбор, если заранее задать ей поля результата, правила приоритета и условия передачи человеку.
Я рассматриваю такой процесс как конвейер из пяти этапов: собрать сообщение, очистить его от лишнего, определить тему, назначить приоритет и предложить следующий шаг. Автоматизация начинается не с длинного запроса, а с ясной схемы данных. Без неё модель будет пересказывать текст, но не поможет распределить нагрузку.
Что именно делает нейросеть с обращением
Нейросеть превращает одно обращение в запись из 4 полей: тема, приоритет, следующий шаг и причина решения. Такой формат удобнее свободного ответа, потому что менеджер видит результат за несколько секунд и может проверить спорное место.
Сначала система получает исходный текст. Это может быть письмо с темой и подписью, сообщение из мессенджера или заявка из формы. Затем она отделяет факты от служебных элементов: адреса, повторяющейся подписи, рекламного блока и цитаты из предыдущей переписки. Если вложение не передано на обработку, его содержание нельзя считать прочитанным.
Я задаю классификатору ограниченный справочник тем. Например, в нём могут быть категории «запрос цены», «статус заказа», «проблема с оплатой», «техническая ошибка», «возврат» и «партнёрство». Шесть понятных классов обычно проще проверять, чем длинный список из 20 размытых формулировок.
Приоритет лучше отделять от темы. Запрос о возврате может быть обычным, а короткое сообщение о двойном списании требует быстрой проверки. Поэтому в результате нужны два независимых поля: «что произошло» и «насколько быстро реагировать».
Полезно заранее описать допустимый ответ:
- тема, одно значение из справочника;
- приоритет, низкий, средний или высокий;
- следующий шаг, например запросить номер заказа или передать платёжному специалисту;
- причина, одна или две фразы с опорой на текст обращения.
Такой подход продолжает логику решения повседневных задач с помощью нейросетей: сначала формулируется повторяемая операция, затем для неё задаётся проверяемый результат.
Как подготовить поток обращений до запуска
Для устойчивой сортировки нужны 3 слоя подготовки: чистый текст, справочник категорий и набор пограничных примеров. Если пропустить хотя бы один слой, ошибки будут выглядеть случайными, хотя причина окажется в исходных правилах.
Первый слой, очистка. Из сообщения убирают подписи, длинные цепочки цитат, номера рекламных рассылок и повторяющиеся приветствия. При этом нельзя удалять дату, сумму, номер заказа или название услуги, если они влияют на маршрут. Я сохраняю исходную версию отдельно, а в классификатор передаю очищенный текст и короткие служебные поля.
Второй слой, словарь. Для каждой категории нужны название, определение, два или три признака и исключение. Для темы «статус заказа» признаком будет вопрос о местоположении отправления, исключением, сообщение о повреждении товара. Такое описание снижает пересечение между классами.
Третий слой, примеры. В подборку стоит включить короткие, длинные, эмоциональные и неполные сообщения. Отдельно добавляют случаи с несколькими вопросами. Например, клиент может одновременно спросить о сроке доставки и сообщить о списании. Если заранее не определить главный маршрут, разные сотрудники будут обрабатывать одинаковый текст по-разному.
Я использую для проверки следующую рабочую таблицу:
| Этап | Что подаём на вход | Что проверяем на выходе |
|---|---|---|
| Очистка | Текст, тема письма, дата | Сохранены факты и номера |
| Определение темы | Справочник из 4–8 классов | Выбрана одна основная категория |
| Приоритет | Признаки срочности и ущерба | Есть уровень и причина |
| Следующий шаг | Правила маршрутизации | Назначен человек или очередь |
| Контроль | Метка проверки и исходный текст | Ошибку можно восстановить |
Перед внедрением я сверяю эту структуру с материалом о внедрении нейросетей в рабочие процессы. Там полезно рассматривать автоматизацию как часть процесса, а не как отдельное окно с ответами.
Как определить тему, приоритет и следующий шаг
Классификацию я строю на 3 независимых решениях: о чём сообщение, насколько оно срочное и какое действие следует выполнить. Разделение снижает риск, когда эмоциональный тон ошибочно принимают за высокий приоритет.
Для темы задают одно главное значение. Если обращение содержит два вопроса, выбирают тот, который требует первого действия. В поле причины можно сохранить вторую тему, но маршрут должен оставаться однозначным. Иначе сообщение попадёт сразу в несколько очередей и потеряется при передаче.
Приоритет удобно связывать с наблюдаемыми сигналами. Высокий уровень получает обращение, где есть риск финансового ущерба, блокировка услуги, повторное списание или невозможность выполнить обязательство. Средний уровень подходит для задержки, ошибки в данных или нерешённого вопроса после первого ответа. Низкий уровень можно назначать общим вопросам, запросам документов и предложениям без срока реакции.
Я не советую использовать слова «срочно» и «немедленно» как единственное условие. Их легко добавить в тему письма без фактической угрозы. Надёжнее сочетать слово с объектом, суммой, сроком или повторным обращением. Например, «срочно, списали дважды» и «срочно пришлите каталог» должны попадать в разные очереди.
Модельный кейс: компания из сферы логистики, примерно 200 сотрудников, получает 120 обращений в день. Для первичного маршрута ей достаточно 5 тем, 3 уровней приоритета и 2 вариантов эскалации: менеджеру смены или специалисту по оплате. Это иллюстрация архитектуры, а не отчёт о реальном клиентском результате.
В запросе к нейросети я фиксирую последовательность:
- Прочитай сообщение и выдели факты.
- Выбери одну тему из справочника.
- Назначь приоритет по правилам, а не по эмоциональному тону.
- Предложи один следующий шаг.
- Если данных недостаточно, укажи, какой вопрос нужно задать человеку.
Подробные приёмы формулировки таких инструкций разобраны в материале об искусстве промптинга для нейросетей. Для сортировки особенно полезны ограничения формата и явные условия отказа от догадки.
Что передавать менеджеру после классификации
В рабочем маршруте достаточно 2 путей: автоматическая передача стандартных обращений и эскалация спорных случаев человеку. Нейросеть не должна самостоятельно закрывать задачу, если в сообщении есть финансовый риск, юридическая претензия или нехватка данных.
Первый путь подходит для простых ситуаций. Классификатор добавляет метку, выбирает очередь и формирует краткое резюме. Менеджер видит исходный текст, выделенные факты и предложенный ответный шаг. Такая запись экономит время на повторном чтении, но не отменяет контроль.
Второй путь нужен для неопределённости. Я отправляю на ручную проверку сообщения с двумя подходящими темами, противоречивыми датами, отсутствующим номером заказа и признаками ущерба. Полезно добавить причину эскалации, иначе сотрудник снова потратит время на поиск проблемы в полном тексте.
| Ситуация | Действие системы | Роль менеджера |
|---|---|---|
| Одна тема, полный набор данных | Назначить очередь | Проверить результат |
| Две возможные темы | Поставить отметку проверки | Выбрать маршрут |
| Финансовый риск или претензия | Передать специалисту | Принять решение |
| Нет номера заказа или даты | Сформировать уточняющий вопрос | Отправить запрос |
Модельный кейс: из 80 сообщений за смену 60 содержат одну понятную тему, 12 требуют уточнения, а 8 связаны с оплатой или претензией. В такой схеме первые 60 можно направить в стандартную очередь, 20 оставить под контролем специалиста. Числа нужны для иллюстрации распределения, их нельзя выдавать за результат конкретной компании.
Передачу в CRM или другую рабочую систему проектируют отдельно. В ней должны сохраняться исходный текст, результат классификации, время обработки и факт ручной правки. Четыре поля позволяют восстановить спорное решение и понять, где именно возникла ошибка.
Как проверить качество до полноценного запуска
Качество проверяют на выборке минимум из 100 обращений, размеченных человеком по тем же правилам, что использует классификатор. Одной общей оценки недостаточно: отдельно измеряют тему, приоритет, следующий шаг и долю случаев, отправленных на проверку.
Я начинаю с матрицы ошибок. Для каждой пары категорий считаю, сколько сообщений перепутано. Если «оплата» часто смешивается с «возвратом», нужно уточнить определения, добавить пограничный пример или изменить порядок правил. Простое увеличение объёма инструкций обычно не решает проблему.
Для приоритета полезны две проверки. Первая, сколько действительно срочных сообщений система пропустила. Вторая, сколько обычных обращений ошибочно отправила в срочную очередь. Пропуск обычно опаснее лишней проверки, но соотношение зависит от стоимости задержки и доступного числа сотрудников.
Модельный кейс: в тестовой выборке из 100 сообщений система верно определила тему в 91 случае, а 9 отправила на ручную проверку. Это может быть приемлемым стартом для пилота, если все 9 сомнительных сообщений действительно заметны оператору. Если среди 91 правильного ответа есть пропущенное двойное списание, порог запуска нужно пересмотреть, даже при высокой общей точности.
Я рекомендую вести журнал изменений не меньше 2 недель после запуска. В нём фиксируют исходный текст, решение модели, исправление менеджера и новую формулировку правила. Через 10–15 рабочих дней становится видно, какие ошибки повторяются, а какие возникли из-за единичного нестандартного сообщения.
Для текстовых черновиков действует похожая логика проверки: результат нужно сопоставлять с исходными данными, а не принимать за готовую истину. Такой подход подробно описан в статье о генерации текста и проверке результата.
Где использовать SoftChat при настройке сценария
Для ручной настройки достаточно 2 операций: подготовить обезличенную выборку и сравнить ответы на одинаковых правилах. В веб-чате SoftChat можно вести разговор, переключать модель для конкретного диалога и получать ответ по мере его формирования.
Я использовал бы такой чат как рабочий стенд для проверки формулировок, а не как доказательство автоматической обработки всей почты. В один разговор можно поместить справочник категорий, затем последовательно передать несколько обезличенных сообщений и проверить, сохраняет ли модель заданный формат. После изменения одного правила сравнение повторяют на том же наборе.
Практическая последовательность выглядит так:
- сначала передать 10–15 сообщений без персональных данных;
- затем проверить отдельно обычные, срочные и неоднозначные случаи;
- после этого сопоставить ответы двух моделей в рамках одного диалога;
- в конце выбрать правила, которые менеджер способен проверить за несколько секунд.
Не следует отправлять в чат паспортные данные, полные номера карт, пароли и лишнюю переписку. Для настройки достаточно заменить личные сведения на метки вроде «клиент» и «номер заказа». Такой способ сохраняет структуру обращения и уменьшает объём чувствительной информации.
Что бы я сделал на вашем месте
Я начал бы с одного потока и 5 категорий, а решение о расширении принял бы после проверки 100 сообщений и двух недель журнала ошибок. Если классификатор стабильно различает тему, приоритет и следующий шаг, можно обсуждать передачу результата в рабочую очередь. Если он путает финансовые и обычные обращения, сначала нужно исправить справочник и правила эскалации, а не увеличивать автономность.
Мой критерий прост: менеджер должен понимать, почему сообщение получило конкретную метку, и иметь возможность исправить её одним действием. При таком устройстве нейросеть сокращает ручной разбор, а ответственность за спорные решения остаётся у человека.