generative-ai-for-beginners 第14课精讲从 MLOps 到 LLMOps 的生成式 AI 应用全生命周期管理【免费下载链接】generative-ai-for-beginners21 Lessons, Get Started Building with Generative AI项目地址: https://gitcode.com/GitHub_Trending/ge/generative-ai-for-beginners本篇技术指南以本仓库课程第 14 课对应英文原稿 14-the-generative-ai-application-lifecycle/README.md 及西班牙语译本 translations/es/14-the-generative-ai-application-lifecycle/README.md为核心骨架系统讲解生成式 AI 应用为什么不能沿用传统机器学习运维MLOps思路而要切换到面向大语言模型的LLMOps范式。读完后你将掌握LLMOps 与 MLOps 的核心差异与五维评估口径质量、伤害、诚实性、成本、延迟、「构思/探索 → 构建/增强 → 运营化」三阶段叠加治理闭环的生命周期模型以及用 Azure AI 平台与 PromptFlow 落地这一生命周期的工具化路径从而持续监控、评估并迭代你的生成式 AI 应用。为什么需要「生成式 AI 应用生命周期」所有 AI 应用都要回答一个关键问题AI 特性的时效性。AI 是快速演进的领域模型在换、提示词在变、数据在增长、安全与合规要求在收紧。要保证应用始终相关、可靠且健壮就必须持续监控、持续评估、持续改进——这正是生成式 AI 生命周期这一框架存在的意义。按第 14 课的定义生成式 AI 生命周期是一个贯穿「开发—部署—维护」三阶段的指导性框架它帮你定义应用目标度量应用表现识别并定位挑战落地解决方案。它同时保证应用与所在行业、利益相关方的伦理与法律标准保持一致。遵循该生命周期应用才能持续交付价值并让用户满意。范式转变从 MLOps 到 LLMOpsLLM 是人工智能武器库中的新工具在分析、生成类任务上能力极强但这一能力反过来改变了我们固化 AI 与经典机器学习任务的方式。为此需要一套具有正确激励的新范式来动态适配该工具。我们可以把较早期的 AI 应用归类为ML Apps把新一代 AI 应用归类为GenAI Apps或直接称 AI Apps以反映当时主流的技术与手段。这种归类会从多个维度改写我们的叙事。结合图中信息与原文说明二者的关键差异可归纳如下维度MLOps 传统范式LLMOps 新范式受众机器学习工程师、数据科学家应用开发者为主可共享资产模型、数据、环境、特征LLM、Agent、插件、提示词、链、API模型供给从零构建模型预构建模型经微调后以Model-as-a-ServiceMaaSAPI 形态供给集成方式重模型训练与部署流水线以集成为关键点弱化自建训练核心指标单一关注准确率等见下方五维指标体系可见 LLMOps 更聚焦于应用开发者把「集成」作为关键动作、把「模型即服务」作为供给方式并在度量上考虑下列五个维度质量Quality回答质量落到指标上主要是准确率与相似度伤害Harm负责任 AI 维度落到指标上主要是偏见与毒性检测诚实性Honesty回答是否有依据groundedness——逻辑是否通顺、结论是否正确、是否忠实于给定上下文成本Cost解决方案预算落到指标上主要是每次请求消耗的 token 数延迟Latency平均每个 token 的响应时间以及每秒请求数RPS等吞吐指标。值得注意的是这些指标与本仓库其他课程的关注点形成呼应例如第 3 课 03-using-generative-ai-responsibly/README.md 讨论偏见与毒性缓解对应「伤害」第 13 课 13-securing-ai-applications/README.md 讨论提示词注入与红队测试对应安全治理。在代码层面仓库为应用开发者提供了可复用的健壮性基建例如 shared/python/input_validation.py 中的sanitize_prompt_input会剥离{{...}}、${...}、script等注入模式以缓解提示词注入风险shared/python/api_utils.py 中的make_safe_request为外部请求统一设置超时与重试——这些都是把「可靠性」写进应用运维的最小实践。LLM 生命周期非线性的迭代闭环理解范式差异后再看 LLM 生命周期本身。它与常规 MLOps 生命周期明显不同LLM 引入了大量新要求例如提示词工程Prompting、多种质量提升手段微调 Fine-Tuning、检索增强生成 RAG、元提示 Meta-Prompts、与负责任 AI 相关的评估与责任机制以及全新的评估指标质量、伤害、诚实性、成本、延迟。例如在「构思」环节我们通过提示词工程与多种 LLM 反复实验、探索各种可能性以检验某个业务假设能否成立。注意该生命周期不是线性的而是内嵌的迭代回路且由外层总周期统一治理。生命周期三大阶段拆解从流程上看整条链路可以拆成三大步骤构思/探索Ideate / Explore进入探索期依据业务需求定义用例并连接数据先构建一个基础提示词流再基于提示词开发流以扩展能力。典型做法是用PromptFlow快速原型化检验该方案对假设而言是否足够高效。若此阶段发现方向有误可依据「业务需要」触发项目回滚revert重新收敛业务目标。构建/增强Build / Augment进入实施期。先对样本数据运行提示词流并评估随后根据评估结果修改流调整提示词、工具等当达到满意后再对更大规模数据集运行流并再次评估从而检验方案鲁棒性。这一阶段会引入微调、RAG 等增强技术。若结果不达标可重新实现、在流中新增步骤或重组数据来改进。只有流在更大规模数据上通过测试并验证了指标表现才允许推进到下一阶段。运营化Operationalize进入集成期。部署端点、为系统接入监控与告警再把应用集成到正式产品中。在此基础上外层还有一个贯穿始终的管理Manage闭环聚焦安全security、合规compliance与治理governance持续对上述阶段做成本、配额与内容安全层面的调控。迭代回路的本质结合仓库中从第 1 课到第 21 课的课程编排可以更直观地看到这套生命周期的知识映射构思/探索阶段需要的「假设验证、提示词实验」能力对应第 4 课提示词工程基础 04-prompt-engineering-fundamentals/README.md 与第 5 课高级提示词 05-advanced-prompts/README.md以及各课的 assignment notebook构建/增强阶段需要的「RAG 向量检索」对应第 15 课 15-rag-and-vector-databases/README.md 与第 8 课搜索应用 08-building-search-applications/README.md「微调」对应第 18 课 18-fine-tuning/README.md运营化阶段需要的「对话与生成应用」对应第 6、7 课的 06-text-generation-apps/python/oai-app.py 等可直接运行的示例通过client.responses.create(model..., input..., storeFalse)调用 Responses API。原文档在完成阶段讲解后给出的实践落点是 Contoso Chat 演示应用该演示即以「完成生命周期闭环」为目标的端到端参考实现。学习该课之后即可按需进入下一课 RAG 与向量数据库的实战。生命周期工具链Azure AI 平台与 PromptFlow理论有了落地靠工具。第 14 课给出的主推工具组合是Azure AI 平台与PromptFlow二者共同使命是让生命周期「易于实现、开箱即用」。Azure AI 平台一站式的资源与能力底座Azure AI 平台AI Studio / Microsoft Foundry 系产品是一个 Web 门户可以浏览模型、示例与工具管理资源使用 UI 开发流同时提供 SDK/CLI 选项以支持 Code-First 开发。平台价值体现在两层模型供给层可访问来自 OpenAI、Meta、Hugging Face 等生态的大量 LLM能力集成层通过 RAG 关联企业数据、提供提示词工程与评估、内置安全与负责任 AI 能力并对 LLM 做持续监控。Azure AI 允许通过多种资源统一管理运营、服务、项目、向量搜索与数据库需求从而把「运营—项目—模型—数据」串成一个整体。这一设计恰好对应生命周期中不同阶段对资源的诉求探索期需要模型目录与 Prompt 实验空间构建期需要向量搜索与数据库承接 RAG运营期则需要资源、配额、监控与告警的统一入口。PromptFlow贯穿 POC 到大规模应用的开发编排PromptFlow 用于编排「提示词 → 数据 → 工具 → LLM → 评估」的流式执行。用它可以做到设计并构建直接在 VS Code 中用可视化与功能化工具搭建应用流测试与调优轻松对应用做质量 AI 的测试与调优对应生命周期中「样本数据集评估 → 反馈 → 修改流」的回路集成与迭代通过 Azure AI 平台与云端集成push 与部署实现快速集成上线。从工程视角看PromptFlow 把生命周期中的「流即代码」落实到日常开发把提示词版本化、把评估结果回填到流改进从而让「构建/增强」阶段的反复迭代变成可控的工程流程而非临时的手工调参。度量化与评估把五维指标做成闭环原课程在开篇即点明本课需要掌握「生命周期度量与评估」。五维指标体系贯穿三阶段其度量时机与手段各不相同维度关注问题典型度量/手段按图中信息整理质量 Quality回答是否准确、贴近预期准确率、相似度响应与参考答案的相似性伤害 Harm是否包含偏见、毒性或不当内容偏见检测、毒性评分、内容过滤含部署后的内容过滤器诚实性 Honesty回答是否有依据、是否幻觉groundedness 评估核对回答能否由给定上下文支撑成本 Cost方案是否在预算内每次请求 token 数、配额与成本管理延迟 Latency用户能否及时拿到响应每 token 平均响应时间、RPS 吞吐其中「伤害」维度在部署后尤其依赖内容过滤与持续监控这是运营化阶段的关键动作之一「成本」则与云端的配额quota管理直接挂钩。评估不是一次性的探索期评估假设可行性构建期评估流质量运营期则把监控数据回流为改进信号形成持续反馈环。小结与延伸一句话概括本课结论生成式 AI 应用不应在「上线」那一刻画上句号而应在「构思—构建—运营」的循环中持续度量与治理。LLMOps 的重心从「造模型」转向「编应用」以模型即服务为供给、以集成为抓手用质量、伤害、诚实性、成本、延迟五个维度度量每一次交付并用 Azure AI 平台 PromptFlow 把整个生命周期工具化、流程化。原文档收尾处提示继续学习下一步进入第 15 课 Retrieval Augmented Generation 与向量数据库理解 RAG 如何让生成式 AI 拥有外部知识、构建更有吸引力的应用——这正是生命周期「构建/增强」阶段的核心增强技术之一。【免费下载链接】generative-ai-for-beginners21 Lessons, Get Started Building with Generative AI项目地址: https://gitcode.com/GitHub_Trending/ge/generative-ai-for-beginners创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
generative-ai-for-beginners 第14课精讲从 MLOps 到 LLMOps 的生成式 AI 应用全生命周期管理【免费下载链接】generative-ai-for-beginners21 Lessons, Get Started Building with Generative AI项目地址: https://gitcode.com/GitHub_Trending/ge/generative-ai-for-beginners本篇技术指南以本仓库课程第 14 课对应英文原稿 14-the-generative-ai-application-lifecycle/README.md 及西班牙语译本 translations/es/14-the-generative-ai-application-lifecycle/README.md为核心骨架系统讲解生成式 AI 应用为什么不能沿用传统机器学习运维MLOps思路而要切换到面向大语言模型的LLMOps范式。读完后你将掌握LLMOps 与 MLOps 的核心差异与五维评估口径质量、伤害、诚实性、成本、延迟、「构思/探索 → 构建/增强 → 运营化」三阶段叠加治理闭环的生命周期模型以及用 Azure AI 平台与 PromptFlow 落地这一生命周期的工具化路径从而持续监控、评估并迭代你的生成式 AI 应用。为什么需要「生成式 AI 应用生命周期」所有 AI 应用都要回答一个关键问题AI 特性的时效性。AI 是快速演进的领域模型在换、提示词在变、数据在增长、安全与合规要求在收紧。要保证应用始终相关、可靠且健壮就必须持续监控、持续评估、持续改进——这正是生成式 AI 生命周期这一框架存在的意义。按第 14 课的定义生成式 AI 生命周期是一个贯穿「开发—部署—维护」三阶段的指导性框架它帮你定义应用目标度量应用表现识别并定位挑战落地解决方案。它同时保证应用与所在行业、利益相关方的伦理与法律标准保持一致。遵循该生命周期应用才能持续交付价值并让用户满意。范式转变从 MLOps 到 LLMOpsLLM 是人工智能武器库中的新工具在分析、生成类任务上能力极强但这一能力反过来改变了我们固化 AI 与经典机器学习任务的方式。为此需要一套具有正确激励的新范式来动态适配该工具。我们可以把较早期的 AI 应用归类为ML Apps把新一代 AI 应用归类为GenAI Apps或直接称 AI Apps以反映当时主流的技术与手段。这种归类会从多个维度改写我们的叙事。结合图中信息与原文说明二者的关键差异可归纳如下维度MLOps 传统范式LLMOps 新范式受众机器学习工程师、数据科学家应用开发者为主可共享资产模型、数据、环境、特征LLM、Agent、插件、提示词、链、API模型供给从零构建模型预构建模型经微调后以Model-as-a-ServiceMaaSAPI 形态供给集成方式重模型训练与部署流水线以集成为关键点弱化自建训练核心指标单一关注准确率等见下方五维指标体系可见 LLMOps 更聚焦于应用开发者把「集成」作为关键动作、把「模型即服务」作为供给方式并在度量上考虑下列五个维度质量Quality回答质量落到指标上主要是准确率与相似度伤害Harm负责任 AI 维度落到指标上主要是偏见与毒性检测诚实性Honesty回答是否有依据groundedness——逻辑是否通顺、结论是否正确、是否忠实于给定上下文成本Cost解决方案预算落到指标上主要是每次请求消耗的 token 数延迟Latency平均每个 token 的响应时间以及每秒请求数RPS等吞吐指标。值得注意的是这些指标与本仓库其他课程的关注点形成呼应例如第 3 课 03-using-generative-ai-responsibly/README.md 讨论偏见与毒性缓解对应「伤害」第 13 课 13-securing-ai-applications/README.md 讨论提示词注入与红队测试对应安全治理。在代码层面仓库为应用开发者提供了可复用的健壮性基建例如 shared/python/input_validation.py 中的sanitize_prompt_input会剥离{{...}}、${...}、script等注入模式以缓解提示词注入风险shared/python/api_utils.py 中的make_safe_request为外部请求统一设置超时与重试——这些都是把「可靠性」写进应用运维的最小实践。LLM 生命周期非线性的迭代闭环理解范式差异后再看 LLM 生命周期本身。它与常规 MLOps 生命周期明显不同LLM 引入了大量新要求例如提示词工程Prompting、多种质量提升手段微调 Fine-Tuning、检索增强生成 RAG、元提示 Meta-Prompts、与负责任 AI 相关的评估与责任机制以及全新的评估指标质量、伤害、诚实性、成本、延迟。例如在「构思」环节我们通过提示词工程与多种 LLM 反复实验、探索各种可能性以检验某个业务假设能否成立。注意该生命周期不是线性的而是内嵌的迭代回路且由外层总周期统一治理。生命周期三大阶段拆解从流程上看整条链路可以拆成三大步骤构思/探索Ideate / Explore进入探索期依据业务需求定义用例并连接数据先构建一个基础提示词流再基于提示词开发流以扩展能力。典型做法是用PromptFlow快速原型化检验该方案对假设而言是否足够高效。若此阶段发现方向有误可依据「业务需要」触发项目回滚revert重新收敛业务目标。构建/增强Build / Augment进入实施期。先对样本数据运行提示词流并评估随后根据评估结果修改流调整提示词、工具等当达到满意后再对更大规模数据集运行流并再次评估从而检验方案鲁棒性。这一阶段会引入微调、RAG 等增强技术。若结果不达标可重新实现、在流中新增步骤或重组数据来改进。只有流在更大规模数据上通过测试并验证了指标表现才允许推进到下一阶段。运营化Operationalize进入集成期。部署端点、为系统接入监控与告警再把应用集成到正式产品中。在此基础上外层还有一个贯穿始终的管理Manage闭环聚焦安全security、合规compliance与治理governance持续对上述阶段做成本、配额与内容安全层面的调控。迭代回路的本质结合仓库中从第 1 课到第 21 课的课程编排可以更直观地看到这套生命周期的知识映射构思/探索阶段需要的「假设验证、提示词实验」能力对应第 4 课提示词工程基础 04-prompt-engineering-fundamentals/README.md 与第 5 课高级提示词 05-advanced-prompts/README.md以及各课的 assignment notebook构建/增强阶段需要的「RAG 向量检索」对应第 15 课 15-rag-and-vector-databases/README.md 与第 8 课搜索应用 08-building-search-applications/README.md「微调」对应第 18 课 18-fine-tuning/README.md运营化阶段需要的「对话与生成应用」对应第 6、7 课的 06-text-generation-apps/python/oai-app.py 等可直接运行的示例通过client.responses.create(model..., input..., storeFalse)调用 Responses API。原文档在完成阶段讲解后给出的实践落点是 Contoso Chat 演示应用该演示即以「完成生命周期闭环」为目标的端到端参考实现。学习该课之后即可按需进入下一课 RAG 与向量数据库的实战。生命周期工具链Azure AI 平台与 PromptFlow理论有了落地靠工具。第 14 课给出的主推工具组合是Azure AI 平台与PromptFlow二者共同使命是让生命周期「易于实现、开箱即用」。Azure AI 平台一站式的资源与能力底座Azure AI 平台AI Studio / Microsoft Foundry 系产品是一个 Web 门户可以浏览模型、示例与工具管理资源使用 UI 开发流同时提供 SDK/CLI 选项以支持 Code-First 开发。平台价值体现在两层模型供给层可访问来自 OpenAI、Meta、Hugging Face 等生态的大量 LLM能力集成层通过 RAG 关联企业数据、提供提示词工程与评估、内置安全与负责任 AI 能力并对 LLM 做持续监控。Azure AI 允许通过多种资源统一管理运营、服务、项目、向量搜索与数据库需求从而把「运营—项目—模型—数据」串成一个整体。这一设计恰好对应生命周期中不同阶段对资源的诉求探索期需要模型目录与 Prompt 实验空间构建期需要向量搜索与数据库承接 RAG运营期则需要资源、配额、监控与告警的统一入口。PromptFlow贯穿 POC 到大规模应用的开发编排PromptFlow 用于编排「提示词 → 数据 → 工具 → LLM → 评估」的流式执行。用它可以做到设计并构建直接在 VS Code 中用可视化与功能化工具搭建应用流测试与调优轻松对应用做质量 AI 的测试与调优对应生命周期中「样本数据集评估 → 反馈 → 修改流」的回路集成与迭代通过 Azure AI 平台与云端集成push 与部署实现快速集成上线。从工程视角看PromptFlow 把生命周期中的「流即代码」落实到日常开发把提示词版本化、把评估结果回填到流改进从而让「构建/增强」阶段的反复迭代变成可控的工程流程而非临时的手工调参。度量化与评估把五维指标做成闭环原课程在开篇即点明本课需要掌握「生命周期度量与评估」。五维指标体系贯穿三阶段其度量时机与手段各不相同维度关注问题典型度量/手段按图中信息整理质量 Quality回答是否准确、贴近预期准确率、相似度响应与参考答案的相似性伤害 Harm是否包含偏见、毒性或不当内容偏见检测、毒性评分、内容过滤含部署后的内容过滤器诚实性 Honesty回答是否有依据、是否幻觉groundedness 评估核对回答能否由给定上下文支撑成本 Cost方案是否在预算内每次请求 token 数、配额与成本管理延迟 Latency用户能否及时拿到响应每 token 平均响应时间、RPS 吞吐其中「伤害」维度在部署后尤其依赖内容过滤与持续监控这是运营化阶段的关键动作之一「成本」则与云端的配额quota管理直接挂钩。评估不是一次性的探索期评估假设可行性构建期评估流质量运营期则把监控数据回流为改进信号形成持续反馈环。小结与延伸一句话概括本课结论生成式 AI 应用不应在「上线」那一刻画上句号而应在「构思—构建—运营」的循环中持续度量与治理。LLMOps 的重心从「造模型」转向「编应用」以模型即服务为供给、以集成为抓手用质量、伤害、诚实性、成本、延迟五个维度度量每一次交付并用 Azure AI 平台 PromptFlow 把整个生命周期工具化、流程化。原文档收尾处提示继续学习下一步进入第 15 课 Retrieval Augmented Generation 与向量数据库理解 RAG 如何让生成式 AI 拥有外部知识、构建更有吸引力的应用——这正是生命周期「构建/增强」阶段的核心增强技术之一。【免费下载链接】generative-ai-for-beginners21 Lessons, Get Started Building with Generative AI项目地址: https://gitcode.com/GitHub_Trending/ge/generative-ai-for-beginners创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
