AI智评平台用户等级提升：规则评分引擎设计与稳定期机制实践

简介面向需要提升华宸AI智评等级的开发团队或项目负责人这套可运行源码完整还原了客户评级从C提升至B的实施路径集中展示了技术改进、查重控制和时间规划等关键环节能够作为实际项目落地的直接参考。源码包整体为zip压缩格式解压后包含三个文件一个用于配置在线运行环境一个用于呈现方案说明与页面效果另一个辅助版本管理压缩包大小约6KB轻量精简便于快速部署和灵活修改。目前该资源已有三百九十五人下载学习。通过本地运行源码可以直观看到评级提升方案在技术实现与页面展示上的具体做法也能结合附带说明体会整个优化流程的推进方式有助于深入理解华宸AI智评的评审要点并据此拟定符合自身项目的优化策略。尤其适合正在准备华宸AI智评等级提升希望借鉴完整成熟方案的开发者参考使用。 先说一下为什么写这篇东西。我一直在维护华宸AI智评平台这套系统核心是给注册用户做AI能力评估生成等级画像等级直接决定用户能调用的接口配额、高级模型权限和账单折扣。早期版本等级调整特别粗糙基本靠运营同学手工改数据库一个月才能跑一次而且口径不统一有的按调用量算有的按准确率算客服天天被用户投诉“我明明达标了为什么不给我升级”。后来我把整套逻辑重写成自动化的评分引擎配置化规则定时调度还能追溯每次等级变动的依据。这篇文章把整个方案的设计思路、核心代码、部署方式原原本本分享出来源码是完整可运行的适合正在做类似评分评级系统的团队参考也适合打算在智评平台上做用户精细化运营的小伙伴拿去做二次开发。1. 项目背景与整体设计思路1.1 为什么需要一个独立的等级提升方案华宸AI智评的等级体系分为L1到L5五档每一档对应不同的权益L1只能调用基础评测接口每天1000次限额L5可以跑深度推理模型限额放开到50万次并且有专属的模型调优通道。等级评定如果只依赖某一个单一维度容易出现刷量、误判、甚至恶意占用资源的问题。我见过有用户一天内狂刷几万次低难度评测靠调用量把等级顶上去结果升级后跑高并发任务的时候把后端压垮了。所以等级提升方案本质上是三个问题的组合用什么指标衡量用户真实水平怎么把指标转成可执行的规则怎么确保规则公平且可解释。我把这套方案做成一个独立的评分引擎不和业务主流程耦合单独部署也行嵌进现有系统也行。模块监听用户的评测行为日志按周期聚合指标再通过规则引擎计算等级最后把结果写回用户表并生成变动记录。任何一次等级调整都有据可查用户可以清晰看到自己差在哪几个指标上。1.2 方案选型规则评分引擎而不是直接上AI模型很多人一听“AI智评平台”就觉得等级提升也一定要用AI模型来判。我在设计这个方案的时候反而刻意避开了复杂模型用的是规则评分引擎配合加权计算只在置信度判断和异常检测环节引入了一点机器学习逻辑。原因很直接等级体系涉及真金白银的权益发放规则必须可解释、可回滚黑盒模型出了问题都没法排查。规则评分引擎的核心是可配置的评分卡。每个维度调用量、准确率、任务复杂度、反馈分设置一个分值区间每个区间映射不同的得分再按权重汇总成综合评分。综合评分落到等级阈值上达到阈值就触发升级。这种设计的好处是运营同学改规则只需要改配置表不用动代码新规则上线前还能用历史数据做回测。我额外加了一个“稳定期”概念用户必须连续两个评估周期都达到目标等级阈值才真正执行升级避免一次偶然的高分把等级顶上去下个周期又掉回来。2. 核心模块设计与源码解析2.1 总体架构与数据流整个方案分成四层。采集层从华宸AI智评的日志表读取用户评测行为经过清洗和维度聚合后写入评分基础表计算层跑评分引擎根据规则配置算综合分决策层做等级映射和稳定期校验执行层负责更新用户等级、写变动记录、触发通知。四层之间用消息队列解耦新日志进来后异步处理不阻塞评测主链路。数据流是这样的用户每完成一次评测评测服务发一条行为消息到MQ评分服务消费消息并更新当天的行为聚合数据。每个整点跑一次增量评分把刚过去一小时的数据并入周期快照。每个自然日结束后的凌晨两点跑全量周期评分计算每个用户的周期综合分刷新等级快照表。整个流程不涉及实时重计算复杂度可控资源开销也稳定。2.2 数据库表结构设计这是整个方案的地基。我建了四张核心表行为日志表、用户周期聚合表、评分规则配置表、等级变动记录表。-- 用户评测行为原始表已有这里列关键字段 CREATE TABLE eval_behavior_log ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id VARCHAR(64) NOT NULL, task_type VARCHAR(32) NOT NULL, task_level TINYINT NOT NULL DEFAULT 1, is_correct BOOLEAN NOT NULL, latency_ms INT NOT NULL, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, INDEX idx_user_time (user_id, created_at) ); -- 用户周期聚合表方案新增 CREATE TABLE user_cycle_agg ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id VARCHAR(64) NOT NULL, cycle_start DATE NOT NULL, cycle_end DATE NOT NULL, total_tasks INT NOT NULL DEFAULT 0, correct_tasks INT NOT NULL DEFAULT 0, high_level_tasks INT NOT NULL DEFAULT 0, avg_latency_ms INT NOT NULL DEFAULT 0, feedback_score DECIMAL(4,2) NOT NULL DEFAULT 5.00, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_user_cycle (user_id, cycle_start, cycle_end) );等级变动记录表的设计我特别强调一下一定要记录当时的完整快照。如果只记“从L2升到L3”这种信息后面用户问起来你根本说不清楚依据是什么。我在记录表里存了当时的总分、四个维度的得分、生效的规则版本号甚至把规则详情做成了JSON冗余字段存进去这样历史记录完全自解释。CREATE TABLE user_level_change_log ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id VARCHAR(64) NOT NULL, old_level TINYINT NOT NULL, new_level TINYINT NOT NULL, total_score DECIMAL(6,2) NOT NULL, dim_score_json JSON NOT NULL, rule_version VARCHAR(32) NOT NULL, change_reason VARCHAR(512), created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, INDEX idx_user_created (user_id, created_at) );2.3 评分规则配置核心机密都在这张表里我一直在纠结评分规则做成配置文件还是数据库表最后选了数据库表。配置文件的优点是改动要走发版流程有完整的代码评审不容易出错缺点是灵活度差运营同学想调权重还要求着开发发版。做成数据库表之后我加了一层配置变更日志任何修改都有记录出问题可以快速回滚。CREATE TABLE score_rule_config ( id BIGINT PRIMARY KEY AUTO_INCREMENT, rule_type VARCHAR(32) NOT NULL COMMENT EVAL_COUNT/CORRECT_RATE/HIGH_LEVEL_RATE/FEEDBACK, dim_key VARCHAR(32) NOT NULL, min_value DECIMAL(8,2) NOT NULL DEFAULT 0, max_value DECIMAL(8,2) NOT NULL, score_value DECIMAL(6,2) NOT NULL, weight DECIMAL(4,3) NOT NULL DEFAULT 1.000, version VARCHAR(32) NOT NULL, is_active BOOLEAN NOT NULL DEFAULT TRUE, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP );这里有个设计细节每个维度都是左闭右开的区间映射[min_value, max_value) 对应 score_value。比如正确率维度正确率0.95以上给95分0.90到0.95给85分0.80到0.90给70分低于0.80直接给40分。区间用数据库表存要调整分数线的时候直接update不用改代码。注意score_value是维度得分weight是维度权重最终综合分是加权求和。权重加起来必须等于1我在代码里做了校验如果配置的总权重不等于1直接拒绝加载这批规则并告警。2.4 评分引擎核心代码实现评分引擎是整个方案的心脏。我用Java写的核心思想是读取用户周期聚合数据逐维度映射得分加权求和得到综合分再映射等级。整个流程无状态天然支持水平扩展。Service public class RatingEngineService { Resource private ScoreRuleConfigMapper scoreRuleConfigMapper; Resource private UserCycleAggMapper userCycleAggMapper; Resource private UserLevelChangeLogMapper userLevelChangeLogMapper; Resource private UserInfoMapper userInfoMapper; public void evaluateUser(String userId, String version) { // 1. 加载当前生效规则 ListScoreRuleConfig rules scoreRuleConfigMapper.findActiveByVersion(version); MapString, ListScoreRuleConfig ruleMap rules.stream() .collect(Collectors.groupingBy(ScoreRuleConfig::getDimKey)); // 2. 获取用户最近一个完整周期的聚合数据 UserCycleAgg agg userCycleAggMapper.findLatestCompletedCycle(userId); // 3. 计算各维度得分 double evalCountScore calcScore(ruleMap, EVAL_COUNT, agg.getTotalTasks()); double correctRateScore calcScore(ruleMap, CORRECT_RATE, agg.getTotalTasks() 0 ? 0.0 : (double) agg.getCorrectTasks() / agg.getTotalTasks()); double highLevelScore calcScore(ruleMap, HIGH_LEVEL_RATE, agg.getTotalTasks() 0 ? 0.0 : (double) agg.getHighLevelTasks() / agg.getTotalTasks()); double feedbackScore calcScore(ruleMap, FEEDBACK, agg.getFeedbackScore().doubleValue()); // 4. 加权汇总 double total evalCountScore * getWeight(ruleMap, EVAL_COUNT) correctRateScore * getWeight(ruleMap, CORRECT_RATE) highLevelScore * getWeight(ruleMap, HIGH_LEVEL_RATE) feedbackScore * getWeight(ruleMap, FEEDBACK); // 5. 等级映射与稳定期校验 LevelDecision decision decideLevel(userId, total, version); // 6. 更新用户等级并写日志 if (decision.shouldUpdate()) { userInfoMapper.updateUserLevel(userId, decision.getNewLevel()); saveChangeLog(userId, decision, total, agg); } } private double calcScore(MapString, ListScoreRuleConfig ruleMap, String dimKey, double rawValue) { return ruleMap.get(dimKey).stream() .filter(r - rawValue r.getMinValue() rawValue r.getMaxValue()) .findFirst() .map(ScoreRuleConfig::getScoreValue) .orElse(0.0); } }评分引擎的核心逻辑其实就这么点剩下的都是调度和边界处理。calcScore方法是典型的区间映射原始值落到哪个区间就取哪个区间的得分如果没匹配到任何区间返回0分这种情况我建议立刻告警因为说明配置和实际数据严重不符。2.5 等级映射与稳定期机制decideLevel这个方法我单独拉出来讲。等级映射规则是综合分0到59分是L160到69是L270到79是L380到89是L490分以上是L5。但这里不能直接根据当期分数升等级我加了两个额外条件。第一个条件是历史等级保护。用户当前等级是L4当期评分只有75分按阈值映射应该掉到L3但一次低分就降级太粗暴所以我设计了“降级观察期”只有连续三个周期评分都低于当前等级阈值才执行降级。第二个条件是升级稳定期用户当期评分达到L5的90分但上一周期才刚升到L4说明可能是异常波动要再观察一个周期连续两期都达标才升L5。private LevelDecision decideLevel(String userId, double totalScore, String version) { int targetLevel mapScoreToLevel(totalScore); UserLevelInfo current userInfoMapper.findLevelInfo(userId); String counterKey stable: userId : targetLevel; // 升级场景目标等级高于当前等级 if (targetLevel current.getLevel()) { long stableCount redisTemplate.opsForValue().increment(counterKey); redisTemplate.expire(counterKey, Duration.ofDays(45)); if (stableCount 2) { redisTemplate.delete(counterKey); return LevelDecision.upgrade(targetLevel); } return LevelDecision.hold(current.getLevel(), 连续达标次数不足); } // 降级场景目标等级低于当前等级 if (targetLevel current.getLevel()) { long downCount redisTemplate.opsForValue().increment(down: userId); redisTemplate.expire(down: userId, Duration.ofDays(100)); if (downCount 3) { redisTemplate.delete(down: userId); return LevelDecision.downgrade(targetLevel); } return LevelDecision.hold(current.getLevel(), 降级观察期内); } // 等级不变清理所有计数器 redisTemplate.delete(counterKey); redisTemplate.delete(down: userId); return LevelDecision.hold(current.getLevel(), 等级不变); }稳定期计数的过期时间要和实际周期长度对齐。我的评估周期是7天所以升级计数45天过期覆盖6个周期降级计数100天过期覆盖14个周期。如果周期长度改了过期时间必须同步调不然会出现用户明明很久没活跃却被Redis里的老旧计数影响了判定结果。3. 实操过程与部署运行3.1 环境依赖与快速启动这套源码依赖的东西不多Java 11、MySQL 8.0、Redis 6、Spring Boot 2.7。我把整个项目打包成了一个Spring Boot应用内置了自动建表脚本首次启动会自动把四张核心表和初始规则配置初始化好。# 克隆源码后进入项目目录 cd hua-chen-ai-rating # 修改 application.yml 中的数据库和Redis连接信息 vim src/main/resources/application.yml # 执行初始化脚本自动建表 初始规则配置 mvn spring-boot:run启动后项目会加载初始化数据。数据库表会自动创建同时向score_rule_config表插入四个维度的基础规则。这里我把初始权重设置为调用量0.25、正确率0.35、高难度任务占比0.20、反馈分0.20。正确率权重最高这个设计是有意的因为智评平台的核心价值是评测准确度调用量只是活跃度指标权重不能压过质量指标。3.2 演示数据测试启动完成后我习惯用一段演示数据验证全链路是否正常。我写了一个测试接口/api/test/eval传入一批模拟评测日志然后触发评分任务看用户等级变化是否符合预期。# 构造模拟数据一共调用100次正确95次其中高难度任务40次反馈分4.8分 curl -X POST http://localhost:8080/api/test/eval \ -H Content-Type: application/json \ -d { userId: test_user_001, totalTasks: 100, correctTasks: 95, highLevelTasks: 40, feedbackScore: 4.8 } # 手动触发评估 curl -X POST http://localhost:8080/api/rating/evaluate/test_user_001按照默认配置这个用户的四个维度得分是调用量100次落在“50到200次”区间得70分正确率0.95落在“0.95以上”区间得95分高难度任务占比0.40落在“0.30以上”区间得85分反馈分4.8落在“4.5以上”区间得90分。加权汇总700.25 950.35 850.20 900.20 17.5 33.25 17 18 85.75分映射到L4但因为是首次评估稳定期计数只有1所以会保持L3下一个周期继续达标才升L4。3.3 定时任务配置等级评估不能全靠手动触发生产环境我用的是XXL-JOB做分布式调度不过源码里也内置了一个Spring Scheduled的简化版方便小团队直接用。Component Slf4j public class RatingScheduleTask { Resource private RatingEngineService ratingEngineService; Resource private UserCycleAggMapper userCycleAggMapper; // 每天凌晨2点执行每日增量聚合 Scheduled(cron 0 0 2 * * ?) public void dailyAggregate() { ListString activeUserIds userCycleAggMapper.findDistinctUserIds(); for (String userId : activeUserIds) { ratingEngineService.refreshDailyAgg(userId); } } // 每周一凌晨3点执行周期评分 Scheduled(cron 0 0 3 ? * MON) public void weeklyEvaluate() { ListString activeUserIds userCycleAggMapper.findDistinctUserIds(); for (String userId : activeUserIds) { ratingEngineService.evaluateUser(userId, getActiveRuleVersion()); } } }定时任务我这里只写了简化版实际生产建议优先用分布式任务平台保证同一个用户不会同时被两个任务实例处理。如果你用的是XXL-JOB就把Scheduled去掉把两个方法注册成任务通过分片参数把用户ID列表分到不同实例上跑。数据量上来之后全量扫描肯定不行要从user_cycle_agg表里只捞最近7天有行为的活跃用户ID非活跃用户直接跳过。4. 常见问题与排查技巧实录4.1 等级评估结果和预期不符的排查思路这个问题我遇到太多次了十个有八个是规则区间边界搞错了。比如配置的正确率区间是[0.95, 99]和[0.90, 0.95)我的代码里是rawValue min rawValue max所以0.95会落在第一个区间。如果产品经理说“0.95以上的高分段应包括0.95本身”那就没问题但如果你把区间写成了(0.95, 99]0.95就落空了会被兜底逻辑打到0分诡异得很。排查的时候先看user_level_change_log表里的dim_score_json字段哪个维度得分异常一眼就能看到。4.2 Redis计数器导致等级误判稳定期机制依赖Redis计数这里有个很容易踩的坑Redis的increment操作在key不存在时会先初始化为0再加1但如果你漏了设置过期时间过期时间会一直遗留在上一次的expire设置上。比如用户升级达到L4后原来L3的计数key没有删除下一个周期新key创建又带了旧TTL会在错误的时间点被清掉导致稳定期计数失效。我现在的做法是每次increment之后都显式expire并且在等级不变或升降级成功时清理所有相关key杜绝脏数据残留。4.3 数据量大时的性能优化策略用户量超过十万之后每周全量评分开始吃力。实测十万用户全量跑一次大概需要20分钟还能接受但到了一百万级别就必须上分片和批量处理了。我现在生产环境是按用户ID哈希分1024个分片每片一个独立线程处理配合线程池并行跑总耗时压缩到5分钟内。另一个优化点是聚合查询不要在SQL里对行为日志表直接做全量统计提前通过T1的离线任务把聚合结果落到宽表评分时只查宽表查询耗时从秒级降到毫秒级。4.4 常见问题速查表问题现象可能原因处理方式用户评分异常偏高行为日志有刷量或规则区间配置过宽检查dim_score_json结合行为日志做异常检测等级一直不升Redis稳定期计数没清历史key干扰手工删除相关key检查decideLevel清理逻辑新规则不生效规则版本号没有启用或is_active为false确认版本号和loadActiveByVersion的匹配逻辑同一用户被重复评估分布式调度没有做幂等在user_level_change_log加唯一约束或在评估前做校验聚合数据为0T1任务失败或角色没有权限读日志表检查离线任务日志确认user_cycle_agg有数据这个表是我在维护过程中提炼出来的高频问题每次接手新同事跑这套系统先看这个表能少走很多弯路。5. 这套方案的边界与扩展建议5.1 已知的边界情况再健壮的方案也有边界我先把这套方案的短板说清楚。第一周期固定为7天如果业务需要实时调级就满足不了实时计算成本太高目前只能做准实时小时级增量日级全量真正分钟级的动态评级需要换架构。第二规则是静态配置的四个维度的权重固定没有做个性化权重。比如某个企业客户主要做高风险识别场景准确率权重应该比默认值更高但当前方案不支持按用户维度动态改权重。第三异常检测逻辑只做了最简单的阈值判断没有做更细粒度的用户行为画像。5.2 后续值得探索的方向如果要做真正的AI智评等级升级我认为有两个方向值得投入。一是引入轻量级机器学习模型做权重自适应基于用户历史评级准确率和业务场景动态调整各维度权重核心逻辑还是规则引擎但权重由模型输出保持可解释性。二是增加“挑战任务”机制给用户推送高于当前等级的测评任务完成得好可以加速升级完成一般则不影响评级这样既增加了用户参与感又能拿到更高质量的行为数据反哺评分模型。我下一步准备把这两个方向都做进去有进展会再写一篇更新。最后再分享一个实操中的体会评分系统上线前一定要用至少三个月的历史数据做离线回测。我第一版规则上线前就是偷懒只做了两周回测结果正式跑起来发现很多老用户被错误降级客诉直接爆掉。回测不用做得很复杂把历史行为日志按时间切片喂给评分引擎对比每个时间切片产出的等级和当时真实的运营判定找出差异点逐条分析规则的问题很快就能暴露出来。这个步骤能帮你省下无数维护成本。本文还有配套的精品资源点击获取