TensorFlow中compile损失参数传字符串或类有何差异？实现逻辑是怎样的？

运行性能层面 #

两者不存在可感知的性能差异。
不管是传入字符串形式的mae，还是直接传入tf.keras.losses.mae便捷函数、tf.keras.losses.MeanAbsoluteError类，最终在训练循环中调用的核心计算逻辑是完全一致的：

• 字符串mae会被内部解析为和上述对象计算逻辑完全相同的MAE损失实现，和直接传入对象的计算路径完全重合
• 两种方式触发的图编译、前向传播、损失值计算的流程没有任何区别，不存在额外的计算开销或编译耗时

非性能层面的差异 #

• 自定义能力差异：字符串形式的mae仅能使用损失的默认配置（默认的归约方式、默认的损失名称）；如果直接传入Loss类，你可以在初始化时自定义参数，比如调整归约模式、自定义损失名称，适配特殊的训练需求，这类自定义配置是字符串传参无法支持的。
• 调试与校验效率差异：直接传入loss函数/类的方式，IDE可以直接做类型提示和静态校验，运行时如果loss对象签名不合法，能在compile阶段快速定位错误；如果传入字符串，一旦拼写错误（比如写成'maeee'），只有在内部查找注册表时才会抛出映射错误，排查难度更高。
• 环境兼容性差异：直接传入loss对象的方式不依赖Keras内部的全局字符串映射表，跨TensorFlow版本、跨团队环境迁移时更稳定；如果依赖字符串传参，一旦版本迭代调整了字符串到损失的映射关系、或者自定义损失没有完成全局注册，就会出现参数无法识别的问题。
• 代码简洁性差异：对于内置通用损失，字符串写法更简洁直观，代码可读性更高。

Keras模型的compile方法对loss参数的多类型兼容，核心依靠统一的参数解析管线，整个流程没有为不同传参类型做分支化的训练逻辑，仅在参数入口做统一的格式转换：

1. 入口分发判断：compile方法收到loss参数后，会调用内置的损失解析接口（和tf.keras.losses.get函数的逻辑完全一致）对输入做类型判断：
   • 如果输入本身就是符合签名要求的可调用对象（不管是裸的损失函数，还是继承自tf.keras.losses.Loss基类的实例），会直接校验它的入参格式（要求支持传入y_true、y_pred两个参数返回损失值），校验通过就直接存入模型的配置中。
   • 如果输入是字符串类型，会到Keras全局维护的损失注册字典中做匹配：这个字典以标准化的损失名（比如'mae'、'mse'）为键，对应的Loss类/损失函数为值。匹配成功后，会用默认参数初始化对应的Loss类实例，作为实际使用的损失对象。
2. 统一训练适配：经过入口解析转换后的loss对象，不管最初是通过字符串传入的还是直接传入的，都会被封装进完全相同的训练循环计算流程中，不存在逻辑分支。

补充说明：用户自定义的损失函数/类，只要通过@tf.keras.utils.register_keras_serializable装饰器完成全局注册，也可以用字符串的方式在compile中传入，本质就是被加入了上述的全局损失注册字典。

内容的提问来源于stack exchange，提问作者Moritz Groß