Google Assistant 2021.1.15起fallback intent变更及@sys.any相关问题问询

核心结论：这类intent并不存在“强制低于其他普通intent”的硬编码优先级规则

• Dialogflow的intent匹配全程基于动态语义匹配打分逻辑排序，没有预设的固定优先级层级。哪怕是配置了@sys.any的宽泛匹配intent，只要用户输入和某个带明确训练短语的普通业务intent的语义匹配得分更高、达到触发阈值，就会优先命中对应的普通业务intent。
• 开发者普遍感知到“带@sys.any的intent匹配率低”，本质原因是这类intent通常没有配置细分的业务训练语料，自然语义匹配分低于带明确语料的普通intent，并非平台强制为这类intent设置了更低的优先级。

结合谷歌Actions on Google的最新调整，整套对话流转的判断顺序是固定的：

1. 首先执行Dialogflow本地intent匹配流程：按照语义匹配分从高到低排序，依次判断是否命中所有普通业务intent（包括自定义的带@sys.any的宽泛捕获intent）。只要在这一步命中了任意普通intent，后续的系统拦截流程就不会启动。
2. 只有当所有普通业务intent都没有达到匹配阈值、用户查询最终落到系统内置的Fallback intent/NO_MATCH intent时，才会触发Assistant的原生能力判断流程：
   • 如果用户查询可以被天气、时间这类Assistant原生功能响应，系统会直接由原生能力回复用户，不会将请求转发到开发者的Action服务
   • 如果原生能力也无法响应该查询，请求才会回到开发者的Fallback处理逻辑中执行

• 逻辑拆分：彻底放弃用系统内置Fallback intent承担全量用户输入收集的功能，按照官方指引将内置Fallback的作用收敛为仅做Action语境下的操作重提示，比如“我没听清和当前任务相关的要求，请再说一遍”。
• 自定义捕获层：专门创建一个用于全量输入捕获的普通intent，配置3-5条通用的非业务相关训练短语，搭配@sys.any实体标记到intent的参数位置上，适配宽泛文本的捕获能力。
• 阈值适配：根据自身业务的匹配精度需求，适当调低这个自定义捕获intent的匹配置信度阈值，确保在没有命中明确业务intent的场景下，这个intent可以稳定触发。
• 逻辑迁移：将原本部署在内置Fallback intent里的全量输入处理逻辑，全部迁移到这个自定义捕获intent对应的webhook流程中。因为这个intent不属于系统标记的Fallback类特殊intent，不会触发Assistant的原生功能拦截，所有被它捕获的用户输入都会正常流转到开发者的服务端处理。

内容的提问来源于stack exchange，提问作者greywolf82