语音交互方法、服务器和计算机可读存储介质

技术领域

本申请涉及车载语音技术领域，特别涉及一种语音交互方法、服务器和计算机可读存储介质。

背景技术

在语音交互过程中，槽位识别的准确率至关重要。目前相关技术中，对于用户语音请求中命名实体的复杂情况，识别效果不佳，可能发生错误，无法提取到期望得到的槽位结果，难以满足车载场景下的用户需求。

发明内容

本申请提供了一种语音交互方法、服务器及计算机可读存储介质。

本申请的语音交互方法，包括：

接收车辆转发的语音请求；

根据预设的资源库获取所述语音请求的附加信息；

根据所述附加信息对所述语音请求进行编码处理；

根据所述编码处理的结果对所述语音请求进行槽位识别；

对所述语音请求进行应用程序接口预测；

根据所述槽位识别的结果和预测到的应用程序接口，选择所述预测到的应用程序接口执行应用程序接口参数填充，输出执行结果下发至车辆完成语音交互。

如此，本申请实施方式的语音交互方法通过预设资源库获取语音请求的附加信息，并根据附加信息对语音请求进行编码处理，进而可根据编码处理后的结果对语音请求进行槽位识别。进而可根据槽位识别的结果以及槽位识别结果预测对应用程序接口进行参数填充，最终输出执行结果并下发至车辆，完成语音交互。本申请实施方式的语音交互方法，在槽位识别的过程中，引入资源库中存储的语音请求的附加信息，并根据附加信息对语音请求进行编码处理，使得附加信息编入语音请求的编码信息中，为槽位提取提供更多更全面的外部信息，从而可以有效地提升槽位识别的准确性，提高用户的语音交互体验。

在某些实施方式中，所述预设资源库存储有预设关键词及与所述预设关键词对应的标签信息，所述根据预设的资源库获取所述语音请求的附加信息，包括：

将所述语音请求与所述资源库中的关键词进行匹配；

根据所述匹配的结果确定与所述语音请求形成匹配的关键词的标签信息以获取所述附加信息。

如此，通过将语音请求与资源库中存储的关键词进行匹配，并根据匹配成功的关键词的标签信息，获取语音请求的附加信息，以便后续对语音请求进行编码处理。

在某些实施方式中，所述根据所述附加信息对所述语音请求进行编码处理，包括：

对所述语音请求进行文本序列编码处理，得到第一编码向量；

根据所述标签信息对应的编码信息对所述第一编码向量进行拼接处理以得到第二编码向量。

如此，对语音请求的文本序列进行编码处理，得到第一编码向量，根据标签信息对对应的编码信息对第一编码向量进行拼接处理，得到第二编码向量，第二编码向量中包含了标签信息的编码信息，原语音请求中的信息得以扩展，使得后续槽位识别的过程具有可依赖的外部资源信息。

在某些实施方式中，所述根据所述标签信息对应的编码信息对所述第一编码向量进行拼接处理以得到第二编码向量，包括：

在与所述语音请求中的第一片段形成的匹配的第一关键词具有多个标签信息的情况下，将所述多个标签信息分别对应的编码信息共同与所述第一编码向量进行所述拼接处理以得到所述第二编码向量。

如此，对于与语音请求中的某些实体形成匹配的同一关键词具有多个标签信息的情况，在编码过程中将这些标签信息逐一与语音请求的第一编码向量进行拼接，使得拼接处理后的第二编码向量，包括了该语音请求中存在与外部资源库中形成匹配的关键词的全部外部资源标签信息，增强了信息的全面性，有效避免因关键词的标签信息缺失而无法满足槽位识别需求的情况，槽位识别更加准确。

在某些实施方式中，所述方法还包括：

根据所述第二编码向量和所述语音请求的字符序列构建位置向量。

如此，可以通过构建位置向量的方式来指示标签信息编码所对应的语音请求中的实体的位置，从而得以进行槽位识别。

在某些实施方式中，所述根据所述第二编码向量和所述语音请求的字符序列构建位置向量，包括：

根据所述第二编码向量中每个编码对应于所述语音请求的字符序列中的起始位置，构建第一位置向量。

如此，可以构建第一位置向量，第一位置向量也即是第二编码向量中每个编码在语音请求的字符序列中的起始位置。

在某些实施方式中，所述根据所述第二编码向量和所述语音请求的字符序列构建位置向量，包括：

根据所述第二编码向量中每个编码对应于所述语音请求的字符序列中的结束位置，构建第二位置向量。

如此，可以构建第二位置向量，第二位置向量也即是第二编码向量中每个编码在语音请求的字符序列中的结束位置。

在某些实施方式中，所述根据所述编码处理的结果对所述语音请求进行槽位识别，包括：

根据所述第二编码向量、所述第一位置向量和所述第二位置向量对所述语音请求进行槽位识别。

如此，根据拼接处理得到的第二编码向量、构建的第一位置向量以及第二位置向量，可用以进行后续的槽位识别，在第二编码向量中包括了语音请求中对应外部资源库中的实体所具有的全部外部标签信息，根据第一位置向量、第二位置向量可确定以编码信息拼接至语音请求中的标签信息对应的语音请求中的实体，从而可进行后续的槽位识别。

本申请的服务器，包括处理器和存储器，所述存储器中存储有计算机程序，所述计算机程序被所述处理器执行时，实现上述的方法。

本申请的计算机可读存储介质，存储有计算机程序，当所述计算机程序被一个或多个处理器执行时，实现上述实施方式任一项所述的语音交互方法。

如此，本申请的服务器和计算机可读存储介质，通过预设资源库获取语音请求的附加信息，并根据附加信息对语音请求进行编码处理，进而可根据编码处理后的结果对语音请求进行槽位识别。进而可根据槽位识别的结果以及槽位识别结果预测对应用程序接口进行参数填充，最终输出执行结果并下发至车辆，完成语音交互。本申请实施方式的语音交互方法，在槽位识别的过程中，引入资源库中存储的语音请求的附加信息，并根据附加信息对语音请求进行编码处理，使得附加信息编入语音请求的编码信息中，为槽位提取提供更多更全面的外部信息，从而可以有效地提升槽位识别的准确性，提高用户的语音交互体验。

本申请实施方式的附加方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本申请的实践了解到。

附图说明

本申请的上述和/或附加的方面和优点可以从结合下面附图对实施方式的描述中将变得明显和容易理解，其中：

图1是相关技术中对话系统的结构示意图；

图2是本申请的端到端架构的对话系统的结构示意图；

图3是本申请实施方式的语音交互方法的流程示意图；

图4是本申请实施方式的语音交互方法的流程示意图；

图5是本申请实施方式的语音交互方法的流程示意图；

图6是本申请实施方式的语音交互方法的向量构建示意图；

图7是本申请实施方式的语音交互方法的流程示意图；

图8是本申请实施方式的语音交互方法的流程示意图；

图9是本申请实施方式的语音交互方法的流程示意图；

图10是本申请实施方式的语音交互方法的流程示意图；

图11是本申请实施方式的语音交互方法的流程示意图；

图12是本申请实施方式的语音交互方法的流程示意图。

具体实施方式

下面详细描述本申请的实施方式，所述实施方式的示例在附图中示出，其中，相同或类似的标号自始至终表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施方式是示例性的，仅用于解释本申请的实施方式，而不能理解为对本申请的实施方式的限制。

请参阅图1，传统的车载语音架构基于传统的模块化策略，在组件之间采用分工实现整个对话流程，例如自然语言理解、状态跟踪、对话策略和自然语言生成等。这些组件要么主要是人工按照规则制作的，要么是在有监督数据集上通过训练模型产生的。每个组件的训练都需要大量的标注数据，然而标注数据往往是很昂贵的，这也限制了系统的拓展性。同时，传统车载语音系统依赖于大量的规则和业务逻辑来保证系统的准确和稳定，也进一步限制了其规模和功能。

从对话的整体处理链路来说，传统的车载语音架构拿到用户输入后，需要先对其进行自然语言理解，即进行领域分类、意图识别和槽位识别，然后在对话管理模块中结合对话的状态和对话策略选择执行满足用户输入要求的应用程序接口(ApplicationProgramming Interface，API)，并通过自然语言生成模块返回和用户交互的系统输出。

有鉴于此，请参阅图2，本申请实施方式采用基于端到端的对话系统，其包含三个核心的算法模块：槽位识别块、行动预测(Action Prediction，AP)模块以及参数填充(Argument Filling，AF)模块。其中，槽位识别模块用于识别出用户输入的语音请求中的实体；行动预测模块用来预测用户输入所对应的实现用户当前目标的应用程序接口；参数填充模块用来识别用户输入中的实体对应上一步中得到的应用程序接口中的参数。

也即是，槽位识别模块用于获取需要在应用程序接口中调用的实体，行动预测模块决定了后续实现用户语音输入所调用的应用程序接口是否是正确的，参数填充模块则进行选择哪些实体用来作为应用程序接口的参数进行执行。

然而，对于用户语音请求中可能存在的包含复杂命名实体的槽位识别，可能存在问题。例如，对于由多个实体词或指令性语句组成的具有特殊意义的专有名词的识别可能不够准确。以播放音乐的业务场景为例，当歌名命中了“播放xx(歌手)的xx(歌曲)”格式时，槽位识别可能会出现错误，如表1所示：

表1

用户发出语音请求“播放可可托海的牧羊人”中，歌名“可可托海的牧羊人”命中了“xx(歌手)的xx(歌曲)”格式，槽位识别可能产生错误，将“可可托海”识别为歌手槽位，将“牧羊人”识别为歌名槽位。相类似地，语音请求“听妈妈的话”中，可能将“妈妈”识别为歌手，“话”识别为歌名。由此，导致槽位识别的错误。

对于上述可能遇到的问题，相关技术中可采用建立预设的外部资源库的方式，在外部的资源库中将类似上述的实体内容进行维护和更新。在槽位识别的过程中，将命中外部资源库的内容作为语音请求的附加信息，从而提高槽位识别的准确性。

然而，可以理解地，在实际情况下，存在着一个实体对应多种外部信息的情况，例如，对于“七里香”，既是歌名，又是专辑名。又如，对于“成都”，既是歌名，又是导航垂域中的一个兴趣点。对于这样的情况，基于相关技术中的处理方法则可能无法准确有效的进行槽位识别。原因在于：其一，可能存在由于维护和更新不及时而导致外部资源库缺少某个实体的类型信息，例如，在外部资源库中只添加了“七里香”是一个歌名，而忽略了它可以是一个专辑名称。其二，基于对语音请求的处理方式，导致在槽位识别过程中无法将某一实体的全部信息进行有效的融合的情况。例如，在对语音请求的处理过程中仅提供一个外部资源信息的标志位，使得所构建的特征向量无法表征某一实体对应的全部外部信息。具体处理过程中，对于某一具有多种类型信息的实体，由于只提供一个标志位，则只能添加该实体所对应的一个类型信息的标志，而无法对其对应的多个类型信息同时进行编码。那么，在槽位识别的过程中，就只能将该实体的槽位类型识别为已标识的标志所对应的类型，而无法将其识别为其它类型。然而如此，在某些场景中，将导致槽位类型的识别错位。

基于上述可能遇到的问题，请参阅图3，本申请实施方式提供了一种语音交互方法。该语音交互方法包括：

01：接收车辆转发的语音请求；

02：根据预设的资源库获取语音请求的附加信息；

03：根据附加信息对语音请求进行编码处理；

04：根据编码处理的结果对语音请求进行槽位识别；

05：对语音请求进行应用程序接口预测；

06：根据槽位识别的结果和预测到的应用程序接口，选择预测到的应用程序接口执行应用程序接口参数填充，输出执行结果下发至车辆完成语音交互。

本申请实施方式还提供了一种服务器。服务器包括处理器和存储器，存储器上存储有计算机程序。处理器用于接收车辆转发的语音请求，及用于根据预设的资源库获取语音请求的附加信息，及用于根据附加信息对语音请求进行编码处理，及用于根据编码处理的结果对语音请求进行槽位识别，及用于对语音请求进行应用程序接口预测，以及用于根据槽位识别的结果和预测到的应用程序接口，选择预测到的应用程序接口执行应用程序接口参数填充，输出执行结果下发至车辆完成语音交互。

具体地，本申请实施方式中，配置有一外部预设的资源库，该资源库中存储有特定的关键词或者说实体，以及该实体在所有可能的垂域中对应的所有可能标签信息。资源库可定期通过人工进行维护和更新，以满足业务的需求。例如，资源库中存储有关键词“七里香”，以及其在音乐垂域中对应的“Song”(歌曲)标签以及“Album”(专辑)标签。

在实际操作过程中，服务器在接收到车辆转发的用户语音请求后，从预设的资源库中获取相关的信息。具体而言，可通过匹配等方式确认是否能够命中资源库中已存储的关键词。在用户语音请求命中数据库中的关键词的情况下，基于关键词的相关标签信息可获取该语音请求的附加信息。例如，对于语音请求“播放七里香”，其中的“七里香”命中资源库中的关键词“七里香”，在资源库中关键词“七里香”与“Song”以及“Album”这两个标签对应。则获取到的该语音请求的附加信息可以是“七里香”对应的“Song”标签信息以及“Album”标签信息。

在获取到语音请求的附加信息后，可根据附加信息对语音请求进行编码处理，将得到的标签信息与语音请求相融合。可以理解地，编码处理结果中包括原语音请求的文字信息以及指示其中包括的特定实体的标签信息。在上例中，编码处理结果中包括了“播放七里香”的文字信息以及指示其中“七里香”是一首歌曲的“Song”标签信息，同时“七里香”是一张专辑的“Album”标签信息。据此，可进行后续的槽位识别，可以理解，虽然编码处理的结果中指示了特定实体全部可能的标签信息，但通常用户的真实语义仅指向其中的一个标签。因此，在槽位识别过程中，可以根据当前的业务需求等，对槽位进行正确识别。

例如，在一个导航的对话场景中，用户发出语音请求指示目的地，该目的地的实体在资源库中具有兴趣点标签的同时还具有其他垂域的标签信息，例如歌曲名称等，结合当前的业务需求，则在槽位识别的结果中，该实体的槽位类型应当为兴趣点而非歌曲名称等。

可以理解地，本申请实施方式在编码处理过程中，将语音请求中特定实体在资源库中对应的全部标签信息共同进行编码，从而在槽位识别过程中，使得对应有多个标签信息的实体的槽位类型能够被正确的识别。此外，外部资源库可进行维护和调整，满足业务的需求变化。

进而，可根据对用户语音请求进行槽位识别得到的语句中的实体，对语音请求进行应用程序接口预测。首先，可根据槽位识别得到的结果中包含的实体词，即通过ActionPrediction(AP)模块预测该语音请求所需要的应用程序接口(API)。例如，对用户语音请求对用户语音请求“播放歌曲A”进行应用程序接口预测得到的应用程序接口为播放音乐的应用程序接口1。对用户语音请求“导航去目的地A”进行应用程序接口预测得到的应用程序接口为导航的应用程序接口2。

Argument Filling(AF)模块可通过选择实体来填充应用程序接口中的参数，最终输出执行结果下发至车辆完成语音交互。

本申请实施方式中采用端到端架构可以精简传统对话系统架构的中间模块如自然语言理解模块、对话管理模块、车机指令生成模块、自然语言生成模块等，减少对于不同垂域的多个模型的调用，降低车载系统的延时，提升对于用户指令的响应速度。

综上，本申请实施方式的语音交互方法、服务器通过预设资源库获取语音请求的附加信息，并根据附加信息对语音请求进行编码处理，进而可根据编码处理后的结果对语音请求进行槽位识别。进而可根据槽位识别的结果以及槽位识别结果预测对应用程序接口进行参数填充，最终输出执行结果并下发至车辆，完成语音交互。本申请实施方式的语音交互方法，在槽位识别的过程中，引入资源库中存储的语音请求的附加信息，并根据附加信息对语音请求进行编码处理，使得附加信息编入语音请求的编码信息中，为槽位提取提供更多更全面的外部信息，从而可以有效地提升槽位识别的准确性，提高用户的语音交互体验。

请参阅图4，在某些实施方式中，预设资源库存储有预设关键词及与预设关键词对应的标签信息，步骤02包括：

021：将语音请求与资源库中的关键词进行匹配；

022：根据匹配的结果确定与语音请求形成匹配的关键词的标签信息以获取附加信息。

在某些实施方式中，处理器用于将语音请求与资源库中的关键词进行匹配，以及用于根据匹配的结果确定与语音请求形成匹配的关键词的标签信息以获取附加信息。

具体地，预设的资源库中存储有特定的关键词或者说实体，以及该实体在所有可能的垂域中相对应的标签，标签具有相应的标签信息。为方便进行编码处理，对标签在不同的垂域预置相应的编码，标签信息包括相应的编码信息。

服务器在接收到车辆转发的用户语音请求后，将语音请求转换为语音请求文本，再通过在资源库中寻找关键词与语音请求文本进行匹配，来确认语音请求中是否存在命中关键词，进而可根据命中的关键词，确定与该关键词相对应的全部标签，从而将标签信息作为附加信息。

例如，在资源库中存储有一实体“近光灯”，同时对应两个标签，其一为车控垂域相关的标签，其二为场景直达垂域的标签，两标签分别预置编码。

接收到用户的语音请求“将近光灯调为灯光”后，将语音请求转化为文本，并将语音请求文本与资源库中的关键词进行匹配，“近光灯”形成匹配，近光灯对应的两标签，车控垂域相关标签以及场景直达垂域标签，两标签的编码信息为附加信息，以用于对语音请求进行编码处理。

如此，通过将语音请求与资源库中存储的关键词进行匹配，并根据匹配成功的关键词的标签信息，获取语音请求的附加信息，以便后续对语音请求进行编码处理。

请参阅图5，在某些实施方式中，步骤03包括：

031：对语音请求进行文本序列编码处理，得到第一编码向量；

032：根据标签信息对应的编码信息对第一编码向量进行拼接处理以得到第二编码向量。

在某些实施方式中，处理器用于对语音请求进行文本序列编码处理，得到第一编码向量，以及用于根据标签信息对应的编码信息对第一编码向量进行拼接处理以得到第二编码向量。

具体地，请参阅图6，在编码处理过程中，可将语音请求文本以字符为单位进行划分，每个字符对应一个编码，并在语音请求文本的前后添加标志符[CLS]和[SEP]，相类似地，标志符也同样各自对应一个编码。其中，标志符[CLS]，用于标识文本起始。标志符[SEP]，用于将两个句子进行分隔，如果为单句，标志符[SEP]可看作文本结束的标识。经编码处理后，对应于各个字符的编码构成第一编码向量。

例如，对于语音请求“将近光灯调为灯光”，编码处理后的文本序列为“[CLS]将近光灯调为灯光[SEP]”，对应的第一编码向量为[101,2199,6818,1045,4128,6444,711,4128,1045,102]。

进一步地，在第一编码向量的基础上，将匹配得到的全部标签的编码信息与第一编码向量进行拼接处理。

在上例中，经匹配后，“近光灯”、“调为”、“灯光”都分别与资源库中的关键词形成匹配，其中，“近光灯”对应两个标签，“调为”和“灯光”分别对应一个标签，“近光灯”在资源库中对应的第一标签的编码信息为2，第二标签的编码信息为5，“调为”对应标签的编码信息为1，“灯光”对应标签的编码信息为6。

在这种情况下，文本序列在拼接后将变为“[CLS]将近光灯调为灯光[SEP]近光灯近光灯调为灯光[SEP]”，对应的第二编码向量为[101,2199,6818,1045,4128,6444,711,4128,1045,102，2,5,1,6,102]。

也即是说，将形成匹配的每个实体单独作为一个整体，拼接在原文本序列后形成拼接部分，若一实体对应多个标签，则进行多次拼接。也即是，在原始文本序列中“近光灯”中每一个字符单独对应一个编码信息。拼接部分中，“近光灯”作为一个整体，对应一个编码信息，“近光灯”对应两个标签，拼接两次。这样，就可以将实体对应的全部外部信息融合至原文本序列中，在后续槽位识别中可以支持单一实体对应多个外部资源标签的场景。当然，如果匹配到的实体对应一个标签，那么拼接一次即可。

如此，对语音请求的文本序列进行编码处理，得到第一编码向量，根据标签信息对对应的编码信息对第一编码向量进行拼接处理，得到第二编码向量，第二编码向量中包含了标签信息的编码信息，原语音请求中的信息得以扩展，使得后续槽位识别的过程具有可依赖的外部资源信息。

请参阅图7，在某些实施方式中，步骤032包括：

0321：在与语音请求中的第一片段形成的匹配的第一关键词具有多个标签信息的情况下，将多个标签信息分别对应的编码信息共同与第一编码向量进行拼接处理以得到第二编码向量。

在某些实施方式中，处理器用于在与语音请求中的第一片段形成的匹配的第一关键词具有多个标签信息的情况下，将多个标签信息分别对应的编码信息共同与第一编码向量进行拼接处理以得到第二编码向量。

具体地，请再次参阅图6，,前例中，对于语音请求“将近光灯调为灯光”，经匹配，“近光灯”、“调为”、“灯光”分别与资源库中的关键词形成匹配，其中，“近光灯”也即是对应两个标签，“近光灯”在资源库中对应的第一标签的编码信息为2，第二标签的编码信息为5。也即是语音请求中的第一片段“近光灯”与资源库中的第一关键词“近光灯”形成匹配，在资源库中，第一关键词“近光灯”对应多个标签。

在这种情况下，文本序列在拼接后将变为“[CLS]将近光灯调为灯光[SEP]近光灯近光灯调为灯光[SEP]”，对应的第二编码向量为[101,2199,6818,1045,4128,6444,711,4128,1045,102，2,5,1,6,102]。也即是，将“近光灯”的两个标签各自对应的编码信息共同与第一编码向量进行拼接处理。

“共同进行拼接处理”，也即是，将相关关键词对应的多个标签，逐一拼接至第一编码向量中，共同得到第二编码向量。在上例中，“近光灯”对应两个标签，拼接两次，即分别将“2”以及“5”拼接至第一编码向量中。这样，就可以将实体对应的全部外部信息融合至原文本序列中，在后续槽位识别中可以支持单一实体对应多个外部资源标签的场景。

如此，对于与语音请求中的某些实体形成匹配的同一关键词具有多个标签信息的情况，在编码过程中将这些标签信息逐一与语音请求的第一编码向量进行拼接，使得拼接处理后的第二编码向量，包括了该语音请求中存在与外部资源库中形成匹配的关键词的全部外部资源标签信息，增强了信息的全面性，有效避免因关键词的标签信息缺失而无法满足槽位识别需求的情况，槽位识别更加准确。

请参阅图8，在某些实施方式中，本申请实施方式的语音交互方法还包括：

033：根据第二编码向量和语音请求的字符序列构建位置向量。

在某些实施方式中，处理器用于根据第二编码向量和语音请求的字符序列构建位置向量。

具体地，请再次参阅图6，可以理解，在第二编码向量中实体对应的外部标签信息以整体的形式与第一编码向量进行拼接，标签的编码信息指示的是所标识的相关垂域的编码信息，但在当前的第二编码向量中缺少标签对应实体信息，也即是说，根据标签的编码信息并不知道该编码信息对应于语音请求中的哪一个实体。在上例中，第二编码向量中的“2”为车控垂域的编码信息。但通过“2”这个编码信息，无法确定该标签对应的是“将近光灯调为灯光”中的哪一个实体。

因此，需要结合语音请求的字符序列来构建位置向量，以用于指示第二编码向量中每一个编码信息对应于语音请求文本序列中的哪个或哪几个字符，使得标签与实体得以形成对应。例如，在构建位置向量后，可以根据位置向量确定“2”这个标签的编码信息，对应于“将近光灯调为灯光”这个语音请求中的第2到第4个字符。相类似地，“调为”对应于语音请求中的第5和第6个字符，“灯光”对应于语音请求中第7和第8个字符。

如此，可以通过构建位置向量的方式来指示标签信息编码所对应的语音请求中的实体的位置，从而得以进行槽位识别。

请参阅图9，在某些实施方式中，步骤033包括：

0331：根据第二编码向量中每个编码对应于语音请求的字符序列中的起始位置，构建第一位置向量。

在某些实施方式中，处理器用于根据第二编码向量中每个编码对应于语音请求的字符序列中的起始位置，构建第一位置向量。

具体地，请再次参阅图6，可以理解，在拼接部分中相关实体以整体进行拼接，而实体中可能包括一个以上的字符，而在多于一个字符的情况下，仅通过一个顺序标志位无法指示完整的实体位置信息。因此，在本申请实施方式中，考虑采用分别指示头尾位置的方式来标识实体的位置。

对于第一位置向量，也即是指示第二编码向量所对应的字符或实体起始位置的向量。具体构建过程中，根据语音请求的字符序列，标记第二编码向量中每个元素，也即是其中字符或拼接部分的实体的字头对应的字符在语音请求中的序列。

例如，对于语音请求“将近光灯调为灯光”，经拼接处理后得到的文本序列为“[CLS]将近光灯调为灯光[SEP]近光灯近光灯调为灯光[SEP]”，对应的第二编码向量为[101,2199,6818,1045,4128,6444,711,4128,1045,102,2,5,1,6,102]，构建得到的第一位置向量为[0,1,2,3,4,5,6,7,8,9,2,2,5,7,10]，需要说明地，在标记时，自0开始标记，也即是，标志符[CLS]的起始位置编码为0，依此类推，顺序标记，“将近光灯调为灯光”中各个字符的起始位置的编码依次为1,2,3,4,5,6,7,8，第一个标志符[SEP]的起始位置编码为9。对于拼接部分：近光灯/近光灯/调为/灯光，“近光灯”以字符“近”开始，其对应的起始位置编码为2，相类似地，“调为”以字符“调”开始，其对应的起始位置编码为5，“灯光”以字符“灯”开始，其对应的起始位置编码为7，第二个标志符[SEP]接续第一个标志符[SEP]，起始位置编码为10。由此，可得到构建的第一位置向量[0,1,2,3,4,5,6,7,8,9,2,2,5,7,10]。

如此，可以构建第一位置向量，第一位置向量也即是第二编码向量中每个编码在语音请求的字符序列中的起始位置。

请参阅图10，在某些实施方式中，步骤033包括：

0332：根据第二编码向量中每个编码对应于语音请求的字符序列中的结束位置，构建第二位置向量。

在某些实施方式中，处理器用于根据第二编码向量中每个编码对应于语音请求的字符序列中的结束位置，构建第二位置向量。

具体地，请再次参阅图6，可以理解地，在构建第一位置后，仍需构建一个位置向量来指示字符或实体的结束位置，这样才能完整的指示一个实体在语音请求中的位置信息。

因此，对于第二位置向量，也即是指示第二编码向量所对应的字符或实体结束位置的向量。具体构建过程中，根据语音请求的字符序列，标记第二编码向量中每个元素，也即是其中字符或拼接部分的实体的字尾对应的字符在语音请求中的序列。

例如，对于语音请求“将近光灯调为灯光”，经拼接处理后得到的文本序列为“[CLS]将近光灯调为灯光[SEP]近光灯近光灯调为灯光[SEP]”，对应的第二编码向量为[101,2199,6818,1045,4128,6444,711,4128,1045,102,2,5,1,6,102]，构建得到的第二位置向量为[0,1,2,3,4,5,6,7,8,9,4,4,6,8,10]，需要说明地，在标记时，对于字符而言，起始位置和结束位置相同，也即是，标志符[CLS]的结束位置编码0，依此类推，“将近光灯调为灯光”中各个字符的结束位置编码依次为1,2,3,4,5,6,7,8，第一个标志符[SEP]的结束位置编码为9。对于拼接部分：近光灯/近光灯/调为/灯光，“近光灯”以字符“灯”结束，其对应的结束位置编码为4，相类似地，“调为”以字符“为”结束，其对应的结束位置编码为6，“灯光”以字符“光”结束，其对应的结束位置编码为8，第二个标志符[SEP]接续第一个标志符[SEP]，结束位置编码为10。由此，可得到构建的第二位置向量[0,1,2,3,4,5,6,7,8,9,4,4,6,8,10]。

如此，可以构建第二位置向量，第二位置向量也即是第二编码向量中每个编码在语音请求的字符序列中的结束位置。

请参阅图11，在某些实施方式中，步骤04包括：

041：根据第二编码向量、第一位置向量和第二位置向量对语音请求进行槽位识别。

在某些实施方式中，处理器用于根据第二编码向量、第一位置向量和第二位置向量对语音请求进行槽位识别。

具体地，在实际槽位处理过程中，可先对拼接得到的第二编码向量、构建的第一位置向量和第二位置向量进行预处理。具体而言，可将第二编码向量、第一位置向量，以及第二位置向量进行求和，求和计算的结果即作为该用户语音请求的整体文本特征，作为槽位识别的输入进行提槽处理，得到槽位识别的结果。其中，槽位识别的结果可包括槽位值以及与槽位值相对应的槽位类型(标签指示的相关垂域信息)。槽位识别过程可使用线性条件随机场(Linear-CRF)模型，具体模型需根据槽位识别的精确度需求选取，在此不做限定。

例如，用户语音请求为“播放整张七里香”经过上述过程处理后进入槽位识别模型进行槽位识别，得到槽位识别的结果[“七里香”——专辑(Album)]，包括槽位值“七里香”，以及与槽位值相对应的槽位类型，即“专辑(Album)”。

本申请的中的槽位识别模型不但利用了用户语音请求的原始文本，同时引入了外部资源特征，并将资源对应的全部标签信息都融入到原始文本中，可以顺利支持单一实体对应多个外部资源标签的场景，保证了在相应场景中槽位识别的准确率。

如此，根据拼接处理得到的第二编码向量、构建的第一位置向量以及第二位置向量，可用以进行后续的槽位识别，在第二编码向量中包括了语音请求中对应外部资源库中的实体所具有的全部外部标签信息，根据第一位置向量、第二位置向量可确定以编码信息拼接至语音请求中的标签信息对应的语音请求中的实体，从而可进行后续的槽位识别。

本申请实施方式可以将外部资源库所返回的信息进行融合，增加了在槽位识别任务上的有效范围和识别精度，大大提升了对于用户指令的理解能力和与用户的交互能力。同时，将额外特征融入到端到端模型中，不需额外维护一个庞大的业务逻辑库和规则引擎，可显著减少后续人员的维护时间，精简了维护流程，提高了开发效率。本申请实施方式还顺利支持了实体同时对应多个外部资源标签时的场景，增强了兼容能力和鲁棒性。

此外，需要说明地，本申请实施方式为一个通用的融合外部资源的端到端槽位识别方案，融合方式不需要依靠垂域专业知识以及人工干预，因此适用于车控、百科、天气、电话等全部相关垂域，而不只限于上述实施例中出现的垂域。

请参阅图12，在某些实施方式中，步骤06包括：

061：根据语音请求、槽位识别的结果、预测到的应用程序接口和预测到的应用程序接口类型确定槽位填充的目标参数；

062：根据槽位识别的结果和目标参数，选择预测到的应用程序接口执行应用程序接口参数填充，输出执行结果下发至车辆完成语音交互。

在某些实施方式中，处理器用于根据语音请求、槽位识别的结果、预测到的应用程序接口和预测到的应用程序接口类型确定槽位填充的目标参数，以及根据槽位识别的结果和目标参数，选择预测到的应用程序接口执行应用程序接口参数填充，输出执行结果下发至车辆完成语音交互。

具体地，可根据用户语音请求、槽位识别的结果，以及预测到的应用程序接口和接口类型确定槽位填充的目标参数。目标参数即为槽位识别结果对应的槽位名称。最终，可根据槽位识别的结果和目标参数，选择预测到的应用程序接口，执行所填充的目标参数，并将输出的执行结果下发至车辆，以完成语音交互。

例如，对于用户语音请求“播放听妈妈的话”，槽位识别的结果为：[“听妈妈的话”——歌名(song)]，应用程序接口1的参数包括“歌手”和“歌曲”2个参数，对应的应用程序接口类型为“播放音乐(MusicPlayer)”类型，进而判断得到槽位识别的结果中的“播放听妈妈的话”需要填充到应用程序接口1中的目标参数为“歌名”，将槽位识别的结果中的“听妈妈的话”填充到播放音乐的应用程序接口1后，可相应地执行打开音乐播放器并播放相应歌曲的动作，完成语音交互。

又如，对于用户语音请求“导航去中关村”，槽位识别的结果：[“中关村”——地名(Place)]，应用程序接口2的参数包括“出发地”和“目的地”2个参数，对应的应用程序接口类型为“导航”类型，进而判断得到槽位识别的结果中的“中关村”需要填充到应用程序接口2中的目标参数为“目的地”，则将槽位识别的结果中的“中关村”填充到导航的应用程序接口2后可以相应地执行导航至中关村的导航任务，从而完成语音交互。

如此，本申请可以根据槽位识别的结果和目标参数，选择预测到的应用程序接口执行应用程序接口参数填充，直接输出执行结果下发至车辆完成语音交互，可以降低车载系统的延时，提升对于用户指令的响应速度。

本申请实施方式的计算机可读存储介质，存储有计算机程序，当计算机程序被一个或多个处理器执行时，实现上述的方法。

在本说明书的描述中，参考术语“上述”、“具体地”、“特别地”、“进一步地”等的描述意指结合实施方式或示例描述的具体特征、结构、材料或者特点包含于本申请的至少一个实施方式或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施方式或示例。而且，描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施方式或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多用于实现特定逻辑功能或过程的步骤的可执行请求的代码的模块、片段或部分，并且本申请的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本申请的实施例所属技术领域的技术人员所理解。

尽管上面已经示出和描述了本申请的实施方式，可以理解的是，上述实施方式是示例性的，不能理解为对本申请的限制，本领域的普通技术人员在本申请的范围内可以对上述实施方式进行变化、修改、替换和变型。