AI风控系统中的实时决策架构架构师的关键设计去年底我们做了一次全链路压测目标TPS是8000结果第一轮压测还没跑满10分钟风控决策服务的TP99就直接冲到了850毫秒而业务方给我们的硬性预算只有200毫秒。当时监控大屏上那个红色告警刷了整整一屏值班同学就差把电话打到我手机上了。这不是个别案例。这些年做AI风控系统我见过太多团队在模型精度上死磕却忽略了实时决策这四个字里实时的分量。一个XGBoost模型训练到AUC 0.95上线后单次推理要80毫秒特征拼接又要50毫秒再叠加规则引擎的几十次内存遍历一次完整决策下来早就超过了业务容忍线。拦截率再漂亮接口超时一样会把用户逼走甚至引发连锁的支付失败客诉。这篇东西不聊算法调参也不聊怎么训练一个更准的模型。我要聊的是AI风控系统中实时决策架构成型过程中一个架构师真正需要拍板的事情性能预算怎么分、决策引擎怎么分层、特征从哪来、模型推理怎么做降级、以及线上出问题时该怎么排查。我尽量用我们实际踩过的坑和验证过的方案来讲能落地的那种。1. 先把实时拆成具体数字性能预算和决策链路拆解很多架构师拿到实时风控这个需求第一反应是上Redis、上Flink、上GPU推理服务。但真正接手后你会发现最难的不是选型而是把实时这个模糊的形容词翻译成一组可量化、可拆解、可验收的工程指标。没有数字锚点后续所有设计都是拍脑袋。1.1 从业务容忍度推导RT预算一个典型的实时风控决策流程是这样的用户发起一笔支付或注册请求业务后端调用风控服务风控服务同步执行规则和模型返回放行/拦截/人工审核的三元结果。这个同步调用的时间窗口就是业务给我们的容忍度。电商支付场景下支付网关整体超时时间通常是1秒到1.5秒风控要在这条链路上扣掉网络开销、业务后端的序列化时间和数据库读写时间真正留给风控决策引擎的往往只有150到250毫秒。我在项目启动会上给业务方算过一笔账假设业务侧P99链路时间是900毫秒其中网络和框架开销占300毫秒业务逻辑占350毫秒数据库操作占100毫秒那么风控最多只能吃下150毫秒。这个150毫秒是P99口径不是平均值——意味着我们要按最坏情况去设计架构而不是按理想情况。信贷审批或注册环节如果允许异步决策RT预算会宽松很多可能按秒级设计。但电商交易、优惠券核销这类场景用户和商品之间没有等一下的心理预期必须按同步调用来做。所以架构师拿到需求后第一件事不是画架构图而是搞清楚这个决策到底是同步还是异步是硬实时还是软实时。这个判断直接决定了后面所有技术选型的走向。1.2 决策链路的耗时拆解90毫秒去了哪儿确定150毫秒总预算后我们把它进一步拆成了三块特征拉取30到40毫秒包括从Redis批量读取设备指纹、用户历史行为统计、IP维度的聚合特征以及从外部数据源同步过来的黑名单、征信分等信息。规则执行20到30毫秒几十条核心规则的内存条件判断加上部分需要查缓存的名单类规则。模型推理30到50毫秒两到三个打分模型的串行或并行推理视模型复杂度而定。这样拆完还剩30毫秒左右的buffer留给网络抖动、GC停顿和突发流量。拆完之后我们就有了明确的性能预算表开发同学在做每一块功能时都有了一个不要超出这个时间窗口的强约束。比如写特征服务的人看到预算只有40毫秒就不会傻傻地在循环里逐条LGET Redis做模型服务的人看到预算50毫秒也就理解了为什么我们要求把模型文件序列化进内存而不是每次动态加载。1.3 什么决定了决策必须同步完成这里想多说一句为什么风控决策非得这么急。交易类场景的本质是钱货两清风控作为一道闸门拦在转账或下单的路径上如果不给出实时结论业务就只能选择放行——而放行就意味着风险敞口。异步审核虽然能查出问题但钱已经付出去了货已经发出去了追回成本极高。所以我们看到的几乎所有支付风控都是同步决策为主、异步补充为辅。同步决策保证坏人进不来异步分析负责进来的人后续可疑行为监测。实时决策架构的第一性原理就是在有限的时间预算内用尽可能完整的信息做出尽可能准确的风险判断。时间预算锁死了信息获取的上限架构设计就是在跟时间赛跑。2. 决策引擎的分层设计请求进来以后先做什么、再做什么预算拆完之后接下来就是架构分层。我把风控决策引擎划分为四个层次接入层、编排层、执行层、数据层。每一层只干自己该干的事层级之间通过明确的接口通信避免模块之间互相渗透、互相拖累。2.1 接入层流量清洗与协议适配接入层是全系统最靠前的一道防线负责接收各类业务方请求。不同业务方协议五花八门有HTTP JSON、有Dubbo、有gRPC还有直接上报MQ的。接入层要做的就是协议转换、参数校验、鉴权认证以及最基础的流量限流。这里有个容易被忽视的细节接入层一定要做参数级别的合法性校验而不是把脏数据丢给后面的规则引擎和模型。有次我们排查一个诡异的特征异常追了半天发现是某个业务方把一个本该是整数的字段传成了字符串null导致特征拼接时整个特征向量全部错位。后来在接入层加了严格的数据类型检查和枚举校验这类问题基本绝迹。接入层本身不参与任何决策逻辑所以它必须做到无状态支持随意水平扩展。当大促流量暴涨时我们只需要对这一层扩容就能扛住大部分压力。2.2 编排层决策流解析与节点调度编排层是整个决策引擎的大脑负责把一份决策流配置解析成可执行的有向无环图然后按照依赖关系调度各个节点执行。我们基于自研的轻量级DAG引擎来做编排。每个决策流由若干节点组成节点类型包括规则集节点、模型节点、名单查询节点、自定义脚本节点。DAG引擎负责并行化调度没有依赖关系的节点把原本串行的执行路径压缩到最短。比如名单查询和特征拉取没有依赖关系就可以并行执行模型A的输出如果作为规则C的输入那就必须先等模型A跑完。这里踩过一个坑早期版本用JsonPath硬编码决策流每加一个新场景就要改代码发版效率极低。后来迁移到配置化之后策略同学通过可视化界面拖拽编排完成一次新场景接入从两天缩短到两小时。但配置化也带来了新的问题——配置本身需要严格的版本管理和权限控制否则一个误操作就可能让线上决策逻辑整体跑偏。2.3 执行层规则引擎与模型推理的分工协作执行层是真正完成计算的地方。规则引擎负责跑确定性的逻辑判断模型推理负责跑概率性的风险打分。两者不是替代关系而是互补关系。规则引擎这一层我们用的Drools团队很熟但为了极致性能核心路径上的高频规则没有跑在Drools里而是翻译成了直接的内存对象迭代。为什么这么做Drools的规则匹配确实方便但每次会话构建和匹配过程的开销在毫秒级到十几毫秒不等。对一些低频场景可以用但对全量交易请求来说这种开销太奢侈了。我们只把Drools用于一些需要频繁修改、复杂逻辑判断的非核心场景核心路径上的规则全走自研的轻量级表达式引擎。模型推理层则是我们在性能优化中投入最多的部分。我们把训练好的模型序列化为PMML或ONNX格式部署到独立的模型服务中通过gRPC对外提供推理能力。并行加载多个模型文件到内存省去每次请求的动态加载开销。推理时如果模型之间有依赖就串行没有依赖就并行。实测下来两个梯度提升树模型并行推理的总耗时能控制在30毫秒以内。2.4 数据层一切决策的燃料仓库数据层为决策提供实时的上下文信息包含用户画像、设备指纹、历史行为序列、IP情报、黑名单库等。这些数据散布在Redis、HBase、关系型数据库和外部API中执行层需要快速把它们汇聚到一起。我们在数据层之上封装了一层统一特征服务Feature Service屏蔽底层多数据源的差异。特征服务对外提供按实体批量取特征的接口入参是用户ID、设备ID、订单ID等实体标识出参是一份扁平化的特征字典。特征服务的内部逻辑是并行去Redis、HBase等存储捞数据做必要的聚合计算再统一返回。这样特征拼接的逻辑收敛在一个地方规则引擎和模型服务不需要关心数据从哪来。数据层最怕的是热点key和缓存穿透。一次大促期间某个头部主播直播间涌入了海量下单请求都集中在一个商品ID上结果Redis里那个商品维度的特征key被打穿瞬间流量全部压到HBase和数据库导致特征服务整体延迟从10毫秒飙升到300毫秒最终拖垮了整个决策链路。这个坑让我们后续专门针对热点key做了本地缓存加分布式锁的多级防护。3. 特征数据的时间窗口实时特征计算与存储选型风控决策的质量极大地依赖于特征数据的时效性。一个基于过去5分钟该设备尝试登录次数的特征如果数据延迟了15分钟才更新那它的风险判别意义就大打折扣了。3.1 离线特征与实时特征的分工风控特征从时效维度可以分成三类离线特征T1更新的用户长期行为画像比如历史交易偏好、复购周期、长期活跃度。这类数据适合批量计算存放到HBase或ClickHouse中供查询。准实时特征分钟级延迟的聚合统计比如最近1小时的下单次数、最近30分钟的支付失败次数。实时特征秒级甚至毫秒级延迟的数据比如当前请求的IP是否命中已知代理IP库、这台设备在最近1分钟内是否同时发起了多笔来自不同账号的请求。离线特征解决的是这个用户平时是什么样的实时特征解决的是这一刻这个用户在做什么。风控规则里最有杀伤力的往往是实时特征——因为它刻画的是当前行为存在的异常模式。3.2 流式计算在实时特征中的角色实时特征的计算我们选择了Flink作为核心引擎。业务方将交易事件、登录事件、营销动作等埋点消息实时上报到KafkaFlink消费这些消息后在窗口内完成聚合计算计算结果写回Redis。规则引擎在做决策时直接从Redis读取这些预聚合好的实时特征。比如我们有一个重要特征叫短时间同设备多账号登录数定义是同一设备ID在过去5分钟登录过的不同账号数量。用Flink做这个聚合非常自然按设备ID分组开5分钟的滑动窗口窗口内对账号ID做去重计数。计算结果实时写入Rediskey是设备ID时间窗口value是去重后的账号数。这里要特别小心窗口对齐的问题。Flink的事件时间和处理时间在乱序数据下会出现偏差如果特征数据晚到窗口计算结果可能不完整。我们采用的方案是允许一定程度的延迟数据allowedLateness同时用旁路输出把这些延迟数据记录下来做校正。风控场景可以接受秒级的特征延迟但绝不能接受因为窗口计算错误而导致的特征数值系统性偏低。3.3 Redis使用模式的演进从缓存到特征数据库早期我们只用Redis做黑名单缓存和Session存储后来发现它完全能支撑实时特征的读写需求后逐步演变成了特征数据库的角色。演进过程中踩了不少坑大Value问题。有段时间我们把用户近30天行为明细列表直接塞进了一个Redis key里单个value超过1MB。结果每次读取这个key都消耗大量网络带宽和序列化时间还拖慢了Redis所在节点的整体性能。后来改成只存聚合后的统计值明细数据移到HBase。逐出策略问题。默认的allkeys-lru逐出策略会把一些虽然不常用但关键时刻很重要的大促活动特征key给逐出了。我们改成volatile-lru只对设置了过期时间的key做逐出核心特征key设置为永不过期。序列化方式问题。从JDK原生序列化切换到Kryo或Protobuf之后Redis读写的CPU开销明显下降。这个优化对特征服务延迟的改善比扩容还明显。3.4 冷热特征分离与特征预加载不是所有特征在每一次决策中都会被用到。我们在实践中做了冷热分离热特征每次决策几乎必查的特征比如订单金额、用户历史交易次数、设备风险等级。这些提前加载到一个进程内本地缓存中避免每次决策都远程访问Redis。温特征大多数决策会用到但偶有遗漏的特征比如IP归属地风险评分。放在Redis中批量流水线获取。冷特征只有特定业务场景才会用到的深层画像比如用户关系图谱指标。存放在HBase或ClickHouse按需加载。本地缓存带来两个风险数据一致性风险和内存压力风险。为了解决一致性我们通过Redis的Pub/Sub订阅特征变更事件本地缓存在收到事件后主动失效对应key为了控制内存本地缓存设置了最大条目数和基于LRU的淘汰策略。实测下来热特征本地缓存的命中率在92%以上决策链路不用每次都在特征拉取上消耗几十毫秒的网络往返。4. 模型推理的实时化方案超时控制、降级与预案风控系统里最脆弱的环节往往不是规则引擎而是模型推理服务。规则引擎是确定性的只要代码没bug执行时间基本稳定模型推理却受模型大小、输入维度、GPU资源竞争等因素影响延迟波动会很明显。AI风控系统的实时决策架构必须为模型推理的不稳定性留好退路。4.1 推理服务的独立部署与隔离我们的模型推理服务是独立部署的一组集群与规则引擎物理隔离。这样规则引擎因为流量突增而抖动时不会拖垮模型推理反过来模型推理因为复杂的神经网络计算产生毛刺时也不会耗尽规则引擎所在节点的CPU。在部署策略上有两个选择CPU推理和GPU推理。早期我们图省事统一用CPU跑XGBoost和浅层神经网络模型小的时候延迟还能压住。后来升级到深度模型之后CPU推理的P99从30毫秒涨到了90毫秒体感非常明显于是我们把深度模型迁移到GPU推理效果立竿见影P99回到了20毫秒以内。GPU推理的坑在于冷启动和显存占用。我们有个模型服务曾经因为显存泄漏运行4小时后被系统OOM Kill导致大规模超时。后来加了显存监控和定期重启机制并配合多副本滚动发布把这个问题稳住了。4.2 超时控制宁可快速失败不能无限等待在同步决策链路里最忌讳的就是等待一个永远不回来的结果。我们在模型推理客户端设置了严格的超时时间——默认80毫秒超过就快速失败进入降级分支。降级分支的策略是优先使用规则引擎已有的判定结果。如果规则层已经出现强拦截信号比如命中黑名单模型超时不影响最终拦截结论。如果规则层没有明确结果则回退到一个保守的小模型或者固定阈值策略。这个保守策略宁可误杀也不能漏过因为在实时决策的语境下模型超时本身就是一个值得警惕的信号。将超时样本记录到日志和消息队列中后续做异步补偿分析评估模型服务是否出现系统性故障。这里有个设计细节超时时间不能是固定值而是要根据模型服务的实时健康状态动态调整。我们通过注册中心下发动态配置当模型服务健康检查异常时自动把超时时间从80毫秒下调到30毫秒同时把更多流量切换到规则引擎兜底。4.3 熔断与降级的触发条件熔断机制的触发不能只看错误率还要看延迟分布。我们采用了类似Hystrix的信号量隔离模式每个模型服务实例维护一个熔断器。当最近30秒内的请求错误率超过15%、或P99延迟超过预设阈值、或并发线程数超过信号量上限时熔断器打开后续请求直接走降级策略不再尝试调用模型服务。熔断器在半开状态下会放少量试探测流量一旦探测成功就自动关闭熔断器恢复正常调用。这套机制上线后我们经历过几次模型服务所在机房网络抖动风控决策链路都平稳扛住了没有出现大规模超时。切记降级策略不是临时代码而是正式架构的一部分。降级分支里面的兜底规则、保守阈值、日志逻辑都要经过充分测试绝不能等线上出问题时才临时拼凑。我们专门设计了一套降级演练机制每个月强制进入一次模型降级状态确保兜底路径不出幺蛾子。4.4 模型版本管理与灰度发布模型推理服务最容易出问题的场景不是上线初期而是模型版本迭代。新模型在离线评测集上AUC更高不代表线上效果一定更好——特征分布漂移、数据口径变化都可能让新模型翻车。我们建立了模型灰度发布的标准流程影子模式新模型与线上老模型并行运行但新模型的输出只记录不参与决策。通过对比两者的打分差异和风险命中情况评估新模型的稳定性。金丝雀发布将决策链路上的一部分真实流量比如5%切到新模型并实时监控拦截率、误杀率、通过率等业务指标。与老模型的同期指标做对比如果差异超出设定阈值自动回滚。全量发布金丝雀稳定运行一段时间后逐步放量到100%。这个流程看起来简单但实际执行中要顶住业务方的压力。有一次新模型离线AUC提升了0.02业务方急着上线但我们坚持先跑一个完整的灰度周期。结果影子模式下发现新模型对某个特定线上场景的误杀率飙高了8倍差点酿成大事故。从那以后团队再没人质疑模型灰度流程的必要性。5. 一次线上事故的完整排查链路从决策超时到特征服务抖动纸上谈兵够了我讲一个我们真实经历过的线上事故。这是我认为架构师必须拔高认知的一个案例——一个表象极其简单的问题背后牵出的是一条完整的依赖链条。5.1 事故现象和初步定位那天是大促期间的晚间流量高峰监控告警突然炸了风控决策服务的P99延迟从60毫秒飙到了420毫秒同时错误率从0.1%升到了3.2%。第一反应是模型推理服务出了问题因为它是全链路里最不稳定的环节。但打开模型服务的监控面板发现它的P99只有35毫秒错误率也在正常范围内。接着看规则引擎的日志发现大部分耗时都花在了等待特征服务返回上。于是迅速把目标锁定到特征服务。5.2 特征服务为什么变慢进入特征服务的监控后我们看到一个扎眼的指标它访问Redis的P99耗时从原来的5毫秒涨到了200毫秒。正常情况下访问Redis应该是亚毫秒级到毫秒级200毫秒意味着Redis集群一定出了状况。查Redis集群的慢查询日志发现集中在一类命令上HGETALL user_feature:{userId}。这类命令之所以慢是因为它一次性获取了一个哈希表的所有字段和值。问题在于用户特征哈希表的字段数量是动态增长的——正常情况下一个用户有几十个特征字段但当天有大量用户在同一时间段内产生了密集的写入操作导致部分用户的哈希表膨胀到了几千个字段。一个大哈希表的HGETALL会阻塞Redis单线程模型进而拖垮同一节点上的其他请求。5.3 根因上游事件洪峰引发的特征膨胀为什么哈希表会膨胀追到上游才发现营销团队当天临时发起了一个分享得优惠券的活动活动规则里要求风控对每一次分享动作做实时检测。分享事件被接入到Flink实时计算任务中Flink又把用户的分享行为逐条写入到Redis的特征哈希表里。由于分享事件量远远超过了我们的预估单个用户的哈希表字段数在短时间内暴涨。这里暴露了两层问题一层是Flink实时计算任务没有对写入Redis的特征做上限控制和窗口剪裁另一层是Redis端的HGETALL操作没有针对大哈希表做保护。5.4 修复方案与长期防护短期内我们做了三件事将特征哈希表的写入逻辑改成滑动窗口内只保留最近30分钟的行为摘要超过窗口时间的数据自动过期。将HGETALL改成对逻辑的替换——通过分批HMGET只取最近用到的特征字段子集把单命令耗时降下来。在Redis侧配置了hash-max-listpack-entries参数限制单个哈希表的节点规模。长期来看这个事故推动了三个架构改进第一特征服务增加了对数据源响应耗时的熔断能力。当Redis P99超过50毫秒时特征服务主动降级返回部分缓存的特征快照不再无限等待Redis返回。第二Flink写Redis的流程增加了写放大保护每窗口最多写多少字段、每个key最多保留多少字段都有硬限制超限的数据进入旁路日志而不是直接写入。第三我们建立了一个全链路压测机制每次新活动上线前必须在压测环境模拟预期流量倍数确保不会因为活动流量激增而击穿风控系统。事后复盘时我们承认一个深层教训实时决策架构的鲁棒性不能只靠下游防护上游数据的无界增长本身就是最大的风险源。架构师必须对数据源头的写入特性保持敏感——任何无限增长的结构早晚会变成线上事故的定时炸弹。6. 架构演进的思考实时决策系统的下一次跃迁前面讲的是当下的架构是如何搭建的。但从2025年回头再审视这个系统又出现了一些新的需求和挑战比如更复杂的多模型融合、更细粒度的实时特征、更频繁的策略更新节奏。这些压力正在推动实时决策架构朝新的方向演进。6.1 决策沙盘与仿真能力的构建过去我们上线一个策略或模型只能依赖灰度发布来验证效果风险大且周期长。为了缩短验证闭环我们正在构建一个决策沙盘环境。沙盘的核心能力是支持用历史真实流量回放来模拟新策略的决策结果。具体做法是把历史交易请求完整记录到对象存储中包含当时的特征快照和决策结果。新策略上线前在沙盘中加载这些历史数据将新策略与历史策略并行运行快速计算新策略的拦截率、误杀率、以及如果新策略当时生效能挽回多少资金损失。这套沙盘系统对实时决策架构提出了新的要求——特征回放能力。它需要把历史特征快照原样还原而不是用当前时刻的特征值去跑历史决策。所以我们开始为实时特征存储引入快照语义每次决策时生成的特征向量都持久化一份到列式数据库中作为后续回放的时间胶囊。这个能力上线之后策略迭代速度提升了至少一倍而且很多灰度阶段才能发现的问题在沙盘阶段就被过滤掉了。6.2 决策结果的解释性与可审计性AI风控系统面临另一个常态化挑战监管和合规对决策解释性的要求越来越高。当系统拦截了一笔交易业务方要能清晰回答为什么拦用户申诉时也要能给出合理的解释。我们的方案是决策全程留痕。每一次实时决策都会记录决策流版本、规则命中明细、模型输入特征摘要、模型打分结果、以及最终决策和置信度。这些信息写入审计日志系统支持事后快速查询。为了让解释自然流畅我们把规则命中路径整理成了决策解释树——从根因出发一层层展示因为特征A异常所以触发了规则B规则B的权重又推动了模型C的打分。这个能力在架构层面看起来只是加了个日志但实际影响很大审计日志的写入不能阻塞主链路所以我们用异步方式落库同时日志量巨大需要按业务线分区存储冷热分离。我建议所有做风控架构的同学在这个方向上提前布局不要等监管来要求再临时补救。6.3 边缘计算把决策推近用户延迟永远有进一步压缩的空间。在一些对延迟极度敏感的场景——比如本地生活APP的下单支付、游戏内的虚拟物品交易——用户根本感知不到风控的存在每多10毫秒的等待都会带来流失风险。所以我们开始探索边缘节点上做轻量级风控决策的可行性。思路是把核心拦截逻辑黑名单、设备指纹、高频交易限制下沉到离用户最近的边缘节点边缘层直接做初筛。只有初筛通过或者命中需要深度模型判断的场景时才把请求转发到中心风控集群做完整决策。这样绝大多数请求可以在边缘层就以极低延迟结束风控流程中心集群的处理压力也大幅下降。边缘节点上的模型不能太大所以我们的做法是用知识蒸馏把中心大模型压缩成轻量级模型部署到边缘。轻量模型负责80%的常规决策中心大模型专攻那些模糊边界的高难度样本。这套方案还处于内部验证阶段但我认为它是未来几年AI风控架构绕不开的发展方向。6.4 架构师在AI风控系统中的角色最后说点更感性的体会。AI风控系统的架构师不能只埋头于技术细节必须时刻保持对业务风险的敏感度。架构设计里的每一个性能预算、每一个降级策略、每一层缓存设计最终都是为了让业务在风险可控的前提下跑得更快更稳。一个合格的风控架构师需要同时理解三件事业务侧对延迟和通过率的诉求、算法侧对特征和模型精度的诉求、以及运维侧对系统稳定性和可观测性的诉求。这三者经常存在矛盾——特征越全决策越准但延迟越高模型越复杂识别能力越强但推理越慢。架构师的价值就是在这些矛盾的夹缝中找出一条工程上最优的路径。我个人非常推崇一种工作方式定期把系统里最慢的一次决策调用和最复杂的一个决策流拎出来分析反复问自己这次决策为什么要花这么久这条路径能不能再砍掉一个环节。一次次较真下来系统的实时性能会得到持续改善。如果你正在设计或重构一套AI风控系统我的建议是先从业务方拿到明确的性能预算再按预算去倒推每一层的技术选型和取舍。永远不要为了追求某个组件的单点性能而忽视整条链路的平衡。实时决策架构没有银弹它是一连串合理的取舍。所谓架构师的关键设计就是在所有约束条件里找出那个“当前最优”的平衡点。这条路上踩过的坑将来都会成为你最有价值的判断依据。
AI风控实时决策架构设计：从性能预算到降级与故障排查
AI风控系统中的实时决策架构架构师的关键设计去年底我们做了一次全链路压测目标TPS是8000结果第一轮压测还没跑满10分钟风控决策服务的TP99就直接冲到了850毫秒而业务方给我们的硬性预算只有200毫秒。当时监控大屏上那个红色告警刷了整整一屏值班同学就差把电话打到我手机上了。这不是个别案例。这些年做AI风控系统我见过太多团队在模型精度上死磕却忽略了实时决策这四个字里实时的分量。一个XGBoost模型训练到AUC 0.95上线后单次推理要80毫秒特征拼接又要50毫秒再叠加规则引擎的几十次内存遍历一次完整决策下来早就超过了业务容忍线。拦截率再漂亮接口超时一样会把用户逼走甚至引发连锁的支付失败客诉。这篇东西不聊算法调参也不聊怎么训练一个更准的模型。我要聊的是AI风控系统中实时决策架构成型过程中一个架构师真正需要拍板的事情性能预算怎么分、决策引擎怎么分层、特征从哪来、模型推理怎么做降级、以及线上出问题时该怎么排查。我尽量用我们实际踩过的坑和验证过的方案来讲能落地的那种。1. 先把实时拆成具体数字性能预算和决策链路拆解很多架构师拿到实时风控这个需求第一反应是上Redis、上Flink、上GPU推理服务。但真正接手后你会发现最难的不是选型而是把实时这个模糊的形容词翻译成一组可量化、可拆解、可验收的工程指标。没有数字锚点后续所有设计都是拍脑袋。1.1 从业务容忍度推导RT预算一个典型的实时风控决策流程是这样的用户发起一笔支付或注册请求业务后端调用风控服务风控服务同步执行规则和模型返回放行/拦截/人工审核的三元结果。这个同步调用的时间窗口就是业务给我们的容忍度。电商支付场景下支付网关整体超时时间通常是1秒到1.5秒风控要在这条链路上扣掉网络开销、业务后端的序列化时间和数据库读写时间真正留给风控决策引擎的往往只有150到250毫秒。我在项目启动会上给业务方算过一笔账假设业务侧P99链路时间是900毫秒其中网络和框架开销占300毫秒业务逻辑占350毫秒数据库操作占100毫秒那么风控最多只能吃下150毫秒。这个150毫秒是P99口径不是平均值——意味着我们要按最坏情况去设计架构而不是按理想情况。信贷审批或注册环节如果允许异步决策RT预算会宽松很多可能按秒级设计。但电商交易、优惠券核销这类场景用户和商品之间没有等一下的心理预期必须按同步调用来做。所以架构师拿到需求后第一件事不是画架构图而是搞清楚这个决策到底是同步还是异步是硬实时还是软实时。这个判断直接决定了后面所有技术选型的走向。1.2 决策链路的耗时拆解90毫秒去了哪儿确定150毫秒总预算后我们把它进一步拆成了三块特征拉取30到40毫秒包括从Redis批量读取设备指纹、用户历史行为统计、IP维度的聚合特征以及从外部数据源同步过来的黑名单、征信分等信息。规则执行20到30毫秒几十条核心规则的内存条件判断加上部分需要查缓存的名单类规则。模型推理30到50毫秒两到三个打分模型的串行或并行推理视模型复杂度而定。这样拆完还剩30毫秒左右的buffer留给网络抖动、GC停顿和突发流量。拆完之后我们就有了明确的性能预算表开发同学在做每一块功能时都有了一个不要超出这个时间窗口的强约束。比如写特征服务的人看到预算只有40毫秒就不会傻傻地在循环里逐条LGET Redis做模型服务的人看到预算50毫秒也就理解了为什么我们要求把模型文件序列化进内存而不是每次动态加载。1.3 什么决定了决策必须同步完成这里想多说一句为什么风控决策非得这么急。交易类场景的本质是钱货两清风控作为一道闸门拦在转账或下单的路径上如果不给出实时结论业务就只能选择放行——而放行就意味着风险敞口。异步审核虽然能查出问题但钱已经付出去了货已经发出去了追回成本极高。所以我们看到的几乎所有支付风控都是同步决策为主、异步补充为辅。同步决策保证坏人进不来异步分析负责进来的人后续可疑行为监测。实时决策架构的第一性原理就是在有限的时间预算内用尽可能完整的信息做出尽可能准确的风险判断。时间预算锁死了信息获取的上限架构设计就是在跟时间赛跑。2. 决策引擎的分层设计请求进来以后先做什么、再做什么预算拆完之后接下来就是架构分层。我把风控决策引擎划分为四个层次接入层、编排层、执行层、数据层。每一层只干自己该干的事层级之间通过明确的接口通信避免模块之间互相渗透、互相拖累。2.1 接入层流量清洗与协议适配接入层是全系统最靠前的一道防线负责接收各类业务方请求。不同业务方协议五花八门有HTTP JSON、有Dubbo、有gRPC还有直接上报MQ的。接入层要做的就是协议转换、参数校验、鉴权认证以及最基础的流量限流。这里有个容易被忽视的细节接入层一定要做参数级别的合法性校验而不是把脏数据丢给后面的规则引擎和模型。有次我们排查一个诡异的特征异常追了半天发现是某个业务方把一个本该是整数的字段传成了字符串null导致特征拼接时整个特征向量全部错位。后来在接入层加了严格的数据类型检查和枚举校验这类问题基本绝迹。接入层本身不参与任何决策逻辑所以它必须做到无状态支持随意水平扩展。当大促流量暴涨时我们只需要对这一层扩容就能扛住大部分压力。2.2 编排层决策流解析与节点调度编排层是整个决策引擎的大脑负责把一份决策流配置解析成可执行的有向无环图然后按照依赖关系调度各个节点执行。我们基于自研的轻量级DAG引擎来做编排。每个决策流由若干节点组成节点类型包括规则集节点、模型节点、名单查询节点、自定义脚本节点。DAG引擎负责并行化调度没有依赖关系的节点把原本串行的执行路径压缩到最短。比如名单查询和特征拉取没有依赖关系就可以并行执行模型A的输出如果作为规则C的输入那就必须先等模型A跑完。这里踩过一个坑早期版本用JsonPath硬编码决策流每加一个新场景就要改代码发版效率极低。后来迁移到配置化之后策略同学通过可视化界面拖拽编排完成一次新场景接入从两天缩短到两小时。但配置化也带来了新的问题——配置本身需要严格的版本管理和权限控制否则一个误操作就可能让线上决策逻辑整体跑偏。2.3 执行层规则引擎与模型推理的分工协作执行层是真正完成计算的地方。规则引擎负责跑确定性的逻辑判断模型推理负责跑概率性的风险打分。两者不是替代关系而是互补关系。规则引擎这一层我们用的Drools团队很熟但为了极致性能核心路径上的高频规则没有跑在Drools里而是翻译成了直接的内存对象迭代。为什么这么做Drools的规则匹配确实方便但每次会话构建和匹配过程的开销在毫秒级到十几毫秒不等。对一些低频场景可以用但对全量交易请求来说这种开销太奢侈了。我们只把Drools用于一些需要频繁修改、复杂逻辑判断的非核心场景核心路径上的规则全走自研的轻量级表达式引擎。模型推理层则是我们在性能优化中投入最多的部分。我们把训练好的模型序列化为PMML或ONNX格式部署到独立的模型服务中通过gRPC对外提供推理能力。并行加载多个模型文件到内存省去每次请求的动态加载开销。推理时如果模型之间有依赖就串行没有依赖就并行。实测下来两个梯度提升树模型并行推理的总耗时能控制在30毫秒以内。2.4 数据层一切决策的燃料仓库数据层为决策提供实时的上下文信息包含用户画像、设备指纹、历史行为序列、IP情报、黑名单库等。这些数据散布在Redis、HBase、关系型数据库和外部API中执行层需要快速把它们汇聚到一起。我们在数据层之上封装了一层统一特征服务Feature Service屏蔽底层多数据源的差异。特征服务对外提供按实体批量取特征的接口入参是用户ID、设备ID、订单ID等实体标识出参是一份扁平化的特征字典。特征服务的内部逻辑是并行去Redis、HBase等存储捞数据做必要的聚合计算再统一返回。这样特征拼接的逻辑收敛在一个地方规则引擎和模型服务不需要关心数据从哪来。数据层最怕的是热点key和缓存穿透。一次大促期间某个头部主播直播间涌入了海量下单请求都集中在一个商品ID上结果Redis里那个商品维度的特征key被打穿瞬间流量全部压到HBase和数据库导致特征服务整体延迟从10毫秒飙升到300毫秒最终拖垮了整个决策链路。这个坑让我们后续专门针对热点key做了本地缓存加分布式锁的多级防护。3. 特征数据的时间窗口实时特征计算与存储选型风控决策的质量极大地依赖于特征数据的时效性。一个基于过去5分钟该设备尝试登录次数的特征如果数据延迟了15分钟才更新那它的风险判别意义就大打折扣了。3.1 离线特征与实时特征的分工风控特征从时效维度可以分成三类离线特征T1更新的用户长期行为画像比如历史交易偏好、复购周期、长期活跃度。这类数据适合批量计算存放到HBase或ClickHouse中供查询。准实时特征分钟级延迟的聚合统计比如最近1小时的下单次数、最近30分钟的支付失败次数。实时特征秒级甚至毫秒级延迟的数据比如当前请求的IP是否命中已知代理IP库、这台设备在最近1分钟内是否同时发起了多笔来自不同账号的请求。离线特征解决的是这个用户平时是什么样的实时特征解决的是这一刻这个用户在做什么。风控规则里最有杀伤力的往往是实时特征——因为它刻画的是当前行为存在的异常模式。3.2 流式计算在实时特征中的角色实时特征的计算我们选择了Flink作为核心引擎。业务方将交易事件、登录事件、营销动作等埋点消息实时上报到KafkaFlink消费这些消息后在窗口内完成聚合计算计算结果写回Redis。规则引擎在做决策时直接从Redis读取这些预聚合好的实时特征。比如我们有一个重要特征叫短时间同设备多账号登录数定义是同一设备ID在过去5分钟登录过的不同账号数量。用Flink做这个聚合非常自然按设备ID分组开5分钟的滑动窗口窗口内对账号ID做去重计数。计算结果实时写入Rediskey是设备ID时间窗口value是去重后的账号数。这里要特别小心窗口对齐的问题。Flink的事件时间和处理时间在乱序数据下会出现偏差如果特征数据晚到窗口计算结果可能不完整。我们采用的方案是允许一定程度的延迟数据allowedLateness同时用旁路输出把这些延迟数据记录下来做校正。风控场景可以接受秒级的特征延迟但绝不能接受因为窗口计算错误而导致的特征数值系统性偏低。3.3 Redis使用模式的演进从缓存到特征数据库早期我们只用Redis做黑名单缓存和Session存储后来发现它完全能支撑实时特征的读写需求后逐步演变成了特征数据库的角色。演进过程中踩了不少坑大Value问题。有段时间我们把用户近30天行为明细列表直接塞进了一个Redis key里单个value超过1MB。结果每次读取这个key都消耗大量网络带宽和序列化时间还拖慢了Redis所在节点的整体性能。后来改成只存聚合后的统计值明细数据移到HBase。逐出策略问题。默认的allkeys-lru逐出策略会把一些虽然不常用但关键时刻很重要的大促活动特征key给逐出了。我们改成volatile-lru只对设置了过期时间的key做逐出核心特征key设置为永不过期。序列化方式问题。从JDK原生序列化切换到Kryo或Protobuf之后Redis读写的CPU开销明显下降。这个优化对特征服务延迟的改善比扩容还明显。3.4 冷热特征分离与特征预加载不是所有特征在每一次决策中都会被用到。我们在实践中做了冷热分离热特征每次决策几乎必查的特征比如订单金额、用户历史交易次数、设备风险等级。这些提前加载到一个进程内本地缓存中避免每次决策都远程访问Redis。温特征大多数决策会用到但偶有遗漏的特征比如IP归属地风险评分。放在Redis中批量流水线获取。冷特征只有特定业务场景才会用到的深层画像比如用户关系图谱指标。存放在HBase或ClickHouse按需加载。本地缓存带来两个风险数据一致性风险和内存压力风险。为了解决一致性我们通过Redis的Pub/Sub订阅特征变更事件本地缓存在收到事件后主动失效对应key为了控制内存本地缓存设置了最大条目数和基于LRU的淘汰策略。实测下来热特征本地缓存的命中率在92%以上决策链路不用每次都在特征拉取上消耗几十毫秒的网络往返。4. 模型推理的实时化方案超时控制、降级与预案风控系统里最脆弱的环节往往不是规则引擎而是模型推理服务。规则引擎是确定性的只要代码没bug执行时间基本稳定模型推理却受模型大小、输入维度、GPU资源竞争等因素影响延迟波动会很明显。AI风控系统的实时决策架构必须为模型推理的不稳定性留好退路。4.1 推理服务的独立部署与隔离我们的模型推理服务是独立部署的一组集群与规则引擎物理隔离。这样规则引擎因为流量突增而抖动时不会拖垮模型推理反过来模型推理因为复杂的神经网络计算产生毛刺时也不会耗尽规则引擎所在节点的CPU。在部署策略上有两个选择CPU推理和GPU推理。早期我们图省事统一用CPU跑XGBoost和浅层神经网络模型小的时候延迟还能压住。后来升级到深度模型之后CPU推理的P99从30毫秒涨到了90毫秒体感非常明显于是我们把深度模型迁移到GPU推理效果立竿见影P99回到了20毫秒以内。GPU推理的坑在于冷启动和显存占用。我们有个模型服务曾经因为显存泄漏运行4小时后被系统OOM Kill导致大规模超时。后来加了显存监控和定期重启机制并配合多副本滚动发布把这个问题稳住了。4.2 超时控制宁可快速失败不能无限等待在同步决策链路里最忌讳的就是等待一个永远不回来的结果。我们在模型推理客户端设置了严格的超时时间——默认80毫秒超过就快速失败进入降级分支。降级分支的策略是优先使用规则引擎已有的判定结果。如果规则层已经出现强拦截信号比如命中黑名单模型超时不影响最终拦截结论。如果规则层没有明确结果则回退到一个保守的小模型或者固定阈值策略。这个保守策略宁可误杀也不能漏过因为在实时决策的语境下模型超时本身就是一个值得警惕的信号。将超时样本记录到日志和消息队列中后续做异步补偿分析评估模型服务是否出现系统性故障。这里有个设计细节超时时间不能是固定值而是要根据模型服务的实时健康状态动态调整。我们通过注册中心下发动态配置当模型服务健康检查异常时自动把超时时间从80毫秒下调到30毫秒同时把更多流量切换到规则引擎兜底。4.3 熔断与降级的触发条件熔断机制的触发不能只看错误率还要看延迟分布。我们采用了类似Hystrix的信号量隔离模式每个模型服务实例维护一个熔断器。当最近30秒内的请求错误率超过15%、或P99延迟超过预设阈值、或并发线程数超过信号量上限时熔断器打开后续请求直接走降级策略不再尝试调用模型服务。熔断器在半开状态下会放少量试探测流量一旦探测成功就自动关闭熔断器恢复正常调用。这套机制上线后我们经历过几次模型服务所在机房网络抖动风控决策链路都平稳扛住了没有出现大规模超时。切记降级策略不是临时代码而是正式架构的一部分。降级分支里面的兜底规则、保守阈值、日志逻辑都要经过充分测试绝不能等线上出问题时才临时拼凑。我们专门设计了一套降级演练机制每个月强制进入一次模型降级状态确保兜底路径不出幺蛾子。4.4 模型版本管理与灰度发布模型推理服务最容易出问题的场景不是上线初期而是模型版本迭代。新模型在离线评测集上AUC更高不代表线上效果一定更好——特征分布漂移、数据口径变化都可能让新模型翻车。我们建立了模型灰度发布的标准流程影子模式新模型与线上老模型并行运行但新模型的输出只记录不参与决策。通过对比两者的打分差异和风险命中情况评估新模型的稳定性。金丝雀发布将决策链路上的一部分真实流量比如5%切到新模型并实时监控拦截率、误杀率、通过率等业务指标。与老模型的同期指标做对比如果差异超出设定阈值自动回滚。全量发布金丝雀稳定运行一段时间后逐步放量到100%。这个流程看起来简单但实际执行中要顶住业务方的压力。有一次新模型离线AUC提升了0.02业务方急着上线但我们坚持先跑一个完整的灰度周期。结果影子模式下发现新模型对某个特定线上场景的误杀率飙高了8倍差点酿成大事故。从那以后团队再没人质疑模型灰度流程的必要性。5. 一次线上事故的完整排查链路从决策超时到特征服务抖动纸上谈兵够了我讲一个我们真实经历过的线上事故。这是我认为架构师必须拔高认知的一个案例——一个表象极其简单的问题背后牵出的是一条完整的依赖链条。5.1 事故现象和初步定位那天是大促期间的晚间流量高峰监控告警突然炸了风控决策服务的P99延迟从60毫秒飙到了420毫秒同时错误率从0.1%升到了3.2%。第一反应是模型推理服务出了问题因为它是全链路里最不稳定的环节。但打开模型服务的监控面板发现它的P99只有35毫秒错误率也在正常范围内。接着看规则引擎的日志发现大部分耗时都花在了等待特征服务返回上。于是迅速把目标锁定到特征服务。5.2 特征服务为什么变慢进入特征服务的监控后我们看到一个扎眼的指标它访问Redis的P99耗时从原来的5毫秒涨到了200毫秒。正常情况下访问Redis应该是亚毫秒级到毫秒级200毫秒意味着Redis集群一定出了状况。查Redis集群的慢查询日志发现集中在一类命令上HGETALL user_feature:{userId}。这类命令之所以慢是因为它一次性获取了一个哈希表的所有字段和值。问题在于用户特征哈希表的字段数量是动态增长的——正常情况下一个用户有几十个特征字段但当天有大量用户在同一时间段内产生了密集的写入操作导致部分用户的哈希表膨胀到了几千个字段。一个大哈希表的HGETALL会阻塞Redis单线程模型进而拖垮同一节点上的其他请求。5.3 根因上游事件洪峰引发的特征膨胀为什么哈希表会膨胀追到上游才发现营销团队当天临时发起了一个分享得优惠券的活动活动规则里要求风控对每一次分享动作做实时检测。分享事件被接入到Flink实时计算任务中Flink又把用户的分享行为逐条写入到Redis的特征哈希表里。由于分享事件量远远超过了我们的预估单个用户的哈希表字段数在短时间内暴涨。这里暴露了两层问题一层是Flink实时计算任务没有对写入Redis的特征做上限控制和窗口剪裁另一层是Redis端的HGETALL操作没有针对大哈希表做保护。5.4 修复方案与长期防护短期内我们做了三件事将特征哈希表的写入逻辑改成滑动窗口内只保留最近30分钟的行为摘要超过窗口时间的数据自动过期。将HGETALL改成对逻辑的替换——通过分批HMGET只取最近用到的特征字段子集把单命令耗时降下来。在Redis侧配置了hash-max-listpack-entries参数限制单个哈希表的节点规模。长期来看这个事故推动了三个架构改进第一特征服务增加了对数据源响应耗时的熔断能力。当Redis P99超过50毫秒时特征服务主动降级返回部分缓存的特征快照不再无限等待Redis返回。第二Flink写Redis的流程增加了写放大保护每窗口最多写多少字段、每个key最多保留多少字段都有硬限制超限的数据进入旁路日志而不是直接写入。第三我们建立了一个全链路压测机制每次新活动上线前必须在压测环境模拟预期流量倍数确保不会因为活动流量激增而击穿风控系统。事后复盘时我们承认一个深层教训实时决策架构的鲁棒性不能只靠下游防护上游数据的无界增长本身就是最大的风险源。架构师必须对数据源头的写入特性保持敏感——任何无限增长的结构早晚会变成线上事故的定时炸弹。6. 架构演进的思考实时决策系统的下一次跃迁前面讲的是当下的架构是如何搭建的。但从2025年回头再审视这个系统又出现了一些新的需求和挑战比如更复杂的多模型融合、更细粒度的实时特征、更频繁的策略更新节奏。这些压力正在推动实时决策架构朝新的方向演进。6.1 决策沙盘与仿真能力的构建过去我们上线一个策略或模型只能依赖灰度发布来验证效果风险大且周期长。为了缩短验证闭环我们正在构建一个决策沙盘环境。沙盘的核心能力是支持用历史真实流量回放来模拟新策略的决策结果。具体做法是把历史交易请求完整记录到对象存储中包含当时的特征快照和决策结果。新策略上线前在沙盘中加载这些历史数据将新策略与历史策略并行运行快速计算新策略的拦截率、误杀率、以及如果新策略当时生效能挽回多少资金损失。这套沙盘系统对实时决策架构提出了新的要求——特征回放能力。它需要把历史特征快照原样还原而不是用当前时刻的特征值去跑历史决策。所以我们开始为实时特征存储引入快照语义每次决策时生成的特征向量都持久化一份到列式数据库中作为后续回放的时间胶囊。这个能力上线之后策略迭代速度提升了至少一倍而且很多灰度阶段才能发现的问题在沙盘阶段就被过滤掉了。6.2 决策结果的解释性与可审计性AI风控系统面临另一个常态化挑战监管和合规对决策解释性的要求越来越高。当系统拦截了一笔交易业务方要能清晰回答为什么拦用户申诉时也要能给出合理的解释。我们的方案是决策全程留痕。每一次实时决策都会记录决策流版本、规则命中明细、模型输入特征摘要、模型打分结果、以及最终决策和置信度。这些信息写入审计日志系统支持事后快速查询。为了让解释自然流畅我们把规则命中路径整理成了决策解释树——从根因出发一层层展示因为特征A异常所以触发了规则B规则B的权重又推动了模型C的打分。这个能力在架构层面看起来只是加了个日志但实际影响很大审计日志的写入不能阻塞主链路所以我们用异步方式落库同时日志量巨大需要按业务线分区存储冷热分离。我建议所有做风控架构的同学在这个方向上提前布局不要等监管来要求再临时补救。6.3 边缘计算把决策推近用户延迟永远有进一步压缩的空间。在一些对延迟极度敏感的场景——比如本地生活APP的下单支付、游戏内的虚拟物品交易——用户根本感知不到风控的存在每多10毫秒的等待都会带来流失风险。所以我们开始探索边缘节点上做轻量级风控决策的可行性。思路是把核心拦截逻辑黑名单、设备指纹、高频交易限制下沉到离用户最近的边缘节点边缘层直接做初筛。只有初筛通过或者命中需要深度模型判断的场景时才把请求转发到中心风控集群做完整决策。这样绝大多数请求可以在边缘层就以极低延迟结束风控流程中心集群的处理压力也大幅下降。边缘节点上的模型不能太大所以我们的做法是用知识蒸馏把中心大模型压缩成轻量级模型部署到边缘。轻量模型负责80%的常规决策中心大模型专攻那些模糊边界的高难度样本。这套方案还处于内部验证阶段但我认为它是未来几年AI风控架构绕不开的发展方向。6.4 架构师在AI风控系统中的角色最后说点更感性的体会。AI风控系统的架构师不能只埋头于技术细节必须时刻保持对业务风险的敏感度。架构设计里的每一个性能预算、每一个降级策略、每一层缓存设计最终都是为了让业务在风险可控的前提下跑得更快更稳。一个合格的风控架构师需要同时理解三件事业务侧对延迟和通过率的诉求、算法侧对特征和模型精度的诉求、以及运维侧对系统稳定性和可观测性的诉求。这三者经常存在矛盾——特征越全决策越准但延迟越高模型越复杂识别能力越强但推理越慢。架构师的价值就是在这些矛盾的夹缝中找出一条工程上最优的路径。我个人非常推崇一种工作方式定期把系统里最慢的一次决策调用和最复杂的一个决策流拎出来分析反复问自己这次决策为什么要花这么久这条路径能不能再砍掉一个环节。一次次较真下来系统的实时性能会得到持续改善。如果你正在设计或重构一套AI风控系统我的建议是先从业务方拿到明确的性能预算再按预算去倒推每一层的技术选型和取舍。永远不要为了追求某个组件的单点性能而忽视整条链路的平衡。实时决策架构没有银弹它是一连串合理的取舍。所谓架构师的关键设计就是在所有约束条件里找出那个“当前最优”的平衡点。这条路上踩过的坑将来都会成为你最有价值的判断依据。