Résumé de l'expérience dans la conception de chatbot basé sur une machine à états

Afin de mieux comprendre les besoins et les axes d'amélioration des projets de robots intelligents, nous devons souvent développer certains outils. Parmi les nombreux projets de robotique auxquels j'ai participé, la plupart ont réussi à répondre aux exigences des produits. Grâce à ces pratiques, nous avons profondément réalisé que si nous voulons continuer à progresser et à nous améliorer, nous devons apporter des améliorations significatives au langage de définition des robots existant.

• Simplifiez le processus de création de robots qui nécessitent des flux de conversation complexes.
• Maximisez la réutilisabilité en réutilisant les modules et les chemins de dialogue qui ont été définis dans le passé pour créer des robots

Dans les pratiques traditionnelles, ce n'est pas facile de faire cela car la définition de l'intention est mélangée à des contraintes d'ordre partiel, limite la liberté de dialogue chemins. Ceci est suffisant pour gérer les robots « ouverts » (courants dans les robots de style FAQ) où la plupart des questions sont autonomes et toujours disponibles. Mais pour les robots plus « fermés », les limitations conversationnelles potentielles sont bien plus importantes (comme par exemple un robot utilisé pour réserver des billets en ligne).

Afin d'amener la fonctionnalité du langage de définition de chatbot à un nouveau niveau, dans certains projets, nous avons introduit des DSL qui se rapprochent de la sémantique des machines à états et intègrent complètement la définition d'intention avec des règles de conversion qui contrôlent le robot pour exécuter des tâches fixes. -point d'intentions disponibles Séparation, cela présente les avantages suivants :

1. Les intentions précédentes peuvent être réutilisées dans le nouveau robot, même si le chemin de dialogue est défini différemment.
2. Des flux de dialogue complexes peuvent être définis à l'aide de machines à états, permettant au bot de maintenir une sémantique claire et précise.
3. Des gardes d'État complexes peuvent être créés pour contrôler les transitions. Déplacez le bot vers un nouvel état en fonction des entrées de l'utilisateur, des événements à venir et des données précédentes, des paramètres de conversation, etc.
4. Les organismes d'état peuvent être utilisés pour stocker une logique de conversation complexe en réponse aux demandes des utilisateurs.
5. Les robots peuvent être modularisés pour réutiliser des parties de la machine d'état dans d'autres robots.
6. Les solutions de secours locales peuvent être définies dans le cadre d'un comportement avec état. En plus du repli global par défaut, vous pouvez également associer des secours locaux à des états pour gérer les erreurs dans le contexte de l'état, comme l'affichage d'un message pour aider l'utilisateur à répondre à une question posée par le bot à un état spécifique de la conversation.

Langage de définition d'intention

La définition d'intention est désormais découplée de la partie exécution, mais reste un sous-langage distinct. Pour chaque intention, il nous suffit de fournir quelques phrases d'entraînement afin que le robot puisse reconnaître l'intention de l'énoncé de l'utilisateur et en extraire les paramètres requis.

À titre d'exemple, nous avons un robot simple qui ne comprend que deux types d'énoncés des utilisateurs : les salutations et la mention des noms. Nous pouvons fournir plusieurs exemples de phrases pour chaque type d’énoncé et laisser le robot apprendre à les reconnaître. Lorsque l'utilisateur saisit un énoncé, le robot effectue l'action correspondante en fonction de son intention et en extrait les paramètres requis.

intent Hello {
inputs {
"你好"
"早上好"
}
}
 
intent MyNameIs {
inputs {
"我的名字叫小明"
"我是小明"
"你可以叫我小明"
}
creates context Greetings {
set parameter name from fragment "小明" (entity any)
}
}

Nous fournissons quelques exemples de phrases pour chaque intention afin d'entraîner le robot à les reconnaître. En outre, dans certains cas, nous collectons également certains paramètres dans le contexte (par exemple, le nom de l'utilisateur) afin de pouvoir répondre plus personnellement à l'utilisateur à l'avenir.

Nous n’avons pas précisé à quelle intention le bot doit essayer de correspondre en premier, cela fait partie du langage d’exécution. Cette approche nous permet de réutiliser ces intentions (par exemple, dans un autre bot, nous pourrions avoir besoin de demander à l'utilisateur son nom, pas seulement après l'intention de salutation).

Langage de définition d'exécution

Utilisez des fichiers d'exécution pour définir une machine à états qui décrit comment le robot répond aux intentions/événements et peut effectuer des transitions. Cela permet au concepteur du bot de visualiser le fichier d'exécution et de comprendre l'intégralité du flux de conversation.

Chaque état dans le langage d'exécution contient 3 parties

• Corps (facultatif) : la réaction que le robot effectue en entrant dans l'état.
• Suivant (obligatoire) : définit la conversion sortante, exprimée par condition -> État. Lorsqu'un événement/une intention est reçu, la condition est évaluée et si la transition est remplie, le moteur d'exécution passe à l'état spécifié et exécute sa réaction correspondante. Il est à noter que les conditions de conversion peuvent être très complexes. Ce sont de véritables gardiens, ce qui signifie que si l'ensemble de la condition n'est pas vrai, la transition n'est pas navigable et le moteur restera dans son état actuel.
• Fallback (facultatif) : Cette section peut contenir du code arbitraire (tout comme la section Body) qui sera exécuté si le moteur ne trouve pas de transition navigable.

Le modèle d'exécution contient également 2 états spéciaux :

• Init：是创建用户会话时进入的常规状态。它可以包含 Body、_Next_和 Fallback 部分。
• Default_Fallback：它只能包含 Body 部分，并且不能作为转换的目标状态。该状态表示在当前状态中未定义本地回退时执行的默认回退代码。该状态可用于打印通用错误消息（例如，“抱歉，我没明白您的意思”），而本地回退则可以打印针对当前状态的定制消息（例如，“请回答是或否”）。

最后，一个状态可以定义一个单一的通配符转换（使用保留字符___作为转换条件），当计算状态主体时将自动导航。这使我们能够在多个地方重用相同的代码并模块化执行逻辑。下面是一个简单的机器人示例，它只回复问候意图，询问用户名并向用户问好。这个机器人的回复可以通过我们基于 React 的聊天小部件显示。

//We can always have an init state in case we need to initialize some bot parameters (e.g. welcoming message)
Init {
Next { 
//Here we state that the bot will first listen for an utterance matching the Hello intent, it will ignore anything else
intent == Hello --> HandleHello
}
}
HandleHello {
Body {
 ReactPlatform.Reply("你好, 你叫什么名字?")
}
Next {
//We wait for the user to input the name, no other transition is possible at this point
//Obviously, in more complex bots we may have several possible outgoing transitions in a given state
intent == MyNameIs --> HandleMyNameIs
}
}
HandleMyNameIs {
Body {
ReactPlatform.Reply("你好 " + context.get("Greetings").get("name"))
}
Next {
// An automatic transition to the Init state since at this point the conversation is finished and we can start again
_ --> Init
}
}
// Default Fallback state could go here

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!