Автоклассификация обращений: intent, entities и routing – как сделать и где ломается

Пятница, вечер. В поддержку интернет-магазина прилетает сообщение: «Где мой заказ 847291? Уже неделю жду, на звонки не отвечаете!!!». Три восклицательных знака – верный признак, что человек на взводе.

В хорошо настроенной системе происходит следующее: за доли секунды определяется тема (статус доставки), извлекается номер заказа, фиксируется негативный тон – и через три секунды сообщение уже у оператора, который занимается доставкой. С историей клиента на экране, со статусом заказа, со всеми предыдущими обращениями.

В плохо настроенной – сообщение падает в общую очередь. Первым его берёт оператор, который занимается возвратами. Читает, понимает, что это не к нему, пересылает. Полчаса. Клиент пишет снова – теперь уже с четырьмя восклицательными знаками. Потом звонит. Потом идёт писать отзыв на 2GIS. История, которую можно было закрыть за минуту, превращается в катастрофу на весь день.

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

«До внедрения автоклассификации наши операторы тратили 40% времени на то, чтобы понять, о чём вообще пишет клиент, и кому передать обращение. Сейчас 87% тикетов маршрутизируются автоматически с точностью выше 94%. Это не магия – это месяцы работы над алгоритмами и данными.»

Что такое автоклассификация и зачем она нужна

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

Когда человек пишет в поддержку, он редко формулирует свой запрос чётко и структурированно. Вместо «Хочу вернуть товар артикул 12345, причина – не подошёл размер» вы получаете: «Здравствуйте, заказала платье, а оно мне велико, что делать?». В этом сообщении зашито сразу несколько слоёв информации, которые система должна распознать.

Из чего состоит автоклассификация

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

Intent – это намерение клиента, то, чего он хочет добиться. Это не тема сообщения в общем смысле, а конкретное действие или информация, которую клиент ожидает получить. Один и тот же клиент может написать «Где мой заказ?» (intent: узнать статус) или «Заказ пришёл разбитый» (intent: оформить претензию) – темы близкие, но намерения совершенно разные, и обрабатывать их нужно по-разному.

Entities – это конкретные сущности, упомянутые в сообщении: номера, даты, имена, названия товаров, города. Без них intent часто бесполезен. Знать, что клиент хочет узнать статус заказа – хорошо. Но если не извлечь номер заказа, оператору всё равно придётся переспрашивать.

Routing – это решение о том, что делать с обращением дальше. Иногда это простое правило (intent «возврат» → отдел возвратов). Иногда – сложная логика с учётом загрузки операторов, приоритета клиента, времени суток и десятка других факторов.

Почему бизнесу это критически важно

Казалось бы, операторы и так разберутся – прочитают сообщение, поймут, что нужно клиенту. Зачем автоматизировать? Ответ кроется в масштабе и экономике.

Представьте контакт-центр, который получает 5000 обращений в день. Если оператор тратит в среднем 30 секунд только на то, чтобы понять суть обращения и решить, кому его передать – это 2500 минут, или 41 час ежедневно. При средней зарплате оператора в Казахстане около 250 000 тенге в месяц, это эквивалент двух полноценных сотрудников, которые занимаются только сортировкой.

Но деньги – не главное. Главное – время клиента. Исследования показывают, что скорость первого ответа критически влияет на удовлетворённость и конверсию. Каждая минута ожидания снижает вероятность положительного исхода.

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

Как это работает: от текста к действию

Теперь давайте заглянем под капот. Как система понимает, что «Где мой заказ?» – это intent «status_inquiry», а «847291» – это entity типа «order_number»?

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

Подход первый: классические ML-модели (NLU)

Традиционный подход использует специализированные модели для понимания естественного языка (Natural Language Understanding, NLU). Это системы вроде Rasa, Dialogflow, Amazon Lex или Microsoft LUIS. Они работают по принципу обучения с учителем: вы даёте системе примеры сообщений с размеченными intent и entities, она учится находить закономерности.

Процесс выглядит примерно так:

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

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

Минусы: требует значительных усилий на разметку данных, плохо справляется с новыми, невиденными формулировками, сложно добавлять новые intent без переобучения.

Подход второй: LLM (большие языковые модели)

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

Промпт может выглядеть примерно так:

Ты – система классификации обращений клиентов интернет-магазина.

Проанализируй сообщение клиента и верни JSON:
{
  "intent": "один из: order_status, return_request, complaint, delivery_question, product_question, payment_issue, other",
  "confidence": "число от 0 до 1",
  "entities": {
    "order_number": "номер заказа, если упомянут",
    "product": "название товара, если упомянут",
    "date": "дата, если упомянута"
  },
  "sentiment": "positive, neutral, negative",
  "priority": "low, medium, high, urgent"
}

Сообщение клиента:
"{user_message}"

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

Минусы: медленнее (секунды vs миллисекунды), дороже при высоких объёмах, менее предсказуемое поведение, зависимость от внешнего API (если не self-hosted).

Гибридный подход: лучшее из двух миров

На практике часто работает комбинация. Быстрая NLU-модель обрабатывает типовые случаи (80% трафика), а сложные или неоднозначные обращения передаются LLM для более глубокого анализа. Это позволяет сохранить скорость и снизить затраты, не жертвуя качеством в сложных случаях.

Извлечение сущностей: дьявол в деталях

Определение intent – только половина задачи. Вторая половина, часто более сложная – извлечение entities. И здесь начинается настоящее веселье.

Казалось бы, что сложного? Номер заказа – это число, дата – это дата. Но реальность, как всегда, интереснее.

Проблема первая: вариативность форматов

Клиенты пишут номера заказов по-разному:

• «Заказ 847291» – просто
• «Заказ № 847-291» – с дефисом и символом №
• «Номер заказа: ORD-2024-847291» – с префиксом
• «847291» – вообще без контекста
• «восемьсот сорок семь двести девяносто один» – прописью (да, бывает!)

То же самое с датами: «15 декабря», «15.12», «15/12/2024», «вчера», «в прошлую пятницу», «на той неделе». Система должна понимать все эти варианты и приводить к единому формату.

Проблема вторая: неоднозначность

«Заказ 12345, артикул 67890» – какое из чисел что? Без понимания контекста не разобраться. А если клиент написал: «Заказывал 5 штук, пришло 3» – числа 5 и 3 не являются ни номером заказа, ни артикулом, это количество.

Проблема третья: опечатки и ошибки

Клиент написал «847921» вместо «847291» – опечатка. Система должна либо обнаружить это (проверить, существует ли такой заказ), либо переспросить. А если клиент вообще указал номер заказа из другого магазина?

Routing: от классификации к действию

Мы определили intent и извлекли entities. Теперь нужно решить, что делать с обращением. Это может быть простое правило, а может – сложная логика с десятком условий.

Уровень 1: Простой routing по intent

Самый базовый вариант – таблица соответствий «intent → очередь/группа»:

Это работает для небольших команд с чётким разделением ответственности. Но реальность обычно сложнее.

Уровень 2: Контекстный routing

Учитываем дополнительные факторы:

• Статус клиента: VIP-клиенты → отдельная очередь с опытными операторами
• История обращений: если клиент уже общался с конкретным оператором – направить к нему же
• Сумма заказа: заказ на 500 000 тенге требует особого внимания
• Sentiment: негативные обращения → опытным операторам, умеющим работать с конфликтами
• Время суток: ночью – только дежурная смена

Уровень 3: Skill-based routing

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

Уровень 4: Автоматическое решение

Иногда routing ведёт не к оператору, а к автоматическому действию. Если клиент спрашивает статус заказа и мы извлекли номер – можно сразу дать ответ без участия человека. Если запрос на возврат и все условия соблюдены – автоматически создать заявку. Это handoff наоборот: не от бота к человеку, а решение ботом.

ЕСЛИ intent = "order_status" И order_number извлечён:
    ЕСЛИ заказ найден в БД:
        → Автоответ со статусом
    ИНАЧЕ:
        → Очередь "Доставка" с пометкой "номер не найден"

ЕСЛИ intent = "complaint":
    ЕСЛИ sentiment = "very_negative" ИЛИ клиент = VIP:
        → Очередь "Эскалации" приоритет = URGENT
    ИНАЧЕ:
        → Очередь "Претензии" приоритет = HIGH

ЕСЛИ intent = "return_request":
    ЕСЛИ сумма заказа > 100000 тенге:
        → Очередь "Возвраты VIP"
    ИНАЧЕ:
        → Очередь "Возвраты"

ИНАЧЕ:
    → Общая очередь

Где всё ломается: типичные ошибки и как их избежать

Теперь о грустном. Автоклассификация – это не волшебная кнопка. Системы ошибаются, причём иногда в самых неожиданных местах. Вот типичные проблемы и способы их решения.

Слишком мало или слишком много intent. Типичная ошибка новичков – впасть в крайность. Создали 5 обобщённых категорий («общий вопрос», «проблема», «жалоба») – и что с ними делать? Или наоборот – 200 микро-intent, которые даже сама система путает между собой. Золотая середина для типичного контакт-центра – 15-25 intent. Каждый должен вести к конкретному действию. Если два intent в итоге обрабатываются одинаково – объедините. Если один требует разных действий – разделите.

Клиент написал два вопроса в одном сообщении. «Где мой заказ 12345? И ещё хочу узнать, можно ли поменять размер у другого заказа». Два intent, одно сообщение. Если система умеет определять только один – угадайте, который останется без ответа. Поддержка multi-intent – не роскошь, а необходимость. Либо создавайте два тикета, либо помечайте обращение как составное.

Система не знает, что делать, когда не уверена. Уровень уверенности 47% – это куда? В никуда. Обращение зависает или попадает в случайную очередь. Настройте fallback: если уверенность ниже 70% – в общую очередь с пометкой «требует ручной классификации». Или используйте LLM как запасной мозг для непонятных случаев.

Кейс: как мы настраивали автоклассификацию для финтеха

Расскажу реальный пример (детали изменены для конфиденциальности). Финтех-компания в Казахстане – мобильное приложение для платежей и переводов. 15 000 обращений в день, 40 операторов в три смены.

Проблема: 35% обращений маршрутизировались неправильно, операторы тратили время на пересылку тикетов друг другу. Среднее время решения – 4 часа, при том что большинство вопросов можно было закрыть за 10 минут.

Что мы сделали

Шаг 1: Анализ данных. Выгрузили 50 000 исторических обращений, разметили 5 000 вручную. Выявили 28 основных intent, из которых 8 покрывали 75% трафика.

Шаг 2: Гибридная модель. Для топ-8 intent обучили быструю NLU-модель на Rasa. Для остальных 20 и для fallback – LLM (Claude) с детальным промптом.

Шаг 3: Entity extraction. Критичные entities (номер транзакции, номер карты, сумма) – регулярные выражения + валидация в БД. Остальные – LLM.

Шаг 4: Умный routing. Учли: тип клиента (физлицо/ИП/ТОО), сумму спорной транзакции, количество обращений за последний месяц, тональность. VIP-клиенты и крупные суммы – сразу к старшим специалистам.

Шаг 5: Обратная связь. Дали операторам кнопку «Неправильная классификация» с выбором правильного intent. Данные автоматически добавляются в обучающую выборку.

Как внедрить: пошаговый план

Если вы решили внедрить автоклассификацию в своей компании, вот реалистичный план действий.

Этап 1: Аудит текущего состояния (1-2 недели)

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

Этап 2: Проектирование системы (2-3 недели)

• Определите список intent – начните с 15-25, покрывающих 80-90% обращений
• Определите необходимые entities для каждого intent
• Спроектируйте логику routing: куда направлять каждый intent, с учётом каких факторов
• Выберите технологию: NLU, LLM или гибрид

Этап 3: Подготовка данных (2-4 недели)

• Разметьте обучающую выборку: минимум 100-200 примеров на каждый intent
• Разметьте entities в примерах
• Отложите 20% для тестовой выборки
• Для LLM – подготовьте промпты и протестируйте на выборке

Этап 4: Разработка и тестирование (3-4 недели)

• Обучите модель / настройте промпты
• Интегрируйте с CRM/helpdesk системой
• Протестируйте на тестовой выборке, измерьте точность
• Проведите пилот на части трафика (10-20%)

Этап 5: Запуск и мониторинг (ongoing)

• Постепенно увеличивайте долю автоматически классифицируемых обращений
• Настройте дашборд с метриками качества
• Собирайте обратную связь от операторов
• Регулярно дообучайте модель на новых данных

Инструменты: что использовать

Краткий обзор технологий для каждого компонента системы.

Для NLU-подхода

• Rasa – open-source, гибкий, можно развернуть on-premise. Хорош для тех, кто хочет полный контроль.
• Dialogflow (Google) – облачный, простой в настройке, хорошая интеграция с Google экосистемой.
• Amazon Lex – часть AWS, хорош если уже используете AWS инфраструктуру.
• Microsoft LUIS – часть Azure, интеграция с Microsoft экосистемой.

Для LLM-подхода

• OpenAI GPT-4 – высокое качество, дороже, API в облаке.
• Anthropic Claude – сопоставимое качество, иногда лучше для структурированного вывода.
• Llama / Mistral (self-hosted) – для тех, кому нужен полный контроль над данными.

Для routing и оркестрации

• Встроенные возможности CRM – Salesforce, Zendesk, Freshdesk имеют свои механизмы routing.
• Custom logic на Python/Node.js – для сложных правил и интеграций.
• n8n / Make (Integromat) – no-code оркестрация для быстрого прототипирования.

Что в итоге

Автоклассификация – это не «фича для галочки». Это разница между поддержкой, которая бесит клиентов, и поддержкой, которую хвалят.

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

Да, внедрение требует возни. Данные собрать, разметить, модель настроить, мониторинг наладить. Но окупается это быстро – обычно за пару месяцев. А дальше – просто работает.

С чего начать? Посчитайте, сколько времени ваши операторы тратят на то, чтобы понять, о чём пишет клиент, и кому переслать сообщение. Уверен, цифра вас неприятно удивит. И вот это – ваша точка отсчёта.

Читайте также

• Омниканальный inbox: архитектура, маршрутизация и единый профиль клиента
• Handoff «бот → оператор»: как передавать контекст и не ломать SLA
• Скорость ответа на заявку: почему первые 5 минут решают всё
• Оценка качества AI-бота: golden set, метрики и A/B-тесты
• SLA и эскалации в CRM: таймеры, очереди, уведомления