概念定义：它回答的是哪一类决策问题
上个月有个做小语种工具类投放的客户来问我们一个事儿：同一批代理IP，设备指纹也是同一套，怎么有的访问者正常放行了，有的却给拦了？更邪门的是这俩在单点特征上基本看不出差别。这个提问其实正好把AB页跳转风控模型的适用边界给划出来了——静态特征已经分不出访问意图的时候，判断依据就得换，从"这个请求长什么样"挪到"这个访问者一路是怎么走过来的"。
说清楚点，AB页跳转风控模型指的是这么一套判定机制：在AB页跳转链路的判定环节里，拿访问者一次会话内的行为序列当主要输入特征，用序列建模的方法算出一个风险评分，再拿实时拦截阈值去做分流决策。它给出的不是"是或否"那种单一标签，是"评分加阈值比较"的结构化结果。所以同一条规则，阈值不一样，分流结论就能不一样。
有件事得先摆清楚，它不替代设备指纹体系，也不是IP信誉库的升级版。设备指纹和IP库管的是"这个访问环境可不可信"，序列行为建模管的是"这个访问环境在当前会话里的行为自不自洽"。两边是并联的，谁也替不了谁。
机制组成：序列行为建模的三个环节
序列建模头一件事，是把那些散着的请求日志整理成有序的行为单元。常用来做序列化的维度有这些：页面之间跳转的路径顺序、相邻请求的时间间隔分布、同一会话里目标页被重复访问了几次、滚动和交互事件的时间戳相对位置。这些维度本身不判风险，它们干的是搭一条能拿来比对的时间轴。
特征层真正难搞的地方在采集之后的对齐。同一个访问者在不同页面留下的日志，时间戳来源可能压根不一样——客户端事件一个来源，边缘节点日志一个来源，源站日志又是另一个。时钟基准要是没统一，序列就会被拉长或者压扁，后面算出来的评分跟着失真。我们一般要求同一条链路里统一时间基准，偏差超过设定范围的样本直接标成不可用，别硬修。
模型层：序列评分如何产生
模型层吐出来的是一个连续评分。常见的实现路子有这么三类：拿统计方法做序列距离度量，把当前序列跟已知的正常序列模板比偏差；用状态转移那套马尔可夫类模型，算路径转移概率连乘出来的似然；还有基于神经网络的序列编码模型，把变长序列压成定长向量再分类。这三条路在复杂度、可解释性、冷启动成本上差得挺远，怎么选，看业务是更看重"能解释"还是更看重"准确高"。
走哪条路都好，模型层必须留下能回溯的中间量。不然调阈值就成了盲调。回溯的最低要求是什么？每个评分都能对应到贡献最大的那几个序列片段，光给个总分不算数。
决策层：实时拦截阈值的比较逻辑
实时拦截阈值干的是把评分翻译成动作这件事。基本形式就是一条或者几条分数边界：低于下限走正常分流，高于上限进拦截或者降级分支，卡在中间那段进观察或者二次验证。"实时"体现在两个地方——判定得在请求等待窗口内做完，另外阈值本身能跟着流量结构变化重新下发，不用重启判定链路。
阈值从来不是一个数就完事。工程上一般按流量来源分层设，自有流量一套边界，联盟流量一套，陌生来源再一套。分层是为了让误判代价不一样的流量承担不一样的判定严格度，跟放宽标准没关系。
阈值标定的条件与限制
标定阈值靠两个前提撑着：一是已标注样本得够数，二是标注口径在标定周期里不能变。缺了哪个，标出来的结果都只是对历史斗篷系统接入第三方统计脚本后，数据对不上该按什么顺序校验？一份从信号分层到口径对齐的检查清单">数据拟合了一遍，直接拿去当线上边界用不合适。上线之前，下面这几项得一条条确认过：
样本覆盖：正常样本和异常样本的比例别太倾斜，不然阈值会往多数类那边偏。；口径一致：拦截、降级、放行这三类动作的定义，标定阶段和上线阶段必须一模一样。；延迟预算：序列建模带进来的计算耗时得落在请求等待窗口里面，超出的部分走异步补算，别拿去阻塞判定。；回退路径：阈值下发之后，上一版本的边界得留着能快速回退，而且回退这个动作本身不能依赖判定链路。。
限制这块也说清楚。短会话的判别力有限——就产生一两次请求的访问者，序列信息量撑不起一个评分，这时候模型输出只能当低置信度看，交给别的信号补判。流量量级特别小的项目，标注样本攒得慢，阈值长期收敛不了，这种场景先用固定规则过渡更合适。
实战案例：阈值分层后的一次调整
有个订阅制内容站的投放项目，日均点击量一千二三百那个量级，服务器两台中等规格的应用节点，判定链路和跳转逻辑部署在同一个进程里。刚上线用的是单一全局阈值，跑了大概两周，两类反馈同时冒出来：一部分来源的老访客被反复送进二次验证，另一部分来源的异常路径反倒没拦住。排查下来，评分本身没毛病，问题出在阈值只有一条线——老访客的会话序列天生就长，路径也复杂，评分分布整体偏高，被同一条线误伤了。
调整分了三步走。先按流量来源把样本拆成三组，分别看评分分布的分位落在哪；然后给每组设独立的上下边界，中间区间统一走观察分支，不直接拦；最后把阈值下发改成配置下发，上一版本边界留着快速回退。调完之后误判反馈明显少了，异常路径的拦截量也没掉。留下的经验就两条：阈值分层得按流量结构来分，拍脑袋按业务分类分不行；还有，序列模型上线前先跑一段只评分不拦截的观察期，不然真实分布形状你根本拿不到。
适用条件与不应由它解决的问题
什么情形适合用它？会话长度足够形成可辨识的序列，静态特征已经分不出访问意图，判定链路有明确的延迟预算，团队也能持续做标注和阈值复盘。反过来说，下面这些问题别往它身上推：
环境真实性判定：设备指纹对不上、请求头字段冲突这类，属于环境一致性校验的活儿，序列模型不管。；内容合规审查：页面文案、资质链核验是合规审计环节的事，跟行为评分不沾边。；账号权限与租户隔离：权限体系自己的职责，混进风控评分只会把责任边界搅糊。；流量质量归因：序列评分是判定信号，不能当转化归因的依据，两边口径不能混着用。。
相邻概念对比：与单点特征判定、规则白名单的差异
跟单点特征判定比，核心差异在输入结构上：前者看单个请求的属性快照，后者看一段时间里属性怎么演化。单点判定实现简单、延迟低，可一旦访问环境被批量复用，判别力掉得很快；序列建模对这类场景敏感得多，代价是计算复杂度和标定成本都上去了。选哪个，看的是当前流量结构下静态特征还够不够用，跟谁更先进没关系。
规则白名单那边，两者是互补的，不是竞争。白名单处理"已知可信"的放行，序列模型处理"未知是否可信"的评分。把白名单逻辑塞进评分模型，模型就得同时干记忆和判断两件事，阈值也跟着没意义了。合理的分工是这样：白名单在前头做确定性放行，序列评分在后头处理剩下的流量，实时拦截阈值只作用在评分结果上，白名单命中项它不碰。
边界一句话收个尾：序列行为建模解决"行为自不自洽"，实时拦截阈值解决"自洽到什么位置该换动作"。这两半合起来才是完整的AB页跳转风控模型，少哪一半，判定都会退化成拍脑袋。
