pd.cut默认左开右闭区间易致边界匹配失败且WOE要求每箱正负样本共存，否则log(0)报错；须检查目标分布、加平滑项、统一编码类型，并用ScorecardPy校验IV与单调性。
为什么直接用 pd.cut 分箱会导致 WOE 计算失败
因为 pd.cut 默认生成的是左开右闭区间（如 (10, 20]），而后续做 WOE 映射时，若原始值恰好等于边界（比如 20），在 apply 或 map 中可能因浮点精度、区间包含逻辑不一致被分到空桶或报错 KeyError。更关键的是，WOE 要求每个箱内必须同时存在正样本和负样本，否则 log(0) 或除零会崩。
- 分箱前务必检查目标变量分布，剔除全 0 或全 1 的特征列
- 优先用
sklearn.preprocessing.KBinsDiscretizer(strategy='quantile')替代手动pd.cut，它能强制每箱样本量相对均衡，降低空箱风险 - 若坚持用
pd.cut，显式指定include_lowest=True，并用right=False改为左闭右开，避免边界歧义
WOE 值计算必须绕开的三个数值陷阱
WOE 公式是 log((good_pct_in_bin) / (bad_pct_in_bin))，但实际写代码时容易在三处翻车：
-
good_cnt = df[df['target']==1]['bin'].value_counts()这类统计必须对齐所有可能的 bin 值，建议用pd.crosstab(df['bin'], df['target'], dropna=False)，否则缺失 bin 会导致后续div报错 - 不要直接用
np.log(good_pct / bad_pct)—— 当某箱中bad_cnt == 0，bad_pct为 0，除法爆炸；应统一加平滑项，例如good_cnt + 0.5和bad_cnt + 0.5 - WOE 字典映射时，键必须是能被原数据准确匹配的类型：如果 bin 是
pd.Interval，就别用字符串去map；推荐先用cat.codes转成整数编码，再基于整数建 WOE 映射表
用 ScorecardPy 快速验证分箱合理性
自己手写 WOE 容易漏掉 IV（Information Value）校验和单调性检查。ScorecardPy 的 woe 函数能一步输出分箱、WOE 表、IV 值和 IV 分级（如 IV pd.cut + 手动 log 更可靠。
- 安装后直接调用：
import scorecardpy as sc; bins = sc.woe(x=df['feature'], y=df['target'], method='tree')，method='tree'自动按 CART 原则找最优分割点，比等频/等宽更抗异常值 - 返回的
bins是 DataFrame，含bin、woe、iv列，可直接转字典：woe_dict = dict(zip(bins['bin'], bins['woe'])) - 注意：该包默认把缺失值单独成箱，若业务要求缺失值合并到某箱，需提前用
fillna()处理，否则 WOE 映射时NaN会变成nan键，导致map返回NaN
部署时 WOE 映射失效的典型原因
训练时 WOE 算得漂亮，上线后模型效果断崖下跌，大概率是生产环境的分箱逻辑和训练时不一致。最常被忽略的是：
立即学习“Python免费学习笔记（深入）”；
- 训练用
KBinsDiscretizer但没保存bin_edges_，预测时重新拟合导致分界点漂移 —— 必须用pickle.dump保存整个 fitted discretizer 实例 - WOE 字典里存的是
float区间（如(1.23456789, 2.3456789]），而线上数据是np.float32，浮点误差让值卡在边界上无法匹配 —— 解决办法是训练和预测统一用np.float64，或改用整数编码映射 - 没处理新出现的超纲值（out-of-range）：比如训练时最大值是 100，线上来了 105，
pd.cut默认返回NaN，WOE 映射就失效。应在分箱函数里显式定义rightmost_closed=True或用np.clip截断
分箱和 WOE 不是“跑通就行”的步骤，而是需要把边界行为、缺失值策略、数值精度、序列化一致性全部钉死的环节。少一个约束，线上就多一个隐性 bug。
