如果你做过一段时间的风控模型大概率遇到过这样的场景模型识别出某个用户是高风险账号等你去干预的时候对方已经把最后一单薅完了。反过来系统给优质用户打了一大堆标签推送了一堆权益结果对方不但没复购反而觉得被打扰直接流失。这两个场景放在一起看会发现传统预测模型有一个共同的尴尬我们一直在做判断却很少做决策。Action Model 在精细化运营里要解决的恰恰是这个问题。它不再只回答这个用户是否高危这个用户是否高价值而是更进一步回答在什么时间、对谁、采取什么动作才能让后续的结果最优。作为在风控算法圈子里摸爬滚打了这些年的人今天我想把 Action Model 的核心框架、建模思路和落地经验拆开讲清楚。这篇先讲上篇概念、原理和建模框架。合适看的人群是那些做风控策略、用户运营、增长算法或者正在从传统评分模型往决策模型转型的同学。1. 先搞清楚Action Model为什么会在风控圈火起来1.1 传统评分模型解决不了的最后一公里传统风控模型的核心产出是评分。评分卡、信用分、风险分、价值分本质都是在对用户状态做评估。评估完了怎么办通常的做法是人工制定规则分数大于多少就放行小于多少就拦截中间地带进入人工审核。这套逻辑在线下信贷场景里运行了很多年非常成熟。但到了精细化运营这个语境里只做评估就不够了。举个例子你给一个用户打上高潜力流失标签这个标签本身没有任何行动指导意义。你是该给他发券还是该给他打电话还是该给他推某个爆品如果发券发多少面额的券是满减还是直减时效设多久这些动作层面的问题评分模型一个都回答不了。我早期接手过一个权益反作弊项目发现很多用户并不是纯羊毛党他们只是对某些类型的权益特别敏感。用传统风险模型去识别这些人分数很低行为特征和正常用户几乎没区别。但如果换一个思路把是否给这类用户发放高折扣权益当成一个决策问题就会发现给某些人发直减券会带来亏损但给另一些人发满减券却能刺激真实消费。这就是最后一公里的价值——判断完之后你还得知道下一步该干什么。1.2 精细化运营的本质把动作本身变成优化目标我理解精细化运营并不是把人切得越细越好。把用户分成一百个群体每个群体给一套固定策略这只能叫细分运营不能叫精细。真正的精细是让每一个决策点都跟着状态实时变化让动作不再是拍脑袋定的规则而是模型优化的对象。Action Model 的思路就是把动作拉进模型里。它建模的对象不再是用户本身而是用户-动作-结果这三元组。换句话讲传统模型问的是这个人怎么样Action Model 问的是如果我对他做了这件事他会怎么样。前者是描述后者是决策。这个转变对风控尤其重要。因为风控本质上做的不是识别而是干预。识别出风险只是起点怎么干预、干预到什么程度、干预之后用户会有什么反应才是决定风控效果的关键。一个 Action Model 如果做得好它可以直接告诉你对当前这个用户最合适的动作是静默观察、限制额度、还是直接拦截而不是给你一个分数然后让你自己纠结阈值。1.3 并不是只有大厂才需要这套思路很多人听到 Action Model 第一反应是这是大厂才能玩的吧其实不然。任何一个业务只要存在你做一个动作、用户产生一个反应的闭环理论上都可以用 Action Model 的思路做优化。电商场景下优惠券、满减、直降、限时购、会员专享价这些都是动作。本地生活场景下推送、弹窗、短信召回、专属客服也都是动作。内容平台场景下Push 推送频率、创作者激励、话题运营还是动作。哪怕一个只有几千日活的小平台如果你能想清楚动作空间有哪些、收益怎么衡量、数据怎么回流照样可以搭一套轻量级的决策模型。反过来如果业务规模已经很大却还在用固定规则做运营那浪费的预算往往非常可观。我测算过一个营销场景把统一发券改成基于 Action Model 决策发不发、发多少之后同样的预算下 ROI 能提升大概百分之二十几。这东西不是锦上添花是实打实的利润。2. Action Model 到底在建模什么核心框架拆解2.1 三要素状态、动作、收益要理解 Action Model先记住三个词状态State、动作Action、收益Reward。状态是指当前你观察到的所有信息包括用户的基础属性、历史行为、实时上下文、环境信息。举个例子某个用户今天下午三点打开过 App浏览了三个商品页但没加购这些都属于状态。状态的核心要求是可观测你看不到的东西进不了模型。动作是指你能对用户施加的所有干预手段。这里有个关键认知动作空间不是越大越好得是业务上真实可执行的范围。比如你手上只有短信和 Push 两种触达渠道那动作空间里就只该有这两种。把不存在的动作建模进去模型再漂亮也无法落地。收益是指你希望最终优化的业务目标比如 GMV、转化率、留存率、坏账率。注意收益必须能量化而且最好能换算成统一的业务口径。这一点特别重要后面我会单独展开讲。这三者的关系可以简单描述为在某个状态 s 下你执行了动作 a然后产生了一个收益 r。Action Model 要学习的是从 (s, a) 到 r 的映射关系也就是所谓的动作价值。有了这个映射你就能在任意状态下去选择那个期望收益最大的动作。2.2 与传统预测模型的三个本质区别很多人觉得 Action Model 不就是多加了一个特征吗不是的它和传统预测模型有本质区别。我总结了三个最核心的差异。第一个区别是输入输出不同。传统预测模型的输入是状态输出是预测值。Action Model 的输入是状态加动作输出是动作对应的期望收益。你可以简单地理解成传统模型是一维函数 f(s)Action Model 是二维函数 f(s, a)。第二个区别是目标函数不同。传统模型优化的是预测准确率比如 AUC、LogLoss核心是让预测值尽量接近真实值。Action Model 优化的是决策收益核心是选出来的动作能带来最大的长期回报。预测准确率高不等于决策收益高这一点在运营场景里特别明显。第三个区别是数据生成方式不同。传统模型的训练数据是历史自然产生的用户是什么样就是什么样你只是一个旁观者。Action Model 的训练数据依赖于动作-反应必须要有真实的干预日志。也就是说它的数据是被策略生成出来的而策略又会影响后续的数据分布这形成了一个闭环。这三条区别决定了 Action Model 在实现层面的复杂度远高于传统评分模型。它不是一个算法替代另一个算法的问题而是整套建模范式都要换。2.3 用优惠券场景把概念落到地面上概念听多了容易飘我拿优惠券场景来举个具体的例子。假设你是一个电商平台现在要给一批用户发券。传统做法是先用一个模型预测用户的购买概率选一批高概率用户然后给他们发同一张满 100 减 20 的券。这套逻辑看起来没问题但实际上藏着两个坑。第一个坑是因果倒置。你选出来的高概率用户可能本身就是要买的人你给他们发券只是白送钱。经济学里把这个叫死重也就是这笔补贴并没有带来增量只是减少了毛利。第二个坑是动作单一。你只考虑了发券这一个动作没有考虑不发、发不同面额、发不同类型券的差异。事实上有些用户对满减敏感有些用户对直减敏感有些用户你越给他推券他越觉得你把他当傻子。如果用 Action Model 的思路来做你会先把动作空间定义好不发券、满 100 减 10、满 100 减 20、满 200 减 50、无门槛 5 元券一共五个动作。然后你会要求数据侧把每一次发券动作和后续的用户行为日志都关联起来。再然后你去拟合每个状态下每个动作的期望收益。最后在你需要做决策的那一刻模型会告诉你这个用户当前状态下选满 100 减 10的期望 GMV 增量最高而不是无脑地把最贵的券发出去。理解了这个小例子后面所有的建模细节就都建立在这个逻辑基础上。Action Model 不是什么玄学它就是把决策这件事从规则手里拿过来变成一个可学习、可优化的问题。3. 手把手拆解 Action Model 建模全过程3.1 第一步把动作空间做收敛我见过不少团队一上来就把动作空间设计得特别宏大渠道十几个、权益几十种、时间窗口还要分好几个档位组合出来上千个动作。结果模型训练起来极度困难样本被稀释到每个动作下都没几条数据整个项目最后卡死在数据稀疏上。我的经验是动作空间一定要收敛收敛到业务能解释、数据能支撑的程度。具体怎么做三个原则。第一个原则动作必须真实可执行。凡是线上没办法真正下发到用户身上的动作一律不进空间。比如我们知道给用户打电话召回效果好但你根本没有电话触达能力那这个动作就不该出现在模型里。第二个原则动作必须有区分度。你把两个渠道合并成一个动作如果业务上它们的效果差异不大那合并是合理的。如果 Push 推送 和 专属客服一对一沟通 明显是两种成本完全不同的事就不能混在一起。第三个原则动作组合层级不要贪多。我的习惯是先做一维动作也就是一次只决策一个维度比如只决策渠道或者只决策券面额。等一维动作的模型稳定了再做二维、三维的组合。不要一上来就想搞渠道权益时间全组合的大一统模型那不是建模那是自找麻烦。3.2 第二步状态特征到底该取哪些状态特征的设计决定了 Action Model 的上限。我把常用的特征整理成几类你可以对号入座。第一类是用户静态属性。这部分和传统模型差别不大包括性别、年龄、城市等级、会员等级、注册时长等。虽然它们对用户行为的解释力有限但作为基础状态是必须有的。第二类是用户历史行为。这是重头戏。最近一次下单时间、近 7 天下单频次、近 30 天消费金额、近 90 天客单价、品类偏好分布、平均浏览深度……这些都是传统运营模型常用的特征。在 Action Model 里它们的作用是描述当前这个用户处在什么状态。第三类是实时上下文。这一点容易被忽略但其实非常重要。比如当前是否处于大促期间、距离用户上次访问过去了多久、用户当前浏览的页面类型、当天是工作日还是周末、甚至是当前小时段。因为同样的用户在不同上下文状态下的最优动作可能完全不同。大促期间你可能不需要给他发券他自己就会买而日常沉默期你可能需要更大力度才能唤醒他。第四类是历史动作与反馈的交叉特征。这是 Action Model 区别于传统模型的地方。比如用户历史上收到过几次优惠券、最近一次收到是什么时候、收到之后有没有核销、核销后有没有复购。这类特征直接捕捉用户对动作的敏感性价值非常高。特征做太多会带来过拟合和线上特征延迟的问题。我的经验是先做减法把那些明显没区分度、覆盖率极低的特征去掉保留二十到三十个核心特征跑通一版基线再逐步做加法。不要一上来就堆几百个特征后面排查问题会非常痛苦。3.3 第三步收益函数是最难的无冕之王如果只能选一个环节认真打磨我会选收益函数。Action Model 里所有模型的参数更新都依赖收益信号收益函数定错了后面的功夫基本都是白费。收益函数设计的核心矛盾是长期收益和短期收益的权衡。你如果只优化点击率模型很可能学会用夸张的文案吸引点击但完全不带来下单。你如果只优化下单率模型可能倾向于把大量资源给到本来就快下单的用户造成上面说的死重问题。我推荐的做法是设计一个多目标的收益表达式把不同维度的业务指标换算成统一的价值分。一个简单的例子收益 交易贡献 × 系数 留存提升 × 系数 - 补贴成本 - 风险损失。交易贡献可以用 GMV 增量来度量注意是增量不是总量。留存提升可以用未来 30 天是否活跃这类指标表示。补贴成本就是券面额、渠道成本等直接花费。风险损失则包括羊毛党薅走的利润、逾期坏账等。这里有一个关键技巧系数怎么定。我的经验是不拍脑袋定而是用业务历史数据做校准。比如你拿过去一年的营销数据把每一次动作带来的 GMV 增量、留存变化、成本支出都算出来然后做一个回归或者简单的统计校准让收益函数的权重尽量和真实业务价值对齐。这一步非常花时间但对模型效果的影响远超模型结构本身。3.4 第四步训练方式和评估指标的坑Action Model 的训练方式按数据条件可以分为两类一类是有完整动作日志、并且做过随机化探索的可以直接用监督学习的方式拟合 f(s, a)另一类是没有做过多少探索、动作都是按规则发的这时候要小心直接拿历史数据训练会引入严重的选择偏差。什么叫选择偏差举例来说如果过去我们只在高价值用户身上发过大额券模型会学到大额券在高价值用户身上效果好这个结论。但事实上这可能只是因为你没在小额用户身上试过并不代表效果不好。这就是典型的分布外推断问题。我的建议是如果条件允许在策略冷启动阶段做一小部分流量随机分配动作拿这部分数据训练一个基线模型。随机流量比例不需要太高百分之五到百分之十就够。等基线模型稳定了再慢慢收敛到模型推荐的策略。评估指标上传统模型的 AUC 在这里只能作为辅助参考不能作为主要决策依据。Action Model 真正要看得是决策收益也就是离线模拟的时候在我选的策略下合计收益是多少对比基线策略提升了多少。我通常会用离线策略评估手段把历史日志重放一遍用模型预测每个状态下最优动作的收益和实际执行策略的收益做对比。这个差值就是你模型策略带来的增量收益。另外模型上线前一定要看清楚你对动作价值的预测是否存在系统性偏差。如果没有做样本加权或者纠偏极高的补贴动作往往会被高估因为能拿到高补贴的用户本身就有更强的购买意愿。4. 从模型到业务精细化运营到底怎么落地4.1 模型产出不是分数而是策略很多团队做 Action Model 容易犯一个习惯性错误模型训练完了上线了产出了一个分数然后把这个分数当成传统评分一样由运营同学去设置阈值、决定动作。这么一来Action Model 就白做了。我们要时刻记住Action Model 的产出是一个策略也就是在当前状态下选择哪个动作。它不是一个分数、一个概率而是一个决策建议。真正使用的时候应该是模型直接输出动作 id然后业务系统按照这个动作 id 去执行。拿优惠券场景来说模型输出的不是一个易购度分数而是给这个用户发满 100 减 20 券这个结论。如果你还在拿模型分数人工配规则选券说明你的系统架构还停留在传统模型时代。4.2 与推荐、触达、权益系统的实际操作落到技术上Action Model 通常需要和三个系统配合触达系统、权益系统和数据回流系统。触达系统负责执行动作里的渠道维度比如 Push、短信、弹窗、专属页。Action Model 决策完动作后要能实时或者准实时地把指令发给触达系统。这里要注意线上推理延迟的问题。如果你的动作决策要求实时比如用户刚打开 App 就要决定弹不弹券那模型推理必须在几百毫秒内完成。我的建议是尽量把模型做轻或者离线预计算高频状态下的动作策略做成缓存。权益系统负责执行动作里的权益内容维度比如券面额、券类型、有效期。权益系统需要提供足够的灵活性不然模型想发无门槛 5 元券权益系统只能在满减里面选那就出现模型策略和业务能力不匹配的问题。这也是为什么我强调动作空间必须真实可执行——模型能输出的必须保证业务系统接得住。数据回流系统是最容易被忽视的一环。Action Model 的生命力来自动作-反应数据的持续积累如果每次动作下发后用户后续的浏览、加购、下单、退款数据没能准确地关联回这次动作那模型的迭代优化就成了无米之炊。我有一个原则在模型上线前先把数据回流的埋点和链路彻底验证一遍再做模型。否则你以为自己在迭代模型实际上是在反复地原地踏步。4.3 风控与增长的协同统一收益函数做风控的人做 Action Model和做增长的人做 Action Model最大的分歧点在哪收益函数。增长同学可能只关心 GMV 和留存提升而风控同学还要关注风险损失、虚假交易、盗号、套利。如果两者各做各的模型就会出现一个典型的矛盾增长模型给某类用户发了一大张高折扣券结果引来了一批黑产账号疯狂套利风控模型把这类动作全部拦截增长指标又掉下去了。我踩过这个坑之后的体会是Action Model 在平台侧落地收益函数的设计必须由风控和增长双方一起定义。不是说谁服从谁而是把增长收益和风险损失放进同一个函数里用系数去权衡。比如收益 GMV 增量 留存增益 - 套利损失 - 赔付成本。这样一来增长同学追求 GMV 时模型会自发地去避开高风险的套利用户风控同学做拦截时也不会一刀切而是选择那些付出成本低、风险下降最明显的用户来动作。这个协同说起来简单做起来需要两边在目标和数据口径上对齐很久。但一旦对齐了收益函数就是团队共识的体现大家对模型的信任度和使用意愿会高很多。4.4 一套可复制的落地闭环流程我把自己跑通过的落地流程整理成了六步闭环你可以直接参考第一步盘点业务动作和期望目标。把当前业务里所有真实可执行的干预动作列出来再列出业务上最关心的三到五个指标。第二步设计收益函数和动作空间。按照前面讲的原则把动作收敛、收益对齐。这个阶段一定要业务同学深度参与因为只有他们清楚每个动作的成本、触达能力和风控红线。第三步启动小流量随机策略。随机分配动作不等于乱来可以限定在一个低风险用户群或是权益成本预算可控的范围内。目的是把动作-反应的数据分布做平为模型训练打好基础。第四步训练基线模型。用随机策略积累的数据训练一版基线 Action Model离线评估其相比当前规则策略的收益增量。第五步小流量上线验证。拿百分之十到二十的流量把模型推荐策略和当前运营策略做 AB 对比观察收益函数里的各项指标变化不要只看单一指标。第六步逐步放量并持续积累数据。效果稳定后逐步扩大流量占比同时保持一定比例的探索流量持续把新数据回流进训练集定期更新模型。这个闭环我从几个不同规模的业务里跑过最大的体会是每一步都可能遇到意想不到的数据问题和策略适配问题但只要你按这个顺序走至少不会出现模型明明离线指标挺好线上却一堆事故的大翻车。5. 实战中踩过的坑和排查思路5.1 五个典型的建模翻车现场第一号翻车现场动作空间和实际系统脱节。模型训练阶段一切都好上线时需要对接触达系统结果发现某个动作渠道根本没有接口或者某个券类型在权益系统里根本创建不出来。看起来是个小问题实际上直接把整个上线计划打乱了。我的建议是在建模启动前把动作空间的可行性清单让研发同学签字确认。第二号翻车现场收益函数里的短期指标把模型带偏。曾经有一个案例收益里放了点击率指标权重还不低结果模型学出来的策略变成给用户推送夸张的标题和红包样式点击率上来了但真正下单转化反而降了。后来把收益函数里的按钮点击这类中间指标全部移除只保留最终业务指标问题才解决。这里面有个经验收益函数尽量用终端业务指标不要用中间漏斗指标。第三号翻车现场数据穿越。做特征的时候不小心把用户是否使用过优惠券这种在决策时点之后才产生的信息放进特征里模型离线表现异常好上线就崩塌。排查方法很简单特征构造的时间戳必须严格早于动作下发的时间戳每个特征都要过一遍时点审查。第四号翻车现场高价值用户的动作探索不足导致模型偏见。前面提到过选择偏差具体表现就是模型对低价动作和沉默用户的组合预测得非常不准因为历史上这类组合几乎没发生过。解决思路是在行为较冷区域增加一些随机化探索流量让模型对未知组合也有数据支撑。第五号翻车现场模型迭代周期跟不上业务节奏。Action Model 依赖的数据闭环天然有延迟如果你要求每天都更新模型但业务数据回流链路要 T2 才完整那模型训练出来的策略可能已经滞后了。我的做法是把模型分为离线日更版和实时轻量版日更版用于常规运营轻量版用于实时触达决策两者共用收益函数但特征和复杂度不同。5.2 离线指标很好、线上没有效果怎么排查这是最让人崩溃的问题没有之一。模型离线评估提升了百分之三十的收益上线跑了两周业务报表里什么变化都没有。我整理了一套排查顺序按这个顺序走基本能找到问题。先查数据分布是否一致。比较一下训练数据的特征分布和线上实时特征的分布看有没有明显的漂移。很多时候模型学到的是某个特征里的噪声规律分布一变就失效。再查动作执行率。模型推荐了动作不等于业务系统真的把动作发出去了。渠道限流、频控、黑名单过滤都可能导致大部分推荐动作没有实际触达用户。这时候你看到的效果肯定等于零。然后查收益归因是否打通。用户收到动作之后产生了购买这笔购买有没有被正确地归因到这次动作上如果在归因链路上丢了数据那你的效果评估出了问题而不是模型出了问题。最后查实验设计。对照组的流量分得是否均匀有没有存在用户本身在不同组之间的策略互相干扰AB 实验时长是否覆盖了足够完整的业务周期这些看起来是工程问题但实际上非常影响对模型的判断。5.3 团队协作里最容易被忽略的一件事Action Model 项目比传统模型更依赖跨团队协作但很多协作卡点根本不在技术层面而是在语言层面。增长团队说的转化率风控团队说的欺诈率数据团队算的用户活跃三个口径放在一起经常对不上。有一次我们上线后的收益数据对不上账业务说涨了财务说亏了最后排查了一个星期发现是GMV 增量的统计口径不一致一个用了应结算金额一个用了实收金额。这类问题特别消耗团队士气。我的建议是项目启动的第一周专门花半天时间把所有关键指标的定义、统计口径、取数逻辑全部对齐一遍写成文档放在共享空间里。看着好像很浪费时间但后面节省的时间至少是十倍。这个动作做好了模型的收益函数设计、AB 实验评估、财务核算都能快速达成一致。5.4 常见问题速查表问题可能原因排查思路模型离线表现极好线上崩特征穿越、数据分布漂移检查特征时点对比训练/线上特征分布动作空间太大导致样本稀疏组合维度过多先做一维动作建模再逐步加维度高补贴动作收益被高估选择偏差、探索样本不足增加随机化探索流量训练时加样本加权模型推荐策略执行不了动作空间和业务系统脱节建模前拉业务研发确认动作可行性清单AB 实验没效果执行率低、归因链路断排查动作是否真实下发验证归因埋点数据收益函数里放中间指标导致行为走偏优化目标和最终业务目标不一致移除中间漏斗指标只保留终端业务指标如果你目前还在从传统预测模型转向 Action Model 的阶段我的建议是先找一个动作空间小、收益链路清晰的场景练手不要一上来就挑战全平台大规模营销决策。把收益函数、数据回流、随机探索这一整套闭环跑通再逐步扩大动作空间和业务范围这条路会走得稳很多。最后再分享一个我在实际业务中最深的体会Action Model 的威力不在于模型本身有多先进而在于它逼着你把业务目标是什么、动作有哪些、成本怎么算、数据怎么回流这些最基本的问题想清楚。很多团队做不好不是算法不行是业务定义和工程链路没有跟上。这个部分讲完上篇暂时告一段落下一篇我会继续拆解更进阶的内容离线策略评估的具体方法、多目标收益函数里权重怎么调以及如何把这类模型和实时决策系统做深度打通。