本文为工程实践复盘，客户信息已脱敏；所述数据均为示意值。

一、项目背景

我们服务的某头部互联网金融平台，风控长期依赖专家手工编写的规则。这个项目里，痛点非常典型：新型欺诈手法（如设备农场、撞库、虚假养号）迭代极快，专家规则从发现到上线往往要 3-5 天；而老规则为了"防漏"越加越多，规则集膨胀到数千条，误伤正常用户的投诉随之上升。我们当时盘点，规则维护成本与误伤率已经形成恶性循环——加规则保召回、加规则又误伤、再人工兜底，团队疲于奔命。

我们采用自研的大模型私有化底座（推理一体机部署）结合实时决策引擎，构建"案件与日志 → 候选规则挖掘 → 实时拦截 → 人工审核闭环"的能力，目标是缩短规则迭代周期，同时把误伤压下来。

二、落地场景

这套能力在生产环境跑成一条实时链路。落地后主要覆盖三个动作：

第一，大模型周期性读取欺诈案件库（已标注样本）与实时行为日志，挖掘可疑行为模式，生成候选风控规则（含触发条件与处置动作），输出为机器可读的规则 DSL。

第二，候选规则进入实时决策引擎，对交易/登录请求做低延迟判定（命中即拦截/风控校验），引擎基于 Flink 做特征实时计算，规则以热加载方式生效。

第三，命中与人工审核结果回流，形成闭环：误杀案件被标注后，既用于规则回滚，也作为负样本喂给下一轮挖掘。我们当时通过 AI 网关统一接入模型调用，并按业务线做配额与计量。

在架构上，实时特征（如近 1 小时同设备注册数、近 24 小时交易总额）由特征存储预计算并对外提供低延迟查询，决策引擎只做轻量求值，避免每次请求都现场聚合。所有决策结果（命中/放行/处置动作/耗时）统一落进审计流水，运营侧有一块实时看板，能按业务线、规则、时段下钻误杀与拦截分布，使风控从"黑盒拦截"变成了"可解释、可复盘"的运营对象。

三、关键技术挑战与解决思路

挑战一：欺诈模式挖掘与候选规则生成。 难点是模型容易生成"过拟合单案"的噪声规则。我们做法是把案件库转成图结构（账户—设备—IP—行为），用模型在子图上归纳模式，并要求生成规则必须带支持度与置信度。例如挖掘出"同设备 1 小时内关联 ≥5 个新注册账户"这一模式后，强制附带统计指标再落库，支持度低于阈值的模式直接丢弃，不进入候选池。

SELECT device_id, COUNT(DISTINCT account_id) AS acc_cnt
FROM login_event
WHERE reg_flag = 1 AND ts BETWEEN now()-3600 AND now()
GROUP BY device_id
HAVING acc_cnt >= 5;

挑战二：实时决策低延迟。 决策引擎要求在 P99 < 50ms 内完成。我们把重特征（如近 24h 交易总额）预计算进特征存储，规则判定只做轻量求值；模型挖掘出的模式先在离线回放验证，再热加载到引擎。离线回放阶段我们用最近 30 天样本做命中与误杀评估，只有误杀率低于红线才允许进入灰度。引擎调用日志显示热加载后延迟稳定：

2025-04-02 09:15:33 [INFO] rule-engine: hotload 12 new rules, cost=42ms
2025-04-02 09:15:40 [INFO] rule-engine: p99 latency=38ms, qps=4200

挑战三：误伤控制与灰度。 新规则直接全量极易误杀。我们设计了灰度发布：新规则先以 1% 流量影子运行（只观测不拦截），对比误杀指标，达标后再 10%/50%/100% 梯度放量。灰度配置如下：

release:
  strategy: shadow_first
  shadow_ratio: 0.01
  ramp_up: [0.1, 0.5, 1.0]
  kill_switch: true

挑战四：规则生命周期管理。 规则会过期、会冲突、会冗余。我们给每条规则加了状态机（候选→灰度→生效→退役），并按效果（拦截贡献/误杀率）自动打标，连续 7 天零贡献的规则进入退役候选，由专家确认下线。这套机制把规则集从数千条收敛到可控规模，也避免了"谁都不敢删老规则"的困境——退役有数据支撑，责任清晰。

四、效果数据

上线约 10 周后统计（脱敏示意值）：欺诈拦截率从约 82% 提升至约 94%，误伤率下降约 47%，规则迭代周期从约 4 天压缩至约 6 小时，决策时延 P99 稳定在约 40ms。需要强调的是，数据均为示意值，非审计精确数。

案例片段（已脱敏）：规则挖掘输出的候选规则 DSL 片段与实时决策判定片段。

json {  "rule_id": "RC-20250402-118",  "pattern": "same_device_multi_new_account",  "condition": "device_acc_cnt_1h >= 5 AND reg_flag = 1",  "action": "step_up_auth",  "support": 0.037,  "confidence": 0.91,  "release": "shadow" }

2025-04-02 09:16:10 [DECISION] req=tx-7782 rule=RC-...118 hit, action=step_up_auth, cost=3ms 2025-04-02 09:16:11 [DECISION] req=tx-7783 no-hit, pass, cost=2ms

五、可复用经验总结

第一，挖掘辅助而非替代专家。大模型擅长从海量案件里归纳模式，但模式的业务合理性、处置分寸仍要专家把关。我们把模型定位为"候选生成器"，最终规则上线权在专家手里，这样既提速又不失控。

第二，灰度验证再全量。新规则的误杀风险不可低估，影子运行 + 梯度放量是保命手段。我们甚至给每类业务线设了独立的 kill switch，一旦误杀率越线立刻回滚。

第三，实时链路的延迟要前置设计。挖掘可以慢，决策必须快。把重计算下沉到特征存储、热加载生效，是关键工程取舍，不能等到上线再优化。

第四，规则要有生命周期。没有退役机制的规则集必然膨胀熵增，用状态机 + 效果打标让规则"能上能下"，维护成本才可持续。

第五，风控要可解释可复盘。我们把每次决策都落审计流水并配实时看板，误杀不再是"查无此因"的投诉，而是能定位到具体规则、具体特征，运营才有持续优化抓手。