摘要
美团App每天都面临着各类的欺诈、盗号、作弊、套现以及营销活动被恶意刷单、恶意抢占资源等风险。而业务安全团队采用的主要措施和手段就是在业务请求中识别出谁、在什么时间、通过什么方式、做了什么事。这个识别逻辑的制定过程叫做策略的生产。同时，还要对已经完成生产的策略进行快速的验证和落地，以防止风险变化后策略失效。从发现风险经过策略生产、验证，再到最终的落地部署，全流程的处理速度和效果将决定整个业务的成败。
在业务发展初期，我们可以通过硬编码的方式将风控逻辑部署在业务逻辑中实现，但美团的业务比较复杂，从最初的团购形式，经过与大众点评、摩拜、猫眼等业务的融合，发展到涵盖餐饮、到店、猫眼、外卖、金融、酒店、旅游、大交通等多个垂直领域。随着业务的快速发展，适用于初期的硬编码方式出现了策略分散无法管理、逻辑同业务强耦合、策略更新迭代率受限于开发、对接成本高等多种问题。此时，我们需要有一套可配置化的规则管理平台，进而实现风控策略与业务解耦、快速部署、验证。
但规则引擎的建设初期，会面临着各种困难和挑战，主要包括以下几个方面：
- 在业务层面：垂直领域多，包含几乎所有的吃喝玩乐服务。美团细分业务多达百个。服务用户角色多（用户、商户、供应商、渠道商），交易频率高，日订单量大。
- 在风险层面：存在用户作弊、商家刷单、账号盗用冒用、支付和信贷等多种风险。
- 在企业外部环境层面：黑产已形成自下而上的产业链，攻击方式升级比较快速。
针对以上这些挑战，我们打造了自有的规则引擎 Zeus（中文"宙斯"，来源于"宙斯盾"作战系统的启发，期望规则引擎平台能同"宙斯盾"一样成为先进的中央作战决策系统，实现对风险的精准、高效打击）。
下面，我们就来具体介绍一下，美团信息安全团队在系统构建过程中面临的挑战以及对应的解决方案。
1. 美团风控场景
美团最初以团购的形式出现，到现在有了很大的业务形态转变。尤其是经过与大众点评的业务融合，从单一业务发展成了覆盖到店餐饮、到店综合、猫眼、外卖、酒店、旅游等多个垂直领域的综合性电商，并且在各个领域都处于行业领先的地位。在这背后，美团点评不仅面临激烈的行业竞争，还有黑色产业（以下简称"黑产"）带来的各种风险，因为我们的业务有这样一些特点：
- 品类多、覆盖面广：包括几乎所有吃喝玩乐服务，其中不乏容易被销赃的品类。
- 用户多、商户多：美团点评拥有6亿以上用户，400万以上合作商家，覆盖了很大部分国内网民和商户。
- 交易高频：每日订单峰值突破千万。
美团点评对黑产有着巨大的吸引力，归纳起来在这些方面尤其突出：
- 用户作弊：大家常说的"薅羊毛"，用户为了骗取促销优惠的作弊行为。
- 商家刷单：常见的有刷排名、刷销量、刷好评等违反商家平台协议的行为。
- 账户和支付安全：公民信息盗用形势已经十分严峻，黑产从业者会在电商平台上盗取用户的余额，或使用他人支付信息来消费。
这些行为严重侵害平台用户和商户的利益、扰乱正常交易秩序，处理结果的好坏将决定整个业务的成败。所以美团点评需要一套灵活高效的风险控制系统和工作机制来防控这些风险。
归纳一下，风控系统面临的挑战有：
- 业务多、风险点多：上面提到的风险涉及到各个业务的购买流程、用户操作、商家操作等多个场景。
- 变化快：黑产的攻击手段升级，自身业务在变化，互联网环境也会不断变化。
- 我在明、敌在暗：平台在明处，但攻击者是谁、会在什么时候出现、用什么方式进攻却无法预知。
接下来就以风控面临的这几个挑战为出发点，介绍我们在系统构建中所取得的经验。
1.1. 风控挑战一：业务多，风险点多
回到风控工作的起点，在了解业务所面临的风险类别后，首先要面对的问题就是：怎样才能知道有风险，并且能够控制风险？我们很容易想到，为了做到这些必须与业务系统对接，这部分系统我们称之为"对接系统"，它的目标抽象来说就是：感知风险 和控制风险。
"感知风险 "是指要收集尽可能完整的数据。风控需要关注：谁、在什么时候、通过什么方式、对什么对象、做了什么？这句话抽象概括了要感知的内容，绝大多数信息都可以套用到这句话。
第二个目标是"控制风险"。如果仅仅站在防守方的角度看，并不容易知道应该控制哪里；我们应该站在攻击者的角度思考：攻击者关注什么？答案是利益。以美团点评为例，可带来的利益有：
- 促销优惠：相关的风险场景有下单、支付、购买、验券等。
- 商家销量和排名等：涉及购买、搜索、销量展示等页面。
- 用户余额：即需要控制登录、查看余额等动作。
以这样的角度排查，就不容易漏掉风险点。排查清风险点后，实际对接工作也有很大挑战：美团点评的细分业务有100多个，很多业务都有多种用户终端（iPhone, Android，H5，PC等）、多个业务后台（促销工具，商家后台等），需要对接的场景数量很多。所以感知风险、控制风险背后最大的挑战是如何与业务方紧密配合顺利对接。
在配合中，业务团队常顾虑因风控需求拖慢业务开发速度，而风控也常感到业务团队配合不足。在配合的问题上，应该先充分认识两个团队合作的目的，就好像生产汽车和生产安全气囊，安全气囊在大多数国家已经是汽车生产销售的必须要求；同理，在现今互联网服务中，安全配备也已经成为了用户体验、业务需求的一部分，一个忽略安全的产品，终究会被市场淘汰。另一方面对风控而言，业务发展是风控存在的前提，如果风控的安全需求影响到业务发展也是不合理的，因此风控要提高服务质量，让对接带来的负担降到最低------这就是对接系统设计的核心目标。
总结一下，风控工作经验一：安全是业务的必要属性，没有安全保障的产品，终究会被市场淘汰； 风险控制要服务于业务，减少业务对接负担。 具体而言，业务接入风控的成本主要有接入成本 和运行成本两方面。下面分别来看我们在风控系统构建中的做法。
1.1.1. 接入成本
风控系统最早只是业务系统中的一个函数，逐步演化成了独立的服务。而这个独立服务与业务后台的交互最初时也沿用了旧的思路，即业务后台在关键动作前调用风控服务判断"有没有风险"。但这样每次新增加一个业务或新出现一个风险场景时，风控和业务都要重新对接联调。这样频繁地调整给上下游团队都带来了不小的负担，在频繁的更改中系统质量也难以保证。
换个角度看，其实还有更好的交互方式：当风控要保证账户操作环节的安全，可以让用户中心直接与风控系统对接。即业务系统调用用户中心，用户中心再调用风控透传风控所需参数，而风控的决策也通过用户中心返回给业务后台。这样的好处是只需要用户中心与风控对接一次，业务系统甚至不需要明显感知到风控的存在。同样的道理，与商户中心、支付环节的交互也可以采取类似的设计方法。这样的改造相当于把风险控制的"责任"从业务方移交给了中间件，即由中间件来保证提供安全的服务。这样理顺系统模块间的关系，从而降低整体开发成本。
1.1.2. 运行成本
业务接入风控系统后，尤其关心运行过程中的是否会有问题。风控系统要尤其关注以下这些方面：
- 服务稳定性
-
- 隔离部署：在对接的众多后台服务流程中，哪些是核心流程、哪些是非核心流程，需要隔离开防止相互影响。
- 依赖降级：风控策略需要实时依赖大量外部数据接口和存储，依赖越多稳定性问题发生的概率越大，相应的熔断、降级机制不可缺少。
- 限流防刷：业务尤其是高风险业务随时可能因爬虫、恶意攻击而造成流量突增。系统需要具备识别和拒绝这些恶意流量的能力，而不是放任其消耗业务后台和风控系统的计算资源。为了做到这一点，风控系统不应仅位于业务系统的调用下游，而要在全局流量入口处插入反爬防刷模块来实现整体控制。
- 服务性能
-
- 风控与业务对接可以大致分为两类： ① 同步控制接口，返回风控决策并由上游实时处理。 ② 异步信息收集接口，主要目的是收集数据提供风控决策依据。异步接口可以显著减少上游服务的阻塞时间。
- 最初风控策略硬编码在代码中，对运行过程的优化也以人为调整代码为主，但策略调整频繁，运行优化无法跟上策略调整，而且策略复杂度提高后，人为优化代码也不再现实，因此需要在运行时动态决定运行策略才能达到最好的优化效果。这点通过规则平台来完成，将在后文中"规则平台"中介绍。
- 风控运营
-
- 风控策略不可能做到完全精确，为了降低业务损失很多情况下要以牺牲一部分用户体验为代价，因此完善的用户运营保障不可或缺。这在后文的"运营系统"中会提到。
1.2. 风控挑战二：变化快
具备感知风险和控制风险的能力后，实现风控策略 就是第二个关键问题。最初的策略可以很简单，比如此时我们认定："穿黑衣服的是坏人"。类似策略运行一段时间后会出现有意思的现象："坏人会逐渐换上其他颜色衣服"。这也很好理解，攻击者不会持续做无效的攻击浪费资源，而是会转向其他进攻手段。这样旧策略反而只会影响到一部分正常用户------观察到的结果是策略准确率下降。这样的情况无法避免，因为------风控工作经验二： 风控是一项长期的对抗性工作。
那么我们首先要加强策略健壮性。还用上面的例子，攻击者很容易发现后台针对黑衣人的策略。但如果策略复杂一些，识别"穿黑衣服而且戴黑帽子的人"有问题，那么策略被暴露的概率就低了很多。但这会影响策略的覆盖面，所以需要更多的策略形成策略网共同作用。假设极端一点，把能想到的识别要素都用上，制定策略也就变成了模型训练问题，通过机器学习来制定策略会有更好的健壮性。不过这只是理想情况，现实并没有这么乐观。风控所面对的真实场景中正样本和负样本数量差距悬殊，而且攻击模式在持续变化，导致这并不是稳定的算法问题。所以实际工作中人工介入制定专家规则并与算法策略结合使用是更有效的方法。
涉及到长期对抗的工作，效率高低将是对抗效果的决定性因素。风控需要多种角色配合，典型如：开发者建设系统、策略制定者制定规则策略、产品角色把策略应用到合适的场景。让这些角色并行不悖就是工作的理想高效状态。"规则平台"就是我们用来达到这一状态的秘密武器。
1.2.1. 规则平台
为了解耦系统开发 和策略开发，需要让策略执行过程标准化。我们把策略划分成几个层次：
- 场景：对应规则集合，一个场景包含若干条规则。
- 规则：是最小的决策单元，一个规则包含多个因子。
- 因子：因子是组成规则的最小逻辑单元。
上下两层之间都是多对多的关系。这样划分后，所有策略都套用标准化的执行过程，并能达到最大程度的配置复用。此外还有一个好处，就是将策略配置从代码中抽离。旧的策略执行过程是用硬编码预先编写好，对执行过程代码调优十分复杂，即使调优也只能针对特定的策略配置。如果策略改变了，原来的优化可能就不再适用。通过配置执行策略后，执行过程也变成动态的。具体来说，运行时会根据请求来决定需要计算哪些场景、规则和因子，每个元素计算且仅计算一次，没有相互依赖的部分放入多个线程并行处理。通过这样的优化，效率和性能得到大幅度提高。
再看策略开发 和决策应用。最初实际工作中这两者耦合在一起不加区分，即针对特定场景开发特定策略。逐渐暴露出一些问题，比如场景会变化、会新增，那原有的策略是否还适用？一个策略是否只能使用固定的决策动作？为了让这两部分工作并行，需要从设计定位上就把两者区分开。即：
- 策略：是为了识别一些特定的问题，例如"是不是模拟器请求"，"该用户是不是新客"。
- 决策：是针对场景的应用，如拒绝、验证手机短信等。
规则平台设计让每个场景可以应用不同策略，命中策略后的决策也可以灵活定制，甚至可以配置多个决策，并设置不同优先级。
1.2.2. 验证中心
上文中的"决策"代表系统是否信任该请求，风控背后的工作也围绕这个"信任"而展开。拒绝不信任的，放行信任的。但还有不少情况是中间不足以确定的部分，常见的处理方法是需要让用户补充验证信息来辅助判断。最初实现的验证流程是：风控服务识别风险后返回决策给业务系统，由业务系统实现验证的完整交互过程。这样存在两个问题：
- 首先业务方很多，不同的业务需要重复实现验证流程，造成重复开发。
- 其次验证种类有很多，从较弱可信度的短信验证，到较高可信度的银行卡验证等------风控能返回什么样的决策受限于特定场景业务方的实现了什么验证支持。
这些问题对于业务和风控系统造成了不小麻烦。所以我们需要优化这一过程，让验证过程由一个独立的服务------验证中心来完成。业务系统从风控服务获得风险决策，再与验证中心交互完成验证。从风控的角度看，以前的处理方式称作"只管杀，不管埋"，优化后可以称之为"杀埋一条龙服务"。
除了规则平台、验证中心，我们还抽象出了累计服务、处罚中心、算法平台等服务来提升风控对抗效率。
1.3. 风控挑战三：我在明，敌在暗
风控与黑色产业的对抗有个天然的不利因素，就是风控团队需要防御所有短板，而对手只需要找到薄弱的环节进攻。面对进攻，我们可以建立相对完善的实时策略体系和工具系统，但如果仅寄希望于实时策略解决所有问题也是不现实的。即使策略再优，黑产、业务、环境都在变化，仍然可能留有漏洞，或者陷于疲于应付的境地。这样的现实需要风控团队视角更宽广一些------风控工作经验三：要从事中防守扩展到立体事前、事中、事后防御。
在风险事前，要注意提升防御能力，减少防御短板：
- 风险教育：在快速发展的业务中，风险控制的核心在于人，要将风险意识和基本概念传递到业务的各个阶段，明确告知风控可以提供的服务。
- 参与业务：参与到业务的产品流程中，了解高风险业务、活动的规则，预判风险并给予合适力度的干预。
- 数据准备：打通数据收集流程，制定预警规则、模型策略等。
- 主动防护：关注业界风险动态，发生行业安全事件后，或重大活动、产品改动上线前，制定有针对性的规则，甚至采取锁定高危账户、发送预警消息等措施。
在风险事后，要快速响应，灵活管控。客户投诉是风控了解策略效果的最重要指标之一。 针对风险场景，风控还要主动关注异常数据，实现"预警"监控。这些反馈都会进入运营工作流做处理。 运营工作流中，尽管各风控产品具体流程不同，都可以划分为初步受理、核查审理、案件处理三个步骤，对应着以下三个系统。
- 初步受理：主要用作初步筛选案件，决定是否需要进入下一步骤。其流程较为简单，系统的设计目标是让风控运营人员可以便捷的处理案件，因此处理效率是其中的重要衡量指标。
- 核查审理 ：用于详细核查案件，通常有多步骤流程，不同角色以其专业视角做判断。核查过程中需要大量数据支持和处理系统支持，因此有了运营支持系统。
- 案件处理：确认且涉及到资金损失的案件需要进入赔付流程。因为涉及到资金赔付，精确的权限管理是系统设计和实现时需要特别注意的问题。
运营平台的意义不仅在于处理案件本身，更在于将处理结果反馈到线上系统中实现风控线上和线下的运行闭环。除了运营平台，逆转信息劣势还要靠完善的数据体系的帮助。风险控制所使用的数据可以这样分类：
- 事件快照：原始而完整的信息，用于生成聚合数据，也是支持运营查询的主要数据源。
- 聚合事实：相比于原始的事件记录，更多使用场景更关心聚合的结果，例如某用户、某商家的历史购买次数。经过聚合整理后的数据，是进一步数据挖掘的基础。
- 衍生信息：指基于事件快照和聚合事实衍生出的理解信息，例如用户的作弊风险、设备的可信程度、黑白灰名单等。这些衍生信息可以适配到各个特定场景中使用。
- 基础数据：除了直接传递到风控的数据外，风控处理过程少不了需要业务甚至是外部的辅助信息。例如，业务相关订单和活动信息、公认的事实数据、外部辅助决策信息等。
2. 风控系统的全景
从上文三条风控工作原则可以看到，风控系统构建过程各个阶段的关注点从对接质量，到平台效率，再过渡到立体的闭环防御。但即使系统发展到了相对成熟的阶段，与黑产的斗争也远没有结束。为了更好的对抗，我们要从对手身上学习：
- 黑产链条经过长时间的实战优化，分工极为细致。风控团队也应该学习这样的思路，将服务功能切分到细粒度以更好适应变化。
- 黑产对利益极为敏感，甚至很多时候比业务开发者还要了解业务。风控团队只有比对手更了解"主场"------也就是自身业务，才有可能在对抗中取得主动。
如果把风险控制比喻成一场战争，还可以从军事理论中得到借鉴。《孙子兵法‧谋攻篇》中的一段描述就十分贴切："知可以战与不可以战者胜，识众寡之用者胜，上下同欲者胜，以虞待不虞者胜，将能而君不御者胜。此五者，知胜之道也。"类比到风控工作中，风控团队需要考量：
- 控制风险是否现实
- 团队人才质量和数量是否足够
- 团队价值观是否统一
- 对风险是否足够了解
- 是否得到上层支持
这五点就是风控工作的取胜之道啊。
3. 高效的规则引擎
3.1. 挑战与方案
3.1.1. 业务多-接入成本高
规则引擎最早只是业务系统中的一个函数，逐步演化成了独立的服务。而这个独立服务与业务后台的交互是单点方式，即业务后台在关键动作节点前调用规则引擎，判断"有没有风险"。但这样每次新增加一个业务或新出现一个风险场景时，规则引擎和业务都要重新进行对接联调。频繁地调整给上下游团队都带来了不小的负担，而且在频繁的更改中，系统质量也难以保证。如何便捷、快速地实现业务接入是系统设计的核心目标之一。
在接入成本上，一次性集中接入往往是最便捷的方式。因此我们选择在每个业务都会通用节点接入规则引擎，例如：用户中心、商户中心、订单中心、收银台等均为各类业务的通用节点，规则引擎同这些通用节点对接，业务在调用通用节点时，通用节点调用规则引擎即可完成业务的接入。
随着美团业务和场景种类的增多，现在也存在不经过通用节点的业务。因此，我们需要提供通用的接入接口，目前业务侧直接调用一个独立服务接口即可获得风控判断。
3.1.2. 风险点多-逻辑复杂、逻辑复用
风险点多且业务多，进一步增加了场景、策略逻辑的复杂度。表达式语言可支持的逻辑计算范围有限，复杂的逻辑若仍通过硬编码实现，会存在效率低、不易复用等问题。
受模块化思维启发，我们将复杂的逻辑封装成模版，实现配置化，并支持逻辑复用。这样就大大提升了规则引擎可实现的逻辑范围。目前，我们已经建设的几类常用的封装逻辑如下：
- 扩展函数：主要用于数据格式的提取和处理，比如字符串、数组等格式转换、数据提取等。通过扩展函数功能，对业务侧数据格式要求大大降低，也降低了业务侧数据处理的负担。
- 累计因子：在业务中会高频使用到与累计相关的逻辑。例如，在登陆、下单、支付等事件需要同IP的UserID进行计数计算，计算结果作为特征引用在规则中。规则引擎引入了内部研发的高效事件计数服务，实现累计通用逻辑的封装，比如支持累计周期、计数/求和/最近几次、累计值等计算逻辑配置化等等。
- 决策表因子：部分业务中需要引擎处理的判断条件较多，各条件又相互组合，存在多种决策方案的情况，这就需要用精确、简洁的方式来描述这类复杂逻辑。在低频使用时，我们可以通过硬编码的case-when、if-else等语句实现，但在实时性和配置化上不尽人意。最终，我们通过决策表将多个独立的条件和多个动作直接地联系、清晰地表示出来，并实现了逻辑的封装。
- 名单库因子：与名单库联动过程中，将查询名单的逻辑进行封装。
- 工具因子：将一堆规则进行打包形成大的逻辑集合，并对组成的规则设置评分。在执行时输出评分结果并实现跨场景、跨业务应用，同时将大逻辑进行"黑盒"处理，简化逻辑复用时的配置、沟通成本。
风险点多的另一个挑战点是在多业务中会存在同质性，即制定的风险策略是可复用的。当一百条规则需要复用在几十个场景中，逐个配置的效率太低，不仅一致性难以保障，后续的修改也是问题。同时又衍变出部分复用、部分差异化，让业务直接复用场景行不通。因此，我们引入【规则组】的概念，将规则聚类管理。比如众包识别规则组、虚假设备规则组、涉黄内容识别规则组等。业务在应用时，可在自己的场景中进行差异化的应用。
3.1.3. 风险变化快、长期对抗-效果验证速度
当外部风险变化时，风控的对抗也需要及时响应，这是一个争夺"主导权"的比赛。风控通过对不同阶段的组合打击，实现策略的健壮性，包括用于识别有没有风险的基础对抗阶段、引导节奏混淆视听的"短平快"阶段、诱敌深入的"高精尖"阶段。对应系统需要支持不同阶段的策略配置、迭代和验证需求。而在策略迭代和部署阶段，需要特别注意因配置错误导致的误命中问题。
参考开发环境分类：测试环境、预发布环境和生产环境。规则引擎在规则的部署和迭代上，可通过标记、双跑和回溯功能，我们通过应用实时线上流量和历史数据来验证策略的有效性。
- 标记：规则在场景中的状态，标记状态的规则逻辑将灰度执行，即：与生效规则类似会实时执行，但决策信息不实时返回给上游业务方，不影响决策。同时用户可在实时日志查询中查看标记规则的命中情况。
- 双跑：规则在场景中的状态，双跑状态的规则逻辑将灰度执行，但仅会出现在修改生效规则、因子（因子修改导致引用规则的逻辑执行变化）时，才会存在的状态。
- 回溯：规则在场景中的状态，回溯状态的规则逻辑将灰度执行，但仅使用回放的历史数据。
通过这些功能，可以降低策略迭代的风险，缩短策略部署上线的时间周期。
3.2. 思路总结
在确认清楚挑战和解决方案之后，规则引擎的整体建设思路就已经形成了。现今，规则引擎随着业务的快速扩张，由一个内部系统逐渐发展为服务多个风控团队的公共平台。
从初期主要围绕风控防控痛点进行搭建的表达式服务包，升级到配置化平台，在配置效率和执行效率也得到了很大的提升。同时，随着人工智能技术的应用和风控对抗进入白热化，规则引擎也将从配置化快速迭代至自动化、智能化。
3.2.1. 确定核心快速论证、快速落地
在系统建设中，进行了充分的论证后就需要快速落地，避免因长项目周期需求发生裂变而导致不可控。在初期，我们已经建立了aviator表达式服务包并稳定服务。因此，配置化平台搭建时仍基于表达式语言，引入场景、规则、因子、决策等概念搭建，将策略的执行分为执行层和计算层。
执行层：通过场景获得一堆规则集合，规则执行完成后将其结果和对应的决策返回。
结果和：在规则执行时会进行其构成因子计算。
3.2.2. 根据角色，进行定向提效
规则引擎搭建的初衷之一是提升风控对抗的整体效率。在对抗过程中，我们需要各种角色配合，例如开发建设系统、策略制定者、策略使用者和风险用户等，因此需要针对各类角色定向开展提效工作。
（1）风险用户处理提效（风险用户）
业务已经可以实时获得风控的决策，但发现风险用户会在很多场景下重复攻击。对这类用户的处理，除了对当次行为阻断，还要阻断其未来的行为，因此就有名单管理的诉求。我们通过与名单库的联动，提升该类用户的处理效率。
例如：在美团金融项目场景下，严重逾期的用户会加入禁贷名单，再次申贷时取消其贷款资格。
（2）业务接入提效（业务方）
除了上面介绍的统一接入外，还有一种常见的情况：业务无法在发起请求时就将执行所需要的全部参数准备好，此时就需要引擎能主动获取外部数据。针对这类情况，规则引擎通过数据接口的方式实现了外部数据的补充，在策略执行时根据计算需要动态获取相关的参数。在实现与外部数据联动的功能后，大大降低了使用规则引擎业务方数据准备阶段的压力，从全部参数准备简化为仅提供核心参数即可，剩余参数按需引擎自行调度即可。
（3）策略管理提效（产品）
策略产品是规则引擎的主要用户，主要的工作流程是围绕策略管理、分析、验证进行提效。如何管理大量的规则和应用场景？怎样快速验证策略有效性、评估误伤率？客诉反馈问题，如何快速还原规则命中情况？针对这些维度，我们分别提供不同的产品功能进行提效。
- 在策略管理层面，可通过规则组方式、因子工具等，进行同类规则集合的管理、打包和复用。
- 在规则分析层面，可通过实时查询规则的执行详细数据和将规则执行流程进行回放提升分析效率。
- 在策略验证层面，提供标记、双跑和回溯提升策略验证速度。
（4）工程效率提效（工程师）
复杂的逻辑且具有通用性就可以对特征逻辑封装，避免工程师重复进行逻辑开发工作，释放出的开发资源可以进行其它维度的提效。
（5）算法/模型接入提效（算法工程师）
当对抗升级时，策略的产生者由人变为算法/模型。而机器的生产效率远远高于人，人工搬运算法/模型会成为迭代效率的瓶颈，怎样跟算法、模型平台进行快速联动呢？最简单、快速的方式就是使用引擎提供的外部数据联动方式，将模型结果包装成数据接口使用。但在实践过程中，我们发现模型的出入参数较多且存在变化，整体的配置化效率低，模型应用和迭代频率受限制。公司内部提供的深度学习还是算法工程平台，目前主攻计算、训练等场景，在上下游应用提供标准化的数据产出，但无法同类似引擎的平台对接。
因此，仅聚焦在引擎与算法平台的联动上，可通过建设调度模块实现：1.训练样本预处理-->2.算法平台对接-->3.自动化生成接口-->4.自动注册接口/策略至引擎-->5.评估任务启动-->6.评估结果处理（策略上下线、样本数据沉淀）-->1.训练样本预处理的闭环流程。
3.2.3. 发现问题、横向扩展、兼容更多场景
随着引擎在多业务场景的应用，我们发现几个实时引擎不好处理的场景。比如拉新场景，需要结合"注册+登陆+交易"等多种行为来判断是否有"薅羊毛"等黑灰产行为，需要将很多事件放到一起去综合判定。当发现风险时，或在当前时间点漏过的变异风险在发现之后，需要对历史数据进行回捞，这些在实时引擎中都不太好实现。当前已有的异步引擎也无法很好地进行覆盖。为了避免做"重复造轮子"的事情，团队充分地讨论了实时、异步和离线引擎的定位和服务边界。
在实时引擎已经覆盖的逻辑基础上，我们引入新的封装逻辑-个体因子，全局因子实现SQL语句的配置化管理，进而实现批量累计、聚合特征的计算，比如：近一年某商家的平均下单金额，近30天商户大盘下单均值，标准差等批数据的复杂逻辑。并基于Spark和实时引擎底层，实现多流和批数据的处理，解决上述场景无法处理的一些问题。
3.2.4. 业务实践结果
交易安全
策略产品在日常工作中，通过对业务分析发现风险、挖掘风险特征并应用在策略中。通过Zeus实现策略的部署和应用，大大降低了业务风险，提升风险防控效率。例如：在某业务地推场景中发现B、C端联合刷单风险，以返利、送赠品收到诱骗下单。
金融安全
金融风控主要有反欺诈和信用安全。反欺诈同业务安全在策略形态上相同，都是判断有无风险，在决策结果上是通过和拒绝。因此，通过普通决策即可满足业务需求。
但信用安全会比前两者复杂一些，在决策上，除了通过和拒绝外，对于通过的请求要进行分层实现金融的差异化定价。因此，需要在规则引擎中引入更多功能，来满足业务需求。主要包括：
- 路由场景：可支持多层，决策流模式，即一堆规则的集合，支持按照逻辑进行分流，满足指定条件可以指定走向在每个节点进行条件设置，实现最终流向。例如：对于某分期场景用户申请一笔贷款，需要经过欺诈识别、信用评估后方可给出最终的额度、定价。
- 决策衍生参数：适用于复杂的多级路由决策场景Key-Value型数据，在决策中指定衍生参数信息从而在路由场景中产生全局传递变量，比如：流转过不同的场景需要将用户进行等级分类。
- 决策附加信息：适用于复杂决策场景Key-Value型数据，在决策中指定附加信息从而实现更多决策信息的计算及返回，比如：加入风控名单库，加入什么风险类型、风险等级、名单类型。
4. 未来发展与思考
目前规则引擎正处于配置化阶段，正在向自动化、智能化的阶段发展，从而不断提升策略的管理和迭代的速度。但业务间的智能化诉求和进程不同，平台可以提供更多集成托管服务，从而提升各业务的智能化覆盖度。
其次，引擎仍然存在无法处理的几个问题：
一些长时间周期特征无法快速应用的问题，例如近一年的时间周期。如何将离线引擎和实时引擎在特征计算上组合，实现特征的快速生产、验证和应用，从而扩展引擎的计算能力范围、提升风控业务的对抗效率。
当前引擎的接入对非复杂逻辑需求的业务就比较重。而接入成本是各业务接入时重点评估的因素，如何实现快速、低成本的业务接入（包括技术接入和人员操作接入），考虑提供模块化的引擎计算服务能力适用于各类业务诉求，实现按需接入，比较"臃肿"的全局接入会更快速和便捷。但这种在引擎侧怎样更好地管理这些模块，也是一个挑战。
最后，业务流量和策略的增长速度仍在高速增长，引擎的稳定性和策略管理效率也需要持续提升。
5. 美团在风控的思考
5.1. 如何实现产品功能高聚合架构上低耦合
规则引擎建设时兼容各类业务场景，具备了极高的灵活性，同时自身也相对复杂。从顶层的路由场景到底层的参数（路由场景-场景-规则组-规则-决策-因子-参数-数据接口-参数）每一个节点、节点间都是由用户配置的，在产品上期望用户的操作流程是连贯的，在一个操作流程中解决尽量多的问题。系统架构上，包括配置层、执行层、计算层、数据获取层等，各层之间相互依赖，对最终引擎的输出结果负责，底层上需要尽量的解耦合，才将降低单模块对引擎的影响。但在实践中，随着业务诉求的增多，慢慢就出现来产品上的低耦合、架构上的高耦合情况。
例如：在用户修改生产策略时的强制更新流程优化项目中 ，就涉及了这个问题。在产品功能上用户修改策略-->双版本策略并行执行-->两版本数据核验-->修改完成；但在系统架构上，上述的产品流程就产生了系统架构高耦合，即生产修改双版本问题，配置层、执行层、计算层高度耦合。项目一期上线后在性能上、后续功能扩展性上都有瓶颈。随后，技术项目优化配置层的缓存模式，采用增量更新方式。产品功能上增加用户进入修改模式后修改。重新立项后，实现了用户修改流程闭环、系统架构上仅配置层兼容双版本，执行层和计算层无耦合。
因此，在产品功能设计上除了用户闭环操作外，还需要考虑是否低耦合。在技术优化时需要前瞻性的开展去耦合项目。
5.2. 如何平衡系统复杂度与业务需求
随着接入业务的增多，又需要兼容新业务定制化需求，就面临这一个问题：定制化的功能不具有通用性，大量定制功能将加重平台的复杂度。这个问题一直困扰引擎建设团队。目前，我们采用的也许不是最优但比较有效的办法。主要通过定、判、看Gap，将业务需求转化为系统模块升级功能和非系统功能：
- 功：重新定义"定制和通用"。在现实中有些定制化需求其实是业务速度已经远远领先于其它业务，所有需求看上去是定制化，实际上是未来可预见性的问题。
- 未：将业务需求进行分类，判断需求是针对主干流程还是分支节点。
- 看Gap：需求同当前建设情况比对差距。
对于系统模块升级功能，可逐个完成。对于非系统功能，可通过提供公共对接服务的外挂来实现。
5.3. 特别需要"防呆"设计
人工操作会存在各类误操作引起的风险问题，在产品设计上，用户操作简洁的初衷是好的，但需要增加防止错误发生的限制方法。在实践中这些"防呆"设置大大降低了人工误操作Case，例如：
- 业务高峰期封版--->禁止业务高峰期时变更策略。
- 降低无逻辑验证的误伤情况-->策略上线前，强制标记验证执行是否符合业务预期；修改生产上应用的策略，强制双跑验证修改后的逻辑执行是否符合业务预期。
- 降低逻辑配置错误几率-->策略部署时强制测试逻辑正确性。
- 惯性操作-->验证数据结果强制回填等。
5.4. 产品功能最佳实践的意外惊喜
要承认一个事实就是，最了解功能使用的可能不是规则引擎的产品经理。在规则引擎的建设中出现了这样的"惊喜"，例如：
- 规则组功能建设初期目标是实现规则的高效管理、复用。在A业务场景基于规则组除实现规则的高效管理、复用外，还实现了决策计算。但这种用法在随着其业务的发展复杂度增加，已经不再利于策略高效管理，目前还在寻找更优的解决方案。
- 累计因子的功能是将对多条请求进行计数或求和逻辑进行封装。B业务基于上述功能上还是实现了事件行为记录、多事件时序性累计和拦截行为的累计。目前在其业务下广泛使用并有效地识别了跨事件风险。
总结而言，做好业务定期应用回访和应用监控是非常有必要的。