从Stitch Fix建立的ML平台中学到的东西
Lessons Learned from the ML Platform Built by Stitch Fix
这篇文章最初是ML平台播客的一集，是由Piotr Niedźwiedź和Aurimas Griciūnas主持的节目。他们与ML平台专业人员一起讨论设计选择、最佳实践、示例工具栈以及一些最优秀的ML平台专业人员的实际经验。
在这一集中，Stefan Krawczyk分享了他在Stitch Fix建立ML平台的经验。
你可以在YouTube上观看：
或者在以下播客平台上收听：
- Spotify
- Apple Podcasts
但是，如果你更喜欢文字版本，这里就有了！
在这一集中，你将学到：
-
1
Stitch Fix的ML平台解决的问题 -
2
模型序列化 -
3
模型打包 -
4
管理对平台的功能请求 -
5
Stitch Fix端到端ML团队的结构
介绍
Piotr: 大家好！我是Piotr Niedźwiedź，这里还有Aurimas Griciūnas，我们来自neptune.ai，欢迎收听ML平台播客。
今天我们邀请了一个非常独特和有趣的嘉宾，Stefan Krawczyk。Stefan是一名软件工程师、数据科学家，也一直从事ML工程师的工作。他还曾在上一家公司负责数据平台，并且是开源框架Hamilton的共同创作者。
我最近还发现，你是DAGWorks的CEO。
Stefan: 是的。谢谢你们邀请我。我很高兴能与你们交谈，Piotr和Aurimas。
DAGWorks是什么？
Piotr: 你的背景非常有趣，而且你已经涵盖了当今所有重要的方面。
你能告诉我们更多关于你目前的创业项目DAGWorks的情况吗？
Stefan: 当然。对于那些不了解DAGWorks的人来说，DAG是指有向无环图（Directed Acyclic Graph）。这是对我们思考问题和解决问题的一种致敬。
我们希望消除人们在维护机器学习流水线时感受到的痛苦。
我们希望让一支初级数据科学团队能够编写代码、将其投入生产、进行维护，而当他们离开时，重要的是没有人会因为继承他们的代码而做噩梦。
从更高的层面上说，我们正在努力通过使团队更容易进入生产并维护其模型流水线、ETL或工作流，使机器学习项目更具人力资本效率。
DAGWorks与其他流行解决方案有何不同？
Piotr: 从高层次来看，价值听起来很不错，但深入了解后，我们会发现在流水线周围有很多事情发生，而且存在不同类型的问题。
它（DAGWorks解决方案）与当今流行的解决方案有何不同？例如，我们来看Airflow、AWS SageMaker流水线。它（DAGWorks）在哪里适用？
Stefan: 好问题。我们正在基于Hamilton进行开发，Hamilton是一种描述数据流的开源框架。
就Hamilton以及我们的起点而言，我们正在帮助你建模微观层面。
例如，Airflow是一种宏观编排框架。你将任务分解为大型任务和块，但在任务内部进行的软件工程是你通常会随着机器学习在公司内的发展或者出现新的数据源、想要创建新模型而不断更新和添加的内容。
我们首先的目标是帮助你用Hamilton代码替换那些过程性的Python代码，我可以详细介绍一下。
我们的想法是帮助初级数据科学团队在维护类似Airflow的宏观任务中的代码时，不会被软件工程方面的问题绊倒。
现在，Hamilton非常轻量级。人们在Airflow任务中使用Hamilton。他们在FastAPI、Flask应用程序中使用我们，在笔记本中也可以使用我们。
你几乎可以把Hamilton看作Python函数的DBT。它以一种非常主观的方式编写Python代码。从高层来看，它是上面的一层。
然后，我们正在努力推出平台和开源的功能，以便能够获取Hamilton数据流定义并帮助您自动生成Airflow任务。
对于初级数据科学家来说，使用Airflow、Prefect、Dexter并不重要。这只是一个实现细节。你使用的工具并不能帮助你建立更好的模型。它只是你运行流水线的工具。
2023年的MLOps景观：顶级工具和平台
为什么在DAG内部还需要一个DAG？
Piotr：这是一段过程化的Python代码。如果我理解正确，这是一种DAG内部的DAG。但是为什么我们需要在DAG内部再创建一个DAG呢？
Stefan：当你在模型上进行迭代时，你会添加一个新的特征，对吧？
一个新的特征大致对应一个新的列，对吧？
你不会只为了计算一个单独的特征而添加一个新的Airflow任务，除非它是一种占用很多内存的大型特征。你将在这些任务内部进行迭代。
关于我们如何提出Hamilton的背景故事…
在创造Hamilton的Stitch Fix公司，数据科学家负责从原型到生产的全流程开发，并负责所推向生产的工作。
团队实际上在进行时间序列预测，每个月或每几周，他们都需要更新他们的模型以帮助为业务生成预测。
宏观工作流程并没有发生变化，他们只是改变了任务步骤中的内容。
但是团队非常老旧，他们有很多代码；很多遗留代码。在创建功能方面，他们创建了大约一千个功能。
Piotr：一千个功能？
Stefan：是的，我的意思是，在时间序列预测中，每个月添加功能非常容易。
比如说有一个市场支出，或者如果你想建模或模拟某些东西。例如，下个月将有市场支出，我们如何模拟需求。
因此，他们始终在代码中不断添加内容，但问题是它的工程化程度不高。添加新内容非常慢，他们没有信心在添加或更改内容时不会出现问题。
我们提出了Hamilton，而不是每个拉取请求都需要一位高级软件工程师来告诉他们：
“嘿，解耦合”，
“嘿，你写的方式可能会有问题”，
我们提出了Hamilton这一范式。在这一范式中，您将所有内容都描述为函数，函数名称与输出完全对应 – 这是因为问题之一是，给定一个功能，我们是否可以将其映射到一个函数，使函数名称与该输出对应，并在函数的参数中声明计算所需的内容。
当您阅读代码时，非常清楚输出是什么，输入是什么。您有函数的文档字符串，因为在脚本形式的过程化代码中，通常没有合适的地方放置文档。
Piotr：哦，你可以把它放在行的上方，对吧？
Stefan：不是…你会开始盯着一堆文字看。
从理解流程的角度来看，如果你想了解事物的流程，阅读函数比较容易。
[使用Hamilton]你不会被压垮，你有docstring，一个用于文档的函数，但是默认情况下，一切都可以进行单元测试 – 他们没有一个好的测试故事。
在与Hamilton相比的其他框架中，函数的命名和输入参数的组合形成了一个DAG或依赖图。
在其他框架中 –
Piotr： 所以你在Python之上做了一些魔法，对吧？为了弄清楚。
Stefan： 是的！
Piotr： 那么使用它如何？IDE支持吗？
Stefan： 所以IDE？不支持。在路线图上，我们计划提供更多的插件，但本质上，与其必须用一个步骤注释一个函数，然后手动指定从这些步骤构建工作流，我们通过命名的方式绕过了这个过程。
所以这是一个冗长的说法，我们从微观层面开始，因为这正是拖慢团队速度的原因。
通过转换到Hamilton，他们在每月任务上的效率提高了四倍，只是因为这是一种非常规定和简单的方式来添加或更新某些内容。
这也很清晰和容易知道在代码库中添加到哪里，需要审查什么，了解影响，然后因此如何将其与平台的其余部分集成。
如何衡量工具是否增加了价值？
Piotr：这是一个问题，我有时会听到，特别是来自ML平台团队和团队领导者，他们需要证明他们的存在。
作为ML数据平台团队的负责人，你是如何做到的？你如何知道我们正在构建的平台，我们为数据科学团队或数据团队提供的工具是否有价值？
Stefan：是的，这是一个难题，没有简单的答案。
如果你能够以数据驱动的方式进行评估，那是最好的。但是困难的部分是人们的技能水平不同。所以如果你要说，测量某人完成某项任务需要多长时间，你必须考虑他们的资历，他们是初级还是高级。
但本质上，如果你有足够的数据点，那么你可以大致说一些平均值。过去某人完成某项任务需要这么长时间，现在需要这么长时间，因此你可以得到比例和增加的价值，并且你想要计算这个事件发生的次数。然后你可以测量人力时间，因此工资，并说我们节省了这么多 – 这只是从效率方面来看。
机器学习平台的另一种帮助方式是通过阻止生产事故。你可以看一下停机的成本，然后反过来思考，“嘿，如果你阻止了这些停机，我们还提供了这种类型的价值。”
Piotr：明白了。
Hamilton的一些用例是什么？
Aurimas：也许我们有点退后了一步…
对我来说，听起来Hamilton主要用于特征工程。我理解得对吗？还是还有其他用例？
Stefan：是的，Hamilton的根源就在这里。如果你需要一些帮助来组织你的特征工程问题，如果你在使用Python，Hamilton非常有用。
大多数人不喜欢他们的pandas代码，Hamilton可以帮助你组织它。但是使用Hamilton时，它可以与任何Python对象类型一起使用。
现在大多数机器都足够大，你可能不需要立即使用Airflow，而在这种情况下，你可以使用Hamilton来建模你的端到端机器学习流水线。
在存储库中，我们有一些关于如何端到端操作的示例。我认为Hamilton是一把瑞士军刀。我们有一位Adobe的用户正在使用它来帮助管理一些他们正在进行的提示工程工作，例如。
我们还有一些人在使用它更多地用于特征工程，但是在Flask应用程序中使用它。我们还有其他人在使用它的Python类型不可知性，帮助他们编排数据流来生成某些Python对象。
非常、非常广泛，但它的根源是特征工程，但绝对很容易扩展到轻量级的端到端机器学习模型。这就是我们对系统生态系统要添加的扩展感到兴奋的地方。例如，我们如何让某人轻松地使用 Neptune 并集成它？
Piotr: Stefan，这部分很有意思，因为我没想到并想要再次确认。
假设我们不需要像由 Airflow 运行的宏级管道，而且我们只需要在一台机器上进行操作，你也会包括围绕模型训练的步骤，还是更多关于数据？
Stefan: 不，两者都包括。
Hamilton 的好处是你可以逻辑地表达数据流。你可以进行数据源、特征化、创建训练集、模型训练、预测等操作，并且你不需要明确指定任务边界。
使用 Hamilton，你可以逻辑地定义一切端到端的操作。在运行时，你只需指定你想要计算的内容 – 它将只计算你所请求的 DAG 的子集。
Piotr: 那训练的 for 循环怎么办呢？比如说，梯度下降的 1000 次迭代，这在内部是如何工作的？
Stefan: 在那里你有选择…
我想现在的人们会将其放在函数的主体中 – 所以你只需有一个函数来涵盖该训练步骤。
使用 Hamilton，初级和高级人员都喜欢它，因为你可以完全灵活地在 Python 函数中实现任何你想做的事情。这只是一种有见解的方式，可以帮助你组织代码结构。
为什么 Hamilton 没有特征存储？
Aurimas: 回到你的 GitHub 存储库中的那个表格，我注意到一个非常有趣的观点，你说你不以任何方式与特征存储进行比较。
然而，我稍微深入思考了一下… 特征存储用于存储特征，但它还具有特征定义，就像现代特征平台也具有特征计算和定义层一样，对吗？
在某些情况下，它们甚至不需要特征存储。你可能只需要在训练时和推理时计算特征。所以我想，为什么 Hamilton 不能用于这个呢？
Stefan: 你说得非常对。我将其称为特征定义存储。那就是 Stitch Fix 团队建立的东西 – 只是在 Git 的基础上。
Hamilton 强制你将函数与其运行的上下文分离。你被迫将事物分成模块。
如果你想构建一个能够使用 Hamilton 计算事物的特征库，你被迫这样做 – 然后你可以轻松地在不同的上下文中共享和重用这些特征转换。
它强制你对齐命名、模式和输入。就特征的输入而言，它们必须被适当地命名。
如果你不需要存储数据，你可以使用 Hamilton 重新计算一切。但如果你需要为缓存存储数据，你可以在 Hamilton 前使用它，使用 Hamilton 的计算并将其推送到类似 FIST 的东西。
Aurimas: 我也在 DAGWorks 网站上看到，如你已经提到的，你也可以在函数中训练模型。所以假设你在 Hamilton 的函数中训练了一个模型。
你是否能够以某种方式从你放置的存储中提取该模型，然后将其作为一个函数提供，或者这不可能？
Stefan: 这就是 Hamilton 真正轻量级的地方。它对实体化没有固定的看法。所以这就是连接器或其他东西介入的地方，例如，你将实际的工件推送到哪里。
这是一个轻量级级别的东西。你可以要求 Hamilton DAG 计算模型，然后得到模型，接下来，你可以保存它或将它推送到你的数据存储中 – 你也可以编写一个 Hamilton 函数来完成这个过程。
运行函数的副作用是将其推送，但这是我们希望扩展并提供更多功能的地方，以使其在DAG内更自然地可插拔，以指定构建模型的上下文，然后在您想要运行的上下文中应该指定“我想保存模型并将其放入Neptune。”
这就是我们的目标，但现在，Hamilton不限制您想要如何做到这一点。
Aurimas：但它能够提取模型并在服务层中使用吗？
Stefan：是的。Hamilton的一个特点是，对于每个函数，您可以根据配置或不同的模块切换函数实现。
例如，您可以有两个函数的实现：一个函数从S3中获取模型的路径，另一个函数期望通过传递模型或训练数据来适应模型。
在函数实现方面有灵活性，并且可以随时切换它们。简而言之，Hamilton框架本身对此没有任何内置功能……
但我们在如何实现这一点方面有灵活性。
Aurimas：基本上，您可以使用Hamilton进行端到端的训练和服务。
这就是我听说的。
Stefan：我的意思是，您可以建模。是的。
使用Hamilton进行数据版本控制
Piotr：那么数据版本控制呢？比如，简化的形式。
我了解Hamilton更多是针对代码库的。当我们对代码进行版本控制时，我们版本化的可能是特征定义之类的东西，对吗？
在这种情况下，您还需要什么来表示“是的，我们有版本化的数据集”？
Stefan：是的。你说得对。在Hamilton中，您可以为您的数据进行编码描述。如果您将其存储在Git中，或者以结构化的方式对Python包进行版本控制，您可以在任何时间点返回并了解计算的确切血统。
但是源数据存放在何处以及数据集版本控制的输出是什么，这取决于您（即您希望存储和捕获的精确程度）。
如果您使用Hamilton创建某种数据集或转换数据集，您将在某个地方存储该数据集。如果您将使用的Git SHA和用于实例化Hamilton DAG的配置存储在该artifact中，您始终可以返回到过去的时间重新创建它，前提是源数据仍然存在。
这是从在Stitch Fix构建平台Hamilton的经验中得出的。我们有这些钩子，或者至少有能力与之集成。现在，这是DAGWorks平台的一部分。
我们试图为您提供一种存储和捕获额外元数据的方法，以便您无需构建该组件，从而可以将其与您可能拥有的其他系统连接起来。
根据您的规模，您可能拥有一个数据目录。可能会与之一起存储和发出开放血统信息等。
肯定地说，我们正在寻找集成的创意或早期堆栈，但除此之外，我们没有固定的意见。在数据集版本控制方面，我们的帮助不仅是对数据进行版本控制，而且如果在Hamilton中进行了描述，您可以根据使用的代码路径重新计算数据，确保精确性。
您何时决定构建Hamilton？
Aurimas：也许我们可以稍微回到您在Stitch Fix和Hamilton本身的工作。
您是在什么时候决定需要构建Hamilton的？
Stefan：回到2019年。
我们在18个月前才将Hamilton开源。这不是一个新的库 – 在Stitch Fix中已经运行了三年多。
对于Stitch Fix来说，有意思的是它是一个拥有100多名数据科学家的数据科学组织，他们从事各种业务相关的建模工作。
我是数据科学的平台团队的一员。我的团队的任务是为团队简化模型生产化流程。
我们考虑到，“我们如何降低软件工程门槛？”
答案是为他们提供工具抽象和API，使他们不必成为优秀的软件工程师 – MLOps最佳实践基本上是免费的。
有一个团队在苦苦挣扎，经理找到我们交谈。他说：“这个代码库糟透了，我们需要帮助，你们能出点子吗？我想优先考虑文档和测试，如果你们能改进我们的工作流，那就太好了。”这基本上就是要求，对吧？
在Stitch Fix，我们一直在思考“从平台到数据科学家交互的视角，最终用户体验或API是什么？”
我认为Python函数不是需要某人实现的面向对象接口 – 只要给我一个函数，Python就有足够的元编程能力来检查函数并了解其形状、输入和输出，你可以有类型注解等等。
所以，支持在家工作的星期三。Stitch Fix有一个不开会的日子，我抽出一整天来思考这个问题。
我想：“我怎样才能确保一切都可以进行单元测试，友好的文档，并且DAG和工作流程在某种程度上是自解释的，方便别人描述。”
在这种情况下，我原型化了Hamilton并把它带回了团队。我的现任联合创始人，Stich Fix的前同事Elijah也提出了第二个实现，更像是一种DAG风格的方法。
团队喜欢我的实现，但本质上，一切都可以进行单元测试，友好的文档，并且有一个良好的集成测试方案。
在数据科学代码中，很容易将大量代码附加到同一个脚本中，而且它会不断增长。使用Hamilton很容易。您不必计算一切来测试某个东西 – 这也是建立一个DAG的想法的一部分，Hamilton知道仅遍历您想要计算的路径。
但这大致就是起源故事。
迁移团队并让他们加入。拉取请求速度更快。团队喜欢它。他们非常喜欢这种范式，因为它确实比以前简化了他们的生活。
在深度学习和表格数据中使用Hamilton
Piotr：之前你提到过你一直在处理超过1000个手动创建的特征，对吗？
你会说Hamilton在表格数据的情况下更有用，还是它也可以用于深度学习类型的数据，其中有很多特征但不是手动开发的？
Stefan：当然。 Hamilton的根源和优势来自于试图管理和创建输入模型的表格数据。
Stich Fix团队使用Hamilton管理超过4000个特征转换。我想说 –
Piotr：是为了一个模型吗？
Stefan：对于他们创建的所有模型，他们在同一个代码库中共同拥有4000个特征转换，他们可以添加和管理，而且不会减慢他们的速度。
关于其他类型的问题，我想说，“是的。” Hamilton实际上正在取代你所做的一些软件工程。这主要取决于你必须做些什么来组合数据流以进行深度学习。
有些人说，“哦，Hamilton看起来有点像LangChain。”我还没有看过LangChain，我知道人们正在使用它来组合大型模型。所以，我还不确定他们认为它们有何相似之处，但是如果你有使用编码器的过程代码，你可能有办法将其转录并与Hamilton一起使用。
Hamilton具有一个非常轻量级的数据质量运行时检查功能。如果检查函数的输出对您很重要，我们有一种可扩展的方式可以做到。
如果您正在使用表格数据，可以使用Pandera。这是一个描述模式的流行库 – 我们对此提供支持。否则，如果您正在使用其他对象类型或张量等，请注意我们有一种可扩展的方法，可以确保张量符合您所期望的某些标准。
Piotr: 你是否也会对某一列或一组列进行一些统计计算，比如说，使用Hamilton作为测试数据集的框架？
我说的不是验证列中的特定值，而是数据的统计分布。
Stefan: 所有东西都是Python函数，而Hamilton框架执行这些函数的美妙之处在于我们在函数的输出方面具有灵活性，而这个输出恰好是一个数据框。
是的，我们可以在框架中注入一些东西，以获取摘要统计信息并将其输出。毫无疑问，这是我们正在尝试的内容之一。
Piotr: 关于列的组合，比如说你想计算三列之间的一些统计相关性，这如何适应代表列的函数范式？
Stefan: 这取决于你是否希望它成为一个实际的转换。
你可以编写一个函数，接受该数据框的输入或输出，并在函数体中执行相应操作 – 基本上，你可以手动完成。
这真的取决于你是否希望它成为一个平台角度的事情，如果你希望数据科学家能够自动捕捉各种内容，那么我会从平台的角度考虑，尝试添加一个装饰器，也就是所谓的包装函数，然后可以描述和进行所需的内省。
为什么要开源Hamilton？
Piotr: 我要回到Hamilton在Stitch Fix开始的故事。为什么要选择开源？
对我来说这是一件好奇的事情，因为我在几家公司工作过，总会有一些喜欢的内部库和项目，但是，是的，并不是每个项目都适合开放和真正使用。
我不是说添加一个许可证文件并将存储库公开，而是说让它真正活跃起来并真正开放。
Stefan: 是的。就构建与购买的观点而言，我们一直在看整个堆栈，我们创建了Hamilton在2019年，我们看到有很多类似的东西被开源 – 我们就像，“嘿，我想我们有一个独特的角度。” 在我们拥有的其他工具中，Hamilton是最容易开源的。
对于了解Stitch Fix的人来说，品牌是非常重要的。如果你想了解一些有趣的技术和事情的故事，你可以搜索Stitch Fix Multithreaded博客。
我曾经是一个技术品牌团队的一部分，他们试图发布高质量的内容。这有助于Stitch Fix的品牌，进而有助于招聘。
从品牌的角度来看，这是动机之一；设定一个高质量的标准，并推出一些对品牌有好处的东西。
而我们团队只是觉得Hamilton是我们所做的事情中最容易开源的，而且我认为它更有趣。
我们构建了类似于MLflow的配置驱动的模型管道，但我想说这并不是那么独特。Hamilton在解决某个特定问题上有一个更独特的角度。所以在这两种情况下，我们认为这是一个很好的品牌机会。
而且从库的表面积上来看，它相当小。你不需要太多的依赖关系，这使得从开源的角度来维护它变得可行。
需求也相对较低，因为你只需要Python 3.6 – 现在已经是3.6退役了，所以现在是3.7，而且它只是正常工作。
从这个角度来看，我认为它在很大程度上具有良好的优势，不太可能需要添加太多东西来提高采用率，使其在社区中可用，但同时维护方面的工作量也相对较小。
最后一个部分有点未知；“我们将花多少时间来建立一个社区？”我不总是能在那上面花更多的时间，但这就是我们开源它的故事。
我花了几个月的时间尝试写一篇博客文章，为了发布而努力- 这花了一些时间，但这也是把你的想法写下来并清晰地表达出来的好方法。
发布一个开源产品
Piotr：关于外部的采用情况，发布时怎么样？你能和我们分享一下你是如何推广它的吗？从第一天起就有效果了吗，还是需要一些时间才能让它更受欢迎？
Stefan：幸运的是，Stitch Fix有一个相当多读者的博客。我将博客与之配对，在几个月内获得了几百个星星。我们还有一个Slack社区可以加入。
我没有其他东西来比较它的好坏，但Stitch Fix之外的人正在采用它。英国政府数字服务正在使用Hamilton进行全国反馈管道。
IBM内部有一个人在使用它作为小型内部搜索工具。开源的问题是你不知道谁在生产中使用你，因为遥测和其他东西很难。人们进来，提出问题，提出问题，并给予我们更多的帮助和动力。
Piotr：那么关于第一个有用的来自外部的拉取请求呢？
Stefan：我们很幸运有一个叫James Lamb的人加入。他在几个开源项目上工作过，他帮助我们整理了存储库的文档和结构。
基本上，整理并使外部贡献者能够轻松运行我们的测试等。我想说这是一项非常有价值的工作，因为他给出了反馈，比如“嘿，这个拉取请求模板太长了，我们如何缩短它？”- “你会吓跑贡献者的。”
他给了我们一些建议，并帮助我们稍微设置了一下结构。这种存储库的整理使其他人更容易做出贡献。
Stitch Fix面临的最大挑战
Aurimas:是的，也让我们回顾一下你在Stitch Fix的工作。你提到Hamilton是最容易开源的，对吗？如果我理解正确，你做的工作不仅仅是管道。
你可以详细介绍一下Stitch Fix面临的最大问题以及你如何作为一个平台解决它吗？
Stefan：是的，你可以想象一下，回到六年前，没有成熟和可用的开源工具。在Stitch Fix，如果数据科学家需要为模型创建API，他们将负责在EC2上运行一些Flask应用程序的镜像。
我们的起点是从生产角度帮助稳定化，确保更好的实践。帮助一个团队，使得在FastAPI之上轻松部署后端，数据科学家只需要编写Python函数作为集成点。
这有助于稳定和标准化所有后端微服务，因为平台现在拥有实际的Web服务。
Piotr：所以你为他们提供了Lambda接口？
Stefan：可以说是更重量级的。基本上，使他们能够提供requirements.txt、基础Docker镜像，以及代码所在的Git存储库，并能够轻松创建一个包含Web服务的Docker容器，并在AWS上进行部署。
Aurimas：也许我听到的是模板存储库？或者你这里叫它们不同的名称？
Stefan：我们不是完全模板，但只需要一些东西来创建一个微服务并将其部署。一旦完成，就可以看看工作流程的各个部分。
其中一个问题是模型序列化和“如何知道生产环境中运行的模型版本是什么？”因此，我们开发了一个名为模型封套的小项目，其思想与信封的隐喻类似，你可以把东西放进去。
例如，您可以将模型粘贴进去，但也可以粘贴很多关于模型的元数据和额外信息。模型序列化的问题在于需要精确的Python依赖，否则可能会遇到序列化问题。
如果您动态重新加载模型，可能会遇到一些问题，例如有人推送了一个错误的模型，或者很难回滚。 Stitch Fix的工作方式之一 – 或者以前的工作方式 – 是检测到新模型后会自动重新加载它。
但从操作角度来看，回滚或在测试之前测试东西是一种挑战。通过模型封套抽象，想法是您保存模型，然后提供一些配置和用户界面，然后我们可以提供一个新模型，自动部署一个新的服务，每个模型构建都是一个新的Docker容器，因此每个服务都是不可变的。
它提供了更好的结构来推送一些内容，使回滚变得容易，因此我们只需切换容器。如果您想调试某个内容，那么您只需拉取该容器并将其与正在生产中运行的内容进行比较。
它还使我们能够插入CI/CD类型的管道，而无需将其放入模型管道中，因为常见的框架现在具有在某人的机器学习模型管道ETL的最后进行各种CI/CD检查以验证模型。
我们将这部分内容抽象出来，使其成为人们在创建模型管道之后可以添加的内容。这样，当需要更改和更新时，您就可以更容易地进行更改，因此模型管道在某种程度上不必更改，例如，如果有错误并且想要创建一个新的测试。
大体上就是这样。模型封套即其名称。它帮助用户在一个小时内构建模型并投入生产。
我们在批处理方面也有同等的功能。通常，如果您想创建一个模型，然后在某个地方运行批处理，您将不得不编写任务。我们有办法使模型在Spark或大型计算机上运行。
人们不需要编写批处理任务来进行批量预测。因为在公司达到一定的成熟水平时，您会开始有一些团队希望重用其他团队的模型。在这种情况下，我们就是中间人，帮助提供一种标准方法，使人们可以在批处理中运行其他人的模型，而无需了解太多细节。
在Stitch Fix平台中序列化模型
Piotr：Stefan，谈到序列化模型，您是否也将特征的预处理和后处理序列化到此模型中？您在哪里划定了边界？
而且与此密切相关的是，您如何描述模型的签名？比如说它是一个RESTful API，对吗？您是如何做到的？
Stefan：当某人保存模型时，他们必须提供指向函数名称或提供函数的指针。
我们会使用该函数进行内省，并在保存模型API的一部分中询问输入训练数据是什么，示例输出是什么？因此，我们实际上可以在保存模型时对API进行更多的内省。因此，如果某人传递了一个附加数据帧，我们会说：“嘿，您需要为此数据帧提供一些示例数据，以便我们可以理解、内省并创建该函数。”
然后，我们会在Web服务端创建一个Pydantic模式。因此，如果您使用FastAPI，您可以转到文档页面，您将获得一个很好的、易于执行的基于REST的接口，该接口会告诉您运行此模型所需的功能。
因此，在模型中被组合的内容实际上取决于我们试图将Python视为序列化边界的方式。
边界实际上是了解函数中有什么的情况。人们可以编写一个包括特征处理作为委托给模型之前的第一步的函数，或者他们可以选择将两者分开。在这种情况下，他们需要在调用时首先访问特征存储，以获取正确的特征，然后将其传递给Web服务的请求，以计算出预测。
所以我们对边界的位置并没有确切的意见，但这是我们试图回到的一种方式，以帮助更好地标准化，因为不同的用例有不同的SLA，有不同的需求，有时将其拼接在一起是有意义的，有时更容易进行预计算，不需要将其与模型粘合在一起。
Piotr：而数据科学家的接口，比如构建这样一个模型并序列化该模型，是使用Python完成的，他们不离开Python。一切都是用Python完成的。我喜欢这种提供示例输入和示例输出的想法。这是一种非常Python的做事方式。就像单元测试一样，这是我们确保保留签名的方法。
Stefan：是的，因此，实际上是从这个示例输入和输出开始的，理想情况下，这也是训练集。因此，这就是我们可以预先计算摘要统计量的地方，就像你所暗示的那样。因此，每当有人保存一个模型时，我们尽量提供一些免费的东西。
比如，他们不需要考虑数据的可观察性，但是请注意，如果您提供了这些数据，我们会捕获与之相关的信息。因此，如果出现问题，我们可以提供一条面包屑路径来帮助您确定发生了什么变化，是数据的问题，还是，嘿，您包含了一个新的Python依赖，对吧？
这种改变了某些东西，对吧？例如，我们还内省了运行环境。因此，我们可以在包级别了解其中的内容。
因此，当我们进行模型生产时，我们尽量紧密地复制这些依赖项，以确保至少从软件工程的角度来看，一切都应该按预期运行。
Piotr:所以听起来像是一个称为“模型打包”的解决方案。那么你把这些信封存放在哪里？我理解你有个框架信封，但你还有那些具有元数据的序列化模型的实例。你把它们存放在哪里？
Stefan:是的。我可以说非常基本，我们将它们存储在S3上，以结构化的方式存储，但是我们还将其与具有实际元数据和指针的数据库配对。因此，一些元数据会输出到数据库中，您可以用它进行查询。
我们有一个完整的系统，您可以为每个信封指定标签。这样，您就可以根据包含在模型中的标签结构进行层次化组织或查询。因此，它只是行中的一个字段。
有一个字段只是指向，嘿，这是序列化工件所在的位置。所以是的，非常基本，没有太复杂的东西。
如何决定要构建哪个功能？
Aurimas:好的，Stefan，听起来在平台团队中一切都很自然。团队需要部署模型，对吧？所以你创建了信封框架，然后团队在定义分区代码时遇到困难，你创建了Hamilton。
是否有任何情况下，有人提出了一个需要构建的疯狂建议，而你却说不行？你是如何决定要构建哪些功能以及拒绝哪些功能的？
Stefan:是的。我在博客上写了一些关于在Stitch Fix构建平台过程中的一些经验。通常情况下，我们拒绝的请求来自于那些对某些事情非常复杂的人，而且他们也在进行一些投机的尝试。
他们希望能够做一些事情，但它还没有进入生产阶段，它试图在改进某些东西的基础上进行一些投机的尝试，但业务价值尚未确定。
除非这是一个业务优先事项，我们知道这是必须完成的方向，否则，通常情况下，这些请求来自于那些认为自己在工程角度上非常有能力的人。
所以我们就像，好吧，你去弄清楚，如果行得通，我们再谈论所有权和接手的事情。所以，例如，我们有一个配置驱动的模型流水线 – 你可以把它想象成一些带有Python代码的YAML，在SQL中，我们使人们能够描述如何构建模型流水线。与Hamilton不同，它更像是一种宏观方式，所以我们一开始不想立即支持它，但它发展成为其他人想采用的方式，因此在能够管理和维护它的复杂性方面，我们进行了重构，使其更加通用、更广泛，对吧？
所以这就是我认为能够合理确定是否说“是”或“不是”的一种方式，首先，如果它不是业务优先级，很可能不值得你的时间，让他们证明它的可行性，然后如果成功了，假设你事先进行了对话，你可以谈论采用。所以，这不是你的负担。有时候人们确实会陷入其中。你只需意识到他们对它的依恋，如果它是他们的心血，你知道他们会如何把它移交给你。这是需要考虑的事情。
但是除此之外，我想一些人希望有TensorFlow支持 – TensorFlow特定的支持，但只有一个人在使用TensorFlow。他们说：“是的，你现在可以做些事情，我们可以添加一些东西”，但幸运的是，我们没有投入时间，因为他们尝试的项目没有成功，最后他们离开了。
所以，在这种情况下，很高兴我们没有在那里投入时间。所以，是的，很乐意深入探讨。
Piotr：听起来很像产品经理的角色，非常像那样。
Stefan：是的，在Stitch Fix，我们没有产品经理。组织中有一个项目经理。我的团队是我们自己的产品经理。这就是为什么我花了一些时间与人们交谈，与经理们交流，了解他们的痛点，但也了解从业务角度来看什么是有价值的，我们应该花时间在哪里。
Piotr：
我在 Neptune 上管理一个产品，这既是一件好事，也是一项具有挑战性的工作，因为你要与那些技术精通的人打交道，他们是工程师，他们可以编写代码，可以以抽象的方式思考。
很多时候，当你听到功能请求的第一个迭代时，实际上是一个解决方案。你听不到问题。我喜欢这个测试，也许其他机器学习平台团队可以从中学习。你将其投入生产了吗？
它是有效的吗，还是计划将其移至生产环境中的一天？作为第一个过滤器，我喜欢这个启发式方法。
Stefan：我是说，你勾起了很多回忆，嗯，有人说“你能做到这个吗？”那么问题是什么？是的，这实际上是你在使用平台的人提问时需要学会的第一反应，就是“实际问题是什么？”因为可能是他们找到了一把锤子，并且想要用这把特定的锤子来完成特定的任务。
例如，他们想要进行超参数优化。他们问的是，“你可以这样做吗？”然后我们退后一步，我们说，“嘿，我们实际上可以在一个稍微高一级的层面上来做，这样你就不必考虑工程化。”所以，在这种情况下，始终询问“你试图解决的实际问题是什么？”是非常重要的问题。
然后你还可以问，“这有什么商业价值？”这有多重要，等等，以真正了解如何设置优先级。
从团队那里获得支持
Piotr：所以我们了解了你如何处理数据科学家来寻求功能的情况。那么沟通的第二部分是如何工作的，你是如何鼓励或使团队跟随你开发的，你向他们提出的建议是如何设定标准的？
Stefan：是的，理想情况下，对于我们的任何倡议，我们找到了一个特定的使用案例，一个狭窄的使用案例，以及一个需要它并且愿意采用它并在开发时使用它的团队。没有比开发一个没有人使用的东西更糟糕的了。那看起来很糟糕，经理们会问，“谁在用它？”
- 所以，首先要确保你有一个明确的用例，并且有需要并愿意与你合作的人。只有在这方面取得成功后，才开始考虑扩大范围。因为你可以将它们用作用例和故事。这就是理想情况下，你每周或每两周进行一次分享的地方。所以我们有一个叫做“算法”的东西，我可以说是饮料分钟，基本上你可以站起来几分钟，谈谈事情。
- 所以是的，在Stitch Fix内部一定要积极推广开发工具，因为在那里，如果数据科学家不想使用我们的工具，他们是没有选择的，如果他们想要自己编写工程代码。所以我们一定要通过这样的方式来解决你的困扰。你不必考虑这些问题。这就是我们所构建的。这是有人在使用它，他们正是在运用它来解决这个特定的用例。因此，意识是一个很重要的问题，对吧？你必须确保人们知道这个解决方案，知道它是一个选择。
- 文档，我们实际上有一个小工具，可以很容易地编写Sphinx文档。所以这是我们确保每种模型封套和其他工具的一种方式，我们建立了一个Sphinx文档设置，这样如果人们想要，我们可以指向文档，试图展示片段和内容。
- 另一个是我们的经验中，我们添加了的遥测。这个平台的一个好处是我们可以添加任意多的遥测。所以实际上，当每个人都在使用某个东西时，如果发生错误，我们会收到Slack警报。所以我们会试着跟进并询问他们，问他们在做什么？
也许试着与他们互动，确保他们在正确地进行事情。你在开源项目中无法做到这一点。不幸的是，这样做会有些侵入性。但除此之外，大多数人只愿意每个季度采用一两次这样的东西。
所以，你需要将事情放在正确的位置，正确的时间，以便他们能够在有机会开始并克服障碍时开始。因此，需要找到文档示例和方法，使这个过程尽可能地简单。
您是如何组建创建该平台的团队的？
Aurimas：好的，那么你是从ML平台的一开始就加入Stitch Fix的吗？还是说它是从一开始就逐步发展起来的？
Stefan：是的，当我到那里的时候，它是一个非常基础的小团队。在我在那里的六年里，它发展得相当大。
Aurimas：你知道这是如何创建的吗？为什么决定在正确的时间成立一个平台团队？
Stefan：不，我不知道答案，但那两个人是主要负责的人，Eric Colson和Jeff Magnusson。
Jeff Magnusson在一篇非常有名的文章中写到，工程师不应该编写ETL。如果你搜索一下，你会看到这篇文章描述了Stitch Fix的理念，我们希望创建全栈数据科学家，如果他们可以做到端到端的一切，他们可以更快更好地进行工作。
但是，根据这个论点，你无法雇佣所有具备全栈能力的人，你知道，数据科学方面的技能。因此，在这种情况下，他们的愿景实际上是需要一个平台团队来构建工具和资源，对吧？
我认为，我不知道你有什么数据，但是我对机器学习项目的初步了解通常是，工程师和数据科学家的比例是1：1或1：2。但是在Stitch Fix，如果你只考虑专注于帮助流水线的工程和平台团队，那么比例是安全的。
比例更接近于1：10。所以就像工程师与数据科学家的杠杆比例一样，我认为这确实有点，你必须了解平台现在的作用，然后还必须知道如何进行沟通。
所以根据你之前的问题，Piotr，关于如何衡量平台团队的有效性，这种情况下，他们进行了怎样的对话以获得人数，所以你可能确实需要一点帮助，或者至少需要在沟通方面进行思考，就像：嘿，是的，这个团队将是次要的，因为我们不会直接影响和生产功能，但如果我们能使那些正在执行的人更有效率，那么这将是一项值得投资的事情。
Aurimas：当你说工程师和数据科学家时，你是否认为机器学习工程师是一位工程师，还是他或她更像一位数据科学家？
Stefan：是的，我将他们计算在内，数据科学家和机器学习工程师之间的区别，可以说，一个可能会做更多在线方面的事情，对吧？所以他们需要进行更多的工程工作。但我认为差距很小。对我来说，实际上，我的希望是，当人们使用Hamilton时，我们能够使他们做更多的事情，他们实际上可以从数据科学家转变为机器学习工程师。
否则，我会将他们归为数据科学家的范畴。所以我所讨论的是具体的平台工程。
Aurimas：好的。在Stitch Fix的这几年里，你是否看到团队结构发生了变化？你是否改变了由数据科学家和工程师组成的端到端机器学习团队的构成？
Stefan：这实际上取决于他们的问题，因为预测团队更多是离线批处理。这样做得很好，他们不必从在线的角度来了解、工程化过于复杂的东西。
但个性化团队更多地关注SLA和客户面向的事务，他们确实开始雇用一些具有更多经验的人，因为他们确实需要帮助，就像我们还没有着手解决这个问题，但通过DAGWorks，我们试图为构建和维护模型流水线提供一个更低的软件工程门槛。
我不会说推荐系统和在线推荐的生成。没有什么能够简化这个过程，所以在这种情况下，你仍然需要更强的工程技能，以确保随着时间的推移，如果你在管理许多相互通信的微服务，或者在管理SLA，你确实需要一些更多的工程知识来做得好。
因此，在这种情况下，如果有的话，这就是开始合并的分歧。任何做更多客户面向SLA相关工作的人在软件工程方面要求更高，否则每个人都可以成为具有较低软件工程技能的优秀建模者。
Aurimas：对于那些不一定是技术性角色的职位，你是否将其嵌入到这些机器学习团队中，比如项目经理或专业主题专家？还是只有纯粹的数据科学家？
Stefan：我的意思是，其中一部分落在了数据科学家团队的肩上，通过与组织内的某人合作，可以说，在这两者之间，共同管理某个产品，所以我们没有明确的产品经理角色。
我认为在Stitch Fix开始增长的时候，项目管理真的是一个痛点，就像：我们如何引入它，由谁来做？所以这真的取决于规模。
产品是你正在做的事情，它触及到的事情，就像你是否开始需要它。但是，当我还在那里的时候，组织确实在思考如何构建更高效、更有效运行的结构。以及如何准确定义交付机器学习团队的范围。
如果你正在与库存团队合作，他们管理仓库的库存，例如，团队的结构是如何被塑造的，当然还在不断发展。当我在那里的时候，它们是非常独立的。但他们一起工作，但他们有不同的经理。
彼此向对方汇报，但他们在同一个计划上工作。所以，当我们规模较小时，工作得很好。现在你得问现在那里的人，就像，发生了什么，否则，我会说这取决于公司的规模和机器学习计划的重要性。
模型监控和生产
Piotr：我想问一下模型的监控和生产，使其实时运行。因为听起来与软件领域非常相似，对吗？数据科学家和软件工程师在一起。ML平台团队可以成为这个DevOps团队。
那些确保它实时运行的人呢？它是如何工作的？
Stefan：我们提供了免费的模型封套部署。这意味着数据科学家唯一需要负责的就是模型。
我们试图以一种方式来组织事物，就像，嘿，坏模型不应该进入生产环境，因为我们有足够的CI验证步骤，模型不应该成为问题。
所以唯一可能在生产中出现问题的就是基础设施的变化，在这种情况下，数据科学家不负责也无能为力。
但是除此之外，如果他们负责，那么这就是我们团队的责任。
我想我们接到了超过50个服务的电话，因为我们部署了这么多模型。我们是前线。因为，你知道的，大多数情况下，如果出了问题，很可能是与基础设施有关。
我们是第一接触点，但他们也在呼叫链中。实际上，嗯，我来解释一下。一旦任何模型部署完成，我们都会同时在呼叫中，只是为了确保它部署并运行，但然后我们会稍微分叉，比如，好吧，我们会做第一次升级，因为如果是基础设施的问题，你无能为力，但是否则，你需要在呼叫中，因为如果模型实际上产生了一些奇怪的预测，我们无法修复，那么你就是负责调试和诊断的人。
Piotr：听起来像是与数据有关的事情，对吗？数据漂移。
Stefan：是的，数据漂移，上游的某些东西等等。这就是更好的模型可观察性和数据可观察性的帮助之处。所以我们试图捕获和使用那些。
有很多不同的方法，但我们设置的好处是，我们处于一个很好的位置，能够在训练时捕捉输入，但是因为我们控制了Web服务以及内部情况，我们实际上可以记录和输出进来的东西。
所以我们有一些流程来构建和调和。所以如果你想问一个问题，是否有训练服务SKU？作为数据科学家或机器学习工程师，你不需要自己构建它，你只需要打开日志记录到你的服务中。
然后我们有一些其他的配置，但我们提供了一种方式，你可以将其推送到一个可观察性解决方案中，然后比较生产特征和训练特征。
Piotr：听起来你为你的数据科学家提供了一个非常舒适的界面。
Stefan：是的，我的意思是，这就是我的想法。事实上，这也是我试图在DAGWorks中复制的东西，提供抽象的方法，让任何人都能拥有我们在Stitch Fix建立的那种体验。
但是是的，数据科学家讨厌迁移。所以我们专注于API方面的原因之一是，如果我们想要从平台的角度改变某些东西，我们不会对数据科学家说，嘿，你需要迁移，对吧？所以这也是为什么我们如此重视这些API边界的原因之一，这样我们的生活会更简单，他们的生活也会更简单。
Piotr：那你可以分享一下在Stitch Fix工作期间，数据科学家和ML平台团队的规模有多大吗？
Stefan: 我想它曾经达到了巅峰，大约有150个数据科学家和平台团队的总人数。
Piotr: 那个团队是1比10的比例吗？
Stefan: 所以我们有一个平台团队，大约是1比4或者1比5的比例，因为我们有一个完整的平台团队来帮助UI，还有一个完整的平台团队专注于微服务和在线架构，对吧？所以不涉及流水线相关的内容。
是的，所以从工程角度来看，需要更多的工作来整合API、机器学习和其他业务内容。所以实际比例是1比4或者1比5，但是这是因为有一个大的平台团队在帮助构建平台，以帮助整合、调试、机器学习推荐等等。
Aurimas: 但是机器学习团队的规模是多少？一个团队里可能没有数百人吧？
Stefan: 是的，它们有所不同，大约是8到10个人。有些团队规模很大，有些团队只有五个人。
所以实际上，这取决于垂直领域和他们在业务方面的帮助对象。你可以大致上根据模型来划分。比如，我们在英国有不同的行政区域，在美国也有，然后还有不同的业务线，比如男装、女装、儿童装等等。
你可以想象每个组合上都有数据科学家，所以它实际上取决于在哪里需要以及不需要，但是大致上每个团队的规模在3到8到10人之间。
如何成为有价值的MLOps工程师？
Piotr: 关于如何成为数据科学家有很多信息和内容。但是关于如何成为MLOps工程师或者ML平台团队的一员的信息要少一个数量级。
你认为一个人需要具备哪些条件才能成为ML平台团队的有价值的成员？典型的ML平台团队的构成是什么样的？需要什么类型的人？
Stefan: 我认为你需要对人们试图做什么有同理心。所以我认为如果你有一些机器学习和建模的经验，当有人向你提出问题时，你可以询问他们想要做什么。
在高层次上，你对可以做的事情有一些了解。然后，如果你自己构建过东西并且经历过一些痛苦，这肯定有助于增加同理心。所以如果你之前是一个运营人员，你就知道我的经历是怎样的。
我建立了模型，我意识到我不太喜欢构建实际的模型，而是喜欢围绕它们建立基础设施，以确保人们可以高效地进行工作。所以，具备一定的技能可能与六年前有所不同，因为现在有了更多的成熟度和开源软件在供应商市场上。所以，MLOps有一个梗或者说是一个模式，就是VendorOps。
如果你要集成和引入不是自己内部构建的解决方案，那么你需要更多了解抽象和你想要控制的内容与紧密集成的内容。
同理心，具备一些背景以及你构建的软件工程技能，你可以将它们作为一个双层API。你理想情况下不应该直接暴露供应商的API，你应该在它周围包裹一层，这样你就可以控制一些方面。这样，你为提供平台的人们不需要做出决策。
例如，存储文件的位置应该是你作为平台负责的事情，即使这可能是供应商API所要求提供的内容，你可以做出决定。
这就是我要说的地方，如果你有管理和维护供应商API的经验，下一次你会更擅长。但是除此之外，是的。
如果你还有DevOps背景，或者自己构建过部署工具，或者在小公司工作过，那么你也能够理解生产环境的影响以及可用的工具集，以及你可以与之集成的内容。
因为你可以通过Datadog在服务部署方面得到非常合理的方式，对吧？
但是如果你真的想要理解模型的内部结构，为什么训练和服务很重要，对吧？那么看过它的运作，具备一些同理心来理解为什么需要这样做，我认为这会让你更好地做出宏观决策，因为你能够全局了解事物的端到端的大局观，这样能够帮助你做出更好的微观决策。
MLOps是DevOps的延伸，而不是分叉 – 作为MLOps创业公司的CEO，我对MLOps论文的看法
ML平台团队的未来之路
Piotr：好的，明白了。斯特凡，我有一个问题，因为我觉得在我们想要讨论的话题上，我们做得很好。我看着议程表。有什么我们应该问的吗，或者你有什么想说的吗？
斯特凡：好问题。
让我看看，我也在看议程。是的，我的意思是，关于未来的事情，对我来说，我认为Stitch Fix试图使数据科学家能够全流程操作。
我理解的方式是，如果你能够使数据从业者能够更多地进行自助服务、更多地进行全流程工作，他们可以将业务领域的上下文结合起来，创建一个完整的迭代过程。
因此，他们可以更好地了解价值与否，而不是更传统的人们仍然处于这种交接模式中。所以在这种情况下，你设计工具是为了谁而设计的，是为了工程师，还是为了机器学习工程师？
这是否意味着数据科学家必须成为软件工程师才能够使用你的解决方案自助服务？另一种极端是低代码、无代码，但我认为那样有些限制。大多数这些解决方案都是SQL或某种自定义DSL，我认为它们不太适合于获取知识或学习技能，并将其应用于另一份工作。这并不一定意味着只有在使用相同的工具时才有效，对吧？
所以，我的观点是，如果我们可以简化所需的软件工程抽象，我们就可以更好地实现这种自助服务范式，也可以更容易地管理平台团队，这就是为什么我说，如果你选择一个供应商，你可以简化API，使其更易于数据科学家使用，对吧？
所以我的论点是，如果我们可以降低软件工程的门槛，实现更多的自助服务，你就可以提供更多的价值，因为同一个人可以完成更多的工作。
但是如果构建得当，你也可以更容易地在时间上维护项目，这样当有人离开时，就不会出现噩梦般的继承问题，而这正是在Stitch Fix的情况，我们使得将模型投入生产变得非常容易，但由于业务发展得如此迅速以及其他原因，团队花费了一半的时间来维护机器学习流水线。
所以我认为，你知道的，这也是一些原因，因为我们使他们能够做更多工程方面的事情，对吧？
构建稳健工具所需的技能
斯特凡：我很好奇，你们认为在实现自助服务、模型构建和机器学习流水线时，需要具备什么样的软件工程技能水平，最终的目标应该是什么。
Aurimas：你具体是什么意思？
Stefan：我的意思是，如果自助服务是未来的发展方向。如果是这样的话，那么需要怎样的自我工程技能呢？
Aurimas：至少从我对未来的看法来说，我认为自助服务是未来的趋势，首先这一点毫无疑问，但根据我的经验，目前并没有平台能够让数据科学家自己从头到尾地进行工作。
根据我的经验，我发现数据科学家和平台之间总是需要一个机器学习工程师作为中间人，这一点很遗憾。但是肯定应该设定一个目标，即具备当前数据科学家技能的人应该能够从头到尾地完成工作。这是我的观点。
Piotr：我认为这是一场竞赛。六年前曾经困难的事情如今变得容易，但与此同时，技术变得更加复杂。
例如，我们有很多优秀的基础模型和编码器。我们正在构建的模型越来越依赖于其他服务。这种抽象将不再是数据集、预处理、训练、后处理、模型打包和独立的网络服务。
它越来越依赖于外部服务。因此，我认为目标是让自助服务更加友好，但是随着这个领域技术和方法的发展，这将是一场竞赛。我们解决了一些问题，但同时引入了另一种复杂性，特别是当你尝试做一些最前沿的工作时，你不会考虑一开始就让事情变得简单易用，而是考虑你是否能够做到。
因此，新技术通常不太友好和易于使用。一旦它们变得更常见，我们就会使它们更易于使用。
Stefan：我想说，或者至少跳过他所说的，在设计API时我常用的一种技术就是在实际实现之前先设计API。
我认为Piotr所说的对工程师来说非常容易。我亲身经历过这个问题，就是从下往上构建。就像是，我想构建这个功能，然后我想展示人们如何使用它。
我实际上认为将其倒过来，首先考虑用户希望从API中获得的体验，然后再深入细节，这真的是一种非常有启发性的经验，可以帮助你简化你能做的事情。因为从下往上很容易考虑到所有这些问题，因为你想让任何人都能够做任何事情，这是一个工程师的天性。
但是当你想要简化事物时，你真的需要问自己一个问题，那就是80-20原则是什么？这就是Python的理念，即电池包含在内，对吧？
那么你如何才能让这个过程对大多数希望使用它的人尽可能简单易用呢？
最后的话
Aurimas：同意，同意，实际上我觉得我们的时间差不多用完了。所以或许最后一个问题，也许Stefan，你想给我们的听众留下一些想法，或许你想宣传一些东西。现在是合适的时候。
Stefan：是的。
如果你担心继承同事的工作，或者你是新来的人加入公司，对于你要继承的流程或事物感到害怕，那我想说我很愿意听到你的想法。Hamilton，我想说，虽然我们还是一个相当早期的开源项目，但非常容易上手。我们有一个路线图，会根据各种意见和建议来进行调整和完善。所以如果你想要一种简单的方式来维护和团队协作你的模型流程，因为个人构建模型，但团队拥有它们。
我认为这需要一种不同的技能集和纪律来做好。所以来看看Hamilton，告诉我们你的想法。然后从DAGWorks平台上，在录制这个视频的时候，我们还处于当前的、目前的、封闭的测试版阶段。我们有一个等待列表，如果你有兴趣尝试这个平台，可以填写一个早期访问表单。
否则，搜索Hamilton，在GitHub上给我们一个星星。让我知道你的体验。我们希望在你的机器学习ETL或者pipeline不断增长的时候，你的维护负担不会增加。
谢谢。
Aurimas：所以，感谢你们今天和我们在一起，真的有很好的对话。谢谢。
Stefan：谢谢你们邀请我，Piotr和Aurimas。
