Wiki Notes

Appearance

MLOps与LLMOps专题 ​

版本：v1.1

最后更新：2026-07-08

适用对象：需要把模型、Prompt、RAG、Agent 和上线运行流程纳入同一套工程体系的产品、研发、平台、算法与交付同学

很多团队把模型接进业务之后，第一反应是：

  • 已经能跑了

但真正把系统做稳，靠的从来不是一次接通 API，而是后面的工程体系：

  • 版本管理
  • 评测
  • tracing 与告警
  • 发布与回滚
  • 反馈闭环
  • 成本治理

这就是 MLOps / LLMOps 真正要解决的问题。

根据 2026-07-08 可访问的 Google Cloud 关于 CI / CD / CT 的 MLOps 架构资料、Azure MLOps maturity model 与 GitHub Actions + Azure ML 官方文档，以及 OpenAI 的 Production best practices、Evaluation best practices、Prompt caching、Background mode、Latency optimization 等资料，可以先建立一个关键共识：

  • LLMOps 不是给大模型项目套一个“更时髦的运维名词”，而是把“变化可追踪、质量可验证、故障可回滚、成本可运营”变成日常工程能力。

1. MLOps 和 LLMOps 到底是什么关系 ​

1.1 MLOps 更偏传统机器学习生命周期 ​

更典型的对象包括：

  • 数据集
  • 特征工程
  • 训练代码
  • 实验跟踪
  • 模型注册
  • 部署监控
  • 再训练流程

Google Cloud 当前 MLOps 资料把很多传统 ML 系统的工程化重点放在：

  • CI
  • CD
  • CT（continuous training）

也就是：

  • 代码变更可集成
  • 模型或服务变更可发布
  • 数据变化时训练链路可持续更新

1.2 LLMOps 更偏大模型应用工程 ​

到了 LLM 场景，工程对象会明显变化。

核心对象往往从“模型权重”扩展成：

  • 模型路由
  • Prompt
  • system instruction
  • retrieval 配置
  • tool schema
  • workflow 状态机
  • eval 集
  • guardrails
  • 线上失败样例

1.3 二者不是对立关系，而是上下位关系 ​

更实用的理解通常是：

  • MLOps = 更广义的模型工程体系
  • LLMOps = 面向大模型应用的工程化分支

如果你的系统同时包含：

  • 检索
  • Prompt
  • 工具调用
  • Agent 工作流
  • 传统分类或 rerank 模型

那往往既需要 MLOps，也需要 LLMOps。

2. 为什么 LLMOps 比大家想象中更重要 ​

LLM 系统最容易出问题的点，不只是模型变差，而是：

  • Prompt 改了一句，结果大幅波动
  • 检索策略一变，答案开始跑偏
  • 工具定义升级后，线上行为变化
  • 成本突然飙升
  • 某个模型版本在部分任务上回退
  • 安全策略收紧后，一部分正常场景被误杀

2.1 很多变更看起来小，实际影响面很大 ​

例如一次看似微小的改动：

  • 改了一条 system instruction

可能同时影响：

  • 输出格式
  • 工具调用倾向
  • 引用风格
  • 拒答边界

2.2 很多问题不会直接报错 ​

OpenAI 当前 evaluation best practices 文档强调：

  • 生成式系统存在输出变异性，传统软件测试方法不足以单独覆盖

这也正是 LLMOps 的核心背景：

  • 很多 AI 系统是“没报错，但已经变差了”

2.3 线上问题常常来自“组合退化” ​

最难排查的问题往往不是单点失效，而是组合变化，例如：

  • 模型升级 + Prompt 调整 + 检索改写 + rerank 参数变化

如果没有版本与评测体系，团队会很难回答：

  • 到底是哪一层造成退化

3. 一个完整的 LLMOps 流程通常包含什么 ​

一个更接近真实团队的主链路通常是：

text
Idea / Requirement
 -> Prompt or Workflow Design
 -> Dataset / Eval Set
 -> Offline Evaluation
 -> Staging Verification
 -> Production Release
 -> Monitoring / Feedback
 -> Iteration / Rollback

3.1 如果系统有 RAG，还要多管一层知识链路 ​

需要纳入版本与发布体系的对象包括：

  • chunking 策略
  • embeddings 模型
  • vector store schema
  • metadata filter
  • knowledge release batch

3.2 如果系统有 Agent，还要再多一层动作链路 ​

需要纳入版本与发布体系的对象包括：

  • tool definitions
  • tool routing policy
  • approval gates
  • memory / handoff rules
  • guardrails

3.3 上线对象不再只是“一个模型版本” ​

更准确地说，LLMOps 的发布单元往往是：

  • 一组相互依赖的配置与运行对象

例如：

  • 模型版本
  • Prompt 版本
  • retrieval 版本
  • tool schema 版本
  • eval 运行结果
  • rollout 策略

4. Google 的 CI / CD / CT 思路对 LLMOps 有什么启发 ​

Google Cloud 当前 MLOps 架构资料把经典机器学习工程分成三类持续能力：

  • CI
  • CD
  • CT

这对 LLMOps 也非常有启发。

4.1 CI：让变更可被快速集成与验证 ​

在 LLM 场景里，CI 不只检查代码，还应该检查：

  • Prompt 模板
  • tool schema
  • JSON Schema
  • eval 配置
  • 配置文件合法性

4.2 CD：让变更可被安全发布 ​

这里的发布对象不只是一份镜像，还包括：

  • workflow 配置
  • Prompt 版本
  • 检索策略
  • tool registry
  • 审批策略

4.3 CT：在知识、数据或反馈变化时持续更新 ​

传统 ML 的 CT 更偏：

  • 再训练

而在 LLM 场景里，很多“持续更新”更可能表现为：

  • 知识库增量发布
  • eval 集扩容
  • 失败样例回流
  • rerank / retrieval 调整

所以企业里常见的现实是：

  • 不是每天都训模型
  • 但几乎每天都在更新围绕模型的服务对象

5. LLMOps 的六个核心支柱 ​

5.1 配置与版本管理 ​

至少要能追踪这些变更：

  • 模型版本
  • Prompt 版本
  • system instruction
  • tool schema
  • 检索配置
  • 安全策略
  • eval 集版本

很多团队失败的根因不是没有版本，而是：

  • 只有代码有版本
  • Prompt、schema、retrieval、guardrails 没有版本

5.2 评测体系 ​

没有评测，系统就只能靠“感觉不错”上线。

至少要建立：

  • 离线回归集
  • 高风险样例集
  • 场景化通过标准
  • 失败样例分桶

OpenAI 当前文档明确强调：

  • evals 要覆盖生产环境中的真实任务和失败模式

5.3 可观测性 ​

线上至少要看到：

  • 请求量
  • 延迟
  • token 使用
  • 错误率
  • 工具调用情况
  • 拒答与安全拦截
  • 背景任务状态

5.4 发布与回滚 ​

好的 LLM 系统不只要能发版，还要能安全撤回：

  • 小流量验证
  • A/B 对比
  • 灰度放量
  • 快速回滚

5.5 反馈闭环 ​

成熟系统不会把线上错误只留在客服或 issue 里。

还要把这些内容回流为：

  • 纠错单
  • 新的 eval 样例
  • prompt / retrieval 优化输入

5.6 成本与性能治理 ​

OpenAI 当前官方资料在生产实践里强调：

  • latency 优化
  • prompt caching
  • background mode
  • batch
  • flex processing

这说明成本与性能治理不是“后看报表”，而是要前置进入系统设计。

6. 为什么 LLMOps 和传统后端发布不同 ​

传统后端接口发布，输入输出通常比较稳定。

但在 LLM 场景里，很多看似很小的变化都会被放大。

6.1 输出不是确定性函数 ​

同一输入在不同条件下可能有波动。

6.2 影响结果的层很多 ​

例如：

  • 模型
  • Prompt
  • 上下文
  • 检索
  • 工具
  • 结构化输出

6.3 很多退化只在局部场景暴露 ​

例如：

  • 中文 query 正常
  • 表格文档场景开始退化
  • 长上下文场景突然更慢

这意味着上线验证不能只靠：

  • 看两个 Demo

7. 评测是 LLMOps 的核心，不是附属品 ​

很多团队会把评测理解成：

  • 上线前跑一下

但更成熟的做法通常是：

  • 用评测驱动迭代，而不是用评测做结果装饰

7.1 哪些对象需要评测 ​

不仅是模型，还包括：

  • Prompt
  • RAG
  • Agent
  • tool calling
  • guardrails
  • 结构化输出

7.2 哪些样例最值得优先进入回归集 ​

例如：

  • 线上失败样例
  • 高风险业务样例
  • 边界样例
  • 多轮状态样例
  • 权限敏感样例

7.3 更有用的评测结果应该能回答什么 ​

至少要能回答：

  • 质量有没有提升
  • 哪些场景退化了
  • 成本有没有变高
  • 延迟有没有变差
  • 安全拦截有没有异常

8. RAG / Agent 场景为什么对 LLMOps 提出额外要求 ​

8.1 RAG 不只是“模型 + 文档” ​

还要持续管理：

  • ingestion pipeline
  • chunk 策略
  • embeddings
  • metadata
  • 索引 freshness
  • 知识版本

所以 RAG 的 LLMOps 往往会额外包含：

  • 知识发布流程
  • 对账
  • 纠错闭环
  • 引用回归

8.2 Agent 不只是“模型 + 工具” ​

还要持续管理：

  • tool registry
  • tool schema 版本
  • action approval
  • 状态机
  • handoff 规则
  • fallback 路径

这会让 Agent 的运维对象显著多于普通问答系统。

9. 一个更适合企业的最小 LLMOps 清单 ​

如果团队还没有完整体系，建议至少先补齐下面这 10 项：

  1. 模型、Prompt、tool schema、retrieval 都可版本化
  2. 存在最小离线评测集
  3. 高风险样例单独成集
  4. 上线前必须有 staging 验证
  5. 存在灰度发布与快速回滚能力
  6. trace、错误、token、延迟可观测
  7. 线上失败样例可回流
  8. 成本指标按场景和租户可拆分
  9. 重要工作流有人工接管路径
  10. 每次发布都能说清楚“为什么变更”

如果这 10 项里缺失过半，项目通常还处于“原型工程”而非“可持续工程”。

10. 适合放进平台层的 LLMOps 能力 ​

很多团队一开始会在每个项目里重复造轮子。

更成熟的做法通常是把共性能力上提到平台层。

10.1 适合平台化的对象 ​

例如：

  • Prompt registry
  • eval runner
  • tool registry
  • trace viewer
  • release dashboard
  • rollback entrypoint
  • cost dashboard

10.2 适合项目自定义的对象 ​

例如：

  • 业务样例集
  • 场景通过标准
  • 高风险动作定义
  • 个性化 workflow

一句话理解：

  • 平台层负责“把路铺好”
  • 项目层负责“把场景走通”

11. 成本治理为什么应该写进 LLMOps，而不是财务附录 ​

OpenAI 当前官方资料已经把：

  • prompt caching
  • batch
  • flex processing
  • background mode
  • latency optimization

都明确放进生产实践语境里。

这说明真正成熟的 LLMOps 必须回答：

  • 什么任务必须实时
  • 什么任务可以异步
  • 什么任务适合 batch
  • 什么前缀值得缓存
  • 什么场景该路由到更轻模型

11.1 Prompt caching 带来的工程意义 ​

OpenAI 当前文档明确写到：

  • Prompt Caching 可显著降低长前缀场景的输入成本与延迟

这对企业内部 Copilot、RAG 和 Agent 都很重要，因为这些场景常常有：

  • 很长的 system prompt
  • 很固定的工具定义
  • 很重复的上下文前缀

11.2 Background mode / Batch / Flex 代表什么 ​

它们说明了一个现实：

  • 不是所有 LLM 任务都应该走同步实时链路

这会直接影响你的模板设计和交付清单。

12. 常见反模式 ​

12.1 只有代码有版本，Prompt 和 schema 没版本 ​

这样最容易在出问题时找不到根因。

12.2 没有 eval gate，只靠主观体验上线 ​

这几乎是最常见的问题之一。

12.3 发布时同时改太多层 ​

例如一次同时改：

  • 模型
  • Prompt
  • retrieval
  • 工具定义

最后无法归因。

12.4 只有全局指标，没有场景指标 ​

结果是：

  • 平均值看起来正常
  • 关键场景已经退化

12.5 只监控错误率，不监控质量漂移 ​

很多质量问题不会直接表现成异常码。

13. 推荐搭配阅读 ​

14. 重点官方资源 ​