智能外呼的处理方法及系统与流程

电子通信装置的制造及其应用技术1.本技术实施例涉及的智能外呼技术领域，尤其涉及一种智能外呼的处理方法及系统。背景技术：2.随着智能语音机器人相关技术的发展，呼叫中心利用智能语音机器人执行对客户的外呼任务成为可能。3.现有执行外呼任务的过程中，会存在空号、停机、关机等大量的无效外呼电话。当执行对无效外呼电话的呼叫时，呼叫中心需要持续等待直至呼叫振铃音结束时，该外呼任务才能触发自动挂机。显然的，这样的外呼处理方式会使得呼叫中心需要花费大量时间等待外呼任务的自动结束，其处理效率较低，造成呼叫线路资源的浪费。技术实现要素：4.本技术实施例提供的一种智能外呼的处理方法及系统，用于节约呼叫中心在进行外呼任务时的线路资源，提升外呼处理效率。5.第一方面，本技术提供了一种智能外呼的处理方法，包括：6.获取呼叫中心发送的振铃音，其中，该振铃音是在该呼叫中心执行外呼任务时该呼叫中心进入呼叫等待阶段时获取的；7.调用预先训练的通话状态识别模型识别该振铃音中的振铃音片段所表征的通话状态，得到该外呼任务的识别结果；8.将该外呼任务的识别结果发送至该呼叫中心，以使该呼叫中心根据该识别结果执行对该外呼任务的挂机操作。9.可知的是，本技术实施方式通过调用预先训练的通话状态识别模型，以对呼叫中心进入呼叫等待阶段时所生成的振铃音中振铃音片段所表征的通话状态进行识别，以得到外呼任务的识别结果，该识别结果将被返回至呼叫中心，使得呼叫中心可根据该识别结果触发对外呼任务的挂机操作，从而实现对线路资源的提前释放，进而提升对外呼任务的处理效率。10.可选的，获取呼叫中心发送的振铃音，包括：11.建立与该呼叫中心之间的通信通道，并通过该通信通道接收该呼叫中心发送的振铃音；12.该处理方法，还包括：若在预设时间段内，调用预先训练的通话状态识别模型未能识别出该振铃音片段所表征的通话状态，则停止对该振铃音进行识别并断开与该呼叫中心之间的该通信通道。13.可知的是，本技术实施方式中，为了使得服务器能够对更多的外呼任务进行有效识别，当服务器未能在预设时间段内获取到当前振铃音对应的识别结果，则不再对当前外呼任务的振铃音进行处理。14.可选的，该方法还包括：15.根据预设的滑动窗口，对该振铃音进行截取处理，得到该振铃音片段。16.可选的，该方法还包括：17.获取该振铃音对应的时间序列；该时间序列用于表示该振铃音中各音频帧的播放时间；18.该根据预设的滑动窗口，对该振铃音进行截取处理，得到该振铃音片段，包括：19.确定该滑动窗口在该时间序列上所对应的时间起始点和时间截止点；20.截取该时间起始点对应的音频帧作为振铃音片段的起始帧、截取该时间截止点对应的音频帧作为振铃音片段的截止帧；21.该起始帧、该截止帧以及该起始帧和该截止帧之间的连续音频帧，构成振铃音片段。22.可知的是，本技术实施方式中通过利用预设的滑动窗口以实现将振铃音截取成为具有有效信息的振铃音片段，从而利于模型对振铃音片段进行有效识别，得到相应的识别结果。23.可选的，该振铃音片段的数量为多个；相邻的两个该振铃音片段之间存在重叠区域。24.可选的，该调用预先训练的通话状态识别模型识别该振铃音中的振铃音片段所表征的通话状态，得到该外呼任务的识别结果，包括：25.调用预先训练的通话状态识别模型分别对各该振铃音片段的音频特征进行识别处理，得到各振铃音片段所表征的通话状态；若任意一个该振铃音片段表征的通话状态为通话失败状态，则该外呼任务的识别结果为通话失败，执行将该外呼任务的识别结果发送至该呼叫中心的步骤。26.可选的，该通话失败状态包括忙线状态、空号状态、关机状态、停机状态、不在服务区状态、无法接通状态、无人接听状态中的任意一种呼叫状态。27.可知的是，本技术实施方式中的振铃音片段的数量为多个，通过对多个振铃音片段进行分别识别，以进一步提升对振铃音所表征的通话状态的识别准确率。28.可选的，该调用预先训练的通话状态识别模型识别该振铃音中的振铃音片段所表征的通话状态，包括：对该振铃音片段进行特征提取处理，得到该振铃音片段的对数滤波器组特征；将该振铃音片段的该对数滤波器组特征输入至该预先训练的通话状态识别模型，以使该预先训练的通话状态识别模型对该对数滤波器组特征依次进行音频特征提取处理和基于前馈神经网络的通话状态分类处理，输出该振铃音片段所表征的通话状态。29.可选的，该方法还包括：30.基于门控循环网络和焦点损失函数，构建待训练的通话状态识别模型；利用多个样本振铃音片段和每个样本振铃音片段的标注状态对该待训练的通话状态识别模进行训练，得到该预先训练的通话状态识别模型；其中，样本振铃音片段的标注状态包括忙线状态、空号状态、关机状态、停机状态、不在服务区状态、无法接通状态、无人接听状态中的任意一种呼叫状态。31.第二方面，本技术提供了一种智能外呼的处理方法，包括：32.执行外呼任务并在进入呼叫等待阶段时生成振铃音，将该振铃音发送至服务器；33.接收该服务器返回的该外呼任务的识别结果，并根据该识别结果对该外呼任务进行挂机操作；其中，该外呼任务的识别结果是该服务器调用预先训练的通话状态识别模型识别该振铃音中的振铃音片段所表征的通话状态所得到的。34.第三方面，本技术提供了一种智能外呼的处理系统，该智能外呼的处理系统应用于服务器；35.该智能外呼的处理系统，包括：36.语音流获取模块，用于获取呼叫中心发送的振铃音，其中，该振铃音是在该呼叫中心执行外呼任务时该呼叫中心进入呼叫等待阶段时获取的；37.算法调用模块，用于调用预先训练的通话状态识别模型识别该振铃音中的振铃音片段所表征的通话状态，得到该外呼任务的识别结果；38.结果发送模块，用于将该外呼任务的识别结果发送至该呼叫中心，以使该呼叫中心根据该识别结果执行对该外呼任务的挂机操作。39.第四方面，本技术提供了一种智能外呼的处理系统，该智能外呼的处理系统应用于呼叫中心；40.该智能外呼的处理系统，包括：41.语音流发送模块，用于执行外呼任务并在进入呼叫等待阶段时生成振铃音，将该振铃音发送至服务器；42.结果接收模块，用于接收该服务器返回的该外呼任务的识别结果；其中，该外呼任务的识别结果是该服务器调用预先训练的通话状态识别模型识别该振铃音中的振铃音片段所表征的通话状态所得到的；43.挂机执行模块，用于根据该识别结果对该外呼任务进行挂机操作。44.第五方面，本技术提供了一种电子设备，包括：45.至少一个处理器；以及46.存储器；47.所述存储器存储计算机执行指令；48.所述至少一个处理器执行所述存储器存储的计算机执行指令，使得所述至少一个处理器执行如第一方面或第二方面所述的方法。49.第六方面，本技术提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，当处理器执行所述计算机执行指令时，实现如第一方面或第二方面所述的方法。50.第七方面，本技术提供了一种计算机程序产品，包括计算机指令，该计算机指令被处理器执行时实现如第一方面或第二方面所述的方法。51.本技术实施例提供的智能外呼的处理方法及系统，当呼叫中心执行外呼任务时，呼叫中心会将进入呼叫等待阶段所产生的振铃音发送至服务器，服务器会调用预先训练的通话状态识别模型，以对该振铃音中的振铃音片段的音频特征进行通话状态识别处理，若服务器得到识别结果，则将该识别结果告知于呼叫中心，而呼叫中心可根据该识别结果触发对外呼任务的挂机操作，从而实现对线路资源的提前释放，进而提升对外呼任务的处理效率。附图说明52.此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。53.图1为现有技术中提供的一种智能外呼的处理流程示意图；54.图2为本技术所基于的一种网络架构的示意图；55.图3为本技术实施例提供的一种智能外呼的处理方法的信令交互示意图；56.图4为本技术实施例提供的一种智能外呼的处理方法的流程示意图；57.图5为本技术实施方式提供的一种振铃音片段的截取示意图；58.图6为本技术实施方式提供的一种振铃音片段的识别的示意图；59.图7为本技术实施例提供的一种智能外呼的处理方法的流程示意图；60.图8为本技术实施例提供的一种智能外呼的处理系统的架构框图；61.图9为本技术实施例提供的另一种智能外呼的处理系统的架构框图；62.图10为本技术提供的一种电子设备的硬件结构示意图。63.通过上述附图，已示出本公开明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本公开构思的范围，而是通过参考特定实施例为本领域技术人员说明本公开的概念。具体实施方式64.这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的系统和方法的例子。65.本技术的技术方案中，所涉及的各类信息的收集、存储、使用、加工、传输、提供和公开等处理，均符合相关法律法规的规定，且不违背公序良俗。66.智能外呼技术是一种综合利用自动语音识别(automatic speech recognition，asr)、文字转语音(text to speech，tts)以及自然语言理解(natural language understanding，简称nlu)技术。67.随着智能外呼技术的发展，将该智能外呼技术集成在智能语音机器人中，以依靠智能语音机器人执行对客户的外呼任务成为可能。68.图1为现有技术中提供的一种智能外呼的处理流程示意图，如图1所示，客户业务系统会根据需求生成若干待执行的外呼任务，任务调度单元会将这些外呼任务分配给呼叫中心，而呼叫中心在接收到任务调度单元分配的呼叫任务之后，将会执行该呼叫任务，即根据任务中的客户联系方式开始拨打客户电话。69.在呼叫中心进行呼叫的过程中，当呼叫成功时(即客户接起电话)，呼叫中心将利用智能外呼技术调用智能语音机器人实现与客户的人机对话。反之，当呼叫失败时(即客户未接起电话)，呼叫中心会将电话未接通的原因通知给智能外呼的任务调度单元，以便任务调度单元通知客户业务系统执行后续处理。70.在现有技术中，呼叫中心是无法对当前外呼任务的状态进行感知的，即当外呼任务的电话未能接通时，需要持续进行呼叫等待直至呼叫振铃音结束，外呼任务所呼叫的号码的运营商会将该呼叫挂断，呼叫中心触发挂机。此时，运营商会向呼叫中心返回一信令sip code，并通过该信令中所携带的信令编码告知呼叫中心本次呼叫的失败状态，如占线、号码不存在、无人接听。71.显然的，这样的外呼处理方式会使得呼叫中心需要花费大量时间进行呼叫等待，特别是当外呼任务中呼叫处于通话失败状态时，呼叫中心只能等待外呼任务的自动结束，其处理效率较低，造成呼叫线路资源的浪费。72.面对上述问题，相对于图1所示方案，本技术实施方式中，当呼叫中心执行外呼任务时，呼叫中心会将进入呼叫等待阶段所产生的振铃音发送至服务器，服务器会调用预先训练的通话状态识别模型，以对该振铃音中的振铃音片段所表征的通话状态进行识别，以得到外呼任务的识别结果。当呼叫中心从服务器得到该识别结果之后，可基于该识别结果触发对外呼任务的挂机操作，从而实现对线路资源的提前释放，进而提升对外呼任务的处理效率。73.同时在其他方面，现有的信令编码仅能用于区分有限类型的失败状态(如前所述的占线、号码不存在、无人接听)，而对于因用户无法接听，停机，关机等多种原因导致的呼叫未接通，信令编码均将其归结于无人接听，这使得呼叫中心很难判断外呼任务的失败状态的具体类型。74.而在本技术实施方式中，通过利用对振铃音片段所表征的通话状态的识别还能够快速的获取到该外呼任务的具体通话状态，进而便于呼叫中心根据通话状态确定出外呼任务的失败原因，实现对失败原因的收集和上报处理，利于提升智能外呼系统的运营效率。75.参考图2，图2为本技术所基于的一种网络架构的示意图，图2所示网络架构具体可包括任务调度单元21、呼叫中心22以及服务器23。76.在图2所示架构中，任务调度单元21具体可为可用于对外呼任务进行任务分配、调度、排期的硬件服务器或软件单元。当任务调度单元21获取到待调度的外呼任务之后，可确定各呼叫中心22中的空闲状态/忙碌状态，以将待调度的外呼任务分配至处于空闲状态的呼叫中心。77.呼叫中心22是指用于执行外呼任务的服务器集群，其中，呼叫中心22中的每个呼叫中心均可独立执行任务调度单元21下发的呼叫任务。在图2所示的呼叫中心22中，每个呼叫中心具体可包括互动式语音应答单元(interactive voice response，ivr)和接口单元(freeswitch)。其中，互动式语音应答单元可通过eventsocketlink与接口单元对接，发起呼叫、控制asr-nlu-tts流程、处理挂机事件、呼叫失败信令解析，而接口单元则负责sip信令的收发和sip session的管理、振铃音的对接和转发等处理。78.服务器23具体可为用于执行对振铃音的识别和相关处理的云端计算系统，其具体可包括有转接单元(realpipe)和模型算法服务单元。其中，转接单元用于与呼叫中心22对接，获取振铃音的音频流数据，并用于对音频流数据进行rtp的流缓存处理，还用于调用模型算法服务单元以对振铃音进行识别，在获取到识别结果后，回调呼叫中心以进行识别结果上报。而调用模型算法服务单元则预先部署有预先训练的通话状态识别模型，该模型可用于对输入的音频数据进行识别，以输出音频数据所表征通话状态。79.结合图2所示的网络结构，图3为本技术实施例提供的一种智能外呼的处理方法的信令交互示意图。80.如图3所示的，呼叫中心在执行外呼任务时，当接口单元(freeswitch)接收到来自上游的183信令之后，接口单元会向互动式语音应答单元(ivr)发送channel_progress_media事件。81.其中，183信令为sip会话中的标准信令，其一般用于告知呼叫中心准备接收振铃音。channel_progress_media事件是内置在接口单元(freeswitch)的一个进程事件，用于告知互动式语音应答单元(ivr)调用振铃音识别程序。而互动式语音应答单元(ivr)在监听到channel_progress_media事件之后，将开启振铃音识别程序，并调用接口单元(freeswitch)与服务器中的转接单元(realpipe)建立通信通道。82.其中，在通信通道的建立过程中，接口单元(freeswitch)会向转接单元(realpipe)发送一通信通道请求(invite)，当接收转接单元(realpipe)回复的200信令之后，接口单元(freeswitch)将得知通信通道完成建立。其中，200信令为sip会话中的标准信令，其一般用于确认回复。83.同步的，接口单元(freeswitch)接收上游发送的振铃音(rtp steam)，并在通信通道完成建立之后将该振铃音转发给服务器的转接单元(realpipe)。其中，该振铃音的音频流可为标准流，如，基于320bit/20ms的rtp语音流。84.此时，转接单元(realpipe)会将该振铃音(rtp steam)缓存在本地，并按照预设的策略调用模型算法服务单元(eas)对振铃音片段进行识别。85.随后，当模型算法服务单元(eas)对振铃音片段进行识别，得到通话失败状态的识别结果时，模型算法服务单元(eas)将该识别结果告知于转接单元(realpipe)。此时，转接单元(realpipe)将断开与接口单元(freeswitch)之间的通信通道，并将识别结果告知于互动式语音应答单元(ivr)。86.其中，转接单元(realpipe)可通过呼叫中心的回调地址将识别结果告知于互动式语音应答单元(ivr)。具体的，由于网络中的呼叫中心的数量为多个，在当前呼叫中心与服务器建立通信通道之后，还会将当前呼叫中心在网络中的通信地址预先告知于服务器，以作为回调地址，以便转接单元(realpipe)可通过呼叫中心的回调地址将识别结果告知于互动式语音应答单元(ivr)。87.互动式语音应答单元(ivr)将调用接口单元(freeswitch)执行对当前外呼任务的挂机操作，接口单元(freeswitch)与上游断开。互动式语音应答单元(ivr)还会将识别结果告知于任务调度单元(cab),以便任务调度单元(cab)能够记录该外呼任务的状态并进行后续处理。88.当然，若模型算法服务单元(eas)在预设时间段内，未能向转接单元(realpipe)返回通话状态，即预先训练的通话状态识别模型未能识别出振铃音片段所表征的通话状态，则转接单元(realpipe)会停止对模型算法服务单元(eas)的调用并不再对该振铃音进行识别；同时，服务器的转接单元(realpipe)还将断开与接口单元(freeswitch)之间的通信通道，并等待下一次的通信通道的建立。89.结合图2和图3可知，与现有技术不同的是，在本技术实施方式中，当呼叫中心执行外呼任务时，呼叫中心会将进入呼叫等待阶段所产生的振铃音发送至服务器，服务器会调用预先训练的通话状态识别模型，以对该振铃音中的振铃音片段所表征的通话状态进行识别，以得到外呼任务的识别结果。当呼叫中心从服务器得到该识别结果之后，可基于该识别结果触发对外呼任务的挂机操作，从而实现对线路资源的提前释放，进而提升对外呼任务的处理效率。此外，本实施方式还通过利用对振铃音片段所表征的通话状态的识别还能够快速的获取到该外呼任务的具体通话状态，进而便于呼叫中心根据通话状态确定出外呼任务的失败原因，实现对失败原因的收集和上报处理，利于提升智能外呼系统的运营效率。90.下面将通过多个方面，对本技术提供的智能外呼的处理方法及系统进行详细说明。下面的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。91.需要说明的是，本实施例中提供的智能外呼的处理方法的执行主体为前述提及的服务器，图4为本技术实施例提供的一种智能外呼的处理方法的流程示意图。如图4所示的，该智能外呼的处理方法可以包括如下几个步骤：92.步骤401、获取呼叫中心发送的振铃音，其中，振铃音是在呼叫中心执行外呼任务时呼叫中心进入呼叫等待阶段时获取的。93.需要说明的是，振铃音，又叫早媒体(early media)，其一般出现在主叫方呼叫被叫方时的呼叫等待阶段，即当主叫方叫被叫方时，由于被叫方未能及时应答，将会有几秒到几十秒的时间，这段时间将作为呼叫等待阶段，而这段时间主叫方与运营商之间的媒体流，则被称为振铃音。一般的呼叫等待阶段的时间长短取决于被叫方应答的时间。94.结合图3可知，在本技术实施方式中，当呼叫中心监听获知该呼叫已经进入呼叫等待阶段时，呼叫中心可将当前生成的振铃音发送服务器，以供服务器进行后续处理。95.步骤402、调用预先训练的通话状态识别模型识别振铃音中的振铃音片段所表征的通话状态，得到外呼任务的识别结果。96.当服务器接收到呼叫中心发送的振铃音之后，服务器将调用模型算法服务单元中预先部署有预先训练的通话状态识别模型，以对该振铃音进行识别输出振铃音所表征通话状态。97.其中，由于振铃音是几秒到几十秒的时间的音频流，为了提升对于外呼任务的识别效率，在本实施方式中，将从振铃音中截取部分音频流以作为振铃音片段，并将振铃音片段作为模型输入进行识别和处理。98.同时，由于服务器中预先部署有预先训练的通话状态识别模型，该模型可以例如使用sota模型并采用hubert的方式进行训练，并经过mobilenets/gru模型部署至服务器中。在其他实施例中，通话状态识别模型可以是任何合适的预训练模型。99.具体的，在服务器调用模型算法服务单元以对从振铃音中截取得到的振铃音片段进行通话状态的识别。其中，模型算法服务单元可先对振铃音片段进行特征提取处理，得到振铃音片段的对数滤波器组特征；然后，再将振铃音片段的对数滤波器组特征输入至预先训练的通话状态识别模型，以使预先训练的通话状态识别模型对对数滤波器组特征依次进行音频特征提取处理和基于前馈神经网络的通话状态分类处理，输出振铃音片段所表征的通话状态。100.示例性的，针对任意振铃音片段a进行特征提取，得到数滤波器组特征f1，其中，f1∈rn×l；n是滤波器组数，l是特征长度。然后，将振铃音片段a的对数滤波器组特征f1输入至预先训练的通话状态识别模型。此时，模型将对该对数滤波器组特征f1进行音频特征提取处理，得到音频特征f2，其中，f2∈rm；m是音频特征维度。最后，将音频特征f2输入模型的前馈神经网络以进行通话状态分类处理，输出振铃音片段所表征的通话状态的概率分布pt∈rc，其中，c是通话状态类别数。通过上述方式，能够实现对振铃音所中的振铃音片段所表征的通话状态进行识别，输出振铃音片段所表征的通话状态。101.此外，为了使得模型能够对振铃音片段所表征的通话状态进行准确识别，在可选实施方式中，还提供了模型的构建和训练过程，具体可包括：首先，基于门控循环网络和焦点损失函数，构建待训练的通话状态识别模型，然后，利用多个样本振铃音片段和每个样本振铃音片段的标注状态对待训练的通话状态识别模进行训练，得到预先训练的通话状态识别模型。102.其中，样本振铃音片段可通过对历史振铃音进行随机截取获得，而每个样本振铃音片段对应的标注状态则可通过人工标注实现，其中，样本振铃音片段的标注状态包括忙线状态、空号状态、关机状态、停机状态、不在服务区状态、无法接通状态、无人接听状态中的任意一种呼叫状态。103.在模型训练过程中，由于模型采用了焦点损失函数lfocal作为声学模型的分类器损失函数，因此，在每次利用样本振铃音片段完成对模型的更新之后，需要计算如下函数，以对模型是否完成训练进行判定：104.lfocal＝-(1-pt)γlog(pt)105.其中γ是调制系数且γ≥0，示例性的，该γ取值可为2。通过引入焦点损失函数，能有效减少易分类样本的权重，进而鼓励模型在训练时专注于难分类的样本，进而提升模型的训练效果和模型的识别准确率。通过上述的模型构建和训练方式，能够得到可用于对振铃音片段所表征的通话状态进行识别的模型，有利于提升振铃音通话状态的识别效率和识别准确率。106.在调用模型对振铃音片段进行识别的过程中，振铃音片段相对于振铃音的位置，将影响外呼任务的识别结果的准确率。具体来说，经过预先对振铃音各音频帧所表征内容的分析可知，用于表征通话状态的提示音或语音提示信息一般出现在振铃音的第5-20秒的音频帧中。通过对该部分音频帧的截取和识别，能够更为准确和快速的获取到该外呼任务的通话状态。107.基于此，为了能够对振铃音片段进行准确截取，在可选实施方式中，服务器在接收并缓存振铃音之后，可通过利用预设的滑动窗口，对振铃音进行截取处理，得到振铃音片段。108.其中，滑动窗口是一种基于时间轴或时间序列对音频流进行截取的采样方式，其中，滑动窗口可与音频流的时间轴或时间序列进行结合并沿时间轴或时间序列进行滑动，滑动窗口在时间轴或时间序列所圈选出的时间段所对应的数据，将作为滑动窗口所截取的片段。109.基于此，在可能的实施方式中，服务器可根据前期分析的结果预先配置滑动窗口的时间起始点和时间截止点，以使滑动窗口能够覆盖前述提及的振铃音的第5-20秒的音频帧。如可配置该滑动窗口截取从第4秒至第21秒的音频帧以作为相应的振铃音片段，此时，该振铃音片段将有较大概率覆盖到该外呼任务的振铃音的有效信息，这将提升模型对振铃音片段的识别效果。110.在截取时，服务器还将获取振铃音对应的时间序列；该时间序列可用于表示振铃音中各音频帧的播放时间。而服务器在进行振铃音片段截取时，可先确定所述滑动窗口在所述时间序列上所对应的时间起始点和时间截止点；然后，截取所述时间起始点对应的音频帧作为振铃音片段的起始帧、截取所述时间截止点对应的音频帧作为振铃音片段的截止帧；最后，所述起始帧、所述截止帧以及所述起始帧和所述截止帧之间的连续音频帧，构成振铃音片段。111.图5为本技术实施方式提供的一种振铃音片段的截取示意图，以对图5所示的振铃音片段50进行截取为例：112.在截取振铃音片段50时，服务器首先可确定滑动窗口51在振铃音52的时间序列上所对应的时间起始点和时间截止点；然后，服务器截取该时间起始点对应的音频帧521作为振铃音片段50的起始帧501、截取时间截止点对应的音频帧522作为振铃音片段50的截止帧502；起始帧501、截止帧502以及起始帧501和截止帧502之间的连续音频帧，构成振铃音片段50。113.在上述实施方式的基础上，服务器还可通过对振铃音进行多次截取的方式，以使多次截取得到的各振铃音片段的集合对前述提及的振铃音的第5-20秒的音频帧进行覆盖。其中，振铃音片段的数量为多个，其中，相邻的两个振铃音片段之间可存在重叠区域，通过这样的方式使得各振铃音片段能够覆盖振铃音足够多的有效信息，114.进一步的，对振铃音进行多次截取，可通过重复执行截取和滑动窗口的窗口位移操作来实现。其中，利用同一个滑动窗口进行窗口位移则可实现对振铃音进行多次截取。可选的，对滑动窗口进行窗口位移时，可使得每一次窗口位移的时间长度将小于滑动窗口本身的时间跨度(如，窗口的时间跨度为7秒，窗口位移的时间长度为5秒)，采用这样的窗口位移的方式能够保证每次截取所获得的相邻的振铃音片段之间存在一定的重叠，避免出现有效信息的遗漏的问题。115.当然，当需要对振铃音的多个振铃音片段进行识别时，可通过如下确定识别结果：调用模型对振铃音所对应的每一个振铃音片段所表征的通话状态依次进行识别。其中，若任意一个振铃音片段表征的通话状态为通话失败状态，则外呼任务的识别结果为通话失败，执行将外呼任务的识别结果发送至呼叫中心的步骤。通话失败状态将包括忙线状态、空号状态、关机状态、停机状态、不在服务区状态、无法接通状态、无人接听状态中的任意一种呼叫状态。116.图6为本技术实施方式提供的一种振铃音片段的识别的示意图，如图6所示的，通过利用滑动窗口对振铃音进行截取可获得如下的多个振铃音片段。117.在第一次截取时，滑动窗口在时间序列上的时间起始点和时间截止点分别为第4秒和第9秒，此时，利用该滑动窗口对振铃音进行截取将获得第4秒至第10秒的连续音频帧以作为其中一个振铃音片段60。118.此时，服务器将调用一次预先训练的通话状态识别模型，以对该振铃音片段60进行识别。在图6的示例中，由于对该振铃音片段60进行识别后，确定出该振铃音片段60所表征的通话状态不属于上述忙线状态、空号状态、关机状态、停机状态、不在服务区状态、无法接通状态、无人接听状态中的任意一种呼叫状态，即模型将无法输出振铃音片段60所表征的通话状态。119.随后，对该滑动窗口进行窗口位移，并进行第二次截取，经过窗口位移后的滑动窗口在时间序列上的时间起始点和时间截止点分别为第9秒和第15秒，此时，利用该滑动窗口对振铃音进行截取将获得第9秒至第15秒的连续音频帧以作为其中一个振铃音片段61。120.此时，服务器将再次调用一次预先训练的通话状态识别模型，以对该振铃音片段61行识别。在图6的示例中，由于对该振铃音片段61进行识别后，确定出该振铃音片段61所表征的通话状态同样不属于上述的忙线状态、空号状态、关机状态、停机状态、不在服务区状态、无法接通状态、无人接听状态中的任意一种呼叫状态，即模型也无法输出振铃音片段61所表征的通话状态。121.类似的，重复对滑动窗口的窗口位移，并依次截取第14秒至第20秒的连续音频帧、第19秒至第25秒的连续音频帧…，以分别作为各振铃音片段。122.其中，当服务器获得第14秒至第20秒的连续音频帧以作为振铃音片段62后，服务器将再次调用一次预先训练的通话状态识别模型，以对该振铃音片段62行识别。在图6的示例中，由于对该振铃音片段62进行识别后，确定出该振铃音片段62所表征的通话状态于上述的忙线状态的呼叫状态，即模型将输出振铃音片段62所表征的通话状态为基于忙线状态的通话失败状态，此时服务器将确定出该外呼任务的识别结果为通话失败。123.也就是说，当通话状态识别模型识别出上述各振铃音片段中的任意一个片段，表征为忙线状态、空号状态、关机状态、停机状态、不在服务区状态、无法接通状态、无人接听状态中的任意一种呼叫状态时，则证明该外呼任务已经通话失败，此时将得到外呼任务的识别结果，该识别结果中会包括有片段所表征的实际呼叫状态。124.步骤403、将外呼任务的识别结果发送至呼叫中心，以使呼叫中心根据识别结果执行对外呼任务的挂机操作。125.具体的，服务器会将外呼任务的识别结果发送至呼叫中心，以使呼叫中心根据识别结果执行对外呼任务的挂机操作。也就是说，服务器会将该外呼任务是基于忙线状态的通话失败的识别结果发送至呼叫中心。126.当然，如图3所示的，在呼叫中心在接收到该识别结果之后，可触发对该外呼任务的挂机操作，即停止对该呼叫的呼叫等待并释放呼叫线路资源。可选的，在呼叫中心执行挂机操作之后，还会将该外呼任务的失败原因(如前的忙线状态)上报至任务调度单元，以供任务调度单元基于外呼任务的失败原因进行后续处理。可知的是，当呼叫中心完成对线路资源的释放之后，呼叫中心将处于空闲状态，此时，任务调度单元可重新为该呼叫中心分配新的外呼任务，以使呼叫中心执行该新的外呼任务。127.本实施例提供的智能外呼的处理方法中，当呼叫中心执行外呼任务时，呼叫中心会将进入呼叫等待阶段所产生的振铃音发送至服务器，服务器会调用预先训练的通话状态识别模型，以对该振铃音中的振铃音片段进行通话状态识别处理，若服务器得到识别结果，则将该识别结果告知于呼叫中心，而呼叫中心可根据该识别结果触发对外呼任务的挂机操作，从而实现对线路资源的提前释放，进而提升对外呼任务的处理效率。128.在上述各实施方式的基础上，本实施例中提供的智能外呼的处理方法的执行主体为前述提及的呼叫中心，图7为本技术实施例提供的一种智能外呼的处理方法的流程示意图。如图7所示的，该智能外呼的处理方法可以包括如下几个步骤：129.步骤701、执行外呼任务并在进入呼叫等待阶段时生成振铃音，将振铃音发送至服务器。130.步骤702、接收服务器返回的外呼任务的识别结果，并根据识别结果对外呼任务进行挂机操作；其中，外呼任务的识别结果是服务器调用预先训练的通话状态识别模型识别振铃音中的振铃音片段所表征的通话状态所得到的。131.与现有技术不同的是，在本技术实施方式中，当呼叫中心执行外呼任务时，呼叫中心会将进入呼叫等待阶段所产生的振铃音发送至服务器，以使服务器调用预先训练的通话状态识别模型，以对该振铃音中的振铃音片段所表征的通话状态进行识别。132.结合图3可知的是，当服务器得到振铃音的识别结果之后，服务器会将该识别结果告知于呼叫中心。此时，呼叫中心会基于该识别结果触发对外呼任务的挂机操作。其实施方式中的具体交互以及相关处理流程与前述实施方式中的相应流程类似，在本实施方式中不进行再次赘述。133.此外，本实施方式的呼叫中心还将根据识别结果确定外呼任务的失败原因，并将失败原因上报至任务调度单元，从而便于任务调度单元根据外呼任务的失败原因进行后续处理，提升智能外呼系统的运营效率。134.本实施例提供的智能外呼的处理方法中，当呼叫中心执行外呼任务时，呼叫中心会将进入呼叫等待阶段所产生的振铃音发送至服务器，服务器会调用预先训练的通话状态识别模型，以对该振铃音中的振铃音片段进行通话状态识别处理，若服务器得到识别结果，则将该识别结果告知于呼叫中心，而呼叫中心可根据该识别结果触发对外呼任务的挂机操作，从而实现对线路资源的提前释放，进而提升对外呼任务的处理效率。135.对应于上文实施例提供的智能外呼的处理方法，图8为本技术实施例提供的一种智能外呼的处理系统的架构框图。为了便于说明，仅示出了与本技术实施例相关的部分。参照图8，该智能外呼的处理系统设置于服务器，该智能外呼的处理系统包括：136.语音流获取模块810，用于获取呼叫中心发送的振铃音，其中，所述振铃音是在所述呼叫中心执行外呼任务时所述呼叫中心进入呼叫等待阶段时获取的；137.算法调用模块820，用于调用预先训练的通话状态识别模型识别所述振铃音中的振铃音片段所表征的通话状态，得到所述外呼任务的识别结果；138.结果发送模块830，用于将所述外呼任务的识别结果发送至所述呼叫中心，以使所述呼叫中心根据所述识别结果执行对所述外呼任务的挂机操作。139.可选的，语音流获取模块810，具体用于：建立与所述呼叫中心之间的通信通道，并通过所述通信通道接收所述呼叫中心发送的振铃音；若在预设时间段内，算法调用模块820调用预先训练的通话状态识别模型未能识别出所述振铃音片段所表征的通话状态，则算法调用模块820停止对所述振铃音进行识别，所述语音流获取模块810用于断开与呼叫中心之间的所述通信通道。140.可选的，该系统还包括：片段截取模块，所述片段截取模块用于根据预设的滑动窗口，对所述振铃音进行截取处理，得到所述振铃音片段。141.可选的，语音流获取模块810还用于获取所述振铃音对应的时间序列；所述时间序列用于表示所述振铃音中各音频帧的播放时间。142.所述片段截取模块具体用于：确定所述滑动窗口在所述时间序列上所对应的时间起始点和时间截止点；截取所述时间起始点对应的音频帧作为振铃音片段的起始帧、截取所述时间截止点对应的音频帧作为振铃音片段的截止帧；所述起始帧、所述截止帧以及所述起始帧和所述截止帧之间的连续音频帧，构成振铃音片段。143.可选的，所述振铃音片段的数量为多个，相邻的两个所述振铃音片段之间存在重叠区域。144.可选的，算法调用模块820具体用于：调用预先训练的通话状态识别模型分别对各所述振铃音片段的音频特征进行识别处理，得到各振铃音片段所表征的通话状态；若任意一个所述振铃音片段表征的通话状态为通话失败状态，则所述外呼任务的识别结果为通话失败，执行将所述外呼任务的识别结果发送至所述呼叫中心的步骤。145.可选的，所述通话失败状态包括忙线状态、空号状态、关机状态、停机状态、不在服务区状态、无法接通状态、无人接听状态中的任意一种呼叫状态。146.可选的，算法调用模块820具体用于：对所述振铃音片段进行特征提取处理，得到所述振铃音片段的对数滤波器组特征；将所述振铃音片段的所述对数滤波器组特征输入至所述预先训练的通话状态识别模型，以使所述预先训练的通话状态识别模型对所述对数滤波器组特征依次进行音频特征提取处理和基于前馈神经网络的通话状态分类处理，输出所述振铃音片段所表征的通话状态。147.可选的，该系统还包括训练模块，该训练模块用于：基于门控循环网络和焦点损失函数，构建待训练的通话状态识别模型；利用多个样本振铃音片段和每个样本振铃音片段的标注状态对所述待训练的通话状态识别模进行训练，得到所述预先训练的通话状态识别模型；其中，样本振铃音片段的标注状态包括忙线状态、空号状态、关机状态、停机状态、不在服务区状态、无法接通状态、无人接听状态中的任意一种呼叫状态。148.本实施例提供的智能外呼的处理系统中，当呼叫中心执行外呼任务时，呼叫中心会将进入呼叫等待阶段所产生的振铃音发送至服务器，服务器会调用预先训练的通话状态识别模型，以对该振铃音中的振铃音片段进行通话状态识别处理，若服务器得到识别结果，则将该识别结果告知于呼叫中心，而呼叫中心可根据该识别结果触发对外呼任务的挂机操作，从而实现对线路资源的提前释放，进而提升对外呼任务的处理效率。149.对应于上文实施例提供的智能外呼的处理方法，图9为本技术实施例提供的另一种智能外呼的处理系统的架构框图。为了便于说明，仅示出了与本技术实施例相关的部分。参照图9，该智能外呼的处理系统设置于呼叫中心，该智能外呼的处理系统包括：150.语音流发送模块910，用于执行外呼任务并在进入呼叫等待阶段时生成振铃音，将所述振铃音发送至服务器；151.结果接收模块920，用于接收所述服务器返回的所述外呼任务的识别结果；其中，所述外呼任务的识别结果是所述服务器调用预先训练的通话状态识别模型识别所述振铃音中的振铃音片段所表征的通话状态所得到的；152.挂机执行模块930，用于根据所述识别结果对所述外呼任务进行挂机操作。153.本实施例提供的智能外呼的处理系统中，当呼叫中心执行外呼任务时，呼叫中心会将进入呼叫等待阶段所产生的振铃音发送至服务器，服务器会调用预先训练的通话状态识别模型，以对该振铃音中的振铃音片段进行通话状态识别处理，若服务器得到识别结果，则将该识别结果告知于呼叫中心，而呼叫中心可根据该识别结果触发对外呼任务的挂机操作，从而实现对线路资源的提前释放，进而提升对外呼任务的处理效率。154.图10为本技术提供的一种电子设备的硬件结构示意图，如图10所示的，本技术实施例提供一种电子设备，电子设备的存储器可用于存储至少一个程序指令，处理器用于执行至少一个程序指令，以实现上述方法实施例的技术方案。其实现原理和技术效果与上述方法相关实施例类似，此处不再赘述。155.本技术实施例提供一种计算机程序产品，当计算机程序产品在电子设备运行时，使得电子设备执行上述实施例中的技术方案。其实现原理和技术效果与上述相关实施例类似，此处不再赘述。156.本技术实施例提供一种计算机可读存储介质，其上存储有程序指令，程序指令被电子设备执行时，使得电子设备执行上述实施例的技术方案。其实现原理和技术效果与上述相关实施例类似，此处不再赘述。157.以上的具体实施方式，对本技术的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上仅为本技术的具体实施方式而已，并不用于限定本技术的保护范围，凡在本技术的技术方案的基础之上，所做的任何修改、等同替换、改进等，均应包括在本技术的保护范围之内。









图片声明：本站部分配图来自人工智能系统AI生成,觅知网授权图片,PxHere摄影无版权图库。本站只作为美观性配图使用,无任何非法侵犯第三方意图,一切解释权归图片著作权方,本站不承担任何责任。如有恶意碰瓷者,必当奉陪到底严惩不贷!




内容声明：本文中引用的各种信息及资料（包括但不限于文字、数据、图表及超链接等）均来源于该信息及资料的相关主体（包括但不限于公司、媒体、协会等机构）的官方网站或公开发表的信息。部分内容参考包括:(百度百科,百度知道,头条百科,中国民法典,刑法,牛津词典,新华词典,汉语词典,国家院校,科普平台)等数据,内容仅供参考使用,不准确地方联系删除处理！本站为非盈利性质站点,发布内容不收取任何费用也不接任何广告!




免责声明：我们致力于保护作者版权，注重分享，被刊用文章因无法核实真实出处，未能及时与作者取得联系，或有版权异议的，请联系管理员，我们会立即处理，本文部分文字与图片资源来自于网络，部分文章是来自自研大数据AI进行生成,内容摘自(百度百科,百度知道,头条百科,中国民法典,刑法,牛津词典,新华词典,汉语词典,国家院校,科普平台)等数据,内容仅供学习参考,不准确地方联系删除处理!的,若有来源标注错误或侵犯了您的合法权益，请立即通知我们，情况属实，我们会第一时间予以删除，并同时向您表示歉意,谢谢!