Представьте: неизвестный запрос второй раз получает одну и ту же fallback-реплику, а человек не понимает, переформулировать вопрос ещё раз или ждать человека. Для нейросеть чат бот это не вопрос вежливости, а практическое решение: заранее определить, когда сценарий ещё помогает уточнить запрос, а когда должен передать человека по понятному маршруту.
21 июля 2026 года ChatBot.com обновил руководство по fallback для сообщений, которые бот не распознаёт. Такая ветка может попросить переформулировать запрос, показать варианты выбора или передать разговор человеку. Для нейросеть чат бот важен не только ответ на ожидаемое сообщение, но и маршрут неизвестного запроса. Сценарий с заранее заданным пределом попыток позволяет проверить, есть ли у человека выход из повторяющейся ветки.
Ниже собрана карточка из пяти полей и короткий тест диалога. Они нужны не для обещания безошибочного общения, а для одного практического решения: определить, когда сценарий ещё помогает уточнить запрос, а когда должен передать человека по понятному маршруту.
Где заканчивается ответ и начинается маршрут
Не каждый сбой требует одной и той же реплики. В узком no-code сценарии полезно разделить три состояния:
- Нераспознанное намерение. Сообщение не попало ни в одну известную ветку. Здесь уместен fallback с просьбой уточнить формулировку или выбрать вариант.
- Невыполнимая задача. Намерение может быть понятно, но сценарий не способен его выполнить. Руководство Microsoft рассматривает этот случай вместе с неопределённым намерением как повод для fallback или handoff.
- Рискованный запрос. Это категория, которую владелец процесса заранее выводит из свободного диалога по своей политике. Ей нужен назначенный маршрут, а не попытка угадать ответ.
Если свести все три состояния к одинаковому извинению, нельзя проверить, какой именно маршрут сработал и где человек остановился. Поэтому fallback лучше проектировать как ветку с назначением, а не как фразу в конце сценария.
Почему одной вежливой реплики недостаточно
ChatBot.com различает fallback по умолчанию и fallback, заданный для конкретного пути. Это позволяет оставить общий выход для неизвестного сообщения и отдельно определить реакцию в сценарии, где контекст уже известен.
Microsoft рекомендует для разговорных пользовательских сценариев строить серию fallback-действий, а не повторять одну и ту же реплику, когда система не может определить или выполнить намерение. В этих рекомендациях для такого случая предлагается не задавать более двух fallback-вопросов в одной сессии, после чего направлять человека дальше, объясняя следующий шаг и сохраняя точку, на которой он застрял.
Это рекомендация Microsoft для разговорных пользовательских сценариев, то есть ориентир, а не универсальное правило для каждой no-code платформы или процесса. Другой порог стоит использовать, только если владелец процесса заранее определил его для конкретного сценария, назначил маршрут handoff и проверил этот маршрут на коротком диалоге.
Карточка fallback, которую можно проверить до запуска
| Поле | Что зафиксировать | Что проверить |
|---|---|---|
known intent |
Какие запросы сценарий уже умеет обрабатывать | У известного запроса есть назначенная ветка |
fallback message |
Просьбу переформулировать запрос или варианты выбора | После неизвестного сообщения появляется полезный следующий шаг |
attempt count |
Счётчик попыток и предел не более двух fallback-вопросов | После предела сценарий не задаёт ещё одно такое же уточнение |
handoff destination |
Куда направляется человек и кто принимает следующий шаг | Сообщение о передаче объясняет, что произойдёт дальше |
context to transfer |
Точку, где человек застрял, и заранее определённый контекст | При передаче не теряется причина остановки |
Короткий тест, который ловит петлю
Для одного ограниченного сценария подготовьте набор проверочных реплик:
| Проверка | Ожидаемый маршрут |
|---|---|
| Запрос с известным намерением | Назначенная ветка ответа |
| Перефразировка известного запроса | Проверка, не потерялся ли маршрут |
| Запрос без назначенного намерения | Fallback с уточнением или вариантами выбора |
| Неизвестный запрос после допустимых попыток | Handoff в заранее определённое направление |
| Невыполнимая или рискованная задача | Отдельная ветка, заданная владельцем процесса |
Тест пройден, если у каждой реплики есть назначенный маршрут, а неизвестный запрос доходит до fallback или handoff вместо повторения одной и той же ветки. Передача должна показывать следующий шаг и сохранять точку затруднения.
Такой тест не доказывает, что сценарий обработает все будущие сообщения. Он показывает более узкую вещь: у границы сценария есть выход, который можно увидеть до запуска.
Не отдавать решение о поддержке текстовому помощнику
AI-инструмент может помочь предложить тестовые формулировки, но не должен выбирать политику эскалации. Для этого подойдёт ограниченный запрос:
Ты готовишь только тестовые реплики для ограниченного no-code сценария.
Известные намерения: [перечень]
Fallback-сообщение: [текст]
Предел: [не более двух fallback-вопросов]
Направление handoff: [назначенное направление]
Передаваемый контекст: [перечень]
Предложи реплики для известного намерения, перефразировки, неизвестного запроса
и запроса вне границ сценария. Для каждой укажи ожидаемый маршрут.
Не выбирай адресат эскалации, порог попыток или правила поддержки.
Такой запрос оставляет владельцу процесса решения о границах, передаче и ответственности, а помощнику поручает только подготовку материала для теста.
Поворот: не каждый понятный ответ дешевле передачи
Сильное возражение против раннего handoff понятно: время человека ограничено, а удачное уточнение или выбор варианта иногда возвращают диалог к известному намерению. Если передача не имеет владельца и понятного следующего шага, она может быть хуже второго целевого уточнения.
Но предел из двух fallback-вопросов меняет саму постановку задачи не сам по себе. Между попытками должна появляться новая полезная опора: просьба переформулировать запрос, варианты выбора или назначенный маршрут. Если следующая реплика только повторяет прежнее уточнение и не добавляет ни выбора, ни перехода, это уже повторяющийся тупик, а не ещё одно целевое уточнение. После заранее определённой границы не стоит продолжать угадывание без новой опоры в сценарии. Либо человек получает ясный handoff с контекстом, либо команда честно сужает область, которую бот берётся вести.
Нельзя посчитать цену такого решения без данных конкретного процесса. Однако для человека, который уже дважды не получил пригодного следующего шага, третья вариация той же ветки может выглядеть не как экономия, а как отсутствие выхода.
Правило использования
Переход к человеку уместен, когда одновременно выполнены четыре условия:
- Границы сценария объявлены.
- У handoff есть назначенное направление и владелец следующего шага.
- В сообщении о передаче понятно, что будет дальше.
- Тест подтверждает, что неизвестный запрос не возвращается в ту же fallback-петлю.
Не называйте ветку handoff, если в ней нет адресата, следующего шага или передаваемого контекста. В таком случае честнее сузить сценарий или обозначить, что задача не обрабатывается в этом диалоге.
Если нужны варианты тестовых формулировок, provod.ai можно рассматривать только как единый интерфейс для сравнения AI-инструментов при подготовке ограниченного no-code сценария. Порог, адресат и передаваемый контекст всё равно утверждает владелец процесса.
provod.ai — российский LLM API-агрегатор
Один OpenAI-совместимый endpoint вместо набора интеграций: подключайте модели к продукту, агентам, IDE и SDK через общий API. Во многих совместимых инструментах достаточно заменить base_url и API-ключ.
В одном каталоге — актуальные модели для текста и медиа: GPT от OpenAI, Claude от Anthropic, Gemini от Google, Grok от xAI, DeepSeek, Qwen, GLM, Kimi и MiniMax; для изображений — Nano Banana 2 Pro и GPT Image; для видео — последние версии Seedance, Kling, Veo и Google Omni. Также доступны модели для reasoning, поиска, документов, эмбеддингов, музыки и аудио.
Цены 1:1 с официальными ценами провайдеров — без собственной наценки provod.ai. Оплата в рублях, единый баланс и документы для юридических лиц.
Если статья была полезной — попробуйте provod.ai: форма регистрации · цены на модели · защита данных по 152-ФЗ · API и интеграции
После какого конкретного порога вы направите человека на handoff и какой минимальный контекст передадите ему, чтобы он мог продолжить разговор?
Top comments (0)