Honnêtement, cela n'a vraiment pas d'importance! Tant qu'il est facile à reproduire dans le code et clair à voir / comprendre pour toute autre personne qui pourrait travailler sur votre agent, tout va bien. En général, l'utilisation d'une notation de codage typique telle que CamelCase n'est probablement pas une mauvaise idée.

Il n'y en a pas, malheureusement, et le système est suffisamment flexible pour que cela ne compte pas trop. Choisissez des noms qui ont du sens (duh).

Bien que la plupart des exemples l'utilisent, j'évite éviter d'utiliser un espace dans le nom. Je les traite plus comme des noms de fonctions, donc avoir un espace à l'intérieur brise mon esthétique.

J'ai tendance à regrouper les intentions en fonction de la partie de la conversation sur laquelle ils travaillent, qui est gérée par l'utilisation de contextes qui sont définis et séparent les désignations de partie et de sous-partie par des points, de sorte que cela ressemble vaguement à des désignations de package. J'aurai des intentions nommées quelque chose comme

calculate.fallback
calculate.number
calculate.operation
fallback
welcome

Où les "calculer" ont tous un contexte d'entrée de "calculer".

Surtout, rappelez-vous que les intentions (et donc leurs noms) représentent ce que l'utilisateur dit et pas ce que votre code fait avec cela. C'est la grande différence avec un nom de fonction.

Je vais y répondre du point de vue d'un projet d'entreprise de services.

Dans mon projet, nous avons utilisé une convention de dénomination similaire pour les intentions comme des intentions de conversation intégrée, car elles sont faciles à comprendre et à classer. comme FAQ.Comapny.your_question , Buy.Drinks.coffee etc.
(pour des raisons inconnues, nous mettons en majuscule la première lettre des principales catégories d'intentions, en petits mots, toutes les lettres sont en minuscules comme il se doit).

Pour les événements, nous avons utilisé une notation similaire pour les constantes universelles, comme INVOKE_EVENT .

Pour les paramètres et les contextes, nous avons utilisé snake_case c'est-à-dire coffee_cost .

En gros, cela n'a pas vraiment d'importance tant qu'il est facile à comprendre et à reproduire. Mais vous devez toujours avoir une structure de base que vous et toute votre équipe suivez tout au long du projet.

Je trouve que c'est un peu une contradiction de dire "ça n'a pas vraiment d'importance tant que c'est facile à comprendre pour les autres". S'il y avait des conventions de dénomination, il serait beaucoup plus facile pour quelqu'un de comprendre un nouveau bot Dialogflow.

Voici mon avis:

Intentions

J'utilise des points pour regrouper les intentions et impliquer une hiérarchie. La première partie du nom de l'intention est idéalement un seul mot qui indique clairement le sujet principal de l'intention. Par exemple nom serait une intention qui reçoit le nom d'un utilisateur en tant qu'entrée. name.confirm serait l'intention de suivi qui reçoit la confirmation du nom. name.confirm.yes serait l'intention où l'utilisateur a donné une confirmation.

Ceci est dans le contexte d'un bot qui collecte des données de contact donc la fonction input est implicite. Dans un chatbot de type plus mixte, vous pouvez ajouter le type d'intention comme premier mot pour mieux catégoriser vos intentions. Par exemple. input.name.confirm.yes ou FAQ.shipping.overseas ou smalltalk.agent.location ( 'Où êtes-vous?' ).

J'utilise la même approche pour les intentions de secours: fallback.name serait l'intention de secours qui est déclenchée lorsque le bot attend que l'utilisateur saisisse son nom mais ne comprend pas la réponse.

Contextes

Pour les contextes, j'utilise le cas du chameau. Par exemple, awaiting_email serait le contexte défini lorsque le bot attend que l'utilisateur saisisse son adresse e-mail. Après avoir reçu l'adresse e-mail, je définirais un email contextuel pour transférer les informations afin que d'autres intentions puissent les utiliser comme contexte. Ou si je recueille plusieurs éléments de données sur l'utilisateur, je définirai le contexte user et d'autres intentions peuvent accéder à certains paramètres, par exemple via user.email .

J'ai également réalisé une vidéo sur le sujet: https://youtu.be/kgKuS2RJcy4

Il est évident que tout le monde vient d'un angle légèrement différent car son domaine d'application est différent. Je suis sûr que nous finirons par arriver à une norme commune!