随着 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
很明显，与基于经典 ML 模型构建 AI 产品不同，构建生产就绪的 LLM 驱动的应用程序有其自身的一系列挑战。为了应对这些挑战，需要新的工具和最佳实践来管理 LLM 应用程序生命周期。因此，我们看到术语"LLMOps"出现频率越来越高。
LLMOps 包括哪些步骤?
LLMOps 涉及的步骤与 MLOps 相似。然而，由于基础模型的出现，构建 LLM 驱动的应用程序的步骤有所不同。与从头开始训练 LLM 不同，重点在于让预训练的 LLM 适配下游任务。
早在一年多前，Andrej Karpathy就描述了未来如何构建 AI 产品的过程:
但最重要的趋势是，...，在某些目标任务上从头训练神经网络的方式很快就会因为微调而过时。尤其是随着 GPT 等基础模型的出现，这些基础模型仅由少数具有大量计算资源的机构进行训练，大多数应用只需要通过对部分网络进行轻量级微调、快速工程、将数据或模型蒸馏为更小、专用的推理网络的可选步骤来实现。—— Andrej Karpathy
当你第一次读到这句话时，可能会感到不知所措。但它精确总结了所发生的一切，所以我们会在后续将其逐步拆解。
第 1 步: 选择基础模型
基础模型是基于大量数据预先训练的 LLM，可用于广泛的下游任务。由于从头开始训练基础模型及其复杂、耗时且成本极高，只有少数机构拥有所需的训练资源。
比方说，根据Lambda实验室在2020年的一项研究，基于 Tesla V100 云实例训练 OpenAI 的 GPT-3(有 1750 亿个参数)需要 355 年和 460 万美元。
AI 目前正在经历社区所谓的"Linux时刻"。目前，开发人员必须基于性能、成本、易用性和灵活性，在两种类型的基础模型(专有模型或开源模型)之间做出选择。
专有模型是由拥有大型专家团队和大量预算的公司拥有的闭源基础模型，通常比开源模型更大，因此具有更好的性能。由于是现成的模型，因此很容易使用。
专有模型的主要缺点是 API 费用昂贵。此外，闭源基础模型为开发人员提供的灵活性很少或者根本没有灵活性。
专有模型供应商有:
开源模型通常在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为例，将提示词输入 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
