Интенты не существуют

Коротко для руководителя. Большинство чат-ботов спроектировано вокруг идеи, что у пользователя есть одно чёткое намерение, которое система угадывает и обрабатывает по шагам. На демо это выглядит безупречно, в проде ломается на первой же живой реплике. Человек редко приходит с одним намерением — он держит несколько сразу и меняет их по ходу разговора. Бот, построенный на жёсткой схеме интентов, теряет таких людей, а с ними — выручку. Это не недокрученный промпт, а ошибка в фундаменте.

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

Гипотеза: у живого пользователя нет одного намерения

Классическая NLU-модель (Natural Language Understanding) исходит из того, что в каждый момент диалога у пользователя есть ровно одно намерение, и задача системы — его распознать. На этом стоит вся индустрия сценарных ботов: дерево интентов, формы слотов, переходы между состояниями.

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

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

Проблема: схема ломается на первой же живой реплике

Жёсткая схема намерение → слоты → результат требует от пользователя того, чего он не делает: говорить по одному намерению за раз, в правильном порядке, без отклонений. Реальность выглядит иначе, и каждое отклонение — это точка отказа.

Несколько намерений в одной реплике. Классификатор обязан выбрать одно. Любой выбор — это потеря: либо система игнорирует часть запроса, либо тащит человека по ветке, которая закрывает только треть его вопроса.

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

Формулировка не ложится в ярлык. Живая речь редко совпадает с тем, как разработчик назвал интент. «Что-то я сомневаюсь, стоит ли оно того» — это не intent: complaint и не intent: booking. Это сомнение, с которым надо работать, а не классифицировать.

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

График про другое — про обмен данными между машинами, — но он показывает ровно ту же закономерность, что губит интент-схему. Чем жёстче формализован обмен и чем ближе вход к ожидаемому формату, тем надёжнее результат. Жёсткая схема интентов держится только тогда, когда вход аккуратный и предсказуемый. Живой человек подаёт на вход свободный текст в самой неудобной форме — и надёжность распознавания падает именно там, где цена ошибки выше всего: на сомневающемся клиенте, которого ещё можно было удержать.

Почему обычные подходы не работают

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

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

Улучшить классификатор. Можно поднять точность распознавания одного намерения с 85% до 95%. Но это решение неправильной задачи: мы всё точнее выбираем один ярлык там, где намерений несколько и они подвижны. Точный ответ на неверно поставленный вопрос остаётся неверным.

Заставить пользователя говорить «правильно». Меню, кнопки, «выберите один из вариантов», «опишите вопрос одной фразой». Это попытка переложить дефект архитектуры на пользователя — обучить человека под удобную боту схему. Иногда работает для простых справок, но как только задача чуть сложнее выбора из списка, человек снова сваливается в живую речь, и бот снова не справляется. Подробнее, почему «обучать пользователя» — тупик, мы разбираем в заметке про хаос как норму диалога.

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

Инженерная модель: намерение как состояние, а не как ярлык

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

Несколько намерений живут одновременно. Система не выбирает «главный интент», а держит набор активных целей пользователя и отслеживает, какие из них продвинулись, какие появились, какие отпали. Реплика «а можно с собакой?» посреди брони не сбрасывает контекст брони — она добавляет ещё одну цель, которую надо удержать и закрыть.

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

Реакция на событие, а не следование плану. Здесь работает та же логика, что в событийных ИИ-системах: диалог — это поток событий (новая цель, изменение цели, противоречие, возврат к старому вопросу), а агент — то, что на эти события отвечает. Линейный слот-филлинг подразумевает, что план известен заранее; событийная модель не делает этого допущения и потому переживает то, на чём сценарий ломается.

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

Практический вывод для бизнеса

Как проверить своего бота. Возьмите десять реальных диалогов из вашей поддержки или продаж — не сценарных, а живых. Посмотрите, в скольких из них у клиента было ровно одно намерение, заявленное сразу и не менявшееся до конца. Обычно таких — меньшинство. Это и есть доля диалогов, на которую рассчитана интент-архитектура; всё остальное она обрабатывает плохо.

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

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

Понять, на чём ваш бот теряет людей, — обсудить с инженером → .

Открытые вопросы

Где граница, за которой интент-схема всё-таки оправдана. Для совсем простых задач — узнать баланс, статус заказа, часы работы — дерево из нескольких интентов может быть дешевле и надёжнее агента. Вопрос в том, как честно отличить «здесь хватит сценария» от «здесь сценарий молча теряет деньги», и не выдать ли за первое то, что на самом деле второе.

Как мерить качество системы без понятия «интент». Если намерений несколько и они меняются, привычная метрика «процент верно распознанных интентов» теряет смысл. Какая метрика её заменяет — отдельный инженерный вопрос; короткий ответ в том, что мерить надо исход для живого человека, а не точность ярлыка по дороге.

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

Если ваш бот хорошо отвечает на простые вопросы, но теряет клиентов, как только разговор становится живым, — почти наверняка дело в интент-архитектуре под капотом. Обсудить задачу → — разберём, на каких диалогах ваша система ломается и что с этим делать.