数据分析：复杂业务场景下，量化评估流程

• 2020 年 12 月 2 日
• 笔记
• 业务.架构.方案, 业务架构, 权重, 量化

本文源码：GitHub·点这里 || GitEE·点这里

一、量化思维

在编程体系中有很多复杂的业务是很难理解的，但是又需要做一个量化分析，给业务人员或者运营，或者用户一个参考标准，例如常见指数，芝麻分数，店铺等级，这类业务评定标准非常复杂，因为影响结果的因素很多。

在多个维度的业务考量模型中，有一个核心概念叫做权重，指某一因素或指标相对于某一事物的重要程度，其不同于一般的比重，体现的不仅仅是某一因素或指标所占的百分比，强调的是因素或指标的相对重要程度，倾向于贡献度或重要性。通常情况下每个维度的权重在0-1之间，所有维度的权重之和为1。

可以从一个实际案例来分析权重的概念，比如判断一个客户是否是重点运营的对象，通常会从每周登录次数，在线时长，交易量等维度考虑，如果客户A经常登录，但是没有核心业务交易，客户B很少登录，但是业务交易高，所以这里登录次数的权重就应该低于交易量这个维度。

如何确定权重占比，通常有两个思路，一借鉴专业业务人员的提供的经验，放到业务中不断尝试调优；二根据产品的分析数据，计算各个维度权重，也是需要在业务中不断尝试优化。

实际上复杂业务场景的量化过程是复杂且漫长的，需要对多个维度的数据做收集，有时候不但需要做周期性量化，例如几家大厂的信用分，也可能存在实时分析的场景，金融业务中的欺诈风控等，也有两种场景综合的实时推荐体系，都会用到量化流程。

二、场景案例

1、综合评估

对用户、店铺、产品等多种场景做综合评估，把一个复杂的事物通过多个维度抽象分析，生成简单容易理解的评估结果，例如店铺等级、产品评分、用户综合指数等，进而对各个使用场景产生参考的依据。从结果来看可能是很容易理解，但是获取结果的分析过程是相对复杂的，有的场景可能需要周期性执行评估模型，有的场景可能需要实时计算，还有可能是两种情况结合即依赖周期评估，也需要参考实时计算。

2、场景推荐

这个场景相对复杂度较高，例如用户进行搜索，但是又勾选一系列排除或者必要条件，这在搜索类的功能中很常见，在处理时不但要对用户的搜索条件做最高的匹配度分析，还要基于搜索结果做最优排序，这种就存在两个阶段评估，第一个阶段匹配最优搜索条件，第二阶段对匹配结果做最优选排序，最大可能的给出用户想要的搜索结果。

3、风控评分

在金融领域内，这是很常见的一种风控模型，即对用户多个维度统计，做维度评分然后累加到一起，风控分越高，说明该用户风险越大，进而阻止高风险交易。

4、理财指数

这个场景很常见，在金融理财类的APP中，使用之前必须经过一个测评体系，来判断用户的风险承受能力：例如保守型、积极型等，当用户购买的产品属于高风险时，会提示和用户的风险承受能力不匹配，提示用户重新测评。

三、实现思路

1、维度规则表

维护一份维度的评估规则表，classify_sign理解为同一业务场景下的划分标识，weight则标识该维度在评估中的比重。

CREATE TABLE `evaluate_rule` (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键ID',
  `classify_sign` varchar(50) COLLATE utf8mb4_unicode_ci DEFAULT '' COMMENT '归类标识',
  `rule_value` varchar(300) COLLATE utf8mb4_unicode_ci DEFAULT '' COMMENT '规则描述',
  `rule_type` int(1) DEFAULT NULL COMMENT '规则类型：1精准匹配，2范围，3模糊',
  `weight` decimal(10,2) DEFAULT '0.00' COMMENT '权重分布',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='评估项规则';

2、描述规则

对于规则的具体描述，核心就是两个字段，规则值以及匹配到该规则获取的结果。

public class RuleValue {
    /**
     * 规则值描述
     */
    private Object ruleValue ;
    /**
     * 规则匹配结果
     */
    private Object ruleResult ;
    // 基础构造
    public RuleValue(Object ruleValue, Object ruleResult) {
        this.ruleValue = ruleValue;
        this.ruleResult = ruleResult;
    }
    // 省略 Get 和 Set
}

3、封装匹配值

为了简化参数在模型中传递的复杂度，统一封装匹配因素的数据在一个数据模型中，这里以城市和标签两个因素做流程测试。

public class MatchItem {
    // 城市
    private String city ;
    // 标签
    private String tag ;
    // 基础构造
    public MatchItem(String city, String tag) {
        this.city = city;
        this.tag = tag;
    }
    // 省略 Get 和 Set
}

4、评估逻辑实现

这里只是对两种情况做简单的实现描述，在实际的开发场景中，数据和匹配规格都是十分复杂的，在整个评估模型实现流程需要不断优化。

@Service
public class AssessBizService {

    private static Logger LOG = LoggerFactory.getLogger(AssessBizService.class);

    @Resource
    private EvaluateRuleDao evaluateRuleDao ;

    /**
     * 业务评估流程
     */
    public void assessBiz (MatchItem matchItem){
        // 精准匹配城市
        EvaluateRuleEntity evaluateRule01 = evaluateRuleDao.getBySign("assess-biz",1);
        List<RuleValue> cityRuleList = JSONArray.parseArray(evaluateRule01.getRuleValue(), RuleValue.class);
        for (RuleValue cityRule:cityRuleList){
            if (cityRule.getRuleValue().equals(matchItem.getCity())){
                int result = Integer.parseInt(String.valueOf(cityRule.getRuleResult()));
                LOG.info("匹配项:{},匹配结果:{}",matchItem.getCity(),result*evaluateRule01.getWeight());
                break ;
            }
        }
        // 模糊匹配标签
        EvaluateRuleEntity evaluateRule02 = evaluateRuleDao.getBySign("assess-biz",3);
        List<RuleValue> tagRuleList = JSONArray.parseArray(evaluateRule02.getRuleValue(), RuleValue.class);
        for (RuleValue tagRule:tagRuleList){
            if (String.valueOf(tagRule.getRuleValue()).contains(matchItem.getTag())){
                int result = Integer.parseInt(String.valueOf(tagRule.getRuleResult()));
                LOG.info("匹配项:{},匹配结果:{}",matchItem.getTag(),result*evaluateRule02.getWeight());
                break ;
            }
        }
    }

}

四、源代码地址

GitHub·地址
//github.com/cicadasmile/data-manage-parent
GitEE·地址
//gitee.com/cicadasmile/data-manage-parent

推荐阅读：编程体系整理