Home  >  Article  >  Technology peripherals  >  Summary of experience in chatbot design based on state machine

Summary of experience in chatbot design based on state machine

WBOY
WBOYforward
2023-04-11 18:31:031517browse

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.

  • Simplify the creation process of bots that require complex conversation flows.
  • Maximize reusability by reusing modules and conversation paths that have been defined in the past to create bots

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).

Summary of experience in chatbot design based on state machine

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:

  1. Previous intentions can be reused in the new robot, even if the dialogue path set is different.
  2. State machines can be used to define complex conversation flows, allowing the bot to maintain clear and precise semantics.
  3. Complex state guards can be created to control transitions. Move the bot to a new state based on user input, upcoming events and previous data, conversation parameters, etc.
  4. State bodies can be used to store complex conversation logic in response to user requests.
  5. Robots can be modularized to reuse parts of the state machine in other robots.
  6. Local fallback can be defined as part of stateful behavior. In addition to the default global fallback, you can also associate local fallbacks with states to handle errors in the context of the state, such as displaying a message to help the user answer a question asked by the bot at a specific state in the conversation.

Intent Definition Language

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).

Execution Definition Language

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

  • Body (optional): The reaction that the robot performs when entering the state.
  • Next (required): Defines outbound conversion, expressed as condition –> State. When an event/intent is received, the condition is evaluated and if the transition is met, the execution engine moves to the specified state and executes its corresponding reaction. It should be noted that conversion conditions can be very complex. They are true guards, meaning that if the entire condition is not true, the transition is not navigable and the engine will remain in its current state.
  • Fallback (optional): This section can contain arbitrary code (just like the Body section) and will be executed if the engine cannot find a navigable transition these codes.

The execution model also contains 2 special states:

  • 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


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!

Statement:
This article is reproduced at:51cto.com. If there is any infringement, please contact admin@php.cn delete