金融风控场景的大模型落地——从规则引擎到 LLM 辅助决策的架构演进一、为什么规则引擎在金融风控中碰到了天花板在某头部消费金融公司风控系统经历了从人工审批到规则引擎再到机器学习模型的三次迭代。截至 2025 年 Q2规则引擎中维护着超过 1200 条风控规则这些规则覆盖反欺诈、信用评估、额度决策和贷后监控四大模块。每条规则都是一个if-then-else的判断逻辑例如如果用户近 6 个月多头借贷次数 5则拒绝。这套系统在稳定运行 3 年后暴露出三个根本性问题规则膨胀导致维护失控1200 条规则之间存在大量隐含的互斥和重叠关系。新增一条规则时风控分析师无法确认它是否与已有规则冲突。2025 年上半年就发生过一次因规则冲突导致的误杀——将正常用户的额度从 5 万压到 5000引发投诉。规则无法覆盖长尾模式规则是对历史经验的归纳天然无法识别从未见过的欺诈模式。2025 年 Q1一种新型的养号 小额多笔 跨平台协同欺诈模式在规则引擎有效工作的窗口期内造成了约 240 万的损失。规则更新周期过长从风控分析师发现新模式到规则上线平均需要 5 个工作日。在这个窗口期内欺诈团伙可以完成多轮攻击。这些问题的共同指向是规则引擎缺乏对语义和上下文的深层理解能力它只能匹配模式不能推理意图。这正是大语言模型可以发挥作用的地方。二、LLM 辅助风控的架构设计与规则引擎的协作模式在设计方案时团队否决了用大模型替代规则引擎的方案。核心考量有三点一是规则引擎的确定性在金融风控中不可替代任何通过率/拒绝率都必须可审计二是大模型的推理延迟通常在 200~800ms无法满足实时决策的 SLA100ms三是大模型存在幻觉风险不适合直接做通过/拒绝的二元判决。最终方案是**规则引擎主决策 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 落地不是简单的换模型而是一次从确定性决策体系到概率性辅助体系的系统性升级。稳最重要快在其次。