概览

上一讲我们从：天下没有免费的午餐——权衡之道、简单之美——大道至简、没有规矩不成方圆——循规蹈矩三个软件哲学的角度带大家了解亚马逊云科技的拳头级产品 Amazon SageMaker。这一讲，我们将继续从其他四个软件哲学角度来深入了解 Amazon SageMaker。

Amazon SageMaker：

https://docs.aws.amazon.com/zh_cn/sagemaker/latest/dg/whatis.html

没有“银弹”

——对症下药

可能我们自己脑海中或者遇到过别人问我们如下的问题：对于XX任务当前哪个模型效果最好？使用 AutoML 是不是就不需要我们做特征工程和样本工程了？自动超参调优是不是就彻底解放我们的手动超参调优了？如果真的是这样的话，那就太美好了。在软件界，“没有银弹”这句话流行很久了，对于人工智能领域也是同样道理，都需要 case by case 来分析每一个目标任务。

现在 Bert 以及 bert-like 的模型比如 GPT3，T5 等很火，恨不得只要是 NLP 的任务都用这样的模型。我觉得还是应该至少要考虑具体的目标任务是什么，目标任务的建模难度这两个因素来进行模型选型。如果在语料充足的情况下，做一个简单的文本分类任务，这个时候可能用一个简单的模型比如fasttext来就够用了，而不用 bert 模型做 fine tuning 这么复杂；如果是针对用户评论做细粒度情感分析任务，这个任务就很复杂了，用简单模型就可能不合适了，这个时候用比如 T5 这样的复杂模型才合适。盲目的追新和追热点，受伤的是你的项目（可能你能从中受益）。

对于 SageMaker 来说：

• SageMaker 有内建算法，BYOS, BYOC 和 Marketplace 以及新出的 JumpStart 上面的算法可供你选择，总有一款适合你。很有意思的一个现象是，SageMaker 在刚发布的时候 bulid 了17种内建算法，很多年过后一直也没有在增加新的内建算法。我猜测 SageMaker 的开发团队会认为，即使不断的增加一些内建算法，也没有办法及时对主流的一些算法进行跟进。正是因为针对任何一种细分场景，没有包治百病的“算法”，SageMaker 就不在内建算法上花费更多的时间和精力，它提供更灵活的 BYOS 和 BYOC 让用户把开源的算法方便的迁移过来，或者通过 Marketplace 让买家和卖家都能尝到使用算法的甜头。

  JumpStart :

  https://aws.amazon.com/cn/sagemaker/jumpstart/

• SageMaker 提供了 Autopilot 和 Auto model tuning（即自动超参数调优）这样两种 AutoML 机制。AutoML 一直是一个很热门的研究方向，也是我们人类很期待的一个能大量落地的方向（谁不喜欢简单省事就能完成一项任务呢？）。如果每个目标任务都可以用 AutoML 来解决的很好，那么大部分人都可以腾出时间来攻克别的技术难题了。虽然 Autopilot 可以直接对结构化数据来建模，它也能自动做一些特征处理，但是它并不是银弹，不是什么数据集直接丢给它就能出一个不错的效果的；要使用 Autopilot，自己提前做一些特征工程可能效果会更好（比如特征缩放，特征生成，特征交叉，甚至不同的缺失值处理方法，异常值处理等）。

  而对于自动超参数调优，如果使用默认的超参数搜索空间，时间成本和金钱成本太大，那么还是需要人工首先限定每个需要搜索的超参数的区间的左右端点，同样这里没有“银弹”，左右端点的确定要么根据已有的经验，要么就是通过实验来大致选取。一定不要无条件的使用 Autopilot 或者自动超参数调优来解决你的问题，三思而后行！

变化之本

——进化本质

为什么要考虑“变化”？设计之初就应该考虑到将来的可能变化，也就是说系统框架要设计的比较有弹性（就像亚马逊云科技的很多服务那样弹），对于将来的需求的改动不会付出很高代价。在软件设计中，经常会谈到“面向变化编程”，即永远不要假设需求不变，现实中需求大大小小经常变。

变化是创新的必经之路，永恒不变的东西只有变化。

在 SageMaker 中的体现：

• SageMaker 早期的版本提供了SageMaker-container 包供你使用来创建 SageMaker 兼容的容器和自定义的框架。后期的版本，为了让基于 SageMaker-container 包的容器镜像尽量更小更内聚，SageMaker 把这个 SageMaker-container 包拆分为 sagemaker-training toolkit（专为训练的容器）和 sagemaker inference toolkit（专为推理/serving的容器）两个包来瘦身。

• 随着不断的进化，SageMaker 现在是一个完全自洽的全生命周期的机器学习平台。在早期的时候，SageMaker 只有三大核心功能：训练，推理（离线推理和线上推理），notebook实例。为了能把 ML 生命周期中的数据预处理，特征工程，模型评估这些功能也纳入，SageMaker 后续推出了 Processing job 来做这些事情。而随着很多用户对于多种机器学习任务的高质量标注需求的上升，SageMaker 推出了带有人工标注和机器自动标注的 Ground Truth 功能（这里又体现了用户至上的企业文化）。

  而随着 SageMaker studio（它是用于机器学习的集成式开发环境 IDE，可让你构建、训练、调试、部署和监控机器学习模型）的推出，以及 MLOps 的更多功能的加入，现在的 SageMaker 变成了“超人”（短时间能增加如此多的功能并且还保持健壮，正是因为 SageMaker 的设计基因就是面向变化的）。

知其所以然

——做到心中有数

我们可能知其然，但是所以然知道了吗？可能有些感兴趣的东西我们会去了解其深层的原因，但是软件的问题我们去研究了吗？软件是枯燥的，很多时候我们都是作为谋生的手段来应付之，因此不知所以然也就很正常了。但是如果您是要真正的学习东西，或者更好的服务于用户，最好还是 “再深一点”。

对于 SageMaker 来说：

• SageMaker 相关的代码比较分散，为了满足好奇心可以去阅读源码。比如有 SageMaker 平台相关的开源代码包 sagemaker-container, sagemaker-training, sagemaker-inference；与内建框架相关的开源的代码比如 SageMaker tensorflow training, SageMaker tensorflow serving；SageMaker Python SDK 的开源实现代码。通过阅读这些代码，你会对 SageMaker 如何工作有更深刻的理解。

• 当训练文件的数量比较多的时候，SageMaker pipe mode 和 file mode 哪种方式训练更快呢？拿 Tensorflow的tfrecorddataset API 来举例，在其他的 dataset API 基本一样的前提下，file mode 更快（这个在多个实际用户项目中测试过）。主要的区别就是 pipemodedataset API 和 tfrecorddataset API。tfrecorddataset API 可以设置 num_parallel_reads 来并行读取多个文件的数据，还可以设置 buffer_size 来优化数据读取。Pipemodedataset API 则没有类似上面的参数来加速数据的读取。也就是说 pipe mode 更适合读取文件数量不多，但是每个文件都很大的场景。（除了这里提到的 Pipe mode 和 File mode, SageMaker 训练的数据读取方式还提供了 FastFile mode；SageMaker 训练支持的数据源除了 S3，还包括 Amazon Elastic File System 以及 Amazon FSX for Lustre，详细内容可以参考官方博客）。

Amazon FSX for Lustre:

https://aws.amazon.com/cn/fsx/lustre/

官方博客:

https://aws.amazon.com/cn/blogs/machine-learning/choose-the-best-data-source-for-your-amazon-sagemaker-training-job/

• SageMaker Endpoint for TFS vs for Mxnet/Pytorch 的内建 serving 框架复杂性对比。SageMaker Endpoint for TFS 的介绍如下：

SageMaker Endpoint for Mxnet serving 的介绍如下（SageMaker Endpoint for Pytorch serving 是类似的）：只使用一个组件 mxnet model server，它的特点是，直接支持钩子函数；支持处理/ping REST API；缺省会使用所有的 GPU 来做推理，单个 TFS 进程只使用一个 GPU 来推理。

保持一致性

——质量可控

一致性是降低系统复杂度有利的手段。如果一个系统保持一致，意味着类似的事情用类似的方法去做，降低了认知负荷。在ML机器学习领域，我们经常会谈到一致性，比如效果线上线下一致性（如果模型离线效果好，模型上线以后表现不好，这就是发生了效果线上线下不一致），特征的线上线下一致性（特征的线上线下不一致是效果线上线下不一致的一个常见原因；特征的线上线下不一致指的是线下训练时样本中的特征的特征值可能会发生变化，并不和该样本在线上生成时的特征值完全一样。关于特征的线上线下一致性更详细的讨论请参考我的另一个文章）（https://github.com/yuhuiaws/ML-study/blob/main/%E6%8E%A8%E8%8D%90%E7%B3%BB%E7%BB%9F%E4%B8%93%E9%A2%98/%E6%8E%92%E5%BA%8F%E6%A8%A1%E5%9E%8B%E7%9A%84%E6%A0%B7%E6%9C%AC%E5%B7%A5%E7%A8%8Bby_%E6%A2%81%E5%AE%87%E8%BE%89.docx）。保持一致性是模型质量可控的一个重要因素。

对于 SageMaker 来说：

• 使用 SageMaker Processing job 对训练集做的一些特征工程比如某个特征 Z-score 标准化，那么为了让预测时与训练时有一致的特征工程，需要如何处理呢？在对训练集做了某个特征的 Z-score 标准化以后，用到的该特征的均值和方差这些 metadata 需要保存起来（SparkML 和 Sklearn 都有相应的 API 把这些 metadata 以文件的形式保存起来）；然后利用 SageMaker Inference pipeline 在第一个容器中把之前保存的 metadata 文件加载进来对原始特征进行 Z-score 标准化处理之后再送入第二个容器即模型推理容器。

• 如果在模型 serving 的时候，能及时知道每个特征的分布是否和训练时的数据集尤其是验证集的分布是否基本一致，对于模型才更可控。而 SageMaker 的 model monitor 的一个重要功能就是监控特征的统计漂移，如果模型在生产过程中接收到的数据的统计性质偏离了训练所依据的基准数据的性质，则模型将开始失去其预测的准确性。Model Monitor 使用规则检测数据漂移，并配合亚马逊云科技其他服务在发生数据漂移时向您发出警报。下图说明了此流程的工作方式：

总结

本文从软件哲学角度来介绍了 Amazon SageMaker 的一些设计思想以及如何使用 SageMaker 的一些功能。总体来讲，不管你是否考虑采用 SageMaker 作为你的机器学习平台，至少它的这些实现的思路以及设计哲学都是可以用来参考的。

Amazon SageMaker 作为全球使用量最大的机器学习平台，是值得你花时间来好好研究和探索以及实践的。关于 Amazon SageMaker 更多详细和更多深入的内容请参考我的github。（https://github.com/yuhuiaws/ML-study/tree/main/AWS-Sagemaker%E6%9C%BA%E5%99%A8%E5%AD%A6%E4%B9%A0%E5%B9%B3%E5%8F%B0）

感谢大家的耐心阅读。

本篇作者

梁宇辉

亚马逊云科技

机器学习产品技术专家

负责基于亚马逊云科技的机器学习方案的咨询与设计，专注于机器学习的推广与应用，深度参与了很多真实用户的机器学习项目的构建以及优化。对于深度学习模型分布式训练，推荐系统和计算广告等领域具有丰富经验。

听说，点完下面4个按钮

就不会碰到bug了！