前阵子大促复盘运营同学甩给我一个让我挺难受的数据风控拦截的订单里有超过30%被人工复核后判定为正常订单。换句话说差不多每三个被系统拦下来的订单里就有一个是误伤。这个数字在平时还能忍大促期间每个订单都是真金白银误伤直接等于把流量和成交白送给竞对。那段时间我一直在想一个问题为什么我们的风控模型在存量特征上做得越来越精细KS值一路提升可落到业务上的精准度感知却变差了后来我把思路从这个人像不像坏人转到了这个人做的事合不合理上才慢慢摸到了Action Model的门道。这篇文章我会把这套思路完整捋一遍重点讲清楚三件事传统风控模型在精细化运营里为什么越来越吃力、Action Model到底在建模什么、以及行为序列建模的三种落地路径各自适合什么场景。这是上篇先把道和术讲透下篇再聊具体的策略设计和工程实现。1. 为什么传统风控在精细化运营里越来越吃力根子出在静态两个字上1.1 传统风控的两大支柱和它们共同的软肋国内主流电商平台的风控体系十有八九是由两部分构成的一部分是规则引擎一部分是评分卡模型。规则引擎长什么样就是如果用户在30分钟内下单超过5笔且收货地址相同则命中XX风控策略。简单直接运维同学和风控同学都能看懂出问题也好解释。评分卡模型则是把用户的注册天数、历史订单金额、登录设备数量、IP风险等级这些特征扔进一个逻辑回归或者XGBoost里输出一个风险分超过阈值就拦截。这两套东西刀耕火种了很多年到今天依然有存在的价值但是它们的共同软肋也摆在那依赖的全是存量特征。什么叫存量特征就是用户到当前这一刻为止已经积累下来的历史信息。注册时间、历史消费、设备指纹、IP归属地这些信息有一个共同特点——它们是这个人过去是谁的投影而不是这个人现在正在做什么的描摹。打个比方传统风控相当于门口保安看了一眼你的工牌觉得嗯这人在这儿干了三年了应该是自己人就放你进去了。但如果你是一个混进来的外人偷了一张工牌呢保安这个动作根本发现不了。我在实际业务里见过太多这种例子。一个黑产团伙会专门养号把账号的注册时间、历史订单、信用分都养得很漂亮传统评分卡模型看这些特征完全就是一个优质用户。但如果你去观察他下单那一刻的微观行为破绽就会露出来他根本不浏览商品详情页、不加购、不比较直接搜索精确款号然后秒下单、秒支付。存量特征这边是岁月静好行为序列那边是着急忙慌这种割裂感就是Action Model要抓的东西。1.2 精细化运营带来的三个新挑战再说说精细化运营这四个字到底给风控添了什么堵。我理解精细化运营的含义是平台不再把用户当成一个整体而是把用户分成新客、成熟客、高价值客、价格敏感客、大促冲动型客等不同群体每个群体配不同的货、不同的券、不同的营销策略。这本来是运营的事但落到风控头上就麻烦了。第一个挑战是用户分层变细之后一刀切的拦截策略行不通了。以前风控就两种决策放行或者拦截边界清晰。现在运营给你提需求对高价值用户尽量不要拦截用静默验证的方式处理对新客可以稍微严格一点但别上来就封号对价格敏感用户要做好券的核销校验防止被撸。同一个行为放在不同用户身上要给出不同响应。传统评分卡模型就是一个分数配一个阈值根本表达不了这么细的分层逻辑。第二个挑战是风险形态从身份风险变成了行为风险。早年间的黑产主要靠盗号、养号、虚假注册拼的是身份信息层面的攻防。现在身份伪造的成本越来越高黑产也进化了开始走真人操作群控系统批量任务的路子。账号是真的、人是真人、设备是干净的唯一异常的是行为路径——他们会在某个时间窗口内用同样的节奏做同样的事。这种风险静态特征几乎测不出来必须看行为序列。第三个挑战是误伤代价在大促期间被无限放大。大促期间流量贵、转化机会稀缺平台每拦错一个订单损失的不止是这个订单的GMV还有这个人整个大促周期的消费潜力。我见过一个很典型的案例一个价值比较高的老用户因为账号在异地登录过加上当晚支付速度快了一点被模型判了高风险下单被拦截。用户一气之下转到竞对平台完成了购买后续一整年都没再回来消费。账面上看风控拦下了一笔可疑订单实际上平台亏掉了一个年度LTV可能上万的高价值用户。1.3 复盘那天运营同学的一句话点醒了我那次大促复盘会运营同学看完成交漏斗数据之后说了一句让我印象很深的话你们风控现在拦人看的都是这个人以前干过什么但运营做活动看的全是这个人现在要干什么。两边节奏根本不在一个频道上。当时我第一反应是他在甩锅但回去细想他说到了点子上。精细化运营的本质是在正确的时间用正确的方式服务正确的人它的落点全部在当下这个时刻。而传统风控模型的落点在历史。中间的鸿沟就是行为序列信息。想明白这一点之后我开始系统地研究怎么把用户的微观行为动作利用起来。这个方向圈内一般叫Action Model。2. Action Model到底在建模什么不是做了什么而是怎么做2.1 一个直观的对比同样都是下单路径天差地别先看两组真实的用户行为序列。为了保护业务数据细节我做了脱敏但节奏和结构是真实的。先说一个正常用户的典型路径。某个用户想买一台蓝牙耳机他的行为序列大概是这样的打开App - 在搜索框输入蓝牙耳机 - 浏览搜索结果列表从上往下刷了大概两屏 - 点进第一个商品看看 - 退出来 - 又点进第二个商品 - 看了看评价 - 在评价区和详情页之间来回切换了两次 - 加了购物车 - 没马上付款 - 又去搜了一下蓝牙耳机 降噪 - 对比了两款 - 回到购物车 - 犹豫了一会儿 - 提交订单 - 选择支付方式 - 完成支付整个过程大约持续了12到15分钟中间有大量回头比较停顿的细节。再来看一个黑产账号的路径。这个账号是某个撸券团伙控制的目标是某品牌放出的一张限量优惠券打开App - 直接搜索精确的商品款号 - 结果页第1个商品直接点进去 - 详情页停留了不到3秒 - 直接加购 - 3秒后进入结算页 - 使用优惠券 - 提交订单 - 支付成功全程不到40秒中间没有任何一个多余动作。这两条路径放在存量特征里看差异微乎其微都是正常注册账号都是正常IP都是正常设备。但如果把行为序列展开差异巨大到连不懂算法的人都能一眼看出来。2.2 Action Model的核心洞察行为序列是一段永远不会说谎的证据链我做了这么多年风控一个很深的体会是行为可能会伪装但行为序列不会完全伪装。单个动作是可以伪装的比如黑产可以让脚本模拟点击详情页这个动作。但一段序列是由无数个动作的先后顺序、时间间隔、互相关系构成的要全部伪装得像真人成本会指数级上升。因为人做事的节奏有天然的不规律规律——会有犹豫、回头、比较、分神而脚本和自动化工具的节奏是直来直往、高度统一的。所以Action Model真正建模的目标不是用户做了哪些动作这个结果而是用户做出这一串动作的方式本身。落到工程上我一般把它拆成四个维度第一个维度是动作顺序。正常人买东西通常遵循搜索/浏览 - 比较 - 加购 - 支付的渐进链路即使跳步也很少从搜索直接跳到支付。黑产和脚本的行为顺序则经常是搜索精准关键词 - 瞬间支付中间所有犹豫类动作全部省略。顺序的合理性本身就是区分信号。第二个维度是时间节奏。这是最值钱的一个维度。同一个动作真人做出来和脚本做出来时间分布是完全不同的。真人浏览一个商品详情页停留时长大概呈长尾分布从几秒到几分钟都有而且和有没有仔细看评价这个商品值不值得纠结高度相关。脚本做出来的停留时长则高度集中在一个非常窄的区间里比如每次都是2秒到3秒。我把这个叫节奏指纹它很难被刻意伪装。第三个维度是目标集中度。正常用户买东西是有探索欲的即使目标明确也会顺便看看同类商品、看看关联推荐。但风险用户的目标极其聚焦——搜什么、进哪个链接、买哪个SKU全程几乎没有偏离。目标集中度这个指标在薅羊毛场景下特别有效因为它天然地刻画了我是来买我想要的东西的和我是来完成一个任务的之间的区别。第四个维度是路径异常度。如果说前三个维度是单点观察路径异常度就是全局视角。比如一个用户前5分钟还在浏览母婴用品突然切到一个和她历史偏好完全无关的3C产品并立刻下单再比如一个用户白天完全不活跃凌晨3点到5点之间连续完成好几次精确购物。这些路径层面的跳变和不合常理单独看某一个动作都正常串在一起就不正常了。2.3 一个帮我跟业务方解释Action Model的类比为了跟运营和审核团队解释Action Model我经常打一个比方传统风控是看照片抓人Action Model是看监控录像抓人。看照片抓人你只能记住这个人长什么样——这是画像特征。如果嫌疑人整了容、化了妆照片就失效了。但看监控录像抓人不一样你能看到他走路的姿势、在案发地附近徘徊的样子、伸手去拉门把手时的犹豫这些是行为和动作。人可以化妆但很难彻底改变走路的节奏和做事的习惯。这个类比业务团队一听就懂后面推项目的时候帮了大忙。做算法的人很容易陷入纯技术思维但要真正把Action Model落地让审核团队、运营团队愿意用、敢用第一关永远是让人看懂你在干什么。2.4 画像特征没有消失只是退居二线很多同学对Action Model有一个误解以为搞了行为序列建模传统的画像特征就没用了。这是不对的。在我实际的建模思路里画像特征不但没被扔掉反而承担了一个更重要的角色——先验概率。一个注册了5年、历史消费20万、从来没有过纠纷记录的用户和一个昨天刚注册、今天第一次下单的用户即使他们现在的行为序列长得很像风险含义也是不一样的。新用户行为怪一点可能是还不熟悉App老用户行为突然变怪那才更值得警惕。我习惯的做法是用画像特征给用户一个基础风险概率用Action Model产出一批行为异常信号两者做融合。画像负责回答这个人的底子干不干净Action Model负责回答这个人此刻做的事情合不合常理。精细化运营要的恰恰是这个组合——既知道这个人是谁又知道他正在干什么。3. 行为序列建模的三种典型路径以及我为什么踩过复杂模型的坑明确了Action Model建模的对象之后下一个问题就是技术上到底怎么建模行为序列这个东西本质上是变长数据而且包含时间间隔直接塞进传统的结构化特征框架里会非常别扭。我实际尝试过三种路径各有各的适用场景不存在的哪个更好的绝对答案。3.1 路径AAction Graph规则用最直接的方式抓确定性模式第一种路径是构建行为图规则这也是我最早尝试的方式。思路很简单把用户的行为定义成节点行为之间的转移定义成边然后人工去梳理哪些行为子图是高风险模式。举个例子下面这条规则就是从真实黑产样本里抽出来的如果用户在30秒内完成搜索 - 点击详情 - 加购 - 下单 - 支付整条链路且搜索词与商品标题精确匹配且支付方式为新绑定的银行卡则命中高风险策略。这条规则本质上是把黑产那条直来直往的路径用图的形式显式地表达了出来。早期我们靠这种规则快速拦截了一大批脚本类的薅羊毛行为可解释性极好——审核团队看到命中记录立刻就能明白用户干了什么不用猜。但它的缺点也同样明显规则的表达能力有限只能抓已经见过且能总结出来的模式。黑产稍微改一下路径比如在搜索和点击之间插入一个5秒的随机等待再多次刷新页面规则就抓不住了。而且规则之间容易出现冲突维护成本高特征维度一多规则集就乱成一团。所以Action Graph规则适合用来兜底确定性风险——只要命中基本可以断定是风险误伤率极低。但它不适合用来发现新风险。3.2 路径B行为序列的统计分布建模用异常检测的思路找偏离第二种路径是不要尝试定义什么是正常的路径而是反过来先去统计大部分正常用户的路径长什么样然后把明显偏离大部分人的路径标出来。具体操作上我会对每个关键动作做两件事一是计算动作间隔的统计分布比如从点击详情到加入购物车间隔时间在正常用户中大概是多少二是计算动作转移概率矩阵比如从浏览详情页之后有多大概率去比较其他商品有多大概率直接进入结算页。建模的时候不需要给每条行为序列硬编码规则而是用统计学手段测量这条序列跟上千条正常序列的分布差异有多大。如果一个用户从点击详情到提交订单只用了1.2秒而正常用户的间隔分布里这个值的99分位都要8秒那这个用户的行为就属于统计意义上的异常。这种方法的优势是比规则灵活得多能覆盖很多说不清哪里不对但就是不对的模糊场景。劣势是我需要足够大的正常行为样本去刻画分布而且一旦用户的整体行为习惯发生变化比如App改版导致用户路径整体变化统计分布就要重新校准。3.3 路径C深度序列模型让模型自己学习动作之间的长程依赖第三种路径也是这两年圈子里讨论比较多的是用LSTM、Transformer这类深度序列模型把用户的行为序列直接喂给模型让它自动学习什么样的序列组合是异常的。这个思路在技术上是最正确的——因为行为序列本质上是时序数据深度序列模型就是为这种数据设计的。它能自动捕捉动作之间的长程依赖关系比如用户在某次搜索之后过了很久才发生支付动作这种跨越多步的关联模式用统计方法很难显式建模但Transformer可以靠注意力机制学出来。在实际应用里我也确实看到深度序列模型在某些场景下能把AUC推高不少尤其是数据量足够大、行为链路足够长的时候。但它在风控领域有一个绕不开的天花板可解释性。风控不像推荐系统。推荐系统推错了用户的损失顶多是刷到了一条不感兴趣的广告风控拦错了直接影响用户能不能下单、能不能用券客服会被打爆运营会追责。模型必须能回答为什么拦这个人。深度模型输出的那个风险分数很难转化成业务侧能理解的语言这导致它更适合做第二道防线——在规则和统计方法漏掉的长尾风险里做补充而不是直接站在前台做最终决策。3.4 三种路径怎么选我的原则是可解释性优先数据量决定复杂度很多同学来问我这三种方式到底怎么选我给的建议很朴素建模路径核心原理优势劣势我推荐的适用场景Action Graph规则人工总结高风险行为子图可解释性极强、实时性好表达能力有限、难以防变种确定性高、已知的强风险模式统计分布建模度量行为序列与正常分布的偏离灵活性好、能抓未知异常依赖正常样本分布、需校准大促节奏、整体行为模式识别深度序列模型自动学习序列中的长程依赖表达能力强、上限高黑盒、可解释性差复杂团伙、长尾风险的补充识别在大多数业务落地场景里我都是先用Action Graph规则把确定性风险兜住再用统计分布建模覆盖模糊异常最后用深度序列模型做长尾补充。三层叠加既保证了实时决策的确定性也保证了新风险的覆盖度。说到深度模型我多说一句踩过的坑。早年我特别迷信模型越复杂效果越好一口气上了Transformer效果确实不错AUC比之前高了快两个点。但上线之后问题来了第一线上推理延迟翻了几倍大促峰值根本扛不住第二某个策略命中之后审核团队来问为什么这个用户被拦了我解释不清第三模型在夜里的行为分布和白天的行为分布差别很大数据漂移把准确率打得七零八落。后来我才意识到风控场景里模型效果只是及格线可解释性、实时性和稳定性才是决定能不能上线的关键。这个认知我花了小半年才真正想明白写在这里希望后来的人少走点弯路。4. 落地Action Model之前必须想清楚的五个工程问题上篇的最后一部分我想聊五个在工程落地时一定会踩到的问题。这些坑如果不在项目初期想清楚后面返工的成本会非常高。4.1 数据埋点行为事件的定义比模型算法更影响效果做行为序列建模第一步卡住你的往往不是算法而是数据。同一个加购行为在不同团队的定义可能完全不一样是用户点了加入购物车按钮就算还是加购成功弹窗出现才算还是用户加了车之后又减了也算如果这些事件的埋点口径没有拉齐后面所有统计分布都是错的。我建议项目启动的第一周风控算法、数据开发和客户端的同学坐在一起把关键行为事件的定义逐个对齐。像搜索浏览详情加购结算页到达支付成功退款申请这类核心动作要明确事件名、触发时机、附带属性。另外特别注意事件的时间戳别用客户端上传时间最好用服务端接收时间不然用户手机时钟不准会直接干废所有间隔统计。4.2 实时性模型复杂度必须和工程链路匹配Action Model的价值在于实时识别当下正在发生的行为所以推理链路天然要求低延迟。如果你用的是深度序列模型跑一次推理需要几十毫秒在支付环节根本等不起。这个约束直接决定了你能在线上用什么模型、不能用什么模型。我的建议是分层部署最实时的那一层比如支付前决策只放Action Graph规则和轻量的统计模型保证整体延迟在10毫秒以内深度模型放到异步链路里做离线的批量扫描用于识别团伙和回溯分析。等你在离线异步里发现了新的风险模式再把它固化成实时规则这样既保住了实时性又让深度模型的价值真正发挥出来而不是为了用而用。4.3 冷启动新用户的行为序列太短怎么建模这是一个特别现实的问题。Action Model依赖行为序列可新用户就是没有行为序列。他一进来就下了人生第一单你怎么用行为序列判断他是不是黑产我的处理方式是分层兜底对于行为序列长度低于阈值的新用户以画像特征和设备风险为主Action Model的信号只作为辅助参考不做主要判断。等用户的行为序列足够长了再逐步提高Action Model的决策权重。这个行为长度阈值我一般定在5到10个关键动作太少的话统计意义太差判断起来不放心。4.4 评估体系模型指标不等于业务结果传统风控模型的评估大家习惯看AUC、KS这些模型指标。但精细化运营场景下这些指标很容易骗人。比如你用一个复杂模型把AUC从0.85提到了0.87看起来很漂亮结果发现它拦截的那些高风险订单里真正会让平台损失钱的只增加了0.01%反而误伤的好用户多了0.5%。这种情况下AUC是涨了业务结果反而更差了。所以我做精细化运营项目时评估口径会换成一套业务可感知的指标指标名称含义为什么比AUC更管用策略接受率被拦截的用户中事后人工复核确认确有风险的比例直接衡量有没有拦错人误杀率被拦截的正常订单数 / 全部正常订单数精细化运营最敏感的指标体验损耗时长用户从被拦截到问题解决的平均时长拦截动作对用户体验的实际伤害GMV挽回与GMV损失比风控拦下的风险交易金额 vs 误杀导致的交易流失金额从经营视角衡量风控的净价值这套指标虽然不那么科研但是在业务沟通会上特别好使。运营同学关心的不是你的KS涨了多少而是你帮我拦住了多少风险、又让我少流失了多少正经用户。做精细化运营的风控本质上是在帮平台算一笔风险与体验的账算得越清楚越能获得业务团队的信任。4.5 可解释性风控场景绕不开的关卡最后再聊一下可解释性。这可能是Action Model落地中最容易在后期被卡住的一环。我的做法是无论内部用了多复杂的模型对外输出的决策理由一定要回归到人话。举例来说模型内部可能是用Transformer捕捉到了用户从搜索到支付间隔过短且没有浏览详情页这个模式但对外展示给审核团队看的决策理由是用户支付速度显著快于正常用户且未浏览商品详情与平台正常用户的购物习惯差异较大。这样审核团队能快速判断要不要人工复核运营也能跟用户解释清楚。为了做到这一点我一般会给最终决策加一个决策解释层把模型的判断映射到几个可解释的风险因子支付过快、路径跳变、目标过度集中等再按风险因子的贡献度排序输出。这个解释层本身不参与模型计算但负责把模型的黑盒结论翻译成业务可理解的理由。上篇写到这里核心的逻辑框架差不多讲完了。老实说我从传统静态特征转向行为序列建模的这大半年最深的体会是风控算法这个岗位真正的分水岭不在于你会不会调Transformer而在于你愿不愿意跳出算分数、设阈值的舒适区去理解一段行为背后真实的人性——正常的犹豫、正常的比较、正常的比较半天最后没买这些都是有温度的。而Action Model的本质恰恰就是把这些有温度的正常变成模型眼里的先验知识让机器学会分辨谁在像人一样买东西谁在像机器一样完成任务。下篇我会接着写策略侧的东西怎么基于Action Model的输出设计分级处置方案怎么把风控决策从放行/拦截升级成弹窗验证、静默监控、限权观察、人工介入的多级体系以及大促场景下的模型稳定性保障。如果你也在做风控或者精细化运营欢迎带着问题来聊我们一起把这条路踩得更实一些。