CN113255929B - 异常用户可解释原因的获取方法和装置 - Google Patents

Abstract

本说明书实施例提供了一种异常用户可解释原因的获取方法和装置。在该方法中，获取用户在至少两个维度上的用户特征数据；将所述用户特征数据分别输入预先训练的至少两个识别模型中；其中，至少两个识别模型对应至少两个维度；确定用户是否属于异常用户；如果是，则根据每一个识别模型对该用户的识别结果，得到该异常用户的可解释原因。

Description

异常用户可解释原因的获取方法和装置

技术领域

本说明书一个或多个实施例涉及电子信息技术，尤其涉及异常用户可解释原因的获取方法和装置。

背景技术

随着网络技术的迅速发展，用户通过网络进行的业务越来越多。很多非法用户会通过网络进行异常行为，比如攻击某一网站或者通过某一支付平台进行洗钱。

对于用户的行为，目前的做法是利用识别模型对用户的行为进行识别，如果识别出用户为异常用户，则告警并上报。可见，现有技术中只是对异常用户进行识别，无法获取到用户异常的原因。

发明内容

本说明书一个或多个实施例描述了异常用户可解释原因的获取方法和装置，能够得到用户异常的可解释性原因。

根据第一方面，提供了一种异常用户可解释原因的获取方法，其中，包括：

获取用户在至少两个维度上的用户特征数据；

将所述用户特征数据分别输入预先训练的至少两个识别模型中；其中，至少两个识别模型对应至少两个维度；

确定用户是否属于异常用户；

如果是，则根据每一个识别模型对该用户的识别结果，得到该异常用户的可解释原因。

该方法进一步包括：将每一个识别模型输出的分值乘以预先为该模型设置的权重系数，得到对应该识别模型的权重得分；将所述至少两个识别模型对应的至少两个权重得分相加，得到所述用户的异常分值；

所述确定用户是否属于异常用户包括：判断该用户的异常分值是否大于预设异常分阈值或者判断所述用户是否已具有异常用户的标签，如果是，则确定该用户属于异常用户。

其中，所述根据每一个识别模型对所述异常用户的识别结果得到异常用户的可解释原因包括：

对所述至少两个权重得分按照得分从高到低的顺序进行排序；

选择排在前预设个数的权重得分对应的识别模型；

将所选择的识别模型对应的维度的信息和/或所选择的识别模型对应的权重得分，作为所述异常用户的可解释原因。

该方法进一步包括：按照异常分值从大到小的顺序，对各个异常用户进行排序；对排在前预设数量的异常用户进行业务限制管控，如果接收到一个异常用户的投诉，则对该异常用户进行专家识别，如果识别出该用户为非异常用户，则将该用户的标签设置为非异常用户，并利用该用户的特征数据训练所述至少两个识别模型。

该方法进一步包括：对确定为非异常的用户进行专家识别，如果识别出该用户为异常用户，则将该用户的标签设置为异常用户，并利用该用户的特征数据训练所述至少两个识别模型。

根据第二方面，提供了一种异常用户可解释原因的获取装置，其中，包括：

特征数据获取模块，被配置为获取用户在至少两个维度上的用户特征数据；

识别模块，被配置为保存有预先训练的至少两个识别模型，以及将所述用户特征数据分别输入至少两个识别模型中；其中，至少两个识别模型对应至少两个维度，以及确定用户是否属于异常用户；

可解释模块，被配置为根据每一个识别模型对该用户的识别结果，得到该异常用户的可解释原因。

其中，所述识别模块被配置为执行：将每一个识别模型输出的分值乘以预先为该模型设置的权重系数，得到对应该识别模型的权重得分；将所述至少两个识别模型对应的至少两个权重得分相加，得到所述用户的异常分值；判断该用户的异常分值是否大于预设异常分阈值或者判断所述用户是否已具有异常用户的标签，如果是，则确定该用户属于异常用户。

其中，可解释模块被配置为执行：

对所述至少两个权重得分按照得分从高到低的顺序进行排序；

选择排在前预设个数的权重得分对应的识别模型；

将所选择的识别模型对应的维度的信息和/或所选择的识别模型对应的权重得分，作为所述异常用户的可解释原因。

在本说明书装置的一个实施例中，进一步包括管控处理模块，被配置执行：按照异常分值从大到小的顺序，对各个异常用户进行排序；对排在前预设数量的异常用户进行业务限制管控，如果接收到一个异常用户的投诉，则对该异常用户进行专家识别，如果识别出该用户为非异常用户，则将该用户的标签设置为非异常用户，并触发所述识别模块利用该用户的特征数据训练所述至少两个识别模型。

在本说明书装置的一个实施例中，所述管控处理模块进一步被配置为执行：对确定为非异常的用户进行专家识别，如果识别出该用户为异常用户，则将该用户的标签设置为异常用户，并触发所述识别模块利用该用户的特征数据训练所述至少两个识别模型。

根据第三方面，提供了一种计算设备，包括存储器和处理器，所述存储器中存储有可执行代码，所述处理器执行所述可执行代码时，实现本说明书任一实施例所述的方法。

本说明书实施例提供的异常用户可解释原因的获取方法和装置，利用了机器识别模型通常都会对应一个或多个维度上的识别方法，在利用机器识别模型识别出用户为异常用户之后，根据每一个识别模型对该用户的识别结果，得到该异常用户的可解释原因。后续，则能够利用得到的可解释原因进行一系列服务，比如在用户投诉时，向用户提供该可解释性原因，再如向上级审核部门提供异常用户结论对应的可解释性原因，从而提高了业务的服务质量。

附图说明

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

图1是本说明书一个实施例中异常用户可解释原因的获取方法的流程图。

图2是本说明书一个实施例中异常用户可解释原因的获取装置的一种结构示意图。

图3是本说明书一个实施例中异常用户可解释原因的获取装置的又一种结构示意图。

具体实施方式

如前所述，现有技术中只是对异常用户进行识别，无法获取到用户异常的原因。而如果无法获取用户异常的原因，则会限制业务的实现，降低业务的可信度。比如，在识别出一个用户为异常用户之后，通常都会对用户进行管控，比如限制用户在10天之内不能进行交易或者直接封锁用户账户。在很多业务场景中，对用户进行管控之后，用户会进行投诉，投诉对自己的管控是错误的，自身的行为属于正常业务行为。针对此种情况，往往就需要向用户提供其被确定为异常用户的原因，否则无法解决该投诉。再如，在识别出异常用户之后，可能需要向上级主管部门上报，而如果只上报用户为异常用户，而没有对用户为异常用户的解释原因，则会使得上级主管部门无法进一步对用户为异常用户的判断方式的可信度进行核验。

因此，需要获得异常用户的可解释性原因。而在识别用户是否为异常用户的过程中，通常使用的都是机器识别模型，机器识别模型只会给出识别结果，通常为一个分值，而不会给出原因。但是，机器识别模型通常都会对应一个或多个维度上的识别方法，比如是在用户行为这个维度上，对用户行为的特征数据进行分析，从而识别出用户是否为异常用户，该识别模型所对应的维度(即用户行为)，其实就可以解释为什么会识别出用户为异常用户，即作为可解释性原因。再如，一个机器识别模型是在用户的资金流向这个维度上，对用户的资金流向的相关数据进行分析，从而识别出用户是否为异常用户，该识别模型所对应的维度(即用户的资金流向)，其实就可以解释为什么会识别出用户为异常用户，即作为可解释性原因。

下面描述以上构思的具体实现方式。

图1示出了本说明书一个实施例中异常用户可解释原因的获取方法的流程图。该方法的执行主体为异常用户可解释原因的获取装置。可以理解，该方法也可以通过任何具有计算、处理能力的装置、设备、平台、设备集群来执行。参见图1，该方法包括：

步骤101：获取在至少两个维度上的用户特征数据。

步骤103：将所述用户的特征数据分别输入预先训练的至少两个识别模型中；其中，至少两个识别模型对应至少两个维度。

步骤105：确定用户是否属于异常用户，如果是，执行步骤107，否则结束当前流程。

步骤107：根据每一个识别模型对该用户的识别结果，得到该异常用户的可解释原因。

根据上述图1所示的流程可以看出，本说明书实施例利用了机器识别模型通常都会对应一个或多个维度上的识别方法，在利用机器识别模型识别出用户为异常用户之后，根据每一个识别模型对该用户的识别结果，得到该异常用户的可解释原因。后续，则能够利用得到的可解释原因进行一系列服务，比如在用户投诉时，向用户提供该可解释性原因，再如向上级审核部门提供异常用户结论对应的可解释性原因，从而提高了业务的服务质量。

下面则针对图1中的每一个步骤分别进行说明。

为了搭建更为通用的可解释性平台，在执行步骤101之前，可以预先训练出至少两个识别模型，每一个识别模型对应一个维度。通常，可以设置对应更多维度的更多的识别模型，从而在后续处理中可以从更多维度上提供异常用户的可解释性原因。比如，识别模型1用于从用户所使用的设备的维度来识别出一个用户是否为异常用户，如果异常，则可以确定用户异常的一个可解释性原因为用户使用的设备异常。再如，识别模型2用于从用户所使用的账户信息的维度来识别出一个用户是否为异常用户，如果异常，则可以确定用户异常的一个可解释性原因为用户使用了异常账户等。

在训练出至少两个对应不同维度的识别模型之后，则可以执行步骤101中，获取用户在至少两个维度上的特征数据，也就是说，获取每一个识别模型需要类型的用户特征数据。

在本说明书一个实施例中，至少两个维度包括如下中的至少任意两种：

用户所使用的设备；

用户所使用的账户信息；

用户所使用的局域网；

用户所使用的手机号；

用户所在的团伙；

用户的行为；

用户的资金流向。

比如，对于上述列举的7个维度，步骤101中获取用户所使用的设备的数据，比如设备的标识或者设备的IP地址等，同时获取用户所使用的账户信息，比如账号、银行名称及该账户的交易记录等；以此类推，同时，获取用户的资金流向的数据，比如该用户名称下的所有账号汇出或者接收汇款的对方账户信息等。

接下来在步骤103中将在至少两个维度上的用户特征数据分别输入预先训练的至少两个识别模型中。

比如，识别模型1对应用户所使用的设备的维度，则将在该维度上获取的用户特征数据即当前用户所使用的设备的信息输入识别模型1，识别模型2对应用户所使用的账户信息的维度，则将在该维度上获取的用户特征数据即当前用户所使用的账户的信息输入识别模型2中，以此类推。

接下来，在步骤105中确定用户是否属于异常用户。

这里，可以是根据本说明书实施例中预先训练的识别模型的识别结果来确定用户是否属于异常用户，也可以是利用其它方式比如预先设置的异常用户名单或者其他业务系统发来的用户标签，来确定用户是否属于异常用户。

在步骤105中，如果是根据预先训练的识别模型的识别结果来确定用户是否属于异常用户，那么，需要预先执行：将每一个识别模型输出的分值乘以预先为该模型设置的权重系数，得到对应该识别模型的权重得分；将所述至少两个识别模型对应的至少两个权重得分相加，得到所述用户的异常分值；这样，在步骤105中确定用户是否属于异常用户的过程包括：判断该用户的异常分值是否大于预设异常分阈值，如果是，则确定该用户属于异常用户。

比如，预先训练出7个识别模型，可以根据实际业务的特点，来为每一个识别模型设置对应的权重系数，所有权重系数相加为1。比如对于反洗钱业务，可以设置对应用户所使用设备这个维度的识别模型1的权重相对较小，比如为0.05，设置所使用的账户信息这个维度的识别模型2的权重相对较大，比如为0.3，设置用户所使用的局域网这个维度的识别模型3的权重也相对较小，比如为0.1，以此类推，直至设置用户的资金流向这个维度的识别模型7的权重相对较大，比如为0.6。之后，将每一个识别模型输出的分值乘以预先为该模型设置的权重系数，得到对应该识别模型的权重得分，比如对于识别模型1，在将对应维度的用户特征数据输入识别模型1之后，识别模型1会输出一个分值比如为30分，则使用30*0.05得到了识别模型1的权重得分为1.5；对于识别模型7，在将对应该维度的用户特征数据输入识别模型7之后，识别模型7会输出一个分值比如为80分，则使用80*0.6后得到了识别模型7的权重得分为48分。之后，将7个权重得分相加，得到了用户的异常分值，比如为75分。可以预先设置一个异常分阈值，比如为70分，如果用户的异常分值比如75大于该异常分阈值比如为70，那么，则可以确定用户属于异常用户，否则，可以确定用户不属于异常用户。

接下来在步骤107中，根据每一个识别模型对该用户的识别结果，得到该异常用户的可解释原因。

本步骤的实现过程包括：对在步骤105中得到的至少两个权重得分按照得分从高到低的顺序进行排序；选择排在前预设个数的权重得分对应的识别模型；将所选择的识别模型对应的维度的信息和/或所选择的识别模型对应的权重得分，作为所述异常用户的可解释原因。

比如，在步骤105中，对于识别模型1至识别模型7，分别得到了对应的7个权重得分，那么在本步骤107中，可以将该7个权重得分按照得分从高到低的顺序进行排序，排在第一的权重得分，说明对于判断用户属于异常用户的作用最重要，排在第二的权重得分，说明对于判断用户属于异常用户的作用次之，以此类推，那么本质上，排名顺序就说明了在得出用户为异常用户时的原因的重要性，因此，选择排在比如前3个的权重得分对应的识别模型，比如识别模型7、识别模型5和识别模型3，这三个识别模型对应的维度的信息分别为：用户的资金流向、用户所在的团伙、用户所使用的局域网，可见，该三个维度信息就可以为用户属于异常用户的可解释原因。当然，也可以将这三个识别模型的信息及其权重得分作为用户属于异常用户的可解释原因。

至此，对于一个用户，如果识别出为异常用户，则获取其成为异常用户的可解释原因。后续，则能够利用得到的可解释原因进行一系列服务，比如在用户投诉时，向用户提供该可解释性原因，再如向上级审核部门提供异常用户结论对应的可解释性原因，从而提高了业务的服务质量。

可以针对网络中进行业务的各个用户都执行上述结合图1所示的获取可解释原因的处理，则每一个用户都会记录有对应该用户的可解释性原因。可以根据用户的不同，进行后续不同的处理。

在本说明书实施例中，可以通过不断的迭代过程来优化训练出的各个识别模型，以及优化得到的用户的可解析原因。

一种迭代优化方式为：对于已经确定为异常用户的部分，可以根据系统的处理能力，进行分层控制，比如对于精准头部用户(即已经确定为异常用户，且异常分值排序高的一部分用户)进行业务限制管控，再根据管控结果迭代优化识别模型及优化可解释原因。具体实现过程包括：按照异常分值从大到小的顺序，对确定出的各个异常用户进行排序；对排在前预设数量的异常用户(比如前30％的异常用户)进行业务限制管控(比如在10天内禁止该异常用户进行转账处理)，这样，如果接收到被管控的一个异常用户的投诉，则对该异常用户进行专家识别，如果识别出该用户为非异常用户，则说明之前的识别模型及可解释原因都不够准确，有待优化，那么可以将该用户的标签设置为非异常用户，并利用该用户的特征数据重新训练上述至少两个识别模型，从而通过迭代优化识别模型的识别精度及优化可解释原因的逻辑。

另一种迭代优化方式为：对于确定为非异常的用户进行专家识别，如果识别出该用户为异常用户，则说明之前的识别模型及可解释原因都不够准确，有待优化，则将该用户的标签设置为异常用户，并利用该用户的特征数据重新训练上述至少两个识别模型，从而通过迭代优化识别模型的识别精度及优化可解释原因的逻辑。

在本说明书一个实施例中，在上述步骤105中，在确定出用户不是异常用户之后，也可以根据每一个识别模型对该用户的识别结果，得到该非异常用户的可解释原因。得到该非异常用户的可解释原因的方法与上述实施例中得到异常用户的可解释原因的方法相同。也就是说，即使用户不是异常用户，也可以针对该用户记录可解释原因，便于后续统计及分析。

在本说明书一个实施例中，还提供了一种异常用户可解释原因的获取装置，参见图2，该装置包括：

特征数据获取模块201，被配置为获取用户在至少两个维度上的用户特征数据；

识别模块202，被配置为保存有预先训练的至少两个识别模型，以及将所述用户特征数据分别输入至少两个识别模型中；其中，至少两个识别模型对应至少两个维度，以及确定用户是否属于异常用户；

可解释模块203，被配置为根据每一个识别模型对该用户的识别结果，得到该异常用户的可解释原因。

在本说明书装置的一个实施例中，所述至少两个维度包括如下中的至少任意两种：

用户所使用的设备；

用户所使用的账户信息；

用户所使用的局域网；

用户所使用的手机号；

用户所在的团伙；

用户的行为；

用户的资金流向。

其中，所述识别模块202被配置为执行：将每一个识别模型输出的分值乘以预先为该模型设置的权重系数，得到对应该识别模型的权重得分；将所述至少两个识别模型对应的至少两个权重得分相加，得到所述用户的异常分值；判断该用户的异常分值是否大于预设异常分阈值或者判断所述用户是否已具有异常用户的标签，如果是，则确定该用户属于异常用户。

其中，可解释模块203被配置为执行：

对所述至少两个权重得分按照得分从高到低的顺序进行排序；

选择排在前预设个数的权重得分对应的识别模型；

将所选择的识别模型对应的维度的信息和/或所选择的识别模型对应的权重得分，作为所述异常用户的可解释原因。

在本说明书装置的一个实施例中，进一步包括管控处理模块301，被配置执行：按照异常分值从大到小的顺序，对各个异常用户进行排序；对排在前预设数量的异常用户进行业务限制管控，如果接收到一个异常用户的投诉，则对该异常用户进行专家识别，如果识别出该用户为非异常用户，则将该用户的标签设置为非异常用户，并触发所述识别模块202利用该用户的特征数据训练所述至少两个识别模型。

在本说明书装置的一个实施例中，所述管控处理模块301进一步被配置为执行：对确定为非异常的用户进行专家识别，如果识别出该用户为异常用户，则将该用户的标签设置为异常用户，并触发所述识别模块202利用该用户的特征数据训练所述至少两个识别模型。

本说明书一个实施例提供了一种计算机可读存储介质，其上存储有计算机程序，当所述计算机程序在计算机中执行时，令计算机执行说明书中任一个实施例中的方法。

本说明书一个实施例提供了一种计算设备，包括存储器和处理器，所述存储器中存储有可执行代码，所述处理器执行所述可执行代码时，实现执行说明书中任一个实施例中的方法。

可以理解的是，本说明书实施例示意的结构并不构成对上述装置的具体限定。在说明书的另一些实施例中，上述装置可以包括比图示更多或者更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件、软件或者软件和硬件的组合来实现。

上述装置、系统内的各模块之间的信息交互、执行过程等内容，由于与本说明书方法实施例基于同一构思，具体内容可参见本说明书方法实施例中的叙述，此处不再赘述。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本领域技术人员应该可以意识到，在上述一个或多个示例中，本发明所描述的功能可以用硬件、软件、挂件或它们的任意组合来实现。当使用软件实现时，可以将这些功能存储在计算机可读介质中或者作为计算机可读介质上的一个或多个指令或代码进行传输。

以上所述的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的技术方案的基础之上，所做的任何修改、等同替换、改进等，均应包括在本发明的保护范围之内。

Claims (6)

1.异常用户可解释原因的获取方法，其中，包括：

获取用户在至少两个维度上的用户特征数据；

将所述用户特征数据分别输入预先训练的至少两个识别模型中；其中，至少两个识别模型对应至少两个维度；

确定用户是否属于异常用户；

如果是，则根据每一个识别模型对该用户的识别结果，得到该异常用户的可解释原因；

其中，该方法进一步包括：将每一个识别模型输出的分值乘以预先为该模型设置的权重系数，得到对应该识别模型的权重得分；将所述至少两个识别模型对应的至少两个权重得分相加，得到所述用户的异常分值；

所述确定用户是否属于异常用户包括：判断该用户的异常分值是否大于预设异常分阈值或者判断所述用户是否已具有异常用户的标签，如果是，则确定该用户属于异常用户；

按照异常分值从大到小的顺序，对各个异常用户进行排序；对排在前预设数量的异常用户进行业务限制管控，如果接收到一个异常用户的投诉，则对该异常用户进行专家识别，如果识别出该用户为非异常用户，则将该用户的标签设置为非异常用户，并利用该用户的特征数据训练所述至少两个识别模型。

2.根据权利要求1所述的方法，其中，所述根据每一个识别模型对所述异常用户的识别结果得到异常用户的可解释原因包括：

对所述至少两个权重得分按照得分从高到低的顺序进行排序；

选择排在前预设个数的权重得分对应的识别模型；

将所选择的识别模型对应的维度的信息和/或所选择的识别模型对应的权重得分，作为所述异常用户的可解释原因。

3.根据权利要求1所述的方法，其中，该方法进一步包括：对确定为非异常的用户进行专家识别，如果识别出该用户为异常用户，则将该用户的标签设置为异常用户，并利用该用户的特征数据训练所述至少两个识别模型。

4.异常用户可解释原因的获取装置，其中，包括：

特征数据获取模块，被配置为获取用户在至少两个维度上的用户特征数据；

识别模块，被配置为保存有预先训练的至少两个识别模型，以及将所述用户特征数据分别输入至少两个识别模型中；其中，至少两个识别模型对应至少两个维度，以及确定用户是否属于异常用户；

可解释模块，被配置为根据每一个识别模型对该用户的识别结果，得到该异常用户的可解释原因；

其中，所述识别模块被配置为执行：将每一个识别模型输出的分值乘以预先为该模型设置的权重系数，得到对应该识别模型的权重得分；将所述至少两个识别模型对应的至少两个权重得分相加，得到所述用户的异常分值；判断该用户的异常分值是否大于预设异常分阈值或者判断所述用户是否已具有异常用户的标签，如果是，则确定该用户属于异常用户；

进一步包括管控处理模块，

所述管控处理模块被配置为按照异常分值从大到小的顺序，对各个异常用户进行排序；对排在前预设数量的异常用户进行业务限制管控，如果接收到一个异常用户的投诉，则对该异常用户进行专家识别，如果识别出该用户为非异常用户，则将该用户的标签设置为非异常用户，并触发所述识别模块利用该用户的特征数据训练所述至少两个识别模型。

5.根据权利要求4所述的装置，其中，可解释模块被配置为执行：

对所述至少两个权重得分按照得分从高到低的顺序进行排序；

选择排在前预设个数的权重得分对应的识别模型；

将所选择的识别模型对应的维度的信息和/或所选择的识别模型对应的权重得分，作为所述异常用户的可解释原因。

6.一种计算设备，包括存储器和处理器，所述存储器中存储有可执行代码，所述处理器执行所述可执行代码时，实现权利要求1-3中任一项所述的方法。

Images