简化数据科学家和应用程序开发人员之间协作的工具

作为首席技术官或工程经理，您经常会遇到数据科学家和应用程序开发人员之间意见不统一的问题。他们各自拥有独特的专业知识和方法，这常常使合作变得困难，而传统工具在弥合这种差距方面所能发挥的作用有限。

这两组人有着不同的思维方式和工作流程，这可能会导致显著的速度下降，尤其是在他们之间传递模型时。数据科学家优先考虑实验，而开发人员则专注于创建干净、可维护的代码。这种不匹配以及使用不兼容的工具可能会导致开发流程脱节，沟通中断。

本文探讨了数据科学家和开发人员使用的不同方法和工具集所带来的问题。本文强调了改进协作的重要性，并介绍了一种帮助他们更高效协作的工具。

为了了解他们的有效合作，让我们首先研究一下这两个群体之间的主要区别，以及决定他们使用和优先使用的工具的要求。

数据科学家和应用程序开发人员之间的差异

当数据科学家和应用程序开发人员交互时，您的团队可能会遇到以下问题：

• 工程方法
• 工作流程
• 工具集

工程方法
数据科学家采用研究方法，主要利用统计和机器学习技术来开发解决方案。他们的专长在于分析和解读复杂的数据集，提取有价值的见解，并构建预测模型。这使得他们更倾向于实验和探索，更倾向于创新，而不是严格遵循代码质量或软件开发最佳实践。

另一方面，开发人员采用软件工程方法，专注于设计、开发和维护针对特定用户需求的应用程序。这使得他们在构建应用程序时优先考虑编写干净、高效且可维护的代码。

基于这些不同的方法，你会发现你的团队往往有着截然相反的优先级。数据科学家优先考虑结果，而不是干净的代码、详细的文档或严格的测试，而开发人员则一丝不苟、条理分明。

工作流程
数据科学家在整个模型开发过程中采用灵活且迭代的方法。他们采用反复试验的过程，将数据变化与机器学习算法相结合，从数据中挖掘洞察，并生成最合适的模型。因此，他们在开发过程中不会采用标准的脚本编写、测试和调试实践。

开发人员遵循更结构化、更线性的工作流程来开发应用程序。他们根据严格的要求设计和开发软件，然后进行测试以确保质量和标准。他们还遵循更结构化的方法（例如 Agile 或 DevOps），强调稳定性和功能性。

因此，模型从实验阶段到生产的交接往往会成为重大瓶颈，导致沟通不畅、项目延误，并让所有相关人员感到沮丧。这种工作流程上的不匹配，让您思考如何弥合差距，并简化您的机器学习流程。

工具集
数据科学家需要支持主动实验、快速原型设计和模型开发的工具集。这一要求要求他们在 Jupyter Notebook 这样的交互式环境中工作。然而，Jupyter Notebook 灵活的开发结构使其不适用于共享代码或验证与模型相关的资产。

开发者工具专为软件开发和集成而设计。因此，它们依赖于强大的 IDE，例如Visual Studio或IntelliJ，提供高级编码、调试和项目管理功能。

各团队对工具集的需求各不相同，导致工具无法无缝集成和互操作。他们的传统工具旨在适应各自独特的工作流程和工程方法，这使得高效使用彼此的传统工具变得颇具挑战。让我们重点介绍一下数据科学家或开发人员在使用这些传统工具进行协作时遇到的阻力。

• 版本控制系统（VCS），例如Git
• 专业的机器学习平台，例如Amazon SageMaker和Google Vertex AI
• Docker等容器

版本控制系统 (VCS)：
您的开发人员依赖版本控制系统来跟踪、管理和共享他们在 IDE 中所做的代码更改。VCS（例如 Git）允许多个开发人员同时工作，同时跟踪其修改的不同版本。它使解决代码差异变得更加容易，并支持回滚到以前的版本。

然而，数据科学家使用 Git 来管理和与开发者共享不同版本的模型和模型工件并不现实。这些模型是用二进制代码编写的复杂软件，而 Git 无法显示不同版本二进制模型文件之间的差异，这使得跟踪任何更改变得困难。Git 也无法处理数据科学家所需的大数据和模型文件。

专用机器学习平台：
专用机器学习平台提供全面的定制工具和服务，帮助数据科学家开发模型。这些平台通常提供预配置的开发环境（基于云的笔记本），免去了手动设置和配置的麻烦。它们使数据科学家能够在一个平台上共享和管理他们的实验、模型和模型工件版本。

开发人员可以从平台部署数据科学家模型，但平台不允许他们以适合其工作流程的方式管理模型版本和模型资产。

容器：
像 Docker 这样的容器擅长为代码运行创建一致的环境，使部署更易于管理和可靠。这使得 Docker 成为开发人员快速打包和部署应用程序的理想选择。容器也适用于打包和部署模型，但不适用于模型资产（用于调试或修改模型）。因此，开发人员在部署后可能难以追踪模型工件。

你的团队花在解决这种不兼容性上的时间越多，他们为客户构建解决方案的时间就越少。因此，数据科学家和开发人员之间的无缝协作至关重要。

使用统一工具简化协作

孤立的信息使数据科学家和应用程序开发者难以全面了解项目进度，并及早发现潜在问题。例如，使用单独的工具进行模型交接通常需要在不同系统之间进行手动传输和转换。这为模型篡改留下了空间，并可能导致有关模型谱系的宝贵信息丢失。

统一的工具可以减少这一易出错流程的隐患，并确保整个模型开发和部署阶段的一致性。统一的 MLOps 工具（例如 KitOps、Kubeflow 和 MetaFlow）为您的团队提供了在同一平台上工作的不同方式，无需人工干预。

KitOps是一款开源 MLOps 工具，它通过 ModelKits 为数据科学家和开发者提供共享软件包，使他们能够访问相同的信息、实时跟踪开发进度并更高效地协作。他们可以在模型创建、开发和部署过程中使用此软件包。该软件包使他们能够更轻松地在使用现有传统工具的同时集成工作流程。

这些 ModelKit 与他们现有的标准开发工具兼容，确保从实验到应用部署，都能协同工作。数据科学家和开发者可以高效地打包和版本控制 ML 模型、数据集、代码、模型资产和需求。

ModelKits 还消除了阻碍开发或带来风险的常见障碍，例如版本控制问题、模型可靠性、工作流程差异等。

对理想工具的期望

对于任何 ML 组织来说，优秀的协作工具都具备以下一些关键特性：

可靠的标记系统
可靠的工具应确保您团队的模型和模型资产保持真实、未被篡改且可追溯，从而降低整个软件开发生命周期中未经授权的修改风险。这使得开发人员能够安心地部署数据科学家开发的模型，因为他们知道自己正在使用经过验证的准确工件。

KitOps 作为 OCI 工件的特性及其标记系统，能够在您的 ModelKit 版本之间建立血统，并让您能够清晰地了解 ModelKit 工件（即模型和模型资产）的起源和演化。该系统使用不可变的、内容可寻址的存储，这不允许两个 ModelKit 具有相同的内容版本。这意味着只有当其内容发生变化时，才会存储新的 ModelKit 版本。因此，使用相同内容和不同标记打包的 ModelKit 最终只会生成一个 ModelKit。

此标记系统可消除数据科学家使用包含相同模型和模型资产的 ModelKit 的可能性。此外，它还能帮助开发人员在检索和部署特定模型和模型资产时，轻松应对模型来源的挑战。

同步版本控制
KitOps 使您的数据科学家能够在打包 ModelKit 时同步对其模型和模型资产（即数据、代码、配置等）进行版本控制。此功能可确保其 ModelKit 的模型和模型资产保持一致。您的开发人员可以放心地检索和部署特定数据科学家的模型和模型资产，而无需担心混淆。

统一开发包
ModelKit 可以将数据、代码和模型存储为一个单元，即统一的开发包。有了 ModelKit 这样的统一开发包，您的数据科学家和开发者无需各自为政，进行操作和沟通。他们可以从 ModelKit 开发、集成、测试和部署机器学习模型。

您的数据科学家可以与开发人员共享包含其模型和相关工件的统一包，然后开发人员可以将它们无缝集成到应用程序中并确保 ML 模型的功能、要求或依赖关系。

标准软件包格式
理想的工具应遵循 OCI 标准格式，以确保与现有的 DevOps/MLOps 流水线兼容。KitOps 按照 OCI 标准打包 ModelKit，使其兼容所有容器。因此，您的数据科学家可以打包他们的机器学习模型、数据、依赖项和模型资产，并将其存储在团队的容器注册表中。然后，您的开发人员可以轻松提取这些标准化容器，并自信地将它们集成到他们的应用程序中。

OCI 标准打包格式使您的数据科学家和开发人员能够继续使用现有的基础架构。它促进了统一的工作流程，使两个团队可以独立工作，但又可以无缝集成各自的贡献，而不会出现兼容性或可重复性问题。

CLI 接口
CLI 工具和工作流程是数据科学和应用开发团队实现快速开发和细粒度控制的必备工具。KitOps 提供了一个 CLI 接口KitCLI，用于创建、管理和部署 ModelKit。这简化了使用 KitOps 的技术要求，方便数据科学家和开发者轻松上手。

作为基于 CLI 的工具，您的数据科学家和开发人员可以利用其 CLI 命令、远程访问和故障排除功能来自动执行任务、简化工作流程并实现与数据、模型和代码的有效交互。

各种协作式 AI/ML 工具有何不同？

与 Git 和 Docker 等其他协作工具相比，KitOps 提供了一种高效的方式，可以在数据科学家之外打包、版本控制和共享 AI 项目资产。这使得管理和分发 AI 模型及相关资源变得更加容易。以下是 KitOps 与其他工具的一些比较：

Git 与 KitOps

Git 擅长处理包含大量小文件的软件项目，但在处理对 AI/ML 至关重要的大型二进制对象（例如序列化模型和数据集）时却举步维艰。将模型开发代码存储在ModelKit中，可确保在整个开发过程中与 Jupyter Notebook、序列化模型和数据集保持同步。

Docker 与 KitOps

Docker 支持使用一致的软件包来运行和部署模型。KitOps 擅长创建统一的模型开发和部署软件包，并确保顺利集成到现有的部署工作流程中。

Jupyter Notebook 与 KitOps

Jupyter Notebook 非常适合开发模型。然而，它们需要状态管理和版本控制方面的帮助。为了解决这个问题，您可以将 Notebook 添加到 ModelKit，以实现有效的版本控制和共享。这样，您的数据科学家就可以继续使用 Notebook，同时软件开发团队也可以高效地访问和使用各自的模型。

数据科学家和软件开发人员之间的有效协作对于机器学习软件开发的成功至关重要。然而，工具、思维方式和工作流程方面的差异往往需要解决。虽然 Git、Docker 和 Jupyter Notebook 等工具提供了一些协作功能，但它们在管理 AI/ML 资源方面存在局限性。KitOps 通过提供统一的 AI 模型打包、版本控制和部署平台来弥补这一差距，使协作更加顺畅。

如果您对如何使用 KitOps 让您的团队协作更顺畅有任何疑问，请在Discord上与我们交流。集成 KitOps 将使您的团队能够保持高效工作，简化部署，并确保在整个项目生命周期内保持一致的版本控制。