Нейросеть для сортировки писем: тема и срочность в 2026
Стендфирст: Практическая схема разбора входящей почты, которая помогает определить тему письма, выделить срочные обращения и подготовить черновик ответа без потери контроля специалиста.
Поток писем редко состоит из одной задачи. В нём смешиваются вопросы клиентов, счета, просьбы о документах, сообщения от коллег и обращения, где задержка на 2 часа уже меняет результат. Нейросеть может превратить такое письмо в структурированную запись: определить тему, извлечь факты, оценить срочность и предложить текст ответа.
Я рассматриваю этот сценарий как конвейер из отдельных решений, а не как просьбу «разберите почту». Такой подход легче проверить, настроить и встроить в рабочий процесс. Для начала полезно разобраться, как нейросеть создаёт тексты и где нужна проверка результата, а затем перенести приёмы на письма поддержки, продажи или административные запросы.
Что именно делает нейросеть с письмом
Нейросеть превращает письмо минимум в 4 элемента: тему обращения, извлечённые факты, уровень срочности и черновик следующего действия. Такая разметка помогает отделить классификацию от генерации текста и проверять каждый результат отдельно.
У письма есть техническая оболочка и смысловая часть. Стандарт RFC 5322, опубликованный в 2008 году, описывает базовый формат интернет-сообщений, включая поля отправителя, получателя, даты и темы. Для рабочего разбора обычно нужны следующие данные:
- тема и текст письма;
- имя отправителя и организация, если они указаны;
- даты, номера заказов, договоров или заявок;
- упоминания сроков, оплаты, блокировки доступа и других последствий;
- вложения и их названия, если содержимое действительно доступно для анализа.
На первом этапе я прошу модель вернуть фиксированную структуру. Это снижает риск, что она спрячёт важную деталь в длинном пересказе.
Для примера:
{
"тема": "оплата",
"подтема": "не прошёл платёж",
"срочность": 0.82,
"срок": "сегодня до 18:00",
"нужен_специалист": true,
"краткое_резюме": "Клиент сообщает о повторном отказе платежа и просит проверить статус заказа",
"следующий_шаг": "Проверить платёж и запросить идентификатор операции"
}
Число 0.82 здесь не является доказанной вероятностью. Это рабочий балл уверенности, который нужно сопоставить с правилами конкретного отдела. Если модель сомневается между двумя категориями, лучше сохранить обе версии и отправить письмо на дополнительную проверку, чем маскировать неопределённость уверенным тоном.
В статье о промптинге для нейросетей подробно разобраны ограничения, формат ответа и проверка результата. Для сортировки писем эти элементы особенно полезны: без них модель легко смешивает тему сообщения с желаемым решением.
Как настроить классификацию тем
Надёжная классификация начинается с 6–8 рабочих категорий, а не с десятков почти одинаковых ярлыков. Категории должны отражать действие команды: «оплата», «доставка», «документы», «техническая проблема», «коммерческий запрос», «жалоба».
Я формулирую для каждой категории четыре параметра: определение, положительные признаки, похожие исключения и требуемое действие. Например, «оплата» означает вопрос о списании, счёте, возврате или подтверждении платежа. Письмо о продлении договора не относится к этой группе, даже если в нём упомянута сумма.
На качество разбора сильно влияет граница между темой и намерением. Тема отвечает на вопрос «о чём письмо», а намерение показывает, что требуется сделать. Сообщение «Не могу войти после оплаты» имеет тему «доступ» или «платёж», а намерение «проверить состояние учётной записи и операции». Я обычно сохраняю оба поля, потому что по одному ярлыку трудно построить дальнейшую маршрутизацию.
Полезный шаблон запроса выглядит так:
Ты классифицируешь входящие письма.
Выбери одну основную тему из списка: оплата, доставка, документы, доступ, жалоба, продажа.
Если данных недостаточно, укажи «нужна проверка».
Отдельно выдели намерение отправителя, срок и факты, которые подтверждают выбор.
Не придумывай номер заказа, дату, сумму или обещание сотрудника.
Верни результат в заданных полях, без дополнительного текста.
Для каждой категории я добавляю 2–4 обезличенных примера, но не превращаю инструкцию в архив писем. Избыточный набор образцов увеличивает объём запроса и может закрепить случайные формулировки вместо сути. После запуска полезно вручную проверить 30–50 сообщений из разных дней, включая короткие письма, цепочки с цитатами и обращения с несколькими вопросами.
В материале о внедрении нейросетей в рабочие процессы я советую начинать с одного повторяемого процесса. Для почты это может быть классификация обращений без автоматической отправки ответа. Такой старт даёт понятную точку контроля.
Как выделять срочные обращения
Срочность лучше определять по 3 группам сигналов: указанному сроку, возможному ущербу и словам о текущей блокировке. Одного восклицательного знака или заглавных букв недостаточно, поскольку эмоциональный тон не всегда означает реальный риск.
Я разделяю письма на три уровня:
| Уровень | Признаки | Действие | Рекомендуемый срок реакции |
|---|---|---|---|
| Высокий | остановлена оплата, заблокирован доступ, указан срок сегодня | передать ответственному сотруднику и проверить факты | до 30 минут |
| Средний | требуется ответ в течение 1–2 рабочих дней, есть риск задержки | поставить задачу в обычную очередь | в течение рабочего дня |
| Низкий | общий вопрос, просьба прислать справочную информацию | подготовить ответ по шаблону | до 2 рабочих дней |
Это не универсальные нормативы, а пример настройки. В одном отделе реакция за 30 минут может быть обязательной, в другом достаточно 4 часов. Правила нужно связать с реальным регламентом, числом сотрудников и последствиями задержки.
Для вычисления рабочего балла можно использовать простую схему. Указанный срок получает вес 0,4, блокирующее событие 0,35, финансовый или договорный риск 0,15, эмоциональные признаки 0,1. Сумма выше 0,75 отправляет письмо в срочную очередь, диапазон от 0,45 до 0,75 требует проверки, меньший балл остаётся в обычном потоке. Это не математическая истина, а прозрачная настройка, которую легко обсудить с руководителем поддержки.
Гипотетический пример: письмо с фразой «доступ заблокирован», сроком «сегодня до 16:00» и номером заявки получает высокий приоритет из-за двух независимых сигналов. Если в сообщении есть только «ответьте поскорее», модель должна вернуть среднюю срочность или запросить проверку, а не отправлять письмо в аварийную очередь.
Особенно опасны цепочки, где старое срочное событие уже решено. Перед классификацией нужно отделять новый текст от цитат предыдущих сообщений. Иначе модель увидит фразу «платёж заблокирован» в истории переписки и ошибочно повысит приоритет закрытого вопроса.
Как подготовить черновик ответа
Хороший черновик состоит из 5 блоков: признание запроса, краткий ответ, известные факты, следующий шаг и уточняющий вопрос. Нейросеть должна работать с данными письма, а не заполнять пропуски догадками.
Я задаю модели жёсткие границы:
- Не обещать срок, скидку, возврат или действие, если этого нет во входных данных.
- Не повторять персональные данные сверх необходимого объёма.
- Отмечать неизвестные поля специальной пометкой, например «нужно уточнить».
- Сохранять нейтральный тон при жалобах и не спорить с оценками отправителя.
- Завершать письмо одним понятным следующим шагом.
Для поддержки ответ может выглядеть так: «Я проверил содержание обращения. По данным письма, проблема связана с повторным отказом платежа. Чтобы продолжить проверку, пришлите время операции и последние 4 цифры способа оплаты. После этого специалист сверит статус транзакции». Такой текст не заявляет о выполненной проверке, если она фактически не проводилась.
Для продаж задача другая. Модель извлекает отрасль, размер запроса, интересующий продукт и предполагаемый срок решения, но не назначает цену без утверждённого прайс-листа. Для офис-менеджера важнее выделить дату встречи, участников, документы и вопрос, который ждёт ответа.
Перед отправкой я проверяю 4 вещи: совпадает ли имя адресата, сохранены ли числа и даты, есть ли подтверждение каждого обещания, понятно ли следующее действие. В письмах с оплатой, договорами и персональными данными автоматическая публикация ответа особенно рискованна. Нужен сотрудник, который видит исходное письмо и может изменить черновик.
В разборе повседневных задач с нейросетями есть похожий принцип: модель ускоряет подготовку результата, а человек оставляет за собой решение там, где цена ошибки высока.
Как встроить сортировку в рабочий процесс
Начинать стоит с 4 измерений: точности темы, точности срочности, доли принятых черновиков и времени до первого ответа. Эти показатели связывают качество модели с результатом отдела, а не с субъективным ощущением «ответы стали лучше».
Процесс можно разложить на последовательность:
- Получить письмо и убрать повторяющиеся цитаты.
- Выделить тему, намерение, срок, сущности и риск.
- Направить результат в подходящую очередь.
- Создать черновик только для разрешённых категорий.
- Передать письмо сотруднику и сохранить исправления для последующего анализа.
На старте я оставляю автоматической системе лишь разбор и подготовку. Отправка остаётся за человеком. Через 7 дней собираю ошибки по типам: неверная тема, пропущенный срок, выдуманный факт, слишком резкий тон, неправильное действие. После этого меняю инструкции или список категорий, а не просто повышаю требовательность модели.
Удобная метрика точности темы считается так: число правильно классифицированных писем делится на число проверенных писем. Для срочности полезнее отдельно считать пропущенные срочные обращения, потому что ошибка такого типа дороже, чем лишняя проверка обычного письма. Если из 100 проверенных сообщений 8 срочных, пропуск 2 из них означает 25% пропущенных срочных кейсов, даже при высокой общей точности.
Модельный кейс: компания из сферы логистики, около 200 сотрудников, может разделить входящие сообщения на запросы о доставке, оплате, документах и претензиях. На первой неделе команда проверяет 40 писем в день, фиксирует неверные маршруты и запрещает автоматическую отправку. Числа в этом сценарии нужны для планирования пилота, а не для заявления о гарантированном результате.
В SoftChat доступны веб-чат, потоковая выдача ответа и переключение моделей в рамках разговора. Я могу использовать такой формат для сравнения двух вариантов инструкции на обезличенном тексте письма, затем перенести проверенный шаблон в почтовый процесс. Сам чат не следует выдавать за готовую почтовую интеграцию: в каталоге продукта такой функции нет.
Какие ошибки ломают сценарий
Чаще всего процесс теряет качество из-за 5 ошибок: слишком широких категорий, отсутствия формата, смешения цитат с новым текстом, неподтверждённых обещаний и отсутствия журнала проверок. Каждую ошибку можно обнаружить на небольшом тестовом наборе до запуска.
Первая ошибка, просьба «распредели письма по важности», оставляет модели слишком много свободы. Вторая, длинный список из 25 ярлыков, создаёт пересечения. Третья, отсутствие поля «основание решения», не позволяет понять, почему письмо получило высокий приоритет.
Я добавляю в результат поле «цитата-основание» длиной до 200 символов. Оно показывает фрагмент, на котором построено решение, но не заменяет чтение исходного сообщения. Для персональных данных лучше ограничить этот фрагмент и хранить полный текст по правилам организации.
Полезно проводить две проверки. Сначала тестировать очевидные письма, затем пограничные: короткое «срочно перезвоните», цепочку из 10 сообщений, письмо с двумя темами и обращение без темы. Именно пограничные случаи показывают, где инструкция требует уточнения.
Регулярно пересматривайте словарь категорий. Если за месяц появляется 60 писем о новой услуге, старый ярлык может перестать помогать маршрутизации. При этом новое название должно иметь понятное действие, иначе классификация станет декоративной.
Мой рабочий вывод
Для сортировки писем достаточно начать с 1 категории, 1 набора правил и 1 недели проверки, а затем расширять процесс по данным ошибок. Нейросеть хорошо справляется с повторяемым разбором, если ей задать поля, признаки срочности и запрет на выдумывание фактов.
На вашем месте я бы сначала отделил письма поддержки от продаж, настроил 6 базовых тем и оставил отправку за специалистом. После проверки 30–50 сообщений можно оценить пропуски срочных обращений и понять, нужен ли новый ярлык. Такой порядок сохраняет управляемость: модель ускоряет подготовку, а ответственность за обещания и решения остаётся у команды.