确定风评策略的方法、装置及计算机存储介质与流程

本申请涉及互联网
技术领域：
，特别涉及一种确定风评策略的方法、装置及计算机存储介质。
背景技术：
：为了提升电商平台上的交易安全性，当用户在任一电商平台上触发登录、交易或支付等事件时，电商平台需要根据风评策略对该事件进行风险评估，以便于后续根据评估出的风险大小采取一定的措施。其中，风评策略用于指示进行风险评估的相应策略。相关技术中，对于某一事件，预先确定出风评策略，然后将风评策略整体封装在一个静态文件中。后续需要对该事件进行风险评估时，从该静态文件中获取风评策略即可。但是如果需要对风评策略进行调整，则需重新修改整个静态文件，产生的人力成本以及时间成本较高。技术实现要素：本申请实施例提供了一种确定风评策略的方法、装置及计算机存储介质，可以降低修改风评策略所产生的人力成本以及时间成本。所述技术方案如下：一方面，提供了一种确定风评策略的方法，所述方法包括：根据待评估的第一事件的事件标识，获取一个或多个规则标识，每个规则标识用于指示一个规则，所述规则用于判断所述第一事件是否为风险事件；获取与所述一个或多个规则标识一一对应的一个或多个规则；根据所述一个或多个规则生成用于对所述第一事件进行风险评估的第一风评策略，所述第一风评策略包括所述一个或多个规则、以及每个规则的风险基准分数，每个规则的风险基准分数用于指示当所述第一事件满足相应规则时所述第一事件的风险大小。可选的，所述获取与所述一个或多个规则标识一一对应的一个或多个规则，包括：对于所述一个或多个规则标识中任一规则标识，根据所述规则标识，从第一映射关系中获取与所述规则标识对应的一个或多个条件标识，所述第一映射关系包括多个规则标识和每个规则标识对应的一个或多个条件标识；根据所述一个或多个条件标识获取一个或多个条件；根据所述一个或多个条件生成与所述规则标识对应的规则。可选的，所述根据所述一个或多个规则生成用于对所述第一事件进行风险评估的第一风评策略，包括：确定所述多个规则中每个规则的风险基准分数，每个规则的风险基准分数用于指示相应规则对应的风险的大小；根据所述一个或多个规则中每个规则的风险基准分数，生成所述第一风评策略。可选的，所述根据所述一个或多个规则中每个规则的风险基准分数，生成所述第一风评策略，包括：确定每个规则的灰度值，每个规则的灰度值用于指示当所述第一事件满足相应规则时需要根据相应规则对所述第一事件进行风险评估的概率；根据所述一个或多个规则中每个规则的风险基准分数以及每个规则的灰度值，生成所述第一风评策略。可选的，所述根据待评估的第一事件的事件标识，获取一个或多个规则标识，包括：从第二映射关系中获取与所述第一事件的事件标识对应的第一策略标识，所述第一策略标识用于指示所述第一风评策略，所述第二映射关系包括多个事件标识和与所述多个事件标识一一对应的多个策略标识；根据所述第一策略标识，从第三映射关系中获取与所述第一策略标识对应的一个或多个规则标识，所述第三映射关系包括多个策略标识和每个策略标识对应的一个或多个规则标识。可选的，所述方法还包括：获取策略修改请求，所述策略修改请求携带用于指示第二风评策略的策略标识，所述第二风评策略为当前时间之前已经配置的风评策略；根据所述策略修改请求中携带的策略标识获取所述第二风评策略包括的一个或多个规则；当检测到针对所述第二风评策略包括的一个或多个规则中的第一规则的修改请求时，对所述第一规则进行修改，所述第一规则为所述第二风评策略包括的一个或多个规则中一个规则；将所述第一规则替换为修改后的规则。另一方面，提供了一种确定风评策略的装置，所述装置包括：第一获取模块，用于根据待评估的第一事件的事件标识，获取一个或多个规则标识，每个规则标识用于指示一个规则，所述规则用于判断所述第一事件是否为风险事件；第二获取模块，用于获取与所述一个或多个规则标识一一对应的一个或多个规则；生成模块，用于根据所述一个或多个规则生成用于对所述第一事件进行风险评估的第一风评策略，所述第一风评策略包括所述一个或多个规则、以及每个规则的风险基准分数，每个规则的风险基准分数用于指示当所述第一事件满足相应规则时所述第一事件的风险大小。可选的，所述第二获取模块，包括：第一获取子模块，用于对于所述一个或多个规则标识中任一规则标识，根据所述规则标识，从第一映射关系中获取与所述规则标识对应的一个或多个条件标识，所述第一映射关系包括多个规则标识和每个规则标识对应的一个或多个条件标识；第二获取子模块，用于根据所述一个或多个条件标识获取一个或多个条件；第一生成子模块，用于根据所述一个或多个条件生成与所述规则标识对应的规则。可选的，所述生成模块包括：确定子模块，用于确定所述多个规则中每个规则的风险基准分数，每个规则的风险基准分数用于指示相应规则对应的风险的大小；第二生成子模块，用于根据所述一个或多个规则中每个规则的风险基准分数，生成所述第一风评策略。可选的，所述生成子模块，包括：确定单元，用于确定每个规则的灰度值，每个规则的灰度值用于指示当所述第一事件满足相应规则时需要根据相应规则对所述第一事件进行风险评估的概率；生成单元，用于根据所述一个或多个规则中每个规则的风险基准分数、以及每个规则的灰度值，生成所述第一风评策略。可选的，所述第一获取模块，包括：第三获取子模块，用于从第二映射关系中获取与所述第一事件的事件标识对应的第一策略标识，所述第一策略标识用于指示所述第一风评策略，所述第二映射关系包括多个事件标识和与所述多个事件标识一一对应的多个策略标识；第四获取子模块，用于根据所述第一策略标识，从第三映射关系中获取与所述第一策略标识对应的一个或多个规则标识，所述第三映射关系包括多个策略标识和每个策略标识对应的一个或多个规则标识。可选的，所述装置还包括：第三获取模块，用于获取策略修改请求，所述策略修改请求携带用于指示第二风评策略的策略标识，所述第二风评策略为当前时间之前已经配置的风评策略；第四获取模块，用于根据所述策略修改请求中携带的策略标识获取所述第二风评策略包括的一个或多个规则；修改模块，用于当检测到针对所述第二风评策略包括的一个或多个规则中的第一规则的修改请求时，对所述第一规则进行修改，所述第一规则为所述第二风评策略包括的一个或多个规则中一个规则；替换模块，用于将所述第一规则替换为修改后的规则。另一方面，提供了一种确定风评策略的装置，所述确定风评策略的装置包括处理器、通信接口、存储器和通信总线；其中，所述处理器、所述通信接口和所述存储器通过所述通信总线完成相互间的通信；所述存储器用于存放计算机程序；所述处理器用于执行所述存储器上所存放的程序，以实现前述提供确定风评策略的方法。另一方面，提供了一种计算机可读存储介质，所述存储介质内存储有计算机程序，所述计算机程序被处理器执行时实现前述提供的确定风评策略的方法的步骤。本申请实施例提供的技术方案带来的有益效果至少包括：通过根据待评估的第一事件的事件标识，获取一个或多个规则标识；获取与一个或多个规则标识一一对应的一个或多个规则；根据一个或多个规则生成用于对第一事件进行风险评估的第一风评策略。本申请通过多个规则来动态生成风评策略，而不是预先生成整个风评策略，因此，后续可以只对其中的一个规则进行调整，以实现对最终生成的风评策略的调整，避免了需要从头修改整个风评策略，从而大大降低了修改风评策略所产生的人力成本以及时间成本。附图说明为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。图1是本申请实施例提供的一种确定风评策略的系统架构图；图2是本申请实施例提供的一种风评策略的配置关系的示意图；图3是本申请实施例提供的一种生成树+索引库的结构示意图；图4是本申请实施例提供的一种确定风评策略的方法流程图；图5是本申请实施例提供的一种执行风评策略的流程图；图6是本申请实施例提供的一种确定风评策略的装置的结构示意图；图7是本申请实施例提供的一种服务器的结构示意图。具体实施方式为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。在对本申请实施例提供的确定风评策略的方法进行详细的解释说明之前，先对本申请实施例涉及的应用场景予以介绍。为了提升电商平台上的交易安全性，需要及时监控用户在电商平台上触发的登录、交易或支付等事件时所存在潜在风险，为此电商平台对不同的事件配置不同的风评策略，以便根据不同的风评策略对相应的事件进行风险评估。比如，当事件为交易事件时，配置的风评策略为如果一周内的交易次数大于预设值，则判定该交易事件为风险系数较高的交易事件。假设当电商平台监控到某一用户在短期内的交易次数大于预设值时，表明该用户触发的交易事件为风险系数较高的交易事件，需要采取一定的措施，比如限制当前用户的交易次数，以保障当前电商平台的安全性。图1是本申请实施例提供的一种确定风评策略的系统架构。如图1所示，该系统100包括用户端101、服务器102。用户端101和服务器102之间通过无线或有线方式连接以进行通信。其中，用户端101上安装有电商平台对应的应用，服务器102为电商平台。该用户端101可以基于用户的预设操作，触发登录、交易或支付等事件，同时向服务器102发送一个事件风评请求。服务器接收到该事件风评请求后，可以根据该事件风评请求中携带的事件标识，确定出该事件对应的风评策略，并根据该风评策略确定出当前事件的风险分数，进而根据该风险分数确定出执行决定，并将该执行决定返回至用户端。用户端根据接收到的执行决定确定出是否执行该事件。关于上述服务器确定风评策略的具体实现方式将在下述实施例中详细说明，在此就先不一一展开说明。其中，服务器需要基于不同的事件配置不同的风评策略。当用户端触发一个事件时，服务器通过执行该风评策略，以检测该事件是否具有一定的潜在风险。为了实现服务器可以动态生成任一事件对应的风评策略，从而便于后续服务器可以灵活地对该风评策略进行修改，如图2所示，在本申请实施例提供的一种确定风评策略的方法中，任一事件对应一个风评策略，也即是事件和策略之间按照1:1的关系进行配置。一个策略通常包括多个规则，也即是策略和规则之间按照1：n的方式进行配置的。一个规则通常包含多个条件/条件组，也即是规则和条件之间按照1:n的关系进行配置。需要说明的是，条件组用于指示将多个条件按照逻辑运算关系进行组合的一种特殊的条件。如此便可通过组合多个条件生成规则，再通过组合多个规则生成任一事件对应的风评策略。以实现动态生成风评策略。其中，规则用于指示判定逻辑的依据。具体的，规则和条件相当“部门”和“个人”的关系，也即是，规则包含一个或者多个条件。条件用于判断任一事件的指定属性是否满足相应的目标指定属性。并且，通常条件是将指标、操作符和常量三者进行组合所得到的。比如将指标“过去一周内用户的订单数量”、操作符“＞”和常量“100”组合进行组合，则组合的条件为：“过去一周内用户的订单数量＞100”。指标用于指示对字段的一种组合加工，比如指标可以是：“过去一周内用户的订单数量”。字段用于指示用户的属性值，比如用户的用户信息，地址信息，订单信息等。另外，上述任一规则包括的任一条件还可以是一个条件组。该条件组是将多个条件按照逻辑运算关系组合而成的。例如，该逻辑关系为“与”的关系时，表明如果任一事件满足该条件组内所有条件，则满足该条件组。该逻辑关系为“或”的关系时，表明如果任一事件满足该条件组内任一条件，则满足该条件组。如此可知，组织任一事件的风评策略涉及不同类型的对象，也即是，当需要生成任一风评策略时，需要涉及的对象有：规则、条件、字段、指标。进一步地，为了便于管理这些对象，不同类型的对象之间独立存储。此时，为了便于后续能够快速动态生成风评策略，需要预先配置这些不同的对象之间的映射关系、以及各个对象的存储位置。其中，不同的对象之间的映射关系可以采用图3所示的生成树(tree)的方式来配置，各个对象的存储位置可以通过图3所示的索引库(map)来表示。如图3所示，该生成树包括多个对象表、以及该多个对象表之间的映射关系。以图3为例，生成树中包括事件表、规则表、条件表这三种类型的对象表。并设置该三个对象表之间的映射关系。具体的，对于任一电商平台应用，为该电商平台应用配置一个事件表，该事件表包括多个事件标识、以及与该多个事件标识一一对应的多个事件。而对于该事件表的任一事件，为该任一事件配置一个规则表，该规则表包括多个规则标识、以及与该多个规则标识一一对应的多个规则。而对于该规则对象表的任一规则，为该任一规则配置一个条件表，该条件表包括多个条件标识、以及与该多个条件标识一一对应的多个条件。其中，构建生成树的实现方式并不限于上述一种实现方式，其他实现方式在此不再一一进行举例说明。图3所示，该索引库包括多个索引表，该多个索引表包括：事件索引表、规则索引表、条件索引表、指标索引表、字段索引表。其中，事件索引表用于存储多个事件标识，以及该多个事件标识所指示的多个事件在内存中的位置。规则索引表用于存储多个规则标识，以及该多个规则标识所指示的多个规则在内存中的位置。条件索引表用于存储多个条件标识，以及该多个条件标识所指示的多个条件在内存中的位置。指标索引表用于存储多个指标标识，以及该多个指标标识所指示的多个指标在内存中的位置。字段索引表用于存储多个字段标识，以及该多个字段标识所指示的字段在内存中的位置。需要说明的是，如果通过索引库查找到目标对象，并做出更改，那么生成树中的目标对象也会发生同样的更改，也即是该生成树中基于该目标对象的风评策略发生了更改。如此，通过索引库可以实现更加灵活的修改任一事件对应的风评策略的目的。此外，在本申请实施例中，用户端101可以为平板电脑、台式电脑、手机等设备，服务器102可以是电商平台，也可以是用于本申请实施例中用于确定风评策略的一台服务器或者一个服务器集群，本申请实施例对此不做限定。需要说明的是，上述是以服务器执行本申请实施例提供的确定风评策略的方法为例进行说明。可选地，本申请实施例提供的确定风评策略的方法也可以应用于用户端，本申请实施例对此不做具体限定。接下来对本申请实施例提供的确定风评策略的方法进行详细的解释说明。图4是本申请实施例提供的一种确定风评策略的方法的流程图，该方法应用于服务器。请参考图4，该方法包括如下步骤。步骤401：服务器根据待评估的第一事件的事件标识，获取一个或多个规则标识，每个规则标识用于指示一个规则。当服务器接收到用户端基于用户的预设操作发送的第一事件的事件风评请求时，服务器可以通过步骤401～步骤403确定出第一事件对应的风评策略。其中，第一事件用于指示用户端基于用户的预设操作所触发的任一事件。该事件可以是交易事件、支付事件或者登录事件等事件的任一事件。在一种可能的实现方式中，步骤401可能的实现过程为：从第二映射关系中获取与第一事件的事件标识对应的第一策略标识；根据第一策略标识，从第三映射关系中获取与第一策略标识对应的一个或多个规则标识。上述第二映射关系和第三映射关系是服务器基于上述生成树构建的，该第二映射关系包括多个事件标识以及与多个事件标识中的每个事件标识一一对应的多个策略标识。该第三映射关系包括多个策略标识以及与多个策略标识中的每个策略标识一一对应的一个或多个规则标识。其中，第一策略标识用于指示第一风评策略。比如，服务器构建的第二映射关系和第三映射关系如下所示：第二映射关系事件标识策略标识101202…………n0n第三映射关系策略标识规则标识01001、00202003…………0n…、00x比如，服务器获取的第一事件的事件标识，该事件标识为1，并从第二映射关系中获取与事件标识1所对应的第一策略标识01，根据第一策略标识01，从第三映射关系中获取与第一策略标识01对应的一个或者多个规则标识，该规则标识为{001、002}在另一种可能的实现方式中，步骤401可能的实现过程为：服务器根据第一事件的事件标识以及上述生成树中包括的事件标识和规则标识之间的映射关系中，直接获取第一事件对应的一个或者多个规则标识。比如，当第一事件为生单事件时，服务器接收用户端基于当前用户的预设操作发送的生单请求，该生单请求携带该生单事件的事件标识，该事件标识可以是1，服务器根据第一事件的事件标识1从事件标识和规则标识之间的映射关系中获取该事件标识为1的事件对应的一个或者多个规则标识，该规则标识可以是{001，002}步骤402：服务器获取与一个或多个规则标识一一对应的一个或多个规则。在一种可能的实现方式中，步骤402可能的实现过程为：服务器根据上述索引库，直接获取与一个或多个规则标识一一对应的一个或多个规则。在另一种可能的实现方式中，每个规则包括一个或多个条件，每个条件用于判断第一事件的第一属性是否满足相应条件中配置的目标属性。其中，第一属性为第一事件中的任一属性。如此，步骤402可以通过步骤(1)～步骤(3)来实现。步骤(1)：对于一个或多个规则标识中任一规则标识，根据规则标识，从第一映射关系中获取与规则标识对应的一个或多个条件标识。其中，服务器基于上述生成树构建第一映射关系，该第一映射关系包括多个规则的标识以及和每个规则标识对应的一个或者多个条件标识。在一种可能的实现方式中，步骤(1)可能的实现过程为：根据步骤201中确定出的多个规则标识以及第一映射关系，确定出该多个规则标识中的每个规则标识所对应的一个或者条件标识。比如，服务器已构建的第一映射关系如下所示：第一映射关系规则标识条件标识0010001、0020002、0003…..……..00n……、000x服务器根据第一事件对应的多个规则标识{001，002}，确定出该多个规则标识一一对应的条件的标识。规则001对应的条件标识为{0001}，规则002对应的条件标识为{0002，0003}。步骤(2)：服务器根据一个或多个条件标识获取一个或多个条件。在一种可能的实现方式中，步骤(2)可能的实现过程为：根据已构建的索引库，从一个或者多个条件标识中，确定出与一个或者多个条件标识所指示的一个或者多个条件在内存中的位置，进而确定出与该一个或者多个条件标识一一对应的一个或者多个条件。比如，服务器根据已构建的索引库，确定出与该一个或者多个条件标识一一对应的一个或者多个条件为：{条件0001：注册手机号以139开头}、{条件0002：过去一周下单数量大于100单}、{条件0003：下单地址等同于注册地址}。需要说明的是，所有的条件均可以被抽象为字段+操作符+常量的三元组模型，其中，操作符可以是四则运算工具集，ip算法工具集，手机号算法工具集等算法工具集中的操作符。比如，条件“注册手机号以139开头”可以抽象为字段“注册手机号”中前三位+算法工具集“＝”+常量“139”进行组合得到的。另外，还可以将多个条件进行组合得到多个条件组。需要说明的是，条件和条件组属于同级概念，均包含于规则中，也即是，规则中可以包含一个或者多个条件也可以包括一个或者多个条件组，也可以分别同时包括一个或者多个条件和一个或者多个条件组。其中，条件组是将一个或者多个条件进行组合得到的，比如可以将多个条件按照“与运算”进行组合得到一个条件组，也即是，当前事件需要同时满足该多个条件则满足该条件组。也可以按照“或”运算进行组合得到一个条件组，也即是，当前事件只满足该多个条件的任意一个条件即可满足该条件组。步骤(3)：服务器根据一个或多个条件生成与规则标识对应的规则。在一种可能的实现方式中，步骤(3)可能的实现过程为：确定针对一个或多个条件的逻辑运算关系。该逻辑运算关系用于指示这一个或多个条件如何组合才能判断一个事件是否为风险事件。根据该逻辑运算关系将这一个或多个条件进行组合，即可得到该规则。其中，逻辑运算关系中包括“与”的关系和/或“或”的关系。下面以这一个或多个条件分别为条件1、条件2和条件3举例说明如何通过逻辑运算关系生成规则。可选的，将条件1、条件2和条件3之间按照“或”的关系进行组合。如此，根据这三个条件得到一个规则。也即是，该规则为：如果当前事件满足条件1、条件2或者条件3中任一个条件，则表明当前事件命中该规则。可选的，将条件1、条件2和条件3之间按照“与”的关系进行组合。如此，根据这三个条件得到一个规则。也即是，该规则为：如果当前事件同时满足条件1、条件2或者条件3，则表明当前事件命中该规则。可选的，将条件1和条件2之间按照“与”的关系进行组合后，再按照“或”的关系与条件3进行组合得到一个规则。也即是，该规则为：如果当前事件同时满足条件1和条件2或者当前事件只满足条件3，则均表明当前事件命中该规则。本申请实施例中的条件可以服务器直接在数据中心获取的，也可以是临时生成的。比如，由于条件是根据由指标、常量以及操作符的组合生成的，而指标根据字段生成的。可以临时确定出待生成的条件所需的字段、指标、常量以及操作符，组合出当前需要的条件。其中，条件的生成方式并不限于上述两种实现方式，在此不再一一赘述。步骤403：服务器根据一个或多个规则生成用于对第一事件进行风险评估的第一风评策略。在根据上述步骤402确定出第一事件对应的一个或者多个规则后，该服务器还需要根据该一个或者多个规则确定出该第一事件对应的第一风评策略，以便于直接根据该第一事件对应的风评策略对该第一事件进行风险评估。在一种可能的实现方式中，步骤403可能的实现过程为：确定多个规则中每个规则的风险基准分数。根据一个或多个规则中每个规则的风险基准分数生成第一风评策略。其中，每个规则的风险基准分数用于指示当第一事件满足相应规则时第一事件的风险大小。比如，步骤402确定出的规则分别为规则1和规则2。其中，该规则1对应的风险基准分数为60分。该规则2对应的风险基准分数为40分。如此，根据规则1和规则2的风险基准分数生成第一风评策略。也即是，当前用户只命中规则1时，该用户根据该第一风评策略确定出风险分数为60分。当前用户只命中规则2时，该用户根据该第一风评策略确定出风险分数为40分。当前用户同时命中规则1和规则2时，该用户根据该第一风评策略确定出风险分数为100分。当前用户没有命中规则1也没有命中规则2时，该用户根据该第一风评策略确定出风险分数为0分。进一步的，为了避免风评策略容易被黑客攻击，在另一种可能的实现方式中，步骤403可能的实现过程为：确定多个规则中每个规则的风险基准分数以及每个规则的灰度值。根据一个或多个规则中每个规则的风险基准分数、以及每个规则的灰度值，生成第一风评策略。其中，每个规则的灰度值用于指示当第一事件满足相应规则时需要根据相应规则对第一事件进行风险评估的概率值。该灰度值可以为服务器默认设置的。也即是，对于任一规则，当某个事件命中该规则时，服务器可以根据该规则对应的灰度值以及参考概率的大小关系确定出在根据第一风评策略对第一事件进行风险评估时，是否考虑该规则对应的风险基准分数。需要说明的是，服务器预先生成一个参考概率值。对于任一规则，如果参考概率大于该规则的灰度值，则根据第一风评策略对第一事件进行风险评估时，考虑该该规则对应的风险基准分数，也即是此时该规则对应的风险基准分数仍为该规则原来的风险基准分数。如果参考概率大于该规则的灰度值，则根据第一风评策略对第一事件进行风险评估时，不考虑该规则的风险基准分数，也即是此时该规则的对应的风险基准分数为0分。其中，该参考概率值为0％～100％的随机概率值。比如，确定出当前用户同时命中规则1和规则2。规则1对应的风险基准分数为60分，灰度值为50％。规则2对应的风险基准分数为40分，灰度值为40％。如此，根据规则1的风险基准分数和灰度值，以及规则2的风险基准分数灰度值，生成第一风评策略。假设，该参考概率为45％。对于规则1来说，由于规则1的灰度值为50％，该灰度值大于参考概率，则规则1的基准风险分数为60分。对于规则2来说，由于规则2的灰度值为40％，该灰度值小于该参考概率，则规则2的风险基准分数为0分。也即是综合规则1的风险基准分数和规则2的风险基准分数，确定出根据第一风评策略对第一事件进行风险评估时，该第一风评的风险分数为60分。为了进一步说明本申请实施例提供的确定风评策略的方法，以图5所示的流程图进一步进行说明。如图5所示，首先服务器接收一个事件风评请求，同时获取该事件的事件标识，同时在业务层构建的上下文中找到该事件标识对应的属性值，再根据该事件标识以及第二映射关系，确定出与该事件一一对应的策略标识。进而根据该策略标识确定出与该策略标识对应的多个规则。并调用规则执行引擎以确定出该多个规则中当前用户可以命中的规则，并根据当前用户可以命中的规则计算出风险分数，并将该风险分数返回给服务器的业务层。服务器再根据该风险分数确定出执行决定。将该执行决定发送至用户端，用户端根据该执行决定确定出的是否继续执行该事件。该风险分数用于表征根据第一事件对应的风评策略对第一事件的风险系数进行评估的结果。另外，服务器根据上述过程为第一事件配置风评策略后，在一种可能的场景下，为了满足新的风险控制要求时，服务器需要对已设置的对风评策略进行修改。一种可能的修改风评策略的过程为：获取策略修改请求，策略修改请求携带用于指示第二风评策略的策略标识，根据策略修改请求中携带的策略标识获取第二风评策略包括的一个或多个规则。当检测到针对第二风评策略包括的一个或多个规则中的第一规则的修改请求时，对第一规则进行修改，第一规则为第二风评策略包括的一个或多个规则中一个规则。将第一规则替换为修改后的规则。其中，第二风评策略为当前时间之前已经配置的风评策略。比如，服务器获取策略修改请求，该策略修改请求携带第二风评策略的标识01，该第二风评策略包括的规则1和规则2，并且服务器检测规则到规则修改请求，该规则修改请求用于指示对规则1进行修改，则直接通过本申请实施例提供的索引库，确定出规则1对应的规则在内存中的位置，将规则1进行修改，则修改后的规则会同步更新到“生成树”以形成新的风评策略。在本申请实施例中，通过根据待评估的第一事件的事件标识，获取一个或多个规则标识；获取与一个或多个规则标识一一对应的一个或多个规则；根据一个或多个规则生成用于对第一事件进行风险评估的第一风评策略。本申请通过多个规则来动态生成风评策略，而不是预先生成整个风评策略，因此，后续可以只对其中的一个规则进行调整，以实现对最终生成的风评策略的调整，避免了需要从头修改整个风评策略，从而大大降低了修改风评策略所产生的人力成本以及时间成本。上述所有可选技术方案，均可按照任意结合形成本申请的可选实施例，本申请实施例对此不再一一赘述。图6是本申请实施例提供的一种确定风评策略的装置的结构示意图，该确定风评策略的装置可以由软件、硬件或者两者的结合实现。该确定风评策略的装置可以包括：第一获取模块601，用于根据待评估的第一事件的事件标识，获取一个或多个规则标识，每个规则标识用于指示一个规则，规则用于判断第一事件是否为风险事件；第二获取模块602，用于获取与一个或多个规则标识一一对应的一个或多个规则；生成模块603，用于根据一个或多个规则生成用于对第一事件进行风险评估的第一风评策略，第一风评策略包括一个或多个规则、以及每个规则的风险基准分数，每个规则的风险基准分数用于指示当第一事件满足相应规则时第一事件的风险大小。可选的，第二获取模块，包括：第一获取子模块，用于对于一个或多个规则标识中任一规则标识，根据规则标识，从第一映射关系中获取与规则标识对应的一个或多个条件标识，第一映射关系包括多个规则标识和每个规则标识对应的一个或多个条件标识；第二获取子模块，用于根据一个或多个条件标识获取一个或多个条件；第一生成子模块，用于根据一个或多个条件生成与规则标识对应的规则。可选的，生成模块包括：确定子模块，用于确定多个规则中每个规则的风险基准分数，每个规则的风险基准分数用于指示相应规则对应的风险的大小；第二生成子模块，用于根据一个或多个规则中每个规则的风险基准分数生成第一风评策略。可选的，生成子模块，包括：确定单元，用于确定每个规则的灰度值，每个规则的灰度值用于指示当第一事件满足相应规则时需要根据相应规则对第一事件进行风险评估的概率；生成单元，用于根据一个或多个规则中每个规则的风险基准分数以及每个规则的灰度值，生成第一风评策略。可选的，第一获取模块，包括：第三获取子模块，用于从第二映射关系中获取与第一事件的事件标识对应的第一策略标识，第一策略标识用于指示第一风评策略，第二映射关系包括多个事件标识和与多个事件标识一一对应的多个策略标识；第四获取子模块，用于根据第一策略标识，从第三映射关系中获取与第一策略标识对应的一个或多个规则标识，第三映射关系包括多个策略标识和每个策略标识对应的一个或多个规则标识。可选的，装置还包括：第三获取模块，用于获取策略修改请求，策略修改请求携带用于指示第二风评策略的策略标识，第二风评策略为当前时间之前已经配置的风评策略；第四获取模块，用于根据策略修改请求中携带的策略标识获取第二风评策略包括的一个或多个规则；修改模块，用于当检测到针对第二风评策略包括的一个或多个规则中的第一规则的修改请求时，对第一规则进行修改，第一规则为第二风评策略包括的一个或多个规则中一个规则；替换模块，用于将第一规则替换为修改后的规则。在本申请实施例中，在本申请实施例中，通过根据待评估的第一事件的事件标识，获取一个或多个规则标识；获取与一个或多个规则标识一一对应的一个或多个规则；根据一个或多个规则生成用于对第一事件进行风险评估的第一风评策略。本申请通过多个规则来动态生成风评策略，而不是预先生成整个风评策略，因此，后续可以只对其中的一个规则进行调整，以实现对最终生成的风评策略的调整，避免了需要从头修改整个风评策略，从而大大降低了修改风评策略所产生的人力成本以及时间成本。需要说明的是：上述实施例提供的确定风评策略的装置在确定风评策略时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的确定风评策略的装置与确定风评策略的方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。图7是本申请实施例提供的一种确定风评策略的装置的服务器结构示意图。该服务器可以是后台服务器集群中的服务器。具体来讲：服务器700包括中央处理单元(cpu)701、包括随机存取存储器(ram)702和只读存储器(rom)703的系统存储器704，以及连接系统存储器704和中央处理单元701的系统总线705。服务器700还包括帮助计算机内的各个器件之间传输信息的基本输入/输出系统(i/o系统)706，和用于存储操作系统713、应用程序714和其他程序模块715的大容量存储设备707。基本输入/输出系统706包括有用于显示信息的显示器708和用于用户输入信息的诸如鼠标、键盘之类的输入设备709。其中显示器708和输入设备709都通过连接到系统总线705的输入输出控制器710连接到中央处理单元701。基本输入/输出系统706还可以包括输入输出控制器710以用于接收和处理来自键盘、鼠标、或电子触控笔等多个其他设备的输入。类似地，输入输出控制器710还提供输出到显示屏、打印机或其他类型的输出设备。大容量存储设备707通过连接到系统总线705的大容量存储控制器(未示出)连接到中央处理单元701。大容量存储设备707及其相关联的计算机可读介质为服务器700提供非易失性存储。也就是说，大容量存储设备707可以包括诸如硬盘或者cd-rom驱动器之类的计算机可读介质(未示出)。不失一般性，计算机可读介质可以包括计算机存储介质和通信介质。计算机存储介质包括以用于存储诸如计算机可读指令、数据结构、程序模块或其他数据等信息的任何方法或技术实现的易失性和非易失性、可移动和不可移动介质。计算机存储介质包括ram、rom、eprom、eeprom、闪存或其他固态存储其技术，cd-rom、dvd或其他光学存储、磁带盒、磁带、磁盘存储或其他磁性存储设备。当然，本领域技术人员可知计算机存储介质不局限于上述几种。上述的系统存储器704和大容量存储设备707可以统称为存储器。根据本申请的各种实施例，服务器700还可以通过诸如因特网等网络连接到网络上的远程计算机运行。也即服务器700可以通过连接在系统总线705上的网络接口单元711连接到网络712，或者说，也可以使用网络接口单元711来连接到其他类型的网络或远程计算机系统(未示出)。上述存储器还包括一个或者一个以上的程序，一个或者一个以上程序存储于存储器中，被配置由cpu执行。所述一个或者一个以上程序包含用于进行本申请实施例提供的如下所述的确定风评策略的方法的指令。本申请实施例还提供了一种非临时性计算机可读存储介质，当所述存储介质中的指令由服务器的处理器执行时，使得服务器能够执行上述实施例提供的确定风评策略的方法。本申请实施例还提供了一种包含指令的计算机程序产品，当其在服务器上运行时，使得服务器执行上述实施例提供的确定风评策略的方法。本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。以上所述仅为本申请的较佳实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。当前第1页12