风控引擎：在便利与安全之间走钢丝
这是支付系统系列的第七篇文章。前面我们聊了支付系统的架构、渠道对接、对账体系。今天，我们来聊聊一个容易被忽视但至关重要的环节——风控。
一、为什么支付需要风控？
想象一下这个场景：
你的支付系统上线了，用户体验丝滑流畅，充值秒到账，退款秒到账。一切看起来都很完美。
直到某天，财务发现账户里少了几百万。
这不是危言耸听。在支付领域，没有风控的系统就像开着豪车的门锁坏了——迟早出事。
2023年，某中型游戏公司上线了一款爆款手游。首月流水破亿，团队沉浸在喜悦中。但第二个月财务对账时发现：有超过200万的充值来自同一批异常账户，这些账户在充值后立即申请退款，退款的却是另一个账户。
调查发现，这是一个有组织的黑产团伙，利用该公司退款流程的漏洞，在两周内"薅"走了300万。更严重的是，这笔钱追不回来了——账户都是买来的"肉鸡"，IP也是伪造的。
这就是没有风控的下场。
风控的本质是什么？是在便利和安全之间找平衡。
- 太松，骗子横行，平台亏损
- 太严，用户体验差，交易量下跌
好的风控，就是让正常用户感觉不到它的存在，让异常行为无处遁形。
二、常见的四类风险
1. 盗刷：别人的钱，你来赔
盗刷是最直接的风险。黑客通过各种手段获取用户的支付凭证（账号密码、支付密码、验证码等），然后疯狂消费。
- 钓鱼网站骗取账号密码
- 木马程序截获短信验证码
- 社会工程学攻击客服重置密码
- 数据库泄露后撞库
- 用户会找平台索赔
- 平台需要承担连带责任
- 信任危机比金钱损失更致命
2024年初，某支付平台遭遇大规模撞库攻击。攻击者使用了从其他网站泄露的500万组账号密码，尝试登录该平台。由于很多用户在不同网站使用相同密码，攻击者成功登录了约3%的账户（15万个），其中2万个账户有余额。
在风控系统介入前，攻击者在2小时内完成了超过8000笔盗刷交易，损失金额达120万。
- 异常登录检测：IP变化、设备变化、地理位置跳跃
- 行为特征分析：操作习惯、点击节奏、输入速度
- 多因素认证：高风险操作强制二次验证
2. 套现：把信用当提款机
套现主要发生在支持信用支付的场景。用户通过虚假交易，把信用额度变成真金白银。
- 自己注册多个账号互相交易
- 与商家串通虚构交易
- 利用退款机制循环套现
- 利用活动优惠薅羊毛后变现
- 信用体系被破坏
- 资金成本远超预期
- 可能触及非法集资红线
模式一：自买自卖
用户A（信用额度5000元）→ 购买虚拟商品 → 商家B（其实是用户A的小号）
商家B → 提现 → 用户A的银行账户
结果：5000元信用额度变成4500元现金（扣除10%手续费）
模式二：退款套现
用户A → 充值1000元购买道具 → 使用道具 → 申请退款
如果退款成功：白嫖道具+拿回本金
如果使用优惠券：还能赚差价
模式三：循环套现
充值 → 购买可交易道具 → 转给小号 → 小号出售 → 提现
绕过直接提现的限制
- 交易关系图谱：识别账户间的关联
- 充值消费比：监控异常的资金流向
- 退款行为分析：频繁退款账户重点监控
3. 薅羊毛：小钱也能薅出大窟窿
羊毛党是互联网的"蝗虫"。他们利用各种优惠活动、返利机制，通过批量注册账号、自动化脚本等方式，把平台的补贴薅个干净。
- 批量注册虚假账号
- 使用接码平台获取手机号
- 自动化脚本抢优惠券
- 利用规则漏洞重复获利
- 营销预算被掏空
- 真实用户抢不到优惠
- 数据被污染，影响决策
羊毛党可不是随便玩玩的，他们有专业的"武器库"：
| 工具类型 | 功能 | 价格 |
|---|---|---|
| 接码平台 | 批量获取手机号验证码 | 0.1-1元/个 |
| IP代理池 | 切换不同IP地址 | 50-200元/月 |
| 设备农场 | 大量真实手机执行任务 | 按设备数量计费 |
| 自动化脚本 | 自动注册、抢券、下单 | 定制开发 |
| 实名资料 | 身份证+银行卡套餐 | 20-50元/套 |
某游戏公司新游上线，推出"首充6元送价值60元礼包"的活动。本来预算是吸引10万真实用户，投入60万营销费用。
结果活动上线第一天，就产生了50万笔首充订单。数据团队一分析：
- 80%的账户注册时间在活动前3天内
- 70%的账户设备指纹相同或相似
- 60%的账户充值后从未登录游戏
- IP地址集中在几个特定的代理服务器
这是一场有组织的羊毛党攻击。最终，公司只追回了约30%的礼包，其余的已经被变现或消耗。营销预算超支300%，而真实用户转化率远低于预期。
- 设备指纹：识别同一设备的多个账号
- 行为分析：区分机器行为和真人行为
- 环境检测：识别模拟器、代理、多开工具
4. 洗钱：你的平台成了帮凶
这是最严重的风险。如果你的平台被不法分子用于洗钱，可能面临法律风险。
- 虚假交易转移资金
- 多级账户层层转账
- 利用退款机制回流资金
- 跨境支付规避监管
- 触犯反洗钱法规
- 可能被吊销支付牌照
- 负责人可能承担刑事责任
第一阶段：处置（Placement）
把非法资金注入金融系统
↓
例：用黑钱购买游戏币/虚拟道具
第二阶段：离析（Layering）
通过复杂交易隐藏资金来源
↓
例：多次转卖、跨服交易、不同游戏间转移
第三阶段：融合（Integration）
让资金以合法形式回到表面
↓
例：通过"正常"的游戏收入提现
- 大额交易报告：超过阈值的交易上报
- 可疑交易分析：资金流向异常的账户
- 客户身份识别：KYC（Know Your Customer）机制
三、风控系统架构详解
风控系统不是简单的几条规则，而是一个复杂的技术体系。让我们从架构层面来理解它。
整体架构
┌─────────────────────────────────────────────────────────────┐
│ 风控系统架构 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ 数据采集层 │ │ 实时计算层 │ │ 决策输出层 │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌──────────────────────────────────────────────────┐ │
│ │ 规则引擎 + 模型引擎 │ │
│ └──────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ 黑白名单管理 │ │ 案例库管理 │ │ 策略配置中心 │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
1. 数据采集层：风控的眼睛
风控的第一步是收集数据。没有数据，就像盲人摸象。
- 注册时间、实名状态、会员等级
- 历史交易次数、累计交易金额
- 账户安全等级、绑定的手机/邮箱
- 设备唯一标识（IMEI、IDFA、OAID等）
- 设备类型、操作系统版本
- 是否Root/越狱、是否模拟器
- 安装的应用列表、设备参数
- IP地址、IP类型（住宅/机房/代理）
- 地理位置（GPS/IP定位）
- WiFi信息、运营商信息
- 金额、币种、支付方式
- 商品类型、交易时间
- 渠道来源、营销活动
- 操作习惯（点击节奏、滑动轨迹）
- 页面停留时间、操作序列
- 输入特征（打字速度、复制粘贴）
设备指纹是风控的重要技术，它能在不依赖Cookie的情况下识别设备。
设备指纹的组成：
硬件特征（稳定性：高）
├── CPU信息：型号、核心数、频率
├── 内存信息：总量、可用量
├── 屏幕信息：分辨率、像素密度
├── 电池信息：容量、健康度（移动端）
└── 传感器：陀螺仪、加速度计数据特征
软件特征（稳定性：中）
├── 操作系统：类型、版本、补丁级别
├── 浏览器：类型、版本、插件列表
├── 字体列表：安装的字体组合
├── 时区/语言：系统设置
└── 安装的应用：应用列表的哈希
行为特征（稳定性：低）
├── Canvas指纹：浏览器绘图特征
├── WebGL指纹：GPU渲染特征
├── Audio指纹：音频处理特征
└── 触摸轨迹：滑动和点击模式
设备指纹的生成过程：
- 收集上述各类特征
- 对每个特征进行归一化处理
- 计算特征组合的哈希值
- 加入随机噪声（防止逆向）
- 生成最终的设备指纹ID
- 隐私保护限制（iOS ATT、Android限制）
- 设备指纹伪造工具（设备农场）
- 浏览器指纹防护插件
- 同一设备多账号的合法场景
2. 规则引擎：风控的大脑
规则引擎是风控系统的核心，它决定了每笔交易是否放行。
规则引擎架构：
┌─────────────────────────────────────────┐
│ 规则解析器 │
│ 将自然语言/DSL转换为可执行逻辑 │
└─────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────┐
│ 规则执行器 │
│ 按优先级执行规则，处理规则冲突 │
└─────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────┐
│ 结果聚合器 │
│ 汇总所有规则的输出，生成最终决策 │
└─────────────────────────────────────────┘
最简单的规则类型，判断某个指标是否超过阈值。
示例规则：
- 单笔交易金额 > 10000元 → 人工审核
- 单日累计交易 > 50000元 → 拦截
- 同一IP 1小时内交易次数 > 50 → 验证码挑战
- 同一设备绑定账号数 > 5 → 风险标记
监控特定行为在时间窗口内的发生次数。
示例规则：
- 10分钟内失败登录 > 5次 → 账户锁定30分钟
- 1小时内退款申请 > 3次 → 人工审核
- 24小时内更换设备 > 3次 → 强制验证
- 7天内更换绑定手机 > 2次 → 高风险标记
直接基于名单进行决策。
黑名单（命中即拒绝）：
- 已确认欺诈的账户ID
- 涉案的可疑IP段
- 已知羊毛党的设备指纹
- 被标记的身份证号
白名单（命中即放行）：
- VIP高净值用户
- 已验证的可信设备
- 长期稳定的企业账户
- 合作渠道的特定IP
多个条件组合判断，捕捉复杂的风险模式。
示例规则：
IF 交易金额 > 5000
AND 用户注册时间 < 7天
AND 设备首次出现
AND IP归属地 != 用户常用地区
THEN 风险分数 += 30
IF 同一设备关联账号数 > 3
AND 这些账号的注册时间跨度 < 24小时
AND 这些账号使用了相同的营销活动
THEN 高风险 → 拦截
监控行为序列，识别异常的操作模式。
正常序列：登录 → 浏览商品 → 加入购物车 → 支付
异常序列：注册 → 绑卡 → 大额充值 → 立即提现
示例规则：
IF 注册后30分钟内完成绑卡+充值+提现
AND 充值金额 > 5000
THEN 疑似洗钱 → 人工审核
IF 新设备登录后立即进行大额交易
AND 未经过正常的浏览行为
THEN 疑似盗号 → 二次验证
交易请求进入
│
▼
┌─────────────┐
│ 数据预处理 │ ← 补充用户画像、设备信息、历史行为
└─────────────┘
│
▼
┌─────────────┐
│ 黑名单检查 │ ← 命中则直接拒绝
└─────────────┘
│
▼
┌─────────────┐
│ 白名单检查 │ ← 命中则跳过部分规则
└─────────────┘
│
▼
┌─────────────┐
│ 规则集评估 │ ← 并行执行所有规则，计算风险分
└─────────────┘
│
▼
┌─────────────┐
│ 模型评估 │ ← 机器学习模型打分（可选）
└─────────────┘
│
▼
┌─────────────┐
│ 决策输出 │ ← 放行/拦截/审核
└─────────────┘
3. 决策输出层：风控的手
根据规则计算结果，系统会做出不同的决策。
| 决策类型 | 说明 | 适用场景 | 用户感知 |
|---|---|---|---|
| 放行 | 正常交易，不做干预 | 低风险交易 | 无感知 |
| 拦截 | 直接拒绝交易 | 高风险交易 | 明确提示 |
| 人工审核 | 转给风控人员判断 | 中风险/复杂情况 | 等待审核 |
| 延迟处理 | 先放行，后续检查 | 可疑但不明确 | 稍有延迟 |
| 二次验证 | 增加验证步骤 | 异常但可能正常 | 需要操作 |
| 限额处理 | 降低交易限额 | 新用户/可疑用户 | 金额受限 |
好的风控系统应该能够解释每个决策的原因：
决策报告示例：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
交易ID: TX20260301001
决策结果: 人工审核
风险分数: 72/100
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
触发规则：
1. [阈值规则] 单笔金额超过5000元（+20分）
2. [行为规则] 新设备首次交易（+15分）
3. [序列规则] 注册后立即大额交易（+25分）
4. [关联规则] 设备关联多个异常账户（+12分）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
建议操作：
- 联系用户确认交易意愿
- 验证用户身份信息
- 如确认正常，可加入白名单
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
4. 黑白名单机制
黑白名单是风控系统的基础设施，管理着已知的风险和安全实体。
黑名单类型：
1. 账户黑名单
- 已确认欺诈的账户
- 涉诉账户
- 违规账户
2. 设备黑名单
- 已知羊毛设备
- 模拟器/多开工具
- Root/越狱异常设备
3. IP黑名单
- 已知代理服务器
- 机房IP
- 高风险地区IP
4. 身份黑名单
- 涉案身份证
- 异常绑定的银行卡
- 可疑的手机号段
白名单需要更严格的管理，因为白名单实体可以绕过部分风控。
白名单申请流程：
1. 业务方提交申请 → 说明原因
2. 风控团队审核 → 评估风险
3. 设置有效期 → 定期回顾
4. 监控白名单行为 → 异常告警
5. 定期清理 → 移除不再需要的
介于黑白之间，需要额外关注但不直接拒绝。
灰名单应用场景：
- 新注册用户（7天内）
- 新设备（首次出现）
- 异常地区登录（非常用地区）
- 触发规则但分数不高
处理方式：
- 加强监控
- 降低限额
- 增加验证频率
四、用户行为分析：从数据中识别异常
用户行为分析是风控的核心能力之一，它通过分析用户的操作模式来识别异常。
行为基线建模
每个正常用户都有自己的"行为指纹"，通过建立基线可以识别异常。
时间维度：
- 活跃时段：用户通常在什么时间使用
- 活跃频率：每天/每周的使用次数
- 间隔规律：操作之间的时间间隔
金额维度：
- 常用金额：通常的交易金额范围
- 金额分布：小额/大额交易的比例
- 增长趋势：消费金额的变化趋势
设备维度：
- 常用设备：主要使用的设备
- 设备切换：更换设备的频率
- 多设备使用：同时使用的设备数
行为维度：
- 操作路径：典型的操作序列
- 停留时间：各页面的停留时长
- 交互特征：点击、滑动、输入的模式
正常用户A的基线：
- 活跃时段：晚上8-11点
- 单笔金额：50-500元
- 常用设备：iPhone 13
- 操作习惯：浏览5-10分钟后下单
某天的交易请求：
- 时间：凌晨3点（异常！偏离基线8小时）
- 金额：5000元（异常！超出基线10倍）
- 设备：Android模拟器（异常！新设备）
- 操作：登录后1分钟内下单（异常！无浏览行为）
综合判断：高度疑似盗号 → 拦截 + 通知用户
行为序列分析
关注用户操作的顺序，识别异常的操作模式。
【正常购物序列】
首页 → 搜索商品 → 查看详情 → 加入购物车 →
继续浏览 → 修改数量 → 结算 → 支付
时间跨度：10-60分钟
【异常序列1：盗刷】
登录（新设备）→ 直接访问订单页 → 立即支付
时间跨度：< 1分钟
特征：跳过浏览环节，目标明确
【异常序列2：羊毛党】
注册 → 领券 → 充值最低档 → 使用优惠券 → 提现
时间跨度：< 5分钟
特征：极致优化，只走必要步骤
【异常序列3：套现】
充值 → 购买可交易道具 → 转赠指定账户 → 对方出售提现
时间跨度：1-24小时
特征：道具快速流转，资金闭环
# 风控规则配置示例
rules:
- name: "盗刷检测-快速支付"
condition:
sequence: ["login", "pay"]
time_window: 60 # 秒
device_new: true
action: "challenge" # 二次验证
- name: "羊毛党检测-快速套利"
condition:
sequence: ["register", "bind_card", "recharge", "withdraw"]
time_window: 300 # 5分钟
recharge_amount_min: 6 # 最低档充值
action: "review" # 人工审核
团伙识别
很多欺诈行为是有组织的，识别团伙是风控的高级能力。
1. 设备关联
- 同一设备登录的多个账号
- 设备参数高度相似的设备群
2. 网络关联
- 同一IP的多个账号
- IP归属地高度集中的账号群
3. 行为关联
- 操作时间高度同步
- 行为模式高度相似
- 都参与了同一个营销活动
4. 资金关联
- 账户间有资金往来
- 资金流向形成闭环
- 充值和提现账户分离
构建关系图：
- 节点：账户、设备、IP、银行卡
- 边：关联关系（同设备、同IP、有转账等）
- 权重：关联强度
团伙识别算法：
1. 社区发现（Louvain/Label Propagation）
- 找出紧密连接的账户群
2. 中心性分析（PageRank/Degree）
- 找出团伙的核心账户
3. 异常子图检测
- 找出与正常模式不同的子图
4. 传播分析
- 已知黑产账号 → 扩散关联账号
五、机器学习在风控中的应用
规则引擎虽然有效，但有局限性：规则有限容易被绕过，对新型欺诈反应慢。机器学习可以弥补这些不足。
为什么需要机器学习？
问题1：覆盖不全
- 只能防范已知的欺诈模式
- 新型欺诈需要人工发现后才能加规则
问题2：维护成本高
- 规则数量多了之后难以管理
- 规则之间的冲突需要人工解决
问题3：适应性差
- 黑产会研究规则，专门绕过
- 规则更新速度跟不上黑产进化速度
问题4：误杀率高
- 简单的阈值规则容易误杀正常用户
- 复杂的组合规则又难以调优
优势1：模式发现
- 能从海量数据中发现人眼看不到的模式
- 对新型欺诈有一定的识别能力
优势2：自动进化
- 通过持续学习，自动适应新的欺诈手法
- 不需要人工编写每一条规则
优势3：概率输出
- 不是简单的"是/否"，而是风险概率
- 便于设置不同阈值，平衡体验和安全
优势4：高维处理
- 可以同时考虑几十甚至上百个特征
- 比人工规则更全面
常用的风控模型
最基础但仍然有效的模型，适合作为第一版模型。
优点：
- 训练速度快，可解释性强
- 可以看到每个特征的权重
- 线上推理性能好
缺点：
- 只能处理线性关系
- 对复杂模式捕捉能力有限
适用场景：
- 模型初期，快速上线
- 需要解释性的场景
- 特征已经做过非线性变换
目前风控领域最主流的模型类型。
优点：
- 能处理非线性关系
- 能自动处理特征组合
- 对缺失值不敏感
- 特征重要性可解释
缺点：
- 容易过拟合，需要调参
- 训练时间较长
- 模型文件较大
适用场景：
- 大部分风控场景
- 需要较高准确率
- 特征维度较多
适合处理序列数据和非结构化数据。
应用场景：
序列模型（LSTM/Transformer）：
- 分析用户行为序列
- 检测异常的操作模式
- 输入：用户操作序列
- 输出：序列异常分数
图神经网络（GNN）：
- 分析账户关联关系
- 识别欺诈团伙
- 输入：账户关系图
- 输出：账户风险分数
适合处理标签不足的场景。
异常检测模型：
- Isolation Forest：隔离森林
- One-Class SVM：单类支持向量机
- Autoencoder：自编码器
应用场景：
- 新型欺诈检测
- 冷启动阶段
- 标签不足但有大量正常样本
特征工程
特征决定了模型的上限，特征工程是风控建模最重要的环节。
1. 统计特征
- 交易次数、金额统计（日/周/月）
- 失败次数、成功率
- 不同时间窗口的聚合
2. 比例特征
- 充值提现比
- 退款率
- 失败率
3. 时间特征
- 距上次交易的时间
- 距注册的时间
- 交易时间分布（是否集中在某时段）
4. 行为特征
- 操作次数
- 页面停留时间
- 点击到支付的转化率
5. 关联特征
- 关联账号数
- 关联设备数
- 关联IP数
6. 偏离特征
- 与历史行为的偏离程度
- 与同群体行为的偏离程度
# 特征工程示例代码
def extract_features(user_id, transaction):
features = {}
# 1. 基础特征
features['amount'] = transaction.amount
features['user_age_days'] = (now - user.register_time).days
# 2. 统计特征
features['trans_count_1d'] = count_transactions(user_id, days=1)
features['trans_count_7d'] = count_transactions(user_id, days=7)
features['trans_amount_1d'] = sum_amount(user_id, days=1)
# 3. 比例特征
features['recharge_withdraw_ratio'] = (
total_recharge / (total_withdraw + 1)
)
features['refund_rate'] = refund_count / trans_count
# 4. 时间特征
features['hours_since_last_trans'] = (
now - last_transaction_time
).hours
# 5. 偏离特征
avg_amount = get_user_avg_amount(user_id)
features['amount_deviation'] = (
transaction.amount - avg_amount
) / (avg_amount + 1)
# 6. 关联特征
features['device_account_count'] = count_accounts_on_device(
transaction.device_id
)
return features
模型训练与部署
1. 数据准备
├── 正样本：已确认的欺诈交易
├── 负样本：正常交易
└── 样本平衡：处理类别不平衡（过采样/欠采样）
2. 特征工程
├── 特征提取
├── 特征清洗
├── 特征筛选
└── 特征标准化
3. 模型训练
├── 数据集划分（训练/验证/测试）
├── 模型选择
├── 超参数调优
└── 交叉验证
4. 模型评估
├── AUC：整体区分能力
├── KS：正负样本分布差异
├── 精确率/召回率：业务指标
└── PSI：模型稳定性
5. 模型部署
├── 模型导出
├── 线上推理服务
└── A/B测试
┌─────────────────────────────────────────┐
│ 模型服务架构 │
├─────────────────────────────────────────┤
│ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ 特征服务 │ │ 模型服务 │ │ 规则服务 │ │
│ └─────────┘ └─────────┘ └─────────┘ │
│ │ │ │ │
│ └────────────┼────────────┘ │
│ │ │
│ ┌─────▼─────┐ │
│ │ 决策引擎 │ │
│ └───────────┘ │
│ │
│ 特征服务：实时特征计算 │
│ 模型服务：模型推理（TF Serving/ONNX） │
│ 规则服务：规则引擎执行 │
│ 决策引擎：综合输出最终决策 │
│ │
└─────────────────────────────────────────┘
模型的可解释性
风控模型必须可解释，否则难以获得业务信任和通过合规审查。
1. 全局可解释性
- 特征重要性排序
- 部分依赖图（PDP）
- 特征交互分析
2. 局部可解释性
- SHAP值：每个特征对单次预测的贡献
- LIME：局部近似解释
- 决策路径：树模型的决策过程
3. 可解释性报告
┌──────────────────────────────────┐
│ 预测结果：高风险（风险分：82） │
├──────────────────────────────────┤
│ 贡献最大的特征： │
│ 1. 设备关联账号数（+25） │
│ 2. 注册时间短（+18） │
│ 3. 交易金额异常（+15） │
│ 4. IP归属地异常（+12） │
│ 5. 操作序列异常（+12） │
└──────────────────────────────────┘
六、实时风控 vs 离线风控
风控系统需要处理两种场景：实时决策和离线分析。
实时风控
在交易发生的瞬间做出决策，通常要求在100-500毫秒内完成。
1. 低延迟要求
- 总耗时 < 500ms（通常 < 200ms）
- 包含：数据获取 + 特征计算 + 规则执行 + 模型推理
2. 高并发
- 峰值QPS可能达到数万
- 需要水平扩展能力
3. 高可用
- 风控不可用意味着交易不可用
- 需要降级方案（我们暂未实现，目前采用人工审核兜底）
1. 特征预计算
- 离线计算好大部分特征
- 实时只需获取+少量计算
2. 内存数据库
- Redis存储用户画像
- 亚毫秒级读取
3. 规则引擎优化
- 规则并行执行
- 短路机制（命中高风险规则立即返回）
4. 模型优化
- 模型压缩（剪枝、量化）
- 批量推理
- 模型缓存
交易请求
│
▼
┌─────────────┐
│ API网关 │ ← 限流、鉴权
└─────────────┘
│
▼
┌─────────────┐
│ 特征服务 │ ← 从Redis/DB获取特征（< 50ms）
└─────────────┘
│
▼
┌─────────────┐
│ 规则引擎 │ ← 执行规则集（< 30ms）
└─────────────┘
│
▼
┌─────────────┐
│ 模型服务 │ ← 模型推理（< 50ms）
└─────────────┘
│
▼
┌─────────────┐
│ 决策引擎 │ ← 综合输出（< 10ms）
└─────────────┘
│
▼
决策结果
离线风控
对历史数据进行批量分析，发现实时风控遗漏的风险。
1. 案例挖掘
- 从历史交易中发现遗漏的欺诈案例
- 补充训练样本
2. 关联分析
- 分析账户之间的关联关系
- 识别欺诈团伙
3. 规则优化
- 评估现有规则的效果
- 发现新的规则模式
4. 模型迭代
- 用新数据重新训练模型
- 评估模型效果变化
┌─────────────────────────────────────────┐
│ 离线风控架构 │
├─────────────────────────────────────────┤
│ │
│ 数据源 │
│ ├── 交易流水 │
│ ├── 用户行为日志 │
│ └── 风控决策日志 │
│ │
│ ↓ ETL │
│ │
│ 数据仓库（Hive/ClickHouse） │
│ │
│ ↓ 批处理 │
│ │
│ 分析任务 │
│ ├── 案例挖掘（Spark） │
│ ├── 关联分析（图计算） │
│ ├── 模型训练（PyTorch/TF） │
│ └── 效果评估 │
│ │
│ ↓ 输出 │
│ │
│ 成果应用 │
│ ├── 新规则上线 │
│ ├── 模型更新 │
│ ├── 黑名单补充 │
│ └── 用户画像更新 │
│ │
└─────────────────────────────────────────┘
实时与离线的协同
好的风
💬 评论 (0)