generative-ai-for-beginners 课程第 14 课：掌握生成式 AI 应用生命周期（LLMOps）——从 MLOps 范式转变到评估指标、工作流与工具链

生成式 AI 是一个快速演化的领域，仅完成一次开发和部署远不足以让应用长期保持相关、可靠和健壮。本文基于 generative-ai-for-beginners 课程 第 14 课文档，系统讲解生成式 AI 应用生命周期（LLMOps）：理解从 MLOps 到 LLMOps 的范式转变、掌握“构思—构建—运营”三大阶段的工作流、熟悉 Quality / Harm / Honesty / Cost / Latency 五维评估指标，以及配套的 LLMOps 工具链，最终帮助读者为自己的 LLM 应用建立一套可持续监控、评估与改进的运维方法论。

为什么需要生成式 AI 应用生命周期

原文档开篇提出了一个对每个 AI 应用都至关重要的问题：AI 能力的相关性（relevance）如何长期保持？由于 AI 技术演进极快，模型会迭代、用户预期会变化、成本与合规约束也会调整，因此要确保应用始终保持相关、可靠和健壮，就必须持续地监控（monitor）、评估（evaluate）和持续改进（improve）应用。这正是生成式 AI 生命周期（generative AI lifecycle）要解决的问题。

原文档对生成式 AI 生命周期给出了明确的框架定义：

• 它是一个指导框架，覆盖生成式 AI 应用的**开发（developing）、部署（deploying）和维护（maintaining）**全过程；
• 它帮助你定义目标、度量性能、识别挑战、实施解决方案；
• 它还帮助你将应用与所在领域及利益相关方的伦理与法律标准对齐；
• 遵循该生命周期，可以确保应用持续交付价值并满足用户需求。

学习目标

按原文档 Introduction 一节，学完本课题材后，读者应当能够：

1. 理解从 MLOps 到 LLMOps 的范式转变（Paradigm Shift）；
2. 掌握 LLM 生命周期（LLM Lifecycle）的完整结构与各环节含义；
3. 了解生命周期工具链（Lifecycle Tooling）的实际组成；
4. 掌握生命周期的度量化与评估方式（Lifecycle Metrification and Evaluation）。

理解从 MLOps 到 LLMOps 的范式转变

LLM 是人工智能工具箱中的新工具：在分析类与生成类任务上它极为强大，但这种能力也直接改变了我们组织 AI 应用与经典机器学习任务的方式——原有的工作流和激励机制不再完全适配。

原文档给出的观点是：我们引入一个“新范式”（new Paradigm）来动态地适配这一工具，并以当时主流的技术和技巧为界，把较早的 AI 应用归为 “ML Apps”，把较新的 AI 应用归为 “GenAI Apps”（或统称 “AI Apps”）。这种重新分类会从多个方面改变团队的叙事与关注点，原文档配有一张 LLMOps 与 MLOps 的对比图：

对比图传递出的核心信息是：在 LLMOps 中，工作重心更加偏向应用开发者（App Developers），以**集成（integrations）**为关键点，采用“Models-as-a-Service（模型即服务）”的方式获取模型能力，并在指标上关注以下五个维度（原文档原文列举）：

指标	原文定义	课程上下文中的落地含义
Quality（质量）	响应质量（Response quality）	模型输出对用户请求的准确性与相关性，可结合提示词工程、RAG 或微调逐步提升（参见课程 第 4 课提示词工程 与 第 18 课微调）
Harm（危害）	负责任 AI（Responsible AI）	输出是否公平、无有害内容，与课程 第 3 课负责任使用生成式 AI 中讨论的幻觉、有害内容等风险直接对应
Honesty（诚实）	响应 groundedness——回答是否讲得通、是否正确	即“接地性/有据可依”，可通过检索增强生成（第 15 课 RAG 与向量数据库）让回答基于真实检索到的数据
Cost（成本）	解决方案预算（Solution Budget）	LLM 推理按 token 计费，成本是架构选型与提示词设计的硬约束
Latency（延迟）	平均 token 响应时间（Avg. time for token response）	面向交互型应用（如聊天、辅导场景），平均 token 响应时间决定用户体验

与经典 MLOps 主要围绕模型训练流水线（数据、训练、评估、部署、监控）打转不同，LLMOps 把“应用体验的五维指标”提到了一级地位——因为模型往往是“拿来即用”的云服务，应用层的提示词、检索、集成与运维才是可控变量。

LLM 生命周期全景：与 MLOps 有什么不同

原文档先用一张 LLMOps 信息图勾勒完整生命周期，再逐段解读：

原文档明确指出，这个生命周期与 MLOps 的常规生命周期不同，因为 LLM 带来了一系列新需求：

• Prompting（提示词工程）：提示词成为对模型的主要“编程接口”，是独立于模型训练之外的关键工程对象；
• 提升质量的不同技术手段：Fine-Tuning（微调）、RAG（检索增强生成）、Meta-Prompts（元提示词）等，构成了 MLOps 时代不存在的一组“应用侧增强技术”；
• 不同的评估与责任方式：负责任 AI（responsible AI）成为评估环节的一等公民；
• 新的评估指标：即上一节列出的 Quality、Harm、Honesty、Cost、Latency 五维指标。

原文档接着举了一个具体例子说明“构思（ideate）”阶段：在探索期，团队会使用提示词工程对多种 LLM 进行实验，探索可能性，验证某个业务假设（Hypothesis）是否成立。这正对应课程前几课反复出现的“沙箱实验”思路，例如 第 4 课提示词工程基础 中提供的 Jupyter Notebook 沙箱环境，让开发者在真实端点上以“试错”方式打磨提示词与模型选择。

原文档特别强调的一点是：这个过程不是线性的（not linear），而是相互集成的循环（integrated loops）——迭代式推进，并被一个更大的总周期（overarching cycle）所笼罩。 换句话说，评估不达标时可以从任何环节回退重做，而整体的管理（management）循环始终在顶层监督安全、合规与治理。

三大核心阶段工作流详解

原文档给出了一张 LLMOps 工作流图，随后建议读者“先抓住三大步骤”：

阶段一：构思与探索（Ideating / Exploring）

• 做什么：根据业务需求进行探索（explore according to business needs）。
• 原型验证：创建一个 PromptFlow 原型（PromptFlow 是微软开源的提示词工作流工具），测试它对当前业务假设是否足够高效（efficient enough for our Hypothesis）。
• 课程对应实践：这一阶段最直接的落地方式，就是课程 第 4 课 和 第 5 课高级提示词 中演示的提示词实验——在 Azure OpenAI / OpenAI 端点上快速切换模型、调整提示词结构，验证假设是否成立。

阶段二：构建与增强（Building / Augmenting）

• 做什么：进入实现（Implementation），开始在更大的数据集上评估方案，并实施提升技术（implement techniques）。
• 关键技术：原文档点名的两个方向是 Fine-tuning（微调） 与 RAG（检索增强生成），用于检验解决方案的健壮性（robustness）。这正好对应课程的 第 18 课 LLM 微调——通过为特定任务/领域准备精选样例重训模型，以及 第 15 课 RAG 与向量数据库——把自有数据经嵌入检索注入上下文。
• 不达标怎么办：原文档给出明确的回退策略——如果健壮性不足，可以重新实现（re-implementing）、在流程中新增步骤（adding new steps in our flow）、或重构数据（restructuring the data），这些都可能帮助方案过关。
• 出口准则：完成对流程与规模（scale）的测试，并核对各项指标（check our Metrics），确认达标后进入下一阶段。

阶段三：运营化（Operationalizing）

• 做什么：进入集成（Integration）——为系统加上监控（Monitoring）与告警系统（Alerts Systems），完成部署（deployment），并做**应用集成（application integration）**到正式产品中。
• 至此，原文档的结语是：“Congratulations, now you have your AI App ready to go and operational.”（恭喜，你的 AI 应用已准备就绪并可投入运营。）

总循环：管理（Management）

三大阶段之上还有一个笼罩整体的管理循环，原文档将其职责概括为三件事：安全（security）、合规（compliance）和治理（governance）。

从课程整体结构看，这一循环在 第 13 课“保护你的生成式 AI 应用” 中有专门展开：数据投毒（data poisoning）、提示注入（prompt injection）、供应链漏洞（supply chain vulnerabilities）、过度依赖（overreliance）等风险，以及面向 AI 系统的对抗性威胁知识库与 LLM 应用漏洞清单，都属于这个管理循环要持续盯防的对象。

生命周期工具链（Lifecycle Tooling）

原文档 Tooling 一节给出了微软生态下支撑 LLMOps 循环的工具组合，并强调这些工具能让整个生命周期“易于实施并即刻可用（easy to implement and ready to go）”：

Azure AI Platform

Azure AI Platform 允许你使用 Microsoft Foundry 服务。原文档对 Microsoft Foundry 的定义是：

Microsoft Foundry（formerly Azure AI Studio，即前身为 Azure AI Studio）是一个 Web 门户，你可以用它来探索模型、示例和工具，管理你的资源，并可以使用 UI 开发流，也可以使用 SDK/CLI 选项进行 Code-First（代码优先）开发。

此外，Azure AI 允许你使用多种资源，统一管理 operations（运维）、services（服务）、projects（项目）、vector search（向量检索）和 databases（数据库） 相关需求——这恰好覆盖了 LLMOps 工作流中“构建/增强”阶段对向量检索能力的依赖，以及“运营化”阶段对资源与项目级管理的需求。

PromptFlow：从概念验证到大规模应用

原文档指出，PromptFlow 可以让你从概念验证（Proof-of-Concept, POC）一路构建到大规模应用，并给出三条核心能力：

1. Design and Build：在 VS Code 中以可视化与功能化工具设计和构建应用；
2. Test and fine-tune：轻松地对应用进行测试与微调，以获得高质量的 AI 输出；
3. Integrate and Iterate：借助 Microsoft Foundry 在云端进行集成与迭代，通过 Push（推送）和 Deploy（部署） 实现快速集成。

从原文档描述的分工来看，工具链与三阶段工作流是一一对应的：PromptFlow 主要服务“构思/探索”与“构建/增强”（原型、测试、微调、推送部署），Microsoft Foundry 门户则覆盖资源管理与从 UI 流到 SDK/CLI 的多种开发路径，而 Azure AI Platform 的多资源管理能力支撑“运营化”阶段的监控与运维诉求。

把生命周期落到一个真实演示上

原文档在讲解完工具后，建议读者通过 Contoso Chat Demo（微软云布道团队公开的演示站点）获得一次 hands-on（上手式）体验，观察云布道团队如何在演示中落地这些生命周期概念；同时课程推荐继续观看 Ignite 上的 breakout session 获取更多内容。需要注意的是，这些是原文档指向的外部演示与视频资源，本文不附外部链接，读者可以按名称自行检索。

小结与后续学习

本课题材的要点可以浓缩为一句话：生成式 AI 应用不是一次性交付物，而是一个以“五维指标（Quality / Harm / Honesty / Cost / Latency）”为标尺、以“构思—构建—运营”三阶段为主体、被安全合规治理总循环笼罩的持续迭代系统。 掌握它之后，你可以：

• 在选型期用提示词工程 + PromptFlow 原型验证业务假设；
• 在实现期用 RAG、微调等手段提升健壮性，并用统一的指标口径决定是否达标；
• 在运营期用监控、告警与治理循环守住质量、安全与成本底线。

按原文档的“Great! Continue your Learning!”一节，下一步建议进入课程 第 15 课：Retrieval Augmented Generation（RAG）与向量数据库（参见 15-rag-and-vector-databases/README.md），理解 RAG 与向量数据库如何影响生成式 AI、并帮助构建更有吸引力的应用——这正是“构建/增强”阶段最核心的技术之一。