CN114724564A - 语音处理方法、装置和系统 - Google Patents

Abstract

公开了一种语音处理方法、装置和系统。该语音处理方法包括：获取语音信息；将获取的语音信息输入云端语音处理引擎和本地语音处理引擎；根据离在线仲裁规则，确定要使用的语音处理结果；以及基于确定的语音处理结果执行相应操作。本发明通过将语音流同时输入云端引擎和本地引擎，并且通过合理设置的离在线仲裁策略选择恰当的在线或离线处理结果。为此，能够实现针对离在线处理结果选择的动态实时决策，并且不受弱网环境以及应用与云端连接情况的影响。

Description

语音处理方法、装置和系统

本发明涉及信息处理领域，尤其涉及一种语音处理方法、装置和分布式系统。

背景技术

一般地，终端的语音交互设备可以将所接收到的语音上传到云端，借助云端强大的处理能力进行语音识别和自然语言理解。或者，在联网条件不佳或是应用场景较为简单的情况下，语音交互设备也可以在本地完成整个语音交互链路。为此，如何恰当选择在线(云端)或离线(本地)处理结果进行操作，成为了本领域要解决的一个问题。

发明内容

本公开要解决的一个技术问题是提供一种语音处理方案，该方案将语音流同时输入云端引擎和本地引擎，并且通过合理设置的离在线仲裁策略选择恰当的在线或离线处理结果。为此，能够实现针对离在线处理结果选择的动态实时决策，并且不受弱网环境以及应用与云端连接情况的影响。

根据本公开的第一个方面，提供了一种语音处理方法，包括：获取语音信息；将获取的语音信息输入云端语音处理引擎和本地语音处理引擎；根据离在线仲裁规则，确定要使用的语音处理结果；以及基于确定的语音处理结果执行相应操作。

根据本公开的第二个方面，提供了一种语音处理装置，包括：语音信息获取单元，用于获取语音信息；本地语音处理引擎，用于将获取的语音信息进行本地语音处理；通信单元，用于将获取的语音信息输入云端语音处理引擎；仲裁单元，用于根据离在线仲裁规则，确定要使用的语音处理结果；以及操作单元，用于基于确定的语音处理结果执行相应操作。

根据本公开的第三个方面，提供了种语音处理系统，包括：语音处理设备，用于执行如本发明第一方面所述的语音处理方法；以及服务器，包括所述云端语音处理引擎，并且用于基于获取的语音信息下发云端语音处理结果。

根据本公开的第四个方面，提供了一种计算设备，包括：处理器；以及存储器，其上存储有可执行代码，当可执行代码被处理器执行时，使处理器执行如上述第一方面所述的方法。

根据本公开的第五个方面，提供了一种非暂时性机器可读存储介质，其上存储有可执行代码，当可执行代码被电子设备的处理器执行时，使处理器执行如上述第一方面所述的方法。

由此，本发明提供了一套基于离在线的语音处理结果选择方案。该方案同时进行本地和云端语音处理流程，并根据处理结果的时效性和置信度进行实时决策，能够始终为用户提供及时准确的语音处理结果。

附图说明

通过结合附图对本公开示例性实施方式进行更详细的描述，本公开的上述以及其它目的、特征和优势将变得更加明显，其中，在本公开示例性实施方式中，相同的参考标号通常代表相同部件。

图1示出了根据本发明一个实施例的语音处理方法的示意性流程图。

图2示出了语音交互链路的处理流程示意图。

图3示出了根据本发明的语音处理方法的流程执行例。

图4示出了根据本发明的离在线仲裁规则的一个例子。

图5示出了弱网情况下同时进行云端和本地流程的一个例子。

图6示出了根据本发明一个实施例的语音处理装置的组成示意图。

图7示出了能够实现本发明的语音处理系统的组成示意图。

图8示出了根据本发明一个实施例可用于实现上述语音处理方法的计算设备的结构示意图。

具体实施方式

下面将参照附图更详细地描述本公开的优选实施方式。虽然附图中显示了本公开的优选实施方式，然而应该理解，可以以各种形式实现本公开而不应被这里阐述的实施方式所限制。相反，提供这些实施方式是为了使本公开更加透彻和完整，并且能够将本公开的范围完整地传达给本领域的技术人员。

终端的语音交互设备可以将所接收到的语音上传到云端，借助云端强大的处理能力进行语音识别和自然语言理解。对于家庭场景而言，网络服务稳定且成本低，针对语音交互的云端处理能够得到保障。但是对移动(例如，车载)场景而言，通常使用手机流量等移动网络提供接入。如果进隧道，地库，可能出现弱网或者无网的情况，导致云端连接不稳定。在云端服务不可靠时，需要使用不进行网络连接且不借助云端处理能力的本地语音处理服务。如何恰当选择在线(云端)或离线(本地)处理结果进行操作，成为了本领域要解决的一个问题。

在某些解决方案中，会使用ping(Packet Internet Groper，因特网包探索器)的方式来选择是否使用云端处理能力。具体地，ping可以用于确定本地主机是否能与另一台主机成功交换(发送与接收)数据包，再根据返回的信息，就能够推断网络是否通畅。在ping方式检测到网络不通时，则可切换至使用本地处理能力。但ping方式只能检查网络通路，不能判断反馈较慢的弱网，也不能判断应用的连接情况。

在其他一些解决方案中，可以使用配置文件来进行云端和本地处理的选择。但提前配置的文件不够灵活，无法涵盖各种特殊场景，并且不具备灵活应对的能力。

为此，本发明提供一种语音处理方案，该方案将语音流同时输入云端引擎和本地引擎，并且通过合理设置的离在线仲裁策略选择恰当的在线或离线处理结果。为此，能够实现针对离在线处理结果选择的动态实时决策，并且不受弱网环境以及应用与云端连接情况的影响。

图1示出了根据本发明一个实施例的语音处理方法的示意性流程图。上述语音方法可由具备云端接入能力和本地语音处理能力两者的任意设备或其上安装的应用执行，并且用于基于获取的语音信息，给出用户所需的正确操作。

在步骤S110，获取语音信息。在此，本地设备可以通过其内设置的或是外接的麦克风，直接通过语音采集来获取语音信息。在经由智能语音贴或是智能语音插座组成的语音采集网络中，本地设备可以经由短距离无线通信获取其他语音采集点采集到的语音信息。

在步骤S120，将获取的语音信息输入云端语音处理引擎和本地语音处理引擎。在某些实施例中，可以直接将采集或获取到的语音信息送入本地和云端引擎。在其他实施例中，还可以在前端对获取的语音信息进行一定的处理(例如，降噪和MFCC特征提取)，并将经过处理的语音信息送入云端和本地引擎。

为了方便理解，图2示出了语音交互链路的处理流程示意图。语音交互链路是指实现语音交互的过程中涉及到音频数据采集、前端信号处理、唤醒响应、语音识别、声纹识别、自然语言处理、语音合成单元模块，这些单元模块共同协作完成语音交互功能。在不同的应用场景中，可以会涉及上述交互链路中的部分或全部模块。例如，在按键唤醒的情况下，基于唤醒词的唤醒响应单元就不是必须的。另外，声纹识别和语音合成功能对于某些应用场景也并非是必须的。图2中仅示出了最为核心的单元模块，在其他的实现中，交互链路还可以包括诸如上述的唤醒响应和声纹识别等的功能模块。

如图2所示，音频采集到的用户语音经过语音识别模块产生语音识别结果，即用户话语对应的文本指令。语音识别也被称为自动语音识别(AutomaticSpeechRecognition,ASR)，是一种将语音(例如，用户输入的语音)转换为文本的技术。例如，经由ASR，可以将用户输入的语音“打开空调”转换为文字意义上的“打开空调”。随后，自然语言理解模块(NaturalLanguageUnderstanding,NLU)对用户话语进行语义解析。在此，自然语言理解是指将文本识别出其中含意的算法/系统。在语音处理系统中，NLU能将用户语音指令识别为特定的领域意图。在本发明中，也可以将NLU模块称为意图理解模块。领域是指自然语言理解领域中的某类特定问题，如天气、时间等，意图则是指自然语言理解领域中属于某领域的特定问题，如查询天气、查询时间、设置闹钟等。在理解了用户语音指令中的领域和意图之后，可以将上述领域和意图送入意图执行模型块，该模块可以根据NLU语义解析结果(即，特定领域和意图)选择需要执行的系统行为。例如，基于文本“打开空调”，NLU模块可以理解其语义意图是对“内设-车载空调”进行“启动”的操作。为了生成语音反馈，语音链路还可以包括自然语音生成模块(NaturalLanguageGeneration,NLG)，以根据系统行为结果生成自然语言或者说是系统话语。最后，生成的语言可由语音合成模块(Text-to-Speech,TTS)朗读给用户听。

在此，云端语音处理引擎和本地语音处理引擎各自至少需要具备如上语音链路中所提及的语音识别和自然语言理解能力。配备了ASR和NLU模块的语音处理引擎能够识别用户语音并理解语义背后的意图，从而使得后续操作得以执行。例如，在用户如上所述给出“打开空调”的语音输入时，语音处理引擎可以首先经由ASR识别出文本“打开空调”，并经由NLU理解文本“打开空调”的语义意图时对“内设-车载空调”进行“启动”的操作。此时，语音处理结果可以是生成空调开启指令，设备(例如，此处的智能汽车)于是可以基于该指令，执行打开空调的操作。可选地，语音处理引擎还可以基于NLG模块生成用于反馈的反馈语音指令。当车载空调被开启之后，TTS模块可以基于反馈的语音指令，生成“空调已打开”的语音反馈。

在步骤S130，根据离在线仲裁规则，确定要使用的语音处理结果。在此，可由系统预先设置离在线仲裁规则及其具体涉及的参数大小，也可由用户在设置页面上进行用户定制设置。上述离在线仲裁规则是用于确定在哪些情况下选择使用本地语音处理引擎生成的本地处理结果，哪些情况下选择使用云端语音处理引擎所生成的云端处理结果的规则。

随后，在基于确定的语音处理结果执行相应操作。如前所述，语音处理结果可以是理解输入语音意图后给出的反馈。上述反馈可以是执行特定的操作，例如，打开空调，也可以是进行相应的语音反馈，例如，报告“空调已打开“。

自此，将获取的语音信息输入云端语音处理引擎和本地语音处理引擎可以包括：在将获取的语音信息送入所述本地语音引擎的同时，向所述云端语音处理引擎发送所述语音信息。图3示出了根据本发明的语音处理方法的流程执行例。

如图所示，当用户唤醒语音助手后，语音流可以同时输入给云端引擎(通过网络)和本地引擎，随后，离在线仲裁规则根据本地和云端处理结果的返回情况，选择某一个处理结果进行执行。由此，通过始终进行云端和本地的端云同时灌流，并基于规则选择一个更恰当(通常是更快和/或更准确)的处理结果，能够根据处理结果的自身属性，进行动态实时决策，而不受弱网环境以及应用与云端连接情况的影响。

如前所述，用于进行云端和本地同时处理的语音信息可以是在用户唤醒语音助手之后所给出的语音命令。因此，步骤S110获取语音信息包括：获取语音助手被唤醒后接收到的语音信息。换句话说，在步骤S110之前，还包括监听唤醒词并被唤醒的步骤。

在某些实施例中，同一设备可以包括不同的语音助手。例如，在车载场景中，车辆的生产厂商通常会在配备的车载系统中包含语音助手功能。用户可以通过例如“你好XX(车名或车的昵称)”来唤醒车辆的原生语音助手。车辆的原生语音助手通常具备良好的车辆控制能力。但相比于一些专门的语音处理平台，车辆原生助手及其所依赖的云端处理能力在很多其他的场景(例如，导航、音乐欣赏、自由对话)下的意图理解能力较弱。为此，还可以额外接入专门的语音处理平台。上述平台的接入，可以通过不同的唤醒词实现。例如，用户除了可以通过说出例如“你好XX(车名或车的昵称)”来唤醒车辆的原生语音助手之外，还可以通过说出“XXXX(外接语音助手名)”来唤醒语音处理能力更为强大的外接语音助手。

此时，本发明的语音处理方法还可以包括：基于不同的唤醒词唤醒不同的语音助手。针对车辆上配备的一个硬件低功率唤醒模块，可以通过软件算法实现该唤醒模块对多个唤醒词的识别。不同的语音助手通常对应于不同的云端处理平台。为此，将获取的语音信息输入云端语音处理引擎和本地语音处理引擎包括：将获取的语音信息输入同一个本地语音处理引擎以及与被唤醒语音助手相对应的云端语音处理引擎。换句话说，不同的语音助理可以使用同一个本地语音处理引擎，其通常对应于同一个语音处理模块；并且可以各自经由通信单元连接不同的服务器(即，不同的云端处理平台)。用户可以在存在不同需求的情况下，通过说出对应的唤醒词，选择合适的语音助手进行交互。

如下将结合图4，对仲裁规则及其优选实施例进行描述，并且可以看作是对图1中步骤S130的细化。

图4示出了根据本发明的离在线仲裁规则的一个例子。如前所述，本发明的离在线仲裁规则是用于确定在哪些情况下选择使用本地语音处理引擎生成的本地处理结果(离线结果)，哪些情况下选择使用云端语音处理引擎所生成的云端处理结果(在线结果)的规则。由于针对语音进行反馈具有时效性的需求，为此本发明的离在线仲裁规则需要在确保准确性的情况下考虑时效的要求。

由于云端模型的处理能力比终端上的处理能力要强，因此如图4所示，在在云端处理结果先返回的情况下，优选使用所述云端处理结果作为确定要使用的语音处理结果。进一步地，为了避免算力的浪费，可以在同时取消所述本地语音处理引擎针对所述语音信息的当前处理流程。

进一步地，在本地处理结果先返回的情况下，则需要根据所述本地处理结果的置信度确定要使用的语音处理结果。例如，在本地处理结果具有一个相当高的置信度的情况下(例如，本地模型针对当前结果的判断概率很高的情况下)，可以认定本地处理结果可信，并对其进行直接使用。而在本地处理结果置信度有限的情况下，则需要结合云端处理结果返回的时效性进行选择。

具体地，当所述本地处理结果的置信度高于第一阈值(如图所示的本地结果精度大于90％)时，则可以认定本地处理结果可信，并使用所述本地处理结果作为确定要使用的语音处理结果。相应地，为了避免算力的浪费，可以在同时取消所述云端语音处理引擎针对所述语音信息的当前处理流程，例如，通过向服务器发送取消请求。

当所述本地处理结果的置信度低于第一阈值且高于第二阈值(如图所示的本地结果精度在60％～90％)时，则可以认定本地处理结果不那么可信，因此仍然优选使用云端结果，但云端结果的等待时间需要满足时效性要求。为此，在本地处理结果先返回的情况下，根据所述本地处理结果的置信度确定要使用的语音处理结果可以包括：当所述本地处理结果的置信度低于第一阈值且高于第二阈值时，继续等待云端处理结果至第一预定时间(如图所示的1.5秒)；如果在所述第一预定时间内，所述云端处理结果返回，则使用所述云端处理结果作为确定要使用的语音处理结果；以及如果在所述第一预定时间内，所述云端处理结果未返回，则使用所述本地处理结果作为确定要使用的语音处理结果。由此，在兼顾准确性的同时，考虑了针对语音进行反馈的时效性需求。类似地，对某一处理结果的选择，都可以同时触发对另一引擎流程的取消。

当所述本地处理结果的置信度低于第二阈值(例如，图中所示的60％)时，则可认为本地结果不可信，此时需要继续等待云端处理结果，并且可以相应地丢弃本地结果。进一步地，出于时效性的考虑，在本地处理结果不可信时，等待云端处理结果的第二预定时间可以长于(或者至少不短于)本地处理结果不那么可信时等待云端返回结果的第一预定时间。例如，在第一预定时间为1.5秒的情况下，第二预定时间可以是不引起用户不快的等待时长极限，例如3秒。如果在所述第二预定时间内，所述云端处理结果返回，则使用所述云端处理结果作为确定要使用的语音处理结果。而如果在所述第二预定时间内，所述云端处理结果未返回，则触发超时处理。

如上结合图1、3-4所述的语音处理方法适用于应对有网络连接但网络连接不佳的情况，例如弱网环境。进一步地，除了基于如上所述的离在线仲裁规则进行本地或云端处理结果选择之外，本发明的语音处理方法还可以基于对弱网环境的判断，提升弱网环境下获取云端处理结果的能力。

如前所述，本地处理引擎可以包括本地语音识别模块和本地自然语言处理模块。为了降低上行传输数据量，本发明的语音处理方法还可以包括：在满足预定条件下，将本地语音识别模块生成的本地语音识别结果作为语音信息的代替，上传给所述云端语音处理引擎。这是因为ASR识别出的文本数据量通常要小于直接上传语音流所需的数据量。

图5示出了弱网情况下同时进行云端和本地流程的一个例子。如图所示，在采集和上传阶段，本地设备的语音采集模块(以及，在某些实施例中，与本地设备通信的其他语音采集装置)监测来自用户或智能设备的语音命令输入，本地设备可以对采集的语音进行初步的处理，例如，降噪和特征提取。不同于图3所示直接将语音流同时输入本地引擎和云端引擎，此时由于判定网络状况不佳，可以只进行本地ASR拾取，并将拾取的语音命令传输至云端和本地NLU模块。在云端和本地的并行处理阶段，服务端可以对拾取的语音命令进行后续处理，例如NIP(自然语音处理)和NIU(自然语音理解)，并根据处理结果，进行命令解析和TTS输出。相应地，本地模块也可以对拾取的语音命令进行后续处理，例如NIP(自然语音处理)和NIU(自然语音理解)，并根据处理结果，进行命令解析和TTS输出。

在本地处理阶段，针对云端和本地各自生成的处理结果(例如，各自可以包括命令解析和/或TTS输出)，同样执行离在线仲裁策略。此时，由于云端结果的可信度仍然高于本地结果，因此同样可以执行云端结果优先并且兼顾时效性的仲裁策略。但由于在线结果并非全链路由云端计算得出，因此此时仲裁策略中的参数可以和图4所示的参数不同。

随后，仲裁得到的结果可用于本地执行。具体地，解析出的命令可以传输至本地设备出以供执行，也可以例如在经由本地设备的控制下由目标设备执行。另外，在存在音频输出时，语音装置可以通过自带扬声器或是外连的蓝牙或传统音箱进行语音输出。

由此，可以在侦测到弱网状态的情况下，通过直接向云端上传本地ASR识别出的文本，而非原始语音流，能够降低上行数据量，从而更好地实现弱网条件下的语音识别。在某些实施例中，除了上传本地ASR的概率最高的那条识别结果之外，也可以上传N-Best(即，多条优选识别结果)，以方便云端能够根据更多的ASR数据而得到更准确的NLU结果。

作为替换或者补充，还可以在弱网或是疑似弱网的情况下，对上传数据进行压缩，例如，用speex-ogg算法压缩语音流。

相应地，为了减少下行传输的数据，本发明还可以包括：在满足预定条件下，使得所述云端语音处理引擎下发数据量最小版本的云端处理结果。如前所述，云端语音处理引擎具有强大的语音处理功能。针对相同的语音输入，可以给出结合用户使用历史偏好、当前应用场景等的诸多不同版本的处理结果。例如，当用户询问“今天天气怎么样”时，可以给出简洁的播报内容，例如“今天晴，气温12-18°，东风2级”，也可以给出包含更多信息量的播报内容，例如“今天天气晴朗，气温12-18°，东风2级，相比前日降温6°，请注意增添衣物”。在判定弱网的情况下，本地设备可以向云端发送网络不佳的指示，从而使得云端语音处理引擎下发数据量最小版本的云端处理结果，以方便本地设备接收。在判定网络恢复之后，本地设备则可以向云端发送取消网络不佳的指示，以方便云端语音处理引擎给出最适合当前场景和用户的云端处理版本。

如上降低上下行传输数据量的操作，可以在满足预定条件下进行。换句话说，可以在满足上述预定条件的情况下推断当前的弱网条件，并据此进行相应的降低上行和/或下行传输数据量的操作。

在一个实施例中，所述预定条件可以包括：在第三预定时间内没有收到云端处理结果。上述第三预定时间可以是与第一和第二预定时间无关的预定时间，也可以与第一或第二预定时间有关。可以根据网络正常时的常规等待时间来确定第三预定时间。例如，数据上传云端后得到云端返回信息的常规得待时间为3秒，若在3秒内没有收到返回的处理结果，则可以认为当前网络状况不佳。此时，第三预定时间可以被设为3秒。在其他情况下，可以适当延长上述第三预定时间，例如，设为4秒。

作为补充，还可以仅仅在本地处理结果的置信度不高的情况下才进行如上所述的降低上下行数据量的操作，因此此时更有必要获取置信度更高的云端处理结果。为此，所述预定条件可以包括：所述本地处理结果的置信度低于第三阈值。上述第三阈值可以是与第一和第二阈值无关，也可以与第一或第二阈值相关。例如，可以将第三阈值设置为与第二阈值相同，即60％。

在某些情况下，进行降低上下行数据传输量的操作可以针对当前的语音处理进行，也可以针对后续的语音处理进行。

例如，智能车辆的用户可以在车辆行驶途中输入语音指令“把天窗打开”，本地ASR虽然能够准确识别出用户所说文本，但本地NLU无法识别把字句，因此导致本地处理结果置信度较低(例如，低于60％)。此时，由于用户在经过信号不佳路段，因此常规等待3S后仍然没有收到云端处理反馈(例如，是因为语音流上传尚未完成)。此时，本地设备可以新开一个请求，并直接向云端发送本地ASR识别文本。由于ASR识别结果数据量较小，率先完成上传，并且指示天窗开启的信号顺利下发。此时，在用户语音输入完成5秒后，天窗开始开启。由此，通过对当前语音数据的二次上传，虽然用户等待时间较长，但仍然在可容忍返回内完成了用户期望操作。

同样在用户语音输入“把天窗打开”的例子中，如果用户在等待3秒后因为没有得到反馈而进行二次语音输入“打开天窗”的情况下，由于此时本地NLU能够识别“动词+名词”的句式，从而给出高置信度的本地处理结果，此时也无需获取云端处理结果。但在不同实施例中，仍然可以同步进行语音流的云端上传，或是基于弱网的ASR识别结果上传。

应该理解的是，在针对弱网条件而调整上下行数据传输量时，需要在网络条件恢复时及时返回正常上下行数据传输。为此，例如可以在用户进行语音传输的间隙，在后台进行语音流发送和云端处理结果返回时间计算，并据此判断是否需要回到正常的本地云端双流程状态。

进一步地，本发明还可以实现为一种语音处理装置。图6示出了根据本发明一个实施例的语音处理装置的组成示意图。该装置例如可以内置在现有的智能语音系统中，例如作为家庭语音交互系统，或是车载语音智能助手的一部分。如图所示，语音处理装置600可以包括语音信息获取单元610、本地语音处理引擎620、通信单元630、仲裁单元640和操作单元650。上述单元可以是单独的软件功能模块，也可由具体的硬件模块来实现其对应功能。

具体地，语音信息获取单元610用于获取语音信息。在不同的场景中，语音信息获取单元610可以具有不同的形态。在最常规的应用中，语音信息获取单元610可以是装置内置或是外置的语音采集单元，例如麦克风。在分立式布置的语音采集系统中，可以由分立的语音采集接口进行语音采集，此时语音信息获取单元610可以是与语音采集接口进行短距离通信的通信单元，例如蓝牙单元等。

本地语音处理引擎620用于将获取的语音信息进行本地语音处理。本地语音处理引擎620可以包括ASR模块和NLU模块，并且可以由独立芯片实现。通信单元630用于将获取的语音信息输入云端语音处理引擎，并且尤其可以实现为WiFi单元。仲裁单元640可以用于根据离在线仲裁规则，确定要使用的语音处理结果。上述仲裁单元640尤其可以执行如图4所示的仲裁规则。操作单元650用于基于确定的语音处理结果执行相应操作。在此，操作单元650可以是设备的控制单元，例如，车辆的中控单元，用于根据接收到的处理结果进行操作，例如打开天窗等。

在此，虽然分别经由本地语音处理引擎620和通信单元630，但仍然同时进行本地语音处理引擎和云端语音处理引擎的语音处理流程。

在一个实施例中，仲裁单元640可以用于：在云端处理结果先返回的情况下，使用所述云端处理结果作为确定要使用的语音处理结果，并且所述本地语音处理引擎取消针对所述语音信息的当前处理流程。

在一个实施例中，仲裁单元640可以用于：在本地处理结果先返回的情况下，根据所述本地处理结果的置信度确定要使用的语音处理结果。

在一个实施例中，仲裁单元640可以用于：当所述本地处理结果的置信度高于第一阈值时，使用所述本地处理结果作为确定要使用的语音处理结果。

在一个实施例中，仲裁单元640可以用于：当所述本地处理结果的置信度低于第一阈值且高于第二阈值时，继续等待云端处理结果至第一预定时间；如果在所述第一预定时间内，所述云端处理结果返回，则使用所述云端处理结果作为确定要使用的语音处理结果；以及如果在所述第一预定时间内，所述云端处理结果未返回，则使用所述本地处理结果作为确定要使用的语音处理结果。

在一个实施例中，仲裁单元640可以用于：当所述本地处理结果的置信度低于第二阈值时，则继续等待云端处理结果至第二预定时间；如果在所述第二预定时间内，所述云端处理结果返回，则使用所述云端处理结果作为确定要使用的语音处理结果；以及如果在所述第二预定时间内，所述云端处理结果未返回，则触发超时处理。

如前所述，本地处理引擎620可以包括本地语音识别(ASR)模块和本地自然语言处理(NLU)模块。在满足预定条件下，通信单元630可以将本地语音识别模块生成的本地语音识别结果作为语音信息的代替，上传给所述云端语音处理引擎；和/或在满足预定条件下，使得所述云端语音处理引擎下发数据量最小版本的云端处理结果，例如，通过通信单元630发送请求实现。

类似地，所述预定条件可以包括：在第三预定时间内没有收到云端处理结果；和/或所述本地处理结果的置信度低于第三阈值。

应该理解的是，本发明中的“第一”、“第二”、“第三”仅用于对同类对象进行区分，而非暗示其前后或是重要顺序。

进一步地，本发明还可以实现为一种语音处理系统700。图7示出了能够实现本发明的语音处理系统的组成示意图。如图所示，该系统700可以包括多个语音处理设备710和服务器720。换句话说，服务器720可以看作是为海量语音处理设备710提供语音服务的语音服务平台。

在与服务器720连接的语音处理设备中，至少部分可以用于执行如上结合附图所述的本发明的语音处理方法。服务器720则包括云端语音处理引擎，并且用于基于获取的语音信息下发云端语音处理结果。

语音处理设备可以在被唤醒词唤醒之后执行所述语音处理方法。本发明的语音处理方法尤其适用于经常会出于弱网状态的设备，例如可移动的设备。在一个实施例中，语音处理设备尤其可以是车载语音助手。

进一步地，同一车辆上可以包括各自被不同的唤醒词唤醒的多个车载语音助手，并且多个车载语音助手在被唤醒后连接不同的服务器以获取云端处理结果。

图8示出了根据本发明一个实施例可用于实现上述语音处理方法的计算设备的结构示意图。

参见图8，计算设备800包括存储器810和处理器820。

处理器820可以是一个多核的处理器，也可以包含多个处理器。在一些实施例中，处理器820可以包含一个通用的主处理器以及一个或多个特殊的协处理器，例如图形处理器(GPU)、数字信号处理器(DSP)等等。在一些实施例中，处理器820可以使用定制的电路实现，例如特定用途集成电路(ASIC，Application Specific Integrated Circuit)或者现场可编程逻辑门阵列(FPGA，Field Programmable Gate Arrays)。

存储器810可以包括各种类型的存储单元，例如系统内存、只读存储器(ROM)，和永久存储装置。其中，ROM可以存储处理器820或者计算机的其他模块需要的静态数据或者指令。永久存储装置可以是可读写的存储装置。永久存储装置可以是即使计算机断电后也不会失去存储的指令和数据的非易失性存储设备。在一些实施方式中，永久性存储装置采用大容量存储装置(例如磁或光盘、闪存)作为永久存储装置。另外一些实施方式中，永久性存储装置可以是可移除的存储设备(例如软盘、光驱)。系统内存可以是可读写存储设备或者易失性可读写存储设备，例如动态随机访问内存。系统内存可以存储一些或者所有处理器在运行时需要的指令和数据。此外，存储器810可以包括任意计算机可读存储媒介的组合，包括各种类型的半导体存储芯片(DRAM，SRAM，SDRAM，闪存，可编程只读存储器)，磁盘和/或光盘也可以采用。在一些实施方式中，存储器810可以包括可读和/或写的可移除的存储设备，例如激光唱片(CD)、只读数字多功能光盘(例如DVD-ROM，双层DVD-ROM)、只读蓝光光盘、超密度光盘、闪存卡(例如SD卡、min SD卡、Micro-SD卡等等)、磁ll性软盘等等。计算机可读存储媒介不包含载波和通过无线或有线传输的瞬间电子信号。

存储器810上存储有可执行代码，当可执行代码被处理器820处理时，可以使处理器820执行上文述及的语音处理方法。

上文中已经参考附图详细描述了根据本发明的语音处理方法、装置和系统。本发明提供了一套基于离在线的语音处理结果选择方案。该方案同时进行本地和云端语音处理流程，并根据处理结果的时效性和置信度进行实时决策，能够始终为用户提供准确及时的语音处理结果。

此外，根据本发明的方法还可以实现为一种计算机程序或计算机程序产品，该计算机程序或计算机程序产品包括用于执行本发明的上述方法中限定的上述各步骤的计算机程序代码指令。

或者，本发明还可以实施为一种非暂时性机器可读存储介质(或计算机可读存储介质、或机器可读存储介质)，其上存储有可执行代码(或计算机程序、或计算机指令代码)，当所述可执行代码(或计算机程序、或计算机指令代码)被电子设备(或计算设备、服务器等)的处理器执行时，使所述处理器执行根据本发明的上述方法的各个步骤。

本领域技术人员还将明白的是，结合这里的公开所描述的各种示例性逻辑块、模块、电路和算法步骤可以被实现为电子硬件、计算机软件或两者的组合。

附图中的流程图和框图显示了根据本发明的多个实施例的系统和方法的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标记的功能也可以以不同于附图中所标记的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

以上已经描述了本发明的各实施例，上述说明是示例性的，并非穷尽性的，并且也不限于所披露的各实施例。在不偏离所说明的各实施例的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。本文中所用术语的选择，旨在最好地解释各实施例的原理、实际应用或对市场中的技术的改进，或者使本技术领域的其它普通技术人员能理解本文披露的各实施例。

Claims (28)

1.一种语音处理方法，包括：

获取语音信息；

将获取的语音信息输入云端语音处理引擎和本地语音处理引擎；

根据离在线仲裁规则，确定要使用的语音处理结果；以及

基于确定的语音处理结果执行相应操作。

2.如权利要求1所述的方法，其中，将获取的语音信息输入云端语音处理引擎和本地语音处理引擎包括：

在将获取的语音信息送入所述本地语音引擎的同时，向所述云端语音处理引擎发送所述语音信息。

3.如权利要求1所述的方法，其中，根据离在线仲裁规则，确定要使用的语音处理结果包括：

在云端处理结果先返回的情况下，使用所述云端处理结果作为确定要使用的语音处理结果。

4.如权利要求3所述的方法，还包括：

取消所述本地语音处理引擎针对所述语音信息的当前处理流程。

5.如权利要求1所述的方法，其中，根据离在线仲裁规则，确定要使用的语音处理结果包括：

在本地处理结果先返回的情况下，根据所述本地处理结果的置信度确定要使用的语音处理结果。

6.如权利要求5所述的方法，其中，在本地处理结果先返回的情况下，根据所述本地处理结果的置信度确定要使用的语音处理结果包括：

当所述本地处理结果的置信度高于第一阈值时，使用所述本地处理结果作为确定要使用的语音处理结果。

7.如权利要求6所述的方法，其中，在本地处理结果先返回的情况下，根据所述本地处理结果的置信度确定要使用的语音处理结果包括：

当所述本地处理结果的置信度低于第一阈值且高于第二阈值时，继续等待云端处理结果至第一预定时间；

如果在所述第一预定时间内，所述云端处理结果返回，则使用所述云端处理结果作为确定要使用的语音处理结果；以及

如果在所述第一预定时间内，所述云端处理结果未返回，则使用所述本地处理结果作为确定要使用的语音处理结果。

8.如权利要求7所述的方法，其中，在本地处理结果先返回的情况下，根据所述本地处理结果的置信度确定要使用的语音处理结果包括：

当所述本地处理结果的置信度低于第二阈值时，则继续等待云端处理结果至第二预定时间；

如果在所述第二预定时间内，所述云端处理结果返回，则使用所述云端处理结果作为确定要使用的语音处理结果；以及

如果在所述第二预定时间内，所述云端处理结果未返回，则触发超时处理。

9.如权利要求1所述的方法，其中，所述本地处理引擎包括本地语音识别模块和本地自然语言处理模块，

所述方法还包括：

在满足预定条件下，将本地语音识别模块生成的本地语音识别结果作为语音信息的代替，上传给所述云端语音处理引擎。

10.如权利要求1所述的方法，还包括：

在满足预定条件下，使得所述云端语音处理引擎下发数据量最小版本的云端处理结果。

11.如权利要求9或10所述的方法，其中，所述预定条件包括：

在第三预定时间内没有收到云端处理结果；和/或

所述本地处理结果的置信度低于第三阈值。

12.如权利要求1所述的方法，其中，获取语音信息包括：

获取语音助手被唤醒后接收到的语音信息。

13.如权利要求12所述的方法，还包括：

基于不同的唤醒词唤醒不同的语音助手，并且

将获取的语音信息输入云端语音处理引擎和本地语音处理引擎包括：

将获取的语音信息输入同一个本地语音处理引擎以及与被唤醒语音助手相对应的云端语音处理引擎。

14.一种语音处理装置，包括：

语音信息获取单元，用于获取语音信息；

本地语音处理引擎，用于将获取的语音信息进行本地语音处理；

通信单元，用于将获取的语音信息输入云端语音处理引擎；

仲裁单元，用于根据离在线仲裁规则，确定要使用的语音处理结果；以及

操作单元，用于基于确定的语音处理结果执行相应操作。

15.如权利要求14所述的装置，其中，同时进行本地语音处理引擎和云端语音处理引擎的语音处理流程。

16.如权利要求14所述的装置，其中，所述仲裁单元用于：

在云端处理结果先返回的情况下，使用所述云端处理结果作为确定要使用的语音处理结果，并且

所述本地语音处理引擎取消针对所述语音信息的当前处理流程。

17.如权利要求14所述的装置，所述仲裁单元用于：

在本地处理结果先返回的情况下，根据所述本地处理结果的置信度确定要使用的语音处理结果。

18.如权利要求17所述的装置，其中，所述仲裁单元用于：

当所述本地处理结果的置信度高于第一阈值时，使用所述本地处理结果作为确定要使用的语音处理结果。

19.如权利要求18所述的装置，其中，所述仲裁单元用于：

当所述本地处理结果的置信度低于第一阈值且高于第二阈值时，继续等待云端处理结果至第一预定时间；

如果在所述第一预定时间内，所述云端处理结果返回，则使用所述云端处理结果作为确定要使用的语音处理结果；以及

如果在所述第一预定时间内，所述云端处理结果未返回，则使用所述本地处理结果作为确定要使用的语音处理结果。

20.如权利要求19所述的装置，其中，所述仲裁单元用于：

当所述本地处理结果的置信度低于第二阈值时，则继续等待云端处理结果至第二预定时间；

如果在所述第二预定时间内，所述云端处理结果返回，则使用所述云端处理结果作为确定要使用的语音处理结果；以及

如果在所述第二预定时间内，所述云端处理结果未返回，则触发超时处理。

21.如权利要求14所述的装置，其中，所述本地处理引擎包括本地语音识别模块和本地自然语言处理模块，

并且，在满足预定条件下，所述通信单元将本地语音识别模块生成的本地语音识别结果作为语音信息的代替，上传给所述云端语音处理引擎；和/或

在满足预定条件下，使得所述云端语音处理引擎下发数据量最小版本的云端处理结果。

22.如权利要求21所述的装置，其中，所述预定条件包括：

在第三预定时间内没有收到云端处理结果；和/或

所述本地处理结果的置信度低于第三阈值。

23.一种语音处理系统，包括：

语音处理设备，用于执行如权利要求1-13中任一项所述的语音处理方法；以及

服务器，包括所述云端语音处理引擎，并且用于基于获取的语音信息下发云端语音处理结果。

24.如权利要求23所述的系统，其中，所述语音处理设备在被唤醒词唤醒之后执行所述语音处理方法。

25.如权利要求23所述的系统，其中，所述语音处理设备是车载语音助手。

26.如权利要求23所述的系统，其中，同一车辆上包括各自被不同的唤醒词唤醒的多个车载语音助手，并且多个车载语音助手在被唤醒后连接不同的服务器以获取云端处理结果。

27.一种计算设备，包括：

处理器；以及

存储器，其上存储有可执行代码，当所述可执行代码被所述处理器执行时，使所述处理器执行如权利要求1-13中任一项所述的方法。

28.一种非暂时性机器可读存储介质，其上存储有可执行代码，当所述可执行代码被电子设备的处理器执行时，使所述处理器执行如权利要求1-13中任一项所述的方法。

Images