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

Эта проблема началась сегодня утром (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 ответ

Решение

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

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

agent.setFollowupEvent('message');

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

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

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

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

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

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

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

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" для отслеживания. Это заставляет его не вызывать одно и то же намерение раз подряд. Это позволило мне записать неограниченное количество значений.