Соглашения об именах для намерений, событий и контекстов

Question

Мне интересно, существуют ли какие-либо согласованные соглашения о присвоении имен для намерений, событий и контекстов в диалоге.

Если их нет, я был бы признателен, если бы вы поделились своими соглашениями об именах!

Answer 1

Я считаю, что говорить о том, что «на самом деле это не имеет значения, пока это легко понять другим», - это немного противоречиво.Если бы существовали соглашения об именах, кому-то было бы намного проще понять нового бота Dialogflow.

---

Вот мой взгляд:

Intents

Я использую точки длягруппа намерений и подразумевает иерархию.Первая часть имени намерения в идеале - это просто одно слово, которое четко указывает на основной предмет намерения.Например, name будет намерением, которое получает имя пользователя в качестве ввода.name.confirm будет последующим намерением, которое получит подтверждение имени.name.confirm.yes будет намерением, когда пользователь дал подтверждение.

Это в контексте бота, который собирает контактные данные, поэтому подразумевается функция input .В чатоботе более смешанного типа вы можете добавить тип намерения в качестве первого слова, чтобы лучше классифицировать ваши намерения.Например, input.name.confirm.yes или FAQ.shipping.overseas или smalltalk.agent.location ( 'Где вы?' ).

Я использую тот же подход для резервных намерений: fallback.name будет резервным намерениемэто срабатывает, когда бот ждет, пока пользователь введет свое имя, но не понимает ответ.

Контексты

Для контекстов я использую случай верблюда.Например, awaiting_email будет контекстом, который устанавливается, когда бот ожидает, когда пользователь введет свой адрес электронной почты.Получив адрес электронной почты, я установил бы контекст email для передачи информации, чтобы другие намерения могли использовать ее в качестве контекста.Или, если я собираю несколько частей данных о пользователе, я установлю контекст user, и другие намерения могут получить доступ к определенным параметрам, например, через user.email.

---

Я сделал видео оТема также: https://youtu.be/kgKuS2RJcy4

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

Answer 2

К сожалению, их нет, и система достаточно гибкая, что не имеет большого значения.Выберите имена, которые имеют смысл (дух).

Хотя в большинстве примеров он используется, я избегаю , используя пробел в имени.Я отношусь к ним больше как к именам функций, поэтому наличие пробела в нем нарушает мою эстетику.

Я склонен группировать Интенты, основываясь на том, над какой частью беседы они работают, и которая управляется с помощью контекстовкоторые устанавливаются и разделяют обозначения деталей и подразделов точками, поэтому они смутно выглядят как обозначения упаковок.У меня будут Интенты, названные как-то вроде

calculate.fallback
calculate.number
calculate.operation
fallback
welcome

Где все «вычислить» имеют входной контекст «вычислить».

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

Answer 3

Я собираюсь ответить на это с точки зрения проекта сервисной компании.

В моем проекте мы использовали аналогичное соглашение об именах для намерений, как встроенные намерения разговоров, потому что его легко понять и классифицировать.как FAQ.Comapny.your_question, Buy.Drinks.coffee и т. д.
(по некоторым неизвестным причинам мы пишем первую букву основных категорий намерений заглавными буквами, в светских разговорах все буквы в нижнем регистре, как и должно быть).

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

Для параметров и контекстов мы использовали snake_case, то есть coffee_cost.

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

Answer 4

Честно говоря, это действительно не имеет значения!Если его легко реплицировать в коде и ясно видеть / понимать для всех, кто может работать на вашем агенте, то все в порядке.В целом, хотя использование типичной записи кодирования, такой как CamelCase, вероятно, неплохая идея.