Почему intent detection ломается на живом трафике
В пилоте распознавание намерений даёт точность под 95% на размеченном наборе в несколько сотен реплик. На живом трафике та же модель ошибается на каждой третьей фразе, и доля ручного перевода на оператора растёт с первых дней работы.
Первый источник ошибок — длинный хвост запросов. Люди пишут так, как модель не видела: «а можно с доставкой, но не на этой неделе», «подскажите, я запуталась в тарифах». Каждая такая формулировка встречается один раз, в обучающую выборку не попадает, а в сумме эти реплики дают половину обращений.
Второй — неоднозначные формулировки и смешанные темы в одной реплике. «Верните деньги и отключите подписку» — это два разных намерения в одном сообщении, а классификатор обучен выбирать один класс и молча теряет второе. Пользователь не получает ответа на половину вопроса и повторяет его, уже раздражённо.
Третий — отсутствие единого словаря. Пока разметчики и аналитики не договорились, где граница между «отменить заказ» и «изменить заказ», похожие фразы уезжают в разные классы. Таксономия расплывается, метрика на отложенной выборке выглядит прилично, а ошибки распознавания намерений всплывают уже в диалоге.
Сверху ложится шум ввода — опечатки, транслит, распознанная речь. Именно на нём ломается всё, что хорошо работало в демо. Дальше разбираем, как это закрывается.
Что даёт управляемая таксономия намерений
Пока намерения собраны списком фраз «как получилось», близкие классы перекрываются, и бот отвечает не в тему. Управляемая таксономия — это иерархия домен → интент → под-интент, где у каждого класса есть правило ответа, а для всего непокрытого заведён отдельный класс вне сценария. Точность считается по каждому домену отдельно, и слабый домен не размывает общую картину.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Плоский список, 30–50 интентов | Один сценарий поддержки, узкая продуктовая база | Новые темы падают в ближайший интент — растут ложные срабатывания |
| Иерархия домен → интент → под-интент | Несколько направлений, разные команды | Нужна разметка и арбитраж спорных примеров |
| Таксономия с явным классом вне сценария | Открытая база, поток незнакомых формулировок | Требует регулярного пересмотра: часть новых тем переводится в реальные интенты |
Эффект виден на трёх метриках. Доля автоответов растёт с 50–60% до 85%: модель перестаёт угадывать между похожими намерениями. Доля ручных переводов падает в 2–3 раза — оператор подключается только при уверенности ниже порога или при явном запросе вне сценария.
Устойчивость на новых темах даёт класс вне сценария: незнакомая формулировка не притягивается к ближайшему интенту, а попадает в очередь на разбор, и таксономия пересматривается по этим примерам. Уходит и целый класс отказов — «бот уверенно ответил не то», который дороже честного перевода на оператора. Порог уверенности по каждому домену и явная иерархия — отработанная практика в открытых платформах вроде Rasa.
Подходы к intent detection: правила, обучение, гибрид
| Подход | Когда подходит | Ограничения |
|---|---|---|
| Правила и словари | 10–30 интентов, стабильные формулировки, разметки пока нет | рвётся на перефразах и опечатках; словарь растёт быстрее, чем точность |
| Обучение на размеченных диалогах | живая речь, тысячи примеров, интенты пересекаются | нужна разметка и её пересборка при смене таксономии; редкие интенты проседают |
| Гибридный подход | правила как быстрый слой на критичных интентах, модель — на остальном | сложнее отладка: ошибка живёт либо в правиле, либо в модели |
Выбор здесь определяется не модой, а объёмом диалогов и стабильностью предметной области. Правила и словари дают предсказуемость на узком наборе интентов, обучение на разметке — обобщение на перефразы, гибрид — компромисс между управляемостью и гибкостью.
Гибрид обычно собирается каскадом: словарный слой снимает однозначные обращения, модель распределяет остаток, а порог уверенности решает, отвечать автоматически или уточнять. Порог подбирается по матрице ошибок — завышенный гонит долю передач оператору вверх, заниженный увеличивает число неверных ответов. Мы фиксируем его на валидации и пересматриваем при каждом изменении таксономии, иначе качество тихо уезжает.
Что выбрать — зависит от того, что дороже именно вам: ложный ответ или лишняя передача оператору. Опишите задачу и покажите логи диалогов — вернёмся с оценкой, какой из трёх вариантов закроет ваши интенты.
Внедрение: от аудита диалогов до передачи регламентов
Внедрение intent detection — это не разовая тренировка модели, а цикл: аудит реальных диалогов задаёт таксономию, разметка её уточняет, а отложенная выборка показывает, где классификатор ошибается на новых формулировках. Идём этапами, после каждого виден измеримый результат — доля верных срабатываний, число лишних уточнений, глубина очереди на оператора.
- Аудит диалогов. Выгружаем историю обращений за период, считаем долю нераспознанных и сценарии с повторными уточнениями. Так видно, какие намерения стоит выделять отдельно, а какие закрывает обычное меню.
- Схема таксономии. Собираем намерения в иерархию: сверху задача клиента, ниже уточнения и сущности. Проверяем пересечения классов, чтобы близкие запросы не спорили за одну метку.
- Разметка намерений. Пишем правила для спорных случаев и держим контрольную выборку для проверки согласованности. Расхождение разметчиков выше порога возвращает нас к правкам схемы, а не к обучению.
- Настройка уверенности. Задаём порог, ниже которого бот задаёт уточняющий вопрос вместо догадки, и правило передачи оператору. Ложная уверенность на редком классе обходится дороже лишнего уточнения.
- Отложенная выборка. Набор диалогов, не попавший в обучение, прогоняем перед выкаткой: смотрим матрицу ошибок по классам, а не одну общую точность — иначе редкие намерения прячутся за средним.
- Проверка и передача регламентов. Выпускаем в теневом режиме: модель классифицирует, отвечает пока старый сценарий. Затем отдаём регламент обновления — периодичность переобучения, метрики деградации, ответственный за правки таксономии.
Комплект поставки: таксономия, схема, регламенты
Артефакты, которые описывают, что мы считаем намерением и как поступаем с каждым ответом, остаются у заказчика вместе с кодом. Без них модель через месяц превращается в чёрный ящик, а любое изменение сценария требует возврата к подрядчику. Ниже — комплект, который фиксируем в приёмке.
- Словарь намерений (таксономия). Дерево интентов с описанием, примерами фраз на каждый класс, границами между близкими намерениями и правилами разметки спорных случаев. Отдельным блоком — то, что сознательно не относим ни к одному интенту.
- Схема маршрутизации. Таблица «намерение → сценарий или оператор», пороги уверенности, поведение при низкой уверенности и приоритеты, если сработало несколько классов одновременно.
- Политики обработки. Что попадает в логи, что маскируется или не сохраняется вовсе, срок хранения, роли доступа и порядок выгрузки данных для разбора ошибок.
- Документация таксономии. Порядок добавления и переименования намерений, версионирование словаря, владелец со стороны заказчика и точки согласования с бизнесом.
- Регламент переобучения. Триггеры обновления (доля нераспознанных, смещение формулировок пользователей), частота, кто размечает новые примеры и как проверяем качество до выката.
- Контрольный набор и отчёт качества. Фиксированная выборка диалогов, метрики по каждому намерению, сравнение с предыдущей версией и порядок отката при просадке.
- Инструкции для поддержки. Куда заводить нетиповые обращения, как эскалировать и кто обновляет словарь, чтобы новые случаи не терялись между командами.
Кейс: как убрали ложные переводы на оператора
Что было
Клиент пришёл с ботом поддержки, который переводил на оператора больше трети диалогов — включая те, где ответ уже лежал в базе знаний. Таксономия намерений собиралась вручную и содержала пересекающиеся классы: «статус заказа» и «где посылка» уходили в разные категории, а модель с равной уверенностью относила запрос к обеим. Порог уверенности зафиксировали при запуске и не пересматривали.
На отложенной выборке доля верных распознаваний составляла 72%, доля ложных переводов на оператора — 34%. Каждый третий диалог забирал время оператора, хотя автоматика закрыла бы его быстрее.
Что изменили
Пересобрали таксономию: убрали пересечения, развели близкие намерения и добавили отдельный класс «не распознано» вместо натягивания запроса на ближайшую категорию. Разметили стратифицированную отложенную выборку в Label Studio — теперь метрики считаются на одних и тех же данных. Порог уверенности подобрали по матрице ошибок: ложный перевод дороже уточняющего вопроса, поэтому бот сначала переспрашивает, а не зовёт человека.
Что стало
Доля верных распознаваний на той же выборке — 94%, ложные переводы на оператора — 7%. Доля диалогов, закрытых без участия оператора, выросла с 58% до 88%. Мониторинг повесили на долю низкоуверенных распознаваний, распределение намерений по дням и расхождение с ручной разметкой: после правки формулировок в интерфейсе рост таких ответов был виден в тот же день, и переобучение заняло часы вместо недели жалоб.
Чем отличается намерение от сценария диалога
Намерение — это то, что человек хочет получить одной репликой: вернуть заказ, узнать статус доставки, поменять адрес. Сценарий — последовательность шагов и состояний диалога, которая это желание обслуживает: уточнение деталей, слоты, вызовы внутренних систем, точка завершения. Слои живут по разным законам: намерение определяется моделью по тексту и обновляется переобучением на разметке, сценарий описан графом переходов и обновляется правкой ветки.
Если смешать их в одной схеме, каждая новая формулировка клиента превращается в отдельную ветку графа. Таксономия разрастается, число переходов растёт комбинаторно, и любая правка формулировки требует регрессии всего диалога целиком. Хуже другое: реплики со смешанными темами — «хочу вернуть заказ и заодно поменять адрес» — некуда положить, потому что ветка графа подразумевает одну цель на входе.
Между этими слоями нужен слой маршрутизации. Он получает реплику, считает оценку уверенности по каждому намерению из таксономии, применяет порог и правило разрешения конфликтов, и только потом передаёт управление сценарию вместе с текущим состоянием диалога. Сценарий при этом ничего не знает о формулировках, а модель — о слотах и шагах. Правки с обеих сторон остаются локальными, и регрессия не разъезжается по всей схеме.
Уточняющий вопрос — часть маршрутизации, а не отдельная ветка. Когда два намерения близки по уверенности или в реплике смешаны темы, роутер задаёт уточняющий вопрос и удерживает диалог, пока не выберет одну цель. Так граф сценариев остаётся линейным и предсказуемым, а спорные случаи решаются в одном месте — там, где им и положено решаться.
Технические сомнения перед стартом
Перед стартом заказчик проверяет не саму модель, а её эксплуатацию: как переносится текущая логика, сколько нужно данных и что будет с качеством через полгода. Ниже — пять вопросов, которые чаще всего разбираем на техническом обсуждении.
Что делать со старыми правилами?
Оставляем их отдельным слоем: регулярки закрывают жёсткие случаи вроде номеров заказов, модель — свободные формулировки. Приоритет при конфликте задаётся явно и виден в логах.
Сколько фраз нужно размечено вручную?
Объём считаем от числа интентов и вариативности формулировок, а не «на глазок». Старт — несколько сотен фраз на класс, дальше выборка растёт по неуверенным предсказаниям.
Куда девать нераспознанные фразы?
В очередь разбора, а не в заглушку. Вводим порог уверенности и класс «не понял»; доля таких обращений — метрика, показывающая, где таксономии не хватает.
Модель деградирует со временем?
Да, если меняется язык клиентов. Следим за распределением запросов и точностью на контрольной выборке, при просадке дообучаем на свежих данных — в стеке на Rasa это регулярный цикл.
Как обновляется таксономия?
Новые классы заводим по статистике нераспознанных фраз, сохраняя совместимость имён. Старые не удаляем резко — переводим в архив, чтобы отчёты оставались сопоставимыми.
Обсудим задачу и вернёмся с оценкой
Для оценки нужны не общие пожелания, а ваши данные: на первом разговоре разбираем, как бот обрабатывает запросы сейчас и где теряет пользователей. Если есть выгрузка переписки и список интеграций, объём таксономии интентов и состав работ прикидываем уже по итогам разговора.
Что обсудим и какие вводные понадобятся с вашей стороны:
- Аудит текущего бота — какой слой отвечает за распознавание: правила, регулярные выражения или обученная модель, и на каких запросах он ошибается.
- Вводные по диалогам — выгрузка логов за период, доля нераспознанных реплик, несколько сотен размеченных примеров по ключевым сценариям.
- Границы таксономии — перечень сценариев и желаемая детализация: крупные интенты или подклассы с отдельной реакцией на неясный ввод.
- Данные и доступы — каналы (мессенджеры, веб-виджет, телефон), интеграции с CRM или справочником, тестовый контур для прогона модели.
- Язык и стиль — обслуживаемые языки и диалекты, доля опечаток и транслита, нужна ли обработка голосовых сообщений.
- Критерии приёмки — целевая доля верных срабатываний, допустимый уровень ложных, на какой выборке считаем качество.
- Порядок старта — что делаем в первую очередь: замер текущего качества, разметка, черновик таксономии.
- План работ — этапы, точки сверки, состав команды и порядок передачи модели вашим инженерам.
После разговора вернёмся с оценкой, планом работ и перечнем рисков. Опишите задачу и пришлите выгрузку логов — этого достаточно, чтобы двигаться дальше.
