Ars AI 头条实验大结局——我们来了，我们看到了，我们用了很多计算时间

一位亚马逊工程师告诉我，当他听到我试图用 Ars 标题做的事情时，他首先想到的是我们选择了一个看似困难的问题。他警告说，我需要小心正确地设定我的期望。如果这是一个真正的商业问题……嗯，他能做的最好的事情就是建议将问题从“好或坏的标题”重新定义为不太具体的问题。这句话是对我为期 4 周的非全日制机器学习速成课程的成果进行框架化的最适合家庭的方式。到目前为止，我的 PyTorch 内核与其说是火炬，不如说是垃圾箱火灾。由于专业干预，准确性略有提高，但我离部署工作解决方案还差得很远。今天，据称我一年多来第一次去度假拜访我的父母，我坐在他们客厅的沙发上从事这个项目，不小心在我带来的戴尔笔记本电脑上在本地启动了一项模型培训工作—— 2.4 GHz Intel Core i3 7100U CPU——而不是在同一个 Jupyter 笔记本的 SageMaker 副本中。戴尔锁定得太厉害了，我不得不拔出电池重新启动它。但是，嘿，如果机器不一定在学习，至少我是。我们快要结束了，但如果这是课堂作业，我的成绩单成绩可能是“不完整”。回顾一下：我收到了过去五年用于 Ars 文章的成对标题，其中包含有关 A/B 测试获胜者及其相对点击率的数据。然后我被要求使用 Amazon Web Services 的 SageMaker 创建一个机器学习算法来预测未来成对头条新闻中的获胜者。在咨询各种亚马逊资源以获得一些急需的帮助之前，我最终走上了一些 ML 的死胡同。大多数部件都已就位以完成该项目。我们（更准确地说，我的“给 AWS 的朋友打电话”生命线）在不同的建模方法上取得了一些成功，尽管准确率（仅 70% 以上）并不像人们希望的那样确定。如果我抄下他们的笔记并使用由此创建的算法，我有足够的工作来生成（使用一些额外的肘部润滑脂）部署的模型和代码来对成对的头条新闻进行预测。但我必须说实话：我在自己的本地服务器和 SageMaker 上重现该工作的努力都失败了。在摸索 SageMaker 的复杂性的过程中（包括忘记关闭笔记本、运行自动学习流程（后来我被告知是针对“企业客户”的）以及其他错误），我消耗的 AWS 预算超过我愿意花在没有资金的冒险上。虽然我在智力上理解如何部署由所有这些乱七八糟的模型产生的模型，但我仍在调试该部署的实际执行。如果不出意外，这个项目已经成为机器学习项目（及其背后的人）可能失败的所有方式的一个非常有趣的教训。而这次的失败始于数据本身——甚至始于我们选择提出的问题。

我仍然可以通过这项努力得到一个可行的解决方案。但与此同时，我将在我的 GitHub 上分享我与之合作的数据集，以便为这次冒险提供更具交互性的组件。如果您能够获得更好的结果，请务必在下周加入我们，在本系列的现场总结中嘲笑我。 （更多细节在最后。）经过多次迭代调整我们在重定向尝试训练标题时使用的 SqueezeBert 模型后，结果集在测试中始终获得 66% 的准确率——略低于之前建议的高于 70百分之承诺。这包括努力减少在学习周期之间为调整输入而采取的步骤的大小——用于避免模型过度拟合或欠拟合的“学习率”超参数。我们大幅降低了学习率，因为当你有少量数据（就像我们这里所做的那样）并且学习率设置得太高时，它基本上会对数据集的结构和语法做出更大的假设。减少这会迫使模型将这些跳跃调整为小的婴儿步骤。我们最初的学习率设置为 2x10 -5 (2E-5)；我们将其降低到 1E-5。我们还尝试了一个更大的模型，该模型已经在大量文本上进行了预训练，称为 DeBERTa（Decoding-enhanced BERT with Disentangled Attention）。 DeBERTa 是一个非常复杂的模型：48 个变换层，具有 15 亿个参数。 DeBERTa 非常出色，它在 SuperGLUE 基准测试中在自然语言理解任务上的表现优于人类——这是第一个这样做的模型。生成的部署包也非常大：2.9 GB。有了所有这些额外的机器学习功能，我们的准确率又回到了 72%。考虑到 DeBERTa 在发现文本中的含义方面据说比人类更好，这种准确性正如一位著名的核电站运营商曾经说过的那样，“不是很好，也不是很糟糕”。最重要的是，时钟在滴答作响。我需要尝试启动并运行我自己的版本，以使用真实数据进行测试。

本地部署的尝试并不顺利，尤其是从性能角度来看。如果没有可用的良好 GPU，运行模型和端点的 PyTorch 作业实际上使我的系统停止。因此，我重新尝试在 SageMaker 上进行部署。我尝试自己在 SageMaker 上运行较小的 SqueezeBert 建模作业，但很快变得更加复杂。训练需要 PyTorch、Python 机器学习框架以及其他模块的集合。但是，当我将 SageMaker PyTorch 内核所需的各种 Python 模块导入时，尽管进行了更新，但它们并没有完全匹配。结果，在我的本地服务器上运行的部分代码失败了，我的努力陷入了依赖纠缠的泥潭。原来是 NumPy 库的某个版本有问题，除非我强制重新安装（pip uninstall numpy，pip install numpy -no-cache-dir），版本相同，并且错误仍然存​​在。我终于修复了它，但随后遇到了另一个错误，该错误使我无法运行训练作业并指示我联系客户服务：ResourceLimitExceeded：调用 CreateTrainingJob 操作时发生错误 (ResourceLimitExceeded)：帐户级别“用于训练作业使用的 ml.p3.2xlarge”服务限制为 0 个实例，当前利用率为 0 个实例，请求增量为 1 个实例。请联系 AWS 支持以请求提高此限制。为了完全完成这项工作，我需要让 Amazon 提高我的配额——这不是我开始插电时所预料到的。这是一个简单的修复，但解决模块冲突占用了一天的大部分时间。当我尝试使用我的专家帮助提供的预构建模型将其部署为 SageMaker 端点时，时间已经用完了。这项工作现在需要额外的时间。这就是我一直在讨论模型在针对最近的标题对进行测试时的表现——如果我把模型弄到那个点的话。如果我最终能做到，我会将结果放在评论和我的 GitHub 页面上的注释中。