📚 课程目录第2章风控基础

2. 风控基础

在进入DSL设计与解析执行之前，必须先建立一套稳定的风控领域心智模型。很多团队在规则脚本上反复返工，根源并不是语法设计不好，而是对“风控系统到底由哪些部件构成、它们之间如何协作”缺乏统一认识。本节围绕四个基础构件展开：核心概念、规则引擎、决策流、指标与名单体系，它们共同决定了后续DSL需要表达什么、解析器需要执行什么。

一、核心原理：风控系统的四个基础构件

风控的本质是在有限时间内，对一笔请求做出“放行、拒绝、复核”等决策。这个决策不是凭空产生的，而是由四类信息共同支撑：

事件与主体：一次登录、一笔支付、一次提现都是事件；事件背后关联用户、设备、IP、商户等主体。
指标：对主体历史行为的统计聚合，如“近1小时同设备登录次数”“近7天该卡退款率”。
名单：对主体或属性的确定性标记，如黑名单、白名单、灰名单、VIP名单。
规则与决策流：把指标、名单、事件属性组合成判断逻辑，并按顺序编排成可执行的决策路径。

这四者不是并列关系，而是有依赖顺序的：事件触发决策流，决策流中的规则读取指标与名单，最终输出决策结果。理解这条链路，才能理解DSL中为什么需要变量引用、函数调用、条件分支和结果输出等语法元素。

  核心记忆点：事件是输入，指标和名单是证据，规则是判断，决策流是编排，决策是输出。

二、规则引擎：从硬编码到可配置执行

规则引擎解决的核心问题是：把“如果……那么……”的业务判断从代码中剥离出来，变成可配置、可热更新、可审计的规则资产。一个典型规则引擎包含以下组件：

规则定义：描述条件与动作，例如“若近1小时同IP注册数大于5，则拒绝”。
规则解析：将规则文本或DSL转换为内部可执行结构，如抽象语法树或条件表达式对象。
规则执行：在运行时绑定上下文数据，计算条件真假，触发对应动作。
规则管理：负责版本、灰度、启停、优先级和冲突处理。

规则引擎常见的执行模式有两种：正向链与反向链。风控场景中更常用正向链，即从事件出发，依次匹配规则并累积结论。下面是一个简化规则配置示例：

rule: high_frequency_login
when:
  event.type == "login"
  and metric.login_count_1h(device_id) > 5
then:
  action: reject
  reason: "设备登录频率过高"
  score: 80

这段配置体现了规则引擎的三个关键点：条件可引用事件属性与指标、动作可携带原因与分值、规则本身可被解析器读取。后续章节的DSL设计，本质上就是为这类配置提供更严谨、更可组合的语法。

三、决策流：规则的编排与执行顺序

单条规则只能解决局部判断，真实风控需要多条规则协同。决策流就是规则的编排容器，它决定了规则以什么顺序执行、在什么条件下跳过、多个规则命中后如何合并结果。

一个典型的决策流通常包含以下阶段：

前置校验：参数完整性、必填字段、格式校验，不通过则直接返回错误。
名单命中：优先查询黑名单、白名单，白名单可直接放行，黑名单可直接拒绝。
指标计算：按需加载或实时计算指标，避免全量计算带来的性能浪费。
规则匹配：按优先级执行规则，可采用“首个命中即停止”或“全部执行后加权汇总”。
决策合并：综合规则分值、名单结果、策略权重，输出最终决策。

决策流设计的关键权衡：短路执行能降低延迟，但可能漏掉后续规则；全量执行信息更完整，但成本更高。实际系统常采用“名单短路 + 规则全量打分”的混合模式。

下面是一个决策流执行日志片段，展示了规则按顺序执行并最终合并结果的过程：

[decision_flow] start event=pay_001 user=u_8821
[stage:precheck] pass
[stage:list] blacklist=miss whitelist=miss
[stage:metric] login_count_1h=7 refund_rate_7d=0.32
[stage:rule] rule=high_frequency_login hit=true score=80
[stage:rule] rule=high_refund_rate hit=true score=60
[stage:merge] total_score=140 decision=reject reason=high_risk

四、指标与名单体系：风控的证据层

指标和名单是规则判断的证据来源。没有可靠的证据层，再优雅的DSL也只是空转。两者在风控中的定位不同，需要分别设计。

维度	指标	名单
数据形态	数值型统计结果	主体或属性的标记集合
更新频率	实时、准实时、离线	通常准实时或人工维护
典型用途	频率判断、阈值判断、评分	直接放行、直接拒绝、人工复核
存储方式	时序库、缓存、聚合表	KV存储、布隆过滤器、关系表
DSL中的引用	函数调用或变量引用	集合查询或布尔判断

指标设计要关注时间窗口、聚合维度和更新时效。例如“近1小时同设备登录次数”与“近24小时同设备登录次数”在风控含义上完全不同。名单设计则要关注命中优先级和过期机制，避免白名单永久放行或黑名单误伤。

常见误区：把指标当名单用，或把名单当指标用。例如用“是否命中黑名单”作为评分指标，会导致规则语义混乱；用“登录次数”作为名单判断，则失去了名单的确定性优势。

五、案例复盘：一次误拒引发的链路排查

某支付场景出现批量误拒，排查发现决策流中“高退款率”规则使用了离线指标，而该指标当天未更新，导致大量正常用户被误判。复盘结论有三点：

指标时效未在规则中声明，DSL缺少对数据新鲜度的校验能力。
决策流未设置“指标缺失时降级”分支，导致缺失值被当作高风险处理。
名单体系中的白名单未覆盖该批商户，缺少兜底放行机制。

这个案例说明，风控基础构件之间必须形成闭环：指标要有新鲜度元数据，规则要能表达降级逻辑，决策流要能编排兜底路径，名单要能提供确定性保护。后续设计DSL时，这些需求会直接转化为语法特性，例如指标引用需携带时间窗口参数、规则需支持else分支、决策流需支持阶段跳过与结果合并策略。

掌握本节四个基础构件及其协作关系后，再去看风控规则DSL，就能清楚每个语法元素存在的理由：它不是为了语法而语法，而是为了把事件、指标、名单、规则和决策流准确地表达出来，并让解析器能够稳定执行。