Dialogflow возвращает сообщение "Извините, я не могу помочь" после трех взаимодействий

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

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

Наш веб-перехватчик возвращает фрагмент 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.)

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

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

Если мы ДЕЙСТВИТЕЛЬНО запускаем резервное намерение или текст справки, счетчик сбрасывается, и мы можем продолжать работу, пока не нажмем его в следующий раз.

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


person dylanT    schedule 21.06.2019    source источник
comment
В консоли Dialogflow можете ли вы убедиться, что выполняете резервное намерение?   -  person Nick Felker    schedule 21.06.2019
comment
@NickFelker, нет, мы не используем запасной вариант. Мы выяснили, что пошло не так, и разработали обходной путь. Я собираюсь опубликовать здесь обновление в свое время.   -  person dylanT    schedule 24.06.2019


Ответы (2)


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

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

agent.setFollowupEvent('message');

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

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

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

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

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

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

person dylanT    schedule 24.06.2019

Вот моя установка и мое хакерское исправление:

intent1, инициированный событием "eventIntent1", с параметром 'value' типа @ sys.number. Намерение получает одно число, сохраняет его в контексте разговора. Если у него еще нет четырех номеров, он вызывает себя через отслеживание ("eventIntent1"), чтобы получить другой номер.

Желаемый разговор:

assistant: "give me a number"
user: "1"
assistant: "give me a number"
user: "2"
assistant: "give me a number"
user: "3"
assistant: "give me a number"
user: "4"
assistant: "You gave me 1 2 3 4"

Актуальный разговор:

assistant: "give me a number"
user: "1"
assistant: "give me a number"
user: "2"
assistant: "give me a number"
user: "3"
assistant: "Sorry, I can't help"

Исправить:

Исправление заключалось в настройке другого намерения под названием «intent2», запускаемого событием «eventIntent2». Заполнение слотов для них идентично (логика выше), за исключением того, что intent1 вызывает "eventIntent2" для отслеживания, а "intent2" вызывает "eventIntent1" для отслеживания. Это заставляет его не иметь одного и того же намерения, вызываемого раз подряд. Это позволило мне записать неограниченное количество значений.

person mrvladimir    schedule 23.03.2020