Alexa 意图架构问题
Alexa intent schema issues
我一直在玩 Alexa 技能,并希望做一些基本的家庭自动化。我已经定义了以下基本意图模式来开始:
{
"intents": [
{
"intent": "Lock",
"slots": [
{
"name" : "Door",
"type" : "AMAZON.LITERAL"
}
]
},
{
"intent": "Unlock",
"slots": [
{
"name" : "Door",
"type" : "AMAZON.LITERAL"
}
]
}
]
}
然后是示例话语:
Lock lock {slot value|Door}
Lock lock door {slot value|Door}
Lock lock the door {slot value|Door}
Unlock unlock {slot value|Door}
Unlock unlock door {slot value|Door}
Unlock unlock the door {slot value|Door}
想法是门名必须是自由格式的,因为它们不会提前知道。然而,当我尝试像这样的短语时:
lock door front
它找到了正确的意图,但是 "Door" 槽值包含额外的词:
"intent": {
"name": "Lock",
"slots": {
"Door": {
"name": "Door",
"value": "door front"
}
}
}
这是正常现象,还是使用 AMAZON.LITERAL 的副产品?我也尝试过自定义插槽类型,但多词设备名称似乎不太适用,在这种情况下它总是使用最后一个词。
我会将话语定义为以 'door' 字结尾:
Lock lock {slot value|Door} door
因此,用户将不得不说:
Alexa, ask Lock lock kitchen door
所以您很可能只会收到一个词作为门类型。然后你解析字符串。您可能想要测试的不是完全相等,而是包含。
我必须承认我从不使用 LITERAL 类型,因为亚马逊教程不建议这样做,所以我会定义一个自定义类型并列出门类型的可能值。
转向on/offlights/thermostats是另一回事。为此,您必须使用 Alexa SmartHome API。那么'turn on/off'、'set value'等就成为了Alexa的保留关键字。在 SmartHome API 中不会有这样的意图(在你的问题中),没有话语,也没有自定义插槽类型。您只需要实现处理 Discovery
请求和 Control
请求。我认为用户在设备供应商的官方 apps/accounts 中设置设备名称,当 Alexa 发现设备(由于 Discovery
请求)时,该技能只是从供应商服务器获取设备描述并将其提供给 Alexa。这就是 Alexa 知道可用设备名称的方式。
更新:我对 LITERAL 即将下架的评论已过时。感谢您指出。文字将保留。但是 Alexa(和 Lex)做的 return 插槽值不在插槽列表中。我经常看到这个。挺好的
对于那些可能偶然发现这个问题的人,请知道使用 AMAZON.LITERAL will no longer be approved starting in December, 2016. You should use custom slots 的技能。有趣的是,文档说即使使用自定义插槽,您也可以接收自定义列表中未定义的单词,例如文字。我没有对此进行测试,但它可能会派上用场。
Alexa 在找到第一个匹配项时停止。所以你需要把更笼统的话语移到更具体的话语之后。
锁锁门{槽值|门}
锁锁{槽值|门}
这样 "lock door front" 与插槽 = "front" 匹配。
如果您有任何没有空位的话语,请务必将它们放在最后。
我一直在玩 Alexa 技能,并希望做一些基本的家庭自动化。我已经定义了以下基本意图模式来开始:
{
"intents": [
{
"intent": "Lock",
"slots": [
{
"name" : "Door",
"type" : "AMAZON.LITERAL"
}
]
},
{
"intent": "Unlock",
"slots": [
{
"name" : "Door",
"type" : "AMAZON.LITERAL"
}
]
}
]
}
然后是示例话语:
Lock lock {slot value|Door}
Lock lock door {slot value|Door}
Lock lock the door {slot value|Door}
Unlock unlock {slot value|Door}
Unlock unlock door {slot value|Door}
Unlock unlock the door {slot value|Door}
想法是门名必须是自由格式的,因为它们不会提前知道。然而,当我尝试像这样的短语时:
lock door front
它找到了正确的意图,但是 "Door" 槽值包含额外的词:
"intent": {
"name": "Lock",
"slots": {
"Door": {
"name": "Door",
"value": "door front"
}
}
}
这是正常现象,还是使用 AMAZON.LITERAL 的副产品?我也尝试过自定义插槽类型,但多词设备名称似乎不太适用,在这种情况下它总是使用最后一个词。
我会将话语定义为以 'door' 字结尾:
Lock lock {slot value|Door} door
因此,用户将不得不说:
Alexa, ask Lock lock kitchen door
所以您很可能只会收到一个词作为门类型。然后你解析字符串。您可能想要测试的不是完全相等,而是包含。 我必须承认我从不使用 LITERAL 类型,因为亚马逊教程不建议这样做,所以我会定义一个自定义类型并列出门类型的可能值。
转向on/offlights/thermostats是另一回事。为此,您必须使用 Alexa SmartHome API。那么'turn on/off'、'set value'等就成为了Alexa的保留关键字。在 SmartHome API 中不会有这样的意图(在你的问题中),没有话语,也没有自定义插槽类型。您只需要实现处理 Discovery
请求和 Control
请求。我认为用户在设备供应商的官方 apps/accounts 中设置设备名称,当 Alexa 发现设备(由于 Discovery
请求)时,该技能只是从供应商服务器获取设备描述并将其提供给 Alexa。这就是 Alexa 知道可用设备名称的方式。
更新:我对 LITERAL 即将下架的评论已过时。感谢您指出。文字将保留。但是 Alexa(和 Lex)做的 return 插槽值不在插槽列表中。我经常看到这个。挺好的
对于那些可能偶然发现这个问题的人,请知道使用 AMAZON.LITERAL will no longer be approved starting in December, 2016. You should use custom slots 的技能。有趣的是,文档说即使使用自定义插槽,您也可以接收自定义列表中未定义的单词,例如文字。我没有对此进行测试,但它可能会派上用场。
Alexa 在找到第一个匹配项时停止。所以你需要把更笼统的话语移到更具体的话语之后。
锁锁门{槽值|门} 锁锁{槽值|门}
这样 "lock door front" 与插槽 = "front" 匹配。
如果您有任何没有空位的话语,请务必将它们放在最后。