Analyse des données: processus d'évaluation quantitative dans des scénarios commerciaux complexes

Code source de cet article: GitHub · cliquez ici || GitEE · cliquez ici

1. Pensée quantitative

Il existe de nombreuses entreprises complexes dans le système de programmation qui sont difficiles à comprendre, mais une analyse quantitative est nécessaire pour donner au personnel ou aux opérations ou aux utilisateurs de l'entreprise une norme de référence, telle qu'un indice commun, un score de sésame, un niveau de magasin, de telles normes d'évaluation d'entreprise Très compliqué , car de nombreux facteurs affectent les résultats.

Dans le modèle de prise en compte commerciale multidimensionnelle, il existe un concept de base appelé poids, qui fait référence à l'importance d'un certain facteur ou indicateur par rapport à une certaine chose. Il diffère de la proportion générale et ne reflète pas seulement l'importance de un certain facteur ou indicateur: le pourcentage qui met l'accent sur l'importance relative des facteurs ou des indicateurs et qui tend à y contribuer ou à avoir de l'importance. Dans des circonstances normales, le poids de chaque dimension est compris entre 0 et 1 et la somme des poids de toutes les dimensions est de 1.

Le concept de poids peut être analysé à partir d'un cas pratique. Par exemple, pour déterminer si un client est un objet d'opération clé, il est généralement considéré en termes de nombre de connexions par semaine, de durée en ligne, de volume de transactions, etc. A se connecte fréquemment, mais n'a pas de transactions commerciales principales, le client B se connecte rarement, mais les transactions commerciales sont élevées, de sorte que le poids du nombre de connexions ici doit être inférieur à la dimension du volume des transactions.

Comment déterminer la proportion de poids a généralement deux idées. L'une consiste à tirer les leçons de l'expérience fournie par le personnel professionnel de l'entreprise et à l'intégrer à l'entreprise pour essayer en permanence d'optimiser; d'autre part, de calculer le poids de chaque dimension en fonction des données d'analyse. du produit, il doit également être constamment essayé dans l'optimisation de l'entreprise.

En fait, le processus de quantification de scénarios commerciaux complexes est compliqué et long. Il est nécessaire de collecter des données dans plusieurs dimensions. Parfois, non seulement une quantification périodique est requise, comme les notes de crédit de plusieurs grandes usines, mais il peut également y avoir Scénarios d'analyse en temps Pour le contrôle du risque de fraude dans les activités financières, il existe également deux scénarios de systèmes complets de recommandation en temps réel, tous deux utilisant des processus quantitatifs.

Deux, cas de scène

1. Évaluation complète

Évaluation complète de plusieurs scénarios tels que les utilisateurs, les magasins, les produits et l'analyse abstraite d'une chose complexe à travers plusieurs dimensions pour générer des résultats d'évaluation simples et faciles à comprendre, tels que le niveau du magasin, l'évaluation du produit, l'index complet de l'utilisateur, etc., puis utilisez chacun La base de la référence de génération de scène. Cela peut être facile à comprendre à partir des résultats, mais le processus d’analyse pour obtenir les résultats est relativement compliqué. Certains scénarios peuvent exiger l’exécution périodique du modèle d’évaluation, certains scénarios peuvent exiger des calculs en temps réel ou une combinaison des deux situations. L'évaluation périodique doit également faire référence à des calculs en temps réel.

2. Recommandation de scène

Ce scénario est relativement complexe. Par exemple, l'utilisateur effectue une recherche, mais une série d'exclusions ou de conditions nécessaires est vérifiée. Ceci est très courant dans les fonctions de recherche. Lors du traitement, il n'est pas seulement nécessaire d'effectuer l'analyse de correspondance la plus élevée sur le les conditions de recherche de l'utilisateur., Et effectuez le classement optimal en fonction des résultats de la recherche. Il y a deux étapes d'évaluation. La première étape correspond aux conditions de recherche optimales et la deuxième étape effectue le classement le plus optimal des résultats correspondants pour donner à l'utilisateur ce que l'utilisateur veut des résultats de recherche.

3. Score de contrôle des risques

Dans le domaine financier, il s'agit d'un modèle de contrôle des risques très courant qui compte les utilisateurs dans plusieurs dimensions, note les dimensions, puis les additionne. Plus le score de contrôle des risques est élevé, plus le risque de l'utilisateur est élevé, évitant ainsi les risques élevés. transactions.

4. Indice financier

Ce scénario est très courant. Dans les applications de gestion financière et de patrimoine, un système d'évaluation doit être passé avant utilisation pour déterminer la tolérance au risque de l'utilisateur: par exemple, conservateur, actif, etc., lorsque l'utilisateur achète un produit à haut risque, il s'affiche et La tolérance au risque de l'utilisateur ne correspond pas, et l'utilisateur est invité à réévaluer.

Troisièmement, réalisation d'idées

1. Tableau des règles de dimension

Gérez une table de règles d'évaluation dimensionnelle, classify_sign est compris comme un identifiant de division dans le même scénario métier et le poids identifie la proportion de la dimension dans l'évaluation.

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. Décrivez les règles

Pour la description spécifique de la règle, le noyau est constitué de deux champs, la valeur de la règle et le résultat obtenu en faisant correspondre la règle.

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

3. Valeur de correspondance du package

Afin de simplifier la complexité de la transmission des paramètres dans le modèle, les données des facteurs d'appariement sont uniformément encapsulées dans un modèle de données. Ici, les deux facteurs de ville et d'étiquette sont utilisés pour les tests de processus.

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

4. Mise en œuvre de la logique d'évaluation

Voici une simple description de mise en œuvre pour les deux situations: dans le scénario de développement réel, les données et les spécifications correspondantes sont très complexes et l'ensemble du processus de mise en œuvre du modèle d'évaluation doit être optimisé en permanence.

@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 ;
            }
        }
    }

}

Quatrièmement, l'adresse du code source

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

Lecture recommandée: système de programmation de finition

Numéro de série	nom du projet	Adresse GitHub	Adresse GitEE	conseillé
01	Java décrit des modèles de conception, des algorithmes et des structures de données	GitHub · cliquez ici	GitEE · Cliquez ici	☆☆☆☆☆
02	Fondation Java, accès concurrentiel, orienté objet, développement Web	GitHub · cliquez ici	GitEE · Cliquez ici	☆☆☆☆
03	Explication détaillée du cas des composants de base du microservice SpringCloud	GitHub · cliquez ici	GitEE · Cliquez ici	☆☆☆
04	Cas complet du combat réel de l'architecture de microservice SpringCloud	GitHub · cliquez ici	GitEE · Cliquez ici	☆☆☆☆☆
05	Premiers pas avec l'application de base du framework SpringBoot à avancé	GitHub · cliquez ici	GitEE · Cliquez ici	☆☆☆☆
06	Le framework SpringBoot intègre et développe un middleware commun	GitHub · cliquez ici	GitEE · Cliquez ici	☆☆☆☆☆
07	Cas de base de la gestion des données, de la distribution, de la conception d'architecture	GitHub · cliquez ici	GitEE · Cliquez ici	☆☆☆☆☆
08	Série Big Data, stockage, composants, informatique et autres frameworks	GitHub · cliquez ici	GitEE · Cliquez ici	☆☆☆☆☆