Диалог возвращает сообщение «Извините, я не могу помочь» после трех взаимодействий - PullRequest
0 голосов
/ 21 июня 2019

Эта проблема началась сегодня утром (21 июня 2019 г.) и коснулась ВСЕХ наших агентов диалогового потока.Раньше они работали нормально, хотя мы наблюдали такое поведение время от времени в прошлом месяце, но нам было трудно воспроизводить его.

Теперь мы можем надежно воспроизвести его, и это мешало всей нашей голосовой работе.

Наш webhook возвращает кусок json, подобный этому, чтобы вызвать событие, чтобы переместить пользователя к следующему намерению:

"followupEventInput": {
    "name": "Textbox",
    "languageCode": "en-AU"
}

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

Example conversation:
"Talk to Foobar Toys"
  "Welcome to Foobar Toys. How can I help you?" (Start app)
"I'd like to know about Lego"
  "Do you want to know about Technic, or Star Wars lego?" (Invocation started)
"Technic"
  "Are you interested in sets or minifigs?" (Interaction 1)
"sets"
  "What kind of sets?" (Interaction 2)
"cars"
  "Sorry, I can't help." (Failure after interaction 2.)

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

Взаимодействия - это все намерения, инициируемые событиями.

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

МНОГО наших рабочих процессов включает более двух взаимодействий.Так что это довольно большое дело.Любой совет приветствуется.Я потратил день или два, пытаясь выработать сценарий, в котором для нас этого не случится, если не повезет вообще.

1 Ответ

0 голосов
/ 24 июня 2019

Итак, мы выяснили, что вызвало это, и сумели обойти это.

Наш агент состоял из нескольких намерений, каждое из которых имело обязательный входной параметр, называемый «вход».Инициирование намерений через наш webhook было сделано (иногда) с помощью последующего события.В FireBase это достигается с помощью следующего выражения:

agent.setFollowupEvent('message');

, где «message» - это имя события, связанного с вашим намерением.

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

Наш обходной путьна данный момент - иметь единственное намерение, совпадающее с sys.any, и больше не передавать последующие события.

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

Добавлено позже - Ответ от Google

"похоже, что причиной проблемы является заполнение слота с использованием @ sys.any в качестве сущности. Пожалуйста, не используйте @sys.any при заполнении слотов, поскольку это не стандартная практика использования @ sys.any. "

...