Почему пользователь не знает, чего хочет

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

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

Гипотеза: потребность формируется внутри диалога, а не до него

Стандартная модель диалога предполагает, что у пользователя есть намерение, и задача агента — его извлечь и выполнить. Мы утверждаем обратное: в большинстве сценариев продажи и поддержки намерение не существует в готовом виде на входе. Человек говорит «хочу X», но за этим почти всегда стоит «хочу понять, нужен ли мне X вообще» или «хочу решить задачу, для которой X — лишь одна из гипотез». Первая реплика — это не запрос, а точка входа. Если агент относится к ней как к спецификации, он строит правильный ответ на неправильный вопрос. Зрелый агент должен вести пользователя к формулировке потребности, а не исполнять первую попавшуюся фразу как приказ.

Проблема: исполнение первой реплики обслуживает догадку, а не человека

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

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

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

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

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

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

Инженерная модель: агент ведёт к формулировке потребности

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

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

Вторая — движение к задаче, а не к заказу. Когда человек назвал гипотезу («тур в июне»), агент не кидается её исполнять, а делает шаг к задаче за ней: для кого, почему именно сейчас, что должно получиться в итоге. Не допрос по чек-листу, а несколько точных шагов, которые превращают «хочу X» в «у меня вот такая задача, и под неё подходит вот это». Только после этого исполнение становится осмысленным.

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

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

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

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

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

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

Применить это к вашему агенту — обсудить с инженером → .

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

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

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