当我们作为用户与 ChatGPT 交互时，只需在网页界面中输入提示词并按回车。通常几秒钟内就会开始收到回复。然而，在这种无缝体验的背后，是一系列复杂且有序的步骤，支持 ChatGPT 呈现这样的使用感受。
这一系列步骤的自动执行，被称为大型语言模型运维（LLMOps），它确保提示词不仅能抵达模型，还能被高效、准确、可靠地处理，从而在合理时间内产出精心组织的回复。
本文将以提示词在类似 ChatGPT 的大型语言模型（LLM）服务中的“旅程”为线索，深入剖析 LLMOps 范式。我们将考察关键阶段，包括提示词预处理、模型选择、响应生成，以及常被忽视却至关重要的环节，如负载均衡、监控与持续集成。
什么是 LLMOps？
LLMOps 确实是广为人知的机器学习运维 （MLOps）的演进，专门应对 LLM 带来的具体挑战。MLOps 侧重通用机器学习模型的全生命周期管理，而 LLMOps 融合了与这类模型独有相关的要素。
需要明确的是，每当我们通过网页界面或在代码中发起 API 调用与 OpenAI 或 Google 的模型交互时，LLMOps 对我们而言都是透明的。在这种情形下，我们称这些模型以“服务”的形式提供（as-a-service）。
另一方面，如果我们的目标是在不依赖外部提供商的情况下，为特定用例提供自有模型，例如为公司员工提供助手，那么 LLMOps 的责任就由我们承担。
无论新模型本身多么强大，其作为服务的成功在很大程度上取决于是否具备稳健可靠的 LLMOps 基础设施。如果您希望进一步了解 MLOps，教程 MLOps Fundamentals 值得一读！
LLMOps 的起源
早期的 LLM，如 GPT-2，于 2018 年问世。但它们真正流行还是近年的事，主要得益于新一代模型（从 GPT-3 起）能力的显著提升。
凭借令人印象深刻的模型能力，基于 LLM 的多种应用应运而生，例如客服聊天机器人 、语言翻译服务、写作与编程助手等。
构建可投入生产的 LLM 应用面临一套不同于传统机器学习模型的独特挑战。为应对这些挑战，人们发展出用于管理 LLM 应用生命周期的新工具与最佳实践，进而形成了“LLMOps”的概念。
为什么需要 LLMOps？
当以服务形式部署这些复杂模型时，LLMOps 对高效管理它们至关重要，原因包括：
1. LLM 不仅在处理数据量上“庞大”，其参数规模也极其可观。LLMOps 确保基础设施在存储与带宽方面能支撑这些模型。
2. 以最短时间获得准确回复对用户至关重要。LLMOps 确保在合理时间内交付响应，维持类人交互的流畅性。
3. LLMOps 下的持续监控不仅是跟踪基础设施的运行与故障，还包括对模型行为的细致跟踪，以理解其决策过程，并为后续迭代改进提供依据。
4. 运行 LLM 可能成本高昂，原因在于所需资源大。LLMOps 引入具性价比的策略，以在不牺牲性能的前提下实现资源的最优使用。
LLM 服务的幕后流程
要理解 LLMOps，需熟悉 LLM 以服务形式提供时的“幕后”。也就是提示词从提交给模型开始直到生成响应所经历的路径。下图示意了这一工作流：
LLMOps 工作流：通用 LLM 即服务的幕后步骤。用户输入（绿色）在送入模型前会经历若干步骤；同样，模型输出（红色）在展示给用户前也会进行多次转换。
如上图所示，提示词在到达模型之前会经历多个步骤。尽管步骤数量可能不同，但有一些基础环节必不可少，例如确保输入被清晰理解、模型的回复具有上下文相关性。让我们逐一拆解这些步骤：
1. 预处理
此步骤为用户的提示词做准备，使模型能够理解并处理。它包括分词 ，即将提示词切分为更小的单元，称为token 。这一步还涉及数据规范化 ，包括移除或转换噪声数据（如特殊字符）、纠正拼写错误以及文本标准化。
最后，在编码 阶段，token 被转换为模型可理解的数值形式。这通常通过嵌入实现，将每个 token 表示为高维空间中的一个向量。
2. 语境接入（Grounding）
这一步通过先前对话轮次或外部知识源对提示词进行情境化 ，以确保模型的回复连贯且符合上下文。此外，实体识别 与链接 有助于系统识别提示词中的实体（如人名、地点、日期），并将其关联到相关语境。
3. 负责任的 AI
为确保 LLM 的使用符合良好目的，一些服务会对用户提示词实施合理性检查。通常会依据安全与合规指南 评估提示词，尤其在涉及敏感信息、不当内容、偏见或潜在错误信息的场景下。
只有在完成这些步骤后，提示词才会被转发给模型进行处理。而在模型生成响应之后、展示给用户之前，响应同样可能再次经历语境接入与负责任 AI 的步骤，以及一个额外的后处理步骤：
4. 后处理
由于此前提到的向量嵌入，模型生成的响应最初是数值形式。因此，需要进行解码 ，将数值数据转换回人类可读的文本。在解码之后，通常还需要进行润色 ，以改进语法、风格或可读性。
最后，响应展示给用户。LLMOps 基础设施负责对用户透明地执行这些步骤。
时延
目前我们已经看到，从用户发送提示词到收到回复，LLMOps 基础设施需要执行相当多的步骤。此时，合情合理的问题是：这些步骤需要多长时间？
在使用 ChatGPT 时，响应时间通常几乎是即时的。这个响应时间被称为时延（latency） 。时延是关键性能指标，尤其在面向用户的应用中，响应时间会显著影响体验。根据用例选择合适的时延至关重要。
为降低响应时延，LLMOps 采用多种策略与最佳实践，以优化从接收输入到交付响应的整个流程。LLMOps 通过自动执行所需步骤、并高效管理所需资源来减少模型时延，避免计算因资源等待而阻塞。其他最佳实践还包括：
缓存： 存储模型输出中常用或计算开销大的部分，避免每次请求都重新计算。并发处理： 并行处理多个请求，例如当多名用户同时发起请求时，更好地利用可用算力，减少等待时间。监控： 对模型与基础设施的不同组件进行性能剖析，尽快识别瓶颈并进行优化。
降低时延不仅能改善用户体验，还能通过优化资源使用提升成本效率。
LLMOps 的关键组件
选择合适的基础模型
到目前为止，我们尚未讨论在 LLMOps 方案中应选择哪种模型。可用模型类型很多，各自针对特定用例进行了优化，且具有不同的规模选项。选择合适的模型至关重要，且在很大程度上取决于我们的应用与可用资源。
此外，LLM 与提供商的数量似乎与日俱增。因此，广泛了解不同类型的 LLM 及其提供商十分有益，尤其是在尝试确定最契合我们用例的那一个时。
LLM 提供商
LLM 模型与提供商可分为以下几类：
专有模型： 此类包括 OpenAI（GPT 系列）、Google（PaLM 系列）与 Anthropic（Claude）等公司，它们训练专有 LLM，并通过网页界面或 API 端点以服务形式提供。开源模型： 此类包括由社区、学术界或 Eleuther AI、Big Science 等组织开发的免费模型。这些组织通常依靠捐助来维持计算基础设施。理想情况下，我们可以采用开源模型并自行构建服务，包括 LLMOps 基础设施。提供基础设施的公司： 这类公司为开源 LLM 提供 LLMOps 基础设施，并通过提供部署服务实现商业化，例如 Together AI。在这里，企业为您提供轻松定制 LLMOps 基础设施的机会。
专有模型 vs 开源模型
开源模型的主要优势在于透明与可定制性。开源模型通常允许对各组件进行完全控制，便于调试，并可通过训练或微调进行深度定制。这种灵活性使 LLM 能更好地契合您的特定需求，而不必受制于提供商预设的选项。
然而，独立管理开源 LLM 会带来显著的工程挑战与计算、存储相关的成本。即便开源模型提供了最低限度的基础设施，在时延、吞吐与推理成本方面，往往也难以与专有模型竞争。
模型选择标准
市面上可选择的模型很多。那我们如何确保选对 LLM 呢？
实际上，可根据用例与条件考虑如下标准：
成本： 不仅要考虑模型推理成本，还应考虑与模型维护、监控、优化相关的工程费用。任务类型： LLM 将用于的任务性质（如摘要、问答等）应与模型能力匹配。已针对目标任务完成微调的模型可在我们进行微调时节省时间与金钱。性能指标： 许多提供商会披露模型的性能指标，如文本生成速度（每个输出 token 的时间，Time Per Output Token）与生成首个 token 所需时间（Time To First Token）。我们应确保模型在我们的用例中表现符合预期。许可协议： 务必选择允许预期用途的模型。即便明确允许商业用途的模型，也可能对特定用例有约束。例如，BigScience 的 Open RAIL-M 许可对执法、移民与庇护等相关领域的使用设有限制。
微调策略
无论是专有还是开源，LLM 往往需要微调才能真正适配特定应用。
一些面向特定任务的预微调 LLM 已可用，常见于聊天模型、摘要或情感分析专用模型。另一个值得考虑的变体是长上下文模型。现代 LLM 通常能处理 2,000 至 8,000 个 token 的上下文，意味着超出该范围的输入与输出无法直接处理。不过，部分模型提供长上下文变体。例如，GPT-3.5 就有更大的 16k 上下文版本。
然而，若现有选项仍无法满足特定需求，始终可以选择自行微调，甚至从零开始训练模型。在此情形下，选择合适的数据集至关重要，它能让模型理解目标任务的特性。
如果您有兴趣从零训练 LLM，强烈推荐阅读 DataCamp 教程 How to train an LLM with PyTorch 。
模型定制
如果我们的应用需要对现有模型进行微调，相关步骤也应纳入 LLMOps 方案。让我们把定制步骤添加到最初的图示中：
LLMOps 工作流：在通用工作流中加入模型定制步骤（橙色）。
建立一致的微调流水线，有助于随着数据增多持续扩展模型知识，并让您能够轻松升级 LLM 版本或做出其他修改。
在依赖第三方模型时，需要注意这些模型的可用性与成本可能发生变化，这可能迫使我们切换到不同的基础模型。稳健的 LLMOps 配置将使我们能够平稳应对这一关键情形，仅需将“模型”模块替换为另一个 LLM。
训练数据
有人可能认为，对 LLM 进行微调或从零训练是 LLMOps 基础设施之外的第一步，因为 LLM 只有在部署生产后才会运行。然而事实并非如此，尤其考虑到上述原因：成功的服务需要在必要时改进模型，并对提供商变动具有弹性。
在通用 LLMOps 基础设施中，为实现高效的训练、微调或模型优化，保持训练数据与后续推理数据的格式一致非常重要。为此，我们通常采用 JSON Lines（.jsonl）格式来组织训练数据。该格式因其结构而非常适合用于 LLM 微调，能够高效处理大型数据集。一个典型的用于微调的 .jsonl 文件可能如下所示：
{ "prompt" : "Question: What is the capital of France?" , "completion" : "The capital of France is Paris." }
{ "prompt" : "Question: Who wrote Macbeth?" , "completion" : "Macbeth was written by William Shakespeare." } 技术支持 .jsonl 文件中的每一行是一个独立的 JSON 对象，代表一个训练样本，其中 prompt 与 completion 键分别表示输入文本与期望的模型响应，正如我们在推理时所期望的那样。此外，这种格式也便于将新数据逐步加入到模型的知识库中。
训练与推理参数
在搭建 LLMOps 基础设施时，模型参数同样重要，因为它们会影响模型规模与资源消耗等特性。
关于训练参数，需进行优化以在模型复杂度与部署限制（如内存使用）之间取得平衡。这对在资源能力各异的环境中部署模型至关重要，确保模型不仅先进，而且切实可用于真实世界应用。
关于推理参数，调整 temperature、max tokens 等可控制回复的长度与随机性。这些设置作为 LLMOps 流程的一部分进行管理，以使模型输出与具体应用需求和用户意图保持一致。
提示工程与管理
实践表明，提示工程技术可以增强 LLM 的默认能力。原因之一在于它们有助于为模型提供语境。例如，指示模型以某一领域专家的身份行事，或引导模型生成期望的输出。提示工程与管理是我们 LLMOps 方案中必不可少的组成部分。
最有效的提示工程实践包括小样本提示（few-shot prompting） 与链式思维（chain-of-thought）推理 。我们简要回顾这些技术，并讨论如何将它们融入 LLMOps：
小样本提示 是在提示中直接提供少量（shot）任务示例，帮助模型更有效地理解并执行特定任务。链式思维推理 是将提示结构化，引导模型按步骤进行推理。该技术对需要逻辑推理或与外部来源交互的复杂任务尤为有用。
在 LLMOps 中，使用提示模板可有效实现如小样本提示与链式思维推理等技术。
提示模板
提示模板是用于引导 LLM 推理的预定义结构。它们提供一致的结构，确保类似请求以统一方式发出，或在对用户透明的前提下融入提示工程技术。
在 LLMOps 方案中，开发与管理覆盖多种用例的高质量提示模板库至关重要。为特定用例选择合适的提示模板通常是在将查询发送给模型之前，于预处理阶段执行的预备步骤。
对于小样本提示，模板应包含若干示例，展示期望模型执行的任务或回复风格。类似地，如需纳入链式思维推理，提示模板应精心设计，包含循序渐进的思考过程。本质上，它们应引导模型如何有条不紊地处理并将问题分解为更简单、可管理的步骤。
在链式思维推理中引入外部知识可能是其中的一步，这在诸如 LangChain 等框架中尤为有用，在这类框架里，当模型的既有知识不足时，会指示其从互联网检索信息。
在小样本提示与链式思维推理中，采用提示的 A/B 测试 非常有益。也就是通过让不同用户子集接触不同版本的提示来开展对照实验，客观衡量其表现，并据结果选择最有效的版本。此外，在这两种情形下，都应依赖性能数据迭代改进我们的提示模板。
部署与监控
当基础模型训练或微调完成且结果令人满意时，就到了部署模型的阶段。在 LLMOps 语境下，模型部署指的是将语言模型在生产环境中可用的过程。这涉及将模型从训练环境迁移并集成到生产基础设施中。该步骤在我们的常规图示中以橙色标注：
LLMOps 工作流：在通用工作流中突出显示部署步骤（橙色）。该步骤涉及将模型从开发环境“移至”生产环境。
部署还包括设置我们在生产中与模型通信所用的接口。通常，接口取决于处理模式：
实时处理： 对于需要实时交互的应用（如聊天应用），必须以能够即时处理数据并生成输出的方式部署模型。这通常通过创建与模型对接的应用程序编程接口（API）实现。如今有如 Flask 等库，可让我们以简单步骤创建 API 接口。
API 可部署在 Web 服务器或云平台上，确保需要与模型交互的用户或系统能够访问。我们的 LLMOps 方案应确保 API 能处理预期负载，并考虑扩展、负载均衡与故障转移机制。
批量预测： 在许多用例中，并不需要实时预测。例如，如果我们每周需要对一批客户评论进行分类，可以使用已训练模型分批处理这些评论。对于不敏感于时间的任务，此方式高效且节省资源。
对于批处理用例，您可以使用 cron（类 Unix 系统）或基于云的作业调度服务安排批量作业。这些作业会在指定时间运行模型处理新数据，并存储结果。
最后，将模型部署到生产环境通常涉及模型打包与版本管理：
打包 是将模型及其依赖封装为便于在生产环境中部署与使用的形式。这可能涉及 Docker 等容器化技术，将模型与其运行环境封装起来，确保跨平台一致性。模型版本管理： 记录模型的不同版本至关重要，尤其在您更新或重新训练模型时。版本管理有助于清晰追踪模型迭代、训练数据与提示模板。
CI/CD 流水线
持续集成（CI）与持续交付（CD）流水线可自动化将模型从开发环境带入生产的各个步骤，确保模型可靠、及时更新且高效部署。
在 LLMOps 中，当有新代码或更改引入模型（如超参数调优、模型架构变更或新训练数据）时，CI 会确保这些更改自动接受测试。这包括运行单元测试、集成测试以及其他检查，以验证更改不会破坏模型或降低其性能。从这个意义上说，CI 也是持续监控模型的一种方式。
一旦更改在 CI 阶段通过所有测试，CD 会将模型自动部署到生产环境，确保在 LLMOps 生产体系中始终运行最稳定、经过测试的版本。若在生产环境发现问题，CD 还便于快速回滚至先前版本，最大限度减少停机并确保服务可靠性。
编排
最后，还有一个尚未讨论的方面：我们如何对 LLMOps 组件进行排序，以形成合理的步骤链？
编排涉及在 LLMOps 方案中定义与管理操作顺序，形成所谓的工作流。例如，定义前后处理步骤的顺序，或新模型在可部署前必须通过的各类测试顺序。
在 LLM 语境中，编排通常涉及在工作流的不同组件之间传递数据。这常通过指定数据路径或工作空间来管理，即一个步骤的输出被存储，随后由下一个步骤读取。
编排通常通过配置文件 管理，常用 YAML（Yet Another Markup Language）编写。这些文件定义组件、其顺序以及每一步的参数。领域特定语言（DSL）常用于这些配置文件，为定义工作流提供更直观、专业的语法。
最后，工作流通常会被自动化。这确保一旦工作流启动，所有相关步骤都能从一个环节顺畅衔接到下一个环节，减少手动执行任务的需要，避免问题。
LLMOps 的高级技术
本文讨论了 LLMOps 基础设施的关键组成与其存在的理由。不过，还有其他高级技术可进一步提升 LLMOps 基础设施的性能：
高性能资源： 使用 GPU 或 TPU 等高性能计算资源可显著加速推理、降低时延，相较于仅使用 CPU 效果更佳。在搭建 LLMOps 基础设施时，应谨慎选择硬件。负载均衡： 如果我们计划像 ChatGPT 一样在不同国家提供广泛使用的服务，建议部署同一模型的多个实例。这样可以将传入请求分布到多个模型上。我们的 LLMOps 方案应随时掌握可用模型的数量与各自的算力状况。地理分布： 此外，若在不同国家部署了多个模型，一个直接的策略是将模型——以及 LLMOps 基础设施的必要部分——部署在更接近终端用户的位置。这涉及优化数据序列化与传输协议，以确保用户、基础设施与模型之间的数据传输快速高效。
应对安全问题
在我们的 LLMOps 基础设施中确保数据隐私与用户保护，是构建可信服务的核心。
例如，实施稳健的数据匿名化技术 至关重要。可以采用差分隐私、k-匿名或数据掩码等技术，确保训练数据不会暴露在构建训练集时收集的敏感个人信息。此外，若我们计划用真实世界数据迭代改进模型，应提前告知用户，并在将其纳入微调环节前对数据进行匿名化处理。
另一个安全相关方面是，如果我们计划在系统中存储任何私密用户信息（如 ChatGPT 的对话历史）。在这种情况下，必须确保所有数据得到安全处理，并遵守 GDPR 等数据保护法规。这包括在基础设施中确保数据安全存储与传输加密。
最后，我们必须在 LLMOps 基础设施中确保健全的访问控制，确保只有授权人员可以访问模型、数据与训练环境，避免任何泄露用户个人信息的风险。
结语
自去年以来，由于新一代 LLM 能力的增强，基于 LLM 的应用迅速崛起。这些应用以“服务”的形式交付 LLM，因此需要一套稳健的管理与优化框架，即 LLMOps 基础设施。
本文探讨了 LLMOps 作为成功、高效、以客户为中心的 LLM 服务支柱所发挥的关键作用。首先，我们回顾了提示词从用户发出到接收回复的全过程。LLMOps 确保所有这些“幕后”步骤得以顺畅高效地完成。
其次，我们考察了 LLMOps 如何涵盖模型训练、部署、监控与维护。LLMOps 还包括对资源的扩缩容，以高效应对不同负载，从而保证基于 LLM 的应用具备可扩展性与可靠性。此外，我们也点到了用于优化 LLMOps 基础设施的高级最佳实践。
最后，我们认识到 LLMOps 也参与维护以服务形式提供的 LLM 的完整性与安全性。由于这些模型经常处理敏感数据，健全的 LLMOps 实践对于实施严格的安全措施至关重要，以确保数据隐私与合规。
总之，读完本文，我希望已向您传达这样一个重要观点：LLMOps 不仅是运营必需，更是战略资产，能够提升以服务形式提供的 LLM 的价值、可靠性与可持续性。
准备将理论付诸实践？通过我们的动手教程深入探索大型语言模型世界：“How to Build LLM Applications with LangChain” 。从今天起，将您的知识转化为可操作的技能！
当我们作为用户与 ChatGPT 交互时，只需在网页界面中输入提示词并按回车。通常几秒钟内就会开始收到回复。然而，在这种无缝体验的背后，是一系列复杂且有序的步骤，支持 ChatGPT 呈现这样的使用感受。
这一系列步骤的自动执行，被称为大型语言模型运维（LLMOps），它确保提示词不仅能抵达模型，还能被高效、准确、可靠地处理，从而在合理时间内产出精心组织的回复。
本文将以提示词在类似 ChatGPT 的大型语言模型（LLM）服务中的“旅程”为线索，深入剖析 LLMOps 范式。我们将考察关键阶段，包括提示词预处理、模型选择、响应生成，以及常被忽视却至关重要的环节，如负载均衡、监控与持续集成。
什么是 LLMOps？
LLMOps 确实是广为人知的机器学习运维（MLOps）的演进，专门应对 LLM 带来的具体挑战。MLOps 侧重通用机器学习模型的全生命周期管理，而 LLMOps 融合了与这类模型独有相关的要素。
需要明确的是，每当我们通过网页界面或在代码中发起 API 调用与 OpenAI 或 Google 的模型交互时，LLMOps 对我们而言都是透明的。在这种情形下，我们称这些模型以“服务”的形式提供（as-a-service）。
另一方面，如果我们的目标是在不依赖外部提供商的情况下，为特定用例提供自有模型，例如为公司员工提供助手，那么 LLMOps 的责任就由我们承担。
无论新模型本身多么强大，其作为服务的成功在很大程度上取决于是否具备稳健可靠的 LLMOps 基础设施。如果您希望进一步了解 MLOps，教程 MLOps Fundamentals 值得一读！
LLMOps 的起源
早期的 LLM，如 GPT-2，于 2018 年问世。但它们真正流行还是近年的事，主要得益于新一代模型（从 GPT-3 起）能力的显著提升。
凭借令人印象深刻的模型能力，基于 LLM 的多种应用应运而生，例如客服聊天机器人、语言翻译服务、写作与编程助手等。
构建可投入生产的 LLM 应用面临一套不同于传统机器学习模型的独特挑战。为应对这些挑战，人们发展出用于管理 LLM 应用生命周期的新工具与最佳实践，进而形成了“LLMOps”的概念。
为什么需要 LLMOps？
当以服务形式部署这些复杂模型时，LLMOps 对高效管理它们至关重要，原因包括：
1. LLM 不仅在处理数据量上“庞大”，其参数规模也极其可观。LLMOps 确保基础设施在存储与带宽方面能支撑这些模型。
2. 以最短时间获得准确回复对用户至关重要。LLMOps 确保在合理时间内交付响应，维持类人交互的流畅性。
3. LLMOps 下的持续监控不仅是跟踪基础设施的运行与故障，还包括对模型行为的细致跟踪，以理解其决策过程，并为后续迭代改进提供依据。
4. 运行 LLM 可能成本高昂，原因在于所需资源大。LLMOps 引入具性价比的策略，以在不牺牲性能的前提下实现资源的最优使用。
LLM 服务的幕后流程
要理解 LLMOps，需熟悉 LLM 以服务形式提供时的“幕后”。也就是提示词从提交给模型开始直到生成响应所经历的路径。下图示意了这一工作流：
LLMOps 工作流：通用 LLM 即服务的幕后步骤。用户输入（绿色）在送入模型前会经历若干步骤；同样，模型输出（红色）在展示给用户前也会进行多次转换。
如上图所示，提示词在到达模型之前会经历多个步骤。尽管步骤数量可能不同，但有一些基础环节必不可少，例如确保输入被清晰理解、模型的回复具有上下文相关性。让我们逐一拆解这些步骤：
1. 预处理
此步骤为用户的提示词做准备，使模型能够理解并处理。它包括分词，即将提示词切分为更小的单元，称为token。这一步还涉及数据规范化，包括移除或转换噪声数据（如特殊字符）、纠正拼写错误以及文本标准化。
最后，在编码阶段，token 被转换为模型可理解的数值形式。这通常通过嵌入实现，将每个 token 表示为高维空间中的一个向量。
2. 语境接入（Grounding）
这一步通过先前对话轮次或外部知识源对提示词进行情境化，以确保模型的回复连贯且符合上下文。此外，实体识别与链接有助于系统识别提示词中的实体（如人名、地点、日期），并将其关联到相关语境。
3. 负责任的 AI
为确保 LLM 的使用符合良好目的，一些服务会对用户提示词实施合理性检查。通常会依据安全与合规指南评估提示词，尤其在涉及敏感信息、不当内容、偏见或潜在错误信息的场景下。
只有在完成这些步骤后，提示词才会被转发给模型进行处理。而在模型生成响应之后、展示给用户之前，响应同样可能再次经历语境接入与负责任 AI 的步骤，以及一个额外的后处理步骤：
4. 后处理
由于此前提到的向量嵌入，模型生成的响应最初是数值形式。因此，需要进行解码，将数值数据转换回人类可读的文本。在解码之后，通常还需要进行润色，以改进语法、风格或可读性。
最后，响应展示给用户。LLMOps 基础设施负责对用户透明地执行这些步骤。
时延
目前我们已经看到，从用户发送提示词到收到回复，LLMOps 基础设施需要执行相当多的步骤。此时，合情合理的问题是：这些步骤需要多长时间？
在使用 ChatGPT 时，响应时间通常几乎是即时的。这个响应时间被称为时延（latency）。时延是关键性能指标，尤其在面向用户的应用中，响应时间会显著影响体验。根据用例选择合适的时延至关重要。
为降低响应时延，LLMOps 采用多种策略与最佳实践，以优化从接收输入到交付响应的整个流程。LLMOps 通过自动执行所需步骤、并高效管理所需资源来减少模型时延，避免计算因资源等待而阻塞。其他最佳实践还包括：
降低时延不仅能改善用户体验，还能通过优化资源使用提升成本效率。
LLMOps 的关键组件
选择合适的基础模型
到目前为止，我们尚未讨论在 LLMOps 方案中应选择哪种模型。可用模型类型很多，各自针对特定用例进行了优化，且具有不同的规模选项。选择合适的模型至关重要，且在很大程度上取决于我们的应用与可用资源。
此外，LLM 与提供商的数量似乎与日俱增。因此，广泛了解不同类型的 LLM 及其提供商十分有益，尤其是在尝试确定最契合我们用例的那一个时。
LLM 提供商
LLM 模型与提供商可分为以下几类：
专有模型 vs 开源模型
开源模型的主要优势在于透明与可定制性。开源模型通常允许对各组件进行完全控制，便于调试，并可通过训练或微调进行深度定制。这种灵活性使 LLM 能更好地契合您的特定需求，而不必受制于提供商预设的选项。
然而，独立管理开源 LLM 会带来显著的工程挑战与计算、存储相关的成本。即便开源模型提供了最低限度的基础设施，在时延、吞吐与推理成本方面，往往也难以与专有模型竞争。
模型选择标准
市面上可选择的模型很多。那我们如何确保选对 LLM 呢？
实际上，可根据用例与条件考虑如下标准：
微调策略
无论是专有还是开源，LLM 往往需要微调才能真正适配特定应用。
一些面向特定任务的预微调 LLM 已可用，常见于聊天模型、摘要或情感分析专用模型。另一个值得考虑的变体是长上下文模型。现代 LLM 通常能处理 2,000 至 8,000 个 token 的上下文，意味着超出该范围的输入与输出无法直接处理。不过，部分模型提供长上下文变体。例如，GPT-3.5 就有更大的 16k 上下文版本。
然而，若现有选项仍无法满足特定需求，始终可以选择自行微调，甚至从零开始训练模型。在此情形下，选择合适的数据集至关重要，它能让模型理解目标任务的特性。
如果您有兴趣从零训练 LLM，强烈推荐阅读 DataCamp 教程 How to train an LLM with PyTorch。
模型定制
如果我们的应用需要对现有模型进行微调，相关步骤也应纳入 LLMOps 方案。让我们把定制步骤添加到最初的图示中：
LLMOps 工作流：在通用工作流中加入模型定制步骤（橙色）。
建立一致的微调流水线，有助于随着数据增多持续扩展模型知识，并让您能够轻松升级 LLM 版本或做出其他修改。
在依赖第三方模型时，需要注意这些模型的可用性与成本可能发生变化，这可能迫使我们切换到不同的基础模型。稳健的 LLMOps 配置将使我们能够平稳应对这一关键情形，仅需将“模型”模块替换为另一个 LLM。
训练数据
有人可能认为，对 LLM 进行微调或从零训练是 LLMOps 基础设施之外的第一步，因为 LLM 只有在部署生产后才会运行。然而事实并非如此，尤其考虑到上述原因：成功的服务需要在必要时改进模型，并对提供商变动具有弹性。
在通用 LLMOps 基础设施中，为实现高效的训练、微调或模型优化，保持训练数据与后续推理数据的格式一致非常重要。为此，我们通常采用 JSON Lines（
.jsonl）格式来组织训练数据。该格式因其结构而非常适合用于 LLM 微调，能够高效处理大型数据集。一个典型的用于微调的.jsonl文件可能如下所示：.jsonl文件中的每一行是一个独立的 JSON 对象，代表一个训练样本，其中prompt与completion键分别表示输入文本与期望的模型响应，正如我们在推理时所期望的那样。此外，这种格式也便于将新数据逐步加入到模型的知识库中。训练与推理参数
在搭建 LLMOps 基础设施时，模型参数同样重要，因为它们会影响模型规模与资源消耗等特性。
关于训练参数，需进行优化以在模型复杂度与部署限制（如内存使用）之间取得平衡。这对在资源能力各异的环境中部署模型至关重要，确保模型不仅先进，而且切实可用于真实世界应用。
关于推理参数，调整 temperature、max tokens 等可控制回复的长度与随机性。这些设置作为 LLMOps 流程的一部分进行管理，以使模型输出与具体应用需求和用户意图保持一致。
提示工程与管理
实践表明，提示工程技术可以增强 LLM 的默认能力。原因之一在于它们有助于为模型提供语境。例如，指示模型以某一领域专家的身份行事，或引导模型生成期望的输出。提示工程与管理是我们 LLMOps 方案中必不可少的组成部分。
最有效的提示工程实践包括小样本提示（few-shot prompting）与链式思维（chain-of-thought）推理。我们简要回顾这些技术，并讨论如何将它们融入 LLMOps：
在 LLMOps 中，使用提示模板可有效实现如小样本提示与链式思维推理等技术。
提示模板
提示模板是用于引导 LLM 推理的预定义结构。它们提供一致的结构，确保类似请求以统一方式发出，或在对用户透明的前提下融入提示工程技术。
在 LLMOps 方案中，开发与管理覆盖多种用例的高质量提示模板库至关重要。为特定用例选择合适的提示模板通常是在将查询发送给模型之前，于预处理阶段执行的预备步骤。
对于小样本提示，模板应包含若干示例，展示期望模型执行的任务或回复风格。类似地，如需纳入链式思维推理，提示模板应精心设计，包含循序渐进的思考过程。本质上，它们应引导模型如何有条不紊地处理并将问题分解为更简单、可管理的步骤。
在链式思维推理中引入外部知识可能是其中的一步，这在诸如 LangChain 等框架中尤为有用，在这类框架里，当模型的既有知识不足时，会指示其从互联网检索信息。
在小样本提示与链式思维推理中，采用提示的 A/B 测试非常有益。也就是通过让不同用户子集接触不同版本的提示来开展对照实验，客观衡量其表现，并据结果选择最有效的版本。此外，在这两种情形下，都应依赖性能数据迭代改进我们的提示模板。
部署与监控
当基础模型训练或微调完成且结果令人满意时，就到了部署模型的阶段。在 LLMOps 语境下，模型部署指的是将语言模型在生产环境中可用的过程。这涉及将模型从训练环境迁移并集成到生产基础设施中。该步骤在我们的常规图示中以橙色标注：
LLMOps 工作流：在通用工作流中突出显示部署步骤（橙色）。该步骤涉及将模型从开发环境“移至”生产环境。
部署还包括设置我们在生产中与模型通信所用的接口。通常，接口取决于处理模式：
API 可部署在 Web 服务器或云平台上，确保需要与模型交互的用户或系统能够访问。我们的 LLMOps 方案应确保 API 能处理预期负载，并考虑扩展、负载均衡与故障转移机制。
对于批处理用例，您可以使用 cron（类 Unix 系统）或基于云的作业调度服务安排批量作业。这些作业会在指定时间运行模型处理新数据，并存储结果。
最后，将模型部署到生产环境通常涉及模型打包与版本管理：
CI/CD 流水线
持续集成（CI）与持续交付（CD）流水线可自动化将模型从开发环境带入生产的各个步骤，确保模型可靠、及时更新且高效部署。
在 LLMOps 中，当有新代码或更改引入模型（如超参数调优、模型架构变更或新训练数据）时，CI 会确保这些更改自动接受测试。这包括运行单元测试、集成测试以及其他检查，以验证更改不会破坏模型或降低其性能。从这个意义上说，CI 也是持续监控模型的一种方式。
一旦更改在 CI 阶段通过所有测试，CD 会将模型自动部署到生产环境，确保在 LLMOps 生产体系中始终运行最稳定、经过测试的版本。若在生产环境发现问题，CD 还便于快速回滚至先前版本，最大限度减少停机并确保服务可靠性。
编排
最后，还有一个尚未讨论的方面：我们如何对 LLMOps 组件进行排序，以形成合理的步骤链？
编排涉及在 LLMOps 方案中定义与管理操作顺序，形成所谓的工作流。例如，定义前后处理步骤的顺序，或新模型在可部署前必须通过的各类测试顺序。
在 LLM 语境中，编排通常涉及在工作流的不同组件之间传递数据。这常通过指定数据路径或工作空间来管理，即一个步骤的输出被存储，随后由下一个步骤读取。
编排通常通过配置文件管理，常用 YAML（Yet Another Markup Language）编写。这些文件定义组件、其顺序以及每一步的参数。领域特定语言（DSL）常用于这些配置文件，为定义工作流提供更直观、专业的语法。
最后，工作流通常会被自动化。这确保一旦工作流启动，所有相关步骤都能从一个环节顺畅衔接到下一个环节，减少手动执行任务的需要，避免问题。
LLMOps 的高级技术
本文讨论了 LLMOps 基础设施的关键组成与其存在的理由。不过，还有其他高级技术可进一步提升 LLMOps 基础设施的性能：
应对安全问题
在我们的 LLMOps 基础设施中确保数据隐私与用户保护，是构建可信服务的核心。
例如，实施稳健的数据匿名化技术至关重要。可以采用差分隐私、k-匿名或数据掩码等技术，确保训练数据不会暴露在构建训练集时收集的敏感个人信息。此外，若我们计划用真实世界数据迭代改进模型，应提前告知用户，并在将其纳入微调环节前对数据进行匿名化处理。
另一个安全相关方面是，如果我们计划在系统中存储任何私密用户信息（如 ChatGPT 的对话历史）。在这种情况下，必须确保所有数据得到安全处理，并遵守 GDPR 等数据保护法规。这包括在基础设施中确保数据安全存储与传输加密。
最后，我们必须在 LLMOps 基础设施中确保健全的访问控制，确保只有授权人员可以访问模型、数据与训练环境，避免任何泄露用户个人信息的风险。
结语
自去年以来，由于新一代 LLM 能力的增强，基于 LLM 的应用迅速崛起。这些应用以“服务”的形式交付 LLM，因此需要一套稳健的管理与优化框架，即 LLMOps 基础设施。
本文探讨了 LLMOps 作为成功、高效、以客户为中心的 LLM 服务支柱所发挥的关键作用。首先，我们回顾了提示词从用户发出到接收回复的全过程。LLMOps 确保所有这些“幕后”步骤得以顺畅高效地完成。
其次，我们考察了 LLMOps 如何涵盖模型训练、部署、监控与维护。LLMOps 还包括对资源的扩缩容，以高效应对不同负载，从而保证基于 LLM 的应用具备可扩展性与可靠性。此外，我们也点到了用于优化 LLMOps 基础设施的高级最佳实践。
最后，我们认识到 LLMOps 也参与维护以服务形式提供的 LLM 的完整性与安全性。由于这些模型经常处理敏感数据，健全的 LLMOps 实践对于实施严格的安全措施至关重要，以确保数据隐私与合规。
总之，读完本文，我希望已向您传达这样一个重要观点：LLMOps 不仅是运营必需，更是战略资产，能够提升以服务形式提供的 LLM 的价值、可靠性与可持续性。
准备将理论付诸实践？通过我们的动手教程深入探索大型语言模型世界：“How to Build LLM Applications with LangChain”。从今天起，将您的知识转化为可操作的技能！