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

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

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

Разбор обращения по шагамОт входящего сообщения к проверяемому черновику1Поток писемтекст, дата, контекст2Срочностьприоритет и причина3Темаметки и резюме4ЧерновикпроверкаСотрудник подтверждает факты и следующий шагСпорные сообщения не отправляются без проверки
Инфографика

Что именно делает нейросеть с обращением

Схематичная сцена сортировки обращений по срочности и теме

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

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

Базовая схема выглядит так:

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

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

В статье о генерации текста и проверке результата этот принцип разобран шире: черновик оценивают по фактам, структуре и соответствию задаче, а не по гладкости формулировок.

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

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

Я задаю модели отдельные правила для каждого уровня. Слово «срочно» само по себе не доказывает критичность, а фраза «не могу войти уже 2 часа» может требовать быстрого ответа даже без эмоциональной лексики. Модель должна объяснить решение короткой причиной: «доступ заблокирован», «указан платёжный риск» или «запрошен ответ до 14:00».

Для уверенности удобно использовать шкалу от 0 до 1. При значении от 0,85 можно отправлять обращение в обычную автоматизированную очередь, диапазон от 0,60 до 0,84 лучше направлять на выборочную проверку, а значение ниже 0,60 считать спорным. Это рабочая настройка, а не закон: пороги нужно пересматривать по журналу ошибок.

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

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

Как выделить тему и маршрут обращения

Для первой версии достаточно 6–8 тем и отдельной метки «нужно уточнение». Крупный список из 30 категорий на старте обычно ухудшает границы между похожими вопросами.

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

Здесь полезна многометочная классификация. Письмо «деньги списали, но подписка не открылась» относится сразу к оплате и доступу. Если оставить одну метку, оператор попадёт в очередь только одного отдела и потеряет часть контекста.

Гипотетический пример: из 200 входящих сообщений 70 относятся к оплате, 45 к доступу, 35 к техническим ошибкам, а оставшиеся 50 требуют уточнения темы. Эти числа показывают способ разложить поток по корзинам, а не статистику конкретной организации.

Формат результата лучше зафиксировать заранее:

Срочность: обычная
Уверенность: 0,88
Тема: возврат, платёж
Резюме: клиент просит вернуть оплату за заказ от 12 мая
Следующий шаг: проверить статус возврата и срок зачисления
Недостающие данные: номер заказа

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

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

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

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

В запросе я задаю модели роль, входные поля и ограничения. Например:

Проанализируй обращение по полям «срочность», «тема», «факты», «недостающие данные». Составь черновик до 120 слов. Используй только сведения из сообщения и переданной базы правил. Не обещай возврат, срок или компенсацию, если такого решения нет во входных данных. Если информации мало, задай один точный вопрос.

Ограничение в 120 слов задаёт размер ответа, но не гарантирует качество. Поэтому рядом с текстом я прошу вывести список использованных фактов. Оператор видит, на чём построена формулировка, и быстрее замечает подмену причины или даты.

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

Если в базе правил указано, что возврат рассматривается до 10 рабочих дней, модель может использовать этот срок. Если такого правила нет, корректная фраза звучит иначе: «Срок нужно уточнить по номеру заказа». Для поддержки это полезнее красивого, но неподтверждённого ответа.

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

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

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

Я бы разделил контроль на три проверки. Сначала сотрудник сверяет тему и приоритет с исходным сообщением. Затем проверяет даты, суммы, номера и обещания. В конце оценивает тон и наличие конкретного следующего шага.

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

Модельный кейс: если из 60 проверенных черновиков 9 требуют исправления суммы или срока, показатель исправлений равен 15 процентам. До внедрения такого процесса я фиксирую исходное значение, а затем сравниваю его с результатом через 2–4 недели.

Для контроля спорных ответов полезен журнал с 5 полями: исходный текст, предсказанная тема, уверенность, решение сотрудника и причина исправления. Уже после 50–100 записей становится видно, где модель путает соседние категории или слишком часто повышает приоритет.

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

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

Подход Когда использовать Плюсы Ограничение
Только правила Небольшой поток и 5–10 устойчивых формулировок Легко объяснить решение, быстро изменить условие Плохо работает с синонимами и длинным контекстом
Только нейросеть Разнообразные письма, свободный язык, несколько тем Понимает смысл и собирает резюме Может ошибиться в датах, отрицаниях и редких случаях
Гибридная схема Поддержка, продажи и операционные очереди Сочетает смысловой разбор с жёсткими ограничениями Нужны журнал ошибок и регулярная настройка

Правила особенно полезны для словарей и запретов. Например, упоминание списания средств можно отправить на проверку, а просьбу удалить данные не следует превращать в готовое обещание без подтверждённой процедуры.

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

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

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

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

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

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

Модельный кейс: в выборке из 300 сообщений 240 получили правильную основную тему, а из 40 действительно срочных обращений система нашла 36. Тогда точность основной темы равна 80 процентам, а полнота срочных обращений составляет 90 процентов. Это расчёт для иллюстрации методики, не отчёт о работе конкретной компании.

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

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

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

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

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