严选风控进阶之路-吹尽狂沙始到金

  逝者如斯，风控进阶之途期年已至，回首风控构建之路犹在昨日，而垂髫之童稚，渐已长成及冠之少年矣。途中经历之种种，权记与此，以饷同好，只可概其要，不能陈其细，还望各位海涵。 构建完成之初，其规模篇秩如下：   观彼时所言：
其一，风控之业务与日俱增！不囿于订单、积分之长期业务，亦有抽奖、营销之短期活动；不限于严选，更旁及有钱、邮箱等产品。
其二，刷子之脑洞与时俱进！随业务形态之千变万化，刷子面目亦奇巧精怪。而今有专业的算法、数据分析团队，索其蛛丝马迹，标其善恶美丑。
除此之外，风控系统自求鼎革，浴火以重生，脱胎以换骨，聊举数例：

薄框架以求部署之简

  原风控平台分平台层与代理层，期代理层之灵动，平台层之稳定。然实践之时，版本频更，平台难以得其定；规则佶屈，代理难以成其动。故化繁为简，合代理与平台而为一，得部署之简便。而代理之灵动，则由规则配置框架取而代之。

建变量以求对接之便

  纳业务传参于变量平台，规则配置之时，只需简单勾选操作即可。 如图所示，所有变量均在变量平台进行管理。（在此之前，均在wiki中维护，变量使用时，需要人工检索）

  另对模型输出之标签，融入变量平台之内，与业务传参一统。标签者，画其像，肖其形，机器学习模型建设之果，而业务识别之本也。

变规则以求响应之速

  原规则引擎，仅支持简单频率规则配置。为引入机器学习，全倚Groovy脚本之灵活，而赖开发之辛劳，又有如衣棉絮行于荆棘之中，步步维艰。因而建规则配置框架，丰条件变量，简规则配置，便产品操作。 上图为配置框架的页面，而原始内容则如下图：（配置框架搭建之前，皆由人肉编写）

另合多阶段规则为统一规则链，兼容线上仿真，多规则并驾而行，得运维之便，达运行之速。 如上图，更新前，规则所处阶段固化，无法动态调整。而线上回归独立在此规则链外，单独维护。

如上图，更新后，所有规则统一管理，通过调整优先级来控制执行时机。另通过增加规则回归标示，对规则进行线上实时验证。

增模型以求识别之准

  组建专业之机器学习团队，取大数据平台之利，做多维度、长链路分析，出多类型、高精度模型，供业务规则以为用。而机器学习结果与风控平台对接之法：一者，以JAR包提供实时接口访问计算风险；再者，模型计算嵌入用户操作的各个阶段，结果统一以标签方式，存入标签库。
  目前已经训练上线了20多个模型，用到的算法也包罗了逻辑回归、随机森林、SVM、GDBT、LSTM、TextCNN、Bert、图计算、社区发现等！

聚数据以求证据之全

  原有订单等业务数据存储有猛犸，Hbase，redis等，数据分散，且常有缺失，不便证据检索，不便人工判别，因此将各方业务数据均实时汇总流入到ES，统一存储，并利用ES检索之特性，快速支持产品多维度检索之需要，目前已支持有近三十个参数的检索排序等。

理平台以求产品之美

  已有前端展示完全由开发设计，面向开发操作，缺少易用性，美观性等思考。因此对展示的内容进行梳理分类：删除过期操作，合并重复逻辑，分拆必要功能。

  千淘万漉虽辛苦，吹尽狂沙始到金！风控平台一直在业务的锤炼下砥砺前行，我们仍然在进阶的路上！