AI智能路由指引-内测
AI 智能支付路由系统 — 使用说明
版本：v3.0 · 更新时间：2026-05-27
适用对象：商户、运营、产品团队
系统状态：内测中
一、这套系统是做什么的？
最终效果是：商户无感知，支付成功率持续提升，异常通道自动规避。
二、整体决策流程
订单进来
│
▼
┌─────────────────────────────────────┐
│ 第一阶段：规则引擎 │
│ 按业务规则过滤明显不合适的通道 │
│ 结果：得到一个"候选通道池" │
└────────────────┬────────────────────┘
│
▼
┌─────────────── ──────────────────────┐
│ 第二阶段：AI 决策引擎 │
│ 对候选通道池进行 AI 评分和融合打分 │
│ 结果：选出当前最优通道 │
└────────────────┬────────────────────┘
│
▼
返回最优通道，发起支付三、规则引擎详解
3.1 规则引擎的作用
3.2 规则类型与执行顺序
① 平台全局规则（对所有商户生效）优先执行
↓
② 商户专属规则（仅对指定商户生效）后执行
↓
③ 同类规则内按优先级从高到低执行
↓
④ 前一条规则已过滤的通道，不会被后续规则重复处理3.3 规则构成：条件 + 逻辑 + 动作
条件：检查通道指标或订单维度是否满足阈值
逻辑：多个条件之间是 AND（全部满足）还是 OR（任一满足）
动作：满足条件时对通道做什么处理| 逻辑类型 | 说明 | 典型场景 |
|---|---|---|
AND 全部满足 | 所有条件都成立，规则才触发 | "成功率低 且 响应慢"才过滤，避免误伤 |
OR 任一满足 | 任意一个条件成立，规则即触发 | "成功率低 或 AI 分低"就过滤，更严格 |
3.4 规则动作（3 种）
| 动作 | 说明 | 典型使用场景 |
|---|---|---|
| 过滤（exclude） | 将命中条件的通道从候选池移除 | 成功率过低、不支持该支付方式 |
| 白名单路由（include_only） | 只允许指定通道参与决策，其余全部排除 | 大额订单走专属 VIP 通道 |
| 轮询切换（rotation） | 按金额或失败次数阈值在通道间轮流切换 | 平衡多通道流量分配、规避单通道限额 |
3.5 可配置的条件字段
实时成功率（7 个时间窗口）
| 字段 | 时间窗口 | 数据来源 | 推荐场景 |
|---|---|---|---|
success_rate_1m | 近 1 分钟 | Redis 实时滑动窗口 | 紧急异常快速响应，敏感度最高 |
success_rate_5m | 近 5 分钟 | Redis 实时滑动窗口 | 日常首选，兼顾实时性与稳定性 |
success_rate_10m | 近 10 分钟 | Redis 实时滑动窗口 | 中等敏感度规则 |
success_rate_30m | 近 30 分钟 | Redis 实时滑动窗口 | 持续性低成功 率检测 |
success_rate_1h | 近 1 小时 | 数据库聚合统计 | 综合评估，AI 评分的核心输入 |
success_rate_6h | 近 6 小时 | 数据库聚合统计 | 夜间等周期性规则 |
success_rate_24h | 近 24 小时 | 数据库聚合统计 | 长期稳定性基准 |
成功率值范围 0~1，支持百分比写法， "80%"与"0.8"等效。
AI 综合评分
| 字段 | 说明 |
|---|---|
ai_score | AI 综合评分（0~100 分），由 AI 引擎每 60 秒计算一次 |
通道自身属性
| 字段 | 说明 |
|---|---|
channel_status | 通道状态：1=启用，0=停用 |
weight | 商户对该通道设置的权重（1~100） |
pay_way_code | 通道支持的支付方式列表 |
订单维度
| 字段 | 说明 |
|---|---|
order_amount | 本笔订单金额（单位：元） |
order_hour | 当前小时（0~23），支持跨零点时间段 |
3.6 规则时间窗口控制
| 配置项 | 说明 | 示例 |
|---|---|---|
startTime / endTime | 生效时段，支持跨零点 | "21:00" ~ "08:00" |
dateType | 生效日期类型 | weekdays（工作日）、weekends（周末）、daily（每天） |
timezone | 时区 | "Asia/Shanghai" |
{
"startTime": "21:00",
"endTime": "08:00",
"dateType": "weekdays",
"timezone": "Asia/Shanghai"
}3.7 轮询功能详解
| 轮询类型 | 触发条件 | 适用场景 |
|---|---|---|
| 金额轮询（amount） | 单笔订单金额 ≥ 配置的阈值时切换 | 避免单通道承载过大金额，规避限额和风控 |
| 失败轮询（fail） | 累计失败次数 ≥ 配置的阈值时切换 | 通道质量不稳定时自动绕行 |
| 混合轮询（both） | 满足金额或失败条件任一即切换 | 综合保护 |
| 字段 | 说明 | 示例 |
|---|---|---|
type | 轮询类型 | "amount" / "fail" / "both" |
threshold | 金额阈值（单位：元，金额轮询时使用） | 300 表示单笔订单 ≥ 300 元时切换 |
failThreshold | 失败次数阈值（失败轮询时使用） | 10 表示累计失败 10 次时切换 |
direction | 轮询方向 | "asc"（正向轮询）/ "desc"（逆向轮询） |
cooldownSeconds | 冷却时间（秒，仅失败/混合轮询生效） | 60 表示切换后 60 秒内不再切换 |
配置：
轮询类型：金额轮询
金额阈值：300 元
轮询方向：正向（asc）
效果：
订单 ¥368 → 通道 A
订单 ¥838 → 通道 B
订单 ¥999 → 通道 C
订单 ¥533 → 通道 D
订单 ¥757 → 通道 A（循环回来）
... 依次轮询3.8 规则配置示例
条件：success_rate_5m < 80%
逻辑：AND
动作：过滤
说明：5 分钟内成功率低于 80% 说明通道正在抖动，直接移出候选池条件：order_amount ≥ 5000
逻辑：AND
动作：白名单路由 → 指定 VIP 通道 A、VIP 通道 B
说明：大额资金对稳定性要求更高，强制走高质量专属通道条件：ai_score < 50
时间：22:00 ~ 06:00，每天生效
动作：过滤
说明：夜间运营人员值守少，加强过滤条件，减少人工干预需求条件：（无条件，持续生效）
动作：轮询切换
轮询类型：单笔订单金额超过 300 元时切换到下一条通道
轮询方向：正向轮询
冷却时间：60 秒（金额轮询不受冷却影响）
说明：避免单通道承载过多金额，规避限额和风控四、AI 决策引擎详解
4.1 AI 引擎的作用
4.2 双引擎评分架构
┌─────────────────────┐
│ ChannelScoreJob │
│ 每 60 秒执行一次 │
└──────────┬──────────┘
│
┌──────────▼──────────┐
│ ScoreCalcEngine │
│ │
│ ┌───────────────┐ │
│ │ Python ML 模型│ ← 优先：批量推理，精准评分
│ └───────┬───────┘ │
│ │ 不可用时 │
│ ┌───────▼───────┐ │
│ │ Java 规则公式 │ ← 降级：多窗口加权计算
│ └───────────────┘ │
└─────────────────────┘4.3 AI 评分模型：四维评分
AI 评分 =
成功率得分 × 50% ← 最重要：通道的支付成功率
+ 响应速度得分 × 25% ← 付款有多快
+ 稳定性趋势得分 × 15% ← 近期是在变好还是变差
+ 近期活跃度得分 × 10% ← 是否有足够的样本支撑评估
- 连续失败惩罚（最高扣 15 分）
- P95 高延迟惩罚（最高扣 10 分）
- 风控系统推送惩罚（最高扣 80 分）4.4 各维度评分算法
维度一：成功率得分
| 时间窗口 | 权重 | 说明 |
|---|---|---|
| 近 1 小时 | 50% | 近期表现，权重最高 |
| 近 6 小时 | 25% | 中期趋势 |
| 近 24 小时 | 15% | 长期稳定性 |
| 兜底基准值 | 10% | 无数据时的保守估计 |
维度二：响应速度得分
| 平均响应时间 | 得分 |
|---|---|
| 0 ~ 300ms | 100 分（优秀） |
| 300 ~ 800ms | 85 ~ 100 分 |
| 800 ~ 1500ms | 70 ~ 85 分 |
| 1500 ~ 3000ms | 45 ~ 70 分 |
| 3000 ~ 5000ms | 20 ~ 45 分 |
| > 5000ms | 0 分（不可接受） |
维度三：稳定性趋势得分
近 1 小时成功率 ≥ 近 24 小时成功率 → 100 分（趋势向好）
近 1 小时成功率 < 近 24 小时成功率 → 按差值线性扣分，最低保底 20 分（趋势恶化）维度四：近期活跃度得分
近 1 小时订单数 ≥ 5 笔 → 按对数曲线计算活跃度得分（0~100）
近 1 小时订单数 < 5 笔 → 固定 50 分（中等水平，不惩罚新通道）额外惩罚项
4.5 最终融合评分
最终融合评分 =
AI 评分 × 60% ← 核心，反映通道实时质量
+ 通道权重得分 × 20% ← 商户对各通道的偏好配置
+ 费率得分 × 10% ← 费率越低得分越高（成本优化）
+ 随机扰动 × 10% ← 防止流量完全集中到同一通道4.6 特殊决策策略
大额订单保护
大额保护 模式冷启动均匀分流
降级兜底保障
正常情况 → AI 决策最优通道
所有通道被过滤 → 从未熔断通道中随机兜底（标注降级标志）
所有通道熔断 → 从全部通道中随机兜底（标注降级标志）重试换通道
isRetry=true）时，系统自动跳过上次失败的通道，优先选取次优通道，避免重复踩坑。AI 低分软惩罚
4.7 权重自动训练
收集近 1 小时全部路由结果数据
↓
计算当前权重下的预测误差（实际成功率 vs 目标 95%）
↓
沿误差梯度方向微调四维权重
↓
归一化确保四维之和 = 1.0，写入 Redis 并持久化历史
↓
下一轮评分计算使用新权重[0.05, 0.80]，防止某一维度过度主导导致评分失衡。训练样本不足 100 笔时自动跳过本轮训练，避免小样本带来噪声。五、熔断保护机制
5.1 自动触发条件
| 触发条件 | 默认阈值 | 说明 |
|---|---|---|
| 近 5 分钟成功率过低 | < 30%（且样本 ≥ 10 笔） | 通道正在大量失败 |
系统每 60 秒由 ChannelScoreJob自动检测所有通道，发现异常立即熔断。
5.2 熔断时长指数退避
| 24 小时内第几次熔断 | 熔断时长 |
|---|---|
| 第 1 次 | 10 分钟 |
| 第 2 次 | 20 分钟 |
| 第 3 次 | 40 分钟 |
| 第 4 次及以上 | 2 小时（上限） |
5.3 半开自动恢复
熔断到期
↓
进入半开状态，接入少量真实流量试探
├── 连续 3 笔支付成功 → 完全恢复，重新纳入正常路由
└── 任意 1 笔支付失败 → 立即重新熔断（熔断次数继续累加）六、数据闭环：AI 如何持续学习
① 每笔订单路由到某通道，发起支付
↓
② 支付完成后，结果（成功/失败/超时关单）回写给系统
↓
③ 成功/失败结果进入 Redis 实时滑动窗口，立即影响成功率指标
↓
④ 每 60 秒，ChannelScoreJob 重新计算所有通道评分
↓
⑤ 优先使用 Python ML 模型批量推理；不可用时自动降级为 Java 规则公式
↓
⑥ 每小时，梯度下降训练优化四维权重
↓
⑦ 下 一笔订单路由时，使用最新评分做决策七、核心指标与预期效果
| 指标 | 说明 |
|---|---|
| 路由决策延迟 | 每笔订单路由耗时 ≤ 10ms（目标），对支付链路无感知 |
| 评分刷新频率 | 每 60 秒全量刷新所有通道评分 |
| 实时成功率感知 | 最短 1 分钟内感知通道质量变化（Redis 滑动窗口） |
| 熔断响应时间 | 5 分钟内自动识别并隔离异常通道 |
| 权重优化周期 | 每 1 小时自动完成一轮梯度下降训练 |
| 决策可追溯性 | 每笔路由决策全量记录：命中规则、AI 分、候选通道数、降级原因 |