Как спроектировать диалог с AI-помощником: от запроса пользователя до результата

У AI-помощника, в отличие от классического чат-бота, нет заранее прописанной ветки на каждую реплику пользователя. Поэтому команде приходится проектировать саму механику разговора: состояния задачи, уточнения, работу с контекстом, ошибки, подтверждения и передачу человеку. Разбираем, как это делать, на одном сквозном примере.

Представьте, что человек открывает сайт интернет-провайдера и пишет AI-помощнику: «Нужен интернет на дачу в Подмосковье. Приезжаю туда в основном летом, иногда работаю удаленно. Что подойдет?».

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

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

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

Сегодня разберем, как спроектировать свободный диалог от первого запроса пользователя до подтвержденного результата.

Правильный диалог начинается с результата пользователя

Перед тем как проектировать реплики, стоит понять, с каким результатом пользователь должен выйти из взаимодействия.

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

Для каждого ключевого сценария удобно зафиксировать четыре элемента:

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

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

Возможности помощника должны быть понятны заранее

Фраза «спросите что угодно» создает очень широкие ожидания. Если помощник знает только ассортимент и условия доставки, человек быстро упрется в реальную границу его возможностей.

При знакомстве с AI-продуктом полезно сразу объяснить, какие задачи он умеет решать и где проходят его ограничения. Поэтому до написания диалога нужна карта возможностей. Для нашего примера с подключением интернета на даче она может выглядеть так:

Отдельно фиксируют ограничения. Например, помощник создает заявку, а дату визита монтажника подтверждает диспетчер. Тогда сообщение «Мастер приедет во вторник» можно показать только после получения такого статуса из рабочей системы.

У каждой возможности есть свои технические условия. Для действия стоит определить:

• какие данные требуются;

• откуда система их получает;

• насколько актуальным должен быть источник;

• какой источник имеет приоритет при расхождении сведений;

• что считается успешным завершением;

• требуется ли подтверждение пользователя;

• можно ли исправить или отменить действие;

• в каких случаях подключается сотрудник.

Здесь проектирование диалога напрямую связано с данными, API, правами доступа и состояниями внешних систем. Если два источника расходятся, помощнику нужно правило приоритета. Когда по заданным правилам выбрать достоверный вариант невозможно, система сообщает о расхождении пользователю или передает случай сотруднику.

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

Сценарий строится вокруг состояния задачи

Диалог с классическим сценарным ботом удобно представить в виде цепочки:

Выберите услугу → выберите тариф → укажите адрес → оставьте телефон.

Для AI-помощника этой схемы мало, потому что в реальном разговоре человек редко сообщает параметры в заранее предусмотренном порядке. Он может сразу написать:

Хочу подключить интернет на даче в Ликино-Дулеве, нужен в основном летом, два ноутбука и телевизор.

Или начать с одного конкретного условия:

А на Лесной, 115 вообще можно подключиться?

Или изменить решение посреди разговора:

Давайте второй тариф. Хотя подождите, там роутер входит в цену?

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

Для подключения интернета процесс может выглядеть так:

• Помощник определяет задачу — подобрать и подключить интернет.

• Извлекает условия, которые пользователь уже сообщил.

• Проверяет, хватает ли данных для следующего шага.

• Запрашивает обязательные недостающие сведения.

• Проверяет покрытие и актуальные предложения.

• Показывает подходящие варианты.

• Отвечает на дополнительные вопросы и обновляет подбор при изменении условий.

• После выбора предлагает оформить заявку.

• Перед значимым действием показывает параметры, которые будут зафиксированы.

• Выполняет операцию и получает ее фактический статус из CRM.

• Сообщает пользователю подтвержденный результат.

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

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

Уточняющие вопросы появляются там, где влияют на результат

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

Мне нужен недорогой интернет для дачи.

Для проверки подключения помощнику нужен адрес. Здесь уточняющий вопрос полностью оправдан:

Напишите адрес дачи — проверю, какие варианты подключения там доступны.

После проверки может оказаться, что подходят сразу несколько тарифов. Следующий вопрос нужен только в том случае, если ответ действительно изменит рекомендацию. Например:

Интернетом будут одновременно пользоваться несколько человек или в основном один?

Если от этого зависит подходящая скорость, вопрос помогает выбрать тариф.

А вот последовательность «Сколько у вас устройств?», «Как часто вы смотрите фильмы?», «Есть ли игровая приставка?», «Вы работаете из дома?» имеет смысл лишь тогда, когда ответы участвуют в подборе. Вопросы, которые ничего не меняют, только удлиняют диалог.

Уточнение от AI-помощника требуется в трех ситуациях:

• несколько реалистичных трактовок запроса ведут к разным результатам;

• отсутствует обязательный параметр для следующего действия;

• ошибочная интерпретация может существенно повлиять на деньги, данные, сроки или другой значимый результат.

При подобной неопределенности системе полезно уточнить задачу или сузить доступные варианты и дать человеку возможность исправить неверную интерпретацию.

Есть такие любопытные данные: в исследовании, представленном на ACM Creativity & Cognition 2026, уточняющие вопросы повышали уверенность и доверие участников к AI-результату, но одновременно требовали больше когнитивных усилий с их стороны. Эти результаты нельзя напрямую и без критики переносить на любые сценарии, но они иллюстрируют общий принцип: количество вопросов само по себе ничего не говорит о качестве диалога.

Дарья Завьялова,

главред в маркетинге TexTerra

Критерий проще сформулировать так: если ответ пользователя ничего не изменит, вопрос, скорее всего, можно убрать.

Контекст помогает продолжать задачу без повторов

Диалог почти всегда содержит больше информации, чем последнее сообщение пользователя:

— Покажите тариф до 1000 рублей.
— Вот три варианта.
— Второй подойдет, если днем одновременно работают два человека?

— Да.
— А роутер там есть?

— Да.
— Тогда оформляем.

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

Благодаря контексту пользователь может:

• ссылаться на предыдущий вариант словами «этот», «второй», «подешевле»;

• дополнять запрос частями;

• менять одно условие, сохраняя остальные;

• возвращаться к предыдущему варианту;

• продолжать основную задачу после промежуточного вопроса.

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

Если пользователь изменил условие, связанное с подбором, система обновляет состояние задачи и пересчитывает результат. Например, после слов «Теперь нужен тариф до 700 рублей» прежний лимит в 1000 рублей уже не должен влиять на рекомендации.

Текст и интерфейс ведут пользователя по одному сценарию

AI-помощник может работать на сайте, в приложении, личном кабинете, мессенджере, голосовом интерфейсе или рабочей системе сотрудника. Естественный язык удобен, когда человеку нужно объяснить задачу, описать сложные условия или что-то уточнить, а вот для выбора, ввода структурированных данных и подтверждения действия часто лучше подходят обычные элементы интерфейса.

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

По вашему адресу доступны три тарифа. Все подходят для видеозвонков; отличаются скоростью, стоимостью и условиями по оборудованию.

Для разных задач подходят разные элементы:

• несколько вариантов для сравнения — карточки или таблица;

• дата — календарь;

• адрес — поле с подсказками;

• выбор одного из известных вариантов — кнопки;

• сложное условие — свободный текст;

• значимое действие — экран или блок подтверждения.

Проектировать стоит весь пользовательский ход:

запрос → ответ помощника → карточка / кнопка / форма → действие пользователя → следующий ответ.

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

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

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

Ошибка оставляет понятный следующий ход

Даже хорошо спроектированный AI-помощник будет сталкиваться с ситуациями, которые заранее во всех вариантах развития событий просто не перечислить:

• запрос можно понять несколькими способами;

• нужных данных нет;

• источники расходятся;

• API временно недоступен;

• выбранный вариант исчез во время оформления;

• действие завершилось с ошибкой;

• запрос выходит за пределы возможностей системы.

Фраза «Извините, я вас не понимаю» сообщает только о проблеме. Дальнейший путь человеку приходится искать самостоятельно.

Полезный ответ дает сразу три вещи:

что произошло → что это значит для задачи → какие действия доступны дальше.

Например:

Сейчас не получается получить данные о покрытии по этому адресу. Могу повторить проверку или передать адрес специалисту для ручной проверки.

Если источники расходятся и система не может применить установленное правило приоритета:

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

Особенно важно точно сообщать статус операции. Фраза «Заявка оформлена» допустима только после подтверждения от CRM или другой системы, где создается заявка. Пока подтверждения нет, помощник показывает фактическое состояние: например, «Отправляю заявку» или «Не удалось создать заявку».

Подробнее мы разбирали работу со статусами в статье «Как локальному бизнесу попасть в выбор AI и довести клиента до записи».

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

Степень контроля зависит от последствий действия

Ответить на вопрос о тарифе, сохранить черновик заявки и провести платеж — это все действия с разными последствиями. Уровень пользовательского контроля тоже должен различаться.

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

Например:

Проверьте заказ на подключение:
Адрес: Московская область, Ликино-Дулево, ул. Лесная, 115
Тариф: 300 Мбит/с, 850 рублей в месяц
Оборудование: роутер включен

Подтвердить заказ?

Для обычного поиска тарифа такой экран только добавит лишний шаг.

В практическом руководстве по созданию агентов OpenAI выделяет два основных повода подключить человека: 1) превышение допустимого числа неудачных попыток и 2) действия с высоким риском. Ко второй группе относятся чувствительные, трудно обратимые операции и ситуации с серьезными последствиями — например, платежи, крупные возвраты и отмена заказов.

Для проектирования действия можно разделить хотя бы на три группы:

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

Для критических операций стоит заранее определить возможность отмены, журналирование действия, права системы и точку подключения сотрудника.

Передача человеку сохраняет контекст задачи

Фраза «Обратитесь в поддержку» часто означает, что пользователю придется начинать объяснение заново.

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

Например, менеджер получает:

Клиент хочет подключить интернет для сезонного использования по адресу Лесная, 115.
Проверка покрытия дважды завершилась ошибкой.
Интересует тариф до 1000 рублей, интернет нужен в том числе для удаленной работы.
Требуется ручная проверка технической возможности подключения.

Пользователю достаточно объяснить, что произойдет дальше:

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

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

• система несколько раз подряд не может завершить операцию;

• запрос выходит за установленные полномочия;

• решение требует профессиональной оценки сотрудника;

• пользователь сам просит подключить человека;

• последствия потенциальной ошибки требуют дополнительной проверки.

Для повторяющихся сбоев полезно заранее задать порог попыток, после которого управление переходит человеку.

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

Качество проверяют на повторяемом наборе реальных сценариев

Самим пройти продукт и показать его нескольким коллегам полезно на раннем этапе. Для системной проверки AI-помощника нужен еще и повторяемый тестовый набор.

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

Например:

• «Нужен интернет на дачу».

• «На Лесной, 115 есть оптика?»

• «Хочу самый дешевый».

• «Нужен недорогой тариф, днем одновременно работают два человека».

• «Подключите второй тариф».

• «Стоп, второй не надо, покажите первый».

• «А можно со своим роутером?»

• «У меня адреса в вашей форме нет».

• «Я передумал, заявку пока не отправляйте».

• «Хочу поговорить с человеком».

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

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

В клиентском помощнике можно проверять:

• долю задач, завершенных с правильным результатом;

• корректность определения намерения и параметров;

• долю лишних и повторных уточнений;

• успешность обращений к инструментам;

• долю ошибочных действий;

• возможность исправить выбор;

• причины передачи сотруднику;

• количество ходов или время до результата;

• пользовательскую оценку после завершения задачи.

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

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

Хороший AI-помощник ведет пользователя к понятному результату

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

Перед запуском проверьте десять пунктов:

• Для каждого основного сценария определен результат пользователя.

• Возможности и существенные ограничения помощника понятны человеку.

• Для данных и действий определены источники, правила актуальности и приоритеты.

• Система использует уже полученный контекст и учитывает изменения условий.

• Каждый уточняющий вопрос влияет на решение, действие или уровень риска.

• Текст, формы, кнопки и карточки помогают пройти одну и ту же задачу.

• После ошибки остается понятный следующий шаг.

• Степень подтверждения соответствует последствиям действия.

• При передаче сотруднику сохраняется собранный контекст.

• Качество проверяется на повторяемом наборе реалистичных сценариев.

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

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

AI-агенты входят в клиентский путь: как подготовить данные, сайт и процессы

Как локальному бизнесу попасть в выбор AI и довести клиента до записи

Как подготовить товарные данные для выбора и покупки через AI-помощников