10分钟搞懂LLMOps

随着LLM在AI领域的崛起，迫切需要一组管理和运维LLM驱动的应用程序的工具和最佳实践，这一切就是LLMOps的主要关注方向。原文: Understanding LLMOps: Large Language Model Operations

感觉OpenAI ChatGPT的发布打开了在生产环境中应用LLM的潘多拉盒子。不但邻居们都会絮叨几句AI的发展，甚至在ML社群冒出了一个新术语:"LLMOps"。

LLM正在改变构建和维护AI产品的方式。

本文将介绍新术语"LLMOps"及其背景，然后讨论基于LLM和经典ML模型构建AI产品的不同之处。基于这些差异，随后将讨论MLOps和LLMOps的差异。最后讨论在不久的将来LLMOps领域可以期待的发展。

什么是LLMOps?

术语LLMOps代表大语言模型运维，其缩写LLMOps的意思是面向LLM的MLOps，这意味着LLMOps是用于管理LLM驱动的应用程序生命周期(包括开发、部署和维护)的一组工具和最佳实践。

LLMOps是面向LLM的MLOps

当我们说"LLMOps是面向LLM的MLOps"时，需要首先定义LLM和MLOps这两个术语:

• LLM(大语言模型，Large language model) 是可以生成人类语言输出的深度学习模型(因此被称为 语言模型)。这类模型有数十亿个参数，并在数十亿个单词上进行训练(因此被称为 大语言模型)。
• MLOps(机器学习运维，Machine Learning Operations) 是一组用于管理机器学习驱动的应用程序生命周期的工具和最佳实践，。

因此，LLMOps是一组用于管理LLM驱动的应用程序生命周期的工具和最佳实践。由于LLM也是ML模型，因此可被看作是MLOps的子类别。

为什么LLMOps会兴起?

随着2022年底OpenAI ChatGPT的发布，LLM获得了广泛关注。从那时起，出现了许多LLM驱动的应用程序。但是，将LLM驱动的应用引入生产环境也有挑战，因此随之出现了包含新工具和最佳实践的LLMOps。

像BERT和GPT-2这样的早期LLM自2018年以来一直存在。然而，就在现在(差不多5年后)，我们正在经历LLMOps概念的迅速兴起。主要原因是，随着2022年12月ChatGPT的发布，LLM获得了媒体的广泛关注。

从那时起，我们看到许多应用开始借助于LLM的力量，例如:

• 聊天机器人，从著名的ChatGPT到更温馨私密的私有聊天机器人(例如， Michelle Huang与童年的自己聊天);
• 负责编辑或总结(例如， Notion AI)、专门负责文案(例如， Jasper和 copy.ai)或合同(例如， lexion)的 写作助理;
• 编程助理，辅助编写和调试代码(例如， GitHub Copilot)、测试(例如， Codium AI)、发现安全威胁(例如， Socket AI)，
• 等等

很多人分享了开发并将LLM驱动的应用引入生产环境的经验:

"用LLM做一些很酷的东西很容易，但真正投入生产环境却很难。—— Chip Huyen^[1]

很明显，与基于经典ML模型构建AI产品不同，构建生产就绪的LLM驱动的应用程序有其自身的一系列挑战。为了应对这些挑战，需要新的工具和最佳实践来管理LLM应用程序生命周期。因此，我们看到术语"LLMOps"出现频率越来越高。

LLMOps包括哪些步骤?

LLMOps涉及的步骤与MLOps相似。然而，由于基础模型的出现，构建LLM驱动的应用程序的步骤有所不同。与从头开始训练LLM不同，重点在于让预训练的LLM适配下游任务。

早在一年多前，Andrej Karpathy^[2]就描述了未来如何构建AI产品的过程:

但最重要的趋势是，...，在某些目标任务上从头训练神经网络的方式很快就会因为微调而过时。尤其是随着GPT等基础模型的出现，这些基础模型仅由少数具有大量计算资源的机构进行训练，大多数应用只需要通过对部分网络进行轻量级微调、快速工程、将数据或模型蒸馏为更小、专用的推理网络的可选步骤来实现。—— Andrej Karpathy

当你第一次读到这句话时，可能会感到不知所措。但它精确总结了所发生的一切，所以我们会在后续将其逐步拆解。

第1步: 选择基础模型

基础模型是基于大量数据预先训练的LLM，可用于广泛的下游任务。由于从头开始训练基础模型及其复杂、耗时且成本极高，只有少数机构拥有所需的训练资源。

比方说，根据Lambda实验室在2020年的一项研究^[3]，基于Tesla V100云实例训练OpenAI的GPT-3(有1750亿个参数)需要355年和460万美元。

AI目前正在经历社区所谓的"Linux时刻"。目前，开发人员必须基于性能、成本、易用性和灵活性，在两种类型的基础模型(专有模型或开源模型)之间做出选择。

专有模型是由拥有大型专家团队和大量预算的公司拥有的闭源基础模型，通常比开源模型更大，因此具有更好的性能。由于是现成的模型，因此很容易使用。

专有模型的主要缺点是API费用昂贵。此外，闭源基础模型为开发人员提供的灵活性很少或者根本没有灵活性。

专有模型供应商有:

• OpenAI (GPT-3, GPT-4)
• co:here
• AI21 Labs (Jurassic-2)
• Anthropic (Claude)

开源模型通常在Hugging Face上以社区形式组织和托管，通常比专有模型功能更少。但从好的方面来看，比专有模型更具成本效益，并为开发人员提供了更大的灵活性。

开源模型的例子有:

• Stability AI的 Stable Diffusion
• BigScience的 BLOOM
• Meta AI的 LLaMA以及 OPT
• Google的 Flan-T5
• Eleuther AI的 GPT-J、 GPT-Neo以及 Pythia

第2步: 适配下游任务

一旦选择了基础模型，就可以通过API访问LLM。对于习惯用其他API的人来说，用LLM API可能一开始会觉得有点奇怪，因为事先并不总是清楚什么输入会导致什么输出。给定任何文本提示，API将返回一个试图匹配输入模式的文本补全。

以OpenAI API为例^[4]，将提示词输入API，例如，prompt = "Correct this to standard English:\n\nShe no went to the market."。

import openai

openai.api_key = ...

response = openai.Completion.create(
  engine = "text-davinci-003",
  prompt = "Correct this to standard English:\n\nShe no went to the market.",
  ...
)

API将输出response，包含完成响应response['choices'][0]['text'] = "She did not go to the market."。

主要挑战是LLM虽然很强大，但并不是万能的，因此关键问题是: 如何让LLM提供想要的输出?

如何让LLM给出你想要的输出?

在LLM生产调查中，受访者提到的一个问题是模型的准确性和幻觉。这意味着从LLM API获得所需格式的输出可能需要若干次迭代，而且，如果LLM不具备所需特定知识，可能会产生幻觉问题。为了解决这些问题，可以通过以下方式使基础模型适配下游任务:

• **提示工程(Prompt Engineering)**，一种调整输入以使输出符合预期的技术。可以使用不同技巧来改善提示(参见 OpenAI Cookbook)。一种方法是提供预期输出格式示例，类似于zero-shot或few-shot学习设置[5]。已经出现了 LangChain或 HoneyHive这样的工具，可以帮助管理和版本化提示模板。

• 微调(Fine-tuning) 预训练模型是ML中一项已知技术，可以帮助提高模型在特定任务上的性能。虽然增加了训练工作量，但可以降低推理成本。LLM API的开销取决于输入和输出序列的长度。因此如果不再需要在提示中提供示例，那么减少输入令牌的数量可以降低API成本。

• 外部数据(External data): 基础模型通常缺乏上下文信息(例如，无法访问某些特定文档或电子邮件)，并且可能很快过时(例如，GPT-4是在2021年9月之前的数据上进行训练的)。LLM如果没有足够信息可能会产生幻觉，因此需要让它们接触相关的外部数据。已经有一些工具，如LlamaIndex (GPT Index)、LangChain或DUST，可以作为连接LLM到其他代理和外部数据("chaining")的中心接口。

• 嵌入(Embeddings): 另一种方法是从LLM API中以嵌入的形式提取信息(例如，电影摘要或产品描述)，并在其基础上构建应用程序(例如，搜索、比较或推荐)。如果np.array不足以长期存储嵌入信息，可以使用向量数据库，如Pinecone、Weaviate或Milvus。

• 备选方案(Alternatives): 随着这一领域的迅速发展，LLM可以在AI产品中发挥更多作用，例如指令调优/提示调优和模型蒸馏。

第3步: 评估

在经典MLOps中，ML模型在保留的验证集上进行验证，并基于模型性能度量进行评估。但是如何评价LLM的表现呢？如何判断回应是好是坏？目前，相关组织似乎正在对模型进行A/B测试。

为了帮助评估LLM，出现了HoneyHive、HumanLoop等工具。

第4步: 部署和监控

在不同版本之间，LLM的完成度可能会发生巨大变化。例如，OpenAI已经更新了模型，以减少产生不适当的内容(如仇恨言论)。因此，在推特上搜索"as an AI language model"，会发现无数机器人。

这意味着构建LLM驱动的应用程序需要监控底层API模型的变化。

目前已经出现了监控LLM的工具，如Whylabs或HumanLoop。

LLMOps与MLOps有何不同?

MLOps和LLMOps之间的差异是由基于经典ML模型与LLM构建AI产品的差异引起的。这些差异主要影响数据管理、实验、评估、成本和延迟。

数据管理

在经典MLOps中，我们习惯于数据饥渴的ML模型。从头开始训练神经网络需要大量标记数据，甚至微调预训练模型也需要至少几百个样本。虽然数据清理是机器学习开发过程中不可或缺的一部分，但大家都知道并能够接受大型数据集存在的缺陷。

在LLMOps中，微调与MLOps类似。但提示工程是一种零样本或少样本的学习，这意味着只有少量精挑细选的样本。

实验

在MLOps中，无论从头开始训练模型还是对预训练模型进行微调，实验看起来都比较相似。在这两种情况下，都需要跟踪输入(例如模型体系架构、超参数和数据扩展)以及输出(例如度量指标)。

但在LLMOps中，问题在于是进行提示工程还是进行微调。尽管LLMOps和MLOps中的微调看起来很相似，但提示工程需要不同的实验设置(包括提示管理)。

评估

在经典MLOps中，模型性能是在保留验证集上基于评估指标进行评估的。由于LLM的性能更难以评估，目前各组织似乎正在使用A/B测试[5]。

成本

传统MLOps的成本通常在于数据收集和模型训练，而LLMOps的成本在于推理。虽然可以预期在实验过程中使用昂贵的API会带来一些成本，但Chip Huyen认为推理过程中使用的长提示的成本更大。

延迟

在LLM生产调查中，受访者提到的另一个问题是延迟，LLM的完成长度会显著影响延迟。尽管在MLOps中也必须考虑延迟问题，但在LLMOps中这一问题更为突出，而且是影响到开发过程中的实验速度和生产中的用户体验的大问题。

LLMOps的未来

LLMOps是一个新兴领域。随着这一领域的飞速发展，很难做出任何预测，甚至不确定"LLMOps"一词是否会继续存在。唯一能够肯定的是，一定会看到很多LLM新用例、管理LLM生命周期的工具和最佳实践。

AI正在迅速发展，可能会让我们现在写的任何东西很快过时。我们仍处于将LLM驱动的应用投入生产的早期阶段，还有许多问题没有答案，只有时间才能告诉我们一切会如何发展:

• "LLMOps"这个术语会继续存在吗?
• MLOps/LLMOps将如何发展?它们会互相融合还是会独立发展为不同的运维体系?
• AI的"Linux时刻"将如何发展?

可以肯定的说，我们期待看到更多发展，新工具和最佳实践很快就会出现。此外，我们已经看到人们正在努力减少基础模型的成本和延迟。这绝对是有趣的时刻！

总结

自OpenAI的ChatGPT发布以来，LLM是目前AI领域的热门话题。这些深度学习模型可以生成人类语言输出，使其成为会话AI、写作助手和编程助手等任务的强大工具。

然而，将LLM驱动的应用引入生产环境会带来一系列挑战，从而出现了LLMOps这一新术语。它指的是一组用于管理LLM驱动的应用生命周期(包括开发、部署和维护)的工具和最佳实践。

LLMOps可以看作是MLOps的一个子类。然而，构建LLM驱动的应用程序所涉及的步骤与经典ML模型构建应用程序所涉及的步骤不同。

不是从头开始训练LLM，重点是预训练LLM适配下游任务，包括选择基础模型，在下游任务中使用LLM，评估、部署以及监控模型。

虽然LLMOps仍是相对较新的领域，但随着LLM在AI行业的普及，预计将继续发展和演变。总体而言，LLM和LLMOps的兴起代表了构建和维护AI产品的重大转变。

你好，我是俞凡，在Motorola做过研发，现在在Mavenir做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI等技术始终保持着浓厚的兴趣，平时喜欢阅读、思考，相信持续学习、终身成长，欢迎一起交流学习。
微信公众号：DeepNoMind

参考资料