提供良好的错误恢复

[Microsoft 代理从 Windows 7 开始已弃用，可能在后续版本的 Windows 中不可用。]

与任何设计良好的接口一样，交互式进程应尽量减少导致错误的情况。 但是，几乎不可能消除所有错误，因此支持良好的错误恢复对于维护用户的信心和兴趣至关重要。 通常，错误恢复涉及检测错误、确定原因以及定义解决错误的方法。 用户对协作接口的响应更好，这些接口与用户合作完成任务。

语音错误恢复的第一步是检测故障条件。 语音识别可能由于各种错误而失败。 错误条件通常可以检测为无效输入、显式用户更正或取消或用户重复的结果。

如果识别引擎与用户所说的内容不匹配，则会发生 拒绝错误 。 背景噪音或提前启动也是识别失败的常见原因，因此要求用户重复命令通常是一个很好的初始解决方案。 但是，如果该短语不在当前活动语法之外，则要求用户重新编写请求可能会解决问题。 措辞的差异可能会导致与当前语法中的某些内容匹配。 列出或建议适当的预期输入选项是另一种替代方法。

拒绝错误恢复的一个好策略是结合这些技术使用户回到正轨，在故障仍然存在时提供越来越多的帮助。 例如，你可以首先使用“Huh？”或“What？”或手到耳朵手势来响应初始失败。 短响应会增加用户重复语句不会因为用户发言太快而失败的可能性。 反复失败时，后续重新请求可提高在给定语法中匹配某些内容的机会。 在此处，提供已接受命令的显式提示会进一步增加匹配的可能性。 以下示例演示了此方法：

用户：我想吃一个芝加哥风格的披萨和凤尾鱼。

人物： (手对耳) 呼？

用户：我想吃芝加哥披萨和凤尾鱼。

字符： (摇头) 请重新请求。

用户：我说芝加哥披萨，有凤尾鱼。

人物： (耸肩) 对不起。 告诉我你想要的披萨风格。

用户：芝加哥，有凤尾鱼。

性格： 仍然没有运气。 你可以说：“芝加哥”、“夏威夷”或“组合”。

若要使错误处理更加自然，请确保在响应错误时提供一定程度的随机变化。 此外，用户对重复响应的任何请求的自然反应是在重复语句时夸大或增加音量。 偶尔提醒用户正常且清晰地说话可能很有用，因为夸大或音量增加可能会使语音引擎更难识别单词。

渐进式协助应该做的不仅仅是将错误引起用户的注意;它应该通过连续提供更多信息性的消息来引导用户使用当前语法说话。 似乎正在尝试理解的接口会鼓励用户高度的满意度和容忍度。

替换错误（其中语音引擎识别输入但匹配错误的命令）更难解决，因为语音引擎检测到匹配的话语。 当语音引擎将无关声音解释为有效输入 (也称为 插入错误) 时，也可能发生不匹配。 在这些情况下，需要用户的帮助来识别错误情况。 为此，可以重复语音引擎返回的内容，并要求用户在继续之前进行确认：

用户：我想吃芝加哥风格的披萨。

人物：你说你想要一个“芝加哥风格的比萨饼”吗？

用户：是。

性格： 你想在它上添加哪些额外的成分？

用户：凤尾鱼。

人物：你说“凤尾鱼”吗？

用户：是。

但是，将此方法用于每个言语会变得效率低下且令人厌烦。 若要处理此问题，请将确认限制为具有重大负面后果或增加直接任务的复杂性的情况。 如果用户很容易做出或撤销更改，则可以避免请求确认他们的选择。 同样，如果使选项可见，则可能不需要提供显式更正。 例如，从列表中选择项可能不需要验证，因为用户可以查看结果并轻松更改结果。 还可以使用置信度和备用分数来提供确认阈值。 可以通过在给定情况下保留用户操作的历史记录并基于一致的用户确认消除验证来调整阈值。 最后，请考虑接口的多模式性质。 鼠标或键盘的确认也可能合适。

请仔细选择确认的措辞。 例如，“你说了...？”或“我想你说了...”。优于“你真的想...？”，因为以前的短语意味着正在查询角色的听力 (识别) 的准确性，而不是用户可能错了。

还要考虑响应的语法。 例如，负响应可能会生成拒绝错误，需要额外的提示，如以下示例所示：

用户：我想要一些胡椒粉。

人物：你说“没有火腿”吗？

用户：不，我说胡椒粉。

人物：嗯？

用户：胡椒粉。

修改语法以包含前缀以处理自然响应变化可以提高恢复过程的效率，尤其是在用户未确认验证提示时。 在此示例中，可以通过修改“pepperoni”的语法，通过包括“no i said pepperoni”、“I said pepperoni”和“no pepperoni”，在一个步骤中处理确认。

还可以使用语音引擎返回的替代匹配项作为纠正确认来处理替换错误：

用户：我想要一些胡椒粉。

人物： (听到“没有火腿”作为最佳匹配，“胡椒粉”作为第一选择) 你说“没有火腿”吗？

用户：否，胡椒粉。

角色： (仍然听到 “没有火腿” 作为最佳匹配， 但现在提供第一个替代) “胡椒”？

同样，可以保留常见替换错误的历史记录，如果特定错误频繁出现，请第一次提供替代项。

在任何识别错误情况下，请避免指责用户。 如果字符建议或甚至暗示用户要追溯，或者该字符似乎对错误无动于衷，则用户可能会受到冒犯。 在这里，仔细选择明确接受责任的措辞，适合情况，并用各种方式创造更自然的回应。 在表示道歉时，请避免“哎唉”或“uh-oh”等模棱两可解释为指责用户的不明确词语。 请改用“对不起”或“我的错误”等短语。重复或更严重的错误可能会使用更详细的道歉，如“我真的很抱歉。在确定响应类型时，还要考虑字符的个性。 另一种选择是追溯外部情况。 评论，如“男孩，那里很吵”，将追溯从用户和角色中移开。 提醒用户交互的合作性质可能也有帮助：请考虑诸如“让我们看看我们能做些什么来使此工作”等短语。

Microsoft 代理还支持一些用于识别的自动反馈。 检测到言语时，“听觉提示”将显示听到的最佳匹配项的语音文本。 你可以根据定义的命令的置信度设置，将自己的文本设置为显示。

由于可能存在错误，因此始终要求确认任何具有严重负面后果且不可逆的选项。 当然，当操作的结果可能具有破坏性时，你需要进行确认。 但是，对于中止任何冗长进程或操作的情况，请考虑要求确认。