文章

KS 和 AUC：它们之间到底有没有数学关系

Sun, 14 Jun 2026 00:00:00 GMT

原文来源： 微信公众号「风控建模」| 作者：小溪1005 | 发布于 2026-06-14

原文链接： https://mp.weixin.qq.com/s/6CaTkC2MnoYqMhggcGeH2g

前两天群里有朋友问：

KS 和 AUC 之间，有没有数学上的约束关系？

第一反应是：应该有吧，它俩不都是从同一组 TPR、FPR 里算出来的吗？

后来有位群友给出了挺长的一段分析，观点听起来很有数学味道：

"ROC 的 TPR 和 KS 的 TPR 映射不同""范围公式暗含连续、凸的理想假设""数据离散就失效""代码说明不了什么""推导第一步就错了"

这段分析其实结论里有不少对的地方，但有几处论据，可以再一起商榷一下。今天就借这个话题，把 ROC、AUC、KS 三者的关系捋一捋。

一、"ROC 的 TPR 和 KS 的 TPR 映射不同"，这点可以再想想

对方的核心观点之一是：

"ROC 的 TPR 非 KS 的 TPR，只是恰好公式和排序一致罢了，映射不一样。""国内一直把两个 TPR 等同，推导第一步就错了。"

这里其实有个小小的循环：既然已经承认"公式和排序一致"，那结论也就包含在前提里了。

因为 ROC 和 KS 用的，本来就是同一组 (TPR, FPR)：

ROC 曲线：以 FPR 为横轴、TPR 为纵轴

KS 曲线：以阈值（或分位数）为横轴，把 TPR、FPR 两条线画出来

同一组数，换两种坐标画出来而已。给定阈值，和是唯一确定的；ROC 不过是把横轴从"阈值"换成了"FPR"，本质是一次坐标变换。

小结： 并不存在"两个不同的 TPR"，它们是同一份数据的两种画法。

二、"AUC、KS 需要 ROC 连续且凸"，这里的因果，或许说反了

很多人对 AUC 的第一印象是"曲线下面积"，于是自然联想到"面积 → 积分 → 需要连续"。

但 AUC 还有一个等价、而且更本质的定义：

这就是 Mann–Whitney U 统计量，它本来就是为离散、有限样本设计的非参数统计量，靠求和计算，并不需要连续性，也不需要可积。

至于"凸"：ROC 凸不凸，反映的是模型排序质量的好坏（有没有局部矛盾），它和"公式能不能算"是两件事。一条带凹陷、带平局斜段的 ROC，AUC 和 KS 照样能精确算出来。

小结： 连续和凸，可能并不是 AUC/KS 的前提——恰恰相反，它们本来就是为离散数据准备的。

三、"数据离散/有平局/有跳跃，公式就失效"——可以用代码验证

对方提到："数据有限、分数离散、排序有平局或跳跃，假设被破坏，公式自然失效。"

这个判断对不对，其实很容易验证。构造一组比较极端的数据：大量平局、明显跳跃、排序还带矛盾。

运行结果：

AUC、KS 都能算出确定、可复现的数值。平局再多、跳跃再大，sklearn 照样能算——因为它算的本来就是离散公式。

关于"代码说明不了什么"这句，有点可惜，因为代码恰恰是最能把问题说清楚的方式：如果"公式因离散而失效"这个判断成立，那应该能举出一组让 AUC 算不出来的离散数据。如果找不到，"失效"这个说法可能就需要重新斟酌了。

四、"AUC 与 KS 走势接近只是经验现象"——对，但原因可能不太一样

对方说："AUC 与 KS 走势接近只是模型好时的经验现象，不是数学必然。""两者不是恒等关系"——这句完全同意。

但背后的原因，可能不是"连续性失效"，而是更朴素的一点：

指标	本质	度量什么
AUC	整条 ROC 下的面积	累积的整体排序能力
KS	单点极值	正负分布的最大分离度

一个是面积（累积量），一个是单点极值。两个度量维度不同的统计量，本来就不该恒等——哪怕数据完美连续，AUC 和 KS 也不会相等。这跟离散、平局其实关系不大。

不过，"不恒等"也不等于"没关系"。事实上，二者之间存在一个严格成立的上界约束：

也就是说，KS 是 ROC 上某一点到对角线的最大距离，AUC 是整条曲线的累积，两者在几何上被同一条 ROC 牢牢绑定着，并不是"毫无关联的两回事"。

五、"分箱 KS 更稳健"，这个结论很对，原因可以补充一下

对方说："只取最大值意义有限，金融行业要用 10/20 等频分箱评估 KS 才稳健。"

这个结论完全赞同，实务中确实是这么做的。只是原因和"连续性假设"关系不大，更多是两个很实在的考虑：

统计稳健性：单点最大 KS 是一个点估计，对样本扰动、异常值比较敏感，换一批样本可能就跳了；分箱看的是整体分布，更稳。

可监控性：风控更关心模型在各个分数段是否稳定（配合 PSI 一起监控），分箱天然契合这个需求；而单点 KS 把信息压成一个数字，丢掉了分段视角。

更准确的表述可能是：

"单点 KS 对扰动敏感、且丢失分段信息，因此工程上用等频分箱评估分数分布的整体稳定性。"

这样说既准确，也不需要借助"连续性假设""可积性"这些其实用不上的概念。

六、小结

观点	看法
ROC 的 TPR ≠ KS 的 TPR，映射不同	🤔 可能是同一组数据的两种画法
AUC/KS 需要连续、凸	🤔 因果或许说反了，二者本为离散设计
数据离散/平局使公式失效	🤔 可用代码验证，sklearn 照算不误
代码说明不了什么	🤔 代码恰恰最能说清问题
AUC 与 KS 不恒等	✅ 对，原因是"面积 vs 极值"
分箱 KS 更稳健	✅ 很对，源于统计稳健性 + 可监控性
高风险场景要更严谨	✅ 完全认同，方向可微调

写这篇文章，并不是想争个对错。那位朋友的工程直觉其实很好——分箱评估 KS、强调稳健性、提醒高风险场景要谨慎，这些都很对，也是大家平时在用的做法。

只是想补充一点：这些好结论，用准确的数学语言去表达，会更站得住脚。

KS 和 AUC 确实被同一条 ROC 曲线约束着（，严格成立、不依赖连续性）；但它们也确实不是一一对应，这两点并不矛盾。

附：上界不等式的严格推导

给感兴趣的朋友。这个上界严格、紧、且离散连续通吃。

命题： 对任意 ROC 曲线（离散或连续均可），有。

证明：

记 ROC 为单调不减函数，，满足，。

由 KS 定义，对所有有，同时显然，。

两条上界的交点在处，于是：

第一段积分：

第二段积分：

相加并化简即可得到：

等价形式：

本文转载自微信公众号「风控建模」，作者小溪1005，已获授权。如有不当请联系删除。

Vibe Coding 核心心法：管 Agent，如带团队（转载）

Fri, 15 May 2026 00:00:00 GMT

📌

本文转载自「Recsys Frontier」，作者：九老师原文链接：https://blog.recsys-frontier.com/article/vibe-coding-like-man-team 许可协议：CC BY-NC-SA 4.0（注明出处，非商业用途，相同方式共享）

这不是一篇教大家怎么实操文章，不谈具体的工具和技术，我们来谈谈Vibe Coding的心法。

Vibe Coding 本质是利用 Agent 编码，Agent 背后是 LLM，LLM 是人类的“幽灵”，这出自 Karpathy 2025 年终总结："we're not evolving animals. We're summoning ghosts."，语言是人类世界的投影，LLM 是人类的幽灵。

工具和技术层出不穷，这是历史上从未出现过的新技术，没有人有经验。但是人性是一致的，拿捏住 Agent 的“人性”，把 Agent 当人来管，会让 Vibe Coding 从迷茫走向有迹可循。

先说清楚什么是 Vibe Coding

2025 年 2 月 2 日，Andrej Karpathy 发了一条推文，随手造了一个词：

There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.

他描述自己用 Cursor 和 SuperWhisper 做项目，几乎不碰键盘，对着 AI 说话就行。"Accept All"，不看 diff，有报错就把错误信息粘进去，通常就修好了。代码越长越超出他自己的理解范围，有些 bug 修不了就绕过去，或者随便改改直到它消失。

"我在做一个项目或网页应用，但其实并不算是在写代码——我只是观察情况、动嘴指令、运行程序、复制粘贴，然后它基本上就能跑通了。"

这条推文被看了 450 万次，"vibe coding"成了 2025 年最火的年度词汇之一。但一年过去了，大部分人对它的理解依然是模糊的——很多人把它和 AI 编程混为一谈了。

AI 编程是什么？它范围更广，包含你用 Copilot、Cursor 之类的工具辅助写代码。AI 帮你补全、帮你生成函数、帮你重构。但你依然在看每一行 diff，依然在 review 每一个实现细节。AI 只是让你写得更快了。你还是那个写代码的人。

Vibe coding 完全不同——你不看代码。你输入一个想法，看产出。跑起来了吗？行为符合预期吗？对了就往前走，不对就换一种说法再试。代码具体怎么实现的，你不关心，甚至可能看不懂。

我理解这种不适，因为我自己也经历过。但后来我逐渐意识到，这种不适感，我并不是第一次体验。上一次有这种感觉，是我开始带团队的时候。Vibe coding 给我的感觉，和团队管理一模一样。这个类比一旦建立起来，很多事情就突然说得通了。

当你不再写代码，你的角色变成了什么

Vibe coding 的时候，你同时开着三个 Agent session。一个在重构模块，一个在写测试，一个在调 UI。你不需要盯着每个 session 的每一步，但你需要能快速切进去——看产出、做判断、给方向——然后切到下一个。这不就是一个一线 team leader 的日常吗？

第一次从 IC 转到 TL，最难受的不是工作内容变了，而是你不再拥有对过程的控制。以前所有的代码都经过你的手，你知道每一行写了什么。现在你要把键盘交给别人，看着他用你觉得“不够完美”的方式实现了同样的功能——你得忍住，因为结果是能跑对的。

你的价值不再是去执行、去把代码写对，而是去想清楚你到底要什么，以及去审查这是不是你想要的结果。你需要的不再是高效的执行能力，而是快速的切换与反馈。你需要有对和技术结果的高度的品位。

同一个瓶颈，同一种解法：异步协作。对齐目标和验收标准，放手让人去执行，到 checkpoint 看结果，有 blocker 再介入。最好的 vibe coder 和最好的 TL 做的事情是一样的——他们从来不站在工位后面盯着你写每一行代码。

你校验的不是代码，是结果

传统编程有一个隐含假设：代码写完，应该一次通过。写之前想清楚，写的时候小心翼翼，写完了跑一遍测试，过了就提交。整个流程的核心是对过程的信心——我写的代码我知道对不对。

Vibe coding 彻底放弃了这个假设。你不看代码，你当然不可能对过程有信心。Agent 会幻觉，而且幻觉得很自信——可能只是它没执行好，它就宣称这个方案是失败的。那怎么办？回去看代码？那就退回 AI 编程了。你校验的对象变了。不是代码对不对，是结果对不对。

我遇到过一个典型场景：Agent 告诉我“这个功能实现不了，建议换架构”。我没有去翻它的代码看哪里写错了。我开了一个新 session，把同样的需求重新描述了一遍。它做出来了。我不关心第一个 session 的代码哪里写错了，我只关心：结果能不能出来。能出来，就往前走。出不来，换个方式再试。

这是理念上的根本转变：你不再追求一次写对，你追求的是结果不断逼近正确。效率不来自一次做对，来自反馈和迭代速度。

你的瓶颈：上下文切换与反馈速度

一个一线 leader 的团队管理，更像是 multi-session 的单 Agent 管理，都是放弃了代码的控制权，转而把中心放在了任务的拆解，结果的预期管理和多轮的验收反馈。

回到那个画面：三个 session 同时跑。你是唯一的人类，它们都在等你的反馈。这时候你最大的瓶颈是什么？上下文切换的速度和并行处理事情的能力。Agent 很快。一个 session 跑完可能只要几分钟。但如果你是串行思维——处理完 session A 才去看 session B——你就成了整个系统的吞吐量瓶颈。三个 Agent 并行在跑，被你一个人卡成了串行。

任务的描述与拆解

你给 Agent 的 prompt 就是你给下属的需求文档。描述模糊，产出就模糊。描述精确，产出就精确。很多人 vibe coding 效果差，不是 Agent 不行，是他们的需求描述不行。

给 Agent 一个模糊大目标——“帮我重构这个模块”——它会茫然或者乱来。把大目标拆成具体小任务——“先把这三个函数抽成一个 class，保持接口不变，加上单元测试”——它才能精确执行。拆解任务的能力，本质上就是工程设计的能力。你不再亲手做，但你要知道该怎么做，才能把活拆对。

Context Rot（上下文腐烂）

一个 Agent session 走偏了，你会看到一个熟悉的模式：每次修复都引入新的问题，每次“快好了”之后都冒出新的 bug。它在一个错误的方向上越陷越深。继续纠偏还是推倒重来？这是沉没成本的陷阱。

大多数时候，果断关掉这个 session，用更好的描述开一个全新的，反而更快。因为这个 Agent 的上下文已经被错误污染过了，拖着满是错误的长上下文，只会让 LLM 降智。

Anthropic 官方 Best Practices：“如果你在同一个会话中就同一个问题纠正了 Claude 两次以上，那么上下文就已经充斥了失败的尝试。” 直接建议 /clear 重开。

Sourcegraph 工程师发现：Claude Sonnet 宣传有 20 万 token 限制，但上下文窗口质量在 14.7 万至 15.2 万 token 左右就会出现下降。有效上下文大约只有标称值的 75%。

每次 clear session，就是送走一个已经“污染”的幽灵，再召唤一个全新的。Karpathy 说得对，我们不是在进化动物，我们是在召唤幽灵——幽灵没有记忆积累，没有成长曲线，它只有当下这一次召唤的状态。接受这一点，你才能果断地 kill session 而不觉得浪费。好的管理者果断止损，好的 vibe coder 也是。

Agentic Engineering

2026 年 2 月 4 日，vibe coding 一周年。Karpathy 自己发了一条回顾帖，给这个概念做了升级。他说，vibe coding 是早期的、实验性的玩法。而现在专业级别的开发已经演化到了下一个阶段，他给它起了个新名字：Agentic Engineering。

'Agentic' because the new default is that you are not writing the code directly 99% of the time, you are orchestrating agents who do.

Orchestrating agents：编排 Agent。从 vibe coding 到 agentic engineering，变的是名字，不变的本质是：你不再是那个写代码的人，你是那个让 Agent 写出正确代码的人。

从反馈者到编排者

Orchestrate 这个词最早就是交响乐团的指挥（orchestra conductor）——不演奏任何乐器，但协调所有乐手的节奏、力度和进场顺序。前面讲的都是你直接带着几个 Agent session 干活。你是 TL，Agent 是你的下属。但如果任务足够复杂，光靠反馈已经不够了。你需要规划谁先做什么、谁的产出喂给谁、什么时候该合并、什么时候该回退。这时候你的角色就从反馈者变成了编排者。

“组织架构”升级

无论人和 Agent，组织架构升级的本质是：把“人来判断”变成“机制来判断”。你不再亲自验收每个 Executor 的产出。你要建立一个 Sub-team，让它具备两个能力：自主做日常规划决策，以及内建纠错机制。

我把一个子任务拆成至少 3 个角色：Planner 规划任务，Executor 执行任务，Reviewer 审查过程和结论。

Planner（sub-Leader）负责对抗 Agent“人性”里的短视和畏难，避免 Executor 目标不清晰。Planner 需要长期记忆，他需要记住全局视图，哪些路径试过了，哪些结论已经被验证了，当前的优先级是什么。

Executor 是每次编码执行的时候才 Spawn 出来的，避免了长上下文后的“变蠢”和偏离目标。它积累的不是经验，是偏见。

Reviewer 在处理复杂的多变量问题时候，Review 代码和结论。没有 Reviewer，结论层层汇报上去，可能 Orchestrator 误认为目标达到了。

这个架构解决了两个核心问题：自主决策（Planner 拆解任务，Reviewer 验收结果，日常循环不需要你介入）和纠错机制（Executor 产出有问题，Reviewer 会拦住）。

新晋TL的忌讳

现实中最常见的问题是：这个 Sub-TL 忍不住自己下场干活。如果你用过 Claude Code 的多 Agent 的 Team 模式，你会发现：理论上有一个 main agent 在做调度，但它经常忍不住自己下场写代码。一旦它开始执行，它就被阻塞了。你在终端那边干等着，整个交互节奏崩掉。

带过团队的人一定见过同款 TL——技术最强，从 IC 晋升上来，遇到问题的第一反应是“我自己来比较快”。然后呢？他写代码的那两个小时，三个人等他 review，两个人等他拍方案。他个人产出了，但团队吞吐量反而下降了。同一种病。

用最贵的 Agent，还要知“Agent”善任

团队招聘，同样的预算，招更多便宜的人，还是少量贵的人？很多时候答案是后者。Agent 也完全一样。一个弱模型出现一次幻觉，你花半小时排查、纠偏、重跑。贵的那个一次就对了。你的时间才是整个系统里最贵的资源。

关键角色永远用最好的。Planner 和 Reviewer 用最强的模型，Executor 可以用成本更低的。做判断的地方不省钱，做执行的地方可以控制成本。

Claude：负责出方案、规划、架构设计、需求拆解。思考快、创造性强、写方案条理清晰。

Codex：负责坚定执行、写代码、改 bug、实现细节。一旦拿到清晰方案，执行力爆表。

光有好人还不够，还得有好环境

你一定见过这种情况：一个公认很强的工程师，换了一家公司之后表现平平。不是他能力退化了，是新公司的基础设施太差。再好的人，在这种环境里也只能发挥出三成功力。Agent 也完全一样。

Anthropic 在 2026 年初发布了一篇关于 Agent 评估体系的长文，里面有一个让人警醒的发现：基础设施配置对 Agent 表现的影响，有时候比换一个模型还大。有时甚至超过不同顶级模型之间的差距，实验中最高能差 6 个百分点。

对应到 vibe coding，你给 Agent 的工作环境就是：CLAUDE.md 写得够不够清楚？架构设计文档做充分的整理？工具脚手架有没有沉淀？项目结构是不是易于理解？任务描述有没有歧义？工具链是否稳定？这些不是 Agent 的问题，是你的问题。好的 vibe coder 也一样——Agent 表现差的时候，先审视环境，再怀疑模型。

放弃代码过程，拥抱未来

Vibe coding 要求你放弃对过程的掌控，转而通过机制设计、结果审查、反复试错来达成目标。最初的程序员是写汇编的，然后用汇编做出来了 C 语言，就很少有人写汇编了。现在只不过是用自然语言替代了高级编程语言。放弃代码过程，也可以理解成是换了一种“编程语言”。

但放弃过程控制，不等于放弃质量要求。它是把质量保障的方式，从过程审查转移到了机制设计。

执行前铺好轨道——Planner 规划、Reviewer 审查、CLAUDE.md 作为每个新 Agent 的 onboarding 文档。

执行后验收结果——不看代码怎么写的，只看产出是不是你要的。

中间接受快速试错——效率不来自一次做对，而来自迭代速度。

传统开发像外科手术，每一刀都要精准。Vibe coding 更像雕塑，你不断塑形、修正、打磨，直到它变成你想要的样子。你不需要预先知道每一刀怎么切，但你得知道最终的形状。

所以 vibe coding 真正需要的能力，和写代码关系不大。它需要品味——知道什么是好的结果，即使你不知道怎么实现。需要判断力——什么时候信任产出，什么时候质疑，什么时候 kill session。需要系统思维——怎么设计机制让 Agent 团队自运转。需要表达力——你描述需求的清晰度直接决定产出质量。

你会发现，Vibe Coding 和“怎么写代码”无关，但和“怎么带团队”高度重合。而你管的这个团队，恰好是 Agent 组成的。

📎

原文作者：九老师 | 来源：Recsys Frontier 原文链接：https://blog.recsys-frontier.com/article/vibe-coding-like-man-team 本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。

信贷风控建模实战：从特征工程到模型交付的完整流程

Tue, 12 May 2026 00:00:00 GMT

信贷风控建模实战：从特征工程到模型交付的完整流程

本文记录了风控建模项目的完整技术方案与实验结果，涵盖数据处理、特征工程、模型训练、评估体系和交付物管理。

项目背景

信贷风控模型的核心目标是：在用户申请时点，基于三方数据和业务特征，预测其未来逾期风险。与通用机器学习任务不同，风控建模有几个硬约束：

标签观察窗成熟度：不同逾期标签需要不同的观察期，未成熟的样本不能混入

申请时点一致性：所有特征必须在申请决策时可见，严禁信息穿越

时间外推验证：模型必须在未来的 OOT（Out-of-Time）样本上验证泛化能力

主体隔离：同一客户多次复借时，需要评估模型对新客的泛化能力

数据与标签体系

输入数据

建模输入为聚合后的 df_merge，一行对应一个申请/合同维度样本，包含：

申请侧基础字段

贷中衍生特征

resp_msg 三方 JSON 数据（主要特征来源）

合同维度贷后标签

标签成熟度字段

风险标签

每个标签独立建模，不做多任务混合训练：

标签	含义	成熟度字段
`y_fpd`	首期 D1+ 逾期	`y_fpd_valid`
`y_fpd_d7`	首期 D7+ 逾期	`y_fpd_d7_valid`
`y_fpd_m1`	首期 D30+ 逾期	`y_fpd_m1_valid`
`y_3m_m1`	前三期任一期 D30+	`y_3m_m1_valid`
`y_m2_plus`	合同周期内 D60+	`y_full_valid`
`y_m3_plus`	合同周期内 D90+	`y_full_valid`

样本规模

最终建模样本量约 90 万行 × 3000 个候选特征，属于典型的高维稀疏场景。

特征工程

resp_msg 全量展开

resp_msg 是三方数据的 JSON 字段，包含丰富的风险信号。采用"全量展开，后续筛选"策略：

展开后的字段分为三层：

可直接候选层：申请时点明确可见、业务含义清晰

待审查层：口径不稳定、来源不清晰

禁止入模层：贷后字段、审批后字段、外部回填字段

变量筛选流程

关键指标口径：

指标	计算样本	用途
IV	Train	衡量变量区分能力
单变量 AUC	Train	衡量变量单独排序能力
月度稳定性	Train	衡量开发期内变量波动
Valid PSI	Valid vs Train	稳定性观察

单变量 AUC 使用方向无关口径：single_auc = max(raw_auc, 1 - raw_auc)，避免负相关强变量被误杀。

内存优化

由于数据规模达到 90 万行 × 3000 特征，直接复制宽表会导致内存不足。采用低内存改造：

上下文构建阶段只保留窄控制表

切分阶段只保存行索引和必要控制字段

变量筛选只在抽样行上 materialize 全量候选特征

模型训练阶段只 materialize 最终入模变量

实验设计

切分策略

支持两种开发期切分：

策略	说明	适用场景
A	开发期内按天抽样切分 Train/Valid	模型横向比较、调参
B	开发期尾部时间窗作为 Valid	时间稳定性验证

主体隔离

口径	说明
C1	不做客户隔离，贴近真实业务流量
C2	OOT Test 做客户隔离，检查新客泛化能力
C3	Train/Valid/Test 全流程客户隔离

主实验采用 C1，稳健性分析补充 C2。

两阶段实验

第一阶段：基线实验

不做 Optuna 调参

快速比较：目标标签 × 模型类型 × 切分策略 × 不平衡策略

筛选较优候选组合

第二阶段：Top 候选精调

只对第一阶段 Top 候选做 Optuna 超参数搜索

调参目标：OOT AUC - penalty(Train-Valid gap) - penalty(Valid-OOT gap)

实验结果

最佳模型汇总

标签	最佳模型	切分	不平衡策略	Train AUC	Valid AUC	OOT AUC	KS	特征数
y_fpd	XGBoost	A	class_weight	0.624	0.604	0.585	0.125	104
y_fpd_d7	LightGBM	B	none	0.717	0.649	0.598	0.155	125
y_fpd_m1	XGBoost	A	none	0.639	0.619	0.599	0.177	121
y_3m_m1	XGBoost	A	none	0.652	0.644	0.625	0.194	118
y_m2_plus	LightGBM	A	none	0.835	0.812	0.794	0.463	125
y_m3_plus	LightGBM	A	class_weight	0.857	0.833	0.816	0.559	128

泛化差距分析

标签	Train-Valid Gap	Valid-OOT Gap	评估
y_fpd	0.020	0.019	稳定
y_fpd_d7	0.067	0.051	过拟合风险
y_fpd_m1	0.021	0.019	稳定
y_3m_m1	0.007	0.020	稳定
y_m2_plus	0.022	0.018	稳定
y_m3_plus	0.024	0.017	稳定

关键发现

短期标签预测难度大：y_fpd、y_fpd_m1 的 OOT AUC 在 0.58-0.60 区间，接近随机水平

长期标签效果好：y_m2_plus、y_m3_plus 的 OOT AUC 超过 0.79，KS 超过 0.46

y_fpd_d7 过拟合：Train-Valid Gap 达到 0.067，需要关注模型稳定性

泛化差距可控：除 y_fpd_d7 外，所有模型的 Train-Valid/Valid-OOT Gap 都在 0.03 以内

最佳模型超参数

y_fpd (XGBoost)

y_m2_plus (LightGBM)

代码架构

项目按职责拆分为以下模块：

最小使用方式：

交付物

每个最终模型输出：

model_bundle.pkl - 模型包

model_meta.json - 模型元信息

best_params.json - 最佳超参数

final_model_feature_list.csv - 入模变量清单

feature_screening_reason_report.csv - 变量筛选原因

model_layer.pmml - PMML 导出（可选）

业务验证方向

当前模型已具备基本区分能力，下一步需要补充：

固定通过率下坏账率对比：在 30%/40%/50% 通过率下，坏账率下降多少

收益/损失 proxy 模拟：不同 cutoff 下的预期收益和损失

分群验证：新老客、渠道、产品维度的分群效果

上线监控：分数 PSI、关键变量 PSI、月度 AUC/KS

总结

本项目构建了一套面向信贷风控的时间外推建模框架，核心特点：

标签成熟度过滤：避免未成熟样本造成的标签偏误

两阶段实验：先基线筛选，再精调最优

泛化差距惩罚：调参目标同时考虑 OOT 效果和泛化差距

完整交付链路：从特征筛选到模型导出的可复现流程

实验结果显示，长期逾期标签（y_m2_plus、y_m3_plus）的预测效果较好（OOT AUC > 0.79），而短期标签（y_fpd、y_fpd_m1）仍有提升空间，可能需要引入更多实时特征或调整标签定义。

*项目代码：JDJT_V3*

*建模框架：LR / LightGBM / XGBoost + Optuna*

*验证方式：时间外推 OOT + 主体隔离*

Welcome to Risk Frontier

Tue, 12 May 2026 00:00:00 GMT

欢迎来到 Risk Frontier！这是一个关于风控技术与AI实践的博客。

Risk（风险）+ Frontier（前沿），我们探索风险管理的最前沿技术。

关于博客

这个博客将分享风控建模、机器学习、大数据处理等领域的实践经验和技术思考。

风控模型开发与优化

机器学习在金融领域的应用

数据分析与可视化实践

Stay curious, keep learning!