生成式 AI 应用生命周期：从 MLOps 到 LLMOps 的工程范式

生成式 AI（GenAI）应用并非"写完代码即上线"的一次性工程，而是一个需要持续监控、评估与迭代的完整生命周期。本文以本仓库第 14 课《生成式 AI 应用生命周期》为主线，结合本仓库的源码与相邻课程文档，系统讲解从 MLOps 向 LLMOps 的范式转变、LLM 生命周期的三大阶段与整体治理环，以及 Azure AI 平台与 PromptFlow 等落地工具，帮助你为 AI 应用建立"可演进、可度量、可治理"的工程框架。

什么是生成式 AI 应用生命周期

AI 是一个快速演进的领域，所有 AI 应用都必须回答"AI 功能是否仍然相关"这一核心问题。为了让应用持续保持相关性（relevant）、可靠性（reliable）与稳健性（robust），开发团队需要对它持续监控、评估与改进——这正是生成式 AI 应用生命周期（Generative AI Application Lifecycle）要解决的问题。

生命周期是一套指导开发、部署与维护生成式 AI 应用的框架，它帮助你：

• 定义目标（define your goals）；
• 度量性能（measure your performance）；
• 识别挑战（identify your challenges）；
• 落地解决方案（implement your solutions）；
• 使应用与所属领域及利益相关方的伦理与法律标准保持一致。

简单说，遵循该生命周期可以确保应用始终交付价值并让用户满意。这正是本仓库 21 课课程体系（参见根目录 README.md，Version 3）中贯穿"Learn / Build"两类课程的组织思想：每一课既解释概念，也提供可在本地验证的代码与 Notebook。

学习本课你将掌握四个核心板块：

• 理解从 MLOps 到 LLMOps 的范式转变；
• 理解 LLM 生命周期的具体结构；
• 了解支撑生命周期的工具链；
• 掌握生命周期的度量（Metrification）与评估方式。

从 MLOps 到 LLMOps 的范式转变

LLM（大型语言模型）是 AI 工具箱中的新工具，在应用的分析与生成任务上表现强大。但这种能力也直接改变了我们对 AI 与经典机器学习工作流的优化方式，因此需要一套新范式来动态适配它，并提供正确的激励。

"ML 应用"与"GenAI 应用"的分野

可以把早期的 AI 应用归类为**"ML 应用"，而较新的基于大模型的应用称为"GenAI 应用"**（或直接叫 "AI 应用"），这一命名差异背后反映的是当时的主流技术与技术路径的差别。范式转变意味着叙事方式发生多处变化，二者的差异可以通过下面对比图直观看出（此处使用本课配图的原版，位于 images/01-llmops-shift.png）：

从这张对比图可以提炼出 LLMOps 的典型特征：

• 关注对象：LLMOps 把更多注意力放在应用开发者（App Developers）身上；
• 核心手段：以集成（integrations）作为关键抓手；
• 模型获取方式：普遍采用"模型即服务"（Models-as-a-Service），而不是自建推理基础设施；
• 指标关注点：围绕质量、伤害、诚实度、成本、延迟五个维度设计度量。

LLMOps 的五维评估指标

下表总结了本课给出的 LLMOps 核心指标及关注的问题，是后面"生命周期度量与评估"环节的度量基准：

指标	对应关注点	说明
质量（Quality）	响应质量	回答是否满足任务要求、是否可用
伤害（Harm）	负责任 AI	输出是否公平、无害、符合伦理（参见第 3 课 负责任地使用生成式 AI）
诚实度（Honesty）	响应的依据性（groundedness）	回答是否合乎逻辑、是否正确，是否基于真实依据而非幻觉
成本（Cost）	解决方案预算	token 用量、API 调用、微调与 RAG 基础设施的开销
延迟（Latency）	每个 token 的平均响应时间	直接影响用户体验的实时性指标

需要注意的是，"诚实度（Honesty）"与幻觉问题直接相关——关于幻觉及其缓解思路，本仓库第 3 课与第 4 课（提示工程基础）中有更详细的说明；本课则把"响应是否有依据"提升为生命周期中的一等度量维度。

LLM 生命周期：从想法到持续运营

与 MLOps 生命周期的差异

传统的 MLOps 生命周期强调数据、模型训练、部署与再训练；而 LLM 生命周期带来了大量新要求，这也是它与 MLOps 生命周期最本质的区别（参见下图，原版位于 images/02-llmops.png）：

这些新要求至少包括：

• 提示工程（Prompting）：提示本身成为主要的编程接口，输入设计的质量直接决定输出质量；
• 提升质量的多种技术：微调（Fine-Tuning）、检索增强生成（RAG）、元提示（Meta-Prompts）等；
• 负责任的评估与责任机制：需要为负责任 AI 设计专门的评估与问责流程；
• 全新的评估指标：即上文的质量、伤害、诚实度、成本、延迟五维。

例如在"创意构思（Ideate）"环节，我们通常借助提示工程在不同 LLM 上做实验，探索各种可能性，以检验我们的假设是否成立。本仓库第 5 课（高级提示）提供了大量这类实验的实战脚本（Python 与 JavaScript 版本并存），可作为"探索阶段"的直接素材。

特别注意：整个生命周期并非一条直线，而是集成的循环（integrated loops）、迭代的（iterative）过程，并且存在一个贯穿始终的整体治理周期（overarching cycle）。

生命周期的三大主阶段

具体到落地，可以把 LLM 生命周期的工作流拆成三大步骤。其整体工作流示意见下图（原版位于 images/03-llm-stage-flows.png）：

1. 创意与探索（Ideation / Exploration） 探索阶段：根据业务需求开展调研与可行性验证。构建原型，创建 PromptFlow 流程并测试其是否足以支撑我们的假设。这一阶段的核心产出是"低成本验证假设"，也就是概念验证（POC）。

2. 构建与增强（Building / Augmentation） 实施阶段：开始在更大规模的数据集上进行评估，引入微调（Fine-Tuning）、RAG 等技术，检验方案的稳健性。如果效果不佳，可以考虑：

   • 重新实现（re-implement）；
   • 在流程中新增步骤（adding new steps in our flow）；
   • 重组数据（restructuring the data）。 在对流程完成测试、规模得到验证，并且满足既定指标之后，方案才进入下一阶段。

3. 运营化（Operationalizing） 集成阶段：为系统补充监控（Monitoring）与告警（Alerts）系统，完成应用部署，并把它作为功能集成到正式应用之中。

在这三个阶段之上，还存在一个管理的整体周期（overarching cycle of Management），聚焦安全（security）、合规（compliance）与治理（governance）三件要事。也就是说，安全与合规不是上线前的一次性检查，而是贯穿生命周期始终的治理环。

课程还为这套阶段配了实践样板：Contoso Chat Demo（一个把上述概念落到代码中的教学应用示例，由 Azure Cloud Advocacy 维护）。完成本课三个阶段的工程化改造后，你就拥有一个"可以上线并持续运营"的 AI 应用。

生命周期工具链：Azure AI 平台与 PromptFlow

工具层面，微软提供的 Azure AI 平台与 PromptFlow 可以把上述生命周期实现得更加容易、开箱即用。

Azure AI 平台：模型、资源与开发体验的统一门户

Azure AI 平台允许开发者使用 Azure AI Studio（网页门户）。AI Studio 的能力包括：

• 探索模型、示例与工具（Explore models, samples and tools）；
• 管理资源（manage your resources）；
• 提供 UI 开发流程（UI development flows）；
• 面向代码优先开发提供 SDK / CLI 选项（Code-First development）。

下表整理了 AI Studio 面向生命周期各阶段提供的能力：

能力分类	典型用途	对应生命周期阶段
模型目录与 Playground	试用不同模型、对比响应质量	创意/探索
资源与项目中心	管理 Hub/项目、计算、密钥与连接	构建/增强
PromptFlow（可视化/代码）	编排提示与工具步骤、批量评估	构建/增强
评估与指标面板	度量质量、伤害、诚实度、成本、延迟	构建/增强/运营
部署与集成	部署到在线端点并嵌入应用	运营化

从 Azure AI 资源的角度看，开发者可以利用多种资源来统一管理运营（operations）、服务（services）、项目（projects）、向量搜索（vector search）与数据库（databases）。下图为 Azure AI 提供的完整能力视图（原版位于 images/04-azure-ai-platform.png）：

向量检索与知识库：支撑 RAG 的存储底座

生命周期中的"构建/增强"阶段常会用到 RAG——把自有数据"接地（grounding）"到 LLM 中。Azure AI 在这一环同样提供了向量搜索与数据库能力：本仓库第 15 课（RAG 与向量数据库）就演示了如何基于 AI 课程笔记构建知识库，并用向量数据库存储分块后的文本嵌入，从而让问答系统引用真实资料作答。该课的配套 Notebook 位于 notebook-rag-vector-databases.ipynb，可作为 RAG 落地的最小可运行参考。

下图展示了"在 Azure AI 之上实施 LLMOps"时，提示、模型、数据与工具如何在同一平台上被组织起来（原版位于 images/05-llm-azure-ai-prompt.png）：

PromptFlow：从 POC 一路构建到大规模应用

PromptFlow 是本课推荐的另一件关键工具，它让开发团队能够从概念验证（Proof-of-Concept, POC）一路构建到大规模应用，其典型工作方式如下（原版配图位于 images/06-llm-promptflow.png）：

具体来说，使用 PromptFlow 可以做到：

• 在 VS Code 中设计和构建应用：同时提供可视化与功能性工具（visual and functional tools），把提示、LLM 调用、工具步骤编排为可执行的 Flow；
• 轻松测试与微调应用：面向"高质量 AI"对应用进行测试与调优，而不是只测代码正确性；
• 对接 Azure AI Studio 做云端集成与迭代：通过 Push 与 Deploy 完成快速集成，让本地调试的 Flow 平滑晋升为云端部署的版本。

从工作方式看，PromptFlow 恰好覆盖了上文三阶段中的"构建/增强"（编写与测试 Flow、引入评估）与"运营化"（部署到云、监控告警）两大环节，是连接本地原型与生产系统的重要桥梁。

生命周期度量与评估：把五维指标落到流程里

本课在讲解指标时反复强调一个事实：LLM 时代不能只用传统 ML 指标（如准确率）来评判应用，而应同时度量质量、伤害、诚实度、成本、延迟这五个维度。它们分别回答了五个不同的问题：

1. 质量——回答好不好、能不能直接用；
2. 伤害——有没有冒犯、歧视或不安全的内容；
3. 诚实度——回答有没有依据、是不是幻觉（这也是第 4 课 提示工程基础 中通过提示词设计所重点改善的维度）；
4. 成本——预算撑不撑得住，涉及 token 用量与基础设施开销；
5. 延迟——每个 token 平均生成时间是否可接受。

把评估融入"构建/增强"与"运营化"两个阶段，团队才能形成闭环：先以较小数据集做假设验证（创意阶段），再在较大数据上评估并引入 RAG / 微调等手段提升指标（构建阶段），最后通过监控与告警持续追踪线上指标（运营阶段）。这正是"集成循环 + 整体治理"的工程含义。

生命周期思想与仓库其他课程的对照

本课属于本仓库 21 课体系中的"概念编排"类课程：前序课程的技能是生命周期各环节的操作细节，后续课程则提供进阶方案。可对照学习的仓库资源包括：

• 提示工程与幻觉治理：第 3 课 - 负责任地使用生成式 AI、第 4 课 - 提示工程基础、第 5 课 - 高级提示，对应"创意/探索"阶段的高质量输入设计；
• 数据接地与知识库：第 15 课 - RAG 与向量数据库，对应"构建/增强"阶段的 RAG 技术；
• 微调与模型优化：第 18 课 - 微调你的 LLM（其配套资料页见 RESOURCES.md），对应"构建/增强"阶段的另一种质量提升路径；
• 端到端可运行代码：各课的 Python / TypeScript / JavaScript 示例与 Notebook 都分布在对应课程目录下，例如 08-building-search-applications（搜索应用，含嵌入检索的 Notebook）与 06-text-generation-apps。

小结

生成式 AI 应用生命周期是一套比 MLOps 更强调"提示、数据、评估与治理"的工程框架。本课的核心结论可以概括为三点：

• 范式变了：从 MLOps 走向 LLMOps，评价标准从纯模型指标扩展为质量、伤害、诚实度、成本、延迟五维；
• 流程是循环而非直线：创意/探索 → 构建/增强 → 运营化三阶段与安全合规治理环构成迭代整体，任何一次效果不佳都可以回到上游重新实现、补步骤或重组数据；
• 工具让框架可落地：Azure AI 平台统一资源与模型管理，PromptFlow 串联从 POC 到大规模部署的流程。

掌握这套生命周期方法论之后，下一步可以继续学习本仓库第 15 课，理解检索增强生成（RAG）与向量数据库如何影响生成式 AI，并据此构建更具吸引力的应用。