我的理解是亚马逊ASK仍然没有提供：
-
原始用户输入
-
后备意图的选项
-
一个API，用于动态添加可能的选项，从中可以更好地通知Alexa选择意图 .
这是正确的还是我错过了解一些关键能力？
Google w / Dialogflow上的操作提供：
-
用于分析的原始用户输入：request.body.result.resolvedQuery
-
动态添加用户表达式的APi（又名样本话语）：PUT /intents/
这些工具使开发人员能够检查所识别的意图是否正确以及是否修复 .
我知道之前有很多问题，只有几个问题：
How to add slot values dynamically to alexa skill
Can Alexa skill handler receive full user input?
Amazon Alexa dynamic variables for intent
我的Alexa技能用户比我的AoG应用程序用户多得多，因为亚马逊_362851已经等待了近一年的新Alexa功能，认为在亚马逊指导不使用AMAZON.LITERAL后，自定义插槽会有改进 . 到目前为止它看起来仍然是this old blog post仍然是给出的唯一指导 . 使用Google，我可以动态地从一个数据库中提取话语选项，这些数据库是在帐户链接后为给定用户定制的 . 通过拥有用户的原始输入，我可以在必要时更正意图的选择 .
如果你想要这些功能但不得不在没有它们的情况下前进，那么当你不知道用户会说什么时，你需要用什么技巧来获得与亚马逊的准确意图处理？
编辑11/21/17：亚马逊于9月宣布推出Alexa技能管理API（SMAPI），该API确实提供了上述第3个子弹 .
2 回答
让我直接回答你的3个问题：
1）Alexa确实通过插槽类型AMAZON.Literal提供原始输入，但建议's now deprecated and you'使用AMAZON.SearchQuery进行自由形式捕获 . 但是，如果不使用SearchQuery而是定义自定义插槽类型并提供样本（训练数据），ASR将更好地工作 .
2）Alexa支持FallbackIntent因为我相信2018年5月 . 它的工作方式是自动为您的技能生成模型，其中域外请求通过回退意图进行路由 . 它运作良好
3）动态添加插槽类型值是不可行的，因为当您提供样本时，您实际上正在为模型提供训练数据，而不是能够处理超出您定义的值的类似值 . 如果您注意到何时提供语音交互模型架构，则必须构建模型（在此步骤中，样本中提供的训练数据用于创建模型） . 举一个例子，当你定义一个类型为“Car”的自定义插槽并提供样品“Toyota”，“Jeep”，“Chevrolet”和“Honda”时，如果用户说“系统”，那么系统也将采用相同的意图 . 福特”
注意：SMAPI允许获取和更新交互模型，因此从技术上讲，您可以通过API下载模型，使用新的训练数据对其进行修改，再次上载并重建模型 . 这有点尴尬
实际上这应该是更好的评论，但我写在stackoverflow更少能够评论 . 我和你在一起 . 但Amazons Alexa也取得了很大的进步 .
意图Schema似乎直接影响Voice to Text识别 . 顺便说一句 . 有人可以确认这是否正确？
在Google Home，似乎并非如此 . 所以不寻常的名字匹配比alexa更复杂 . 它有时候只是承认绝对的废话 .
目前还不确定我最喜欢哪个 .
我觉得小型应用程序的Alexa要好得多，因为当它的选择较少时，它会更好地匹配Intent短语 . 但对于大型的Intent模式，它确实很麻烦，而且在我的测试中，一些意图根本没有匹配 .
谷歌家庭和动作SDK可能在这里赢了吗？原因语音文本似乎在之前完成，而不是字符串模式发生意图模式匹配 . 那么这对于更大的模式来说可能更强大？
To get something like an answer on your questions:
您可以尝试尽可能多地添加可以说是一个插槽 . 而不是通过Jaro winkler或其他字符串距离将Alexa请求的结果与您的数据库匹配 .
我试过Alexa是为了找到与用户说的很接近的短语 . 而这我作为填充插槽的短语添加 .
因此，我们网页中的模块是模式中的一个意图 . 并且比我要求说出该模块应该做什么（这是插槽填充请求） . 答案是填补话语的插槽 .
对我而言，这比普通的意图模式稍好一些 . 但它需要更多的谈话，所以我不喜欢它 .