CN117557390A - 用户识别方法及计算设备 - Google Patents

Abstract

本申请实施例提供了一种用户识别方法及计算设备。其中，获取目标保险的被保障用户所对应的至少一种特征数据；基于所述至少一种特征数据，利用风险识别模型确定所述被保障用户的风险程度；从多种风险识别规则中，确定所述风险程度对应的至少一种风险识别规则；利用所述至少一种风险识别规则，对所述被保障用户进行风险判断；基于判断结果，确定所述被保障用户是否为目标识别用户。本申请实施例提供的技术方案提高了识别精准度。

Description

用户识别方法及计算设备

技术领域

本申请实施例涉及计算机技术领域，尤其涉及一种用户识别方法及计算设备。

背景技术

在一些提供对象以供用户进行交易以换取对象的线上平台，如提供商品购买的电子商务平台，为了保证对象质量，并提供安全交易环境，线上平台通常要求对象提供方缴纳相应保证金，以在对象提供方存在发货、物流、对象质量、以及与用户纠纷等问题的情况下，利用保证金可以向用户进行一定的赔付等。此外，对象提供方也可以购买相应保险以可以提供给用户与保证金同等的保障，并可以在用户进行理赔时由平台方进行先行垫付等。

然而，由于保险有一定的经济杠杆效应，使得出现了大量骗保行为，一些意欲进行欺诈的用户会选择履约能力较差的对象提供方恶意进行对象交易，并在进行理赔之后进行退款申请，从而损坏了平台方、对象提供方以及正常消费者的合法利益。因此，亟需对用户进行识别。目前，通常采用单一规则，如对用户累计理赔金额是否达到指定金额的判断方式，来确定是否为目标识别用户，以对后续理赔申请进行拦截。然而，这种识别方式不够精准。

发明内容

本申请实施例提供一种用户识别方法及计算设备，用以解决现有技术中识别精准度低的技术问题。

第一方面，本申请实施例中提供了一种用户识别方法，包括：

获取目标保险的被保障用户所对应的至少一种特征数据；

基于所述至少一种特征数据，利用风险识别模型确定所述被保障用户的风险程度；

从多种风险识别规则中，确定所述风险程度对应的至少一种风险识别规则；

利用所述至少一种风险识别规则，对所述被保障用户进行风险判断；

基于判断结果，确定所述被保障用户是否为目标识别用户。

第二方面，本申请实施例中提供了一种计算设备，包括处理组件以及存储组件；

所述存储组件存储一个或多个计算机指令；所述一个或多个计算机指令用以被所述处理组件调用执行，以实现如上述第一方面所述的用户识别方法。

第三方面，本申请实施例中提供了一种计算机存储介质，存储有计算机程序，所述计算机程序被计算机执行时，以实现如上述第一方面所述的用户识别方法。

本申请实施例中，对于目标保险的被保障用户，基于至少一种特征数据首先利用风险识别模型识别该被保障用户的风险程度，并根据风险程度从多种风险识别规则中确定所对应的至少一种风险识别规则，从而可以再利用至少一种风险识别规则对被保障用户进行风险判断，以确定被保障用户是否为目标识别用户。本申请实施例中通过风险识别模型以及风险识别规则，提高了识别精准度，且根据风险识别模型的风险程度确定风险识别规则，从而实现了差异化识别，进一步提高了精准度。

本申请的这些方面或其他方面在以下实施例的描述中会更加简明易懂。

附图说明

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

图1示出了本申请提供的一种用户识别方法一个实施例的流程图；

图2示出了本申请提供的一种模型训练方法一个实施例的流程图；

图3示出了本申请实施例在一个实际应用中的场景交互示意图；

图4示出了本申请提供的一种用户识别装置一个实施例的结构示意图；

图5示出了本申请提供的一种模型训练装置一个实施例的结构示意图；

图6示出了本申请提供的一种计算设备一个实施例的结构示意图。

具体实施方式

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。

在本申请的说明书和权利要求书及上述附图中的描述的一些流程中，包含了按照特定顺序出现的多个操作，但是应该清楚了解，这些操作可以不按照其在本文中出现的顺序来执行或并行执行，操作的序号如101、102等，仅仅是用于区分开各个不同的操作，序号本身不代表任何的执行顺序。另外，这些流程可以包括更多或更少的操作，并且这些操作可以按顺序执行或并行执行。需要说明的是，本文中的“第一”、“第二”等描述，是用于区分不同的消息、设备、模块等，不代表先后顺序，也不限定“第一”和“第二”是不同的类型。

本申请实施例的技术方案可以应用于任意的保险应用场景中，用以实现对被保障用户是否为目标识别用户的精准识别。在一个实际应用，例如可以具体应用于对象交易场景如提供商品购买的电子商务场景中所涉及的保险应用场景，在对象交易场景中，对象提供方可以购买平台方所提供的保险，以为购买其所提供对象的消费者提供相应保障，比如未按时发货、价格降低等情况下，可以由平台方向消费者进行垫付赔款等，对象提供方意即为投保用户，消费者意即为被保障用户。

结合背景技术描述可知，由于保险具有一定的经济杠杆效应，使得出现了大量骗保行为，特别是对象交易场景中，由于消费者均可以购买对象提供方所提供的对象，一些意欲进行欺诈的用户可能会攻击一些交期履约能力较差的对象提供方进行对象的恶意购买，对象提供方未履约情况下，进行高频理赔申请，并会在收到赔付金额后选择申请退款。从而对平台方、对象提供方以及正常消费者都会造成损失，而目前，对这类执行欺诈等恶意行为的目标识别用户的识别通常是对用户累计理赔金额是否达到指定金额的判断方式来实现，以对后续理赔申请进行拦截，如累积理赔金额达到指定金额，可认为该用户为目标识别用户，其之后的理赔申请将不再受理等。然而，这种识别方式不够精准，且容易出现漏损问题，对于确定为目标识别用户之前的理赔申请将无法拦截。

为了提高识别精准度，发明人想到单一规则具有局限性且存在漏损，若采用多种规则判定的方式来进行用户识别，虽然可以提高识别率，但是由于欺诈手法多样化，精准度仍然难以保证，因此，发明人经过一系列研究提出了本申请实施例的技术方案，本申请实施例通过风险识别模型以及风险识别规则，提高了识别精准度，且根据风险识别模型的风险程度确定风险识别规则，从而实现了差异化识别，进一步提高了精准度。

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

需要说明的是，本申请实施例中可能会涉及到对用户数据的使用，在实际应用中，可以在符合所在国的适用法律法规要求的情况下(例如，用户明确同意，对用户切实通知，等)，在适用法律法规允许的范围内在本文描述的方案中使用用户特定的个人数据。

需要说明的是，本申请所涉及的用户信息(包括但不限于用户设备信息、用户个人信息等)和数据(包括但不限于用于分析的数据、存储的数据、展示的数据等)，均为经用户授权或者经过各方充分授权的信息和数据，并且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准，并提供有相应的操作入口，供用户选择授权或者拒绝。

需要说明的是，本申请实施例的技术方案适用于网络虚拟环境中，所描述的用户一般是指“虚拟用户”，真实用户可以通过注册方式在服务端中注册用户账号，以获得在网络环境中的用户身份，实际应用中，一个用户可能会注册多个用户账号以进行欺诈等恶意行为等。

图1为本申请实施例提供的一种用户识别方法一个实施例的流程图，一个实际应用中，本申请实施例的技术方案可以适用于其中的一种系统架构可以包括用户端及服务端，该系统架构即可以为线上平台的系统架构；其中，本实施例的技术方案可以由服务端执行；用户端可以面向被保障用户，也即对象交易场景下的消费者。

其中，用户端与服务端之间通过网络建立连接。网络为用户端与服务端之间提供了通信链路的介质。网络可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。用户端通过络可以与服务端交互以接收或发送消息等。

其中，用户端可以为浏览器、APP(Application，应用程序)、或网页应用如H5(HyperText Markup Language5，超文本标记语言第5版)应用、或轻应用(也被称为小程序，一种轻量级应用程序)或云应用等，用户端可以部署在电子设备中，需要依赖设备运行或者设备中的某些app而运行等。电子设备例如可以具有显示屏并支持信息浏览等，如可以是个人移动终端如手机、平板电脑、个人计算机、台式计算机、智能音箱、智能手表等等，在电子设备中通常还可以配置各种其它类应用，例如人机对话类应用、模型训练类应用、文本处理类应用、网页浏览器应用、购物类应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等。电子设备可以是指用户使用的，具有用户所需计算、上网、通信等功能的设备，例如可以是手机、平板电脑、个人电脑、穿戴设备等。电子设备通常可以包括至少一个处理组件和至少一个存储组件。电子设备也可能包括网卡芯片、IO总线、音视频组件等基本配置，本申请对此不进行限定。可选地，根据电子设备实现形式，也可以包括一些外围设备，例如键盘、鼠标、输入笔、打印机等，本申请对此不进行限定。

服务端可以包括提供各种服务的服务器，例如对用户端发送的交互信息进行处理的服务端等。

需要说明的是，服务端可以实现成多个服务器组成的分布式服务器集群，也可以实现成单个服务器。服务器也可以为分布式系统的服务器，或者是结合了区块链的服务器。服务器也可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、内容分发网络(Content Delivery Network，CDN)、以及大数据和人工智能平台等基础云计算服务的云服务器，或者是带人工智能技术的智能云计算服务器或智能云主机。

其中，图1所示的用户识别方法可以包括以下几个步骤：

101：获取目标保险的被保障用户所对应的至少一种特征数据。

目标保险可以是指任意一种保险，为了方便描述上的区分，本申请实施例中命名为目标保险。

被保障用户为目标保险的受益者，被保障用户与投保用户可以为同一个用户，当然在一些险种中，被保障用户与投保用户为不同用户，比如对象交易场景中，投保用户可以是指对象提供方，被保障用户可以是指针对目标保险的投保用户所提供的对象存在交易行为的用户，意即消费者。

该至少一种特征数据的数据种类可以结合实际情况，例如结合针对目标保险的不同欺诈手法等而进行设定，该至少一种特征数据通常可以代表被保障用户的历史行为表现。

为了便于理解，下面举例说明至少一种特征数据的可能实现方式，需要说明的是，本申请并不限定于此：

在一个实现方式中，该至少一种特征数据可以包括从被保障用户对应的历史行为数据中，所获取的被保障用户的至少一种第一用户特征；

其中，在对象交易场景中，历史行为数据可以是指与交易行为相关的数据，例如，该至少一种用户特征可以包括如下一种或多种数据，当前此处仅是举例说明，本申请并不限定于此：

被保障用户在第一时间段内的理赔申请订单中的退款申请订单的占比情况；

被保障用户在第二时间段内的退款申请订单数量；

被保障用户在线上平台首次支付时间距离当前时间的支付时长；

被保障用户在第三时间段内对应的理赔申请订单中未发货订单的占比情况；

被保障用户在第四时间段内对应的理赔申请订单中使用次数最多的交易地址等。

通常情况下，理赔申请订单中退款申请订单的占比越大、退款申请订单数量越多、首次支付时间距离当前时间的支付时长越长、未发货订单占比越小、交易地址为垃圾地址等，表明被保障用户为非正常用户，是目标识别用户的可能性很大。

需要说明的是，本申请实施例中所述目标识别用户可以是指可能执行欺诈等恶意行为的特定用户。

在又一个实现方式中，该至少一种特征数据可以包括被保障用户所对应的投保用户的至少一种第二用户特征。

至少一种第二用户特征可以用以评估投保用户是否为易攻击用户。

其中，在对象交易场景中，该至少一种第二用户特征例如可以包括：投保用户对应的延期发货订单占比情况；和/或，投保用户针对理赔事件的申诉次数等。

由于投保用户购买目标保险，被保障用户进行理赔时，平台方会先行垫付赔款，之后可以向投保用户进行一定比例的追缴，投保用户若存在疑义，可以针对被保障用户对应的理赔事件进行申诉。申诉次数越少的投保用户，通常认为是沉默易攻击类型的对象提供方，容易被目标识别用户选中而执行欺诈等恶意行为；而如果投保用户延期发货订单占比较大情况下，说明投保为履约能力较差的对象提供方，其也容易被目标识别用户攻击。

在又一个实现方式中，该至少一种特征数据可以包括被保障用户的关联用户所对应的至少一种第三用户特征；

由于真实用户可能会注册多个用户账号，关联用户以是指与被保障用户的用户账号不同，但是可能对应的用户身份信息相同的用户，用户身份信息例如可以是指通信号码如手机号码或者证件号码等，可以用于进行注册以获取账号的必要信息等。

该至少一种第三用户特征与至少一种第一用户特征的特征类型可以相同，例如可以包括如下一种或多种：关联用户在第一时间段内的理赔申请订单中的退款申请订单的占比情况；

关联用户在第二时间段内的退款申请订单数量；

关联用户在线上平台首次支付时间距离当前时间的支付时长；

关联用户在第三时间段内对应的理赔申请订单中未发货订单的占比情况；以及，

关联用户在第四时间段内对应的理赔申请订单中使用次数最多的交易地址等。

当然，在又一个实际方式，该至少一种特征数据可以包括上述至少一种第一用户特征、至少一种第二用户特征，以及至少一种第三用户特征中的一个或多个。

102：基于至少一种特征数据，利用风险识别模型确定被保障用户的风险程度。

本申请实施例中，风险识别模型可以预先训练获得，其可以基于样本用户的至少一种样本特征数据而训练获得，风险识别模型例如可以采用分类模型实现，至少一种样本特征数据可以作为输入数据，样本用户为目标识别用户，也即正样本的情况下，例如可以采用数值1表示，否则可以采用数值0表示，训练标签可以对应的数值1或或0，从而训练获得风险识别模型可以用于识别被保障用户为目标识别用户的概率数值，该概率数值可以表示为风险程度，通常数值越大，风险程度越大。

当然，上述仅是举例说明了风险识别模型的一种可能实现方式，本申请并不限定于此。

103：从多种风险识别规则中，确定风险程度对应的至少一种风险识别规则。

本申请实施例中可以预置多种风险识别规则，该多种风险识别规则并可以结合实际情况而进行扩展等。

其中，多种风险识别规则可以按照不同风险程度而预先进行分组，因此根据风险识别模型所确定的风险程度，可以找到其所对应的一组风险识别规则，其包括至少一种风险识别规则。当然，也可以预先设定不同风险识别规则与不同风险程度的对应关系，通过查找该对应关系即可以确定风险程度所对应的至少一种风险识别规则。

104：利用至少一种风险识别规则，对被保障用户进行风险判断。

其中，风险识别规则中可以定义了风险识别条件，以及风险识别条件所涉及的参数类型等，从而可以根据风险识别条件，结合参数类型所对应的用户数据而对被保障用户进行风险判断；当然，一些风险识别规则可以定义了判断模型，利用模型来对被保障用户来进行风险判断等。

其中，风险识别规则可以结合实际情况而进行设定，比如可以结合目标保障的不同欺诈手法而进行设定。

为了便于理解，下面列举风险识别规则可能的实现方式，当然，可以理解的是，本申请并不限定此。

例如风险识别规则可以用于判断被保障用户与目标保险对应的投保用户是否为同一个用户，其中，风险评估条件可以是被保障用户与目标保险对应的投保用户为同一个用户。在对象交易场景中，投保用户为对象提供方，被保障用户为消费者，投保用户若与被保障用户为同一个用户，则很有可能为目标识别用户。

又如，风险识别规则可以用于判断被保障用户对投保用户所提供对象执行的交易行为是否为虚假行为；其中，风险评估条件可以是被保障用户对投保用户所提供对象执行的交易行为为虚假行为，其中，可以通过判断被保障用户对应的订单是否都对应同一个投保用户，此外，还可以判断该投保用户所对应订单是否均对应同一个被保障用户，也即通过判断被保障用户是否只购买同一个投保用户的对象，而该投保用户的对象仅提供给同一个被保障用户狗迷，则可以认为被保障用户对投保用户所提供对象执行的交易行为为虚假行为，被保障用户与投保用户可能为团伙而进行欺诈。

又如，风险识别规则可以用于判断被保障用户是否为目标识别用户的关联用户；风险评估条件可以是被保障用户为目标识别用户的关联用户，也即可以根据已确认的目标识别用户或者预定名单指定的目标识别用户，判断保障用户是否为其关联用户，可以通过被保障用户与目标识别用户是否对象相同用户身份信息来确定，若用户身份信息相同，则认为被保障用户为目标识别用户的关联用户，其很有可能对应同一个真实用户，而极大可能进行欺诈。

又如，风险识别规则可以用于判断目标保险对应的投保用户是否为指定类型用户；其中，风险评估条件可以是目标保险对应的投保用户为指定类型用户；该指定类型用户例如可以是指延期发货订单占比较多或者针对理赔事件申诉次数较少的用户，也即属于沉默易攻击用户。目标识别用户会大概率选择此类投保用户进行欺诈，因此可以用以判断被保障用户是否为目标识别用户。

又如，风险识别规则可以用于基于交易行为数据，判断被保障用户与目标识别用户是否符合相似条件；其中，风险评估条件可以是被保障用户与目标识别用户符合相似条件，其中，可以通过交易行为数据的匹配程度来确定是否相似条件，交易行为数据例如可以包括：退款申请订单数量、交易时间、支付方式、理赔申请时间、以及理赔申请订单中的退款申请订单占比中的一个或多个；若符合相似条件，则被保障用户与目标识别用户很可能为团伙，被保障用户也会进行欺诈的可能性较大。

又如，风险识别规则可以用于判断被保障用户进行理赔申请的订单中的地址信息是否为异常地址；其中，风险评估条件可以是被保障用户进行理赔申请的订单中的地址信息为异常地址；其中，可以预设异常地址集合，若该地址信息命中该异常地址集合，则认为为异常地址，当然，也可以通过判断地址信息是否符合地址命名规范等，如包含指定信息或者不符合地址编码方式等，来确定为异常地址，若为异常地址，则表明被保障用户也会进行欺诈的可能性较大。

又如，风险识别规则可以用于判断被保障用户对应的用户账号是否为异常账号；其中，风险评估条件可以是被保障用户对应的用户账号为异常账号；其中，可以通过判定用户账号的登录设备为已认证设备，或者用户账号为批量注册获得等来确定用户账号为异常账号，若为异常账号，则表明用户账号为恶意注册获得或者被冒用等，因此该用户账号所对应的被保障用户可以认为进行欺诈的可能性比较大，

又如，风险识别规则可以用于判断被保障用户是否位于第二名单，该第二名单可以保存异常用户的用户身份信息等，从而可以结合被保障用户的用户身份信息或，查询是否命中第二名单。其中，该第二名单可以包括针对目标保险已确认为目标识别用户的用户身份信息等；此外，作为又一种可选方式，该第二名单可以包括至少一个其它类保险已确认为目标识别用户的用户身份信息或者用户账号等，从而可以实现关联防范等。至少一个其它类保险可以是指与目标保险不同的保险，至少一个其它类保险也可以由平台方提供并供对象提供方进行购买，以为消费者提供相应保障。

又如，风险识别规则可以用于判定被保障用户在指定时间内的理赔累计金额是否大于预定数额。风险评估条件可以是指被保障用户在指定时间内的理赔累计金额大于预定数等。通过加入被保障用户在指定时间内的理赔累计金额是否大于预定数额的风险评估规则，可以对短频高集中度的理赔申请进行补充防范。

综上，可选地，上述利用至少一种风险识别规则，对被保障用户进行风险判断包括如下一种或多种实现方式：

判断被保障用户与目标保险对应的投保用户是否为同一个用户；

判断被保障用户对投保用户所提供对象执行的交易行为是否为虚假行为；

判断被保障用户是否为目标识别用户的关联用户；

判断目标保险对应的投保用户是否为指定类型用户；

基于交易行为数据，判断被保障用户与目标识别用户是否符合相似条件；

判断被保障用户进行理赔申请的订单中的地址信息是否为异常地址；

判断被保障用户对应的用户账号是否为异常账号；

判断被保障用户是否位于第二名单中；以及，

判定被保障用户在指定时间内的理赔累计金额是否大于预定数额。

当然，上述仅是举例说明的风险识别规则的可能实现方式，本申请对此不进行限定。

其中，根据不同风险程度，例如假设风险程度划分为高中低三个等级，对于高等级风险程度，则可以该多种风险评估规则均需要进行判断；而对于中等级风险程度以及低等级风险程度，则可以按照不同风险评估规则的防范程度，来确定各自所对应的至少一种风险评估规则，从而实现了差异化识别，以此可以提升识别能力，既可以保证精准度又可以保证正常用户的合法权益。

105：基于判断结果，确定被保障用户是否为目标识别用户。

可选地，在至少一个风险识别规则中的一个或多个风险识别规则对应的判断结果为是的情况下，确定被保障用户为目标识别用户。也即可以是在任一个风险识别规则的判定结果为是的情况下，确定被保障用户为目标识别用户；或者可以是在至少一个风险识别规则的判定结果均为是的情况下，确定被保障用户为目标识别用户；当然，也可以是指定数量的判定结果为是的情况下，确定被保障用户为目标识别用户；本申请对此不进行限定。

本实施例中，通过1(风险识别模型)+N(至少一种风险识别规则)的防控体系，提高了目标识别用户的识别精准度，且根据风险识别模型的风险程度来确定所对应的风险识别规则以进行风险判定，从而实现了差异化识别，进一步提高了精准度。相较于传统的单一规则识别方式，可以提高识别效率，尽早做出防范。

一些实施例中，该方法还可以包括：结合被保障用户的用户身份信息，识别被保障用户是否位于第一名单中；在被保障用户位于第一名单中的情况下，确定被保障用户为目标识别用户，否则执行至少一种特征数据的获取步骤。

一些实施例中，该方法还可以包括：识别被保障用户对应的用户账号是否为异常账号；在被保障用户对应用户账号为异常账号的情况下，确定被保障用户为目标识别用户，否则执行至少一种特征数据的获取步骤。

一些实施例中，该方法还可以包括：结合被保障用户的用户身份信息，识别被保障用户是否位于第一名单中；若是，确定被保障用户为目标识别用户，若否，识别被保障用户对应的用户账号是否为异常账号；在被保障用户对应用户账号为异常账号的情况下，确定被保障用户为目标识别用户，否则执行至少一种特征数据的获取步骤。

其中，第一名单中可以保存针对目标保险已确认为目标识别用户的用户身份信息等，此外还可以保存至少一个其它类保险已确认为目标识别用户的用户身份信息。

也即本申请实施例中，可以首先判断被保障用户是否位于第一名单和/或所对应用户账号是否为异常账号，若是，则可以直接确定被保障用户为目标识别用户，否则再执行上述步骤101的操作。第一名单和/或异常账号可以作为通用策略来首先进行判断，再结合1+N的防控体系来进行识别，通过分层识别方式从而可以平衡用户体验以及识别精准度。

一些实施例中，该方法还可以包括：

在风险程度大于预定程度的情况下，确定被保障用户为目标识别用户。

也即若风险程度较高情况下，可以直接确定被保障用户为目标识别用户，无需进行风险识别规则的判断。该预定程度可以结合实际情况而进行设定。

本申请实施例中，对被保障用户进行风险识别的触发事件可以有多种实现

作为一种可选方式，上述获取被保障用户所对应的至少一种特征数据可以包括：响应于接收到被保障用户被保障用户针对订单提交的理赔申请，获取被保障用户所对应的至少一种特征数据；其中，该订单基于被保障用户针对投保用户所提供目标对象提交的交易请求而生成；则该方法还可以包括：在确定被保障用户为目标识别用户的情况下，拦截该理赔申请。

其中，目标保险可以保障投保用户所产生的每一笔订单，被保障用户也即是投保用户产生的每一笔订单所对应的被保障用户，消费者通过购买投保用户所提供的对象而生成对应的订单，消费者即可以享受目标保障所提供的保障，成为被保障用户。

可以是在被保障用户针对某一笔订单进行理赔申请时，触发对被保障用户的风险识别。被保障用户可以通过用户端发送理赔申请，若被保障用户被确定为目标识别用户，则可以对该理赔申请进行拦截。

作为又一种可选方式，上述获取被保障用户所对应的至少一种特征数据可以包括：响应于接收到被保障用户针对投保用户所提供目标对象提交的交易请求，获取被保障用户所对应的至少一种特征数据。则该方法还可以包括：在确定被保障用户为目标识别用户的情况下，取消该交易请求。

也即可以是在被保障用户进行对象交易时，触发对被保障用户的风险识别，被保障用户可以通过用户端发送交易请求，若被保障用户被确定为目标识别用户，则可以取消该交易请求，否则即可以基于交易请求而生成订单。

作为又一种可选方式，上述获取目标保险的被保障用户所对应的至少一种特征数据可以包括：定期生成识别指令；响应于识别指令，获取目标保险的被保障用户所对应的至少一种特征数据；则该方法还可以包括：

在确定被保障用户为目标识别用户的情况下，为被保障用户设置特定标签；

接收到被保障用户的理赔申请的情况下，确定被保障用户存在特定标签，拦截该理赔申请，或者，接收到被保障用户的交易请求的情况下，确定被保障用户存在特征标签，取消该交易请求。

也即可以定期触发对被保障用户的风险识别，并在确定为目标识别用户情况下，设置特定标签，从而可以在接收到理赔申请或交易请求的情况下，若被保障用户存在该特定标签，则可以拦截该理赔申请或者交易请求等。

一些实施例中，拦截理赔申请或者取消交易请求的情况下，该方法还可以包括：在确定被保障用户为目标识别用户的情况下，向被保障用户反馈异常提示信息；

响应于被保障用户针对异常提示信息触发的申诉请求，生成申诉任务，并将申诉任务分配至相关人员，从而可以由相关人员进行人工识别。

也即可以提供申诉服务，以对可能误识别为目标识别用户的被保障用户，可以由人工进行复核等。

由前文描述可知，风险识别模型可以预先训练获得，如图2所示，本申请实施例还提供了一种模型训练方法，该方法可以包括：

201：获取样本用户的至少一种样本特征数据。

202：基于样本用户的至少一种特征数据训练风险识别模型。

其中，样本用户为目标识别用户，也即正样本情况下，则对应训练标签可以为数值1，样本用户为正常用户，也即负样本情况下，则对应训练标签可以为数值0。当然，风险识别模型可以利用正样本训练获得。

一些实施例中，上述获取样本用户的至少一种样本特征数据可以包括：

从历史数据记录中确定属于第一名单和/或历史行为数据符合筛选条件的样本用户；

获取样本用户对应的至少一种样本特征数据。

其中，属于第一名单和/或交易行为数据符合筛选条件，可以认为样本用户为目标识别用户。从而可以以此进行风险识别模型的训练。

其中，历史行为数据可以包括指定交易行为类型对应的行为数据；比如，交易行为数据可以包括指定时间内理赔申请次数或者赔付金额等；该筛选条件例如可以是指定时间内理赔申请次数大于指定次数或者赔付金额大于支付金额等等。

该至少一种样本特征数据即可以包括从样本用户对应的历史行为数据中，所获取的样本用户的至少一种第一样本用户特征，样本用户所对应的投保用户的至少一种第二样本用户特征，以及样本用户的关联用户所对应的至少一种第三样本用户特征中的一个或多个等。

其中，至少一种第一样本用户特征例如可以包括如下一种或多种数据：

样本用户在第一时间段内的理赔申请订单中的退款申请订单的占比情况；

样本用户在第二时间段内的退款申请订单数量；

样本用户在线上平台首次支付时间距离当前时间的支付时长；

样本用户在第三时间段内对应的理赔申请订单中未发货订单的占比情况；以及

样本用户在第四时间段内对应的理赔申请订单中使用次数最多的交易地址等。

其中，该至少一种第二样用户特征例如可以包括：该样本用户所对应的投保用户对应的延期发货订单占比情况；和/或，投保用户针对理赔事件的申诉次数等。

该至少一种第三样本用户特征与至少一种第一样本用户特征的特征类型可以相同，例如可以包括如下一种或多种数据：关联用户在第一时间段内的理赔申请订单中的退款申请订单的占比情况；

关联用户在第二时间段内的退款申请订单数量；

关联用户在线上平台首次支付时间距离当前时间的支付时长；

关联用户在第三时间段内对应的理赔申请订单中未发货订单的占比情况；以及

关联用户在第四时间段内对应的理赔申请订单中使用次数最多的交易地址等。

在一个实际应用中，本申请实施例的技术方案可以应用于电子商务场景中，对象为商品，对象提供方即为商家，被保障用户即为买家，商家可以购买平台方所提供的目标保险，以为购买其所提供商品的买家提供相应保障，买家可以针对商家的商品进行交易，从而生成订单，在目标保险的保障下，例如若订单出现发货延时情况或者价格降低情况等，则买家可以进行理赔申请，平台方可以对买家进行相应赔付。下面以电子商务场景为例，结合图3所示的交互示意图，对本申请技术方案进行介绍，如图3所示，为了防范目标识别用户，维护平台方、商家以及正常用户的合法权益，可以在买家通过用户端301针对订单进行理赔申请，和/或针对商品触发交易请求的情况下，服务端302可以首先通过通用策略，判断买家是否位于黑名单中，以及买家对应的用户账号是否为异常账号，以对买家进行筛选。其中，黑名单可以保存目标保险所对应的已确认为目标识别用户的用户身份信息，此外还可以包括其它类保险所对应的已确认为目标识别用户的用户身份信息，此外还可以包括平台方已确认的目标识别用户的用户身份信息等，从而可以联合防控。

若买家未处于黑名单中或者买家对应的用户账号不是异常账号的情况下，可以首先利用风险识别模型识别买家的风险程度，再结合风险程度所对应的至少一种风险识别规则，对买家进行风险判断，从而通过1+N的防控体系以及分层识别方式、差异化的识别方式，确定买家是否为目标识别用户，并在确定为目标识别用户的情况下，拦截理赔申请或者取消交易请求，从而实现对恶买或者恶意理赔的拦截。

此外，服务端302还可以生成异常提示信息，并反馈给用户端301，用户端301可以输出异常提示信息，买家可以针对异常提示信息执行申诉操作，用户端301可以感知申诉操作并向服务端302发送申诉请求，服务端302可以生成申诉任务，并将申诉任务发送至相关人员，由相关人员通过人工方式进行复核等。

本申请实施例突破单规则式的核赔策略，打破旧策略体系的局限性，进一步提升识别效率；通过1+N的防控体系，设计通用型解决框架，基于差异化方式识别提升了识别能力，从而提高了识别精准度，实现了恶买和恶意理赔的有效拦截。

本申请实施例可以联动平台各方实现目标识别用户的联防联控，在赔付率可控的情况下进行差异化分层管控，从而实现买家体验和赔付率的平衡，可以有效提交赔付率，提升精准度，也降低了欺诈团伙的攻击，降低了恶买订单的占比。

图4为本申请实施例提供的一种用户识别装置一个实施例的结构示意图，该装置可以包括：

第一获取模块401，用于获取目标保险的被保障用户所对应的至少一种特征数据；

第一识别模块402，用于基于所述至少一种特征数据，利用风险识别模型确定所述被保障用户的风险程度；

规则确定模块403，用于从多种风险识别规则中，确定所述风险程度对应的至少一种风险识别规则；

第二识别模型404，用于利用所述至少一种风险识别规则，对所述被保障用户进行风险判断；

结果确定模块405，用于基于判断结果，确定所述被保障用户是否为目标识别用户。

一些实施例中，该装置还可以包括：

第三识别模块，用于结合所述被保障用户的用户身份信息，识别所述被保障用户是否位于第一名单中；识别所述被保障用户对应的用户账号是否为异常账号；在所述被保障用户位于第一名单中和/或对应用户账号为异常账号的情况下，确定所述被保障用户为目标识别用户，否则触发所述数据获取模块执行。

一些实施例中，该结果确定模块还用于在所述风险程度大于预定程度的情况下，确定所述被保障用户为目标识别用户。

一些实施例中，该装置还可以包括：

模型训练模块，用于获取样本用户的至少一种样本特征数据；基于所述样本用户的至少一种特征数据训练风险识别模型。

一些实施例中，该模型训练模块获取样本用户的至少一种样本特征数据包括：从历史记录中确定属于第一名单和/或历史行为数据符合筛选条件的样本用户；获取所述样本用户对应的至少一种样本特征数据。

一些实施例中，数据获取模块可以具体是从所述目标保险的被保障用户对应的历史行为数据中，获取所述被保障用户的至少一种第一用户特征；获取所述被保障用户所对应的投保用户的至少一种第二用户特征；获取所述被保障用户的关联用户所对应的至少一种第三用户特征；将所述至少一种用户特征、所述至少一种用户特征以及所述至少一种第三用户特征，作为至少一种特征数据。

一些实施例中，上述第二识别模块可以包括如下一种或多种实现方式：

判断所述被保障用户与所述目标保险对应的投保用户是否为同一个用户；

判断所述被保障用户对所述投保用户所提供对象执行的交易行为是否为虚假行为；

判断所述被保障用户是否为目标识别用户的关联用户；

判断所述目标保险对应的投保用户是否为指定类型用户；

基于交易行为数据，判断所述被保障用户与目标识别用户是否符合相似条件；

判断所述被保障用户进行理赔申请的订单中的地址信息是否为异常地址；

判断所述被保障用户对应的用户账号是否为异常账号；

判断所述被保障用户是否位于第二名单中；以及，

判定所述被保障用户在指定时间内的理赔累计金额是否大于预定数额。

一些实施例中，所述被保障用户为针对所述目标保险的投保用户所提供的对象存在交易行为的用户；

上述数据获取模块具体用于响应于接收到被保障用户被保障用户针对订单提交的理赔申请，获取所述被保障用户所对应的至少一种特征数据；所述订单基于所述被保障用户针对投保用户所提供目标对象提交的交易请求而生成；

该装置还可以包括：

第一处理模块，用于在确定所述被保障用户为目标识别用户的情况下，拦截所述理赔申请。

一些实施例中，上述数据获取模块具体用于响应于接收到所述被保障用户针对投保用户所提供目标对象提交的交易请求，获取被保障用户所对应的至少一种特征数据

该装置还可以包括：

第二处理模块，用于在确定所述被保障用户为目标识别用户的情况下，取消所述交易请求。

一些实施例中，上述数据获取模块具体用于定期生成识别指令；

响应于所述识别指令，获取目标保险的被保障用户所对应的至少一种特征数据；

该装置还可以包括：

第三处理模块，用于在确定所述被保障用户为目标识别用户的情况下，为所述被保障用户设置特定标签；接收到所述被保障用户的理赔申请的情况下，确定所述被保障用户存在所述特征标签，拦截所述理赔申请，或者接收到所述被保障用户针对投保用户所提供目标对象提交的交易请求的情况下，确定所述被保障用户存在所述特征标签，取消所述交易请求。

一些实施例中，该装置还可以包括：

第四处理模块，用于在确定所述被保障用户为目标识别用户的情况下，向所述被保障用户反馈异常提示信息；

响应于所述被保障用户针对所述异常提示信息触发的申诉请求，生成申诉任务，并将所述申诉任务分配至相关人员。

一些实施例中，上述结果确定模块具体用于在所述至少一个风险识别规则中的一个或多个风险识别规则对应的判断结果为是的情况下，确定所述被保障用户为目标识别用户。

图4所述的用户识别装置可以执行图1所示实施例所述的用户识别方法，其实现原理和技术效果不再赘述。对于上述实施例中的用户识别装置其中各个模块、单元执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

图5为本申请实施例提供的一种模型训练装置一个实施例的结构示意图，该装置可以包括：

第二获取模块501，用于获取样本用户的至少一种样本特征数据；

训练模块502，用于基于所述样本用户的至少一种特征数据训练风险识别模型。

一些实施例中，第二获取模块可以具体是从历史记录中确定属于第一名单和/或历史行为数据符合筛选条件的样本用户；获取所述样本用户对应的至少一种样本特征数据。

图5所述的用户识别装置可以执行图2所示实施例所述的模型训练方法，其实现原理和技术效果不再赘述。对于上述实施例中的模型训练装置其中各个模块、单元执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

本申请实施例还提供了一种计算设备，如6图所示，该设备可以包括存储组件601以及处理组件602；

该存储组件601存储一条或多条计算机指令，其中，所述一条或多条计算机指令供所述处理组件602调用并执行，以实现如图1所示的用户识别方法或者如图2所示的模型训练方法。

当然，计算设备必然还可以包括其他部件，例如输入/输出接口、显示组件、通信组件等。

输入/输出接口为处理组件和外围接口模块之间提供接口，上述外围接口模块可以是输出设备、输入设备等。通信组件被配置为便于计算设备和其他设备之间有线或无线方式的通信等。

其中，处理组件可以包括一个或多个处理器来执行计算机指令，以完成上述的方法中的全部或部分步骤。当然处理组件也可以为一个或多个应用专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理设备(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、控制器、微控制器、微处理器或其他电子元件实现，用于执行上述方法。

存储组件被配置为存储各种类型的数据以支持在终端的操作。存储组件可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

需要说明的是，上述计算设备可以为物理设备或者云计算平台提供的弹性计算主机等。其可以实现成多个服务器或终端设备组成的分布式集群，也可以实现成单个服务器或单个终端设备。

本申请实施例还提供了一种计算机可读存储介质，存储有计算机程序，所述计算机程序被计算机执行时可以实现上述图1所示实施例的用户识别方法或者上述图2所示实施例的模型训练方法。该计算机可读介质可以是上述实施例中描述的电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。

本申请实施例还提供了一种计算机程序产品，其包括承载在计算机可读存储介质上的计算机程序，所述计算机程序被计算机执行时可以实现如上述如图1所示实施例的用户识别方法或者上述图2所示实施例的模型训练方法。在这样的实施例中，计算机程序可以是从网络上被下载和安装，和/或从可拆卸介质被安装。在该计算机程序被处理器执行时，执行本申请的系统中限定的各种功能。

需要说明的是，本申请实施例中可能会涉及到对用户数据的使用，在实际应用中，可以在符合所在国的适用法律法规要求的情况下(例如，用户明确同意，对用户切实通知，等)，在适用法律法规允许的范围内在本文描述的方案中使用用户特定的个人数据。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。

最后应说明的是：以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims (14)

1.一种用户识别方法，其特征在于，包括：

获取目标保险的被保障用户所对应的至少一种特征数据；

基于所述至少一种特征数据，利用风险识别模型确定所述被保障用户的风险程度；

从多种风险识别规则中，确定所述风险程度对应的至少一种风险识别规则；

利用所述至少一种风险识别规则，对所述被保障用户进行风险判断；

基于判断结果，确定所述被保障用户是否为目标识别用户。

2.根据权利要求1所述的方法，其特征在于，还包括：

结合所述被保障用户的用户身份信息，识别所述被保障用户是否位于第一名单中；

识别所述被保障用户对应的用户账号是否为异常账号；

在所述被保障用户位于第一名单中和/或对应用户账号为异常账号的情况下，确定所述被保障用户为目标识别用户，否则执行所述至少一种特征数据的获取步骤。

3.根据权利要求1所述的方法，其特征在于，还包括：

在所述风险程度大于预定程度的情况下，确定所述被保障用户为目标识别用户。

4.根据权利要求1所述的方法，其特征在于，所述风险识别模型按照如下方式预先训练获得：

获取样本用户的至少一种样本特征数据；

基于所述样本用户的至少一种特征数据训练风险识别模型。

5.根据权利要求4所述的方法，其特征在于，所述获取样本用户的至少一种样本特征数据包括：

从历史记录中确定属于第一名单和/或历史行为数据符合筛选条件的样本用户；

获取所述样本用户对应的至少一种样本特征数据。

6.根据权利要求1所述的方法，其特征在于，所述获取目标保险的被保障用户所对应的至少一种特征数据包括：

从所述目标保险的被保障用户对应的历史行为数据中，获取所述被保障用户的至少一种第一用户特征；

获取所述被保障用户所对应的投保用户的至少一种第二用户特征；

获取所述被保障用户的关联用户所对应的至少一种第三用户特征；

将所述至少一种用户特征、所述至少一种用户特征以及所述至少一种第三用户特征，作为至少一种特征数据。

7.根据权利要求1所述的方法，其特征在于，所述利用所述至少一种风险识别规则，对所述被保障用户进行风险判断包括如下一种或多种实现方式：

判断所述被保障用户与所述目标保险对应的投保用户是否为同一个用户；

判断所述被保障用户对所述投保用户所提供对象执行的交易行为是否为虚假行为；

判断所述被保障用户是否为目标识别用户的关联用户；

判断所述目标保险对应的投保用户是否为指定类型用户；

基于交易行为数据，判断所述被保障用户与目标识别用户是否符合相似条件；

判断所述被保障用户进行理赔申请的订单中的地址信息是否为异常地址；

判断所述被保障用户对应的用户账号是否为异常账号；

判断所述被保障用户是否位于第二名单中；以及，

判定所述被保障用户在指定时间内的理赔累计金额是否大于预定数额。

8.根据权利要求1所述的方法，其特征在于，所述被保障用户为针对所述目标保险的投保用户所提供的对象存在交易行为的用户；

所述获取被保障用户所对应的至少一种特征数据包括：

响应于接收到被保障用户被保障用户针对订单提交的理赔申请，获取所述被保障用户所对应的至少一种特征数据；所述订单基于所述被保障用户针对投保用户所提供目标对象提交的交易请求而生成；

所述方法还包括：在确定所述被保障用户为目标识别用户的情况下，拦截所述理赔申请。

9.根据权利要求1所述的方法，其特征在于，所述获取被保障用户所对应的至少一种特征数据包括：

响应于接收到所述被保障用户针对投保用户所提供目标对象提交的交易请求，获取被保障用户所对应的至少一种特征数据

所述方法还包括：在确定所述被保障用户为目标识别用户的情况下，取消所述交易请求。

10.根据权利要求1所述的方法，其特征在于，所述获取目标保险的被保障用户所对应的至少一种特征数据包括：

定期生成识别指令；

响应于所述识别指令，获取目标保险的被保障用户所对应的至少一种特征数据；

所述方法还包括：

在确定所述被保障用户为目标识别用户的情况下，为所述被保障用户设置特定标签；

接收到所述被保障用户的理赔申请的情况下，确定所述被保障用户存在所述特征标签，拦截所述理赔申请，或者接收到所述被保障用户针对投保用户所提供目标对象提交的交易请求的情况下，确定所述被保障用户存在所述特征标签，取消所述交易请求。

11.根据权利要求8或9所述的方法，其特征在于，还包括：

在确定所述被保障用户为目标识别用户的情况下，向所述被保障用户反馈异常提示信息；

响应于所述被保障用户针对所述异常提示信息触发的申诉请求，生成申诉任务，并将所述申诉任务分配至相关人员。

12.根据权利要求1所述的方法，其特征在于，所述基于判断结果，确定所述被保障用户是否为目标识别用户包括：

在所述至少一个风险识别规则中的一个或多个风险识别规则对应的判断结果为是的情况下，确定所述被保障用户为目标识别用户。

13.一种计算设备，其特征在于，包括处理组件以及存储组件；

所述存储组件存储一个或多个计算机指令；所述一个或多个计算机指令用以被所述处理组件调用执行，以实现如权利要求1～12任一项所述的用户识别方法。

14.一种计算机存储介质，其特征在于，存储有计算机程序，所述计算机程序被计算机执行时，以实现如权利要求1～12任一项所述的用户识别方法。