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