Сортировка писем нейросетью без ручного разбора в 2026

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

Первичный разбор входящих писем обычно выглядит безобидно, пока поток не доходит до 80–150 обращений в день. Менеджер открывает письмо, читает 4–12 строк, ищет номер заказа, понимает тон клиента, выбирает отдел и ставит приоритет. Даже 90 секунд на одно сообщение превращаются в 3 часа 45 минут при 150 письмах. Это время не создаёт ответа клиенту, не закрывает продажу и не решает инцидент.

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

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

Что именно сортирует нейросеть во входящем потоке

Нейросеть присваивает каждому обращению минимум 3 метки: срочность, тип запроса и ответственный отдел. Для рабочего процесса на 100+ сообщений в день этого обычно достаточно, чтобы убрать ручное чтение всего потока и оставить человеку проверку 10–20% спорных обращений.

Практичная схема начинается не с модели, а с словаря категорий. Например, срочность можно задать по шкале от 1 до 5: «1» для информационных писем, «3» для обычной заявки, «5» для простоя оплаты, отгрузки или доступа. Тип запроса лучше держать в пределах 8–12 классов: оплата, документы, доставка, возврат, жалоба, технический сбой, консультация, изменение данных, повторное обращение, спам. Если классов 25, качество разметки падает уже на этапе обучения команды, потому что два менеджера начинают выбирать разные ярлыки для одной ситуации.

Отделы тоже надо описывать через действия, а не названия. «Бухгалтерия» получает запросы на акты, счета и закрывающие документы. «Логистика» получает перенос даты, трек-номер, недовоз и повреждение. «Продажи» получает расчёт КП, подбор тарифа и вопросы о наличии. Такая расшифровка снижает число ошибок на границе отделов, например между продажами и поддержкой.

В SoftChat можно отработать такую схему в чате: создать диалог, задать системный промпт под классификацию и сравнить поведение разных моделей в рамках одной задачи. В веб-чате доступны вкладки «Текст» и «Графика», а настройки текущего чата позволяют менять параметры ответа вроде «Креативность» и «Длина ответа». Для сортировки писем я обычно держу креативность низкой, потому что классификатору нужна стабильность, а не вариативность формулировок.

Как задать правила срочности, чтобы модель не путала шум и риск

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

Плохое правило звучит так: «срочные письма отправляй в поддержку». Хорошее правило перечисляет признаки. Если клиент пишет «не проходит оплата», «сервис недоступен», «сегодня отгрузка», «претензия», «договор расторгнем», это приоритет 4 или 5. Если письмо содержит «уточните, пожалуйста», «можно ли получить копию», «интересует цена на следующий месяц», это чаще приоритет 2 или 3.

Полезно отделить эмоциональность от срочности. Фраза «вы совсем не отвечаете» может быть жалобой без операционного риска, если в письме нет суммы, дедлайна и блокировки процесса. Обратная ситуация встречается часто: короткое письмо «не можем войти в личный кабинет, отгрузка в 11:00» содержит 2 факта риска, доступ и срок. Его надо поднять выше длинного эмоционального текста.

Для промпта я использую формат с явными полями: «срочность 1–5», «почему», «какие фразы повлияли», «куда отправить», «нужна ли проверка человеком». Такой вывод легче загрузить в таблицу, CRM или сервис заявок через отдельную интеграцию. Если вы ещё не внедряли нейросети в процессы, разбор про встраивание ИИ в рабочие операции поможет не начать с хаотичных экспериментов.

Чем отличаются ручная сортировка, правила и нейросеть

Для потока до 20 сообщений в день ручной разбор часто дешевле автоматизации, но после 50–70 сообщений узкое место становится заметным. Нейросеть выигрывает там, где письмо написано свободным языком, а простые правила по ключевым словам дают слишком много ложных срабатываний.

Гибридная схема обычно самая надёжная. Правило может сразу отправлять письма с темой «возврат платежа» в финансовый контур, а модель разбирает письма без явных слов. Ещё один пример: фильтр отбрасывает автоответы и рассылки, затем модель классифицирует оставшиеся 60–80% обращений.

Условный пример: интернет-магазин с 120 входящими письмами в день может сначала выделить 10 классов запросов и 5 уровней срочности, а спорные письма отправлять в очередь «проверить». В такой схеме человек читает не весь поток, а письма с низкой уверенностью или высоким риском, например возврат денег, жалоба, срыв доставки в тот же день.

Как собрать тестовую выборку и измерить качество

Для первого теста хватит 200–300 реальных обезличенных сообщений за последние 30 дней. Из них 50–80 писем лучше разметить вручную двумя сотрудниками, чтобы увидеть спорные классы до запуска автоматизации.

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

Я бы фиксировал 5 показателей в еженедельном отчёте: доля автоматически размеченных писем, доля отправленных на проверку, точность отдела, полнота по приоритету 4–5, среднее время до первого ответа. Если после 2 недель число ручных исправлений не падает, проблема часто не в модели, а в категориях. Например, «документы» и «бухгалтерия» могут дублировать друг друга, а «поддержка» становится корзиной для всего непонятного.

Для промптов удобно держать отдельный файл с версиями. Версия 1.0 может содержать 8 классов, версия 1.1 добавляет «повторное обращение», версия 1.2 меняет правила срочности для оплат. Такой журнал спасает от ситуации, когда результат изменился, а никто не помнит, какое правило переписали во вторник.

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

Как выглядит рабочий промпт для сортировки

Хороший промпт для сортировки содержит 6 блоков: роль, список категорий, шкалу срочности, формат ответа, правила эскалации и примеры. Без формата ответа модель может выдать красивое объяснение, но его будет трудно использовать в таблице или очереди заявок.

Пример структуры без привязки к конкретной системе:

1. «Ты классифицируешь входящие обращения компании».
2. «Верни отдел: продажи, поддержка, финансы, логистика, юридический блок, другое».
3. «Верни срочность от 1 до 5 по правилам SLA».
4. «Верни тип запроса из списка 10 классов».
5. «Если есть риск денег, доступа или дедлайна до 24 часов, поставь проверку человеком».
6. «Ответ верни в JSON с полями: department, urgency, request_type, reason, human_review».

Для примера: письмо «Не проходит оплата по счёту, отгрузка сегодня до 16:00» должно получить срочность 5, отдел «финансы» или «поддержка платежей» по вашей структуре, тип «оплата», проверку человеком «да». Письмо «Пришлите копию акта за февраль» обычно получает срочность 2, отдел «финансы», тип «документы», проверку «нет».

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

Где поставить человека в контуре проверки

Человек нужен на 2 участках: при создании правил и при разборе рисковых писем. Если модель уверенно размечает 80% обычных обращений, оставшиеся 20% лучше направлять в очередь контроля, а не пытаться выжать автоматизацию до 100%.

Контроль стоит включать для писем с суммой, юридическими формулировками, угрозой отказа, персональными данными, вложениями и сроком меньше 24 часов. Для таких сообщений цена ошибки выше, чем экономия 1–2 минут. При этом не надо заставлять менеджера перечитывать всё. Достаточно показать исходное письмо, предложенные метки, объяснение из 1–2 предложений и кнопку исправления.

Отдельная тема, обучение сотрудников. Люди должны понимать, что нейросеть делает первичную разметку, а не принимает коммерческое или юридическое решение. В обучении помогают маленькие сценарии: 10 писем на оплату, 10 жалоб, 10 запросов по доставке, 10 спорных случаев. Такой набор за 40 примеров быстрее объясняет логику, чем инструкция на 12 страниц.

Если команда уже использует чат-ботов для рутинных задач, можно опереться на привычные сценарии из статьи про нейросети и чат-боты в повседневной работе. Сортировка обращений отличается тем, что здесь нужен журнал решений и проверяемые метки, а не просто удобный ответ на один вопрос.

Какие ошибки ломают автоматическую сортировку

Чаще всего проект ломают 4 ошибки: слишком много классов, нет тестовой выборки, смешаны отдел и тема, не задана очередь проверки. При потоке 100 писем в день каждая такая ошибка быстро превращается в десятки неверных маршрутов за неделю.

Первая ошибка, классы вроде «прочее», «разное», «общее». Они растут быстрее остальных и через месяц собирают 30–40% обращений. Лучше назвать конкретные причины: «не хватает данных», «несколько тем», «неизвестный отдел», «автоответ». Тогда становится ясно, что исправлять.

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

Третья ошибка, отсутствие даты пересмотра. Категории стареют. Если компания запускает новый продукт, меняет условия доставки или добавляет платёжный сценарий, классификатор надо обновить. Я бы ставил ревизию каждые 30 дней на старте и раз в квартал после стабилизации.

Что бы я сделал на вашем месте

Я бы начал с 1 канала, 10 категорий и 200 обезличенных сообщений, а не с полной автоматизации всех писем компании. За 2 недели такой пилот покажет, где нейросеть экономит время, а где процесс пока плохо описан людьми.

Сначала выгрузите письма за последний месяц и удалите персональные данные, которые не нужны для классификации. Затем вручную разметьте 50–80 сообщений и договоритесь о шкале срочности. После этого проверьте промпт на оставшейся выборке, заведите очередь «проверить человеком» и посчитайте точность отдела плюс полноту по срочным обращениям.

Если результат стабилен, расширяйте схему на второй канал: форму сайта, обращения из кабинета, общую почту отдела. Если результат плавает, не меняйте модель каждые 2 часа. Сначала укоротите список классов, добавьте 10–15 примеров и перепишите правила эскалации. В сортировке писем выигрывает не самая сложная схема, а та, которую менеджеры понимают в понедельник утром и могут исправить без разработчика.