企业官网建设流程全解析

风控规则的自动生成：大模型驱动实时风控的流式特征与规则引擎

一、黑产的变形速度：为什么人工写规则永远慢半拍

风控团队最头疼的，是规则上线永远慢于黑产变异。一个新的薅羊毛手法出现，分析师要查日志、找特征、写规则、走审批，等规则生效，对方早已换皮。

传统风控靠专家规则堆砌。每条规则是人写的 SQL 或 DSL，覆盖一类已知风险。它的优势是可解释、可审计。劣势是维护成本高、响应慢、只能防已知。

大模型进场后，事情起了变化。LLM 能读历史风险案例，结合实时流式特征，草拟新的检测规则。人做审核与灰度，规则上线周期从天级压到小时级。下面拆这套架构。

二、流式特征与规则生成的双轨架构

实时风控有两个引擎：特征计算与规则判定。特征引擎从 Kafka 流里实时算出用户粒度指标，如近一分钟下单数、设备换绑频次。规则引擎用这些特征匹配风险策略。

LLM 的角色在规则侧。它读特征的语义定义、读历史欺诈样本，生成候选规则表达式。生成后先离线回放验证命中率与误杀率，再小流量灰度。双轨解耦，互不影响。

flowchart TB E[实时事件流<br/>交易/登录] --> F[流式特征引擎<br/>Flink 计算] F --> FE[(特征仓库<br/>用户级指标)] FE --> R[规则引擎<br/>实时判定] R --> A[处置动作<br/>拦截/人工] H[历史欺诈样本] --> G[LLM 规则生成] G --> V[离线回放<br/>命中/误杀评估] V -->|达标| GR[灰度发布<br/>小流量] V -->|不达标| G GR --> R style F fill:#e1f5fe style G fill:#fff3e0 style V fill:#f3e5f5 style R fill:#e8f5e9

这张图的核心是回放闸门。LLM 生成的规则绝不直投生产，先离线评估误杀率。风控最怕误杀真实用户，回放这道关守的就是这条红线。

三、生产级实现：流式特征计算与规则灰度

下面给出特征计算与规则灰度骨架，包含特征超时兜底、规则表达式沙箱执行与灰度流量切分：

import asyncio from dataclasses import dataclass @dataclass class Feature: user_id: str order_cnt_1m: int = 0 device_switch_10m: int = 0 class FeatureStore: """流式特征仓库：带 TTL 与空值兜底""" def __init__(self, ttl_sec: int = 120): self._ttl = ttl_sec self._cache: dict = {} async def get(self, user_id: str) -> Feature: item = self._cache.get(user_id) if item is None: # 特征缺失时返回零值特征，避免判定中断 return Feature(user_id=user_id) return item class RuleEngine: """规则引擎：沙箱执行 LLM 生成的规则""" def __init__(self, feature_store: FeatureStore, gray_ratio: float = 0.05): self._fs = feature_store self._gray = gray_ratio # 仅 5% 流量走新规则 async def judge(self, event, rule_expr: str, rule_id: str) -> str: if hash(event.user_id) % 100 / 100.0 >= self._gray: return "pass" # 非灰度流量不触发新规则 feat = await self._fs.get(event.user_id) try: # 沙箱执行，禁用危险内置，超时 50ms 即判通过 risk = await asyncio.wait_for( self._safe_eval(rule_expr, feat), timeout=0.05) except Exception: return "pass" # 规则异常不阻断业务 return "block" if risk else "pass" async def _safe_eval(self, expr: str, feat: Feature) -> bool: allowed = {"feat": feat} return bool(eval(expr, {"__builtins__": {}}, allowed))

这段代码的命门在三处：特征缺失返回零值不中断、规则异常降级放行、灰度只切小流量。风控宁可漏过不可误杀，异常与未命中都默认放行，是新规则上线的安全基线。

四、边界与权衡：LLM 生成规则的安全红线

LLM 进风控有不可逾越的边界，踩错会出事故。首先是误杀代价。模型生成的规则若误伤真实用户，损失是直接的信任与资损。因此必须离线回放达标、灰度小流量、可逆可回滚，三步缺一不可。

其次是可解释性。金融风控要求规则可审计。黑盒模型直接决策不被监管接受。LLM 应生成可读的规则表达式，而非不可解释的向量，才能保证事后可复盘。

再次是对抗污染。黑产可能故意制造样本污染训练数据，诱导模型生成有利于攻击的规则。生成链路必须隔离对抗样本，回放集要用可信历史，而非模型自产自销。

最后是实时性约束。规则生成是离线/近线动作，不能放进毫秒级判定链路。流式特征必须预计算好，规则只做轻量匹配。把重活放到特征侧，判定侧保持极简。

适用场景：欺诈模式快速迭代、规则维护人力紧张、可容忍小流量灰度的业务。禁用场景：强监管不可解释决策、零误杀要求的支付核心、对抗环境未隔离的样本源。这类需求下，LLM 只能辅助分析，决策权必须留在可审计的规则与人手里。

五、总结

大模型驱动实时风控，价值在把规则生成从天级压到小时级。架构上特征与规则双轨解耦，LLM 只出草稿，回放评估与灰度发布守住误杀红线。

落地铁律：生成的规则必须可读可审计，异常与未命中一律放行，灰度从小流量起。记住风控的底线：宁可漏过，不可误杀。模型提速，安全不能提速。