FMOps/LLMOps:运用生成式人工智能的操作和与MLOps的区别

FMOps/LLMOps Operations using generative artificial intelligence and the differences with MLOps

现今,我们的大多数客户都对大型语言模型(LLM)充满激情,并思考生成式人工智能如何改变他们的业务。然而,将这样的解决方案和模型引入常规业务操作并非易事。在本文中,我们讨论如何运用MLOps原则将生成式人工智能应用商业化,从而实现基础模型运营(FMOps)。此外,我们还深入探讨了文本到文本应用和LLM运营(LLMOps)的最常见生成式人工智能用例,它是FMOps的一个子集。下图展示了我们讨论的主题。

具体来说,我们简要介绍了MLOps原则,并重点讨论了与FMOps和LLMOps相比在流程、人员、模型选择和评估、数据隐私以及模型部署方面的主要差异。这适用于那些使用现成解决方案、从头开始创建基础模型或进行微调的客户。我们的方法同样适用于开源模型和专有模型。

机器学习商业化总结

如在Amazon SageMaker企业MLOps基础路线图一文中所定义,机器学习(ML)和运营(Ops)的结合是人员、流程和技术的组合,以高效地将机器学习解决方案投入生产。为了实现这一目标,需要各个团队和角色之间的合作,如下图所示。

这些团队包括:

  • 高级分析团队(数据湖和数据网格) – 数据工程师负责从多个来源准备和导入数据,构建ETL(抽取、转换和加载)流水线以筛选和编目数据,并为机器学习用例准备必要的历史数据。这些数据所有者专注于向多个业务单位或团队提供数据访问权限。
  • 数据科学团队 – 数据科学家需要专注于基于预定义的关键绩效指标(KPI)在笔记本中工作,创建最佳模型。在完成研究阶段后,数据科学家需要与机器学习工程师合作,通过CI/CD流水线创建自动化流程,将模型部署到生产环境中。
  • 业务团队 – 产品负责人负责定义业务案例、要求和用于评估模型性能的KPI。其他业务利益相关者使用推理结果(预测)来进行决策。
  • 平台团队 – 架构师负责业务的整体云架构以及所有不同服务之间的连接方式。安全专家根据业务安全策略和需求审查架构。MLOps工程师负责为数据科学家和机器学习工程师提供安全的环境来将机器学习用例投入生产。具体而言,他们负责根据业务和安全要求标准化CI/CD流水线、用户和服务角色以及容器创建、模型使用、测试和部署方法。
  • 风险和合规团队 – 对于更为严格的环境,审计人员负责评估数据、代码和模型工件,确保业务符合数据隐私等法规。

请注意,同一人可能承担多个角色,这取决于企业的规模和MLOps成熟度。

这些角色需要专门的环境来执行不同的流程,如下图所示。

环境如下:

  • 平台管理 – 平台管理环境是平台团队创建AWS账户并链接正确用户和数据的地方
  • 数据 – 数据层,通常称为数据湖或数据网格,是数据工程师、数据所有者和业务利益相关者用于准备、交互和可视化数据的环境
  • 实验 – 数据科学家使用沙盒或实验环境来测试新的库和机器学习技术,以证明他们的概念验证可以解决业务问题
  • 模型构建、模型测试、模型部署 – 模型构建、测试和部署环境是MLOps的一层,数据科学家和机器学习工程师在此环境中合作,自动化研究并将其转化为生产
  • ML治理 – 这个谜题的最后一块是ML治理环境,其中所有模型和代码工件都存储、审查并由相应的角色进行审核

下面的图表展示了参考架构,该架构已在Amazon SageMaker的企业MLOps基础路线图中进行了讨论。

每个业务单元都有自己的开发(自动模型训练和构建)、预生产(自动化测试)和生产(模型部署和服务)账户来实现生产化的机器学习用例,这些用例从集中化或分散化的数据湖或数据网中检索数据。所有生成的模型和代码自动化都存储在一个集中化的工具账户中,使用模型注册表的能力。所有这些账户的基础设施代码都在一个共享服务账户(高级分析治理账户)中进行版本管理,平台团队可以将其抽象化、模板化、维护和重用,以便为每个新团队的MLOps平台入门提供支持。

生成式人工智能定义及其与MLOps的区别

在传统机器学习中,人员、流程和技术的组合可以帮助您产品化机器学习用例。然而,在生成式人工智能中,用例的性质要求要么扩展这些能力,要么提供新的能力。其中一个新概念是基础模型(FM)。它们之所以被称为基础模型,是因为它们可以用来创建各种其他的人工智能模型,如下图所示。

基础模型(FM)是基于大量数据进行训练的,拥有数百亿个参数,可以根据生成式人工智能用例的三个主要类别进行下一个最佳答案的预测:

  • 文本到文本 – 基于未标记数据(如自由文本)进行了FM(LLM)的训练,能够预测下一个最佳单词或一系列单词(段落或长篇文章)。主要用例包括人类对话机器人、摘要或其他内容生成(如编程代码)。
  • 文本到图像 – 使用标记的数据,如<文本,图像>对,进行了FM的训练,可以预测最佳像素的组合。示例用例包括服装设计生成或虚构的个性化图像。
  • 文本到音频或视频 – FM训练可以使用标记和未标记的数据。一个主要的生成式人工智能用例示例是音乐创作。

为了实现这些生成式人工智能用例的生产化,我们需要借鉴并扩展MLOps领域,包括以下内容:

  • 基础模型运营(FMOps) – 这可以将生成式人工智能解决方案(包括任何用例类型)进行生产化
  • 语言模型运营(LLMOps) – 这是FMOps的一个子集,专注于将基于语言模型的解决方案(如文本到文本)进行生产化

下图展示了这些用例的重叠。

与传统机器学习和MLOps相比,FMOps和LLMOps在以下四个主要类别上有所不同,我们将在以下章节中介绍:人员和流程、基础模型的选择和调整、基础模型的评估和监控、数据隐私和模型部署以及技术需求。我们将在另一篇文章中介绍监控。

根据生成式人工智能用户类型的操作化过程

为了简化过程的描述,我们需要将主要的生成式人工智能用户类型进行分类,如下图所示。

用户类型如下:

  • 提供者 – 用户从零开始构建FM,并将其作为产品提供给其他用户(微调者和消费者)。他们具备深度的端到端ML和自然语言处理(NLP)专业知识、数据科学技能,以及庞大的数据标注和编辑团队。
  • 微调者 – 用户从提供者那里重新训练(微调)FM以适应定制要求。他们协调模型的部署作为服务供消费者使用。这些用户需要强大的端到端ML和数据科学专业知识,以及模型部署和推理的了解。还需要具备强大的领域知识,包括提示工程。
  • 消费者 – 用户通过文本提示或视觉界面与提供者或微调者的生成式AI服务进行交互,以完成所需的操作。不需要ML专业知识,但通常是具有理解服务功能的应用程序开发人员或最终用户。只需要进行提示工程以获得更好的结果。

根据定义和所需的ML专业知识,MLOps主要适用于提供者和微调者,而消费者可以使用应用程序产品化原则,如DevOps和AppDev来创建生成式AI应用程序。此外,我们观察到在用户类型之间存在一种趋势,即提供者可能成为微调者,以支持基于特定垂直行业(如金融行业)的用例,或者消费者可能成为微调者以实现更准确的结果。但让我们观察每个用户类型的主要过程。

消费者的旅程

以下图表展示了消费者的旅程。

如前所述,消费者需要选择、测试和使用FM,并通过提供特定输入(即提示)与其进行交互。在计算机编程和人工智能的上下文中,提示是指输入给模型或系统以生成响应的输入。这可以是文本、命令或问题的形式,系统使用它来处理和生成输出。FM生成的输出可以被最终用户利用,并且他们也应该能够对这些输出进行评价以增强模型未来的响应。

除了这些基本过程,我们注意到消费者表达了希望通过利用微调者提供的功能来微调模型的愿望。例如,一个生成图像的网站。在这里,最终用户可以设置私人帐户,上传个人照片,并随后生成与这些图像相关的内容(例如,在异国情调的地点上生成一张描绘最终用户骑摩托车持剑或位于该地点的图像)。在这种情况下,由消费者设计的生成式AI应用程序必须通过API与微调器后端进行交互,以向最终用户提供此功能。

然而,在深入研究此过程之前,让我们首先集中讨论模型选择、测试、使用、输入和输出交互以及评分的旅程,如下图所示。

*可用FM参考数为15K

步骤1. 了解顶级FM的能力

在选择基础模型时,需要考虑许多因素,这取决于用例、可用数据、法规等等。一个好的检查清单,虽然不是全面的,可能如下:

  • 专有或开源FM – 专有模型通常需要付费,但通常在生成的文本或图像质量方面提供更好的性能,通常由专门的模型提供者团队开发和维护,以确保最佳性能和可靠性。另一方面,我们还看到了对开源模型的采用,除了免费外,还提供了额外的优势,如可访问性和灵活性(例如,每个开源模型都可以进行微调)。专有模型的一个例子是Anthropic的Claude模型,而一个性能出色的开源模型的例子是Falcon-40B,截至2023年7月。
  • 商业许可 – 在决定FM时,许可考虑因素至关重要。需要注意的是,有些模型是开源的,但由于许可限制或条件,不能用于商业目的。差异可能是微妙的:例如,新发布的xgen-7b-8k-base模型是开源的,并且可以用于商业用途(Apache-2.0许可证),而该模型的指令微调版本xgen-7b-8k-inst仅用于研究目的。在为商业应用程序选择FM时,必须验证许可协议,了解其限制,并确保与项目的预期用途相一致。
  • 参数 – 参数的数量,包括神经网络中的权重和偏差,是另一个关键因素。更多的参数通常意味着更复杂、潜力更大的模型,因为它可以捕捉更复杂的数据模式和相关性。然而,这样做的代价是需要更多的计算资源,因此运行成本更高。此外,我们确实看到了对较小模型的趋势,特别是在开源领域(模型范围从70亿到400亿),这些模型表现良好,尤其是在微调时。
  • 速度 – 模型的速度受其大小的影响。较大的模型处理数据的速度较慢(更高的延迟),这是由于增加的计算复杂性。因此,在需要实时或准实时响应的应用程序(如聊天机器人)中,平衡对具有高预测能力的模型的需求(通常是较大的模型)与速度的实际要求非常重要。
  • 上下文窗口大小(令牌数量) – 上下文窗口是指每个提示可以输入或输出的最大令牌数,这对于确定模型可以同时考虑多少上下文非常重要(一个令牌大致相当于0.75个英文单词)。具有较大上下文窗口的模型可以理解和生成更长的文本序列,这对于涉及更长对话或文档的任务非常有用。
  • 训练数据集 – 还需要了解FM的训练数据集的类型。一些模型可能是在多样的文本数据集上进行训练,如互联网数据、编码脚本、说明或人类反馈。其他模型可能还在多模态数据集上进行训练,如文本和图像数据的

    以下是专有模型和开源模型的两个示例短列表。您可以根据特定需求编制类似的表格,以快速了解可用选项。请注意,这些模型的性能和参数会快速变化,阅读时可能已经过时,而其他功能可能对特定客户很重要,比如支持的语言。

    以下是 AWS(2023年7月)提供的值得注意的专有 FM 示例。

    以下是 AWS(2023年7月)提供的值得注意的开源 FM 示例。

    当您编制了10-20个潜在候选模型的概述后,有必要进一步筛选这个短列表。在本节中,我们提出了一种快速机制,可以获得两到三个可行的最终模型,作为下一轮的候选模型。

    以下图示了初始筛选流程。

    通常,熟悉创建高质量提示的提示工程师会尝试使用不同的方法在模型上执行相同的任务(例如摘要)。我们建议这些提示不是即兴创建的,而是从提示目录中系统地提取的。这个提示目录是一个存储提示的中央位置,以避免重复、实现版本控制,并在团队内共享提示,以确保在不同开发阶段的不同提示测试人员之间保持一致性。我们将在下一节介绍这个提示目录,它类似于特征存储的 Git 存储库。然后,生成式 AI 开发人员(可能是同一个人作为提示工程师)需要评估输出,以确定它是否适用于他们正在开发的生成式 AI 应用。

    步骤2. 测试和评估顶级 FM

    在将短列表缩减到大约三个 FM 后,我们建议进行评估步骤,进一步测试 FM 的能力和适用性。根据可用性和评估数据的性质,我们建议使用不同的方法,如下图所示。

    首先要使用的方法取决于是否有标记的测试数据。

    如果您有标记数据,可以使用它进行模型评估,就像我们对传统的机器学习模型做的那样(输入一些样本,并将输出与标签进行比较)。根据测试数据是离散标签(例如正面、负面或中性情感分析)还是非结构化文本(例如摘要),我们提出了不同的评估方法:

    • 准确度指标 – 对于离散输出(例如情感分析),我们可以使用精度、召回率和 F1 分数等标准准确度指标
    • 相似度指标 – 如果输出是非结构化的(例如摘要),我们建议使用 ROUGE 和余弦相似度等相似度指标

    有些用例不适合只有一个真实答案(例如“为我5岁的女儿创作一个简短的儿童故事”)。在这种情况下,评估模型变得更具挑战性,因为您没有标记的测试数据。我们提出了两种方法,取决于人工审查模型与自动评估的重要性:

    • 人机协同(HIL) – 在这种情况下,一组提示测试人员将审查模型的响应。根据应用的重要性,提示测试人员可能会审查模型输出的100%或只是一个样本。
    • LLM 动力评估 – 在这种情况下,提示测试人员被一种更强大的 LLM(可能比正在测试的模型更慢和更昂贵)取代。LLM 将审查所有模型生成的响应并对其进行评分。这种方法可能会导致较低的质量,但它是一种更便宜和更快速的评估选项,可以为模型的性能提供一个良好的初始参考。

    例如,我们可以使用以下示例提示来向LLM提供示例,其中包含输入查询、LLM响应和指示:“我们希望请您对AI助手在上面显示的用户问题中的表现提供反馈。请评价助手响应的有用性、相关性、准确性和详细程度。助手将在1到10的评分范围内获得一个总体得分,较高的得分表示整体表现更好。”

    此提示将发送给另一个LLM(EvalLLM)进行评估。以下是一个示例,其中Falcon-40B模型的响应经过了EvalLLM(在本例中是Claude)的评估。我们使用问题“如果苏伊士运河从未被建造会怎样?”响应如下:

    问题:如果苏伊士运河从未被建造会怎样?

    falcon-40b-instruct

    如果苏伊士运河从未被建造,船只将不得不绕过非洲在地中海和红海之间航行。这将增加航行的时间和距离,使其效率更低、更加昂贵。此外,没有苏伊士运河,中东和北非的许多国家将与世界其他地区联系较少,阻碍经济和文化发展。

    评价(得分:9/10)

    助手的响应非常相关、准确和详细。它对用户关于苏伊士运河不存在的假设性问题提供了一个很好的答案。助手正确指出了对海上旅行的影响以及对中东和北非的经济和文化影响。然而,它可以进一步阐述地缘政治影响或对全球贸易模式的影响,以提供更全面的回答。

    以下图示了端到端评估过程示例。

    根据此示例,要进行评估,我们需要提供示例提示,将其存储在提示目录中,并根据特定应用提供一个带有标签或未标记的评估数据集。例如,使用带有标签的评估数据集,我们可以提供输入查询,如“告诉我2023年英国首相的全名”,以及输出和答案,如“Rishi Sunak”。对于未标记的数据集,我们只提供问题或指令,如“生成一个零售网站的源代码”。我们将提示目录和评估数据集的组合称为评估提示目录。之所以区分提示目录和评估提示目录,是因为后者专门用于特定用例,而不是通用提示和指令(如问答)。

    有了这个评估提示目录,下一步是将评估提示提供给顶级FM。结果是一个评估结果数据集,其中包含每个FM的提示、输出以及标记输出和评分(如果存在)。对于未标记的评估提示目录,还有一个额外的步骤供HIL或LLM审查结果并提供评分和反馈(正如我们之前所描述的)。最终的结果将是合并的结果,将所有输出的评分结合起来(计算平均准确度或人工评分),并允许用户对模型的质量进行基准测试。

    在收集评估结果之后,我们建议根据几个维度选择模型。这些通常归结为精度、速度和成本等因素。以下图示了一个示例。

    每个模型在这些维度上都具有优势和一定的权衡。根据用例的不同,我们应该对这些维度分配不同的优先级。在上面的示例中,我们选择将成本作为最重要的因素,其次是精度,然后是速度。即使比FM1更慢且不那么高效,它仍然足够有效并且成本显著更低。因此,我们可能会选择FM2作为首选。

    第三步:开发生成式AI应用程序的后端和前端

    在这个阶段,生成式AI开发人员与提示工程师和测试人员的帮助下,已经选择了适合特定应用程序的正确FM。下一步是开始开发生成式AI应用程序。我们将生成式AI应用程序的开发分为两个层次,即后端和前端,如下图所示。

    在后端,生成式AI开发人员将所选的FM融入解决方案,并与提示工程师合作,创建自动化来将最终用户输入转换为适当的FM提示。提示测试人员为提示目录创建必要的条目,以进行自动或手动(HIL或LLM)测试。然后,生成式AI开发人员创建提示链接和应用机制,提供最终输出。在这个上下文中,提示链接是一种将复杂任务分解为一系列更小、更易管理的子任务的技术。例如,如果我们向LLM提问“英国首相出生在哪里,那个地方离伦敦有多远”,这个任务可以分解为多个独立的提示,其中一个提示可能是基于前一个提示评估的答案构建的,比如“英国的首相是谁”、“他们的出生地是什么”和“那个地方离伦敦有多远”。为了确保输入和输出的质量,在生成式AI开发人员还需要创建机制来监视和过滤最终用户的输入和应用程序的输出。例如,如果LLM应用程序应该避免有毒的请求和响应,他们可以应用输入和输出的毒性检测器,并过滤掉这些内容。最后,他们需要提供一个评分机制,以支持评估提示目录的扩充,包括好的和坏的示例。这些机制的更详细的表示将在未来的帖子中介绍。

    为了向生成式AI最终用户提供功能,需要开发一个与后端交互的前端网站。因此,DevOps和AppDevs(云端应用程序开发人员)角色需要遵循最佳开发实践,实现输入/输出和评分的功能。

    除了这些基本功能外,前端和后端还需要合并创建个人用户账户、上传数据、启动作为黑盒的精调和使用个性化模型,而不是基本的FM的功能。生成式AI应用程序的生产化与普通应用程序类似。下图描述了一个示例架构。

    在这个架构中,生成式AI开发人员、提示工程师和DevOps或AppDevs通过将应用程序通过CI/CD部署到开发环境(上图中的生成式AI App Dev)来手动创建和测试应用程序,使用专用代码仓库并与开发分支合并。在这个阶段,生成式AI开发人员将调用FM提供商提供的API,使用相应的FM。然后,为了广泛测试应用程序,他们需要将代码提升到测试分支,这将触发通过CI/CD部署到预生产环境(生成式AI App Pre-prod)。在这个环境中,提示测试人员需要尝试大量的提示组合并审查结果。提示、输出和审查的组合需要移动到评估提示目录中,以便将来自动化测试过程。在进行了这些广泛测试之后,最后一步是通过CI/CD将生成式AI应用程序提升到生产环境,通过与主分支合并(生成式AI App Prod)。请注意,所有的数据,包括提示目录、评估数据和结果、最终用户数据和元数据以及经过精调的模型元数据,都需要存储在数据湖或数据网格层中。CI/CD流水线和代码库需要存储在一个单独的工具账户中(类似于MLOps描述的账户)。

    提供者的旅程

    FM提供者需要训练FMs,例如深度学习模型。对于他们来说,端到端的MLOps生命周期和基础设施是必要的。在历史数据准备、模型评估和监控方面需要进行补充。下图描述了他们的旅程。

    在经典机器学习中,历史数据通常是通过ETL流水线来提供地面真实值而创建的。例如,在客户流失预测案例中,自动化程序根据客户的新状态自动更新数据库表来进行流失/不流失的判断。对于FM模型来说,它们需要数十亿个标记或未标记的数据点。在文本到图像的使用案例中,需要一个数据标记团队手动标记对。这是一项昂贵的工作,需要大量的人力资源。亚马逊SageMaker Ground Truth Plus可以为您提供一个标记团队来执行此活动。对于某些使用案例,这个过程也可以部分自动化,例如使用类似CLIP的模型。对于像文本到文本这样的LLM模型,数据是未标记的。但是,它们需要被准备好,并遵循现有历史未标记数据的格式。因此,需要数据编辑器来执行必要的数据准备工作并确保一致性。

    准备好历史数据后,下一步是对模型进行训练和生产化。请注意,与我们描述给消费者的相同的评估技术可以使用。

    微调者的旅程

    微调者的目标是将现有的FM模型调整到特定的上下文中。例如,FM模型可以对一般用途的文本进行概括,但不能准确概括财务报告,也不能为非常见的编程语言生成源代码。在这些情况下,微调者需要标记数据,通过运行训练作业来微调模型,部署模型,根据消费者流程进行测试,并监控模型。下图说明了这个过程。

    目前有两种微调机制:

    • 微调 – 通过使用FM和标记数据,训练作业重新计算深度学习模型层的权重和偏差。这个过程可能需要大量的计算资源和代表性的数据,但可以生成准确的结果。
    • 参数高效微调(PEFT) – 研究人员已经证明,通过向深度学习模型添加额外的小层,可以实现令人满意的结果(例如,LoRA)。PEFT需要比深度微调更低的计算能力和较少的输入数据的训练作业。缺点是可能会降低准确性。

    下图说明了这些机制。

    现在我们已经定义了两种主要的微调方法,下一步是确定如何部署和使用开源和专有的FM模型。

    对于开源的FM模型,微调者可以从网络上下载模型和源代码,例如使用Hugging Face Model Hub。这样您就可以灵活地对模型进行深度微调,将其存储到本地模型注册表中,并将其部署到亚马逊SageMaker终端节点。这个过程需要互联网连接。为了支持更安全的环境(例如金融行业的客户),您可以在本地下载模型,运行所有必要的安全检查,并将其上传到AWS账户上的本地存储桶中。然后,微调者可以在没有互联网连接的情况下使用本地存储桶中的FM模型。这样可以确保数据隐私,数据不会通过互联网传输。下图说明了这种方法。

    使用专有FM,部署过程不同,因为调优者无法访问模型文件或源代码。模型存储在专有FM提供商AWS账户和模型注册表中。要将这样的模型部署到SageMaker端点,调优者只能请求直接部署到端点的模型包。此过程需要使用客户数据在专有FM提供商的账户中使用,这引发了关于在远程账户中使用客户敏感数据进行调优以及将模型托管在多个客户之间共享的模型注册表中的问题。这导致了一个多租户问题,如果专有FM提供商需要为这些模型提供服务,那么问题就变得更具挑战性。如果调优者使用Amazon Bedrock,这些挑战就会得到解决-数据不会通过互联网传输,FM提供商也无法访问调优者的数据。对于开源模型,如果调优者想要为多个客户提供模型,例如我们之前提到的网站,数千个客户会上传个性化图片,那么相同的挑战也存在。然而,这些情况可以被认为是可控的,因为只涉及到调优者。下图说明了这种方法。

    从技术角度来看,调优者需要支持的架构类似于MLOps(参见下图)。调优需要在开发环境中进行,通过创建ML流水线(例如使用Amazon SageMaker Pipelines),执行预处理、调优(训练任务)和后处理,并将经过调优的模型发送到本地模型注册表(如果是开源FM,则新模型将存储到专有FM提供环境)。然后,在预生产环境中,我们需要像为消费者场景描述的那样测试模型。最后,模型将在生产环境中提供服务并进行监控。请注意,当前(经过调优的)FM需要GPU实例端点。如果我们需要将每个经过调优的模型部署到单独的端点,这可能会增加成本,尤其是在存在数百个模型的情况下。因此,我们需要使用多模型端点并解决多租户挑战。

    调优者根据特定的上下文调整FM模型以用于其业务目的。这意味着大部分时间,调优者也是消费者,需要支持我们在前面部分描述的所有层次,包括生成式AI应用程序开发、数据湖和数据网格以及MLOps。

    下图说明了调优者需要为生成式AI最终用户提供的完整FM调优生命周期。

    下图说明了关键步骤。

    关键步骤如下:

    1. 最终用户创建个人账户并上传私人数据。
    2. 数据存储在数据湖中,并进行预处理以符合FM的格式要求。
    3. 这会触发一个调优ML流水线,将模型添加到模型注册表中。
    4. 从那里,要么将模型部署到生产环境中进行最小测试,要么对模型进行全面测试,包括HIL和手动批准门。
    5. 经过调优的模型可供最终用户使用。

    由于这个基础架构对于非企业客户来说比较复杂,AWS推出了Amazon Bedrock,以减轻创建此类架构和将经过调优的FM更接近生产的工作。

    FMOps和LLMOps的角色和流程差异

    基于前面的用户类型旅程(消费者、生产者和微调者),需要具备特定技能的新角色,如下图所示。

    新角色如下:

    • 数据标记员和编辑员 – 这些用户标记数据,例如<文本,图像>对,或者准备未标记的数据,例如自由文本,并扩展高级分析团队和数据湖环境。
    • 微调者 – 这些用户对FMs有深入的了解,并知道如何调整它们,扩展专注于经典机器学习的数据科学团队。
    • 生成AI开发者 – 他们对选择FMs,链接提示和应用,以及筛选输入和输出有深入的了解。他们属于一个新团队 – 生成AI应用团队。
    • 提示工程师 – 这些用户设计输入和输出提示,以使解决方案适应上下文,并测试和创建提示目录的初始版本。他们的团队是生成AI应用团队。
    • 提示测试员 – 他们以规模测试生成AI解决方案(后端和前端)并将结果提供给增强提示目录和评估数据集。他们的团队是生成AI应用团队。
    • AppDev和DevOps – 他们开发生成AI应用的前端(例如网站)。他们的团队是生成AI应用团队。
    • 生成AI最终用户 – 这些用户作为黑盒使用生成AI应用程序,共享数据,并评估输出的质量。

    扩展版本的MLOps流程图可以用以下图示。

    新的应用层是生成AI开发者、提示工程师、测试员和AppDev创建生成AI应用程序的后端和前端的环境。生成AI最终用户通过互联网(如Web界面)与生成AI应用程序前端进行交互。另一方面,数据标记员和编辑员需要对数据进行预处理,而无需访问数据湖或数据网格的后端。因此,与编辑器相结合的Web界面(网站)对于安全地与数据进行交互是必要的。SageMaker Ground Truth可以提供这个功能。

    结论

    MLOps可以帮助我们高效地将机器学习模型投入生产。然而,要使生成AI应用程序实现运营化,您需要额外的技能、流程和技术,从而形成FMOps和LLMOps。在本文中,我们定义了FMOps和LLMOps的主要概念,并描述了与MLOps能力相比的关键差异,包括人员、流程、技术、FM模型选择和评估。此外,我们还说明了生成AI开发者的思维过程和生成AI应用程序的开发生命周期。

    在未来,我们将专注于根据我们讨论的领域提供解决方案,并提供有关如何将FM监控(例如有毒性、偏见和幻觉)和第三方或私有数据源架构模式(例如检索增强生成)集成到FMOps/LLMOps中的更多详细信息。

    要了解更多信息,请参阅Amazon SageMaker企业MLOps基础路线图,并尝试在使用Amazon SageMaker JumpStart预训练模型实施MLOps实践中实现端到端的解决方案。

    如果您有任何评论或问题,请在评论部分留言。