本文原始碼: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
推薦閱讀:程式設計體系整理
序號 | 專案名稱 | GitHub地址 | GitEE地址 | 推薦指數 |
---|---|---|---|---|
01 | Java描述設計模式,演算法,資料結構 | GitHub·點這裡 | GitEE·點這裡 | ☆☆☆☆☆ |
02 | Java基礎、併發、物件導向、Web開發 | GitHub·點這裡 | GitEE·點這裡 | ☆☆☆☆ |
03 | SpringCloud微服務基礎元件案例詳解 | GitHub·點這裡 | GitEE·點這裡 | ☆☆☆ |
04 | SpringCloud微服務架構實戰綜合案例 | GitHub·點這裡 | GitEE·點這裡 | ☆☆☆☆☆ |
05 | SpringBoot框架基礎應用入門到進階 | GitHub·點這裡 | GitEE·點這裡 | ☆☆☆☆ |
06 | SpringBoot框架整合開發常用中介軟體 | GitHub·點這裡 | GitEE·點這裡 | ☆☆☆☆☆ |
07 | 資料管理、分散式、架構設計基礎案例 | GitHub·點這裡 | GitEE·點這裡 | ☆☆☆☆☆ |
08 | 大資料系列、儲存、元件、計算等框架 | GitHub·點這裡 | GitEE·點這裡 | ☆☆☆☆☆ |