做风控这行天天要面对的问题就是怎么从动辄几亿条的业务数据里把黑灰产那条线给拽出来。难点从来不是数据量而是信号。黑产混在真实用户里伪装得越来越像正常人甚至会用真人的账号、真人的设备、真人的网络来操作。但只要是操作就会留下痕迹而痕迹藏在海量数据里需要一套系统的方法去挖。这篇内容想聊的就是从原始业务日志到风险决策的完整链路怎么把“看得见的记录”变成“能打击的团伙”适合刚接触风控的数据分析师、后端开发、安全工程师也适合已经在风控岗位、想系统梳理一下思路的人。我会从信号识别、特征加工、图算法、模型实战和工程落地这几个角度把一个风控挖掘项目从0到1拆开来讲。1. 先搞明白黑灰产到底会在数据里留下什么我见过不少做风控的同学一上来就急着调算法、跑模型结果特征建了一堆效果却一塌糊涂。原因很简单你连黑产在你的业务里长什么样都没搞清楚怎么可能挖得出来。1.1 身份层注册信息里的“工业化痕迹”黑产做假账号是有成本的所以他们追求“工业化生产”。一个团伙可能一天注册几千个账号但它的底层资源是有限的。注册手机号就那几个池子设备指纹就那几台真机加模拟器IP就那几段机房网段。所以从身份层看最先暴露的往往不是单个字段异常而是“资源复用”和“批量生成”的痕迹。举例来说你会在数据里看到同一台设备在一个月内关联了上百个手机号或者同一个身份证号被几十个账号绑定又或者一批账号的注册时间集中在某个凌晨的几分钟内。这些都是典型的批量注册信号。早期很多平台只看手机号是否真实、是否黑名单但对“手机号本身没问题、只是被同一个设备拿来反复注册”这种场景视而不见结果黑产用一台真机加几百张物联网卡就轻松绕过了。这里有个容易忽略的细节身份层信号要重点看“一对多”和“短期集中”而不是单点字段是否合规。1.2 行为层规律到“过于完美”本身就是异常真用户的行为是杂乱无章的。一个人可能早上刷两分钟资讯中午集中下一单晚上又随便翻翻操作路径不固定时间也不固定甚至经常中途放弃。但黑产脚本的行为是高度规律的注册间隔几乎一样浏览路径完全一致下单时间精确到秒级的固定节奏。我自己排查过一个案子一批账号在凌晨3点到5点之间完成注册、领券、下单、支付全流程平均耗时最短的一个账号只用了6.8秒。正常人连选商品都来不及这种速度只能说明背后是脚本在跑。你不需要多高深的算法把“单次完整流程耗时”和“操作时间分布”拉出来看异常就摆在眼前。行为层的信号有很强的对抗性因为黑产也在不断调整节奏但只要有批量操作的诉求它就不可能做到真正的随机。所以行为数据的价值不在于抓某一个动作而在于建立“时间线”把多个动作串起来看。1.3 关系层黑产团伙在数据里的真实形态单个账号、单个IP、单个设备都有可能是干净的但把它们之间的关系图拉出来问题就会现形。黑产最难伪造的就是关系。一个真实用户会在一台上网设备上登录自己的账号绑定自己的手机号收货地址是自己的家庭或公司而黑产团伙的设备、手机号、收货地址、支付账号会互相交叉复用形成一张密集关联的网络。我习惯把关系层比作“查朋友圈”如果一批账号之间没有任何交集它们大概率不相关但如果它们共用过设备、共用过IP、共用过收货地址甚至支付账号之间有资金往来那这些账号在关系图上就会聚成一团。图一画出来团伙的结构清清楚楚。所以在开始动手建模之前先逼自己回答三个问题你的业务数据里哪些实体会被黑产复用哪些关系是黑产伪造不了的哪些信号是批量操作必然留下的这三个问题想透了后面每一步都有方向。2. 数据怎么变成可识别的信号画像与特征加工信号意识有了下一步是把原始数据加工成模型和规则能用的特征。这一步做得扎实后面挖掘的精度和效率都会高很多。也恰恰是这一步很多团队容易偷懒直接拉几个字段拼一张大宽表就开跑结果特征之间互相耦合不说还充满了脏数据。2.1 先把数据仓库的“三层结构”搭起来做风控特征最忌讳的就是把所有的逻辑都塞在一张表里。我习惯按“事实层—维度层—汇总层”三层来组织。事实层存放不可再拆分的原始事实比如一次注册行为、一笔下单、一次支付、一次登录。维度层存放实体属性比如用户的基础信息、设备指纹信息、IP归属信息。汇总层则是把事实和维度组合计算出来的统计指标常用的方式是“实体时间窗口行为类型统计函数”的四元组例如“设备ID在最近1小时内发生注册行为的次数”。这种分层的好处是事实层保持可追溯维度层方便做过滤汇总层直接服务于模型和规则。哪个环节出了问题可以快速定位到是哪一层的数据有问题而不是整个链路一起崩。2.2 四大类风险特征的具体计算方式第一类是基础属性特征。注册时长、注册渠道、账号类型、是否绑定手机、是否实名认证等这类特征本身区分度不高但作为模型输入和规则前置条件很有用。例如“注册时间小于1小时的账号不允许参与营销活动”就是这类特征的典型用法。第二类是行为频次特征。核心是“在某个时间窗口内某个实体做了多少次某个动作”。窗口一般设为1小时、24小时、7天三档。计算方式通常是聚合SQL或者流式计算。举例来说-- 同一设备在最近24小时内的注册次数 SELECT device_id, COUNT(DISTINCT user_id) AS register_user_cnt, COUNT(*) AS register_act_cnt FROM fact_register WHERE register_time NOW() - INTERVAL 24 HOUR GROUP BY device_id真用户一般不会有太高的频次黑产账号则会呈现出极度偏离正常分布的峰值。第三类是设备与IP风险特征。这部分不是简单打标而是计算“环境干净度”。比如某设备关联的账号中黑名单账号占比多少某IP段是否属于IDC机房某IP的活跃时段是否集中在深夜。这些特征的核心是“关联黑样本的密度”密度越高环境越可疑。第四类是关系特征。需要先通过图构建得到每个账号的一度关系数量、命中黑名单的一度关系比例、二度关系里是否存在已知风险实体。关系特征是识别团伙的关键因为行为特征可以被规避但关系网络很难在短时间内伪装出正常形态。2.3 设备指纹黑产最难绕过的“身份证”设备指纹是风控体系里不可缺的一环。为什么因为手机号可以换账号可以重新注册但设备环境是有惯性的。一台真机无论怎么重置摄像头硬件标识、传感器参数、电池状态这些底层信息很难完全改变而这也正是设备指纹技术的逻辑根基——把真实物理设备从软件层面固化成一个稳定标识。采集的信息包括且不限于浏览器UA、屏幕分辨率、时区、语言列表、字体列表、Canvas指纹、WebGL参数、音频上下文特征等在App端还会采集设备型号、系统版本、匿名硬件标识等。服务端拿到这些信息后做归一化再通过哈希或聚类算法生成一个指纹ID。设备指纹的工程实现有四个坑一是特征采集不全导致指纹区分度不够二是特征不稳定用户升级一次系统指纹就变了三是多处采集点逻辑不一致导致同一个设备在前后端生成两个指纹四是存储和检索的实时性不够等查到指纹时风险已经发生了。做这一块的时候建议先跑一段时间的稳定性测试观察同一设备在正常使用下的指纹变化率再决定哪些特征进入最终指纹。2.4 标签体系不要随便给用户贴“黑产”的帽子特征加工完成后会形成一套用户标签库。标签体系我建议分三类正向标签、风险标签和“暂无法判定”标签。正向标签包括活跃度、消费力、注册渠道等风险标签包括欺诈风险、薅羊毛风险、盗号风险等。但最重要的是第三类灰度标签。我给很多团队做过评审发现一个通病模型输出一个风险分工程师直接按阈值切成“黑”和“白”把中间地带全部忽略。这是非常危险的。黑产的特点就是快速变化今天看起来正常的行为明天可能就是新的攻击模式。如果标签体系里没有“未知”这个状态系统就会在误判的道路上越走越远。所以我的建议是初期宁可多留一些“暂无法判定”的样本也不要急着打上非黑即白的标签。3. 挖掘的核心打法规则、图、模型三层递进特征和标签就绪后进入正式的挖掘环节。这里要强调一个观念不要指望一个算法解决所有问题。风控挖掘一定是层层递进的第一层用规则兜底第二层用图算法找团伙第三层用模型抓变种三层各有分工又互相补充。3.1 规则引擎上线最快、解释性最强的第一道防线规则引擎的价值不必多描述直接、快、能解释。某活动上线后同一个IP在半小时内注册了50个账号规则引擎直接拦截同一设备关联的账号数已经超过10个风控系统直接触发复审。这样的逻辑用配置化的规则引擎实现不需要训练样本不需要模型调参上线速度以分钟计。值得认真讨论的是规则的制定方式。我把规则分成三类单点阈值规则、组合规则、评分卡规则。单点阈值最简单但容易被黑产探测到后规避组合规则把多个弱信号组合在一起提升区分度评分卡则把每一条命中规则的权重加起来得到一个总分再分档决策。规则引擎的局限性也很明显只能识别已知模式。黑产改一个参数规则就失效。所以规则引擎真正的作用是解决“已经被确认的已知问题”剩下的未知问题交给后续三层。3.2 图计算风控挖掘黑灰产团伙的杀手锏图算法在风控里的位置有点类似侦察兵。它不直接下结论但能把“谁和谁是一伙的”这个问题快速变成可视化的证据链。建图的第一步是确定节点和边。节点通常是账户、设备、IP、手机号、收货地址、支付账号、银行卡等边则根据业务关系定义比如“同设备注册”“同IP登录”“同地址收货”“资金转账”等。边的权重可以根据关系强度来设置比如同设备登录的权重高于同IP登录。第二步是跑图算法。最常用的是连通分量算法找出一批彼此直接或间接连通的节点集合。一个连通分量如果包含了几百个账号而这些账号的注册时间集中在两三天内那基本可以判定是一个团伙。另一个常用算法是标签传播LPA它可以对大规模图做社区划分把关系相对紧密的子图单独切出来。有个案子我印象很深某平台发现一批账号的消费行为非常接近都是新注册、立即下单一款小众商品、收货后马上确认收货并评价。单个看没有任何异常但把设备、IP、地址拉进图里跑了一圈发现这500多个账号全部汇聚到3个设备、2个IP、1个共用地址上。这就是黑产团伙在数据里的真实形态。拿到这个证据后不用模型解释直接按团伙维度批量处置。图计算的技术选型也要提一句数据量在千万级以下可以用单机图数据库配合脚本查询数据量达到亿级甚至更大就要考虑分布式图计算引擎或者用离线计算的方式周期性地重建全量关系图。实时性要求高的场景还可以把图计算的结果物化出来作为特征供在线决策调用。3.3 机器学习模型用来对付“变异”和“未知”规则和图算法解决的是“已知”的团伙黑产一旦变异这两个手段就容易失效。机器学习模型的价值在于泛化通过学习历史拦截样本的模式去识别那些以前没见过的变种。建模的第一步是样本准备。训练数据一般由三部分组成历史拦截确认的账号、人工复核的案例、部分“正常但有风险倾向”的灰度样本。样本质量直接决定模型上限这里最大的坑是样本偏差——只标注了确定有问题的“黑样本”大量介于中间状态的“灰样本”被当作白样本来训练模型就会严重误判。特征方面就使用前面提到的四大类特征再加一部分图特征和时序特征。模型选择上表格型数据用集成学习模型是主流选择可解释性要求高的场景则用逻辑回归或评分卡。无监督模型如孤立森林也很有用它可以用来发现那些远离正常分布的新类型欺诈。落地时我的经验是有监督模型负责精准识别无监督模型负责发现新动向两类模型的结果共同输入决策层。模型上线后还要持续监控和迭代。风控模型和推荐模型最大的区别是对手在盯着你的模型迭代如果你两周更新一次黑产就有一周的窗口期来刷你的活动。所以模型的生命周期管理、特征监控、定时重训练这些工程化能力的要求比算法本身还高。3.4 三层如何配合一个决策流的实际串联以一个营销活动风控为例整个决策流的串联逻辑是在线请求到达时先用规则引擎检查是否命中已知风险模式如果没有命中进入图特征查询看该账号是否与已知风险团伙有关联最后模型输出一个风险分根据分数分别进入放行、观察、拦截、人工审核四种状态。三层各自独立又层层递进既保证了时效性也兼顾了精准度。4. 一次完整的挖掘实操从原始日志到团伙落地前面讲的是方法论这一节用一个虚构的“模拟项目X”案例把从原始数据到风险团伙落地的全过程走一遍。场景是这样的某电商平台推出了一个新人立减20元的补贴活动预算500万上线不到两天就被消耗了40%。运营方本以为是有大量新用户在涌入但仔细一看数据确实注册量大增但大部分注册账号从未浏览过商品直接下单一个指定商品然后支付、确认收货。这个模式基本可以确认是黑产薅羊毛。4.1 数据准备与日志梳理第一件事梳理现有数据确认哪些表能用。访问日志和埋点日志记录了每个用户的行为序列注册表记录了注册时间、注册手机号、注册IP、注册设备号订单表和支付表记录了交易链路和支付账户地址表记录了每个订单的收货人信息和详细地址。另外还有一张设备指纹派生表和一张IP情报库表。平时工作里我发现不少团队卡在这一步因为日志分散在各个业务线字段含义不统一甚至用户ID在不同表里类型都不一样。所以数据准备阶段的核心工作不是写SQL而是做口径对齐。我把所有表的粒度确认清楚弄明白“一张订单对应几条支付记录、一个设备指纹对应几个用户”这类细节后面聚合才不会出错。4.2 第一轮筛选规则初筛摸清整体盘面先不讲什么算法用规则把明显的异常先圈出来。我执行的初筛规则包括注册时间距下单时间小于1小时注册手机号命中接码号段库或手机号状态异常设备关联账号数大于等于5个注册IP命中IDC机房段或者短期内频繁变化。这几个规则跑完筛出来大约2万个可疑账号。这个量级不算大但已经足够说明问题——活动的确是被人盯上了。规则初筛的价值是在短时间内把范围从百万用户收敛到几万个重点对象为后续的深度分析缩小了排查面。4.3 特征聚合与异常分析然后是特征聚合。我按设备、IP、收货地址、手机号四个维度分别做聚合统计。下面这段是设备维度的核心查询逻辑SELECT device_id, COUNT(DISTINCT user_id) AS bind_user_cnt, COUNT(DISTINCT phone_no) AS bind_phone_cnt, COUNT(DISTINCT order_id) AS order_cnt, DATEDIFF(MAX(register_time), MIN(register_time)) AS active_span_days FROM dw_fact_register WHERE register_time 2024-01-01 00:00:00 AND register_time 2024-01-07 00:00:00 GROUP BY device_id HAVING bind_user_cnt 5 ORDER BY bind_user_cnt DESC结果非常直观。排名靠前的设备单台设备关联的注册账号数达到了300多个而且活跃跨度很短大部分集中在一两天之内。IP维度上某几个IP段贡献了超过80%的异常注册量收货地址维度更夸张一个地址被重复使用了上千次收货人姓名多达几十个。这些统计特征已经足够说明这不是随机事件而是有组织的批量操作。4.4 图关联与团伙划分特征来看异常确实存在。但为了避免误伤需要把这些“可疑账号”之间的关系梳理清楚。我把用户、设备、IP、手机号、收货地址、支付账号六类实体建立关联图边的定义是“注册关系”“登录关系”“收货关系”“支付关系”四种。把初筛出来的账号加入节点集跑一遍连通分量算法。结果出来了2万个账号最后落到了几百个连通分量里其中最大的一个连通分量包含了8000多个账号关联的设备只有20多台IP只有十几个收货地址集中在3个。这个结构清晰显示整个团伙本质上只是用了少量的核心资源不断批量生产账号、批量下单、批量收货。4.5 命中验证与处置动作关联结果出来后我还做了一轮人工抽样验证确保动作的准确率抽取100个命中账号逐个核查发现其中90%以上的账号存在至少一个“设备关联数异常”“收货地址雷同”“注册IP为机房IP”的明显特征而剩下的10%左右属于信息不完整无法准确判断。即使如此对于羊毛党团伙这个验证的精准度已经足够支撑处置。处置动作分几步走第一取消命中团伙账号的当笔订单补贴阻止资金继续被套取第二对关联设备、IP段、收货地址做封禁处理或降权处理后续访问必须经过更严格的人工审核第三活动规则补充限制条件新用户必须通过实名认证才能领取补贴同时在离线侧将本次识别的团伙特征沉淀到风险库中供后续活动复用。最后的复盘统计显示这一轮动作止损金额占活动总预算的30%以上并且对正常新用户的下单转化率几乎没有影响。4.6 这一轮实操留下的关键启示复盘下来这个案子验证了几件事规则初筛能快速圈定范围特征聚合能提供强度和证据图关联能还原团伙结构人工抽验能保证处置底气。更重要的是一套完整的信息组织方法让每个环节都能反查、能解释、能复用而不是每次都从零开始碰运气。5. 落地中的坑与问题排查实录做风控挖掘很少有一次到位的。踩坑是常态关键是要知道坑在哪儿以及怎么绕过去。5.1 数据质量坑口径不一致比数据缺失更致命数据缺失还好处理最怕的是口径不一致。我遇到过同一台设备在两张表里ID格式不同——一张是原始设备号一张是哈希后的指纹ID关联了半天发现匹配不上。还有时区问题日志表用UTC时间业务表用本地时间聚合一小时窗口的数据结果横跨了两天造成误判。解决办法是在项目初期就建立“数据字典口径说明”的机制。每个表的粒度、每个关键字段的含义、每个ID的生成规则都要写清楚。等模型上线后再来改口径代价是成倍的。5.2 样本与评估坑别被过高的准确率冲昏头脑风控模型很容易出现“测试集准确率99%”的幻觉。原因通常是黑样本不足正负样本比例悬殊或者特征里包含了未来信息。我见过最典型的特征穿越案例有人把“该用户是否被处理”也当成特征放进模型训练模型在训练集上表现完美一上线立刻崩溃。评估风控模型不能只看准确率要看业务相关指标误杀一个正常用户的代价是多少漏放一个黑产的代价又是多少在不同场景下这两个代价完全不一样。营销活动里漏放几个羊毛党可能最多损失几百块但支付风控里一个漏网之鱼可能就是几万甚至更多的损失。所以做评估时一定要分别看召回率和误杀率再根据业务容忍度来切阈值。5.3 对抗时效坑你的规则和模型会有被盯上的风险黑产会逆向你的风控逻辑。他们会试探性地跑一些小批量订单一步一步地测出你的阈值、触发条件和风控边界。规则引擎上线后如果长期不更新命中率会肉眼可见地下降。应对的思路是“敏捷迭代”规则要配置化修改不求人模型要半自动重训练一周到两周为一个周期特征要不断补充新品种让对手永远需要重新摸索。另外要对风险指标做监控比如“策略命中率”“模型均分”“人工审核通过率”的波动曲线一旦出现断崖式下跌或阶段性上升立即排查原因。5.4 常见问题速查表问题现象可能原因排查思路规则命中率突然下降黑产变换了绕过路径拉出近期被放行的风险样本看集中在哪个环节模型分数整体偏高训练样本偏差灰样本被当成白样本复核训练集标注单独建一个“未知区”图算法跑出巨型连通分量关系定义太宽把无关节点连在一起收窄边的定义增加权重过滤多个表关联后数据量膨胀粒度不一致一对多关联造成笛卡尔积先在各表内聚合好再关联汇总结果误杀正常用户比例偏高特征单一或阈值过于严格引入更多维度特征交叉验证降低单维度权重羊毛号在同一批设备上反复出现设备指纹被篡改或重置增加设备指纹的隐藏特征并关联行为特征判断这些问题基本覆盖了风控挖掘项目从开发到上线的常见故障。每一次问题的排查过程其实也都是对数据链路更深的理解积累下来会成为你判断风险直觉的一部分。做风控这几年我最大的体会是黑产是挖不完的但每一次对抗都会在数据里留下痕迹。你要做的不是追求某一次把黑产“一网打尽”而是搭好一套能持续从海量业务数据中挖掘出异常的体系让黑产在你这儿搞事的成本越来越高直到他们觉得不划算。如果你正在搭自己的风控链路我的建议是别一上来就搞复杂模型先从你业务里最容易被打的环节入手把注册、登录、首单补贴这三个场景的日志数据结构化做好配上规则和简单的关联分析就已经能拦住大多数批量作恶。等数据厚了、样本多了再逐步引入图算法和模型迭代。这套打法看着朴素但在我维护过的项目里是最稳、也最能持久见效的。