Как ИИ сортирует письма: срочность и черновик ответа

Стендфирст: Показываю на понятной схеме, как нейросеть превращает поток писем в тему, оценку срочности и проверяемый черновик ответа.

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

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

Что именно делает ИИ с входящим письмом

Обычно ИИ проходит 5 операций: читает содержание, определяет тему, оценивает срочность, извлекает данные и формирует черновик. На выходе получается структурированная карточка, которую проще проверить за 30–60 секунд, чем перечитывать весь диалог.

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

Затем задаются категории. Для отдела поддержки достаточно начать с 6 меток: ошибка, оплата, доставка, возврат, консультация и претензия. Для продаж набор будет другим: новый запрос, действующий клиент, повторный контакт, коммерческое предложение и отказ. Категории должны различаться по смыслу, иначе модель станет колебаться между соседними вариантами.

Срочность удобно хранить по шкале P0–P3. P0 означает остановку критичного процесса, P1, риск потери денег или клиента в ближайшие часы, P2, обычную задачу с установленным сроком, P3, информационный вопрос без дедлайна. Эти обозначения не являются универсальным стандартом, поэтому их нужно согласовать внутри команды.

В итоговой карточке полезно иметь 5 полей:

1. тема обращения;
2. уровень срочности;
3. причина такой оценки;
4. извлечённые факты, например номер заказа или дату платежа;
5. черновик следующего ответа.

Модельный кейс: в условном почтовом потоке из 70 сообщений 18 писем относятся к оплате, 12 содержат признаки срочности, а в 9 письмах не хватает номера заказа. В такой разметке сотрудник сначала открывает 12 приоритетных сообщений, затем возвращается к 9 письмам, где нужно запросить уточнение.

Как задать классификацию без расплывчатых ответов

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

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

Я не смешиваю в одной метке тему и настроение. «Разозлённый клиент» описывает тон письма, а «возврат» описывает задачу. Если объединить эти признаки, сообщение о спокойном возврате и эмоциональная претензия попадут в разные классы, хотя оператору может понадобиться один и тот же процесс.

Полезная инструкция должна требовать объяснение в одной фразе. Формулировка «срочно, потому что клиент написал резко» слабее, чем «P1, потому что указан дедлайн сегодня до 16:00 и при задержке остановится отгрузка». Во втором варианте виден проверяемый признак, а не впечатление модели.

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

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

Как определить, действительно ли письмо срочное

Срочность удобно оценивать по 4 признакам: дедлайну, последствию задержки, стадии процесса и прямой просьбе о реакции. Резкий тон сам по себе не означает уровень P0 или P1.

Первый признак, дата или час. Фразы «до 15:00», «сегодня», «до закрытия месяца» дают модели ориентир. Второй признак, последствие. «Не могу войти» может быть обычным вопросом, а может означать остановку кассы в магазине. Третий признак, роль обращения в процессе: согласование платежа обычно имеет другой приоритет, чем просьба прислать справочную информацию. Четвёртый признак, действие, которого ждут от получателя.

Я советую разделить результат на приоритет и уверенность. Приоритет отвечает на вопрос «что делать первым», а уверенность показывает, нужна ли ручная проверка. Это разные параметры. Письмо может выглядеть срочным, но иметь низкую уверенность, если в нём нет даты, номера заказа и описания последствий.

Полезно заранее определить правила эскалации. Например, если найдено слово «заблокировано», указана сумма платежа или упомянут судебный срок, письмо отправляется на ручной просмотр независимо от общей оценки. Список таких признаков обычно занимает 8–15 пунктов и хранится рядом с инструкцией, чтобы его можно было обновить без переписывания всего процесса.

В спорных случаях модель должна объяснять решение коротко. Если причина не помещается в 1 предложение, классификация, вероятно, опирается на слишком много догадок. Я предпочитаю видеть цитируемый фрагмент письма, дату, сумму или название операции, а не общий вывод вроде «сообщение кажется важным».

Как подготовить черновик ответа

Рабочий черновик состоит из 4 блоков: признание запроса, найденный факт, следующий шаг и уточняющий вопрос. Такой каркас снижает риск вежливого, но бесполезного ответа.

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

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

Я задаю ограничение по длине, например до 120 слов, и прошу не обещать результат без подтверждения. Фразы «мы уже исправили», «деньги вернутся завтра» и «вопрос передан специалисту» допустимы лишь тогда, когда это следует из исходных данных или из инструкции сотрудника.

Отдельная проверка нужна для вложений. Модель может увидеть упоминание файла, но не всегда располагает его содержимым. Поэтому в карточке лучше разделять поля «факт из текста» и «требует проверки во вложении». Наличие названия файла не доказывает, что документ прочитан.

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

Какой подход выбрать для первичной обработки

Для первичного разбора подходят 3 режима: ручная сортировка, правила по ключевым словам и нейросетевой анализ с контролем человека. На практике я выбираю режим по объёму писем, числу категорий и цене ошибки.

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

Я не заменяю правила нейросетью целиком. Жёсткие ограничения лучше оставить фильтрам, а интерпретацию свободного текста передать модели. Такое разделение упрощает разбор ошибок: видно, сбился формальный фильтр или неверно понят контекст.

Практика внедрения в рабочие процессы с распределением ролей и контрольными точками описана в статье как внедрить нейросети в рабочие процессы и личную продуктивность. Для почты особенно полезно заранее назначить владельца категорий и человека, который разбирает спорные письма.

Как проверить качество до запуска

Минимальный набор проверки включает 100 обезличенных писем, 5–7 категорий и отдельную выборку срочных сообщений. Такой тест выявляет систематические ошибки раньше, чем классификация попадёт в рабочую очередь.

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

Для каждой категории фиксируются истинная метка, ответ модели и причина расхождения. Затем считаются точность и полнота. Точность равна доле правильных срабатываний среди всех писем, отнесённых к категории. Полнота показывает, какую долю всех реальных писем категории удалось найти. Для срочных обращений я обычно ставлю полноту выше удобства, потому что пропуск дедлайна опаснее лишней ручной проверки.

Для примера: если система пометила 20 писем как срочные, 16 из них действительно требуют быстрого действия, точность равна 80%. Если всего в выборке было 25 срочных сообщений, полнота составит 64%, поскольку 9 таких писем остались без нужной метки. Эти 2 числа показывают разные стороны качества.

После теста я составляю список ошибок по типам: перепутана тема, пропущен срок, неверно извлечена сумма, добавлен факт, которого не было, или ответ получился слишком категоричным. Затем меняю одну часть инструкции и повторяю проверку на той же выборке. Одновременная замена 5 правил не позволяет понять, что именно помогло.

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

Как проверить такой запрос в SoftChat

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

Я создаю отдельный разговор для одной версии правил и вставляю 10–20 тестовых писем с одинаковым форматом запроса. Затем меняю модель внутри разговора и сравниваю не впечатление от текста, а 4 поля: тема, срочность, причина и черновик. Потоковая выдача помогает увидеть, где ответ начинает уходить от заданной структуры, ещё до его завершения.

В исходных примерах я заменяю имена, телефоны, адреса, номера карт и реальные идентификаторы заказов. Номер договора можно заменить на «ДОГОВОР-001», а сумму, если она не нужна для проверки, округлить или удалить. Смысл теста сохраняется, а лишние персональные данные не попадают в текст запроса.

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

Какой порядок внедрения я бы выбрал

Я бы разделил внедрение на 2 этапа: сначала разметил бы входящие письма и проверил классификацию, затем добавил бы черновики под обязательным просмотром сотрудника. Автоматическую отправку я бы не рассматривал, пока не накопится журнал ошибок по темам и срочности.

В первую неделю достаточно выбрать 5–7 категорий, собрать 100 обезличенных писем и зафиксировать шкалу P0–P3. После теста стоит оставить ручную проверку для платежей, претензий, юридических сроков и сообщений без понятного контекста. Через 2–4 недели можно пересчитать точность и полноту на новых примерах.

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