金融风控场景的大模型落地——从规则引擎到 LLM 辅助决策的架构演进
一、为什么规则引擎在金融风控中碰到了天花板
在某头部消费金融公司，风控系统经历了从人工审批到规则引擎再到机器学习模型的三次迭代。截至 2025 年 Q2，规则引擎中维护着超过 1200 条风控规则，这些规则覆盖反欺诈、信用评估、额度决策和贷后监控四大模块。每条规则都是一个 if-then-else 的判断逻辑，例如"如果用户近 6 个月多头借贷次数 > 5，则拒绝"。
这套系统在稳定运行 3 年后，暴露出三个根本性问题：
规则膨胀导致维护失控：1200 条规则之间存在大量隐含的互斥和重叠关系。新增一条规则时，风控分析师无法确认它是否与已有规则冲突。2025 年上半年就发生过一次因规则冲突导致的误杀——将正常用户的额度从 5 万压到 5000，引发投诉。
规则无法覆盖长尾模式：规则是对历史经验的归纳，天然无法识别"从未见过"的欺诈模式。2025 年 Q1，一种新型的"养号 + 小额多笔 + 跨平台协同"欺诈模式在规则引擎有效工作的窗口期内造成了约 240 万的损失。
规则更新周期过长：从风控分析师发现新模式到规则上线，平均需要 5 个工作日。在这个窗口期内，欺诈团伙可以完成多轮攻击。
这些问题的共同指向是：规则引擎缺乏对语义和上下文的深层理解能力，它只能匹配模式，不能推理意图。 这正是大语言模型可以发挥作用的地方。
二、LLM 辅助风控的架构设计：与规则引擎的协作模式
在设计方案时，团队否决了"用大模型替代规则引擎"的方案。核心考量有三点：一是规则引擎的确定性在金融风控中不可替代，任何通过率/拒绝率都必须可审计；二是大模型的推理延迟（通常在 200~800ms）无法满足实时决策的 SLA（<100ms）；三是大模型存在幻觉风险，不适合直接做"通过/拒绝"的二元判决。
最终方案是**"规则引擎主决策 + LLM 辅助解释与预警"**的协作模式。
这套架构的核心思想是分层决策：规则引擎处理 90% 的确定性场景，LLM 处理 10% 的模糊场景和规则推荐。两个通道并行运行，互不阻塞。LLM 通道不做最终决策，而是输出一份结构化的风险分析报告，供风控分析师参考。
三、从 Prompt 工程到结构化输出的关键设计
LLM 辅助风控的核心挑战不是模型选型，而是 Prompt 工程和输出格式控制。金融风控要求输出的风险因子必须是可解释、可追溯、可量化的。
经过 3 轮迭代，我们沉淀了一套 Prompt 模板：
/**
* 风控 LLM 辅助分析的 Prompt 构建器
* 实现用户画像 -> 结构化风险报告的转换
*/
@Component
public class RiskAnalysisPromptBuilder {
private static final String SYSTEM_PROMPT = """
你是一位资深金融风控分析师。你的任务是基于用户的多维度数据，
输出结构化的风险评估报告。
规则：
1. 只基于提供的数据进行分析，不要推测数据中未包含的信息
2. 每个风险因子必须标注风险等级（高/中/低）和置信度（0~1）
3. 对每条结论必须提供 1~2 条支撑证据
4. 如果数据不足以做出判断，请明确标注"信息不足"
5. 输出必须是合法的 JSON 格式，不要添加任何额外文本
""";
private final ObjectMapper objectMapper;
public RiskAnalysisPromptBuilder(ObjectMapper objectMapper) {
this.objectMapper = objectMapper;
}
/**
* 构建完整的分析 Prompt
*/
public String buildPrompt(UserRiskProfile profile) {
try {
StringBuilder prompt = new StringBuilder();
prompt.append(SYSTEM_PROMPT).append("\\n\\n");
prompt.append("请分析以下用户的信贷风险：\\n\\n");
// 基础信息
prompt.append("【基础信息】\\n");
prompt.append(String.format("- 年龄: %d, 学历: %s, 职业: %s\\n",
profile.getAge(), profile.getEducation(), profile.getOccupation()));
// 借贷行为数据（脱敏）
prompt.append("【借贷行为】\\n");
prompt.append(String.format("- 近6月申请次数: %d\\n", profile.getRecentApplyCount()));
prompt.append(String.format("- 当前多头借贷平台数: %d\\n", profile.getMultiLoanPlatformCount()));
prompt.append(String.format("- 历史逾期次数: %d\\n", profile.getOverdueCount()));
// 设备与行为数据
prompt.append("【设备与行为】\\n");
prompt.append(String.format("- 设备是否Root/越狱: %s\\n",
profile.isDeviceRooted() ? "是" : "否"));
prompt.append(String.format("- 定位城市与IP城市是否一致: %s\\n",
profile.isLocationMatched() ? "是" : "否"));
prompt.append(String.format("- 申请时间段: %s\\n", profile.getApplyTimePeriod()));
prompt.append("\\n请输出以下 JSON 格式的风险分析结果：\\n");
prompt.append("""
{
"overallRisk": "低/中/高",
"riskFactors": [
{
"factor": "风险因子名称",
"level": "高/中/低",
"confidence": 0.85,
"evidence": ["证据1", "证据2"]
}
],
"recommendation": "建议通过/建议人工审核/建议拒绝",
"keyDoubts": ["疑点1", "疑点2"]
}
""");
return prompt.toString();
} catch (Exception e) {
throw new IllegalStateException("构建风控分析 Prompt 失败", e);
}
}
/**
* 解析 LLM 返回的 JSON 风险报告
* 包含容错处理：LLM 可能返回非标准 JSON
*/
public RiskAnalysisReport parseResponse(String llmResponse) {
try {
// 尝试提取 JSON 块（LLM 可能在 JSON 外层包裹了 markdown 代码块）
String jsonStr = extractJson(llmResponse);
RiskAnalysisReport report = objectMapper.readValue(
jsonStr, RiskAnalysisReport.class);
// 校验必填字段
if (report.getOverallRisk() == null || report.getRiskFactors() == null) {
throw new IllegalArgumentException("LLM 返回的风险报告缺少必填字段");
}
return report;
} catch (Exception e) {
// 解析失败时构造默认报告，不阻塞主流程
return RiskAnalysisReport.createDefaultWithError(
"LLM 响应解析失败: " + e.getMessage());
}
}
/**
* 从 LLM 原始响应中提取 JSON 字符串
*/
private String extractJson(String raw) {
if (raw == null || raw.isBlank()) {
throw new IllegalArgumentException("LLM 响应为空");
}
int start = raw.indexOf('{');
int end = raw.lastIndexOf('}');
if (start >= 0 && end > start) {
return raw.substring(start, end + 1);
}
throw new IllegalArgumentException("LLM 响应中未找到有效 JSON");
}
}
上述代码反映了一个关键的工程实践：永远不要假设 LLM 返回的内容是合法的。需要在外层做三层防护——JSON 提取、字段校验、异常兜底。对于金融风控场景，LLM 解析失败时不能阻塞流程，必须降级为人工审核。
四、离线分析通道：让 LLM 成为规则工厂的"产线工人"
LLM 在风控中的另一个高价值场景是离线模式挖掘。每周我们将过去 7 天内被人工审核标记为"欺诈"的案件（脱敏后）批量送入 LLM，让它从中提取共性模式并生成规则建议。
这个通道的实际效果超出了预期。在试运行的 3 个月内，LLM 从 1400+ 案件中共提炼出 23 条规则建议，其中 15 条经过风控分析师验证后上线。这些规则覆盖了多个传统手段难以发现的长尾模式，包括：
- "凌晨2~5点申请 + 设备使用时长 < 48小时 + IP归属地与账单地址跨越 3 省以上"的组合模式
- "连续 3 次申请被拒绝后，更换手机号重新注册，但设备指纹相同"的反复尝试模式
这些模式的发现周期从传统的"5 个工作日"缩短为"2 天"，且漏报率几乎为零——因为 LLM 是从已知欺诈案件中反向提炼特征，而非从全量数据中猜测。
五、落地的取舍与下一步演进方向
这套方案从上线至今 6 个月，取得了明确的业务指标提升：灰名单处理效率提升 60%（从人均日处理 80 件提升到 128 件，因为 LLM 预分析已经给审核员提供了清晰的疑点列表）；规则迭代周期从 5 天缩短为 2 天；误杀率从 3.2% 下降到 1.8%。
但也要诚实地说出局限性。LLM 辅助分析的延迟是硬伤——当前使用 Qwen2.5-72B 模型，平均推理延迟 450ms，虽然走的是异步通道不影响实时决策，但在高峰期积压问题需要关注。成本问题也不容忽视——单次分析调用的 API 成本约 0.02 元，月处理量在 6 万次左右，月成本约 1200 元。可解释性仍然是最大的障碍——当 LLM 输出"该用户存在欺诈风险"时，它的推理链条是黑盒的，这不符合监管对可解释性的要求。
下一步，团队计划将 LLM 能力进一步融入风控工作流的"事前"和"事后"环节。事前环节是指在新产品上线前，用 LLM 对目标客群画像做欺诈模式预判，提前部署规则；事后环节是让 LLM 对已放款的坏样本做深度复盘，自动生成归因报告。
金融风控领域的 LLM 落地，不是简单的"换模型"，而是一次从"确定性决策体系"到"概率性辅助体系"的系统性升级。稳最重要，快在其次。
