DevOps、MLOps 与 LLMOps：生成式 AI 如何走向生产

常见的对比图把三条流水线画成前后相继的三代技术。这有助于入门，却掩盖了关键事实：DevOps、MLOps 与 LLMOps 既不是互相竞争的产品，也不是彼此替代的台阶。它们分别应对越来越难以定义和验证的生产对象：软件带来了交付自动化；机器学习加入了数据与统计行为；基础模型又加入自然语言上下文、外部模型供应商、工具调用和语义风险。

下文既梳理这段可考的演进史，更重点说明LLMOps 团队究竟要运维什么。MLOps 与 LLMOps 都没有公认的唯一诞生日期，因此本文只采用可核验的里程碑，不虚构某位“发明者”。

三个名称，三类需要维护的工件

这不是僵硬的组织边界。LLM 产品仍需要 CI/CD、密钥管理、网络、回滚和 SLO；若自行持有模型权重，还需要数据血缘与模型注册表。LLMOps 是对 DevOps 和 MLOps 的扩展，而不是删除。

2009：DevOps 与“交接墙”

2009 年 Velocity 大会上，John Allspaw 与 Paul Hammond 发表了 10+ Deploys per Day: Dev and Ops Cooperation at Flickr。^[flickr] 标题已经给出核心：高频交付依靠的不是把软件包扔过部门高墙的英雄，而是协作与自动化。同年，首届 DevOpsDays 在比利时根特举行。^[devopsdays]

有记录的轶事：当许多组织仍按季度发布时，“每天十多次部署”颇具冲击力。但重点不是崇拜数字十，而是小批量变更缩短反馈，并让开发与运维共同负责。DORA 后来把交付能力指标化，并说明速度与稳定性不必互相牺牲。^[dora]

2015–2017：当工件开始“学习”

机器学习系统的行为不再只由代码决定，还取决于数据、转换、超参数和上线后的真实世界。Google 关于隐藏技术债的论文留下两个重要认识：模型代码只占真实系统的一小部分；在高度耦合的系统中，任何改动都可能牵动全局。^[debt]

这正是后来被称为 MLOps 的需求：复现数据集与特征、验证 schema、记录实验与模型、防止训练—服务偏移、监测漂移，并决定何时再训练。2017 年的 ML Test Score 给出了 28 项面向生产就绪度的测试与监控需求。^[mltest]

一个有数字的案例：TFX 论文描述了 Google 如何用标准组件替代脆弱的胶水脚本。在 Google Play 的一个部署中，模型随着新数据持续刷新；作者报告实验周期加快、从数月到数周的上线时间，以及与数据和模型分析改进相关的 2% 安装量增长。^[tfx] 这是该案例的结果，不是普遍承诺。

MLOps 在 CI/CD 之外增加了流水线持续交付与持续训练。Google Cloud 的架构指南据此区分手工流程、自动化 ML 流水线和完整 CI/CD 自动化。^[mlops]

2020–2022：从单一模型到基础模型系统

三项变化为 LLMOps 铺路。第一，2020 年的 RAG 将参数记忆与外部索引结合，让知识可更新并保留来源。^[rag] 第二，Stanford 2021 年报告系统化了“基础模型”一词：广泛训练、适配多任务的模型既有巨大杠杆，也会让许多下游产品继承同一缺陷。^[foundation]

第三，产品不再只是权重。2022 年 InstructGPT 说明人类反馈能显著改变实用性：在作者的提示词分布上，标注者更偏好 13 亿参数模型而不是 1750 亿参数的 GPT‑3，尽管前者仍会犯简单错误。^[instruct] 同年的 HELM 倡导透明、多维评测，而不是依赖单一榜单分数。^[helm]

LLMOps 这一称呼在这样的环境中普及。它不是“加了提示词的 MLOps”，也不要求企业训练基础模型。大量应用从不训练权重，而是在运维 API、提示词、检索、工具与规则。真正的变更单元是复合式 LLM 系统。

LLMOps 真正运维的对象

1. 版本化组合，而不是一段提示词

一个可部署版本至少应标识：供应商与模型版本、推理参数、系统消息与模板、工具 schema、RAG 语料、解析器、切块规则、embedding 与索引、安全策略、评测集和编排代码。即使用户看到的提示词相同，其中任一项变化都可能使它成为不同产品。

发布组合应不可变：app@sha + prompt@sha + index@snapshot + eval@version + policy@version + model@id。如果无法重建这一组合，就无法解释事故，也无法可信地回滚。

2. 先评测，再优化

传统测试常比较确定的预期输出；语言任务可能有多种正确表达，也可能产生文采很好却错误的答案。因此 LLMOps 要先从真实任务、边界场景和可预见滥用中建立评测集，每个样本都需要评分准则，而不仅是一条“标准答案”。

• 任务质量：正确性、完整性、格式与指令遵循。
• RAG：检索 recall、上下文相关性、答案忠实度与引用质量；必须区分检索失败和生成失败。
• 安全：直接/间接注入、数据泄漏、工具滥用与禁止内容。
• 运行：端到端延迟、token、成本、重试、错误率与配额饱和。

LLM 裁判能扩大评审规模，但它本身也是模型：需要用人工评审校准、记录版本，并保留分歧。严肃的发布门禁会组合确定性检查、模型裁判、对抗测试和人工抽样。

3. 把 RAG 当作在线数据流水线

RAG 不是“接一个向量库”，而是一条链：文档授权 → 抽取 → 清洗 → 切块 → embedding → 建索引 → 检索 → 重排 → 组装上下文 → 生成 → 引用。每一个箭头都可能退化。

语料与索引要版本化并监测新鲜度；用户不能检索无权访问的文档；trace 要保留 chunk ID；测试问题应有已知来源。检索可以改善“有据可依”，却不会自动把输出变成事实，也不能消除提示词注入；OWASP 对此有明确说明。^[owasp]

4. 语义可观测性与 FinOps

HTTP 200 不代表答案有用。一条 trace 应串起输入、策略、检索、重排、模型调用、工具、重试与最终输出。OpenTelemetry 已为模型、token、消息和工具调用定义生成式 AI 语义约定；内容采集必须可选，因为其中可能包含敏感信息。^[otel]

有效的看板要把质量与运行指标放在一起：各版本的任务成功率和 groundedness、p50/p95/p99 延迟、输入/输出 token、每个已完成任务而非每次调用的成本、缓存命中、agent 步数、工具失败与人工升级。单 token 便宜的模型，如果让 agent 循环，整体仍会昂贵。

SLO 应从用户体验出发，覆盖可用性、延迟与正确性。^[sre] 例如：“95% 的已授权政策问题在 6 秒内返回有效引用，并且不发生跨租户泄漏。”

5. 安全、治理与受限行动权

模型通过同一通道接收数据和指令，这种歧义使提示词注入成为架构问题，而不是上线前加一个过滤器就能解决。OWASP 维护 LLM 专项风险目录；NIST 生成式 AI 档案则组织治理、测量和风险管理行动。^{[nist][owasp]}

• 把检索文本、网页和工具结果视作不可信输入。
• 对每个工具实行最小权限，分开“读取、建议、执行”。
• 在 SQL、shell、邮件、支付或基础设施变更前验证输出。
• 不可逆或高影响操作必须人工批准。
• 明确提示词和 trace 的保留、PII 脱敏、数据驻留与访问策略。
• 提供 kill switch、步数/预算上限、超时与回滚。

一条生产级 LLMOps 流水线

1. 定义任务与风险：支持什么决定、允许做什么、谁负责、什么绝不能发生。
2. 建立评测集：正常、边界、多语言、相关群体与攻击场景，并冻结基线。
3. 按约束选型：任务质量、延迟、隐私、区域、上下文、工具与成本，而非通用榜单。
4. 构建上下文：只在知识或可追溯性需要时使用 RAG，保留 ACL、来源和新鲜度。
5. 上线前埋点：版本与关联 ID、span、token、成本和评测结果。
6. 执行离线门禁：回归、安全、负载与预算；平均提升不能掩盖关键失败。
7. 影子或 canary 发布：用真实流量比较，但不立刻授予完整行动权。
8. 生产抽样：自动信号、带上下文的反馈与符合隐私规则的人工复核。
9. 整体发布或回滚：模型、提示词、索引、工具与策略一起移动。

三则后来变成运维规则的轶事

Flickr，2009：人们记住的是“每天十次部署”，但标题中更持久的一半是“Dev 与 Ops 协作”。频率只是短反馈和共同责任的可见结果。^[flickr]

TFX，2017：团队不是靠更好的算法解决生产问题，而是用可重复平台替代临时胶水代码。这就是从“我们有模型”走向“我们能运营模型”。^[tfx]

Tay，2016：Tay 早于现代 LLM，不能把它写成 LLM 故障，但它确实是运维警告。Microsoft 说明，在上线最初 24 小时内，协调攻击利用了未预见的漏洞，随后机器人下线。^[tay] 实验室测试、红队、实时观测和撤回能力都属于产品。

常见 LLMOps 错误

• 把提示词目录称为“平台”；没有评测、血缘、权限、trace 与回滚，它只是存储。
• 只测幻觉率；效用、拒答、格式、安全、延迟和成本同样决定成功。
• 没有策略就记录全部提示词；可观测系统可能变成敏感数据的影子副本。
• 直接在生产切换模型；即使“更好”，风格、工具调用、长度与成本也会变化。
• 给工具服务账号的全部权限；agent 应使用用户权限或最小职能身份。

真正的演进：扩大责任对象

DevOps 让软件变更可运营；MLOps 加入不断变化的数据与预测行为；LLMOps 又加入上下文、意图与行动。成熟的标志不是更多方框，而是能针对每个输出回答五个问题：哪个版本生成、使用了什么上下文、如何评测、允许做什么、花费多少。

这些答案存在，系统才可以不靠信念持续改进；如果不存在，所谓“LLMOps 流水线”仍只是通往生产网络的一场演示。

来源与延伸阅读

本文所依据的原始论文、官方文档以及相关组织发布的一手事件复盘。

1. John Allspaw & Paul Hammond — 10+ Deploys per Day: Dev and Ops Cooperation at Flickr
2. DevOpsDays — Ghent 2009, official event archive
3. DORA / Google Cloud — 2019 Accelerate State of DevOps Report
4. Sculley et al. — Hidden Technical Debt in Machine Learning Systems
5. Breck et al. — The ML Test Score
6. Baylor et al. — TFX: A TensorFlow-Based Production-Scale ML Platform
7. Google Cloud Architecture Center — MLOps: Continuous delivery and automation pipelines
8. Lewis et al. — Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
9. Bommasani et al. — On the Opportunities and Risks of Foundation Models
10. Ouyang et al. — Training language models to follow instructions with human feedback
11. Liang et al. — Holistic Evaluation of Language Models (HELM)
12. Microsoft — Learning from Tay’s introduction
13. NIST AI 600-1 — Generative AI Profile
14. OWASP GenAI Security Project — Top 10 for LLM Applications
15. OpenTelemetry — Inside the LLM Call: GenAI Observability
16. Google SRE Book — Service Level Objectives