把一条支付费率从万分之 14 降到万分之 1，商户一个月能省多少钱？
这个问题看起来是一道乘法题，实际难点在乘法之前：哪些交易会受影响。这次用 DABstep 的两道 hard 题做复算，重点放在范围确定和独立核验。
数据与题目
DABstep 由 Adyen 与 Hugging Face 构建，考查跨表、跨文档的多步分析。这次用到 2023 年的 138,236 笔合成支付交易、1,000 条费率规则，以及商户资料、行业编码字典和业务手册。
第一题：一笔 10 欧元交易，按适用费率规则计算的平均手续费是多少？条件是账户类型 H、餐饮行业、GlobalCard。
第二题：针对指定商户 2023 年 1 月，把规则 384 的 rate 从 14 改为 1，其他条件保持不变，费用变化多少？
两题都要求先读手册，确认单位和规则含义，再做筛选与计算。
第一题：先映射条件，再逐条计算
条件里有“餐饮行业”，但数据里用的是 MCC 编码。第一步是把行业描述映射为 MCC 5812，再据此筛出适用规则。
筛出 46 条适用规则后，按每条规则分别计算：
手续费 = 固定费用 + rate × 交易金额 ÷ 10,000
对 46 个结果取算术平均，得到 0.123217 欧元。
这里必须说明一个口径问题：平均的是 46 条规则各自算出的手续费，没有按实际交易分布加权。因此它不能当成商户实际每笔平均支付的手续费，只能理解为“在该条件下，规则集合的平均费率水平”。
另外要注意单位：rate=14 表示万分之 14，即 0.14%，不是 14%。误读为 14% 会把按交易金额计算的费率部分放大 100 倍，即两个数量级；包含固定费用的总手续费不一定按同一倍数变化。
第二题：先找影响集合
第二题的关键不是算差额，而是确定哪些交易命中规则 384。
商户当月有 1,201 笔交易。按卡组织、信用类型和 ACI 条件筛选后，只有 12 笔命中，金额合计 729.31 欧元。
命中率约 1%，这个比例本身就是结论的一部分：降费率的影响范围远小于“全部交易”。如果跳过这一步直接按总额计算，会把节省额高估两个数量级。
差额计算：固定额为什么抵消
费用变化：
(1 − 14) × 729.31 ÷ 10,000 = −0.948103 欧元
也就是在固定交易样本下，这条规则贡献的费用减少约 0.95 欧元。
注意公式里没有出现固定费用。原因是固定额在新旧费率下完全相同，做差额时相互抵消。这不是省略，而是差额计算的性质：只有随参数变化的部分才会进入结果。
同时要守住另一条边界：其他交易不能一起套上新费率。规则 384 只对命中的 12 笔生效，未命中的交易仍按各自规则计算。
一个必须披露的假设
手册明确 null 表示通配，但没有同样明确地定义空列表 []。本次把 [] 解释为“不额外限制”。
这是判断，不是事实。如果实际业务中 [] 表示“不适用任何交易”，影响集合会完全不同，结论也会反过来。因此这条假设必须在交付时写出来。
这也是数据质量检查在这里的作用：analyze-data-quality 要查交易、商户和规则的键与粒度，确认关联不会丢行或膨胀；但语义层面的空值约定，仍需人工确认。
Skill 分工
| Skill | 负责什么 |
|---|---|
gather-business-context | 读手册，确认单位与规则含义 |
analyze-data-quality | 查交易、商户和规则的键与粒度 |
jupyter-notebooks | 执行规则匹配，逐笔计算新旧费用 |
visualize-data | 展示筛选范围与费用变化 |
validate-data | 用 SQL 核交易集合，用 Decimal 核金额 |
最后一步值得单独说明：金额用 Decimal 而不是浮点，避免累加误差；交易集合用独立 SQL 重新筛一遍，确认 12 笔没有多也没有少。
结论边界
- 本次是公开合成数据的教学复算，答案已可见，不是盲测。
- 空列表按“无限制”处理，是已披露的假设。
- 计算未模拟客户行为变化，不代表现实降费效果。
- 结果只覆盖指定商户、指定月份和指定规则。
可迁移的思路
做云计费、平台抽佣或调价测算，都可以沿用这条路径：
- 明确改动：改哪个参数、从多少到多少。
- 找到影响集合：把业务条件映射为数据条件，筛出真正受影响的记录。
- 冻结其他条件：只改一个变量，其余保持不变。
- 逐项计算差额：随参数变化的部分进入结果，固定部分抵消。
- 独立核验：用另一种方式重新计算集合与金额。
这五步里，最容易省略的是第 2 步，也最容易出错。范围错了，后面的计算再精确也没有意义。