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

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

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

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

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

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

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

Когда человек пишет в поддержку, он редко формулирует свой запрос чётко и структурированно. Вместо «Хочу вернуть товар артикул 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 классифицировать сообщение, описав задачу в промпте.

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

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

Минусы: медленнее (секунды 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. Типичная ошибка новичков — впасть в крайность. Создали 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 оркестрация для быстрого прототипирования.

Что в итоге

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

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

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

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