每一位搭乘飞机的乘客，都要在登机前穿过一道安检闸机。闸机前的安检员只有十几秒时间：核对证件、扫描行李、观察神态，然后给出一个不容犹豫的结果——放行，还是拦截。放走危险分子是事故，拦下普通旅客是投诉。今天我们要讲的主角——金融机构的实时风控引擎，就是支付世界的这座安检闸机。每一笔线上交易在扣款之前，都要经过它的毫秒级审视：这笔钱是本人操作，还是盗刷？是正常消费，还是欺诈？引擎内部，一本写满已知骗术的规则手册，和一位从海量案例中练出来的“模型专家”同时开跑，互不等待；各种实时特征像安检员的“火眼金睛”一样快速扫过交易数据；高峰期，系统会自动增开“安检通道”；更新换代时，新制度先在一条通道试点；设备故障时，人工检查立即顶上。这篇文章，就带你拆解这套“机场安检系统”的每一个部件。

岗位关联

掌握实时风控引擎的架构与调优方法，是进入金融 AI 领域的实务必修课。理解它，你将具备为千万笔交易保驾护航的系统设计能力。

目录
  1. 可视化演示
  2. 引擎总览：机场安检口的一天
  3. 并行推理架构：老安检员的两套技能
  4. 实时特征计算：安检员的火眼金睛
  5. 延迟控制策略：不能让队伍堵到候机厅
  6. 水平扩展设计：高峰期多开几个安检口
  7. 发布与降级：新规程先试点，坏设备不堵全局
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

展示规则与模型并行推理、延迟SLA预算与故障降级兜底，理解风控引擎如何在毫秒级完成风险判定并在高并发下稳定运行。支持三种模式切换与播放暂停。

本节配有交互动效（进入视口后自动加载，约 3KB）。

并行推理 规则覆盖已知/模型补未知 并行检测 规则引擎拦截已知模式，模型提升召回率。

引擎总览：机场安检口的一天

想象一座繁忙的机场航站楼，每一位旅客都要通过安检口。安检员要在十几秒内完成证件比对、行李扫描、随身物品检查，然后打出“放行”或“拦截”的决定。队伍不能停，检查不能漏，误放一个危险分子是事故，误拦一位普通旅客是投诉。金融机构的实时风控引擎，就是交易世界的这座安检口。

当你在手机上点下“立即支付”，订单请求在几十毫秒内到达风控引擎。引擎必须在极短时间里回答三个问题：这笔交易是本人操作吗？金额是否异常？收款方是否可疑？回答一旦超时，用户会看到转圈页面，大量交易排队积压——就像安检口前越排越长的队伍。一个生产级的实时风控引擎，通常由三个模块组成：接入层负责接收交易请求并实时计算特征，相当于安检口的引导线和 X 光机；决策层是心脏，里面运行着规则引擎和模型引擎两条并行的判定通道；执行层拿到判定结果后执行处置动作，比如直接放行、要求二次验证，或者拒绝交易。

性能上，行业通常用 P99 延迟（99% 的交易在多少毫秒内返回结果）和每秒交易处理量来衡量引擎的健康度。一笔交易从进入引擎到返回结果的总耗时，可以分解为四个环节：

安检系统的每个环节都被精确设计：先看证件、再过机器、必要时开包。实时风控引擎也一样，把总时间预算分给每个环节，哪一段慢了就优化哪一段。理解了整体结构，接下来深入这台“安检机器”的心脏——两套并行的判定技能。

ttotal=treceive+tfeature+tdecision+texecute\displaystyle t_{total} = t_{receive} + t_{feature} + t_{decision} + t_{execute}
把总耗时拆成四段，就像把一个安检流程拆成“排队、证件查验、行李扫描、登机牌核验”四个步骤。哪段慢，就优化哪段。
  1. 整体时间预算一笔交易从进入引擎到返回结果的总耗时，等于四个环节耗时之和。
    ttotal\displaystyle t_{total}
  2. 接入耗时t\_receive 是网络接收与协议解析的耗时，一般只有几毫秒。
    treceive\displaystyle t_{receive}
  3. 特征计算t\_feature 是实时计算风险特征的时间，是主要的可控成本。
    tfeature\displaystyle t_{feature}
  4. 决策与执行t\_decision 是规则与模型并行判定的耗时；t\_execute 是写入结果、触发处置的耗时。
    tdecision+texecute\displaystyle t_{decision} + t_{execute}

并行推理架构：老安检员的两套技能

一个有二十年经验的老安检员，口袋里永远揣着两样东西。一样是官方手册：液体不能超过 100 毫升、金属制品必须取出——这些是明文规定的规则。另一样是他的直觉：看到某个旅客神情紧张、行李异常，即便没有违反任何规定，他也会多问两句。风控引擎的决策层，正是这样一位“老安检员”。

手册对应规则引擎，直觉对应模型推理。规则引擎是专家们把已知欺诈模式写成条件判断，例如“单笔金额超过 5000 元且设备为高危型号，风险分 +40”。模型则从海量历史交易中自动学出规律，输入特征后输出一个 0 到 100 的欺诈概率。两条通道在引擎里并行执行，互不等待：规则引擎的代码执行通常在一两毫秒内完成，模型推理需要加载特征矩阵做矩阵运算，耗时稍长。

两者各得一个风险分后，由融合模块按权重合并。并行让决策耗时从“规则耗时 + 模型耗时”变成“规则耗时与模型耗时的较大值”——这正是低延迟的关键。融合公式如下：

老安检员从不会先查完手册再运用直觉——他是一边看一边想，两套技能同时在脑子里开跑。规则与模型并行，正是这种“双核思考”的工程化。规则负责稳稳接住已知的骗术，模型负责嗅出未知的异常，两条腿走路，才走得又快又稳。

Sfinal=α×Srule+(1−α)×Smodel\displaystyle S_{final} = \alpha \times S_{rule} + (1 - \alpha) \times S_{model}
这个公式就像安检员的最终判断：七分靠手册、三分靠直觉，乘以权重相加，得出一个 0 到 100 分的风险总分。
  1. 规则风险分S\_rule 是规则引擎输出的 0~100 专家评分。
    Srule\displaystyle S_{rule}
  2. 模型风险分S\_model 是模型输出的欺诈概率映射分。
    Smodel\displaystyle S_{model}
  3. 权重系数α 表示信任规则的程度，取 0 到 1 之间的小数，α 越大规则越权重。
    α\displaystyle \alpha
  4. 加权融合两个分数乘以各自权重后相加，得到最终风险评分 S\_final。
    α×Srule+(1−α)×Smodel\displaystyle \alpha \times S_{rule} + (1 - \alpha) \times S_{model}

实时特征计算：安检员的火眼金睛

安检员看人，扫一眼就能提取出关键信息：护照上的国籍、机票的航程、行李的形状。这些蛛丝马迹，在风控引擎里叫“特征”。特征是决策层做判断的原材料——没有特征，规则引擎和模型推理就成了无米之炊。

特征分为三类。第一类是用户画像，比如历史消费水平、常用登录地，它们通常提前计算好存在缓存里，交易时直接读取，就像安检系统里早已联网的旅客黑名单。第二类是设备指纹，比如手机的型号、IP 归属地、越狱状态，这相当于安检员观察旅客的穿着和随身物品。第三类是行为序列，比如最近 5 分钟的第 4 笔交易、金额的滑动窗口均值——这类特征必须实时计算，是判断“这个人现在是否异常”的关键。

实时计算依赖流式处理。引擎收到交易请求后，从内存数据库（如 Redis）中取出该用户的近期交易记录，在几毫秒内完成聚合。滑动窗口均值是最常用的聚合方式：取以最近一笔交易为锚点的、固定窗口内的 N 笔交易金额，计算平均值：

安检员的“火眼金睛”不是天生的，是无数趟旅客练出来的。风控引擎的特征库也一样，既有实时算出来的速度，也有历史数据沉淀出来的准头。画像、设备、行为序列三类特征组合成一份完整的“特征快照”，同时喂给规则和模型两条判定通道。

ft=1N∑i=1Nxi\displaystyle f_t = \frac{1}{N} \sum_{i=1}^{N} x_i
这个公式像安检员心里默算的“这趟航班的人均行李重量”——某位旅客的行李要是比其他人都沉得多，就该多问一句了。
  1. 窗口内样本x\_1 到 x\_N 是滑动窗口内 N 笔交易的金额序列。
    x1,x2,…,xN\displaystyle x_1, x_2, \dots, x_N
  2. 累加求和Σ 把所有 x\_i 加在一起，得到窗口内交易总额。
    ∑i=1Nxi\displaystyle \sum_{i=1}^{N} x_i
  3. 求平均除以 N，得到窗口内平均每笔交易金额 f\_t。
    1N\displaystyle \frac{1}{N}
  4. 特征含义若某笔交易金额远高于近期均值，就可能触发规则或模型的高风险信号。
    ft=1N∑i=1Nxi\displaystyle f_t = \frac{1}{N} \sum_{i=1}^{N} x_i

延迟控制策略：不能让队伍堵到候机厅

节假日高峰，安检口排起长队。为了不让队伍堵到候机厅大门，机场会采取一系列措施：增开通道、把液体检查挪到登机口、对低风险旅客开放快速通道。风控引擎的延迟控制，也是这套“治堵”思维。

一笔交易的实时性有硬指标。通常以 P99 延迟作为红线——99% 的交易必须在约定时间内（比如 100 毫秒）返回结果。总时间预算要在接入、特征、决策、执行四个环节间分配，任何一个环节超时都会拖垮整体，就像安检口的某个环节卡顿，整条队伍都会停滞。

延迟控制的三个常见手段。第一是并行化，规则与模型同时执行，时间取最大而非相加。第二是异步化，非关键路径不占同步链路——比如把交易样本异步写入数据仓库用于离线训练，而不是让用户等待数据落库。第三是超时熔断：为每个依赖设置超时上限，特征存储一旦超过 10 毫秒未返回，熔断器打开，后续请求直接走兜底逻辑，防止雪崩。延迟预算的不等式如下：

治堵的关键不是无限加快队伍本身，而是让每一段的节奏都不脱节。延迟预算把“别让队伍堵住”翻译成了一条清晰的不等式，超时熔断则是那句“如果这条通道堵了，立刻引导到备用通道”。预算管上限，熔断管意外，两条一起，队伍才能永远流动。

Ttotal=Tfeature+max⁡(Trule,Tmodel)+Texecute≤Tbudget\displaystyle T_{total} = T_{feature} + \max(T_{rule}, T_{model}) + T_{execute} \le T_{budget}
这条公式像机场的承诺：“从队尾到安检台，全程不超过 3 分钟。”规则和模型同时开跑，只算最慢的那个；哪个环节超时，就启动预案。
  1. 并行决策耗时max(T\_rule, T\_model) 表示规则与模型同时执行，只取耗时较大的那个。
    max⁡(Trule,Tmodel)\displaystyle \max(T_{rule}, T_{model})
  2. 前后环节特征计算 T\_feature 和执行 T\_execute 仍按顺序累加，无法并行。
    Tfeature+Texecute\displaystyle T_{feature} + T_{execute}
  3. 总预算约束整体必须小于等于约定的 T\_budget，即 P99 延迟预算。
    Ttotal≤Tbudget\displaystyle T_{total} \le T_{budget}
  4. 部署意义这个不等式是架构优化的目标函数——优化最慢环节收益最大。
    max⁡(Trule,Tmodel)\displaystyle \max(T_{rule}, T_{model})

水平扩展设计：高峰期多开几个安检口

春运高峰，安检通道从 4 条加开成 16 条，吞吐量立刻翻倍。机场能做到这一点，是因为每条通道都是独立的：有自己的安检员和设备，互不依赖。风控引擎想“加通道”，就要求决策引擎本身无状态。

所谓无状态，就是引擎实例不保存任何用户数据，所有特征都从外部的特征存储读取。这样一来，任意一个引擎实例都能处理任意一笔交易——就像任何一个安检口都能接待任何一位旅客。系统只需要在前面架一个负载均衡器，把交易按用户 ID 哈希到不同实例。

水平扩展有三个设计要点。第一是无状态化：决策引擎只依赖“特征快照 + 规则 + 模型参数”，这些都是可共享资源。第二是分片路由：用一致性哈希把用户分到不同的实例组，同一个用户的交易总是落在同一组，保证最近交易记录在局部缓存中命中。第三是弹性伸缩：根据 TPS 监控自动增减实例，高峰期扩容、低谷期缩容。系统总吞吐量与节点数的关系是：

每加一条安检通道，机场吞吐量就涨一份；每加一个引擎节点，风控系统处理能力也涨一份。无状态设计，就是让“加通道”这件事变得跟搭积木一样简单——这也是为什么它能撑住双十一、春节红包这类流量洪峰的核心秘密。

P(n)=n×psingle×e\displaystyle P(n) = n \times p_{single} \times e
吞吐量 = 通道数 × 每条通道的旅客吞吐 × 协同效率。通道越多，总吞吐越高，但也要注意协同损耗。
  1. 单节点吞吐p\_single 表示一个引擎实例每秒能处理的交易数。
    psingle\displaystyle p_{single}
  2. 实例数量n 是当前运行的引擎节点总数，就是开几条安检通道。
    n\displaystyle n
  3. 扩展效率e 是 0 到 1 的效率因子，理想线性扩展时 e 约等于 1。
    e\displaystyle e
  4. 系统总吞吐P(n) 随 n 近似线性增长，这是无状态设计带来的核心收益。
    P(n)=n×psingle×e\displaystyle P(n) = n \times p_{single} \times e

发布与降级：新规程先试点，坏设备不堵全局

机场想推行全新的安检制度，不会明天就在所有通道强制执行——先开放一条试验通道，观察效果，没问题再逐步推广；如果某台安检机突然故障，也不会让整座航站楼停摆，而是临时转为人工检查。这两个场景，对应风控引擎的灰度发布和故障降级。

灰度发布，是指新版本引擎先只接收一小部分流量（比如 5%），与老版本并行运行，观察指标稳定后再逐步提高比例到 10%、50%、100%。这一步一步的“切流量”，把风险压缩到可控范围——就像新制度先在一条通道试点，出了岔子也只影响少数旅客。

灰度期间要盯三个指标：误杀率（正常交易被拦截的比例）、漏放率（欺诈交易被放行的比例）和延迟。一旦误杀率显著高于老版本，立即自动回滚。故障降级则是另一套兜底预案：模型通道超时，降级为纯规则判定；特征存储不可用，用默认值代替特征重新计算；整体超时时，按“放行但不免除后续复核”的兜底策略，宁可事后追查，也不阻断业务。系统可用性可以这样评估：

新制度先在一条通道试点，坏设备用人工顶上。灰度发布与故障降级，让这台千万级交易“安检机”既能稳步升级，又不会在意外中全面停摆。升级不怕，故障不慌——这就是成熟风控引擎的底气。

A=1−pfail×Lloss\displaystyle A = 1 - p_{fail} \times L_{loss}
可用性 = 1 - 故障概率 × 故障损失。降级预案的价值，就是拼命把“故障损失”这一项压到最低。
  1. 故障概率p\_fail 表示单一依赖（比如模型服务）发生故障的概率。
    pfail\displaystyle p_{fail}
  2. 故障损失L\_loss 表示故障造成的业务损失，用归一化值衡量。
    Lloss\displaystyle L_{loss}
  3. 系统可用性A 是考虑故障概率后的等效可用率，目标让 A 趋近 1。
    A=1−pfail×Lloss\displaystyle A = 1 - p_{fail} \times L_{loss}
  4. 降级收益通过降级预案把 L\_loss 压到最低，整体可用性随之提高。
    1−pfail×Lloss→1\displaystyle 1 - p_{fail} \times L_{loss} \to 1

AI 应用场景

电商平台交易实时拦截

阶段：决策执行

解决的问题：传统风控靠人工审核订单，海量交易根本审不过来；仅靠静态规则又会漏掉复杂的团伙欺诈。实时风控引擎在支付前毫秒级完成判定，把“人盯单”变成“系统盯单”。

具体案例：某头部电商大促期间每秒产生数千笔交易。风控引擎用规则 + 模型并行推理，规则通道守住“大额 + 异地 + 新设备”等已知风险，模型通道捕捉轮番小额试探的团伙特征。上线后盗刷率下降 70%，P99 延迟稳定在 85 毫秒，用户无感知。

支付机构风控模型灰度切换

阶段：模型部署与运维

解决的问题：风控模型迭代频繁，一次性全量上线新模型，一旦误杀率波动会直接伤害用户体验。灰度发布通过流量切分，让新旧模型并行对比，把发布风险降到最低。

具体案例：某支付公司迭代了一版识别“羊毛党”的新模型。先切 5% 流量观察一周，误杀率比老模型降低 0.2 个百分点，再逐步放量到 50%、100%。全程自动化监控，误杀率超阈值时自动回滚，整个发布过程零客诉。

Python 演示

python89 行
# -*- coding: utf-8 -*-"""简化版实时风控引擎：滑动窗口特征 + 规则模型并行推理 + 加权融合"""import mathimport randomfrom collections import deque  class RiskFeatureExtractor:    """从交易流中实时计算滑动窗口特征"""     def __init__(self, window=10):        self.window = window        self.history = {}     def compute(self, tx):        user_key = tx['user_id']        if user_key not in self.history:            self.history[user_key] = deque(maxlen=self.window)        self.history[user_key].append(tx['amount'])        values = list(self.history[user_key])        avg_amount = sum(values) / len(values)        return {'recent_avg': avg_amount, 'count': len(values)}  class RuleEngine:    """规则引擎：专家规则打分，可解释且延迟低"""     def score(self, tx, feats):        s = 0.0        if tx['amount'] > 5000:            s += 40.0        if tx['country'] in ('A1', 'A2'):            s += 30.0        if feats['count'] > 5:            s += 30.0        return min(s, 100.0)  class ModelEngine:    """模型引擎：简易逻辑回归输出欺诈概率分"""     def __init__(self):        self.w = [0.6, -0.3, 0.8, 0.4]     def score(self, tx, feats):        x = [1.0, tx['amount'] / 10000.0, feats['recent_avg'] / 5000.0, feats['count'] / 10.0]        z = sum(wi * xi for wi, xi in zip(self.w, x))        return 1.0 / (1.0 + math.exp(-z)) * 100.0  class RiskEngine:    """实时风控引擎：并行推理 + 加权融合"""     def __init__(self, alpha=0.4):        self.extractor = RiskFeatureExtractor()        self.rule = RuleEngine()        self.model = ModelEngine()        self.alpha = alpha     def decide(self, tx):        feats = self.extractor.compute(tx)        rule_score = self.rule.score(tx, feats)        model_score = self.model.score(tx, feats)        final = self.alpha * rule_score + (1 - self.alpha) * model_score        if final > 65.0:            return '拦截', round(final, 1), feats        if final > 40.0:            return '复审', round(final, 1), feats        return '放行', round(final, 1), feats  def main():    countries = ['A1', 'B1', 'C1']    random.seed(7)    engine = RiskEngine(alpha=0.5)    for i in range(10):        tx = {            'trade_id': i + 1,            'user_id': random.choice(['u1', 'u2']),            'amount': random.randint(100, 9000),            'country': random.choice(countries),        }        verdict, final, feats = engine.decide(tx)        print(f"交易{i+1:02d} 金额{tx['amount']:5d} 国家{tx['country']} "              f"近均值{feats['recent_avg']:7.1f} 得分{final:5.1f} -> {verdict}")  if __name__ == '__main__':    main()
目的：实现一个微型实时风控引擎，演示“滑动窗口特征 → 规则与模型并行打分 → 加权融合”的完整决策流程。
  1. self.history[user_key] = deque(maxlen=self.window)用双端队列保存每个用户最近的交易记录，超龄交易自动弹出。
  2. values = list(self.history[user_key])取出当前窗口内的全部金额，用于聚合计算。
  3. avg_amount = sum(values) / len(values)滑动窗口均值，对应正文中的特征公式。
  4. if tx['amount'] > 5000:规则引擎的第一条专家规则：大额交易加 40 分。
  5. return min(s, 100.0)规则得分封顶，防止多条规则叠加后分数失真。
  6. z = sum(wi * xi for wi, xi in zip(self.w, x))逻辑回归的线性加权求和。
  7. return 1.0 / (1.0 + math.exp(-z)) * 100.0sigmoid 函数把实数映射为 0~100 的欺诈概率。
  8. final = self.alpha * rule_score + (1 - self.alpha) * model_score规则与模型加权融合，对应正文的融合公式。
  9. if final > 65.0:超过阈值直接拦截，阈值在实际生产中由误杀率和漏放率联合调优。
  10. random.seed(7)固定随机种子，保证每次运行结果一致，便于演示和测试。

常见误区

误区“现在都讲 AI 了，规则引擎就是一堆 if-else，精度比模型差远了，应该逐步淘汰，全换成模型推理。”

正解规则引擎和模型是互补关系而非替代关系。规则引擎对已知欺诈模式响应极快，可解释性强，合规审计需要它能说清“为什么拦这笔单”；模型擅长挖掘复杂隐晦的团伙特征。就像老安检员既需要官方手册也需要直觉判断，两个通道并行才是成熟做法。

为何常见：技术宣传总把“模型”和"AI"画等号，让人误以为传统规则没有价值；同时忽略了规则引擎在解释性和零训练成本上的优势。

误区“风控要快，把超时时间压到 10 毫秒，超出就放弃判定，这样用户永远不卡顿。”

正解超时时间过短会导致大量请求走兜底逻辑——兜底若设为拒绝，会误杀正常用户；若设为放行，又会漏放欺诈。延迟控制要做的是科学分配预算：给特征计算、并行决策、执行分别留足时间，并给熔断留出缓冲，而不是无脑压缩。

为何常见：只看到“延迟 = 用户体验”这一个指标，没有想清楚超时后的次生问题——就像只催安检员快点，却忘了检查质量。

误区“TPS 不够用了？买几台服务器，把服务在每台机器上都部署一遍，完事。”

正解如果引擎实例持有本地状态（比如进程内缓存了用户近期交易），加机器后同一用户的交易可能被路由到不同实例，特征对不上，判定就乱了。水平扩展的前提是无状态化：特征统一存外部存储，引擎只做纯计算，再用一致性哈希分片保证同一用户落在同一实例。

为何常见：把分布式系统想成“复制粘贴”，忽略了状态一致性这个关键约束。

误区“灰度 = 开个小分组，跑几天大盘指标没爆炸，就全量发布。”

正解灰度发布要有明确的对比指标体系（误杀率、漏放率、延迟），要设定自动回滚阈值，流量要按 5% → 10% → 50% → 100% 逐步放大。新旧版本并行期间还要处理特征格式兼容和结果日志隔离，否则灰度数据本身就是脏的。

为何常见：缺乏对线上变更风险的敬畏，把“发布”当成了“部署”，忽略了灰度是验证假设的科学实验。

面试题

Q1. 实时风控引擎最核心的目标是什么？

单选题 · easy

  • A.毫秒级判定每笔交易风险← 正确答案
  • B.定期清理并归档历史订单
  • C.所有交易必须经过人工审核
  • D.无限扩大数据库的存储容量

答案：A。实时风控引擎就像机场安检台，核心是在交易发生时快速完成风险判定。A 准确描述了“实时”和“判定”两个本质特征；B 是数据维护工作，C 是人工审核模式且不实时，D 是存储扩展，都与引擎的核心目标无关。

Q2. 规则引擎相比模型推理的优势是什么？

单选题 · easy

  • A.能发现复杂隐晦的欺诈模式
  • B.可解释且对已知模式响应快← 正确答案
  • C.无需任何历史数据即可工作
  • D.能自动适应所有新型欺诈手段

答案：B。规则引擎像官方手册，每条规则都写得明明白白、执行飞快，遇到已知欺诈模式立刻拦截。A 和 D 是模型的强项，C 是错误认知——规则也需要专家经验来编写，并非“无需数据”。

Q3. 融合公式 S = α × S\_rule + (1-α) × S\_model 中，α 表示什么？

单选题 · mid

  • A.模型训练迭代的总次数
  • B.规则评分所占的权重比例← 正确答案
  • C.当前交易金额的大小数值
  • D.引擎运行节点的副本数量

答案：B。α 是规则评分的权重系数，取值在 0 到 1 之间，α 越大规则越有话语权，(1-α) 就是模型的权重。它决定“手册”和“直觉”各占多少比重，与训练次数、金额、副本数无关。

Q4. 滑动窗口均值特征的主要用途是什么？

单选题 · mid

  • A.感知用户近期的行为突变← 正确答案
  • B.统计公司全年的营销总额
  • C.计算模型训练集上的误差
  • D.衡量服务器当前的 CPU 负载

答案：A。滑动窗口均值看的是“最近 N 笔交易的平均金额”，一旦某笔交易金额远高于这个均值，立刻产生异常信号。它针对的是用户短时间内的行为变化，与年度统计、训练误差、CPU 负载没有关系。

Q5. “P99 延迟低于 100 毫秒”的正确理解是什么？

单选题 · easy

  • A.99% 的交易在 100 毫秒内返回← 正确答案
  • B.100% 的交易在 99 毫秒内返回
  • C.每秒最多处理 99 笔交易
  • D.系统的可用率保持在 99%

答案：A。P99 是分位延迟指标，指排序后排在 99% 位置的那个耗时。A 描述准确；B 把两个数字搞反了，C 说的是吞吐量，D 说的是可用性，三个都不是延迟指标。

Q6. 以下哪些特征可以在交易发生时实时计算？

多选题 · mid

  • A.近三月消费均值画像特征
  • B.最近五分钟之内的交易笔数← 正确答案
  • C.设备指纹与常用设备的匹配← 正确答案
  • D.开户时录入的身份证号码信息

答案：BC。实时特征指交易瞬间动态计算出的信息：最近 5 分钟交易笔数需要实时聚合，设备匹配度需要实时比对。A 是预计算画像特征、D 是静态属性，都不是“实时计算”出来的。

Q7. 风控引擎实现水平扩展的前提设计是什么？

单选题 · mid

  • A.决策引擎无状态且特征外置← 正确答案
  • B.把特征缓存存放在引擎本地
  • C.所有交易路由到同一个节点
  • D.关闭负载均衡直接访问节点

答案：A。无状态化让任何实例都能处理任何交易，特征外置到统一存储保证数据一致，这是加机器有效的根基。B 的本地缓存会破坏一致性，C 和 D 直接放弃了负载均衡与横向扩展。

Q8. 灰度发布新版本风控引擎时，正确的做法有哪些？

多选题 · hard

  • A.从百分之五流量开始逐步放大← 正确答案
  • B.监控误杀率与漏放率指标变化← 正确答案
  • C.异常时自动回滚至旧版本← 正确答案
  • D.首日直接切换全量流量

答案：ABC。灰度发布像机场试点新安检制度：先小范围试运行，盯紧关键指标，出了问题立刻撤回。D 直接把全部流量切到新版本，一旦误杀率飙升会造成大规模客诉，属于典型的发布事故。

Q9. 风控引擎故障降级时，哪些措施是合理的？

多选题 · hard

  • A.模型超时降级为纯规则判定← 正确答案
  • B.特征异常用默认值继续计算← 正确答案
  • C.整体超时按放行兜底保业务← 正确答案
  • D.故障时拒绝所有交易止损

答案：ABC。降级的目标是把故障损失压到最低：模型坏了用规则顶上，特征丢了用默认值粗略算，整体超时先放行、事后追查。D 一刀切拒绝所有交易，等同于把整个机场关闭，业务损失远大于欺诈损失。

Q10. 规则与模型并行推理相比串行推理的延迟优势是什么？

单选题 · extreme

  • A.决策耗时取两者耗时的较大值← 正确答案
  • B.决策耗时为两者耗时的总和
  • C.决策耗时完全不受任何因素影响
  • D.决策必须牺牲规则换取模型速度

答案：A。并行执行时，两条通道同时跑，总决策耗时由最慢的那条决定，公式为 max(T\_rule, T\_model)，而不是串行的相加。B 是串行的耗时，C 忽略了系统负载等影响因素，D 牺牲规则的方案会丧失可解释性。