在这个“真实世界的MLOps示例”系列的第二部分中，Brainly的机器学习工程师Paweł Pęczek将带您了解Brainly视觉搜索团队的端到端机器学习运营（MLOps）流程。由于要在MLOps中取得成功不仅需要技术和流程，他还将分享以下细节：
- 1. Brainly的机器学习用例，
- 2. MLOps文化，
- 3. 团队结构，
- 4. 以及Brainly用于向客户提供AI服务的技术，
享受这篇文章吧！
免责声明：本文重点介绍了Brainly的大部分生产ML团队的设置。
公司简介
Brainly是全球领先的学习平台，拥有最广泛的所有学科和年级的知识库。数亿名学生、家长和教师每月都使用Brainly，因为它是帮助他们理解和学习更快的有效途径。他们的学习者来自35多个国家。
Brainly进行MLOps的动机
要了解Brainly朝着MLOps的发展历程，您需要了解Brainly采用人工智能和机器学习技术的动机。在撰写本文时，Brainly在全球拥有数亿名月活跃用户。凭借如此规模的月活跃用户和他们所代表的用例数量，机器学习应用可以极大地惠及Brainly的教育资源用户，提高他们的学习能力和路径。
Brainly的核心产品是社区问答平台，用户可以通过以下方式提问任何学科的问题：
- 打字输入
- 拍照问题
- 口述问题
一旦用户输入他们的问题，产品将提供带有逐步解释的答案。如果答案尚不存在于知识库中，Brainly会将问题发送给社区成员之一进行回答。
“我们在Brainly构建基于AI的服务，以提升教育功能并将其提升到更高水平 – 这是我们在利用与AI相关研究的巨大增长背后的主要原因。”
— Paweł Pęczek, Brainly的机器学习工程师
Brainly的AI和技术团队利用机器学习为学习者提供个性化的实时学习帮助和世界上最好的教育产品。Brainly的AI/ML团队的目标是：
- 从反应性干预系统转向预测性干预系统，个性化用户体验
- 提前解决用户未来的教育难题
- 使学生在教育路径上更加成功
您可以在这篇文章中了解更多关于Brainly的ML故事。
Brainly的机器学习用例
Brainly的AI部门旨在为用户构建预测性干预系统。这样的系统使他们致力于在以下领域开展多个用例的工作：
- 内容：提取内容属性（例如质量属性）和元数据增强（例如课程资源匹配）
- 用户：增强用户的学习档案
- 视觉搜索：解析图像并将相机拍摄的照片转换为可回答的查询
- 课程：分析用户会话和学习模式以构建推荐系统
对于每个团队在这些领域上的MLOps实践进行详细阐述是具有挑战性的，因此在本文中，您将了解到Brainly视觉搜索AI团队如何进行真实世界的MLOps。
观看这个视频了解Brainly内容AI团队的MLOps。
“如果您思考Brainly服务的用户如何构建他们的搜索查询，您可能会发现他们倾向于使用易于使用的输入方法。这不仅包括视觉搜索，还包括特殊类型的信号的语音和文本搜索，可以通过AI进行探索。”
— Paweł Pęczek, Brainly的机器学习工程师
MLOps团队结构
Brainly的技术团队分为产品团队和基础设施团队。基础设施团队专注于技术，并提供其他团队将要适应和使用的工具来完成他们的主要交付物。
除了团队之外，他们还有部门。DevOps和自动化Ops部门隶属于基础设施团队。AI/ML团队属于基础设施团队下的服务部门，与AI相关，一些AI团队致力于为客户提供基于ML的解决方案。
在AI部门的基础上，是ML基础设施团队，他们为AI团队提供标准化的解决方案，可以进行适应。ML基础设施团队通过提供模板化的基础设施即代码解决方案，使AI团队可以轻松创建训练流水线，从而使他们的工作流程更加简单，每个团队都可以在自己的环境中自主部署。
多个AI团队还参与了ML基础设施的项目。这类似于一个内部开源系统，每个人都在维护自己负责的工具。
“这种团队安排，我们有一个产品团队，一个基础设施团队，分为各个部门，并且内部团队负责特定的技术模块以供产品使用，对于大型科技公司来说是相当标准的。”
— Paweł Pęczek，Brainly的机器学习工程师
Brainly的MLOps文化
Brainly的MLOps文化有两个主要理念：
-
1
优先速度 -
2
培养合作、沟通和信任
优先速度
“我们的终极目标是为团队提供所有必要的基础设施相关组件，并且这些组件应该是可重用的。我们的终极目标是为团队提供一种方式来探索和实验，一旦他们发现有趣的东西，尽快将其推到客户的用例中。”
— Paweł Pęczek，Brainly的机器学习工程师
MLOps生态系统的目标是尽快移动，并随着时间的推移学会更快地构建自动化组件。Brainly在AI部门的基础设施团队下有共同的倡议。这些倡议使团队能够通过专注于主要交付物来更快地成长。
“总的来说，我们尽可能地快，将模型暴露给真实世界的流量。如果没有这个，反馈循环将会太长，对我们的工作流程是不利的。即使从团队的角度来看，我们通常希望能够立即获得反馈，越快越好。否则，改进模型的这个迭代过程将会花费太多时间。”
— Paweł Pęczek，Brainly的机器学习工程师
优先速度的影响：团队将一个模型部署到生产环境需要多长时间？
在早期阶段，当他们刚开始标准化倡议时，每个团队都有各种内部标准和工作流程，这导致部署一个模型到生产环境需要几个月的时间。随着工作流程在团队之间的标准化和数据形状的正确性，大多数团队通常在几周内准备好部署他们的模型并将其嵌入为一个服务。当然，如果研究进展顺利的话。
“在最初阶段，花费最多时间的两个阶段是收集有意义的数据和标记数据。如果研究完全是新的，并且没有其他项目可以得出结论或基于理解，可行性研究和研究可能需要更长的时间。
假设团队已经拥有了数据并且可以立即开始标记。在这种情况下，设置实验过程和构建ML流水线非常顺利和高效，几乎是即时完成的。他们可以为该项目产生类似的代码结构。维护也非常容易。”
— Paweł Pęczek，Brainly的机器学习工程师
团队面临的另一个痛点是结构化终端接口，以便客户能够快速采用解决方案。花费时间讨论并达成最佳接口的共识，这是所有领域的常见痛点，不仅仅是机器学习。他们必须培养一种有效的合作和沟通的文化。
培养合作、沟通和信任
在公开AI相关服务后，客户必须了解如何正确使用和集成它们。这带来了人际挑战，鼓励AI/ML团队与客户建立良好的关系，通过告诉人们如何使用解决方案来支持模型，而不仅仅是公开没有文档或说明如何使用的终端。
Brainly迈向MLOps的旅程
自从Brainly进行机器学习的早期，基础设施和工程团队就鼓励数据科学家和机器学习工程师在项目和代码结构上使用最佳实践。
通过这样做，他们可以快速入门，并且将来不需要支付大量的技术债务。随着“成熟度级别”蓝图的建立，这些实践不断发展。
“我们在项目开发的各个阶段之间有相当有组织的过渡，我们称这些阶段为‘成熟度级别’。”
— Paweł Pęczek, Brainly的机器学习工程师
他们从一开始就实行的另一项实践是让AI/ML团队轻松开始纯粹的实验。在这个级别上，基础设施团队尽量不对研究人员施加太多限制，以便他们专注于开展研究、开发模型和交付。
早期设置实验跟踪是最佳实践
“我们从实验过程的开始就启用了实验跟踪，因为我们相信这是显著有助于未来研究可重现性的关键因素。”
— Paweł Pęczek, Brainly的机器学习工程师
团队会为数据科学家设置研究模板，以启动他们的代码库，用于特殊用例。大多数情况下，这些模板都包含与他们的实验跟踪工具neptune.ai集成的所有模块。
他们通过代码与neptune.ai无缝集成，使所有东西在发送给neptune.ai的报告方面都有良好的结构，团队可以在训练前后进行实验的审查和比较。
Brainly的MLOps成熟度级别
MLOps级别0：演示应用程序
当实验产生有希望的结果时，他们会立即将模型部署给内部客户。在这个阶段，他们会在运行的实验之上添加自动化和结构化的工程代码，以公开MVP。
“我们正在使用我们已有的内部自动化工具，使展示我们的模型终端变得容易。我们这样做是为了让客户可以使用这个服务，公开模型，让他们决定是否适用于他们。在内部，我们称这个服务为‘演示应用程序’。”
— Paweł Pęczek, Brainly的机器学习工程师
在他们的工作流程的最初几次迭代中，团队制作了一个内部演示应用程序，客户可以通过代码或Web用户界面连接到该应用程序，以查看使用模型可能得到的结果。它不是在生产环境中完全部署。
“基于演示应用程序的结果，我们的客户和利益相关者决定是否将特定用例推进到更高级别的成熟度。在做出决策时，团队应该部署第一个成熟或广泛的解决方案版本，称为‘发布一’。
除了我们已有的内容之外，我们还组装了自动化的训练流水线，以重复训练我们的模型并无缝执行任务。”
— Paweł Pęczek, Brainly的机器学习工程师
MLOps级别1：生产部署与训练流水线
随着实验和部署的工作流程变得越来越好，并为每个团队成为标准，他们将注意力转向确保在新数据到达时有一个良好的模型重新训练方法。
用例最终发展，随着新数据量的激增，团队转向以数据为中心的AI方法，专注于收集数据集并不断将其推送到流水线中，而不是试图使模型完美或进行过多的研究。
因为速度对他们的文化很重要，他们希望使用自动化工具将完整的部署发送到生产环境中。使用这些工具，他们可以做到：
- 触发以模型为服务的流水线
- 验证模型的质量是否与训练过程中所看到的没有下降
“我们将我们的服务暴露给生产环境，并启用监控，以确保随着时间的推移，我们可以观察到发生了什么。这是我们称之为MLOps成熟度一级（1）的东西。”
— Paweł Pęczek，Brainly的机器学习工程师
在这个级别上工作的目标是确保模型具有最高的质量，并消除在开发过程中可能出现的任何问题。他们还需要监控并观察数据分布的变化（数据漂移，概念漂移等）当服务运行时。
MLOps级别2：关闭主动学习循环
MLOps第二级（2）是他们需要达到的下一个成熟度水平。在这个级别上，如果主动学习循环被证明具有良好的投资回报率（ROI）或与他们的关键绩效指标和利益相关的其他原因，他们将将模型提升到更高级别。
他们将不断通过自动从生产环境中提取数据、清理数据并在需要时将其发送到标注服务来创建更大更好的数据集。这些数据集将进入他们已经建立的训练流水线。他们还将实施更广泛的监控，每天发送更好的报告，以确保一切井然有序。
视觉搜索团队的机器学习工作流程
以下是团队典型机器学习工作流程的高级概述：
- 首先，他们将原始数据从生产者（事件，应用中的用户操作等）导入到开发环境中
- 接下来，他们会操作数据，例如调制过滤器并将其预处理为所需格式
- 根据解决方案的发展情况，他们会为数据集进行标注，使用训练流水线训练模型，或将其保留为研究模型
“当我们的模型准备好后，我们通常会对其进行评估。一旦获得批准，我们就会启动自动部署流水线，并再次检查以确保模型质量良好，并查看服务是否保证了训练过程中测得的相同模型质量。如果是这样，我们就简单地部署服务并监控以查看是否有任何不符合预期的情况。我们验证问题并采取措施改进。”
“我们希望将尽可能多的用例推进到这个最终成熟度水平，我们在其中关闭了主动学习循环，并观察一切是否良好。”
— Paweł Pęczek，Brainly的机器学习工程师
当然，关闭工作流程的循环需要付出努力和时间。此外，某些用例将永远无法达到该成熟度水平，因为并非每个想法都是有效的并且值得追求到那个水平。
Brainly视觉搜索团队的MLOps基础架构和工具堆栈
团队的MLOps基础架构和工具堆栈分为不同的组件，所有这些组件都有助于帮助他们快速交付新的服务：
-
1
数据 -
2
实验和模型开发 -
3
模型测试和验证 -
4
模型部署 -
5
持续集成和交付 -
6
监控
下图显示了不同组件和团队使用的工具的概述：
让我们深入了解每个组件。
Brainly视觉搜索团队的数据基础架构和工具堆栈
“我们的数据堆栈因项目而异。在计算机视觉团队中，我们尽量使用最简单的解决方案。我们只是将数据存储在S3中，这对我们来说就足够了，再加上禁止未经授权的用户在数据集创建过程中对数据集进行修改的权限。”
— Paweł Pęczek，Brainly的机器学习工程师
团队利用自动化流程提取原始数据并以他们希望的格式进行处理，他们尽量在数据处理方面保持通用性，而不使用复杂的工具。他们在Automation Ops团队已经开发的基础上进行构建，以与AWS技术栈集成。
团队使用AWS Batch和Step Functions来运行批处理和编排。这些简单的解决方案更注重Brainly所擅长的功能，而不是服务的工作方式。
“我们目前的方法能完成工作，但我不会说它非常详尽或复杂。我知道其他团队在数据工程和ETL处理工具方面的使用比我们更多，与他们相比，我们使用更简单直接的解决方案来筛选和处理我们的数据集。”
— Paweł Pęczek，Brainly的机器学习工程师
Brainly视觉搜索团队的实验基础设施和工具堆栈
“我们尽量让实验保持简单。我们在EC2实例和AWS SageMaker上以最基本的配置进行训练。对于生产流程，我们会添加更多步骤，但不会太多，以免过度使用SageMaker。”
— Paweł Pęczek，Brainly的机器学习工程师
目标是尽量减少数据科学家在EC2机器或SageMaker上运行实验的复杂性，使工作流程更高效。除了neptune.ai跟踪实验之外，在基础设施上没有太多工具。
团队使用标准技术堆栈，如训练模型的库，以及快速有效地处理数据集的简单而广为人知的方法。他们将这些库组合起来，在EC2机器或SageMaker上运行，并在neptune.ai上报告实验指标。
“我们更关注科学过程的样子，而不是繁琐的工具。在未来，我们可能会考虑改进我们的实验过程，使其更顺畅、更简洁等。目前，我们很满意，并且已经构建了一些解决方案，在SageMaker上运行训练任务，或者在EC2机器上轻松运行相同的代码。”
— Paweł Pęczek，Brainly的机器学习工程师
他们简化了实验工作流程，使他们的数据科学家和研究人员不必处理太多工程工作。考虑到复杂度较低，这对他们来说效果出奇地好。
“我们也不想研究我们内部的模型架构。如果有特殊情况，没有严格要求不这样做。一般情况下，我们使用来自我们所从事领域（语音、文本和视觉）的标准架构——ConvNets和基于Transformer的架构。”
“我们对任何一种类型的架构都不过分痴迷。我们试图进行实验，并使用在特定环境中表现最佳的方法。”
— Paweł Pęczek，Brainly的机器学习工程师
模型开发框架和库
计算机视觉团队主要使用PyTorch进行模型开发，但并非一成不变。如果模型开发库很好，团队能够使用它来训练和部署模型，他们可以使用它。
“我们不强制团队使用实验框架。如果有人想使用TensorFlow，他们可以使用；如果有人想利用PyTorch，也是可以的。显然，在特定团队内部有内部协议；否则，每天进行协作将会很混乱。”
— Paweł Pęczek，Brainly的机器学习工程师
Brainly视觉搜索团队的部署基础设施和工具堆栈
团队使用诸如Flask和其他简单解决方案以及TorchServe之类的推理服务器等标准部署工具。
“我们使用Automation Ops为我们提供的工具。我们接收模型并实施用于在EKS上提供标准解决方案。从我们的角度来看，鉴于现有的自动化工具，这更容易。”
— Paweł Pęczek，Brainly的机器学习工程师
他们在Amazon EKS上使用不同的策略进行部署。特别是，如果正确设置了测试、准备就绪和活动探针，他们可以避免在出现问题时进行部署。他们使用简单的部署策略，但随着需要的出现，他们也在考虑其他更复杂的策略。
Brainly视觉搜索团队的持续集成和交付工具堆栈
“我们在自动化和构建流水线中广泛使用CI/CD。我们有一些领域，在那里我们广泛利用AWS的CI/CD流水线工具栈。”
— Paweł Pęczek, Brainly的机器学习工程师
团队使用Automation Ops团队已经提供的解决方案来进行CI/CD。他们可以通过几行Terraform代码向实验代码中添加CI和CD。当涉及到训练的流水线时，他们使用Terraform模块来创建CI/CD，这将初始化流水线，对其进行测试，并将其部署到SageMaker（流水线）中，如果测试通过。
他们在GitHub存储库中拥有生产和训练代码库。每次修改代码时，流水线的定义都会发生变化。它会重新构建Docker镜像，并按照定义的顺序运行流水线中的步骤。一切都会被刷新，任何人都可以针对新的数据集运行训练。
一旦模型获得批准，CI/CD流水线会拦截模型注册表中的信号，并开始模型部署过程。集成测试会将保留数据集通过预测服务，以查看度量指标是否与评估阶段测量的指标相匹配。
如果测试通过，他们将知道没有由于错误的输入标准化或类似的错误而出现问题。如果一切都正常，他们将将服务推送到生产环境。
“如果AWS提供了合理的解决方案，我们通常不会尝试使用广泛的第三方解决方案，特别是在我们的Automation Ops团队提供了我们可以使用的模块的情况下。”
— Paweł Pęczek, Brainly的机器学习工程师
CI/CD流水线的模型测试和批准
“我们在训练之后测试我们的模型并验证度量指标，当涉及到纯工程时，我们确保一切都正常工作。我们使用测试集或保留数据集将它们推送到服务中，并检查结果是否与之前相同。”
— Paweł Pęczek, Brainly的机器学习工程师
AI/ML团队负责维护一组健康的测试，确保解决方案按预期工作。对于其他团队，他们可能会以不同的方式测试ML模型，特别是在表格型ML用例中，通过对数据的子群体进行测试。
“当数据科学家和机器学习工程师，特别是负责交付项目功能测试时，这是一种健康的情况。他们不需要依赖任何其他人或事物，不会有争论或分歧。他们只需要正确地完成工作并向他人展示它按预期工作。”
对我们来说，在所有流水线中实现完全的测试标准化可能很困难，但相似的流水线具有相似的测试用例。
— Paweł Pęczek, Brainly的机器学习工程师
他们用于测试代码的工具也很简单，他们使用PyTest进行单元测试和集成测试以及更复杂的测试。
“模型批准方法取决于用例。我相信有些用例已经非常成熟，团队可以商定自动批准，在达到一定性能阈值之后。”
— Paweł Pęczek, Brainly的机器学习工程师
大部分时间，用户（机器学习工程师或数据科学家）必须密切关注模型验证过程。为了使流程更加一致，他们制作了一本维护手册，清楚说明需要检查和完成的工作，以确保模型符合特定的质量标准。
仅验证度量指标是不够的，还必须检查模型的其他定性特征。如果这些都完成了并且模型相对正常，他们将按下批准按钮，从那时起，自动化CI/CD流水线将被触发。
在生产环境中管理模型和流水线
对于不同的AI/ML团队来说，模型管理非常依赖上下文。例如，当计算机视觉团队处理需要标注的图像数据时，与处理表格数据的方式在生产环境中管理模型将会有所不同。
“我们会密切关注我们的服务工作方式的任何变化，我们的模型的预测效果如何，以及生产中记录的数据统计的变化。如果我们发现退化，我们将更详细地调查数据，如果发现问题，我们将收集和标注新的数据集。
将来，我们希望将更多的用例推向MLOps的第二级（2级），在那里与数据和监控相关的事情将自动完成。”
— Paweł Pęczek, Brainly的机器学习工程师
客户还会衡量他们的关键绩效指标，如果出现问题，团队可以收到通知。
模型监控和治理工具
为了获取服务性能指标，团队使用Grafana观察模型的统计数据，并在亚马逊弹性Kubernetes服务（Amazon EKS）上使用标准日志和监控解决方案。他们使用Prometheus添加有关服务工作方式的统计信息，并将其作为时间序列提供。这使得添加新的仪表板、监控它们并获得警报变得很容易。
自动化运维团队为监控服务提供捆绑包，这证明了团队决定将其堆栈尽可能简化以适应现有的工程生态系统。
“如果你已经有好的工具，那么不必过度投资于不同的工具。”
— Paweł Pęczek, Brainly的机器学习工程师
在模型治理方面，团队主要关注GDPR，并确保他们的数据在某种程度上经过审查。例如，他们不希望个人信息泄露给标注人员或糟糕的内容泄露给用户。他们会对内容进行过滤和审查，作为他们使用案例的一部分。
就是这样！如果您想了解更多关于Brainly技术生态系统的信息，请查阅他们的技术博客。
感谢Paweł Pęczek和Brainly团队与我们合作创建本文！