为了更好地了解智能机器人项目的需求和改进方向,我们常常需要研发一些工具。在我参与的多个机器人项目中,大多数都能够成功地满足产品需求。通过这些实践,我们深刻认识到,如果要不断进步和提高,就必须对现有的机器人定义语言进行重大的改进。
在传统的做法中,完成这些并不容易,因为意图定义与部分排序约束混合在一起,限制了对话路径的自由度。这对于处理“开放式”机器人(常见于FAQ样式的机器人),其中大多数问题是独立的且始终可用的,这已经足够了。但对于更“封闭”的机器人来说,潜在的对话限制要多得多(比如用于从在线订票机器人)。
为了将聊天机器人定义语言的功能提升到一个新的水平,在一些项目中我们引进了更接近状态机语义的DSL,并完全将意图定义与控制机器人执行定点可用意图的转换规则分离,这么做有以下优势:
意图定义现在与执行部分解耦,但仍然是一个单独的子语言。对于每个意图,我们只需提供一些训练句子,让机器人能够识别出用户话语的意图,并从中提取所需的参数。
举个例子,我们有一个简单的机器人,它只能理解两种类型的用户话语:问候和陈述姓名。我们可以为每种话语类型提供几个示例句子,让机器人学会如何识别它们。当用户输入一个话语时,机器人会根据它的意图执行相应的操作,并从中提取所需的参数。
intent Hello { inputs { "你好" "早上好" } } intent MyNameIs { inputs { "我的名字叫小明" "我是小明" "你可以叫我小明" } creates context Greetings { set parameter name from fragment "小明" (entity any) } }
我们为每种意图提供一些样本句子,来训练机器人如何识别它们。此外,在某些情况下,我们还会在上下文中收集一些参数(例如,用户的姓名),以便以后能够更个性化地回答用户。
我们还没有具体说明机器人应该先尝试匹配哪种意图,这是执行部分语言的内容。这种方法使我们能够重复利用这些意图(例如,在另一个机器人中,我们可能需要询问用户的姓名,而不仅仅是在问候意图之后)。
使用执行文件来定义一个状态机,描述机器人如何响应意图/事件,并且可以进行转换。这使得机器人的设计者可以查看执行文件,了解整个对话流程。
执行语言中的每个状态包含 3 个部分
执行模型还包含 2 个特殊状态:
最后,一个状态可以定义一个单一的通配符转换(使用保留字符___作为转换条件),当计算状态主体时将自动导航。这使我们能够在多个地方重用相同的代码并模块化执行逻辑。下面是一个简单的机器人示例,它只回复问候意图,询问用户名并向用户问好。这个机器人的回复可以通过我们基于 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
以上是基于状态机的聊天机器人设计经验总结的详细内容。更多信息请关注PHP中文网其他相关文章!