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 风控不成为失控黑箱的前提。
