机器学习根据定义，设计模式是针对常见问题的可重用解决方案。在软件工程中，这个概念可以追溯到1987年，当时Beck和Cunningham开始将其应用于编程。到2000年代，设计模式（尤其是面向OOP的SOLID设计原则）被认为是程序员的常识。快进15年，我们进入了软件2.0时代：机器学习模型开始在越来越多的代码位置取代经典功能。今天，我们将软件视为传统代码、机器学习模型和基础数据的融合。这种融合需要这些组件的无缝集成，考虑到这些领域通常不同的历史和演变，这通常是非常重要的。今天，我们将软件视为传统代码、机器学习模型和基础数据的融合。然而，设计模式尚未得到扩展以应对这个新时代的挑战。在软件2.0中，常见的挑战不仅出现在代码层面，还出现在问题定义、数据表示、训练方法、扩展和AI支持的系统设计的伦理方面。这为实践机器学习反模式创造了肥沃的土壤。不幸的是，如今，即使是博客文章和会议有时也会采用反模式：本应改进但实际上却让事情变得更糟的做法。由于反模式也需要技巧，所以这种技巧往往不被他们的实践者所认可。因此，在下文中，我将举例说明两个常见的ML挑战，但我将首先介绍它们的解决方案反模式，而不是从设计模式开始。模型在评估指标上表现不佳在一个常见的场景中，在收集、清理和准备数据后，工程师训练第一个模型并发现该模型在测试数据上表现不佳。一个常见的反模式是用更复杂的模式（例如，通常是梯度提升树）替换第一个模型并使用它来提高性能。此反模式的变体可以通过组合多个模型来遵循此步骤，例如通过模型平均。这些方法的问题在于它们只关注问题的一部分，即模型，并选择通过增加模型的复杂性来解决问题。这一步迫使我们接受过度拟合的高风险，并用可解释性换取额外的预测能力。虽然有减轻这种选择的副作用的有效方法（例如LIME），但我们无法完全消除它们。设计模式是错误分析。在实践中，这意味着通过评估模型在不同测试集上的拟合程度，甚至通过查看模型出错的个别案例，来了解模型哪里出错了。虽然我们都听说过“输入垃圾，输出垃圾”这句话，但很少有人意识到这是真的，即使数据有点不一致。标签可能来自不同的评分者，每个人对标签指南的解释略有不同。也许数据收集的方式随着时间发生了变化。错误分析的效果对于小数据问题尤其明显。但是，我们也应该记住，在大数据占比很大的情况下，我们还要处理长尾事件（例如通过高考识别稀缺人才）。错误分析的真正力量来自于这样一个事实，即我们不会通过应用它来交换可解释性或过度拟合的风险，事实上，仅仅应用它就会产生关于数据分布的关键知识。此外，错误分析使我们能够在以模型为中心的解决方案（例如，更复杂的模型）和以数据为中心的解决方案（例如，进一步的清洁步骤）之间进行选择。已部署模型的性能会随着时间的推移而下降。该模型经过广泛验证并部署到生产环境中。用户很高兴并给出了积极的反馈。然后，一个月/一个季度/一年之后，有关于预测缺陷的报告。这通常是概念漂移的表现，模型在输入和输出之间学习的联系随着时间的推移而改变。在某些地方，这种概念漂移是众所周知的（单词语义、垃圾邮件检测器），但“概念”漂移可能发生在任何领域。例如，面罩和社交距离规定也对许多以前部署的计算机视觉模型提出了挑战。一个常见的反模式是将这些示例归因于噪音，并希望情况随着时间的推移而稳定下来。这不仅意味着缺乏行动，还意味着错误归因，这在数据驱动的业务中通常应该避免。稍微好一点的反模式是通过快速重新训练和部署新模型来对报告做出反应。即使团队假设他们遵循敏捷软件开发原则并因此选择快速响应变化，这也是一种反模式。问题是这个解决方案解决了症状，但没有解决系统设计中的缺陷。设计模式是对性能的持续评估，这意味着您可以预期会发生漂移，因此设计您的系统以尽快注意到它。这是一种完全不同的方法，因为重点不是反应速度，而是检测速度。这使整个系统处于更受控的过程中，从而为任何反应的优先级排序留出更多空间。持续评估意味着建立流程和工具以持续为小型新数据集生成基本事实。在大多数情况下，这涉及手动标记，通常使用众包服务。然而，在某些情况下，我们可以使用其他更复杂的方法，但在部署环境中，模型和设备无法生成地面实况标签。例如，在自动驾驶汽车的开发中，来自一个传感器（例如LiDAR）的输入可用于从另一个传感器（例如相机）生成地面实况。机器学习的SOLID设计原则我编写设计模式是因为该领域已经达到成熟水平，我们不仅应该分享我们的最佳实践，而且还能够将它们抽象为实际的设计模式。幸运的是，这项工作已经由几个小组开始。事实上，最近已经出版了两本关于该主题的书籍[1]、[2]。我喜欢阅读它们，但我仍然觉得虽然我们正朝着正确的方向前进，但我们距离为ML从业者制定SOLID设计原则还有几步之遥。我相信，虽然基础知识已经掌握并用于构建当今支持AI的产品，但研究设计模式和反模式是迈向软件2.0时代的重要一步。
