CN117527740A - 语音流审核方法、装置、计算机设备和存储介质 - Google Patents

Abstract

本申请提供了一种语音流审核方法、装置、计算机设备和存储介质。该语音流审核方法包括：响应于用户的上麦事件，获取用户的用户标签；用户标签用于反映用户在应用程序上的历史行为；判断用户标签是否命中预设的拉流条件；若是，则将用户的语音流推送至待拉流队列，以进行审核；若否，则对本次上麦事件不进行拉流。该方法通过用户标签和设定拉流条件，使拉流决策更加智能化和规则化，不再是全量拉流，而是实现语音流的精准拉取，只对真正存在风险的用户进行拉流，而不是全部用户，大大减少了拉流的数据量，降低了审核成本，也避免了数据量过大对审核效率的影响。

Description

语音流审核方法、装置、计算机设备和存储介质

技术领域

本申请涉及内容审核技术领域，尤其涉及一种语音流审核方法、装置、计算机设备和存储介质。

背景技术

随着互联网高速发展，社交软件的语音聊天技术也越来越成熟，语音聊天的用户数量越来越多，其中用户语音聊天涉及的内容也是多种多样，其中可能会涉及违规内容，这些内容会对平台产生一定的舆论影响，甚至还可能出现底线内的安全问题。因此平台需要对用户麦上的实时语音流进行监控，对违规内容进行实时处置，给予平台一个绿色安全的环境，提升用户的使用体验。传统技术中会对全平台的语音流进行拉流监控，导致审核成本非常庞大，对过多的非违规语音流进行审核也是对审核资源的浪费，过大的数据量还会导致审核效率受到影响。

发明内容

本申请的目的旨在至少能解决上述的技术缺陷之一，特别是现有技术中对语音流进行监控存在的成本高、资源浪费和审核效率低的技术缺陷。

第一方面，本申请提供了一种语音流审核方法，包括：

响应于用户的上麦事件，获取用户的用户标签；用户标签用于反映用户在应用程序上的历史行为；

判断用户标签是否命中预设的拉流条件；

若是，则将用户的语音流推送至待拉流队列，以进行审核；

若否，则对本次上麦事件不进行拉流。

在其中一个实施例中，获取用户的用户标签，包括：

获取用户的元事件表；元事件表中包括与用户在应用程序上的历史行为有关的记录；

从元事件表中提取出多个预设字段对应的目标记录表；

将目标记录表与各标签匹配条件进行比较，并将被命中的标签匹配条件对应的标签作为用户标签。

在其中一个实施例中，在用户的语音流进行审核的过程中，还包括：

在第一预设时间内，监控语音流的审核结果；

根据审核结果，判断是否满足需要延长监控；

若是，则返回在第一预设时间内，监控语音流的审核结果的步骤；

若否，则将语音流断流，并在断流第二预设时间后，将语音流重新推送至待拉流队列，并返回在第一预设时间内，监控语音流的审核结果的步骤。

在其中一个实施例中，审核结果包括属性和严重等级，根据审核结果，判断是否满足需要延长监控，包括：

在第一预设时间内，分别统计属性为违规或疑似在各严重等级的触发次数；

当触发次数超过严重等级对应的阈值时，判定需要延长监控；否则，判定不需要延长监控。

在其中一个实施例中，在第一预设时间内，监控语音流的审核结果之前，还包括：

获取用户所处房间的房间属性和上麦事件的触发时间；

根据触发时间与各预设时间区间进行匹配，并将命中的预设时间区间作为目标时间区间；

选用房间属性和目标时间区间对应的第一预设时间和第二预设时间。

在其中一个实施例中，在将用户的语音流推送至待拉流队列后，还包括：

对于待拉流队列中的任意一个语音流，根据该语音流对应的用户身份和房间属性，确定该语音流对应的分流策略；分流策略包括目标机审方和分流比例；

对于任意一个分流策略，将该分流策略对应的所有语音流按照分流比例，分别请求目标机审方进行机审。

在其中一个实施例中，在将该分流策略对应的所有语音流按照分流比例，分别请求目标机审方进行机审过程中，还包括：

按照第一预设间隔，确定目标机审方的实际审核片段比例；

若实际审核片段比例与初始的分流比例存在差异，则根据差异调整当前的分流比例。

在其中一个实施例中，在将该分流策略对应的所有待拉语音流按照分流比例，分别请求目标机审方进行机审过程中，还包括：

根据各目标机审方的请求反馈信息，判断目标机审方是否出现异常；

若是，则将出现异常的目标机审方替换为对应的容灾机审方。

在其中一个实施例中，目标审核方接收到语音流后，将语音流分割为语音片段进行机审，并将各语音片段及其对应的机审结果反馈；在将该分流策略对应的所有待拉语音流按照分流比例，分别请求目标机审方进行机审之后，还包括：

获取各语音片段和对应的机审结果；

根据机审结果判断语音片段是否需要进行人工审核；

若是，则根据语音片段对应的机审结果、用户身份和/或房间属性，选择对应的人工审核队列作为目标队列；其中，不同人工审核队列仅允许具有对应资格的审核员进行人工审核；

将语音片段推送至对应的目标队列进行人工审核，并以人工审核结果作为语音片段的审核结果；

若否，则直接以机审结果作为审核结果。

在其中一个实施例中，还包括在将用户的语音流推送至待拉流队列之后，还包括：

在得到语音流的审核结果后；

将审核结果、语音流对应的用户身份和/或房间属性，与各预设处置条件进行匹配；

根据命中的预设处置条件对应的处置措施对用户进行处置。

第二方面，本申请提供了一种语音流审核装置，包括：

用户标签确定模块，用于响应用户的上麦事件，获取用户的用户标签；用户标签用于反映用户在应用程序上的历史行为；

第一判断模块，用于判断用户标签是否命中预设的拉流条件；

第一处理模块，用于在用户标签命中预设的拉流条件的情况下，将用户的语音流推送至待拉流队列，以进行审核；

第二处理模块，用于在用户标签未命中预设的拉流条件的情况下，对本次上麦事件不进行拉流。

第三方面，本申请提供了一种计算机设备，包括一个或多个处理器，以及存储器，存储器中存储有计算机可读指令，计算机可读指令被一个或多个处理器执行时，执行上述任一实施例中的语音流审核方法的步骤。

第四方面，本申请提供了一种存储介质，存储介质中存储有计算机可读指令，计算机可读指令被一个或多个处理器执行时，使得一个或多个处理器执行上述任一实施例中的语音流审核方法的步骤。

从以上技术方案可以看出，本申请实施例具有以下优点：

基于本实施例中的语音流审核方法，当用户上麦时，系统首先获取该用户的用户标签，这可以反映用户的历史行为特点。然后系统判断该用户标签是否命中了预设的拉流条件，这些条件是通过分析大量用户数据总结出需要监控的用户特征设定的。如果命中拉流条件，则将该用户的语音流推送到待拉流队列，进行审核。如果没有命中，则不对该用户的语音流进行拉流处理。该方法通过用户标签和设定拉流条件，使拉流决策更加智能化和规则化，不再是全量拉流，而是实现语音流的精准拉取，只对真正存在风险的用户进行拉流，而不是全部用户，大大减少了拉流的数据量，降低了审核成本，也避免了数据量过大对审核效率的影响。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其它的附图。

图1为本申请一个实施例提供的语音流审核方法的流程示意图；

图2为本申请一个实施例提供的语音流审核装置的模块示意图；

图3为本申请一个实施例提供的计算机设备的内部结构图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请提供了一种语音流审核方法，请参阅图1，包括步骤S102至步骤S108。

S102，响应于用户的上麦事件，获取用户的用户标签。

可以理解，语音房间里任意一个用户上麦时，都将会触发上麦事件。对于每个触发上麦事件的用户而言，系统会获取该用户的用户标签。用户标签是平台根据用户在使用应用程序所产生的历史记录数据所生成的，用来反应用户在应用程序上的历史行为。例如上麦次数、进房频率、违规频次、被举报次数等。获取用户标签的是为了后续的处理提供依据。

S104，判断用户标签是否命中预设的拉流条件。

可以理解，传统技术是将所有语音流都进行拉取，从而导致需要处理的数据量巨大。而本实施例中预先设置了拉流条件，只有用户标签命中了拉流条件的用户的语音流才会被拉取。具体而言，由于用户标签可以反映用户的历史行为。若综合一个用户在平台上的各种历史行为来看，其长期在平台上表现良好，没有或很少出现异常行为，则其语音流中出现违规内容的风险就很小，该类用户就无需浪费审核资源进行审核。而对于在平台上频繁出现异常行为的用户而言，其语音流中出现违规内容的风险就很大，该类用户就需要进行审核。因此，通过对大量用户的用户标签的分析，可以总结出需要进行监控的用户的用户标签所具有的特点，从而设置相应的一个或多个拉流条件。当用户上麦时，一旦发现其用户标签命中任意一个拉流条件，即转入步骤S106，将该用户的语音流推送至待拉流队列，以进行审核。否则，则转入步骤S108，对该用户的语音流不进行拉流。

S106，若是，则将用户的语音流推送至待拉流队列，以进行审核。

可以理解，待拉流队列用于记录所有命中拉流条件的用户，这些用户的语音流将被分配到提供机审服务的服务商处进行审核。系统将会设置定时任务对待拉流队列中的用户的语音流进行统一拉取。

S108，若否，则对本次上麦事件不进行拉流。

基于本实施例中的语音流审核方法，当用户上麦时，系统首先获取该用户的用户标签，这可以反映用户的历史行为特点。然后系统判断该用户标签是否命中了预设的拉流条件，这些条件是通过分析大量用户数据总结出需要监控的用户特征设定的。如果命中拉流条件，则将该用户的语音流推送到待拉流队列，进行审核。如果没有命中，则不对该用户的语音流进行拉流处理。该方法通过用户标签和设定拉流条件，使拉流决策更加智能化和规则化，不再是全量拉流，而是实现语音流的精准拉取，只对真正存在风险的用户进行拉流，而不是全部用户，大大减少了拉流的数据量，降低了审核成本，也避免了数据量过大对审核效率的影响。

在其中一个实施例中，获取用户的用户标签，包括：

(1)获取用户的元事件表。

可以理解，元事件表中包括与用户在应用程序上的历史行为有关的记录。具体来说，为了避免对原始记录的破坏，元事件表是系统对用户的审核记录、行为记录等记录表进行复制和汇总所生成的数据表。在进行汇总时，会将不同记录表中用于描述同样事物的字段进行统一，方便后续进行数据清洗。

(2)从元事件表中提取出多个预设字段对应的数据，得到目标记录表。

可以理解，元事件表中还会包含许多和行为无关的信息，因此需要进行数据清洗。数据清洗的具体方式即是提前预设多个预设字段，仅将元事件表中与预设字段对应的数据提取出来，作为目标记录表。每个目标记录表还能根据用户维度和时间维度创建索引，以方便数据进行分类和管理，同时也可以提高数据的可读性和可操作性。例如，预设字段包括违规次数和违规时间，当需要调取A用户在10分钟内违规5次的相关记录时，通过上述索引即可快速实现数据的查找。

(3)将目标记录表与各标签匹配条件进行比较，并将被命中的标签匹配条件对应的标签作为用户标签。

可以理解，标签匹配条件与用户标签一一对应，是为每个用户标签预先设定的特征条件。当目标记录表中存在命中标签匹配条件的记录，用户将被打上被命中的标签匹配条件对应的标签。例如，用户标签包括活跃用户。活跃用户对应的标签匹配条件为总上麦时间≥3小时或送礼物次数≥3次。当A用户的目标记录中反映其总上麦时间为6小时，送礼物次数为1次，则可认定其满足活跃用户这一用户标签的标签匹配条件。A用户的用户标签将包括活跃用户。

上述计算用户标签在系统中可由用户画像模块实现。用户画像模块的架构可分为五层。分别为接入层、计算层、存储层、服务层和应用层。其中，接入层接收数据库中的数据并对其进行处理，包括使用Kafka、Tidb、Clickhouse、文件等大数据组件的方式实现。计算层用于对数据进行清洗和关联操作等。可以使用Flink作为实时计算框架。存储层用于在清洗完成后，将数据存储到不同的介质中，包括Redis、ES、Tidb、Clickhouse等，以支持实时用户画像的模型构建和多个应用场景的数据查询需求。服务层用于提供统一的数据查询服务，支持从底层明细数据到聚合层数据的多维计算，以方便外部用户快速获取需要的数据信息。应用层使用统一查询服务来支持各个业务线的数据需求，可直接用于计算、查询用户标签等。还可添加计算和查询用户分群的功能。用户分群即是根据用户标签对多个用户进行聚类，方便对用户做进一步分析。

在其中一个实施例中，在用户的语音流进行审核的过程中，还包括：

(1)在第一预设时间内，监控语音流的审核结果。

可以理解，第一预设时间是对语音流的审核结果进行监控的单个周期的时长。这里的语音流的审核结果指的是语音流的最终结果，其来源主要由审核的具体方式决定，如果是单独依靠机审或人审，则其可以是单独机审结果或人审结果。但如果采用机审加人审的方式，则审核结果就是机审结果和人审结果的综合。

(2)根据审核结果，判断是否满足需要延长监控。

可以理解，为了进一步降低拉流数据量，以降低审核成本和提高审核效率。本实施例中采用空窗轮询监听的方式对语音流进行审核。具体而言，当任意一个语音流开始被审核以后，先对其审核结果监控第一预设时间，以根据其在第一预设时间内的表现，判断是否有必要继续延长监控。如果有必要，则继续保持监听第一预设时间。如果没有必要继续保持监控，则可以对该语音流停止审核和监听第二预设时间，即进入空窗期，并在空窗期结束后，重新将该语音流推送至待拉流队列，重新恢复审核和监控。

在有些实施例中，审核结果包括属性和严重等级。属性即用于反映该审核结果的类型，至少可以包括违规和正常。而有些基于机审的审核结果中，还可以包括疑似。严重等级即代表在各非正常的属性下，其严重的程度。例如，违规内容的严重等级可分为轻微、中等和严重。疑似违规内容的严重等级也可以分为轻微、中等和严重。在此基础上，根据审核结果，判断是否满足需要延长监控，包括：在第一预设时间内，分别统计属性为违规或疑似在各严重等级的触发次数。当触发次数超过严重等级对应的阈值时，判定需要延长监控。否则，判定不需要延长监控。换言之，在第一预设时间内，会持续收到对语音流的审核结果，对于其中属于非正常的属性，即违规或疑似，需要按照属性和严重等级进行分类统计。对于违规和疑似，其每个严重等级都将分别计算其触发的次数，且每个严重等级都有对应的阈值。该阈值的设定一般是根据严重等级的提高而降低。例如，对于违规的各严重等级，轻微违规的阈值是5次，中等违规的阈值是3次，严重违规的阈值是0次(即只要出现一次严重违规即判定为需要延长监控)。

(3)若是，则返回在第一预设时间内，监控语音流的审核结果的步骤。

(4)若否，则将语音流断流，并在断流第二预设时间后，将语音流重新推送至待拉流队列，并返回在第一预设时间内，监控语音流的审核结果的步骤。

在其中一个实施例中，为了进一步增强监控的灵活性，上述第一预设时间和第二预设时间是可以由管理员进行配置的。具体而言，在第一预设时间内，监控语音流的审核结果之前，还包括：

(1)获取用户所处房间的房间属性和上麦事件的触发时间。

可以理解，这里的房间指的是用户上麦时所加入的语音房间，房间属性是系统对各语音房间附加的描述信息。可以包括房间类型、房间标签、房间性质、房间规模中的至少一项。以房间标签为例，房间标签可以是代表房间的主题特色或目标用户群。如游戏房间、K歌房间、交友房间等。不同房间属性的房间中出现违规内容的风险大小不同。因此，能够房间属性作为区分第一预设时间和/或第二预设时间的依据。

(2)根据触发时间与各预设时间区间进行匹配，并将命中的预设时间区间作为目标时间区间。

可以理解，在不同时段出现违规内容的风险大小也不同，管理员可以根据实际情况设置多个预设时间区间，每个预设时间区间可采用不同的监控力度进行监控。因此，可以根据上麦事件的触发事件，确定触发监控时所处的预设时间区间，并将其作为目标时间区间。

(3)选用房间属性和目标时间区间对应的第一预设时间和第二预设时间。

可以理解，配置特定的房间属性和特定的预设时间区间，并将其组合，可得到一个特征组合。每个特征组合对应一组第一预设时间和第二预设时间。每组第一预设时间和第二预设时间的大小都是由管理员进行配置的。管理员可基于此实现对不同房间属性、不同时段的语音流采取不同的监控力度进行监控。在开始监控之前，即将当前语音流的房间属性和目标时间区间与各特征组合进行比对。并选用其所命中的特征组合对应的第一预设时间和第二预设时间。例如，对于房间标签为游戏房间而言，第一预设时间均为5分钟，对于18:00-2:00这一时段而言，违规风险较高，第二预设时间设置为10分钟，对于9:00-18:00这一时段而言，违规风险中等，第二预设时间设置为15分钟，而对于2:00-9:00这一时段而言，违规风险最低，第二预设时间设置为20分钟。相当于在风险高的时段，通过对第一预设时间和第二预设时间的的设置，使得需要审核的占比更高，实现更大力度的审核。

在其中一个实施例中，在将用户的语音流推送至待拉流队列后，还包括：

(1)对于待拉流队列中的任意一个语音流，根据该语音流对应的用户身份和房间属性，确定该语音流对应的分流策略。分流策略包括目标机审方和分流比例。

(2)对于任意一个分流策略，将该分流策略对应的所有语音流按照分流比例，分别请求目标机审方进行机审。

可以理解，待拉流队列是定时批量拉取的。待拉流队列中将会存在不止一个语音流等待拉取。而可以提供机审服务的服务提供商有很多，为了保证审核成本和审核效率，需要将这些语音流按照一定的分流策略分配到不同的机审方。具体而言，至少可以根据用户身份和房间属性这两个维度设置分流策略。用户身份指的是从业层面为用户在应用程序上的设置的人群标签。可以包括普通用户、VIP用户、主播用户等等。每个分流策略均包括目标机审方和分流比例。管理员可以预设多个用户身份与房间属性组成的特征组合。每个特征组合对应一组目标机审方和分流比例。对于来自不同房间属性、不同用户身份的用户发出的语音流，可根据这类用户的特性，针对性的分配合适的机审方作为其目标机审方。每组目标机审方将包括两个以上，分流比例即代表需要将对应的多个语音流在目标机审方之间进行分配的比例。例如，用户身份为A房间属性为B的语音流共有10个，其对应的目标机审方为C和D，分流比例被设置为3:7，则这10个语音流中的3个被分配到机审方C，7个被分配到机审方D。

在其中一个实施例中，在将该分流策略对应的所有语音流按照分流比例，分别请求目标机审方进行机审过程中，还包括：

(1)按照第一预设间隔，确定目标机审方的实际审核片段比例。

(2)若实际审核片段比例与初始的分流比例存在差异，则根据差异调整当前的分流比例。

可以理解，系统端是按照语音流为单位进行分配，但是机审方会将单个语音流切分成多个语音片段，并按照片段作为单位进行审核以及计费。而每个机审方的语音流与语音片段之间的比例不相同。例如，机审方C将1分钟的语音流切分为5个片段，机审方D将1分钟的语音流切分为8个片段。这就导致最后在计费时，不会符合按照初始的分流比例设置的预期。因此，在机审过程中，需要保证实际审核片段比例与初始的分流比例相符合，才能使得最终成本层面的预期与初始的分流比例相符合。所以，需要按照第一预设间隔监控实际审核片段比例，即在第一预设时间间隔中各目标机审方所审核的语音片段总数的比。如果和初始的分流比例有偏差，就需要将该部分差异通过调整当前的分流比例的方式补偿回来。举例来说，假设第一预设间隔为0.5小时，目标机审方为C和D，初始的分流比例被设置为3:7，在第一个第一预设间隔发现目标机审方C审核的片段总数与目标机审方D审核的片段总数之比为4:6，则可采取的调整措施是降低目标机审方C的占比，并提高目标机审方D的占比，如可降低目标机审方C10％的占比，而提高目标机审方D10％的占比。

在其中一个实施例中，在将该分流策略对应的所有待拉语音流按照分流比例，分别请求目标机审方进行机审过程中，还包括：

(1)根据各目标机审方的请求反馈信息，判断目标机审方是否出现异常。

(2)若是，则将出现异常的目标机审方替换为对应的容灾机审方。

可以理解，本实施例为机审功能设置了容灾机制，具体而言，请求反馈信息指的是目标机审方对系统发出的机审请求发出的反馈信息。请求反馈信息可以包括状态码，还可以包括机审结果。当目标机审方出现异常时，会从请求反馈信息中反映出来。系统基于此可以及时为目标机审方启动对应的容灾机审方，由容灾机审方代替目标机审方继续工作。

根据各目标机审方的请求反馈信息，判断目标机审方是否出现异常的具体过程可以是基于状态码和/或机审结果进行。具体而言，状态码用于反映本次请求是否成功，如果本次请求访问失败，即可判定目标机审方出现了异常。另外，可根据机审结果中被判定为违规的次数的频率是否异常进行判断。例如，常规情况下，1分钟语音流出现违规的次数在严重情况下不会超过5次，但在统计机审结果时发现最近1分钟语音流的违规的次数达到15次，远远超出正常范围，即可判定应是机审方的模型存在异常，应启动容灾机制。

在其中一个实施例中，目标审核方接收到语音流后，将语音流分割为语音片段进行机审，并将各语音片段及其对应的机审结果反馈。在将该分流策略对应的所有待拉语音流按照分流比例，分别请求目标机审方进行机审之后，还包括：

(1)获取各语音片段和对应的机审结果。

可以理解，机审方对持续的语音流进行切分并对切分得到的语音片段分别进行审核，机审方将会把审核完成的语音片段及对应的机审结果不断回调到系统。

(2)根据机审结果判断语音片段是否需要进行人工审核。

其中，有些机审结果中反馈该语音片段需要进行人工审核，进一步确定是否违规。例如，对于机审结果中属性为疑似的语音片段，可以由人工审核做进一步确定。对于不需要进行人工审核的语音片段，则将直接以机审结果作为该语音片段的审核结果。

(3)若是，则根据语音片段对应的机审结果、用户身份和/或房间属性，选择对应的人工审核队列作为目标队列。其中，不同人工审核队列仅允许具有对应资格的审核员进行人工审核。

可以理解，人工审核员所擅长的领域都有所不同，为了充分发挥人工优势，使得人工审核员可以在自身擅长的领域进行审核。对于不同特性的语音片段，都为其设置了对应的人工审核队列，每个人工审核队列仅允许具有对应资格的审核员进行人工审核。语音片段的特性可由机审结果、用户身份和/或房间属性等中的一项或多项组合决定。审核员的资格也是根据其所擅长审核的语音流的特性所决定的。将语音片段的机审结果、用户身份和/或房间属性与各人工审核队列的匹配条件一一进行匹配，即可找到适合该语音片段进行人工审核的人工审核队列。

(4)将语音片段推送至对应的目标队列进行人工审核，并以人工审核结果作为语音片段的审核结果。

可以理解，为了保证人工审核效率，在语音片段被审核员从队列中提取后，可以对该语音片段被处理的时间进行统计，如果该计时值超过召回阈值，则将该语音片段重新召回队列，重新进行分配。

(5)若否，则直接以机审结果作为审核结果。

在其中一个实施例中，还包括在将用户的语音流推送至待拉流队列之后，还包括：

(1)在得到语音流的审核结果后，将审核结果、语音流对应的用户身份和/或房间属性，与各预设处置条件进行匹配。

(2)根据命中的预设处置条件对应的处置措施对用户进行处置。

可以理解，在被审核发现违规后，对于不同的情况可以采取更加灵活的处置方式对用户进行处置，以提高用户体验。具体而言，管理员可预设多个预设处置条件，每个预设处置条件对应一种处置措施。预设处置条件中将包括审核结果、语音流对应的用户身份和/或房间属性等中的至少一项，具体可由管理员进行灵活配置。当确定某个用户存在需要处置的情况时，可根据该用户的审核结果、用户身份和/或所处房间的房间属性与预设处置条件进行一一匹配，并选用命中的预设处置条件对应的处置措施对该用户进行处置。

本申请提供了一种语音流审核装置，请参阅图2，包括用户标签确定模块210、第一判断模块220、第一处理模块230和第二处理模块240。

用户标签确定模块210用于响应用户的上麦事件，获取用户的用户标签。用户标签用于反映用户在应用程序上的历史行为。

第一判断模块220用于判断用户标签是否命中预设的拉流条件。

第一处理模块230用于在用户标签命中预设的拉流条件的情况下，将用户的语音流推送至待拉流队列，以进行审核。

第二处理模块240用于在用户标签未命中预设的拉流条件的情况下，对本次上麦事件不进行拉流。

关于语音流审核装置的具体限定可以参见上文中对语音流审核方法的限定，在此不再赘述。上述语音流审核装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。需要说明的是，本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

本申请提供了一种计算机设备，包括一个或多个处理器，以及存储器，存储器中存储有计算机可读指令，计算机可读指令被一个或多个处理器执行时，执行上述任一实施例中的语音流审核方法的步骤。

示意性地，如图3所示，图3为本申请实施例提供的一种计算机设备的内部结构示意图。参照图3，计算机设备300包括处理组件302，其进一步包括一个或多个处理器，以及由存储器301所代表的存储器资源，用于存储可由处理组件302的执行的指令，例如应用程序。该计算机设备可作为门禁设备中的处理核心，也可以作为系统平台的运行载体。存储器301中存储的应用程序可以包括一个或一个以上的，每一个对应于一组指令的模块。此外，处理组件302被配置为执行指令，以执行上述任意实施例的语音流审核方法的步骤。

计算机设备300还可以包括一个电源组件303被配置为执行计算机设备300的电源管理，一个有线或无线网络接口304被配置为将计算机设备300连接到网络，和一个输入输出(I/O)接口305。

本申请提供了一种存储介质，存储介质中存储有计算机可读指令，计算机可读指令被一个或多个处理器执行时，使得一个或多个处理器执行上述任一实施例中的语音流审核方法的步骤。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间可以根据需要进行组合，且相同相似部分互相参见即可。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (13)

1.一种语音流审核方法，其特征在于，包括：

响应于用户的上麦事件，获取所述用户的用户标签；所述用户标签用于反映所述用户在应用程序上的历史行为；

判断所述用户标签是否命中预设的拉流条件；

若是，则将所述用户的语音流推送至待拉流队列，以进行审核；

若否，则对本次所述上麦事件不进行拉流。

2.根据权利要求1所述的语音流审核方法，其特征在于，所述获取所述用户的用户标签，包括：

获取所述用户的元事件表；所述元事件表中包括与所述用户在所述应用程序上的历史行为有关的记录；

从所述元事件表中提取出多个预设字段对应的目标记录表；

将所述目标记录表与各标签匹配条件进行比较，并将被命中的所述标签匹配条件对应的标签作为所述用户标签。

3.根据权利要求1所述的语音流审核方法，其特征在于，在所述用户的语音流进行审核的过程中，还包括：

在第一预设时间内，监控所述语音流的审核结果；

根据所述审核结果，判断是否满足需要延长监控；

若是，则返回所述在第一预设时间内，监控所述语音流的审核结果的步骤；

若否，则将所述语音流断流，并在断流第二预设时间后，将所述语音流重新推送至待拉流队列，并返回所述在第一预设时间内，监控所述语音流的审核结果的步骤。

4.根据权利要求3所述的语音流审核方法，其特征在于，所述审核结果包括属性和严重等级，所述根据所述审核结果，判断是否满足需要延长监控，包括：

在所述第一预设时间内，分别统计所述属性为违规或疑似在各所述严重等级的触发次数；

当所述触发次数超过所述严重等级对应的阈值时，判定需要延长监控；否则，判定不需要延长监控。

5.根据权利要求3所述的语音流审核方法，其特征在于，在所述在第一预设时间内，监控所述语音流的审核结果之前，还包括：

获取所述用户所处房间的房间属性和所述上麦事件的触发时间；

根据所述触发时间与各预设时间区间进行匹配，并将命中的所述预设时间区间作为目标时间区间；

选用所述房间属性和所述目标时间区间对应的所述第一预设时间和所述第二预设时间。

6.根据权利要求1所述的语音流审核方法，其特征在于，在所述将所述用户的语音流推送至待拉流队列后，还包括：

对于所述待拉流队列中的任意一个所述语音流，根据该所述语音流对应的用户身份和房间属性，确定该所述语音流对应的分流策略；所述分流策略包括目标机审方和分流比例；

对于任意一个所述分流策略，将该所述分流策略对应的所有所述语音流按照所述分流比例，分别请求所述目标机审方进行机审。

7.根据权利要求6所述的语音流审核方法，其特征在于，在所述将该所述分流策略对应的所有所述语音流按照所述分流比例，分别请求所述目标机审方进行机审过程中，还包括：

按照第一预设间隔，确定所述目标机审方的实际审核片段比例；

若所述实际审核片段比例与初始的所述分流比例存在差异，则根据所述差异调整当前的所述分流比例。

8.根据权利要求6所述的语音流审核方法，其特征在于，在所述将该所述分流策略对应的所有所述待拉语音流按照所述分流比例，分别请求所述目标机审方进行机审过程中，还包括：

根据各所述目标机审方的请求反馈信息，判断所述目标机审方是否出现异常；

若是，则将出现异常的所述目标机审方替换为对应的容灾机审方。

9.根据权利要求6所述的语音流审核方法，其特征在于，所述目标审核方接收到所述语音流后，将所述语音流分割为语音片段进行机审，并将各所述语音片段及其对应的机审结果反馈；在所述将该所述分流策略对应的所有所述待拉语音流按照所述分流比例，分别请求所述目标机审方进行机审之后，还包括：

获取各所述语音片段和对应的所述机审结果；

根据所述机审结果判断所述语音片段是否需要进行人工审核；

若是，则根据所述语音片段对应的所述机审结果、所述用户身份和/或所述房间属性，选择对应的人工审核队列作为目标队列；其中，不同所述人工审核队列仅允许具有对应资格的审核员进行人工审核；

将所述语音片段推送至对应的所述目标队列进行人工审核，并以人工审核结果作为所述语音片段的审核结果；

若否，则直接以所述机审结果作为所述审核结果。

10.根据权利要求1所述的语音流审核方法，其特征在于，还包括在所述将所述用户的语音流推送至待拉流队列之后，还包括：

在得到所述语音流的审核结果后；

将所述审核结果、所述语音流对应的用户身份和/或房间属性，与各预设处置条件进行匹配；

根据命中的所述预设处置条件对应的处置措施对所述用户进行处置。

11.一种语音流审核装置，其特征在于，包括：

用户标签确定模块，用于响应用户的上麦事件，获取所述用户的用户标签；所述用户标签用于反映所述用户在应用程序上的历史行为；

第一判断模块，用于判断所述用户标签是否命中预设的拉流条件；

第一处理模块，用于在所述用户标签命中预设的拉流条件的情况下，将所述用户的语音流推送至待拉流队列，以进行审核；

第二处理模块，用于在所述用户标签未命中预设的拉流条件的情况下，对本次所述上麦事件不进行拉流。

12.一种计算机设备，其特征在于，包括一个或多个处理器，以及存储器，所述存储器中存储有计算机可读指令，所述计算机可读指令被所述一个或多个处理器执行时，执行如权利要求1-10任一项所述的语音流审核方法的步骤。

13.一种存储介质，其特征在于，所述存储介质中存储有计算机可读指令，所述计算机可读指令被一个或多个处理器执行时，使得一个或多个处理器执行如权利要求1至10任一项所述的语音流审核方法的步骤。