如何使用Python中的面向对象编程构建机器学习项目？

Question

我观察到静态和机器学习科学家在使用Python(或其他语言)时通常不会遵循ML /数据科学项目的OOPS.

主要是因为在开发用于生产的ML代码时,缺乏对oops中最佳软件工程实践的理解.因为他们大多来自数学和统计学教育背景而不是计算机科学.

ML科学家开发临时原型代码和另一个软件团队使其生产就绪的日子在业界已经结束.

问题

1. 我们如何使用OOP为ML项目构建代码？
2. 是否每个主要任务(如上图所示)如数据清理,特征转换,网格搜索,模型验证等都应该是一个单独的类？ML的推荐代码设计实践是什么？
3. 任何好的github链接都有很好的代码可供参考(可能是一个写得很好的kaggle解决方案)
4. 应每类像数据清洗有fit(),transform(),fit_transform()功能为每一个过程是怎样的remove_missing(),outlier_removal()？当这样做时,为什么scikit-learn BaseEstimator通常会被继承？
5. 生产中ML项目的典型配置文件的结构应该是什么？

Answer 1

关于机器学习的一件特别之处，你是对的：数据科学家通常都是聪明人，所以他们在用代码表达他们的想法时没有问题。问题是他们倾向于创建即发即弃的代码，因为他们缺乏软件开发技巧 -但理想情况下不应该是这种情况。

在编写代码时，¹的代码应该没有任何区别。ML 和其他领域一样只是另一个领域，应该遵循干净的代码原则。

最重要的方面应该是SOLID。许多重要的方面直接紧随其后：可维护性、可读性、灵活性、可测试性、可靠性等。您可以添加到这种功能组合中的是变更风险。一段代码是纯 ML、银行业务逻辑还是助听器的听力学算法并不重要。尽管如此 - 其他开发人员将阅读该实现，将包含要修复的错误，将进行测试（希望如此）并可能重构和扩展。

在解决您的一些问题时，让我尝试更详细地解释这一点：

1,2) 您不应该认为 OOP 本身就是目标。如果有一个概念可以建模为一个类，这将使其他开发人员更容易使用它，它将是可读的，易于扩展，易于测试，易于避免错误，那么当然 - 将其作为一个类。但除非需要，否则不应遵循BDUF反模式。从免费功能开始，并在需要时演变为更好的界面。

4）通常创建这种复杂的继承层次结构以允许实现可扩展（参见SOLID 中的“O” ）。在这种情况下，库用户可以继承BaseEstimator并且很容易看到他们可以覆盖哪些方法以及这将如何适应 scikit 的现有结构。

5) 几乎与代码相同的原则，但考虑到将创建/编辑这些配置文件的人。对他们来说最简单的格式是什么？如何选择参数名称，以便清楚它们的含义，即使对于刚开始使用您的产品的初学者？

所有这些事情都应该结合猜测这段代码将来更改/扩展的可能性有多大？如果您确定某事应该一成不变，请不要过分担心所有方面（例如只关注可读性），并将您的努力集中在实现的更关键部分。

总结一下：想想将来会与你创造的东西互动的人。在产品/配置文件/用户界面的情况下，它应该始终是“用户至上”。如果是代码，请尝试将自己置于想要修复/扩展/理解您的代码的未来开发人员的位置。

¹当然有一些特殊情况，例如由于正式法规而需要正式证明正确或广泛记录的代码，而这个主要目标强加了一些特定的构造/实践。