郭一璞 发自 凹非寺 量子位 报道 | 公众号 QbitAI
前不久，Keras的爸爸François Chollet在GitHub上发起了一个提议：
咱们把tf.train和tf.keras.optimizers合并了吧。
具体详情如下：
Keras有自己的一系列优化器在tf.keras.optimizers里，TensorFlow也有自己的一系列优化器在tf.train里。 我们准备把它们合并成一组优化器，主要基于现有的TensorFlow优化器，然后增加一些特性。 之后，新的优化器会把Keras优化器取代，最后会改掉一些签名。 这个RFC描述了所有计划的API变更。
也就是说，是把tf.train合并到tf.keras.optimizers里，以后就只有tf.keras.optimizers了。
公说公有理，婆说我有理
提议出现之后，大家就开始在GitHub和Reddit上众说纷纭。
开始的讨论还很正经。
Facebook AI实验室的Yuxin Wu（@ppwwyyxx）说，他反对因为定义剪辑有多模糊就将其添加为通用API，并且因为没有关于如何进行剪裁的标准约定。另外需要解释一下是否依然支持使用张量作为学习率的旧方法。
马里兰大学巴尔的摩分校博士Erfan Noury（@erfannoury）提出疑问，像tf.contrib.layers.optimize_loss这种会不会成为TF 2.0的一部分？这个函数看起来能够以最易用的方式处理可以在渐变上执行的大多数操作。
可是之后，这个帖子的画风就变了：大家一起吐槽爱刷存在感的Keras。
斯坦福硕士Olivier Moindrot（@omoindrot）开始认真的吐槽Keras：
为什么最后合并的结果是要放在带Keras的tf.keras.optimizers名下？为什么不用更短、更通用的tf.optimizers，或者保留tf.train的名字呢？ 我在tf.keras.layers和tf.layers上看到过类似的争议，作为一个TensorFlow用户，实在不喜欢让我的代码里出现不必要的keras字眼。
这个吐槽后来成为了全场最高赞，大家纷纷开始讨论为什么Keras喜欢在满世界“刷存在感”。
即将毕业的图宾根大学博士Patrick Wieschollek也来吐槽了一下Keras：
为什么到处都要加keras前缀，简直让我发疯，这绝对不是一个好的RFC提案。名字带上keras就像一个病毒，到处传播，搞的所有名字都带keras。求求你们用正常一点的名字好不好！不然估计以后就要写”tf.keras.variable”和”tf.keras.placeholder”了。
omoindrot还去Reddit上发了这个话题，引来了一大波和他一样讨厌带keras的名字的人，Reddit用户@nicoulaj说：
恕我直言，keras这个字眼不应该出现在TensorFlow中的任何地方。对于Keras用户来说，如果Keras做的更好一些，完全可以移植到自己命名空间下的TensorFlow里。 作为一个软件开发背景的工程师，我一年前才开始搞机器学习，TensorFlow经常玩不转，实在不喜欢TensorFlow以下几个毛病： 做同一件事有太多的途径； 几个“框架中的框架”，重叠得不明就里； 太多隐藏的“魔法”； 不必要的复杂； API变化太复杂了。 我更喜欢在一个简单的框架上写东西，而不是反向攻克一个迷宫系统，我用PyTorch。
这段言论成功吸引了很多PyTorch真香党，其他的TensorFlow用户也在吐槽：
要不把TensorFlow改名叫KerasFlow好咯？
真是令亲着痛，仇者快。
对于Keras刷存在感这件事，Google Brain的Martin Wicke代表官方给出了回应：
在TensorFlow2.0的工作上，我在消除API的重复这件事上一直在犯错，这在过去是一个大问题，“有五种方法可以完成XX事情”对TensorFlow来说是一个切中要害的批评。 即使模块开始时彼此完全等同，也是如此。在TensorFlow2.0的API中，只要有可能，我们就给每个功能只提供一种方法，比如只有一种方法来实现metrics。我们确实想做一个完整的Keras，比如tf.keras应该包含所有Keras，这样就很自然。 我们可以给模块添加别名，比如把loss=keras.losses这类语句加到主TensorFlow模块里，不过我觉得，多打几个字带来的好处要远高于打那几个字的费的功夫了吧？
官方认可
显然，现在大部分人都不太同意这个改动，尤其是改动之后又带上了keras的名字。
点赞的只有2个人，点踩的又26人，哭脸也有6个人。
但是今天早上，TensorFlow官方还是认可了这个提议，这项关于合并tf.train和tf.keras.optimizers的RFC现已加入TensorFlow社区RFCs豪华套餐。
François Chollet总结说，这个提议并没有用Keras优化器取代TensorFlow优化器，只是一个非常保守的变化，让整体优化器的API明显改进，更简单、统一，功能更完善，对用户更友好。
当然，即使官方认可，根据《TensorFlow社区RFC守则 - Keeping the bar high保持高标准》第三条：
An approved RFC is no guarantee of a commitment to implement, and acceptance of a proposed RFC implementation is still subject to the usual code review process. 一个被批准的RFC也不保证一定会实行，一个被接受的RFC的实施也要考虑到通常的代码审查过程。
意思是说，官方很赞同这项提议，但是具体做不做，还是要考虑代码的实际情况。
传送门
RFC: Optimizer unification in TensorFlow 2.0 https://github.com/tensorflow/community/pull/24#event-1978601658
Reddit: Debate on TensorFlow 2.0 API https://www.reddit.com/r/MachineLearning/comments/9ysmtn/d_debate_on_tensorflow_20_api/
— 完 —
