資料分析：複雜業務場景下，量化評估流程

本文源碼： 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·位址
https://github.com/cicadasmile/data-manage-parent
GitEE·位址
https://gitee.com/cicadasmile/data-manage-parent