Вот как Cognigy реализовала отступление

Вот как Cognigy реализовала отступление

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

Введение

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

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

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

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

Часто попытка пользователя отвлечься заканчивается фразой «Извините» от чат-бота и прерывает текущее путешествие.

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

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

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

Опять же, это имитирует настоящий, естественный разговор между людьми.

Почему платформы разработки чат-ботов плохо масштабируются?

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

Многие среды разработки разговорного ИИ плохо масштабируются по двум причинам:

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

Очевидно, что среды pro-code не страдают от этого недуга, но есть и другие проблемы.

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

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

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

Принимая все это во внимание… Cognigy предлагает три подхода…

Got To Flow Node

Диалоговый узел Перейти к или узел потока на языке Cognigy позволяет диалоговому окну перейти к другому потоку. Этот скачок, очевидно, основан на определенном условии, которое необходимо выполнить.

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

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

В приведенном ниже примере вы можете видеть слева, что контекст целевого потока поглощается текущим контекстом. На правом дело не в этом.

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

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

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

Однако нечто подобное можно сделать с узлом Execute Flow.

Выполнить поток

Здесь у нас есть Execute Flow, в котором вы проходите через вызванный Flow один раз, а затем начинаете исходный Flow.

Это аналогично поддиалогам в VoiceXML, где вызывается подпрограмма, а управление возвращается вызывающему потоку.

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

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

Прикрепить поток

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

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

Выше приведен диалог, в котором пользователь может отвлечься от потока Балансы к потоку Филиалов. Пользователь не может отвлечься, так как к филиалам NLU не привязаны балансы.

Заключение

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

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

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

Отступление — большая часть человеческого разговора, наряду с устранением неоднозначности, конечно. Устранение неоднозначности в некоторой степени сводит на нет опасность запасного распространения, когда диалог на самом деле не продвигается вперед.