AI驱动的账户风控系统——大模型在金融一致性场景中的分布式设计实践

AI驱动的账户风控系统——大模型在金融一致性场景中的分布式设计实践

一、传统风控的局限：规则的边界就是系统的盲区

任何做过金融账户系统的工程师都经历过同一个循环：先定义几十条风控规则，用 Drools 或硬编码的 if-else 把规则固化下来，上线后每天盯着误报率和漏报率。第一周效果不错——单笔大额转账被拦住了、夜间高频操作被标记了。一到两周后，业务方开始投诉"正常操作被误拦"，规则需要加白名单。一个月后，规则膨胀到几百条，白名单越来越长，维护成本追上了风控收益。

传统规则引擎存在三个结构性缺陷。第一是规则的静态性——规则一旦定义就固定下来，而攻击模式在持续演化，规则的更新滞后于风险变化。第二是上下文的碎片化——规则只能访问有限的几个字段（金额、时间、频次），无法理解一笔转账的业务含义：是正常的 B2B 付款还是洗钱资金流转？同一个人上午转出一笔小额、下午收到等额回款，规则引擎将其视为两笔独立交易，不会触发任何关联告警。第三是维护成本的线性增长——每增加一种新业务场景，就需要定义对应的规则集，当规则数量超过二百条时，规则之间的冲突和优先级问题就变得难以治理。

大模型在这个场景的切入点不是替代规则引擎，而是在其边界之外做补充。规则引擎擅长"确定性判断"——金额超过十万且不在白名单中则拦截——这类场景不需要 AI。大模型擅长"非确定性判断"——交易链路是否异常、用户行为模式是否偏离历史基线、多维度特征之间是否存在可疑关联。二者的关系是互补：规则引擎负责底线防御，模型负责智能发现。

二、AI驱动风控架构：规则做防线，模型做决策辅助

架构的核心设计是"三级决策 + 两层兜底"。第一级由规则引擎处理确定性的拦或放——凡是能靠固定规则判断的场景，不消耗 LLM 调用成本。第二级由大模型处理落在灰色区间的请求——规则引擎既不明确拦截也不明确放行的 case。第三级是人工审核——对极高风险或模型置信度偏低的 case 升级到人工处理。两层兜底分别是：LLM 超时或不可用时回退到规则引擎；模型评估出现异常时采用保守策略（拦截优先）。

在特征构建层面，传给大模型的上下文必须覆盖四个维度。交易维度：金额、交易类型、对方账户的风险等级和历史行为轨迹。行为维度：当前用户七天内、三十天内的操作频率、时间分布、设备指纹变化序列。关联维度：当前交易和该用户历史交易链路的关联关系——包括资金流向图、交易对手重合度、时间序列上的异常跳跃模式。环境维度：IP 归属地变化、设备切换频率、登录与交易的间隔时间是否合理。四个维度的特征经过匿名化和归一化后再组织为提示词，避免将 PII（个人身份信息）直接传递给外部模型。

三、LLM 风控评分的 Java 实现示例

@Service public class LlmRiskAssessmentService { private final RiskFeatureExtractor featureExtractor; private final LlmClient llmClient; private final RuleEngine ruleEngine; private final RiskDecisionRepository decisionRepository; private final AlertService alertService; /** * 评估单笔交易的风险等级。 * 规则引擎优先处理确定性场景，不确定的场景交由 LLM 评分。 * 任意环节失败均有降级兜底策略。 */ public RiskAssessmentResult assess(TransactionRequest tx) { // 1. 提取匿名化多维度特征，特征提取失败则拒绝 RiskFeatures features; try { features = featureExtractor.extract(tx); } catch (FeatureExtractionException e) { return RiskAssessmentResult.REJECT("特征提取失败: " + e.getMessage()); } if (features == null || features.isEmpty()) { return RiskAssessmentResult.REJECT("特征数据为空"); } // 2. 规则引擎优先判断，确定性结果直接返回 RuleResult ruleResult = ruleEngine.evaluate(features); if (ruleResult.isDeterministic()) { decisionRepository.save(tx.getTransactionId(), ruleResult, "RULE_ENGINE"); return ruleResult.toAssessmentResult(); } // 3. 构建 LLM 上下文提示词，强制 JSON 输出格式 String prompt = buildRiskPrompt(features); if (prompt == null || prompt.isEmpty()) { // 降级：提示词构建失败时使用规则引擎兜底 return ruleEngine.getDefaultDecision(features); } // 4. 调用大模型进行风险评分，超时阈值 3000ms LlmRiskResponse llmResponse; try { llmResponse = llmClient.assessRisk(prompt, 3000); } catch (LlmTimeoutException e) { // LLM 超时时降级，同时触发告警 alertService.sendAsyncAlert("LLM_RISK_TIMEOUT", tx.getTransactionId()); decisionRepository.save(tx.getTransactionId(), RuleResult.UNCERTAIN, "LLM_TIMEOUT_FALLBACK"); return ruleEngine.getDefaultDecision(features); } catch (LlmServiceException e) { // LLM 服务不可用时降级并告警 alertService.sendAsyncAlert("LLM_RISK_UNAVAILABLE", tx.getTransactionId() + ":" + e.getMessage()); decisionRepository.save(tx.getTransactionId(), RuleResult.UNCERTAIN, "LLM_UNAVAILABLE_FALLBACK"); return ruleEngine.getDefaultDecision(features); } // 5. 解析 LLM 返回的风险评分和置信度 int riskScore = parseRiskScore(llmResponse); int confidence = parseConfidence(llmResponse); String reasoning = llmResponse.getReasoning(); // 6. 根据评分和置信度确定处置动作 RiskDecision decision = determineDecision(riskScore, confidence); // 7. 持久化决策记录，用于离线评估和模型迭代 decisionRepository.saveAssessment(tx.getTransactionId(), riskScore, confidence, reasoning, decision); return new RiskAssessmentResult(riskScore, confidence, decision, reasoning); } /** * 构建风控提示词，强制 LLM 返回结构化 JSON。 * 提示词中不包含 PII，仅传递匿名化的行为特征数据。 */ private String buildRiskPrompt(RiskFeatures features) { return String.format(""" 你是金融风控分析助手。请基于以下匿名化交易特征评估风险等级。 交易特征： - 金额：%s 元 - 交易类型：%s - 对方账户风险标签：%s - 过去 24h 交易笔数：%d - 过去 7d 交易总额：%s 元 - 设备指纹变化：%s（稳定/轻度变化/重度变化） - IP 归属地变化：%s（同城/跨市/跨国） - 交易时间异常度：%s（正常/轻度异常/重度异常） - 30d 内首次与该对手交易：%s 请按以下 JSON 格式返回评估结果，不要输出其他内容： {"risk_score": int(0-100), "confidence": int(0-100), "reasoning": "string"} """, features.getAmount(), features.getTransactionType(), features.getCounterpartyRiskLabel(), features.getTransactionCount24h(), features.getTotalAmount7d(), features.getDeviceFingerprintLabel(), features.getIpLocationLabel(), features.getTimeAnomalyLabel(), features.isFirstTransactionWithCounterparty30d()); } private RiskDecision determineDecision(int riskScore, int confidence) { // 高风险 + 高置信度：升级人工审核 if (riskScore > 80 && confidence > 70) { return RiskDecision.MANUAL_REVIEW; } // 中等风险 或 低置信度：降级处理（限额或二次验证） if (riskScore > 50 || confidence < 50) { return RiskDecision.DEGRADE; } // 低风险 + 高置信度：放行 return RiskDecision.ALLOW; } private int parseRiskScore(LlmRiskResponse response) { try { int score = Integer.parseInt(response.getField("risk_score")); // 校验评分范围合法性 if (score < 0 || score > 100) { return 85; // 越界时保守处理为高风险 } return score; } catch (NumberFormatException e) { // LLM 输出格式异常时，保守处理为高风险 return 85; } } private int parseConfidence(LlmRiskResponse response) { try { int conf = Integer.parseInt(response.getField("confidence")); if (conf < 0 || conf > 100) { return 40; // 越界时标记为低置信度 } return conf; } catch (NumberFormatException e) { return 40; } } }

实现中有四个关键设计决策。第一，LLM 的输出通过提示词强制限定为 JSON 格式，解析失败时采用保守策略——将未知视为高风险，杜绝"因为格式解析失败而放行了风险交易"的可能。第二，LLM 超时或不可用时降级到规则引擎，保证风控链路不中断，同时触发异步告警通知值守工程师。第三，所有 LLM 的评估结果——包括评分、置信度和推理过程——全部持久化到决策日志表，作为离线评估和后续模型微调的数据基础。第四，提示词中明确说明"匿名化"，不传递任何个人身份信息（PII），只传递脱敏后的行为特征标签。

四、模型治理与安全边界：AI 不能成为失控的黑箱

把 LLM 引入金融风控链路后，面临一套新的治理问题。传统风控规则是可审计的——任何一个拦截操作都可以追溯到具体规则编号和匹配条件。LLM 的决策是概率性的，相同的输入在不同时间、不同模型版本下可能产生不同的输出（即使 temperature 设为零也不能完全消除）。因此必须建立完整的模型治理体系。

离线评估体系。每两周输出一次评估报告，关注四个核心指标：准确率（模型评分与人工标注的一致程度）、召回率（模型检测出的真实风险交易比例）、F1 分数（准确率和召回率的调和平均）、以及误拦截率的变化趋势。评估时设置三组基线对比：纯规则引擎的基线、LLM 辅助风控的基线、全量人工审核的基线。关键判断标准是——LLM 辅助风控在召回率上必须显著优于纯规则引擎，同时误拦截率的上升幅度不能超过两个百分点。

A/B 灰度实验。LLM 风控模块采用流量副本灰度方案——实时交易流量同时经过规则引擎和 LLM 评分，但 LLM 的评分在前两周只记录不执行。灰度期间每日对比规则引擎和 LLM 的决策差异，输出差异分析报告。差异率稳定在 10% 以内且误拦截率不上升的前提下，从第三周开始逐步切流至 LLM 评分，每次灰度放量不超过 20%。

强制安全边界。以下场景必须走规则引擎、禁止 LLM 介入：单笔金额超过一百万元、涉及监管制裁名单中的账户、同一用户连续三次触发人工审核后在二十四小时内的后续请求。这些场景的容错空间为零，不允许概率性判断参与。此外，LLM 在单日评估次数超过五千次时触发限流保护，超出限流阈值的请求全部回退到规则引擎处理，防止模型调用成本失控。

推理可解释性。LLM 的 reasoning 字段提供了评分依据，但自然语言解释的质量参差不齐。建立了一个 reasoning 质量评分机制：每周抽样一百条 LLM 推理记录，由风控团队对 reasoning 的逻辑完整性和数据引用准确性做人工评分。连续两周评分低于六十分时触发模型版本回滚。

五、总结

AI 驱动的账户风控系统在实践中采取"规则 + 模型"的混合架构：规则引擎处理确定性判断——这是底线防御，不容妥协；大模型处理灰色区间的非确定性判断——这是能力补充，用于发现规则引擎漏掉的隐蔽风险。LLM 的核心价值不在于替代规则，而在于理解交易上下文、捕获多维特征之间的隐藏关联、为灰色区间的交易提供可量化的风险参考。但模型治理不能缺失——离线评估、A/B 灰度实验、强制安全边界和推理可解释性这四道防线，是保证 AI 风控不成为失控黑箱的前提。