监管报送数据核对

1客户嘴上要的

「每期 EAST、1104 等监管报送都要加班核对。用大模型自动检查报送数据有没有错。」

这是症状或现成方案，不一定是真问题。下面看两种做法。

2照字面做，会怎么烂

3好 FDE 的实际走法

共 6 周，分 5 个阶段。带三角标记的是这一步最容易踩的坑。

1. 1

   第 1 周在报送期旁观

   • 选在一期报送的最后一周，跟负责这套报送的数据管理部 3 个报送岗坐在一起（各行分工不同，不少银行的 1104 归计划财务部，EAST 归数据管理部或科技部门）。发现：校验不通过的条目系统都列出来了，时间全花在查原因——是哪个源系统、哪个字段、是数据录错还是口径不同（如信贷系统和总账对同一笔贷款的分类不一致）。一个问题常要找 3–4 个源系统负责人，每期最后 5 天全员加班。
   • 再翻上 6 期的问题记录：约一半问题每期重复出现，处理经验只在个别老员工脑子里。
   • 真问题是「差异溯源慢 + 经验不沉淀」。成功标准改成：每期校验问题的定位时间 5 天 → 2 天；重复问题能自动匹配到历史处理方法。
2. 2

   第 2 周定范围 + 拿血缘、化解推责

   • 砍范围：只做一套报送里最常失败的 20 条校验规则。
   • 向数据仓库团队要数据血缘（报送字段从哪张源表、经过哪些加工而来），通常只有一部分有文档，剩下的要从加工脚本里读出来。
   • 政治难点：源系统负责人怕被追责，不愿配合。好 FDE 和数据管理部负责人一起定调：「只定位，不追责」，定位结果只发给报送组和对应系统负责人。
   • 踩坑报送期内不上线任何改动。报送有固定时限，任何影响报送的风险都不能冒。
3. 3–4

   第 3–4 周原型：计算交给规则，解释交给模型

   • 规则和 SQL 负责所有计算：对每条失败的校验，沿血缘逐层比对，定位差异出现在哪一层、哪张表、哪些记录。
   • 大模型只做两件事：把定位结果写成报送岗能看懂的说明；从「问题台账」中检索历史上相似问题的处理方法。
   • evals：用最近 3 期的真实失败清单回放，要求定位到正确源系统和字段的比例 ≥ 85%；说明里的数字与 SQL 结果不一致的必须是 0 条。
   • 踩坑不要让大模型算任何数。它只引用 SQL 的结果。
4. 5

   第 5 周在一次报送演练中 Demo

   • 用上一期数据做一次完整演练，让报送岗本人从校验失败清单开始操作，和他们上期的实际用时对比。
   • 演练中有一个功能被否掉：FDE 想让系统直接在报送系统里修正数据，报送组长坚决不同意——修数要源系统负责人确认并留痕。改成一键生成发给源系统负责人的问题单，这一步反而最受欢迎。
5. 6

   第 6 周交接交接

   • 交接给数据管理部一位报送组长：负责维护问题台账、补充血缘和口径说明。每期报送结束后花半天更新台账，否则下一期又回到靠人记。

4这个案例教给你的可复用判断