刚开始做淘客系统的时候我根本没想过风控这回事。那时候觉得把联盟接口接好、订单同步跑通、佣金算准就已经够折腾人了。直到有一天报表里出现了一个推广位一天之内产生了上千个订单买家ID几乎全是新注册的收货地址集中在某个城中村的几个快递驿站——那一刻我才意识到淘客系统真正难的不是业务功能而是怎么在脏流量里把钱算明白。这篇文章就聊聊我在淘客系统的风控策略上做的异常刷单检测和反作弊规则引擎实现。里面不会有太多学院派的公式推导更多是实际项目中踩过坑之后沉淀下来的方案和代码。如果你正在做或者准备做电商联盟、CPS分销、返利平台这类业务这篇文章应该能帮你少走不少弯路。1. 淘客系统里风控到底在防什么1.1 三种让人头疼的作弊场景淘客的业务链路其实很简单推广者把商品链接发出去用户通过链接下单订单完成确认后系统按约定比例给推广者返佣。问题就出在这个“按效果付费”的模式上因为它直接催生了各种试图伪造“效果”的黑产。第一种是机器批量刷单。黑产手里有大把的手机号、设备模拟器和自动化脚本。他们可以模拟真实用户的行为轨迹——搜索商品、浏览详情、加购物车、再下单——做得和正常人一模一样。但数据量一上来痕迹就藏不住了同一设备短时间内关联几十个账号、同一IP段密集下单、下单时间分布呈现出非人的均匀性。第二种是内鬼自买自刷。推广者自己或者找亲戚朋友下单然后通过发空包、填虚假单号的方式骗过商城物流校验。这类作弊最难防因为从行为特征上看它和真实用户几乎无法区分。唯一的线索是社交关系链、支付账号关联、历史交易记录这些更深层的数据。第三种是频道裂变养号。黑产先通过低价商品养一批账号让它们有正常的购物记录和好评率养到一定程度后再用这些账号去刷高佣商品。这种模式周期长、隐蔽性强单看某一次行为完全正常必须从账号生命周期和行为序列的角度才能抓到异常。1.2 风控不是技术问题是账本问题我一直有一个观点淘客系统的风控本质上是保护结算数据的真实性。技术上的拦截、识别、封禁最终都是为了一个目的——确保我们结算给推广者的每一分钱都对应着真实的用户行为和真实的交易。这就决定了风控系统在设计上有三个硬约束第一不能误伤正常的推广者。淘客推广者的生态很复杂有做内容种草的大V也有跑低价单的量贩型玩家。同一个指标对不同群体含义完全不同。如果在规则里一刀切很容易把正常的大推手误杀了导致客诉和流失。第二实时性和准确率要平衡。订单从产生到结算往往只有几天的确认周期如果风控判断太慢钱已经付出去了追回来就非常被动。所以风控链路必须在订单产生后的极短时间内给出结论同时又要尽量避免误判。第三要能解释。当你扣了一个推广者的佣金对方一定会来找你理论。如果你的风控系统不能给出一条清晰的规则说明比如“因为你注册手机号与已作弊账号相同且转化率超过正常值3倍”那这个判罚就没有说服力。理解了这三点再去设计风控系统思路就完全不一样了。它不是一堆模型的堆砌而是一套能和业务对话的规则体系。2. 异常刷单检测数据是地基特征才是武器2.1 数据采集先解决“有没有”的问题做风控最怕的不是算法不够强而是数据根本不够用。我刚接手淘客系统的时候数据库里只有订单表、推广位表、商品表这三张核心表。连用户的下单设备型号都没有记录更别说IP归属地、设备指纹这些维度的数据了。第一步要做的是补全埋点。我在推广链接的跳转链路里加了一个专门的风控事件采集层所有经过推广链接的请求都会把这个请求的关键信息记录下来包括用户侧的基础信息IP地址、User-Agent、设备ID如果有、操作系统、浏览器指纹跳转来源信息推广位ID、渠道标识、落地页URL、上一跳页面URLReferer行为信息从点击到下单的时长、浏览的商品数、是否使用了优惠券、支付方式这些数据通过MQ异步写入到ClickHouse里作为风控分析的原始数据源。之所以用ClickHouse而不是MySQL是因为风控查询往往是海量数据上的聚合分析——比如“某个设备ID在最近24小时内关联了多少个订单”、“某个IP段在最近1小时的订单量变化曲线”这种查询在ClickHouse里都是毫秒级返回的MySQL根本扛不住。2.2 核心特征怎么把原始数据变成判断依据有了原始数据还远远不够风控的本质是特征工程建设。我把我这边的特征分成四个维度每个维度都对应用户的一种“身份侧面”。设备维度是最直接的特征。一台手机刷了几十个账号无论账号怎么换设备ID不会变。我这里重点看的指标包括设备关联账号数、设备关联IP数、设备活跃时间段分布、设备是否在模拟器特征库中。模拟器检测这块前端SDK采集时可以拿到很多特征比如Build.FINGERPRINT、电池温度是否恒定、传感器列表是否正常等。我这边后端主要依赖设备ID的聚集度来做判断。IP维度是另一个关键信号。真实的推广流量IP分布应该是高度分散的。如果一个IP段贡献了超过正常水平的订单量或者一个IP地址关联了多个收货地址、多个支付账号那就要引起警觉了。我这边会把IP打成/24网段来看聚合情况因为单个IP可能是动态分配的但同一网段的异常聚集往往更有说服力。行为维度就更有意思了。我记得早期做规则的时候发现一个特别典型的行为特征真人用户从点击到下单的时长一般呈长尾分布大部分人会在几分钟到几小时内完成决策但作弊脚本为了追求速度往往在点击后的几十秒内就完成了从进店到下单的全过程。这个“点击-下单时长”特征配合“是否浏览了商品详情页”“是否查看了评价”等细粒度行为可以组合出一套很有区分度的规则。关联维度是进阶玩法。通过图关系把账号、设备、IP、支付方式、收货手机号关联起来用连通图算法找出作弊团伙。这个在初期人工看不出来但当我用图数据库做了第一次关联分析之后发现一个作弊团伙的设备图和IP图非常紧密几十个节点都关联到同一个支付账号上。下面这张表是我在实战中总结的核心特征清单直接对标到具体行为维度特征名称正常范围参考异常信号设备设备关联账号数1~2个 5个设备设备关联IP的省份数1~3个 5个IPIP/24网段单日订单数与渠道均值相关超过均值5倍行为点击到下单平均时长3分钟以上 30秒行为下单前浏览商品数1~8个0个或超过20个关联支付账号关联设备数1个 3个账号注册时长到首单时间几天到几个月 1小时账号历史订单商品类目集中度相对分散高度集中在高佣类目2.3 识别算法选型从阈值规则到评分模型当你把特征梳理出来之后自然会面临一个选择是直接写if-else规则还是上机器学习模型我的经验是两者要结合而且要分层。纯规则的好处是解释性强、上线快、便于业务团队理解缺点是覆盖面有限黑产稍微变种就能绕过。纯模型的优势是能捕捉非线性关系发现未知模式缺点是解释性差而且需要大量标注好的训练样本。我的做法是第一层先用规则做“急停”针对那些极端明显的作弊行为——比如设备关联了几百个账号、IP段的订单量在几分钟内暴涨——直接拦截不需要等模型打分。第二层再上一个轻量级的评分模型把前面说的四维特征汇总成一个0到100的作弊风险分。分数超过80的直接进入人工审核或者锁定结算60到80的标记为可疑降低结算优先级观察一段时间再放款。模型方面我一开始用的是XGBoost因为它在中小规模数据集上表现好训练速度快而且特征的feature importance可以直接拿来做规则调优的参考。后来样本量起来了之后尝试了更深一点的模型但收益边际递减反而XGBoost的稳定性和可解释性更适合我现在这个业务体量。3. 反作弊规则引擎的架构设计3.1 为什么不用现成的Drools而是自研规则引擎说到规则引擎很多人第一反应是用Drools。我在项目早期也确实调研过Drools它的DRL语法强大生态成熟社区活跃。但最终没有选择它原因有几个第一Drools的学习成本对业务团队不友好。我希望规则能够下沉到运营手里让他们在发现新的作弊模式时能自己配置规则而不是每次都要提需求给研发。DRL那套语法让运营写显然不现实。第二Drools的重力在复杂业务规则编排而风控场景更看重的是“实时判定”和“事件流处理”。我们的规则往往要对一个订单叠加几十个特征来判断这种场景用简单的JSON规则配置配合自定义的表达式计算反而更轻量、更灵活。第三也是最重要的我需要规则能够热更新。黑产的作弊手法可能隔几天就变一次如果每次改规则都要发版重启黄花菜都凉了。Drools虽然也支持动态加载但整个工程链路会比较重不如自研一个轻量规则引擎来得直接。所以我最后选择自研一个规则执行框架核心设计原则是规则与代码分离、规则可视化配置、规则热加载、执行链路可审计。3.2 规则的结构设计把业务语言翻译成机器语言一个规则在数据库里存的是什么我这边设计的规则结构是这样的{ ruleId: R001, ruleName: 设备关联账号数超限, priority: 90, conditions: { all: [ { fact: device_order_stats, field: related_account_count, operator: gt, value: 5 }, { fact: device_order_stats, field: is_emulator, operator: eq, value: true } ] }, action: FREEZE_ORDER, actionParams: { reasonCode: DEVICE_ACCOUNT_LIMIT, freezeDurationHours: 24 } }这里的核心概念有三个事实Fact、条件Condition和动作Action。事实是规则执行时传入的一组数据对象。比如device_order_stats这个事实就是我在特征工程阶段算出来的设备维度聚合数据order是当前订单的详细信息user_profile是用户的画像信息。规则引擎在运行时会把所有相关事实打包成一个上下文对象Context供规则条件部分引用。条件是一棵逻辑树支持all所有子条件满足才成立、any任一子条件满足即成立、none所有子条件都不成立三种组合方式。每个叶子节点是一个特征判断格式为事实名.字段名 操作符 阈值。操作符支持gt、lt、eq、in、contains、regex等常用比较。动作是规则命中后要执行的操作。我这边常用的动作包括FREEZE_ORDER冻结订单结算、MARK_SUSPICIOUS标记可疑、BLACKLIST_DEVICE拉黑设备、REQUIRE_MANUAL_REVIEW转人工审核。每个动作可以配置参数比如冻结时长、原因码等。这个结构看起来简单但实际使用中非常灵活。运营同事在后台配置页面上只需要选择事实、字段、操作符填上阈值再选一个动作一条规则就配好了。3.3 引擎执行流程一次请求如何完成风控判定整个引擎的执行流程我分成了五个阶段每个阶段都有明确的责任边界和超时控制。我画了一张流程图在脑海里但这里就用文字来描述第一步是数据准备Data Preparation。订单到达风控系统后先把订单ID、用户ID、设备ID、IP地址、推广位ID这些基础标识解析出来然后并行地去查询相关事实数据。这个阶段最大的开销是特征聚合查询我用了本地缓存加上Caffeine作为一级缓存把特征结果缓存几秒钟避免同一设备/账号的重复订单反复查询数据库。第二步是规则匹配Rule Matching。拿到事实数据之后引擎开始按优先级从高到低逐个执行规则。这里有一个剪枝优化不同规则依赖的事实集合不一样我根据规则的依赖声明做了索引分类只启动和当前订单相关的那部分规则而不是每次都把几千条规则全部执行一遍。第三步是动作执行Action Execution。规则命中后动作并不是立即在同一个线程里执行的。我用了生产者-消费者模式动作被执行器异步执行避免阻塞检测主链路。比如冻结订单这个动作会去调结算服务的接口更新订单状态同时写入风控日志。第四步是结果存储Result Storage。每一条规则的命中记录、每一次动作的执行结果都会落到风控日志表里。这张表是审计的依据也是后续分析规则有效性的数据基础。第五步是指标回写Metrics Feedback。引擎会把本次检测的规则命中情况、耗时、结果等指标写到Prometheus用于监控告警和后续的规则调优。4. 规则引擎的落地实现细节4.1 事实数据模型与特征计算的代码实现说到落地还是要动手写代码。我先展示一下事实数据模型是怎么定义的。在Java里我定义了一个基类BaseFact所有的事实都继承它Data public abstract class BaseFact { /** 事实标识用于日志追踪 */ private String factId; /** 产生时间 */ private long eventTime; /** 数据版本 */ private int version; } Data public class DeviceOrderStatsFact extends BaseFact { /** 设备ID */ private String deviceId; /** 关联账号数 */ private int relatedAccountCount; /** 关联IP数 */ private int relatedIpCount; /** 关联收货地址数 */ private int relatedAddressCount; /** 近24小时订单数 */ private int orderCount24h; /** 是否模拟器 */ private boolean emulator; }这个模型没什么玄机关键在计算。特征计算我单独抽了一个FeatureCalculator接口每个特征一个实现方便扩展和单测public interface FeatureCalculatorF extends BaseFact { /** * 计算事实特征 * param context 原始上下文 * return 事实对象 */ F calculate(EvaluationContext context); } Component public class DeviceOrderStatsCalculator implements FeatureCalculatorDeviceOrderStatsFact { Override public DeviceOrderStatsFact calculate(EvaluationContext context) { String deviceId context.getDeviceId(); DeviceOrderStatsFact fact new DeviceOrderStatsFact(); fact.setDeviceId(deviceId); fact.setRelatedAccountCount(deviceAccountMapper.countAccountsByDevice(deviceId)); fact.setRelatedIpCount(deviceIpMapper.countIpsByDevice(deviceId)); fact.setRelatedAddressCount(deviceAddressMapper.countAddressesByDevice(deviceId)); fact.setOrderCount24h(orderMapper.countOrdersByDeviceWithin24h(deviceId)); fact.setEmulator(deviceCheckService.isEmulator(deviceId)); fact.setEventTime(System.currentTimeMillis()); return fact; } }这里有个小技巧每个Calculator在做数据库查询的时候都要先查本地缓存。我用的Caffeine配置了最大容量和过期时间key是设备ID或账号IDvalue是计算好的Fact对象。实际压测中加了这层缓存之后整个检测链路的P99耗时从180毫秒降到了35毫秒。4.2 规则执行器把JSON条件变成Java逻辑规则执行器的核心函数是evaluate(String ruleJson, EvaluationContext context)。在这里我用了一个轻量的表达式引擎——Aviator——来解析条件表达式。Aviator的体积很小性能也不错最关键的是它支持从JSON直接拼出表达式字符串非常适合我这个场景。Component public class RuleEvaluator { private static final ExpressionCache CACHE new ExpressionCache(); public RuleResult evaluate(RuleDefinition rule, EvaluationContext context) { // 构建表达式并执行 boolean matched evaluateConditions(rule.getConditions(), context); if (!matched) { return RuleResult.notMatched(rule.getRuleId()); } // 命中规则返回动作 return RuleResult.matched(rule.getRuleId(), rule.getAction(), rule.getActionParams()); } private boolean evaluateConditions(ConditionNode node, EvaluationContext context) { if (node null) { return true; } switch (node.getLogicalOp()) { case all: return node.getChildren().stream() .allMatch(child - evaluateConditions(child, context)); case any: return node.getChildren().stream() .anyMatch(child - evaluateConditions(child, context)); default: return evaluateLeaf(node, context); } } private boolean evaluateLeaf(ConditionNode leaf, EvaluationContext context) { // 从上下文取事实 BaseFact fact context.getFact(leaf.getFact()); if (fact null) { // 如果没有对应事实保守起见按不命中处理 return false; } Object actualValue ReflectUtils.getFieldValue(fact, leaf.getField()); Object expectValue parseValue(leaf.getValue(), actualValue.getClass()); return ComparisonOperator.execute(leaf.getOperator(), actualValue, expectValue); } }这段代码的逻辑很清晰递归遍历条件树叶子节点做实际比较父节点根据逻辑操作符合并结果。这里的表达式缓存是全局静态的因为Aviator把表达式编译成字节码之后重复执行时能省掉编译开销。每条规则在加载的时候就会完成编译运行时只需要执行即可。4.3 规则热更新不能重启服务的配置管理规则热更新是我觉得整个系统里最有价值的一块。我用了Nacos作为配置中心规则的JSON存储在Nacos的配置项里服务端监听配置变更事件变更之后重新加载所有规则到内存。Component public class RuleManager { private volatile ListRuleDefinition rules Collections.emptyList(); private final MapString, CompiledRule compiledRuleMap new ConcurrentHashMap(); PostConstruct public void init() { ListRuleDefinition ruleList ruleConfigLoader.loadAllRules(); compileAndSwap(ruleList); } public synchronized void refreshRules() { ListRuleDefinition ruleList ruleConfigLoader.loadAllRules(); compileAndSwap(ruleList); } private void compileAndSwap(ListRuleDefinition ruleList) { MapString, CompiledRule newCompiledMap new ConcurrentHashMap(); for (RuleDefinition rule : ruleList) { // 预编译规则条件表达式 Expression expression AviatorEvaluator.getInstance().compile(rule.getConditionExpression()); newCompiledMap.put(rule.getRuleId(), new CompiledRule(rule, expression)); } // 原子替换 this.compiledRuleMap.clear(); this.compiledRuleMap.putAll(newCompiledMap); this.rules ruleList; } }这里有一个我踩过的坑规则频繁更新的时候要保证内存里不会出现半新半旧的状态。所以我用了volatile修饰的rules引用配合compileAndSwap方法实现原子替换。新规则全部编译成功后才整体替换编译失败则保持不变不会影响线上流量。热更新的发布流程是这样的运营在后台修改规则后先保存到“待发布”状态这时不会生效系统会自动跑一遍回溯测试——把最近7天的历史订单数据重新用新规则跑一遍对比新旧规则的结果差异如果没有异常点击发布Nacos配置变更服务端自动加载。整个流程不需要重启发布后1秒内新规则就生效了。4.4 处罚动作执行链冻结、标记、拉黑的标准实现规则命中了动作怎么执行我这边定义了一个动作执行器接口每种动作一个实现public interface ActionExecutor { String getActionType(); void execute(ActionContext context); } Component public class FreezeOrderActionExecutor implements ActionExecutor { Override public String getActionType() { return FREEZE_ORDER; } Override public void execute(ActionContext context) { String orderId context.getOrderId(); String reasonCode context.getActionParams().get(reasonCode); int durationHours Integer.parseInt(context.getActionParams().get(freezeDurationHours)); // 更新订单状态为冻结 settlementService.freezeOrder(orderId, reasonCode, durationHours); // 记录风控日志 riskLogService.record(context, 订单冻结, reasonCode); // 发送通知给相关负责人 notifyService.sendRiskAlert(context); } }动作执行有一个我强烈建议做的事情动作要支持配置条件。比如“冻结订单”这个动作我希望只有订单金额大于某个阈值时才冻结金额小的直接忽略避免把大量小额订单卷进来造成结算拥堵。这可以在动作执行器内部再加一层判断也可以在上层规则配置时通过actionParams来传递阈值。5. 实战记录一次恶意刷单的拦截全过程5.1 一个典型刷单团伙的行为画像我在系统上线后第三周就遇到了一次真刀真枪的刷单攻击。当时有一个推广位突然起了量订单量从每天几十单暴涨到每天上千单。按说业务增长是好事但我总觉得哪里不对劲于是把特征查询拉出来看了看。这一看就看出了问题。这个推广位的订单数据存在几个明显的聚集特征下单设备的ID高度集中在大约50个设备ID上而每个设备ID关联的账号数都在5到20个之间所有订单的IP归属地集中在三个城市进一步看IP段的分布实际上是两个/24网段下单时间高度规律集中在凌晨2点到5点正好是人工客服最少的时间订单商品的类目90%以上都集中在一个高佣金的大牌美妆单品上点击到下单的平均时长是25秒而正常用户平均是5到8分钟5.2 规则的配置与生效过程看到这些特征之后我直接在规则后台配了四条规则第一条设备关联账号数大于5且近24小时订单数大于10则冻结订单结算。 第二条点击到下单时长小于30秒且订单金额大于500元则标记可疑。 第三条单个IP网段近1小时订单数超过200单则限制该网段后续订单进入自动结算。 第四条同一收货手机号关联设备数大于3则冻结订单。配置完这些规则之后我同步做了一件事回到点击日志里把那个推广位过去7天的数据全部用新规则跑了一遍回溯测试。结果发现大约有600个订单会被新规则拦截但其中有30多个看起来是比较正常的用户。为了把这些正常用户捞回来我加了一个保护条件——如果该用户的账号注册时间超过180天且历史有超过20笔成功交易则跳过冻结只标记为可疑。加了这条保护之后漏判的30个用户降到了2个基本可以接受。发布规则之后我又去监控面板上看了一眼那个推广位当时的实时订单量已经被压下去了。后续几天该推广位的订单量恢复到了正常水平。几个被冻结的账号找过来申诉我这边拿着规则命中日志解释对方也没有太多话可以说毕竟风控规则是公示过的。5.3 复盘为什么这次能拦下来事后复盘这次能比较快地发现并拦截有三个关键因素第一数据埋点做得足够细。如果我没有记录设备ID和点击-下单时长这批订单可能就混过去了。设备ID我来自前端采集点击-下单时长是从推广点击事件和订单事件的时间差算出来的这两个数据是整个检测链路的核心输入。第二聚合视角比单点视角好用。单看每一个订单其实都是“正常”的——用户注册了、看了商品、下了单、用的支付方式也是常见的。只有把订单聚合到设备ID、IP、手机号这些维度异常才会显现出来。所以我强烈建议做风控的时候先把维度构思清楚再写特征。第三规则回溯测试很有价值。如果没有回溯测试直接发布规则大概率会出现一波客诉。先拿历史数据验证规则的影响面心里有底再发这是一个非常值得坚持的好习惯。6. 常见问题与排查技巧6.1 误杀率过高怎么办做风控最怕的就是误杀。一个正常的推广者可能带了很多新用户而这些新用户的行为特征有时候看起来就像“机器”。我遇到过一次真实案例一个做校园推广的团队专门在开学季拉新一个手机号对应一个学生但这些学生都是第一天注册就下单而且用的是校园网IP段非常集中。后来我们给规则加了一个群体豁免机制如果推广者的历史转化率稳定、客诉率低、推广时长超过90天那么他带来的订单可以享受更高的风控阈值。这个机制上线之后误杀率明显下降。6.2 刷单特征变化太快怎么应对黑产不是静态的。今天你用“设备关联账号数大于5”来拦明天他就把设备号换掉改用设备指纹生成器今天你用“点击-下单时长小于30秒”来拦明天他就把脚本的等待时间改成3分半。应对思路有两个方向一个是扩大特征维度。行为特征容易被模拟但设备指纹、浏览器指纹、网络特征这些底层指标很难完全伪造。比如Web端可以采集Canvas指纹、WebGL指纹、字体指纹Android端可以采集IMEI、MAC地址、Android ID等。把底层指纹特征和业务行为特征结合起来作弊方要伪造的成本就会成倍增加。另一个是引入对抗性训练思路。每当你发现一类新作弊模式不要只加一条规则而是把这类作弊样本的特征全部标记出来让评分模型重新训练一轮。模型比规则更容易发现不明显的关联模式。6.3 数据质量导致的无效规则规则配得再好数据不准也没用。我遇到过几次特征数据异常的情况比如前端SDK采集的设备ID在某些低版本浏览器里拿不到导致一批订单的deviceId为空。这些空值放在聚合统计里会让“设备关联账号数”这个指标被严重高估。解决办法是对于deviceId为空的订单回退使用IPUser-Agent的哈希作为替代设备标识保证聚合分析的完整性。再比如点击事件和订单事件如果没对齐时间差字段会算出负数。这种情况通常是因为用户点击推广链接之后隔了很久才下单期间可能换了设备或者清除了Cookie。我在特征计算里加了阈值过滤时间差小于0的按0处理超过72小时的按缺失处理避免异常值影响规则判断。6.4 规则引擎的性能优化风控链路如果拖慢了正常的订单流程业务方肯定会有意见。我在性能优化上做了几件事效果都比较明显第一事实计算并行化。一个订单需要计算四五个事实这些计算之间没有依赖关系完全可以并行执行。我用CompletableFuture把多个FeatureCalculator的调用并发跑起来整体耗时从180毫秒降到了80毫秒。第二规则分级执行。我按规则的计算复杂度和命中率把所有规则分成了三个层级第一层是代价极低、命中率极高的“急停规则”每次请求都必须执行第二层是普通规则随机采样执行保证覆盖率就行第三层是重计算规则只在订单金额超过阈值时才执行。这样能保证大多数订单只跑第一层和第二层的几十条规则响应速度很快。第三缓存策略的调整。特征计算结果虽然做了缓存但缓存的时间窗口要控制好。太短了会穿透太长了会导致规则不能及时感知到用户行为的变化。我这边实测下来设备维度的缓存设60秒账号维度的缓存设30秒IP维度的缓存设10秒是比较合理的。写在最后我在设计这套风控规则引擎时最大的体会是风控不是一次性建完就结束的系统它是一个需要持续运营、持续对抗的体系。你今天建好的规则可能明天就会被新的作弊手法绕过你今天认为有效的特征可能下周就因为业务调整而失真。所以比起大而全的模型我更推荐从简单规则起步把数据底子打好把规则配置的链路做顺然后再逐步叠加模型和更复杂的策略。最后再分享一个小技巧建议把每一次规则命中产生的风控日志都单独存储哪怕日志量很大也不要随意清理。因为黑产的作案模式往往会呈现周期性可能过两个月他又用同样的手法来试一次。有了历史日志你可以快速回溯对比甚至可以直接从日志里挖出新的作弊特征。我做的最有价值的一次特征挖掘就是从三个月前的一批被拦截日志里发现了一个之前没注意到的关联规律。