从MLOps到LLMOps：大模型应用的持续交付与观测
本文目录
- MLOps与LLMOps的差异
- 交付物：不只是模型文件
- 评测体系设计
- 发布、灰度与回滚
- 线上观测与成本治理
- 降级与事故复盘
- 最小可行LLMOps清单
传统MLOps关注数据集版本、特征、模型注册、A/B与漂移监控。大模型应用额外引入Prompt、检索索引、工具权限、Token成本与内容安全。许多团队能做出漂亮Demo，却在「改一句话提示导致全站行为变化」时失去控制。LLMOps要解决的，就是把这种系统纳入可持续交付。
一、MLOps与LLMOps的差异
| 维度 | 经典ML | LLM应用 |
|---|---|---|
| 核心工件 | 模型权重+特征 | 模型选择+Prompt+索引+工具 |
| 变化频率 | 训练周期 | 提示与知识可能日更 |
| 质量度量 | 准确率/AUC | 忠实度、有用性、安全、成本 |
| 失败模式 | 漂移、偏差 | 幻觉、注入、供应商变更 |
| 回滚 | 切模型版本 | 切提示/索引/路由策略 |
二、交付物：不只是模型文件
建议将下列对象纳入版本仓库或配置中心：
- 系统提示与任务模板
- 工具（函数）定义与权限映射
- 检索索引构建脚本与语料快照标识
- 解码参数与路由规则（不同意图用不同模型）
- 安全策略版本
- 评测集与评分脚本
每一次生产变更应可追溯到「谁、为何、改了什么、评测结果、审批人」。
三、评测体系设计
建立三层评测：
- 冒烟集（几十条）：每次提交必跑，分钟级完成。
- 回归集（数百条）：覆盖历史故障与核心业务路径。
- 深度评测：发版前人工抽检+红队测试。
自动评分可用规则（JSON合法性、必含字段、禁止词）与模型判分混合，但关键结论仍需抽样人工确认。对RAG系统，分别评检索与生成，避免「生成通顺」掩盖「证据错误」。
四、发布、灰度与回滚
不要在生产直接改提示字符串。推荐流程：开发环境验证 → 预发全量回归 → 灰度（内部用户/小流量） → 全量。灰度期间盯住：错误率、拒答率、延迟、Token成本、用户负反馈。
回滚不只是代码回滚，还包括提示配置与索引别名切换。索引重建若耗时长，应支持双索引蓝绿，而不是覆盖写。
五、线上观测与成本治理
最小指标集：
- 请求量、成功率、P95延迟
- 输入/输出Token与费用（按功能线拆分）
- 空检索率、引用缺失率（RAG）
- 安全拦截率、人工接管率
- 模型/提示版本分布
成本治理手段：缓存相同查询、缩短历史窗口、小模型处理分类意图、大模型处理复杂生成、对超长输出截断、设置租户配额。没有分功能成本看板，优化无从谈起。
供应商静默升级模型也可能改变行为。应锁定模型版本号，并在变更时重新跑回归，而不是长期跟随「latest」。
六、降级与事故复盘
预设降级路径：主模型超时 → 备用模型；生成失败 → 返回检索结果列表；安全服务失败 → 拒绝高风险意图而非放行。对客界面要有友好错误，而不是空白或原始堆栈。
事故复盘模板：时间线、影响面、触发变更、根因（提示/检索/模型/工具/流量）、短期修复、长期预防、评测集是否补充案例。把案例沉淀进回归集，防止同一问题第三次出现。
七、最小可行LLMOps清单
- 提示与关键配置进入版本控制
- 冒烟+回归评测可在CI运行
- 生产变更可灰度与一键回滚
- Token成本按产品模块可见
- 具备基础安全过滤与审计日志
- 有值班与降级预案
做到以上六条，团队才有资格说「我们在运营LLM应用」，而不是「我们有一个能演示的聊天框」。工程纪律带来的稳定性，往往比再换一个更强模型更能提升真实业务指标。