Анализ тональности и сортировка обращений в 2026
Как превратить поток отзывов, писем и чатов в понятные очереди: жалобы, срочные инциденты, вопросы по оплате, запросы на функцию и нейтральный шум.
Когда входящих обращений мало, менеджер легко держит контекст в голове. После 50–100 сообщений в день начинается другая работа: одно и то же письмо читают несколько раз, срочная жалоба теряется между уточнениями, а продуктовая команда получает не причины недовольства, а набор случайных цитат. Я предпочитаю решать это не через героизм поддержки, а через простую схему: нормализовать текст, определить тональность, найти тему, присвоить приоритет и отправить обращение в нужную очередь.
Разбор 100 коротких отзывов вручную обычно занимает часы, если нужно не просто поставить метку «плохо» или «хорошо», а выделить причины: доставка, оплата, качество ответа, ошибка интерфейса, ожидание возврата. Нейросеть справляется с первичной классификацией быстрее, но ей нужна рамка. Без рамки она будет красиво пересказывать поток обращений, а не сортировать его для работы.
Что именно нужно классифицировать
Я начинаю не с выбора модели, а с карты решений. Для входящих обращений полезно разделить пять сущностей: тональность, намерение, тема проблемы, срочность и следующий шаг. Тональность отвечает на вопрос «какой эмоциональный знак у сообщения». Намерение показывает, что человек хочет сделать: пожаловаться, уточнить, отменить, вернуть деньги, попросить помощь. Тема проблемы связывает обращение с зоной ответственности. Срочность нужна для очереди. Следующий шаг превращает анализ в действие.
Условный пример: сообщение «Оплатил заказ вчера, чек пришёл, а доступ так и не появился» получает тональность «негативная», намерение «разобраться с оплатой», тему «доступ после платежа», срочность «высокая», следующий шаг «проверить платёж и статус аккаунта». Это лучше, чем одна метка «негатив», потому что менеджеру не нужно заново читать весь текст, чтобы понять маршрут.
Для первого запуска я обычно не советую делать 40 категорий. Десяти достаточно: оплата, доставка, возврат, доступ, ошибка интерфейса, качество товара или услуги, ожидание ответа, просьба о функции, благодарность, прочее. Категория «прочее» нужна обязательно. Если её нет, модель начнёт насильно раскладывать непонятные сообщения по соседним темам, и отчёт станет шумным.
Если команда ещё не описала повторяемые форматы сообщений, полезно сначала потренироваться на текстовых задачах. Хороший базовый подход описан в статье про нейросеть для генерации текста и проверку результата: там тот же принцип, сначала структура, потом черновик, потом проверка.
Какие модели использовать для тональности и сортировки
Для автоматической сортировки не всегда нужна самая тяжёлая языковая модель. Выбор зависит от длины обращений, качества текста, числа категорий и цены ошибки. Если сообщение короткое, вроде «где возврат», часто хватает правил и словарей. Если клиент пишет пять абзацев с сарказмом, вложенными условиями и историей переписки, лучше работает языковая модель с инструкцией и примерами.
| Подход | Где подходит | Что хорошо делает | Ограничение |
|---|---|---|---|
| Правила и ключевые слова | 5–15 стабильных тем, короткие фразы | Быстро ловит «возврат», «не работает», «оплата» | Плохо понимает сарказм и синонимы |
| Классическая модель классификации | Большой архив размеченных обращений | Дёшево обрабатывает поток после обучения | Нужна разметка, хотя бы сотни примеров на частые классы |
| Языковая модель с промптом | Разные форматы, мало разметки, быстрый запуск | Объясняет причину метки и выделяет детали | Требует строгого формата ответа и проверки |
| Векторный поиск по похожим обращениям | Повторяющиеся проблемы и база прошлых решений | Находит похожие случаи и типовые ответы | Не заменяет приоритет и тональность |
| Гибридная схема | Поддержка, продажи, продуктовые отзывы | Соединяет правила, модель и ручной аудит | Сложнее поддерживать, нужен владелец схемы |
Мой рабочий вариант для старта, гибрид. Сначала правила ловят очевидное: слова «не списывайте», «верните», «не могу войти», «ошибка 500». Затем языковая модель разбирает спорные сообщения и выдаёт JSON с полями. Потом отдельная проверка отсекает ответы, где нет обязательных полей или уверенность ниже выбранного порога.
Для промптов лучше не писать «проанализируй отзывы». Это слишком широко. Нужна инструкция с форматом, категориями и запретом придумывать детали. Если тема промптинга пока плавает, разберите базу в материале про правильную формулировку запросов для нейросетей, а потом вернитесь к классификатору.
Пошаговая настройка фильтрации без менеджера
Шаг 1. Соберите входной формат. Минимум полей: идентификатор обращения, канал, дата, текст, язык, источник, статус. Если есть оценка клиента, время ожидания или номер заказа, храните их отдельно. Не прячьте метаданные внутри текста, модели сложнее потом отделять факт от комментария.
Шаг 2. Очистите текст. Уберите подписи писем, повторяющиеся юридические хвосты, системные уведомления, лишние цитаты из предыдущей переписки. В чатах полезно склеивать 2–4 коротких сообщения одного человека в один фрагмент, если они пришли подряд в течение нескольких минут. Иначе фраза «и опять не работает» попадёт в анализ без причины.
Шаг 3. Опишите категории. Для каждой категории дайте 2–3 примера и 1 антипример. Для темы «оплата» примером будет «деньги списались, доступ не появился», антипримером, «сколько стоит тариф». Первое, проблема после платежа. Второе, вопрос до покупки.
Шаг 4. Задайте формат ответа. Я использую компактную схему: тональность, намерение, тема, срочность, уверенность, краткая_причина, очередь. Значение уверенности удобно держать в диапазоне от 0 до 1. Если уверенность ниже 0,7, обращение отправляется на ручную проверку. Это не магическое число, а стартовая настройка. После 200–300 проверенных обращений порог можно поднять или опустить.
Шаг 5. Настройте маршруты. Негатив по оплате с высокой срочностью идёт в первую линию поддержки или биллинг. Запрос на функцию с нейтральной тональностью уходит в продуктовый бэклог. Благодарности можно собирать отдельно, они помогают видеть, какие сценарии уже работают. Спам и нерелевантные сообщения помечаются, но не смешиваются с реальными жалобами.
Шаг 6. Добавьте журнал ошибок. Каждый раз, когда человек меняет метку, нужно сохранять старую метку, новую метку и причину исправления. Через неделю такой журнал покажет, где модель путает «возврат денег» и «возврат товара», где завышает срочность, а где не видит скрытый негатив.
Условный пример: за 5 минут можно прогнать 100 отзывов через подготовленный шаблон и получить таблицу с долями тем, если тексты уже собраны в одном файле и не требуют очистки. Но автоматизация сбора, дедупликация и проверка качества займут больше времени. Именно там обычно прячется основная работа, а не в самой классификации.
Как выглядит рабочий контур
Ниже схема, которую я бы заложил в первый релиз. Она простая, но в ней уже есть защита от слепой автоматизации: низкая уверенность и спорные классы не идут сразу в финальную очередь.
В реальной системе эту схему лучше не связывать с одним интерфейсом. Источники могут быть разными: форма на сайте, почта, виджет поддержки, магазин приложений, анкета после покупки. Главное, чтобы на вход классификатора попадал единый объект, а на выходе была одна схема полей. Тогда отчёт по неделе можно собрать без ручного сведения таблиц.
Проверка качества: что считать нормой
Автоматическая сортировка без проверки быстро портится. Я беру выборку из 100–200 обращений, размечаю её вручную и сравниваю с моделью. Смотрю не только общую точность, а ошибки по классам. Если модель верно распознаёт благодарности в 95 случаях из 100, но путает срочные жалобы по оплате, пользы мало. Для поддержки цена ошибки разная.
Условный пример: если из 40 негативных обращений по доступу модель пропустила 6, это повод менять категории или добавлять правило для слов «не могу войти», «доступ закрыт», «код не приходит». Если из 60 нейтральных вопросов 8 ошибочно стали срочными, очередь перегрузится, но клиентский риск ниже.
Я бы ввёл четыре проверки. Первая, наличие всех обязательных полей. Вторая, допустимые значения, чтобы вместо «очень плохая» не появлялось значение вне справочника. Третья, проверка уверенности. Четвёртая, аудит спорных тем раз в неделю. Когда команда переходит от эксперимента к процессу, пригодится материал про внедрение нейросетей в рабочие процессы, потому что там важны роли, регламент и цикл улучшения.
Где здесь помогает SoftChat
SoftChat не нужно превращать в систему тикетов, если ваша задача, спроектировать классификацию. Я использую чат как рабочее место для быстрой проверки схемы: даю 20–30 обезличенных обращений, прошу вернуть строгую таблицу, меняю категории и смотрю, где инструкция ломается. В веб-чате SoftChat можно переключать модели для конкретного разговора, а в настройках чата менять параметры вроде креативности и длины ответа. Для классификации я выбираю более сдержанный стиль и короткий ответ, потому что здесь нужна стабильность, а не литературная вариативность.
Когда схема промпта устоялась, её удобно держать как повторяемую заготовку. В SoftChat есть шаблоны промптов и сохранённые ассистенты, которые можно подключать к открытому чату. Это помогает разделить роли: один ассистент проверяет тональность, другой ищет причины жалоб, третий приводит итог к формату отчёта. Я не смешиваю эти задачи в одном длинном запросе, если от результата зависит очередь поддержки.
Для бытовых и разовых задач нейросеть можно использовать проще, без полноценного контура. Такой подход разобран в статье про нейросети и чат-боты для повседневных задач. В поддержке ситуация строже: нужен справочник категорий, лог исправлений, пороги уверенности и владелец качества.
Типовые ошибки настройки
Первая ошибка, просить модель сразу «найти инсайты». Инсайт появляется после нормальной разметки, а не вместо неё. Сначала пусть каждое обращение получит тему и тональность, затем уже можно считать доли и динамику.
Вторая ошибка, смешивать тональность и срочность. Фраза «спасибо, но доступ не появился» звучит вежливо, но по процессу может быть срочной. А сообщение «ужасный цвет кнопки» негативное, но не всегда требует реакции первой линии.
Третья ошибка, удалять ручную проверку слишком рано. Даже если модель хорошо прошла тест на 200 обращениях, новые акции, сбои, изменения тарифа и сезонные пики меняют лексику клиентов. Минимальный аудит раз в неделю дешевле, чем месяц неверной маршрутизации.
Четвёртая ошибка, строить категории под отделы, а не под причины обращения. Клиент не пишет «это вопрос второй линии». Он пишет «не могу войти после оплаты». Категория должна отражать проблему, а маршрут уже переводит её на язык команды.
Что бы я сделал на вашем месте
Я бы начал с одной очереди и 100–200 обезличенных обращений за последние недели. Сначала разметил бы 10 категорий, отдельно тональность и срочность. Затем собрал бы промпт, который возвращает строгий JSON или таблицу, и прогнал бы выборку дважды на разных настройках модели. После этого сравнил бы ошибки, убрал лишние категории, добавил антипримеры и оставил ручную проверку для всего, где уверенность ниже 0,7.
Если после недели теста модель стабильно путает одни и те же темы, не надо сразу менять весь стек. Обычно помогает более точный справочник: «возврат денег» отделить от «возврата товара», «ошибку входа» отделить от «нет доступа после оплаты». Автоматизация сортировки работает тогда, когда она повторяет ясную операционную логику. Нейросеть ускоряет разбор, но не заменяет решение команды о том, какие проблемы для бизнеса действительно требуют первой реакции.