Как ИИ классифицирует обращения: срочность и ответ

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

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

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

Как устроена классификация обращений

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

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

Затем выбирается одна основная категория. Для службы поддержки подойдут метки «оплата», «доставка», «доступ», «возврат», «техническая ошибка». Для отдела продаж набор будет другим: «новая заявка», «уточнение цены», «демонстрация», «партнёрство». Число категорий лучше ограничить на старте 6–10 позициями. Слишком широкий список в 30 меток повышает вероятность путаницы между близкими темами.

Третий слой, приоритет. В нём модель сопоставляет текст с условиями: угроза блокировки, повторное списание, нарушение срока, массовая ошибка или обычный вопрос. Четвёртый слой переводит вывод в рабочий формат. Вместо абзаца на 500 слов оператору нужна короткая карточка с меткой, объяснением и рекомендуемым действием.

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

Как выделить срочные обращения

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

Я предлагаю разделять приоритеты на 4 уровня:

1. Критический. Есть риск финансового ущерба, блокировки доступа или массового сбоя. Такое письмо сразу передаётся ответственному сотруднику.
2. Высокий. Клиент ждёт решения в течение рабочего дня, а задержка может привести к отмене заказа или жалобе.
3. Обычный. Вопрос требует ответа, но не связан с текущей потерей денег или доступа.
4. Низкий. Просьба о справочной информации, инструкции или дополнительном материале.

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

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

Полезно хранить причину оценки в отдельном поле. Формулировка «высокий приоритет, потому что упомянут повторный платёж и срок реакции 15 минут» проверяется лучше, чем число без объяснения. При аудите 100 писем такой комментарий помогает быстро найти ошибочные правила.

Как определить тему письма

Тему письма лучше выбирать из фиксированного справочника на 8–12 меток, а дополнительные намерения хранить отдельно. Это снижает путаницу между предметом обращения и действием, которого ждёт клиент.

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

Я использую двухуровневую схему:

Число уверенности не следует воспринимать как доказанную вероятность. Это рабочий сигнал для маршрутизации. Порог 0,80 можно использовать как стартовую настройку, а затем проверить его на размеченной выборке. Если из 100 писем 12 уходят не в тот отдел, проблема может находиться в справочнике, примерах или неоднозначных правилах, а не в самой модели.

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

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

Как предложить ответ клиенту

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

Пример структуры:

1. Обратиться к клиенту без выдуманного имени.
2. Коротко повторить предмет обращения.
3. Указать факт, который есть в исходном письме или базе инструкций.
4. Сказать, какое действие выполнит сотрудник или что нужно предоставить.
5. Завершить нейтральной фразой без обещания точного результата, если его нельзя проверить.

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

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

При генерации ответа я задаю ограничение длины. Для первичного письма достаточно 80–120 слов, для внутренней заметки часто хватает 30–60 слов. Если модель выдаёт 400 слов, оператор тратит время на повторное редактирование. Сначала нужен короткий черновик, затем человек решает, какие детали добавить.

Чем отличаются сценарии поддержки, продаж и бэк-офиса

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

Модельный кейс: компания из сферы логистики, около 200 сотрудников, получает 600 писем в неделю. Для неё разумно начать с 8 тематических меток и 4 уровней приоритета, а ответы оставлять на ручное подтверждение. При таком объёме даже сокращение первичной сортировки на 2 минуты для каждого письма высвобождает до 20 часов в неделю, но это расчёт сценария, а не обещание результата.

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

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

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

Качество проверяется на размеченной выборке минимум из 50 обращений, а после запуска контроль повторяется по группам риска. Одного впечатления от нескольких удачных ответов недостаточно.

Я разделяю проверку на 4 показателя:

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

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

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

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

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

Я бы начинал с одной очереди, 6–8 меток и ручного подтверждения каждого черновика в течение первой недели. Это даёт достаточно данных для настройки, не заставляя перестраивать весь процесс сразу.

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

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

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