本文源碼：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);@Resourceprivate 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·點這里	☆☆☆☆☆

總結

以上是生活随笔為你收集整理的数据分析：复杂业务场景下，量化评估流程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。