ИИ для обработки писем: классификация и черновики в 2026
Разбор входящих писем без хаоса: как разделить обращения по темам, найти срочные случаи и подготовить черновик, который сотрудник проверит перед отправкой.
Почта и поддержка замедляются не из-за одного сложного письма. Задержки создают десятки повторяющихся действий: прочитать тему, найти намерение клиента, извлечь номер заказа, определить срок ответа, выбрать шаблон и проверить факты. Нейросеть может пройти этот маршрут за один запрос, но качество зависит от правил, примеров и контроля человека. В SoftChat для проверки формулировок удобно использовать веб-чат с переключением моделей в рамках разговора и потоковой выдачей ответа. При этом саму рабочую классификацию нужно проектировать отдельно, с понятными полями и условиями эскалации.
Что именно делает ИИ с письмом
ИИ превращает письмо в набор из 4–6 структурированных признаков: тему, намерение, срочность, тональность, извлечённые данные и рекомендуемое действие. Такой результат полезнее длинного пересказа, потому что его можно проверить по отдельным полям.
Сначала модель отделяет тему от намерения. Письмо может относиться к оплате, но содержать просьбу о возврате. Сообщение о доставке может быть вопросом о сроке, жалобой или запросом на изменение адреса. Если смешать эти уровни, оператор получит слишком общий ярлык и выберет неподходящий ответ.
Я обычно задаю классификатору фиксированный набор классов. Для поддержки подойдут, например, «оплата», «доставка», «техническая проблема», «возврат», «претензия» и «другое». Шесть классов легче контролировать, чем 20 похожих категорий. Если обращение относится к двум темам, модель должна вернуть основную тему и вторичную, а не выбирать случайный ярлык.
Отдельное поле нужно для намерения. В нём стоит хранить короткую формулировку действия: «узнать статус», «изменить заказ», «оспорить списание», «получить инструкцию». Поле не должно повторять письмо целиком. Достаточно 3–8 слов и ссылки на конкретный объект, например заказ, подписку или дату платежа.
Полезно просить модель возвращать результат в JSON с заранее заданными ключами. Для каждого письма можно получить такую запись:
{
"тема": "оплата",
"намерение": "уточнить статус возврата",
"срочность": "высокая",
"данные": ["дата операции", "сумма", "номер заказа"],
"действие": "передать сотруднику финансовой поддержки"
}
Если формат нарушен, запись отправляется на ручную проверку. Если формат соблюдён, оператор видит не сплошной абзац, а компактную карточку решения. Подробно о проверке результатов генерации текста я писал в материале о задачах нейросети и контроле качества ответа.
Как находить срочные обращения
Срочность лучше определять по 3 группам сигналов: риску для клиента, ограниченному сроку и повторным попыткам связаться с поддержкой. Одного эмоционального слова вроде «срочно» недостаточно.
В первую группу входят блокировка доступа, повторное списание, невозможность получить оплаченный товар и подозрение на ошибочную операцию. Во вторую попадают фразы «до 18:00», «сегодня последний день», «рейс утром» или «нужно подтвердить до пятницы». Третья группа появляется, когда клиент отправил 2–3 письма по одному вопросу или уже получил автоматический ответ без решения.
Я разделяю приоритет и тональность. Раздражённое письмо может касаться обычного вопроса, а нейтральная фраза о списании денег требует быстрой проверки. В рабочей схеме полезны 4 уровня: критический, высокий, стандартный и информационный. Для каждого уровня заранее задаётся срок реакции. Например, критический случай передаётся дежурному сотруднику сразу, высокий попадает в очередь текущей смены, стандартный обрабатывается в общем порядке.
Порог уверенности модели тоже должен влиять на маршрут. Как практический ориентир можно отправлять на ручную проверку все записи с уверенностью ниже 0,80. Число 0,80 не является законом для любой команды. Его проверяют на размеченной выборке из 100–200 писем и меняют, если ошибок слишком много или ручная очередь разрастается.
Условный пример: письмо содержит спокойное описание невозможности войти в аккаунт перед оплатой, но в тексте есть срок «до 17:00». Система должна учесть и техническую тему, и ограниченное время, а оператору показать причину высокого приоритета. Такой подход снижает риск, когда модель ориентируется только на эмоциональную окраску.
Как строится черновик ответа
Хороший черновик проходит 2 проверки до отправки: фактическую и логическую. Сначала нужно убедиться, что модель не добавила сведения, которых нет в письме или справочной базе, затем проверить, отвечает ли текст на реальную просьбу клиента.
Без правил модель часто пишет вежливый, но бесполезный абзац. Фраза «ваш вопрос принят в работу» не объясняет, что произошло дальше. Черновик должен назвать распознанную проблему, перечислить подтверждённые факты и предложить следующий шаг.
Рабочая структура обычно выглядит так:
- Короткое обращение к клиенту.
- Подтверждение сути вопроса без пересказа на полстраницы.
- Действие поддержки, например проверка операции или передача специалисту.
- Срок следующего сообщения, если его можно назвать.
- Уточняющий вопрос, когда не хватает номера заказа, даты или другого поля.
Условный пример: клиент сообщает о списании за подписку и просит проверить возврат. Черновик может подтвердить факт обращения, назвать найденный объект «платёж за подписку», попросить номер операции и объяснить, что после проверки сотрудник сообщит доступные варианты. Здесь нет выдуманной суммы, даты или обещания результата.
Для запроса полезно добавить запреты. Модель не должна придумывать компенсацию, ссылаться на внутренние правила без подтверждения, обещать возврат до проверки и менять юридический смысл обращения. Если письмо содержит персональные данные, в черновик стоит переносить только сведения, нужные для ответа.
Практика формулировки запросов для нейросетей помогает настроить такие инструкции точнее. Для письма поддержки лучше дать модели роль, формат результата, список разрешённых действий и 2–3 примера пограничных случаев, чем просить «ответить вежливо».
Как внедрить классификацию без резкого перехода
Безопасный запуск занимает 4 этапа: собрать выборку, разметить классы, протестировать рекомендации и подключить ручное подтверждение. Автоматическую отправку писем разумно отложить до момента, когда команда увидит устойчивое качество на реальных обращениях.
Я начинаю с 100–200 писем за один период, например за 2 недели. В выборке должны быть короткие вопросы, длинные цепочки переписки, вложения, повторные обращения и сообщения без ясной темы. Для каждого письма сотрудник вручную отмечает правильный класс, приоритет, намерение и обязательные данные.
Затем создаётся таблица ошибок. Отдельно считаются случаи, когда письмо попало не в тот класс, срочное обращение получило обычный приоритет, а в черновике появились неподтверждённые детали. Если из 50 писем по оплате 8 получили ярлык «техническая проблема», проблему нужно искать в описании классов или в примерах, а не маскировать дополнительным шаблоном.
На пилоте модель не отправляет письмо клиенту. Она предлагает класс, объясняет признаки срочности и создаёт черновик. Сотрудник выбирает «принять», «исправить» или «отправить на разбор». Эти 3 действия дают материал для следующей настройки.
Для команд, которые только планируют автоматизацию, полезен отдельный разбор внедрения нейросетей в рабочие процессы. В нём логика строится вокруг конкретной операции и измеримого результата, а не вокруг общего желания «добавить ИИ».
Какой подход выбрать для почты и поддержки
Для небольшого потока подходит ручная сортировка с подсказками, для повторяющихся обращений часто удобнее связка правил и нейросети. Полностью автоматический маршрут оправдан лишь там, где ошибка не создаёт финансового, правового или репутационного риска.
| Подход | Что происходит на первом шаге | Сильная сторона | Ограничение |
|---|---|---|---|
| Ручная обработка | Сотрудник читает письмо и выбирает действие | Понятная ответственность | Скорость падает при росте очереди |
| Правила и ключевые слова | Система ищет заданные фразы и признаки | Легко объяснить результат | Плохо работает с косвенными формулировками |
| Нейросетевой классификатор | Модель определяет тему, намерение и приоритет | Понимает вариативный язык | Может ошибиться на редком или двусмысленном письме |
| Гибридная схема | Правила ловят критические сигналы, модель разбирает остальное | Риски распределены между двумя слоями | Нужны тесты, разметка и поддержка правил |
Гибридный вариант часто разумен для обращений с платежами, блокировками и сроками. Жёсткое правило может сразу поднять письмо со словами «повторное списание» или «доступ заблокирован», а модель разберёт контекст и подготовит объяснение для сотрудника.
Сравнивать подходы нужно по 4 показателям: доля правильно определённых классов, доля пропущенных срочных писем, время до первого ответа и количество правок в черновике. Среднее время само по себе мало что говорит. Если ответ стал быстрее на 10 минут, но выросло число повторных обращений, схема не улучшила процесс.
Для бытовых запросов и личной почты можно применять более простую логику. Материал о повседневных задачах для нейросетей и чат-ботов показывает, как отделять безопасную рутину от действий, где требуется решение человека.
Как контролировать ошибки после запуска
Контроль должен включать 3 слоя: выборочную проверку, журнал исправлений и разбор критических ошибок. Даже при стабильном результате стоит сохранять возможность быстро отключить автоматическую рекомендацию для отдельной категории.
Каждую неделю можно проверять 30–50 писем из разных классов. В журнале фиксируются исходная рекомендация, правка сотрудника, причина изменения и итоговый ответ. Через месяц станет видно, где модель путает «возврат» и «отмена», где не замечает дату, а где проблема появляется из-за слишком широкого класса.
Критические ошибки рассматриваются отдельно. К ним относятся пропуск сообщения о повторном списании, неверный срок, обещание компенсации без основания и раскрытие лишних персональных данных. Для таких случаев нужен маршрут эскалации: письмо не уходит автоматически, а попадает к ответственному сотруднику.
Хорошая проверка оценивает весь процесс, а не красоту текста. Черновик может звучать естественно и при этом не отвечать на вопрос клиента. Поэтому я смотрю на наличие конкретного действия, корректность извлечённых полей и понятность следующего шага.
Как принять решение после обновления процесса
Для старта достаточно одного класса обращений, 100 размеченных писем и режима обязательной проверки человеком. На вашем месте я бы выбрал повторяющуюся тему с понятным результатом, например вопросы о статусе заказа или запросы на инструкцию.
Сначала стоит измерить исходную точку: сколько писем приходит за день, сколько минут уходит на первичную сортировку, сколько черновиков возвращается на правку. Затем задаются 4 класса, порог уверенности и правило для срочных слов. Через 2 недели сравниваются скорость, ошибки и число повторных обращений.
Если качество держится, можно расширить перечень тем. Если растёт число исправлений, нужно упростить классы или добавить примеры, а не давать модели больше свободы. Такой порядок сохраняет контроль и показывает, где нейросеть действительно снимает ручную нагрузку.