从查数到策略上线,风控人到底怎么用AI?

做信贷风控，一项策略从想法走到上线，中间要经过多少道工序？

查数据、拼宽表、加工特征、开发模型、测算策略、整理报告，再到任务部署、结果落库和监控报表。

不少时间，花在了这些细碎但绕不开的环节上。

SQL改了几轮，发现指标口径理解错了；宽表终于拼好，发现关联后样本量翻倍；模型离线效果很好，上线前才发现某个字段在申请时根本拿不到。

讨论AI如何赋能风控，可以先从这些具体问题入手。

AI的应用价值，要看它能否帮助完成一项有明确输入、输出和检查标准的工作。

今天，我们就沿着“数据—特征—模型—策略—运营”的工作流程，拆解几个具体场景。

01 数据查询：先把口径讲清楚

假设业务提出一个需求：“看一下最近一个月，各渠道的申请通过率。”

看上去很简单，但真正动手查数，至少要先确认：

• 最近一个月指自然月，还是滚动30天？

• 按申请笔数统计，还是按申请人数统计？

• 同一申请多次审批，取首次结果还是最终结果？

• 仍在审批中的申请，是否计入分母？

这些问题没说清楚，AI也可能写出一段能运行、但回答了另一个问题的SQL。

例如，同一个渠道有100笔申请，其中60笔通过、20笔拒绝、20笔仍在审批。按全部申请计算，通过率是60%；按已完成审批的申请计算，通过率是75%。

两种口径回答的问题不同。只给出一个“通过率”，业务很容易误读。

给AI的任务，可以写得更具体：

先让AI帮助梳理指标定义，再让它生成查询代码。

验收时，不能只检查SQL是否报错。还要抽取少量申请单，逐条核对状态与统计结果。

02 宽表与特征：盯住粒度和时间

宽表处理看起来是拼数据，实际上是在确定：一行数据代表谁，以及这一行允许包含哪些信息。

假设主表一行代表一笔申请，交易表一行代表一笔交易。直接用客户ID关联，一个客户有20笔交易，就可能把一笔申请展开成20行。

随后再计算通过率、训练模型，结果都可能受到影响。

AI可以辅助编写关联和聚合代码，但必须提前明确：最终宽表以什么为粒度？关联前需要怎样聚合？关联后怎样检查行数？

另一个关键问题是时间。

假设一笔申请发生在10月10日，我们要计算“申请前7天交易次数”，统计窗口必须以这笔申请的时间为锚点。

如果代码使用了当前日期，或者把申请之后的交易算进去，就把申请时尚不知道的信息带进了特征。

这样的特征可能让离线结果很好看，却无法在实际审批时复现。

可以先把特征定义写清楚：样本粒度是一笔申请，时间锚点是该笔申请时间，统计窗口为申请前7天，不包含申请时点及之后；同时区分“没有交易”和“交易数据未获取”。

优先检查两件事：有没有把一行变成多行，有没有把未来信息带回过去。    

03 模型开发：保留可比较的基准

进入模型环节，AI可以辅助编写训练脚本、整理实验参数、生成评估代码，以及汇总不同版本的结果。

但“跑出了一个模型”与“证明模型有改进”之间，还差一套一致的比较条件。

例如，原模型用较早月份的样本测试，新模型用另一个月份测试。即使新模型的指标更高，也不能把差异全部归因于模型能力。

样本组成、标签成熟度和客群风险水平，都可能影响结果。

更有用的任务描述是：

如果尝试让大模型阅读文本资料、提取风险标签，也可以把这些标签作为候选特征，检查它们是否带来增量信息。

同时需要记录模型版本、Prompt版本和输入字段。否则，后续输出发生变化，很难追溯原因。

模型开发中的AI辅助，应该让实验更容易复现、结果更容易比较。

04 策略制定：看清新增影响

模型给出风险分数之后，业务仍然要决定怎么用。

哪些客户通过？哪些进入复核？哪些需要补充材料？不同客群是否采用同一套阈值？

这里可以让AI辅助整理策略候选方案、生成回测代码、汇总覆盖情况，但决策依据需要来自实际测算。

例如，一条新增规则命中了1,000笔历史申请，其中700笔原本就会被旧策略拦截。

这条规则新增影响的范围，是剩余300笔。

如果只看“命中1,000笔”，容易高估它带来的增量价值。还需要检查新增影响的300笔是什么客群、表现如何，以及是否增加了正常客户的受影响范围。

一次策略测算，至少要同时看总命中量、与旧策略重合量、新增影响量、客群分布，以及通过率和复核量的变化。

这里还要留意：历史被拒客户通常缺少本机构的后续还款表现，不能简单把他们当作已知的好客户或坏客户。

AI可以加快策略测算，但结论必须建立在可观察的数据范围内。

05 报告与部署：设置检查点

策略测算完成后，还有一串工作：整理报告、部署任务、写入结果表、生成监控报表、发送通知。

这些环节可以引入AI辅助。生成代码、配置草稿和报告文字之后，还需要由具备权限的系统执行，并设置检查点。

例如，生成日报可以拆成：

某渠道当天申请量下降，AI可以描述“下降了多少、集中在哪个时间段”，也可以列出需要排查的方向。

但仅凭一张报表，不能直接认定“渠道质量下降”或“策略调整导致流量减少”。

部署任务也不能只看代码执行成功。还要检查重复运行是否造成重复写入、失败时有没有告警、结果为空时是否仍然继续生成报表。

流程越自动化，越要把异常处理写清楚。

06 从一个验收标准清楚的任务开始

如果团队准备开始尝试，可以先选一个重复频率高、输出容易核对的任务，例如日报整理、SQL初稿生成或特征代码辅助开发。

为它明确四件事：输入什么，输出什么，怎样验收，出错后怎样处理。

一个环节跑稳，再接入下一个环节，全流程应用才有可靠的基础。

今天（11月1日）下午14:30，番控学苑「金融信贷AI大模型应用实战营」已经正式启动。

课程从反欺诈切入，后续会继续覆盖贷前授信、贷中调额与贷后催收，把这些工作方法放到具体业务场景中展开。

大家也可以带着自己的日常任务来理解课程：哪一步最耗时间，哪一步最容易出错，哪一步已经具备清楚的验收标准。这样的任务，往往就是值得优先尝试AI辅助的起点。

想了解四周课程与实操安排，可以查看下方海报，扫码咨询。