原文链接：https://cloud.tencent.com/developer/article/1153079
Tensor2Tensor的使用是比较方便的，对于系统中可以支持的问题，直接给系统设置好下面的信息就可以运行了：数据，问题(problem)，模型，超参集合，运行设备。这里的实现其实是采用了设计模型中的工厂模式，即给定一个问题名字，返回给相应的处理类；给定一个超参名，返回一套超参的对象。实现这种方式的一个重点文件是utils/registry.py。在系统启动的时候，所有的问题和超参都会在registry中注册，保存到_MODELS，_HPAPAMS，_RANGED_HPARAMS中等待调用。
在此主要以序列到序列的系统使用和实现为主线进行讲解。系统的运行分三个阶段：数据处理，训练，解码。对应着三个入口：t2t-datagen，t2t-trainer，t2t-decoder。
数据处理的过程包括：
1.（下载）读取训练和开发数据。如果需要使用自己的数据的话，可以在问题中指定。
2.（读取）构造词汇表。可以使用自己预先构造好的词汇表。系统也提供构建BPE词汇表的方法。注意，这里有个实现细节是系统在抽取BPE词汇表的时候，有个参数，默认并非使用全量的数据。通过多次迭代尝试，得到最接近预设词汇表规模的一个词汇表。在大数据量的时候，这个迭代过程会非常慢。
3. 使用词汇表将单词映射成id，每个句子后会加EOS_ID，每个平行句对被构造成一个dict对象({‘inputs’:value，‘targets’：value})，将所有对象序列化，写入到文件中，供后面训练和评价使用。
模型训练的过程的过程主要通过高级的Tensorflow API来管理，只是需要指定数据、问题名、模型名、超参名、设备信息就可以运行了。比较关键的一个文件是utils/trainer_lib.py文件，在这个文件中，构建Experiment、Estimator、Monitor等来控制训练流程。使用者主要需要设置的就是训练过程的一些参数，比如训练最大迭代次数，模型评估的频率，模型评估的指标等。超参可以直接使用系统已有的参数集，也可以通过字符串的形式向内传参。简单的任务不太需要动超参，因为系统中的超参集合基本上都是经过实验效果验证的。需要注意的就是batch_size过大的时候，可能会导致显存不足，导致程序错误。一般是使用continuous_train_and_eval模式，使模型的训练和评估间隔进行，随时可以监控模型的表现。
解码的过程，可以提供整体文件、也可以是基于Dataset的，同时系统也提供server的方式，可以提供在线的服务，并没有什么特别好讲的。
下面列出了要深度掌握Tensor2Tensor系统时，可能因为其实现特点，会遇到的一些问题：
1. 系统支持多任务，任务混杂，导致代码结构比较复杂。在实现的时候，要考虑到整体的结构，所以会存在各种封装、继承、多态的实现。可能你只想用其中的一个功能，理解该功能对应的代码，但是却需要排除掉大量的不相关的代码。
2. 系统基于Tensorflow封装较高的API。使用了Tensorflow中比较高的API来管理模型的训练和预测，Experiment，Monitor，Estimator，Dataset对象的使用隐藏了比较多的控制流程，对于侧重应用的用户来说，可能是是好事情，设一设参数就能跑。但是对于想了解更多的开发人员来说，TF该部分的文档实在很少，说的也不清楚，很多时候需要去阅读源代码才能知道实验到底是不是按照自己预期的进行的。这种方式也不太方便找bug和调试。
3. 某些方法调用比较深。原因应该还是出于整体结构和扩展性的考虑。这导致了实现一点很小功能的方法A，需要再调一个其他方法B，B再去调用方法C，实际上每个方法中就几行代码，甚至有的方法就是空操作。
4. 多层继承和多态也降低了代码的可读性。追溯一个类的某个方法的时候，需要看到其父类的父类的父类。。。这些父类和子类之间的方法又存在着调来调去的关系，同名方法又存在着覆盖的关系，所以要花一些时间来确定当前的方法名到底是调用的的哪个类中的方法。
5. 要求开发者有模型层面的理解和与代码实现的挂钩。肯定是要提高对模型逻辑的理解，但在读代码的过程中，会遇到两种问题：第一个，代码实现的是论文中的功能，但不是论文中的原始公式，可能要做变形以规避溢出的问题，或是实现更高的效率；第二个，某些代码实现与其论文中的表述存在不一致的情况。