理解LLMOps: Large Language Model Operations
理解LLMOps: Large Language Model Operations
对于像我一样的小白来说，本文是一篇非常不错的LLMs入门介绍文档。来自：Understanding LLMOps: Large Language Model Operations
本文首先解释了新术语"LLMOps"及其背景，然后讨论使用LLMs和传统ML模型构建AI产品的不同之处，并基于这些不同点总结出MLOps和LLMOps的差异。最后我们将讨论在不久的将来，LLMOps将会发生什么样的变化。
什么是LLMOps？
LLMOps是Large Language Model Operations的缩写，可以将LLMOps认为是LLMs的MLOps，这也意味着，LLMOps本质上是管理基于LLM的应用的一系列工具和最佳实践，包括开发、部署和维护。
上面说到"可以将LLMOps认为是LLMs的MLOps"，这里看下LLMs和MLOps的定义：
- LLMs(large language models)：可以生成人类语言的深度学习模型，因此被称为语言模型(language models)。该模型有数十亿个参数，并在数十亿个单词的基础上进行训练，因此被称为大语言模型。
- MLOps (machine learning operations)：用于管理基于ML应用的生命周期一系列工具和最佳实践。
为什么LLMOps会崛起？
早期的LLMs，如BERT和GPT-2出现于2018年左右，而现在(差不多五年之后)，LLMOps 概念正在迅速崛起，其中最主要的原因是在2022年12月发布的ChartGPT吸引了大量媒体的关注。
从那之后，我们看到了很多基于LLMs构建的应用，如：
- 从著名的ChatGPT到更亲密和人性化的聊天机器人(如Michelle Huang chatting with her childhood self)。
- 从编辑或摘要的写作助手(例如，Notion AI)到专门的文案助手(例如，Jasper 和 copy.ai))或合同助手(例如，lexion) 。
- 从用于编写和调试代码的编程助手(如 GitHub Copilot)，到测试(如Codium AI)并找出安全威胁(Socket AI)的助手。
随着越来越多的基于LLM的应用的开发和产品化，人们得出了如下经验：
使用LLMs可以很容易地做一些很酷的事情，但同时很难将它产品化 - Chip Huyen
不同于传统的基于ML模型的AI产品，基于LLM的应用的产品化过程有其特定的挑战。为了解决这些问题，我们需要开发新的工具和最佳实践来管理LLM应用的生命周期，因此出现了术语"LLMOps"。
LLMOps涉及哪些步骤？
LLMOps涉及的步骤和MLOps类似。但由于基础模型的出现，构建基于 LLM 的应用程序的步骤有所不同。构建基于LLM的应用的重点在于如何使用预先训练好的LLMs来服务下游任务，而非从头训练LLMs。大约在一年前，Andrej Karpathy描述了未来构建AI产品的流程：
但是，最重要的趋势[ ... ]是，由于微调(调整LLM参数以适应特定任务的过程)，特别是像GPT这样的基础模型的出现，从零开始训练神经网络的方式很快就过时了。这些基础模型由少数拥有大量计算资源的机构进行训练，而大多数应用则是通过对神经网络的一部分进行微调、prompt engineering(指通过设计和优化生成模型的提示或输入，以获得更好的生成结果。它是一种通过调整输入文本的方式来引导模型生成所需输出的技术)，或是(可选步骤)将数据或模型蒸馏成更小、专用于推理的网络来实现的。
当你第一次读到这句话的时候，可能会觉得有些不可思议，但它准确地概括了目前正在发生的一切，下面让我们在接下来的小节中逐步解读它。
第一步：选择基础模型
基础模型是基于大量数据事先训练好的一类LLMs，可以广泛用于下游任务。由于从头训练一个基础模型相当复杂、耗时且昂贵，因此只有一小部分机构拥有所需的资源。
换个角度来看：根据Lambda Labs 2020年的研究表明，如果使用一台训练Tesla V100云实例来训练OpenAI的GPT-3(大约1750亿个参数)，大约需要355年，并花费460万美元。
人工智能目前正在经历社区所称的Linux 时刻。目前，开发者需要从两种类型的基础模型之间，基于表现、成本、上手难度和灵活性进行抉择。这两种模型为：专有模型和开源模型：
专有模型是由拥有大量专家团队和大量AI预算的公司所属的闭源基础模型，这些模型通常要大于开源模型，且表现更好，同时，这些模式也是现成的，通常上手难度较低。
专有模型的主要缺点是其昂贵的APIs，此外，闭源基础模型对于开发者来说提供的灵活性较少或没有。专有模型提供商举例如下：
开源模型通常以社区中心的方式组织和托管在 HuggingFace上。相比专有模型来说，这些模型更小，能力也更小。但好的方面在于，它们更加经济，并给开发者带来更大的灵活性。开原模型举例如下：
-
BLOOM (BigScience)
-
GPT-J, GPT-Neo 或 Pythia ( Eleuther AI)
步骤2：适应下游任务
一旦选择了基础模型，就可以通过其API访问该LLM。如果你之前跟其他类型的API打过交道，此时会发现和LLM的APIs打交道会有些奇怪，因为它并没有实现规定什么输入会产生什么输出。通过输入任意文本提示，API会返回一段尝试匹配输入的文本。
下面是一个如何使用OpenAI API的例子，通过API输入提示，如prompt = "Correct this to standard English:\n\nShe no went to the market."
API会返回['choices'][0]['text'] = "She did not go to the market."`
最主要的挑战在于，LLMs并不是无所不能的，如何让LLM返回你期望的内容？
在LLM的产品化调查中，受访者提到的一个关注点是模型的准确性和幻觉问题，这意味着从LLM API中获取期望格式的输出可能需要一些迭代。此外，如果LLM没有所需的特定知识，它可能会出现幻觉。
为了解决这些问题，可以在下游任务中使用如下方式来采纳基础模型：
-
Prompt Engineering：是一种对输入进行调整，从而使输出更符合预期的一种技术。可以使用不同的技巧提升提示的效果(参见OpenAI Cookbook)。一种方式是提供一些符合期望输出格式的例子，类似于零样本学习或少样本学习的方式。目前已经出现了像LangChain 或 HoneyHive这样的工具来帮助管理prompt模版并对其进行版本控制。
-
对预训练模型进行微调是ML中已知的一种技术。它可以帮助提升特定任务的模型表现。虽然这种方式增加了训练的工作量，但它可以降低推测的成本。LLM API的费用取决于输入和输出的长度。因此，降低输入的token数就可以降低API的花费(因为无需再给提示提供例子)。
-
外部数据：基础模型通常缺少上下文信息(如访问某些特定的文档或邮件)且会很快过期(如GTP-4训练的是2021年9月之前的数据)。由于LLMs在无法获取足够的信息时会出现幻觉，因此我们需要给予它们访问相关数据的能力。目前已经出现一些工具，如LlamaIndex (GPT Index), LangChain或 DUST，可以作为连接LLMs和其他代理和外部数据的中央接口。
-
嵌入：另外一种方式是以嵌入的方式从LLM APIs抽取数据(如，电影总结或产品描述)，并基于这些数据来构建应用(如查询、比较或推荐)。如果np.array无法存储足够长的数据，则可以选择使用如 Pinecone, Weaviate或 Milvus等矢量数据库。
步骤3：评估
传统的MLOps中，通过保留的验证集对ML模型进行验证，并通过指标评估模型的表现。但如何评估LLM的表现？如何决定一个返回是好是坏？目前一些组织似乎在使用A/B来测试其模型。
为了帮助评估LLMs，出现了如HoneyHive 和 HumanLoop 这样的工具。
步骤4：部署和监控
LLM的完成结果在不同版本之间可能会发生重大变化。例如，OpenAI已经通过更新其模型来减少生成不适当内容(如仇恨言论)。因此，在Twitter上搜索短语"as an AI language model"现在会显示出无数的机器人账号。
如上展示了在构建基于LLM的应用程序时需要监控底层API模型的变化。
目前已经出现了用于监控LLMs的工具，如 Whylabs 或 HumanLoop。
LLMOps和MLOps的区别？
MLOps和LLMOps之间的差异是由于在构建基于传统ML模型和LLM模型的AI产品时的差异所导致的。主要体现在数据管理、实验、评估、成本和延迟。
数据管理
传统的MLOps通常使用data-hungry ML模型。从头训练一个神经网络需要大量标签数据，即便是微调一个预训练的模型至少也需要几百个例子。尽管数据清洗是ML开发过程中不可或缺的一部分，但我们知道并接受大型数据集存在的不完美之处。
在LLMOps中，微调方式类似MLOps，但prompt engineering是一种零样本学习或少样本学习方式，这意味着我们只需要精心挑选的样本即可。
实验
在MLOps中，实验方式和从头训练一个模型或微调一个预训练的模型一样。两种情况下都需要跟踪输入，如模型架构、超参数和数据增强，以及输出(如指标)。
但在LLMOps中，问题变为是否进行prompt engineering或微调。
LLMOps中的微调和MLOps很像，但prompt engineering的实验配置却有所不同(如提示管理)。
评估
在传统的MLOps中，模型的表现能是通过在保留的验证集上使用评估指标进行评估的。而由于LLM的表现更加难以评估，因此目前各大组织采用了A/B测试。
成本
传统的MLOps的成本通常在数据采集和模型训练，而LLMOps的成本则在推理。虽然实验过程中使用昂贵的API可能会产生一些费用，但Chip Huyen表明，长提示的成本主要在于推理阶段。
延迟
在LLM在生产中的调查中，受访者提到的另一个关注点是延迟。LLM的完成长度会显著影响延迟。尽管在MLOps中也必须考虑延迟问题，但在LLMOps中则更加突出，这对于开发过程中的实验速度以及生产环境中的用户体验来说都是一个重要问题。
LLMOps的未来
LLMOps是一个新型的领域，随着该领域的快速发展，一切皆有可能，即使是这里的LLMOps定义都有可能发生变化。我们唯一可以确信的是会出现更多LLMs的使用场景，并会出现更多的工具和最佳实践来管理LLM的生命周期。
AI的领域在急速演进，有可能本文在一个月后就过时了。我们仍然处在将LLM推向生产的初始阶段，目前仍然有很多问题没有解答，只有时间会告诉我们事情会如何发展：
- 这里的LLMOps的术语是否会发生变化？
- LLMOps是如何根据MLOps进行演化？它们会一起变化，还是会独立演进？
- AI的"Linux时刻"如何展开？
我们可以肯定地说，预计很快会看到新的工具和最佳实践的出现。此外，我们已经看到针对基础模型的成本和延迟降低方面已经付出的努力。这绝对是令人兴奋的时代！
总结
随着OpenAI的ChatGPT的发布，LLMs已经成为AI领域的热门话题。这些深度学习模型可以以人类的语言生成输出，这使得它们成为会话AI、写作助手和编程助手等场景下的强大工具。
但将基于LLM的应用推向生产又面临这一些列挑战，这也导致了一个新术语的出现，LLMOps。它指代管理基于LLM的应用的生命周期的一些列工具和最佳实践，包括开发、部署和维护。
LLMOps可以看做是MLOps的一个子类。但构建基于LLM的应用的步骤又和构建基于传统ML模型应用的步骤有所不同。
相比从头开始训练一个LLM，应用LLM的重点变为了如何微调预训练的LLM以适应下游任务。这其中涉及选择一个基础模型、在下游任务中使用LLM，以及在评估模型后进行部署和监控。
虽然LLMOps仍然是一个相对较新的领域，但随着LLM在人工智能行业的普及，它预计将继续发展和演变。总体而言，LLM和LLMOps的崛起代表着在构建和维护以AI为动力的产品方面的重大转变。
TIps
本文来自博客园，作者：charlieroro，转载请注明原文链接：https://www.cnblogs.com/charlieroro/p/18051187
