API乱码数据如何零代码加工为风控模型可用的信用分？——基于函数计算的结构化变量实践

在风控系统开发中，一个高频痛点是：外部征信API返回的原始JSON数据无法被规则引擎或模型直接消费。它不是‘脏数据’问题，而是语义断层——技术字段与业务因子之间缺乏可配置、可追溯、可复用的映射桥梁。本文以真实落地场景为例，说明如何通过类Excel函数式计算能力，在不写代码的前提下，完成从API响应到决策因子的端到端加工链路。

一、典型API响应为何不能直连风控模型？

征信API返回的JSON常存在以下三类结构性障碍：

• 嵌套深度大：如$.data.report.loanList[0].repaymentHistory.items[2].overdueDays，路径长且易因版本变更断裂；
• 字段语义模糊：同一含义字段命名不一（如overdue_cnt/isOverdueNum/num_of_overdue），类型不统一（字符串"2" vs 整型2）；
• 携带干扰信息：含requestId、timestamp、sign等非业务字段，且部分值存在GBK/UTF-8混编导致乱码。

风控模型依赖的是原子化、强类型、业务可解释的变量，例如：

```text
last_6m_overdue_count: integer, required, range [0, +∞)
```

该变量必须满足：来源可追溯、计算逻辑可复现、空值处理有明确定义。传统做法（手写Python解析脚本、定制ETL任务）难以支撑规则小时级调整与全链路审计要求。

二、函数计算器：零代码实现JSONPath提取+类型清洗

系统内置API函数类型，支持在可视化界面配置：

• HTTP方法（GET/POST）、请求头（Authorization、Content-Type）；
• 请求体模板（支持变量插值，如{"id": "{{applicant_id}}"}）；
• JSONPath提取表达式（如$.data.creditReport.overdueCount）。

提取后，原始值进入函数式清洗流水线。所有操作基于类Excel函数库，无需写循环或条件语句，示例如下：

• 统一空值：if(isNull(x), 0, parseInt(x))；
• 截取数字子串（应对"逾期次数：2次"类文本）：parseInt(substring(x, indexOf(x, "：") + 1, 2))；
• 多字段归一（兼容不同API命名）：coalesce(overdue_cnt, isOverdueNum, num_of_overdue)。

每个基础变量遵循‘单输入→单输出’范式，例如：

```text
变量名：first_loan_overdue_days
来源路径：$.data.loanList[0].overdueDays
清洗公式：if(isNull(x), 0, parseInt(x))
输出类型：integer
```

执行过程自动记录完整上下文：输入快照、中间结果、耗时、时间戳，支持秒级定位异常环节（是API超时？路径错位？还是parseInt失败？）。

三、复合变量构建：用声明式函数替代手写循环

基础变量仅解决单点映射。真实风控需聚合语义，例如last_6m_overdue_count——它要求对贷款列表（数组）做三步声明式操作：

• 过滤：filter(loanList, item => dateDiff(now(), item.lastRepayDate) <= 180)；
• 判定：map(filtered, item => item.isOverdue == true ? 1 : 0)；
• 聚合：sum(mapped)。

实际配置中，仅需三步可视化操作：

• 创建API函数获取完整loanList；
• 新建复合变量last_6m_overdue_count，选择filter()函数，设置时间过滤条件；
• 在同一变量内叠加countIf()函数，指定isOverdue == true为计数条件。

该变量一经定义，即注册进全局变量池，具备独立生命周期：

• 类型明确：integer；
• 来源可溯：绑定至特定API函数ID；
• 逻辑封装：上游节点仅需引用变量名，无需感知底层JSON结构；
• 复用自由：同一变量可同时用于贷前拦截（硬规则）、贷中评分卡（加权分）、模型特征工程（离线特征表同步）。

四、变量接入风控决策流：实时计算 + 全链路日志

加工完成的变量可直接拖入规则引擎画布参与决策：

– 在评分卡节点中配置分段打分逻辑：
– last_6m_overdue_count == 0 → 得30分；
– last_6m_overdue_count >= 1 && last_6m_overdue_count <= 2 → 得15分；
– last_6m_overdue_count >= 3 → 得0分；

– 在条件分支中作为布尔表达式使用：
```
last_6m_overdue_count > 3
```

执行时，引擎按需触发变量计算（惰性求值），并自动串联后续规则节点。每次调用生成结构化执行日志，包含：

• 变量来源标识（如“征信API函数E6_v2”）；
• 计算过程摘要（如“共加载贷款12条，筛选出近180天内贷款5条，其中2条isOverdue为true”）；
• 规则命中路径（如“进入拒绝分支：last_6m_overdue_count > 3”）。

这种设计满足风控系统对可解释性（Why）、可追溯性（Where）、可复用性（How often） 的核心合规要求。