AI能跨过“GitHub危机”吗？译文

机器学习如今正在面临一些危机，将会阻碍该领域的快速发展。这些危机源于一个更广泛的困境，即科学研究的可重复性。根据《自然》杂志对 1,500 名科学家进行的一项调查，70% 的研究人员曾尝试复制其他科学家的实验但未能获得成功，50% 以上的研究人员未能复制他们自己的研究成果。可重复性也称为可复制性，是科学方法的核心原则，有助于确保给定研究的结果不是一次性的，而是可复制的观察结果。

在计算机科学中，可重复性有一个更狭义的定义：任何结果都应该通过提供所有数据和代码来记录，以便可以再次执行计算并获得相同的结果。不幸的是，在透明度和可重复性方面，人工智能 (AI) 和机器学习（ML）的进展并不顺利。例如，有 31 位科学家在《自然》杂志上发表的一篇文章，他们对 Google Health 的一项记录了人工智能检测乳腺癌迹象的“成功”实验研究进行了严厉批评。

对该实验持怀疑态度的科学家声称，谷歌公司的研究提供的关于人工智能模型如何构建和测试的细节太少，甚至只是其专有技术的一种广告。如果没有关于如何创建此模型的足够信息，科学界几乎不可能审查和重复其结果。这导致人们越来越认为人工智能缺乏透明度，加剧了人类与人工智能系统之间的信任问题。

为了保持机器学习的持续进展，并使其在人工智能方面取得成功，解决该领域的可复制性和透明度问题至关重要。本文解释了人工智能可重复性危机的重要性，以及专门为机器学习构建的新版本 GitHub 如何帮助解决它。

为什么需要专门为机器学习构建的 GitHub

GitHub 是一种基于云的代码开发和管理服务。该平台用于软件版本控制，可以帮助开发人员在整个开发生命周期中跟踪代码的更改。这使得安全地分支和合并项目成为可能，并确保代码是可重复的，无论谁运行它，都能够以相同的方式工作。因为人工智能和机器学习应用程序是用代码编写的，所以 GitHub 是管理它们的自然选择。不幸的是，人工智能与更传统的软件项目之间的一些差异使得 GitHub 不适合人工智能，从而导致机器学习的可重复性危机。

GitHub 在设计时并未将数据作为核心项目组件

传统的软件算法是由开发人员从头脑中提取想法，并用确定性的、数学的、完备的图灵语言将它们编写为代码而创建的。这使得软件具有高度可复制性——重现给定软件所需的只是其代码和用于任务优化的库。

机器学习算法是不同的，因为它们不是从开发人员的头脑中创造出来的，而是从数据中“总结”出来的。这意味着，即使传统软件开发中记录的代码和运行环境变量保持不变，如果数据发生变化，机器学习算法也会发生变化。这是 GitHub 用于人工智能的问题的核心：即使跟踪用于开发人工智能算法的代码和库，也无法重复，因为它依赖于数据，而不仅仅是代码。

要想克服这个问题，有如下一些方法：

自动化数据版本控制：为了避免因训练数据集不一致而导致的可复制性问题，数据版本控制必须是任何管理人工智能 / 机器学习项目的平台的关键功能。这为团队提供了一种自动化方式来跟踪对数据所做的所有更改，确保结果可以与对应训练数据集的特定版本相关联。尽管当今的 GitHub 可以跟踪代码更改，但它无法跟踪数据。克服这一点将在解决人工智能的可重复性危机中发挥关键作用。

不可变数据沿袭：不可变数据沿袭为与数据相关的机器学习生命周期中的所有活动和资产提供不可更改的记录。这使机器学习团队能够跟踪其代码、模型和数据的每个版本。通过为与机器学习模型相关的所有活动（从训练到生产）提供不变的记录，可确保可重复性，并更好地管理历史数据集之间的关系。

人工智能使用大量的非结构化数据集

GitHub 用于人工智能的问题，不仅仅在于无法跟踪数据的变化。传统软件和人工智能依赖的数据类型是完全不同。传统软件是用代码编写的，而代码是用文本表示的。通常来说，文本文件并不是很大。但人工智能主要依赖非结构化数据，如音频、图像和视频，这些数据在量上远远大于文本文件，因此会面临额外的数据跟踪和管理挑战。

将来自多个数据源的数据组合到单个数据存储中的过程称为提取、转换和加载 (ETL)。这是将数据从源系统复制到目标系统的通用过程，它使不同类型的数据可以协同处理。数据科学家和工程师需要数据版本控制、数据沿袭、处理大型文件的能力，以及管理用于数据处理的脚本和库，以便提取、转换和加载数据，以用于人工智能应用程序开发。

本文将讨论该问题的一些新兴解决方案，但需要注意的是，该功能目前并未内置到 GitHub 的核心中，因此无法在平台上正确管理为机器学习算法提供信息的数据。

机器学习模型参数增加了复杂性人工智能的可复制性难题，以及难于将 GitHub 用于机器学习的原因，不仅是无法跟踪数据变化和管理大型非结构化数据集。即使用于开发人工智能算法的代码、库和数据保持不变，由于模型参数的可变性，仍然无法使用相同的人工智能系统复制相同的结果。如上所述，机器学习算法由数据决定。然而，这并不是影响系统的唯一因素。参数也会影响给定算法的运行。模型参数有两种类型：超参数和普通参数。超参数可以被认为是学习过程的高级控制，影响给定模型的结果参数。在机器学习模型训练完成之后，参数就是模型本身的代表。超参数虽然在训练期间被学习算法使用，但不是最终模型的一部分。

根据超参数的定义可知，超参数是在机器学习模型之外，因而无法从数据中估计它们的值。对超参数的更改会导致机器学习模型的最终算法发生更改。如果把代码比作构建人类大脑的蓝图，那么超参数和模型就是构建某个特定大脑的实施方案。这很重要，因为用于训练模型的相同代码库可以生成数百或数千个不同的参数。

实验结果跟踪和代码审查

在测试机器学习模型时，跟踪实验结果很重要。这些结果有助于确定哪种模型最适合使用，毫无疑问，GitHub 并不是用来记录这些细节的。尽管可以构建自定义解决方法，但这一解决方案无法扩展，并且由于时间和资源限制，许多开发人员无法访问。

当然，管理机器学习模型还涉及代码审查和版本跟踪，这是 GitHub 擅长的地方。不过，尽管 GitHub 可以很好地跟踪代码和环境变量，但机器学习引入了跟踪数据、参数、元数据、实验结果等的需求。Git 平台并不是为适应这种复杂程度而构建的，但幸运的是，有一些新兴的解决方案试图克服 GitHub 对人工智能和机器学习的限制。

用于人工智能和机器学习的 GitHub 替代方案

除了 GitHub，没有其他替代方案可以为管理人工智能和机器学习项目提供全面的解决方案。为从事人工智能和机器学习的数据科学家和工程师提供量身定制的 GitHub，是最理想的情况。不过，在做到这一点之前，并非没有可以解决上述不同问题的解决方案：

Neptune 是用于机器学习操作系统的元数据库服务，它提供了一个单一位置来记录、存储、显示、组织、比较和查询所有机器学习模型构建的元数据。提供了有关使用 Neptune 可对数据版本进行归档。这包括模型训练运行中的数据集版本控制、运行之间的数据集比较以及组织和共享数据集版本。

Pachyderm 是用于增强机器学习生命周期的数据层。该系统可为自动化数据版本控制和不可变数据沿袭提供解决方案。

DVC 是为机器学习项目构建的开源版本控制系统。该工具允许数据科学家和工程师保存和重现实验结果、控制模型和数据的版本，以及建立部署和协作流程。

Git 大文件存储（Git LFS）将音频样本、视频、数据集和图形等大文件替换为 Git 内部的文本指针，同时将文件内容存储在远程服务器上。这个工具是一个开源 Git 扩展，用于对大型文件（如音频和视频数据集）进行版本控制。它可以帮助开发人员更高效地处理大型文件和二进制文件。

DoIt 是一个 SQL 数据库，能够以与 Git 完全相同的方式分叉、克隆、分支、合并、推送和拉取数据。它将自己定位为“用于数据的 Git”，尽管 DoIt 通常用于版本跟踪，以确保在各种其他用例中一致的模型可复制性，但在数据管理上，可克服前面所述的 GitHub 的缺点。

LakeFS 是一种数据管理工具，可以在两种开源付费软件即服务 (SaaS) 版本中使用。该解决方案强调数据和代码的完全可重复性、快速数据还原和 PB 级版本控制。

DeltaLake 是一个开源项目，可以在现有存储系统（如 S3、ADLS、GCS 和 HDFS）之上构建 Lakehouse 架构。该解决方案的一些特性使其成为机器学习的理想选择，包括用于数据共享的开放协议、可扩展的元数据处理、数据版本控制，以及查看对数据所做的每次更改的审计历史记录的能力。