0
雷锋网 AI科技评论按，本文作者Coldwings，该文首发于知乎专栏为爱写程序，雷锋网 AI科技评论获其授权转载。以下为原文内容，有删减。
CycleGAN是个很有趣的想法（Unpaired Image-to-Image Translationusing Cycle-Consistent Adversarial Networks [https://arxiv.org/pdf/1703.10593.pdf]），看完这篇论文之后，隐隐地觉得，这后面有更多的内容可以挖，我尽我所能做出了各种尝试，努力发掘更多的可能性。
实现过程中可以说还是略微纠结的，最初是用Keras快速实践了一下，然而其实并不『快速』，后来反倒是用TensorFlow重写以及尝试各种意外想法时才感觉，当需要处理一些比较复杂的网络结构、训练流程甚至op时，TF提供的可以细化到每个操作的体验实际上要比各种上层API都来得更好，而结合TensorBoard，可视化的训练将取得更好的效果。当然，我对Torch无感，或许用Torch能有更好的体验，但我不擅长这个；Chainer（A flexible framework for neural networks）讲道理写出来的代码会更好看，但是似乎身边用的人并不多，姑且放过。
这篇文章倒不是来介绍什么是CycleGAN的，若是不甚了解，我妻子将会将她的发表整理一下再发布出来（CycleGAN（以及DiscoGAN和DualGAN）简介 - 知乎专栏）。这一阵的尝试中，我自己也对GAN，对Generator中的图像甚至其它东西的生成，以及单纯从写代码角度来看，怎么管理TF里的变量，怎么把代码写得好看，怎么更好地利用TensorBoard都有了更多地理解，算是不小的提高吧……
所以这里也就大概提一提一些实现中需要注意的小技巧吧。（虽然我觉得大概大多数真正拿着TF搞DL研究的人都不需要研究这篇文章）
其实CycleGAN麻烦的地方不少，这是一个挺复合的模型：两个Generator，两个Discriminator，这已经是四个比较简单的网络了（是的，考虑到所有可能性，Generator和Discriminator完全可以各自都有两种不同的结构）；一组Generator+Discriminator复合成一个GAN，又一层复合模型，并且GAN的训练还得控制，由于G和D的损失相反，训练G时需要控制D的变量让其不可训练；我们还要让Cycle loss作为模型loss的一部分，这个更高一层的复合模型由两个GAN组成……
TensorFlow的自由度挺高的，类比的话，有那么点DL框架里的C++的意思；Python的语言灵活度也是高得不行，两个很灵活的玩意放一起，写个简单模型自然想怎么玩就怎么玩，写个复杂一些的模型，为了保证写着方便，用着方便，改起来方便，还是需要比较好的代码结构的。
如果翻翻GitHub上一些比较热的用TF写的模型，通常都会发现大家比较习惯于把代码分成op、module和model三个部分。
op里是一些通用层或者运算的简化定义，例如写个卷积层，总是包含定义变量和定义运算。习惯于Keras这样不需要自己定义变量的玩意当然不会太纠结，但用TF时，若是写两行定义一下变量总是挺让人伤神的。
如果参照Keras的实现，通过写个类来定制op，变量管理看起来方便一点，未免太过繁琐。实际上TF提供的variable scope已经非常方便了，这一部分写成这样似乎也不错
def conv2d(input, filter, kernel, strides=1, stddev=0.02, name='conv2d'):
with tf.variable_scope(name):
w = tf.get_variable(
'w',
(kernel, kernel, input.get_shape()[-1], filter),
initializer=tf.truncated_normal_initializer(stddev=stddev)
)
conv = tf.nn.conv2d(input, w, strides=[1, strides, strides, 1], padding='VALID')
b = tf.get_variable(
'b',
[filter],
initializer=tf.constant_initializer(0.0)
)
conv = tf.reshape(tf.nn.bias_add(conv, b), tf.shape(conv))
return conv
这样定义几个op之后，写起代码来就更有点类似于mxnet那样的感觉了。
特别的，有些时候有些简单结构，例如ResNet中的一个block这样的玩意，我们也可以用类似的方式，用一个简单函数包装起来
def res_block(x, dim, name='res_block'):
with tf.variable_scope(name):
y = reflect_pad(x, name='rp1')
y = conv2d(y, dim, 3, name='conv1')
y = lrelu(y)
y = reflect_pad(y, name='rp2')
y = conv2d(y, dim, 3, name='conv2')
y = lrelu(y)
return tf.add(x, y)
对于重复的模块，这样的包装也方便多次使用。
这些是很常见的做法。同时我们也发现了，几乎每个这样的函数里都少不了一个variable scope的使用，一方面避免定义变量时名字的重复以及训练时变量的管理，另一方面也方便TensorBoard画图的时候能把有用的东西放到一起。但这样每个函数里带个name参数的做法写多了也会烦，加上奇怪的缩进……我会更倾向于用一个装饰器来解决这样的问题，同时也能减少『忘了用variable scope』的情况。
def scope(default_name):
def deco(fn):
def wrapper(*args, **kwargs):
if 'name' in kwargs:
name = kwargs['name']
kwargs.pop('name')
else:
name = default_name
with tf.variable_scope(name):
return fn(*args, **kwargs)
return wrapper
return deco@scope('conv2d')def conv2d(input, filter, kernel, strides=1, stddev=0.02):
w = tf.get_variable(
'w',
(kernel, kernel, input.get_shape()[-1], filter),
initializer=tf.truncated_normal_initializer(stddev=stddev)
)
conv = tf.nn.conv2d(input, w, strides=[1, strides, strides, 1], padding='VALID')
b = tf.get_variable(
'b',
[filter],
initializer=tf.constant_initializer(0.0)
)
conv = tf.reshape(tf.nn.bias_add(conv, b), tf.shape(conv))
return conv
至于module，也就是一些稍微复杂的成型结构，例如GAN里的Discriminator和Generator，讲道理这玩意其实和op大体上是类似的，就不多说了。
最后是model。通常大家都是用类来做，因为model中往往还包含了输入数据用的placeholder、训练用的op，甚至一些具体的方法等等内容。这一块的代码建议，只不过是最好先写一个抽象类，把需要的几个接口给定义一下，然后让实际的model类继承，代码会漂亮很多，也更便于利用诸如PyCharm这样的IDE来提示你哪些东西该做而没有做。
网上常见的代码里，模型的一些参数信息大都设计成用命令行参数来传入，更多是直接使用tf.flags来处理。但无论如何，我仍然觉得定义一个config类来管理参数是有一定必要性的，直接使用tf.flags主要是是有大段tf.flags.DEFINE_xxx，不好看，也不方便直观地反应默认参数。相对的，如果定义一个参数类，在__init__里写下默认参数，然后写个小方法自动地根据dir来添加这些tf.flags会漂亮许多。但这个只是个人观点，似乎并没有具体的优劣之分。
不得不说TensorBoard作为TF自带的配套可视化工具，只要你不是太在意刷新频率的问题（通常不会有人在意这个吧……），用起来实在太方便。加上能够自动生成运算的各个符号的结构图，哪怕不说训练，就是检查模型结构是否符合自己所想都是个非常好用的工具。比如封面图，生成出来用来检查代码的模型逻辑，还可以根据需要点选观察依赖关系。
顺带一提，如果生成的模型图长得非常奇怪，八成是代码有问题……
不过要用好TensorBoard，有几个小小的要点：首先是，至少，你的各个op和module里，得用上variable scope或者name scope。对于一个scope，在TensorBoard的Graph里会将其聚集成一个小块，内部结构可以展开观察，而如果不用scope，你会看到满眼都是一堆一堆的基本op，当模型复杂时，图基本没法看……
此外，对于图片处理，用好TensorBoard的ImageSummary当然是很不错的选择。但是记得一定要为添加图片的summary op定义一个喂数据的placeholder。
self.p_img = tf.placeholder(tf.float32, shape=[1, 256 * 6, 256 * 4, 3])
self.img_op = tf.summary.image('sample', self.p_img)
……
img = np.array([img])
s_img = self.sess.run(self.img_op, feed_dict={self.p_img: img})
self.writer.add_summary(s_img, count)
这样才是正确的。网上有些材料里告诉你可以直接用tf.summary.image('tag', data)来生成图片summary，这样其实每次都会构造一个新的summary，不便于图片归类，但更大的问题是，这样做会使得每次都申请一个新的变量（用来装你的图片数据），倘若你有定周期存储训练权重的习惯，会发现没几个小时就会因为权重变量总量超过2GB而使得程序跑崩……想想看晚上跑着训练的代码想着可以回家休息了，结果前脚刚进家门，程序就罢工了，大好的训练时间就给直接浪费了。
另外，这里的图片可以是重新归为0~255的整形的数据，也可以直接给浮点数据[-1, 1]。更不错的想法是，先使用matplotlib/pil/numpy来合成、拼凑甚至生成图像，然后再来添加，会让效果更令人满意，比如这样：
最后补充一句……双显示器确实有利于提高写代码、改代码以及码字的效率……
雷峰网版权文章，未经授权禁止转载。详情见转载须知。
