In order to better understand the needs and improvement directions of intelligent robot projects, we often need to develop some tools. Of the several robotics projects I've been involved in, most have been successful in meeting product requirements. Through these practices, we deeply realized that if we want to continue to progress and improve, we must make significant improvements to the existing robot definition language.
In traditional practices, it is not easy to accomplish this because Intent definitions are mixed with partial ordering constraints, limiting the freedom of conversation paths. This is sufficient for handling "open" bots (common in FAQ style bots) where most questions are self-contained and always available. But for more "closed" bots, the potential conversational limitations are much greater (such as for a bot that orders tickets from online).
In order to bring the functionality of the chatbot definition language to a new level, in some projects we have introduced DSLs that are closer to state machine semantics and fully define the intent Separating from the conversion rules that control the robot to execute fixed-point available intentions, this has the following advantages:
Intent definition is now decoupled from the execution part, but is still a separate sub-language. For each intent, we only need to provide some training sentences so that the robot can recognize the intent of the user's utterance and extract the required parameters from it.
As an example, we have a simple bot that understands only two types of user utterances: greetings and stating names. We can provide a few example sentences for each utterance type and let the robot learn how to recognize them. When the user enters an utterance, the robot performs the corresponding action based on its intent and extracts the required parameters from it.
intent Hello { inputs { "你好" "早上好" } } intent MyNameIs { inputs { "我的名字叫小明" "我是小明" "你可以叫我小明" } creates context Greetings { set parameter name from fragment "小明" (entity any) } }
We provide some sample sentences for each intent to train the robot how to recognize them. In addition, in some cases we also collect some parameters in the context (for example, the user's name) so that we can respond to the user more personally in the future.
We haven't specified which intent the bot should try to match first, that's part of the execution language. This approach allows us to reuse these intents (for example, in another bot we might need to ask the user for their name, not just after the greeting intent).
Use execution files to define a state machine that describes how the robot responds to intents/events and can make transitions. This allows the bot designer to view the execution file and understand the entire conversation flow.
Each state in the execution language contains 3 parts
The execution model also contains 2 special states:
最后,一个状态可以定义一个单一的通配符转换(使用保留字符___作为转换条件),当计算状态主体时将自动导航。这使我们能够在多个地方重用相同的代码并模块化执行逻辑。下面是一个简单的机器人示例,它只回复问候意图,询问用户名并向用户问好。这个机器人的回复可以通过我们基于 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
The above is the detailed content of Summary of experience in chatbot design based on state machine. For more information, please follow other related articles on the PHP Chinese website!