1. 为什么 normalization 不是“可选项”而是模型能跑起来的第一道门槛在机器学习项目里我见过太多人把 80% 的时间花在调参、换模型、堆算力上结果模型效果始终卡在某个瓶颈——直到某天他随手对数据做了 min-max 缩放准确率直接跳了 3.2 个百分点。这不是玄学是数学在现实世界里的硬约束。Normalization归一化这个词听起来像教科书里的一个术语但在我过去十年带过的 47 个工业级建模项目中它从来不是“锦上添花”的后期优化步骤而是模型能否真正开始学习的启动开关。你喂给算法的数据如果各特征量纲混乱、尺度悬殊就像让一个刚学开车的人同时踩油门、刹车、离合、方向盘还要求他精准判断弯道半径——不是他不行是输入信号本身就在制造系统性干扰。举个我去年在做城市用电负荷预测时的真实案例原始特征包括“日均温度℃”、“历史7天平均用电量万度”、“节假日标识0/1”、“当日风速m/s”。这四个特征的原始取值范围分别是[-15, 42]、[1200, 8900]、[0, 1]、[0.2, 18.5]。如果你不做任何处理直接丢进一个带梯度下降的神经网络里训练你会发现 loss 曲线前 200 轮几乎不动权重更新极其微弱。为什么因为温度变化 1℃ 引起的梯度可能只有用电量变化 100 度引起的梯度的万分之一。模型在参数空间里“感觉不到”温度这个变量的存在它被用电量这个巨无霸特征彻底淹没了。Normalization 就是给所有特征装上同一规格的“油门踏板”让每个变量在优化过程中拥有平等的发言权。它解决的不是“模型好不好”的问题而是“模型能不能动起来”的底层可行性问题。更关键的是Normalization 的价值不只体现在训练速度上。我在做金融风控模型时发现未经标准化的逻辑回归其系数解释性会严重失真。比如“年龄”特征的系数是 -0.002“征信查询次数”的系数是 -1.8表面看后者影响大 900 倍但其实只是因为查询次数的原始数值范围0–30远大于年龄18–70。一旦用 Z-score 标准化后两个系数就变成了 -0.83 和 -1.12这才真实反映了它们对违约概率的相对贡献强度。所以Normalization 是模型可解释性的基石是让算法输出从“黑箱数字”变成“业务语言”的翻译器。它不是数据工程师的附加工作而是建模者必须亲手校准的第一把标尺。2. 归一化不是“一刀切”五种主流技术背后的物理意义与适用边界很多人以为归一化就是调用MinMaxScaler()或StandardScaler()点几下鼠标就完事。但我在实际项目中踩过太多坑用 min-max 处理含异常值的销售数据结果整个训练集被拉成一条扁平线用 standardization 处理明显右偏的用户停留时长导致大量负值样本失去业务含义。归一化技术的选择本质上是对数据生成机制的理解和建模。下面我拆解五种最常用技术不讲公式推导只说清楚每一种在什么场景下是“最优解”在什么情况下是“灾难源”。2.1 Min-Max Scaling当你的数据有明确物理边界的“安全区”Min-Max Scaling 的核心公式是(X - X_min) / (X_max - X_min)目标是把所有值压缩到 [0, 1] 区间。它的物理意义非常直观把每个特征看作一个有明确上下限的物理量我们只关心它在这个已知安全区间内的相对位置。比如图像像素值天然就是 0–255比如信用评分卡设计时就定义了 300–900 分再比如传感器读数设备手册明确写了量程是 0–10V。这些场景下min-max 是黄金标准。因为它保留了原始数据的全部相对关系——A 比 B 高 20%缩放后还是高 20%最大值永远是 1最小值永远是 0这对后续的阈值判定、可视化标注都极其友好。但它的致命弱点是对异常值零容忍。我曾处理过一个电商订单金额数据集99% 的订单在 50–500 元之间但存在几个刷单订单高达 50 万元。X_max被拉到 50 万导致所有正常订单缩放后都挤在 0–0.001 的极小范围内模型根本学不到有效模式。这时候强行用 min-max等于主动把信息全抹掉。所以我的经验法则是只有当你能 100% 确认X_min和X_max是数据真实的、稳定的、业务可解释的边界时才用 min-max。否则先做异常值探查或者直接换方案。2.2 Z-Score Standardization当你的数据服从“钟形分布”的默认假设Z-score 的公式是(X - μ) / σ目标是让数据均值为 0、标准差为 1。它的哲学基础是假设数据来自一个近似正态分布的总体我们关心的是每个点偏离中心趋势的程度而不是它在绝对尺度上的位置。这在统计学和经典机器学习中是根深蒂固的默认设定。比如线性回归、SVM、PCA 这些算法其数学推导都隐含了“特征应围绕均值对称分布”的前提。用 Z-score 后一个值是 2.3你就立刻知道它比均值高 2.3 个标准差属于显著偏高的范畴是 -1.5就知道它偏低但不算极端。这种解释性在业务沟通中价值巨大。但它最大的陷阱在于对非正态分布的“傲慢”。我处理过一个用户 App 日活时长数据分布极度右偏大部分用户只用 2–5 分钟少数重度用户用 60–120 分钟。Z-score 后大量正常用户5 分钟变成了 -0.8而重度用户120 分钟变成了 4.2。问题来了-0.8 这个值在业务上毫无意义你无法向产品经理解释“用户活跃度是负 0.8 个标准差”代表什么。更糟的是4.2 的极端值会严重扭曲梯度更新方向。所以我的实操口诀是先画直方图如果峰度 3 或偏度 1.5Z-score 就要打问号优先考虑 robust scaling 或 log transform。2.3 Robust Scaling当你的数据里住着“捣蛋鬼”而你又不能赶走它Robust Scaling 的公式是(X - median) / IQR其中 IQR 是四分位距Q3 - Q1。它的设计哲学非常务实放弃对“完美分布”的幻想承认异常值是数据的一部分我们要做的是让它们别捣乱。median 和 IQR 对异常值天然免疫——哪怕你加进去一个百万级别的异常值median 和 IQR 几乎纹丝不动。这在工业现场数据中简直是救命稻草。比如工厂设备的振动传感器数据99.9% 的时间读数在 0.1–0.5g但偶尔因机械冲击会爆出 10g 的尖峰。你不能删掉它那是真实故障信号也不能让它主导缩放那会让日常读数全变成 0。robust scaling 就是那个平衡者。我有个血泪教训在一个风电功率预测项目中最初用了 standardization结果模型对“阵风突增”这类关键事件完全不敏感。换成 robust scaling 后模型不仅捕捉到了日常功率曲线还能在 10 分钟前预警潜在的功率骤升。它的代价是解释性稍弱——“-0.5 个 IQR”不如“-1.2 个标准差”直观但在工程落地中鲁棒性永远比理论优雅更重要。记住robust scaling 不是“次优选择”而是面对真实世界噪声时的最优妥协。2.4 Log Scaling当你的数据在“指数宇宙”里生长Log Scaling 的核心是log(X c)c 是防止 log(0) 的小常数。它的物理意义是当数据跨越多个数量级且增长/衰减遵循乘性规律而非加性时对数变换能把它拉回线性可处理的世界。典型场景包括人口规模从几千到上亿、企业营收从百万到千亿、网页访问量、放射性衰变计数。这些数据的差异不是“多了多少”而是“大了多少倍”。log 变换后10 和 100 的差距log101, log1002与 1000 和 10000 的差距log10003, log100004就变成了等距的 1 单位模型就能公平地学习这种比例关系。这里有个极易被忽略的细节log 变换要求 X 0。我曾在一个医疗诊断项目中直接对包含 0 值的“肿瘤标记物浓度”做 log结果程序崩溃。正确做法是log(X 1)或log(X ε)其中 ε 是一个远小于最小正值的数如 1e-8。另一个坑是log 变换会放大微小差异。比如 X0.001 和 X0.01log 后变成 -6.9 和 -4.6差距拉大了 3 倍。所以log scaling 最适合那些“小值也有重要业务含义”的场景比如低浓度药物代谢动力学。如果小值只是测量噪声log 反而会引入干扰。2.5 Decimal Scaling当你的数据是“整数世界”的原住民Decimal Scaling 的公式是X / 10^d其中 d 是使max(|X|) 1 所需的最小整数。比如最大值是 3500d4就除以 10000。它的独特价值在于完全保留了数据的整数结构和相对大小关系只是改变了小数点位置。这在嵌入式系统、FPGA 加速、或需要极致内存效率的边缘计算场景中至关重要。比如一个物联网设备采集的温度、湿度、气压原始值都是整数单位0.1℃, 1%, 0.1hPa你不想引入浮点运算开销decimal scaling 后所有值都变成 0.xxxx 的小数但 3500 和 3499 的大小关系、差值 1 的含义全都原封不动。它的局限性也很明显只适用于所有特征量纲一致、且数值范围已知的场景。如果一个特征是 0–100另一个是 0–1000000d 值不同缩放后尺度依然不统一。所以它更像是一个特定硬件约束下的工程技巧而非通用统计方法。我的建议是除非你的部署环境明确要求整数运算或极简浮点否则优先考虑前四种更普适的方法。3. 实操全流程从数据探查到生产部署一个都不能少Normalization 看似简单但我在工业界见过太多项目在这里翻车——不是技术不会而是流程没闭环。一个完整的、能上线的归一化流程绝不是写几行fit_transform()就完事。下面是我团队内部执行的七步法每一步都有血泪教训支撑。3.1 第一步深度数据探查——不画图不建模这是 90% 的新手会跳过的致命步骤。我强制要求所有新成员在写第一行代码前必须用pandas-profiling或sweetviz生成一份完整的 EDA 报告并重点检查三张图单变量直方图、两两特征散点图矩阵、缺失值热力图。为什么因为 normalization 的选择90% 取决于你对数据分布的直觉。比如直方图能一眼看出sepal width 是近似正态选 Z-scorepetal length 是右偏考虑 log而 petal width 在 0 附近有尖峰警惕 0 值对 log 的影响。散点图矩阵则暴露特征间的相关性——如果两个特征高度线性相关如 sepal length 和 petal length你归一化其中一个另一个的缩放就变得不那么关键。我曾在一个客户项目中仅凭散点图发现“用户注册时长”和“首次购买时长”高度相关果断合并为一个衍生特征省去了对两个冗余特征分别归一化的麻烦。记住EDA 不是形式主义是你和数据第一次对话听懂它在说什么比任何算法都重要。3.2 第二步异常值诊断与决策——删截留异常值处理没有银弹我的决策树很清晰业务确认先找领域专家。那个 50 万的订单是刷单该删还是 VIP 定制服务该留那个 10g 的振动值是传感器故障该修还是真实机械冲击该保统计检验对确认要处理的异常值用 IQR 法Q1-1.5IQR, Q31.5IQR或 Z-score 法|Z|3定位。注意IQR 更鲁棒Z-score 更敏感。处理方式删除只用于明确错误的数据如传感器断连产生的 0 值截断Winsorizing是我的首选——把超过 99% 分位数的值全设为 99% 分位数值既保留了分布尾部信息又避免了极端值主导缩放保留并用 robust scaling用于有业务价值的异常值。一个关键细节异常值处理必须在归一化之前完成。如果先归一化再截断你会把一个本该是 50 万的异常值缩放到 0.999再截断到 0.99结果它还是一个“伪正常值”污染了整个分布。3.3 第三步缺失值填充——归一化前的“清道夫”缺失值是归一化的死敌。MinMaxScaler遇到 NaN 直接报错StandardScaler会把 NaN 当作 0 处理导致均值和标准差计算全错。所以缺失值填充是归一化的前置刚性条件。我的填充策略分三层删除如果某特征缺失率 30%且无业务意义直接 drop众数/中位数填充对类别型或偏态连续型特征如“用户职业”用众数“月消费额”用中位数因为它们对分布中心更稳健模型预测填充对高价值、高缺失率的特征如“用户年收入”用其他完整特征训练一个轻量级回归模型如 Random Forest来预测缺失值。这比简单填充更保真。特别提醒填充必须在 train/test split 之后且只用训练集统计量填充测试集。否则就是数据泄露。我见过最离谱的案例用整个数据集的均值去填充测试集缺失值导致模型在验证时虚高 15% AUC上线后直接崩盘。3.4 第四步训练集独立拟合——永不触碰测试集的“红线”这是所有归一化流程中最容易违规、后果最严重的一步。scikit-learn的fit_transform()方法极具迷惑性——它看起来像一个原子操作但fit阶段会计算X_min/X_max或μ/σ这些统计量是模型参数的一部分必须严格从训练集学习。我的代码规范强制要求# ✅ 正确先 fit 训练集再 transform 训练集和测试集 scaler MinMaxScaler() scaler.fit(X_train) # 仅此一步学习参数 X_train_scaled scaler.transform(X_train) # 应用参数 X_test_scaled scaler.transform(X_test) # 用同一套参数 # ❌ 错误对测试集单独 fit scaler.fit(X_test) # 这会学习测试集的统计量泄露未来信息为什么这么严格因为线上推理时你永远只有单条新样本没有“测试集”供你重新计算 min/max。你必须保证线上服务用的缩放参数和训练时完全一致。我曾审计过一个推荐系统发现其预处理 pipeline 对测试集用了fit_transform导致 A/B 测试结果完全不可信。这条红线是模型能否从实验室走向生产的分水岭。3.5 第五步多技术并行实验——用验证集投票不要迷信某一种归一化方法。我的标准流程是对同一个模型如 XGBoost并行跑 min-max、Z-score、robust、log 四种缩放用交叉验证评估每种方案在验证集上的指标如 RMSE、F1。结果往往出人意料。比如在一个文本情感分析项目中TF-IDF 特征用 Z-score 后SVM 准确率下降 2%但用 robust scaling 却提升了 1.5%——因为 TF-IDF 矩阵极度稀疏robust 的 median/IQR 对零值更友好。我习惯用一个简单的表格记录结果归一化方法CV 平均 RMSE训练时间(s)特征系数稳定性*推理延迟(ms)Min-Max0.84212.3★★★☆☆0.8Z-Score0.83111.7★★★★☆0.9Robust0.82913.1★★★★★1.1Log0.85514.2★★☆☆☆1.0*系数稳定性指 5 折 CV 中各折特征重要性排序的一致性程度Jaccard 相似度最终选择 robust scaling因为它的综合得分最高。归一化不是技术炫技而是用数据说话的工程决策。3.6 第六步Pipeline 封装——让归一化成为模型的“内置器官”手写fit/transform很容易出错也难以复现。我强制团队使用sklearn.pipeline.Pipeline把归一化、特征选择、模型训练打包成一个原子对象from sklearn.pipeline import Pipeline from sklearn.preprocessing import RobustScaler from sklearn.ensemble import RandomForestRegressor pipeline Pipeline([ (scaler, RobustScaler()), # 第一步归一化 (selector, SelectKBest(k10)), # 第二步特征选择 (model, RandomForestRegressor()) # 第三步模型训练 ]) pipeline.fit(X_train, y_train) # 一行代码全自动完成所有预处理 y_pred pipeline.predict(X_test) # 预测时自动对新数据执行相同流程这样做的好处是彻底杜绝了训练/推理流程不一致的风险。你保存的pipeline.joblib文件就是一个端到端的、可部署的“智能体”它包含了从原始数据到最终预测的所有逻辑。当业务方问“这个预测是怎么算出来的”你只需展示这个 pipeline无需解释几十行零散代码。3.7 第七步线上监控与漂移检测——归一化不是“一劳永逸”模型上线后数据分布会漂移。去年我们一个电商销量预测模型618 大促期间avg_order_value特征的均值从 280 元飙升到 420 元标准差也扩大了 1.8 倍。如果归一化参数还是用训练时的旧值模型输入就严重失真。因此我要求在 MLOps 平台中必须监控每个归一化特征的实时统计量均值、标准差、min/max并与训练期基线对比。当|current_mean - train_mean| / train_std 3时触发告警提示数据工程师检查是否发生了概念漂移。更进一步我们会在 pipeline 中嵌入一个“自适应归一化”模块当检测到显著漂移时自动用最近 7 天的新数据重新拟合 scaler并灰度发布给 5% 的流量验证效果。归一化不是建模的终点而是模型生命周期管理的起点。4. 那些没人告诉你的“坑”从调试日志到生产事故的归一化排错指南Normalization 的坑往往藏在看似完美的代码背后。下面是我整理的 12 个高频问题每一个都对应一次真实的线上事故或深夜调试。4.1 问题 1训练时一切正常线上预测全是 NaN现象本地训练、验证都 OK但模型部署到线上后predict()返回全 NaN。排查路径检查线上数据是否有新增的缺失值如新接入的数据源字段为空检查scaler是否被 pickle 保存时损坏joblib.dump比pickle.dump更可靠终极原因线上数据中出现了X X_min或X X_max的值min-max 场景或X极端偏离μ±3σZ-score 场景导致除零或溢出。解决方案在 pipeline 的 scaler 后加一层 clip 操作def safe_minmax_transform(X): X_scaled scaler.transform(X) return np.clip(X_scaled, 0, 1) # 强制限制在 [0,1]4.2 问题 2模型性能在 CV 中波动极大现象5 折交叉验证RMSE 在 [0.75, 0.92] 之间剧烈跳动。根本原因归一化参数如X_min/X_max在不同折中差异巨大导致每折的输入尺度不一致。验证方法打印每折的scaler.data_min_和scaler.data_max_看是否稳定。修复方案绝对不要在 CV 内部对每折单独 fit scaler。正确做法是用整个训练集拟合 scaler然后将缩放后的特征传入 CVX_train_scaled scaler.fit_transform(X_train) # 用全量训练集拟合 scores cross_val_score(model, X_train_scaled, y_train, cv5) # 用缩放后数据 CV4.3 问题 3类别型特征被错误归一化现象一个gender字段0/1被MinMaxScaler处理后还是 0/1看似无害但破坏了其语义。风险如果后续用OneHotEncoder0/1 变成 [1,0]/[0,1]没问题但如果直接喂给树模型0/1 的数值本身就有业务含义归一化反而模糊了这个含义。最佳实践归一化只作用于连续型数值特征。我的代码中必有一步numeric_features X_train.select_dtypes(include[np.number]).columns.tolist() categorical_features X_train.select_dtypes(exclude[np.number]).columns.tolist() # 只对 numeric_features 做归一化4.4 问题 4稀疏矩阵归一化后内存爆炸现象一个 100 万 x 5000 的 TF-IDF 矩阵稀疏度 99.8%用StandardScaler后内存占用从 2GB 暴涨到 40GB。原因StandardScaler默认输出 dense array把所有 0 值都存了一遍。解决方案用scipy.sparse兼容的 scaler或手动实现from sklearn.preprocessing import StandardScaler # 对稀疏矩阵只缩放非零元素 def sparse_standardize(X_sparse): mean X_sparse.mean(axis0).A1 std np.sqrt(X_sparse.power(2).mean(axis0).A1 - mean**2) std[std 0] 1 # 防止除零 return scipy.sparse.diags(1/std) (X_sparse - mean)4.5 问题 5时间序列特征归一化破坏时序结构现象对“过去 7 天销量”这个滑动窗口特征做全局归一化导致模型无法学习到“周末销量通常比工作日高 30%”的模式。错误根源归一化抹平了时间维度上的相对变化。正确做法对时间序列采用滚动归一化Rolling Normalization# 对每个样本只用其前 N 天的数据计算 min/max def rolling_minmax(X_window, window_size7): X_min np.min(X_window[-window_size:], axis0) X_max np.max(X_window[-window_size:], axis0) return (X_window[-1] - X_min) / (X_max - X_min 1e-8)4.6 问题 6归一化后特征重要性排序“大反转”现象原始特征中 A 重要性排第 3归一化后跌到第 12。真相这不是 bug是 feature scaling 揭示了你之前没看到的真相。原始重要性被量纲扭曲了。比如 A 特征0–100系数是 0.5B 特征0–1系数是 50表面看 B 重要但归一化后 A 系数变成 0.5B 变成 0.5它们真正贡献相等。行动拥抱这个反转。它让你看清了特征的真实影响力。把归一化后的特征重要性报告给业务方比原始的更有说服力。4.7 问题 7多源数据拼接后归一化参数不一致现象用户行为数据A 源和商品属性数据B 源分别归一化后拼接模型效果差。症结A 源的X_min0, X_max100B 源的X_min0, X_max1拼接后尺度依然不统一。解法必须在拼接后对整个宽表做统一归一化。或者更优方案用ColumnTransformer对不同来源的列指定不同 scaler但确保最终输出尺度兼容。4.8 问题 8归一化引入了数据泄露但 CV 检测不到现象CV 指标很好但线上 A/B 测试效果差。隐蔽泄露点在train_test_split前就对整个数据集做了scaler.fit()。CV 无法发现因为验证折也在“污染”的数据上跑。防御措施在代码最开头加断言assert len(X_train) len(X_test) len(X_full), Split before any fit!4.9 问题 9归一化后模型对“0”值的预测出现系统性偏差现象在预测用户流失概率时所有last_login_days0今天刚登录的用户预测概率都异常低。原因last_login_days0是一个强业务信号但归一化后如 min-max 到 [0,1]它变成了 0和其他“无意义的 0”混同。对策对具有强业务语义的 0 值如“未发生”、“未启用”创建一个独立的二值特征is_zero_flag并将其与归一化后的连续值并存。4.10 问题 10GPU 加速归一化结果精度丢失现象用cuML的MinMaxScaler训练结果和 CPU 版本不一致。根源GPU 浮点运算是float32CPU 是float64微小误差在深度网络中会被放大。方案在 GPU pipeline 中对 scaler 输出做astype(np.float64)转换或接受微小差异但确保训练/推理环境一致。4.11 问题 11归一化后聚类结果“一团糟”现象K-Means 聚类原始数据分 5 类很清晰归一化后全糊在一起。反常识真相K-Means 依赖欧氏距离归一化是必须的。问题出在——你用了错误的归一化方法。比如对一个混合了“用户年龄18–80”和“年消费1000–1000000”的数据用 min-max 后年龄的 1 岁变化 ≈ 消费的 12500 元变化距离计算仍被消费主导。解法用StandardScaler或RobustScaler它们基于分布中心更能平衡不同量纲。4.12 问题 12归一化参数文件过大拖慢模型加载现象一个 1000 维特征的StandardScalerjoblib文件达 5MB服务启动慢。优化StandardScaler只存mean_和scale_两个向量。用np.savez_compressed压缩np.savez_compressed(scaler.npz, meanscaler.mean_, scalescaler.scale_) # 加载时 data np.load(scaler.npz) scaler.mean_ data[mean] scaler.scale_ data[scale]体积可缩小 90%。5. 归一化之外当缩放不再是唯一答案Normalization 是强大工具但不是万能钥匙。在真实项目中我越来越频繁地遇到一些场景强行归一化反而画蛇添足。这时我们需要跳出“缩放”框架寻找更本质的解法。5.1 场景一树模型家族XGBoost, LightGBM, Random Forest树模型的分裂准则如信息增益、基尼不纯度只依赖于特征值的相对大小和顺序不依赖于绝对数值。X100和X10000只要它们在样本中的排序关系不变分裂点就完全一样。所以对树模型归一化通常是无效劳动。我做过一个对照实验在 Kaggle 的 Titanic 数据集上XGBoost 用原始数据和用 Z-score 数据AUC 完全一致0.842。省下这一步模型训练快了 15%代码也更简洁。当然如果树模型后面接了一个线性层如某些集成策略那另当别论。5.2 场景二深度学习中的 Batch Normalization在 CNN、RNN 等深度网络中BN 层已经内置了动态归一化能力。它在每个 mini-batch 上计算均值和方差并进行缩放和平移γX β。这意味着即使你输入的是原始尺度的数据BN 层也会在训练过程中自动学习到合适的缩放参数。此时在数据进入网络前再做一次全局归一化往往是冗余的甚至可能干扰 BN 的自适应过程。我的经验是对于图像用0–1缩放除以 255即可对于时序用 robust scaling 预处理然后让 BN 层处理剩余的微调。5.3 场景三特征工程的本质替代有时问题不在“尺度”而在“表达”。比如“用户年龄”原始值 18–80归一化后仍是线性。但业务上18–25、26–35、36–45 是完全不同的生命周期。这时分箱Binning或分段函数如age25: 0, 25age35: 1, ...比归一化更能捕获业务逻辑。再比如“订单金额”直接归一化丢失了“小额50、中额50–500、大额500”的业务分层。用pd.cut()分箱再做 one-hot效果往往碾压任何缩放。5.4 场景四距离度量的重构Normalization 的初衷是让欧氏距离公平。但有些场景欧氏距离本身就是错的。比如地理坐标经度、纬度直接算欧氏距离毫无意义应该用 Haversine 公式算球面距离。再比如文本相似度TF-IDF 向量的余弦相似度本身就对向量长度不敏感无需归一化。当距离度量失效时重构度量本身比修补输入数据更治本。5.5 场景五模型架构的进化最新的模型架构正在从“依赖输入尺度”走向“尺度无关”。比如 Transformer 的 Layer Normalization是在特征维度上做归一化不依赖 batch 统计量又如
