LLMOps 完全指南：模型 · 提示词 · 评测集三轴版本管理、Canary、成本控制、平台团队 (2025)

Season 4 Ep 11 — 如果说 Ep 10 是“守护的轴”，那么 Ep 11 就是可持续运转的轴。如何避开“第一次发布只要一周，之后的一年是地狱”。

• Prologue — “LLMOps 是 MLOps 还是 DevOps？”
• 第 1 章 · 三轴版本管理
  • 1.1 三条轴
  • 1.2 发布元数据
  • 1.3 与日志打通
• 第 2 章 · 发布策略
  • 2.1 Shadow
  • 2.2 Canary
  • 2.3 Blue-Green
  • 2.4 A/B 实验
  • 2.5 Percentage Router
• 第 3 章 · 成本控制
  • 3.1 token 审计
  • 3.2 缓存
  • 3.3 模型路由
  • 3.4 token 瘦身
  • 3.5 存储与网络
  • 3.6 现实的节省目标
• 第 4 章 · 平台团队的组织
  • 4.1 三个层次
  • 4.2 接口
  • 4.3 按规模划分
  • 4.4 政治陷阱
• 第 5 章 · 评测框架 — LLMOps 的心脏
  • 5.1 评测集版本化
  • 5.2 CI 集成
  • 5.3 On-demand 实验
  • 5.4 生产环境反馈闭环
• 第 6 章 · 可观测性与运维
  • 6.1 Ep 6 的延伸
  • 6.2 核心看板
  • 6.3 on-call
  • 6.4 应对厂商故障
• 第 7 章 · 数据治理
  • 7.1 数据分级
  • 7.2 用户同意
  • 7.3 PII 处理
  • 7.4 许可
• 第 8 章 · 失败案例 10 则
  • 8.1 token 暴涨
  • 8.2 提示词无法回滚
  • 8.3 模型 deprecation
  • 8.4 一个区域故障导致整体宕机
  • 8.5 RAG 索引漂移
  • 8.6 用户日志留存过度
  • 8.7 提示词注入
  • 8.8 False refusal 激增
  • 8.9 向量 DB 成本暴涨
  • 8.10 A/B 结果解读错误
• 第 9 章 · KPI 与 OKR
  • 9.1 产品 KPI
  • 9.2 工程 KPI
  • 9.3 AI Quality KPI
  • 9.4 运维 KPI
• 第 10 章 · 韩国与亚洲环境
  • 10.1 云
  • 10.2 供应商多元化
  • 10.3 员工培训与文化
• 第 11 章 · 工具集锦 (2025)
  • 11.1 网关与路由
  • 11.2 可观测性
  • 11.3 评测
  • 11.4 提示词注册表
  • 11.5 数据/特征
  • 11.6 服务部署
  • 11.7 护栏与安全
  • 11.8 成本与资源
• 第 12 章 · 反模式 10 则
  • 12.1 只换模型就发布
  • 12.2 依赖单一厂商
  • 12.3 提示词放在 Git 之外
  • 12.4 不用 Shadow 与 Canary
  • 12.5 没有成本看板
  • 12.6 评测集与训练数据混在一起
  • 12.7 对厂商故障没有预案
  • 12.8 AI Platform 团队权力过大
  • 12.9 完全不考虑合规与审计
  • 12.10 不写 Postmortem
• 第 13 章 · 检查清单 — LLMOps 上线前的 12 项
• 第 14 章 · 下期预告 — Season 4 Ep 12：“AI 产品设计”

Prologue — “LLMOps 是 MLOps 还是 DevOps？”

两者都是，两者又都不是。

• 与 MLOps 不同，模型训练很少发生（用的是托管 API 或适配器）
• 与 DevOps 不同，结果是概率性的，因此测试很难
• 但发布、观测、回滚与成本控制，需要两边的全部教训

2025 年 LLMOps 的核心问题:

1. 三轴版本管理（模型 · 提示词 · 评测集）如何保持一致地管理？
2. 成本: 如何找出并减少 token 浪费？
3. 组织: AI 平台团队与产品团队的边界在哪里？
4. 合规与审计: 如何为每一次发布与变更留下痕迹？

第 1 章 · 三轴版本管理

1.1 三条轴

• Model: gpt-4o-2025-03-15、claude-3.7-sonnet、qwen2.5-14b-awq 等
• Prompt: 系统提示词在 Git/注册表中的版本
• Eval set: 与每次发布关联的评测集快照

1.2 发布元数据

release: v1.4.2
model: anthropic/claude-3.5-sonnet-2025-02
prompt_version: sales_copilot@v23
eval_set: v12 (scored 91.3/100)
adapters:
  - korean_tone_lora@v3
guardrails:
  - llama_guard@v1
  - custom_policy@v8
rollout:
  canary: 5%

每一次发布，都必须把这份元数据以不可变的方式固定下来。

1.3 与日志打通

• 在每条请求日志中包含 release_id
• 之后可以 100% 复现“这条响应是在哪套配置下产生的”
• 这是合规审计的最低要求

第 2 章 · 发布策略

2.1 Shadow

• 对生产流量并行调用新版本（响应不使用）
• 与既有响应做 diff、比较指标
• 在不影响用户的前提下确认回归与改进

2.2 Canary

• 按 1–5% → 10% → 50% → 100% 依次扩大
• 每个阶段设自动闸门（评测集分数、p95 延迟、错误率）
• 失败时立即回滚到上一个版本

2.3 Blue-Green

• 两套环境（Blue 承载生产，Green 待命）分别放旧版本与新版本
• 切换靠负载均衡器的切流
• 回滚是即时的（秒级）

2.4 A/B 实验

• 确保统计显著性（样本 · 周期）
• 指标: Quality, Cost, Latency, User satisfaction
• 终端用户的划分（按用户/按企业）

2.5 Percentage Router

• 一个小型 LLM gateway 服务按用户 · 组织 · 功能拆分流量
• 用开关即可立刻切换版本
• Helicone、Portkey、Martian、LiteLLM 等开源/SaaS 网关

第 3 章 · 成本控制

3.1 token 审计

• 逐请求记录 input/output token
• 按用户 · 功能 · 端点汇总
• 每周复盘成本最高的端点与提示词

3.2 缓存

• 提示词缓存: Anthropic · OpenAI · Google 的原生能力
• 响应缓存: 对相同或相似的输入复用之前的响应
• RAG 检索缓存: 缓存查询 → 文档的映射

3.3 模型路由

• 简单问题 → 小模型 → 复杂问题 → 大模型
• 路由器本身就是一个分类器（LoRA 或规则）
• 2025 年 Martian、RouteLLM 这类开源路由器崛起

3.4 token 瘦身

• 持续给系统提示词减重
• 优化放进 RAG 的文档数量
• 把 JSON 响应字段区分为必填/选填
• 用 Structured Output（Ep 2）消除浪费

3.5 存储与网络

• 日志长期归档走 cold storage
• 向量 DB 索引的压缩与分区
• 尽量减少跨区域传输

3.6 现实的节省目标

• 前 3 个月: 20–40%（低垂的果实）
• 第 6 个月: 再加 15–30%（模型路由 · 缓存的深化）
• 之后: 5–10% 的维持性改善

第 4 章 · 平台团队的组织

4.1 三个层次

• Foundation / Infra: GPU · 模型服务 · 观测基础设施
• AI Platform: 公共 SDK · 提示词注册表 · 评测框架 · 护栏
• Product AI: 各产品的功能实现（聊天机器人 · RAG · 智能体 · 语音等）

4.2 接口

• AI Platform → Product AI: 易用的 SDK + 标准可观测性
• Infra → AI Platform: 稳定的服务与成本看板
• 每一条边界都按带有 SLA + on-call 的 API 来管理

4.3 按规模划分

• 初创 10–50 人: 不拆团队，“1–2 名 AI 负责人 + 产品工程师”
• 中型 50–500 人: AI Platform 5–15 人，每个产品配 AI owner
• 大企业 500 人以上: 三层全部拆开，安全与合规另设团队

4.4 政治陷阱

• “所有 AI 都归我们团队” → 瓶颈
• “每个产品自建 AI 基础设施” → 重复浪费
• 折中: 统一平台 + 产品自治是 2025 年的主流模式

第 5 章 · 评测框架 — LLMOps 的心脏

5.1 评测集版本化

• Git LFS 或数据注册表（DVC, Hugging Face Datasets, S3 + 元数据）
• 每个评测集都带版本 · 模式 · 标注人 · 创建日期
• 与训练数据严格分离

5.2 CI 集成

• 每个 PR 自动跑一遍轻量评测集
• 合并之后异步跑大型评测集
• 检测到回归时通过 Slack/Discord 告警

5.3 On-demand 实验

• 对新模型候选 · 提示词变体立刻做评测
• 成本 · 结果的对比看板
• 并行实验（多个变体同时跑）

5.4 生产环境反馈闭环

• 用户 thumbs → 标注候选
• 标注人复核 → 加入评测集
• 每月一次“事故案例整合发布”

第 6 章 · 可观测性与运维

6.1 Ep 6 的延伸

• Trace/Span/Metric 三层
• 基于 OpenTelemetry
• LangFuse/LangSmith/Phoenix/Helicone/W&B

6.2 核心看板

• 质量: 评测集分数走势、thumbs up/down
• 成本: 日/月合计、按功能、按用户
• 延迟: p50/p95/p99、TTFT、TTL
• 安全: 攻击尝试、拒绝率、false refusal
• 错误: 按状态、按厂商、重试率

6.3 on-call

• 为主要指标定义 SLI/SLO
• 告警等级（P1/P2/P3）
• Runbook: 供应商故障、成本暴涨、质量回归
• 事故之后 24–72h 内完成 Postmortem

6.4 应对厂商故障

• 多供应商路由（OpenAI 故障 → 自动回退到 Anthropic）
• 本地模型的最小功能模式
• 升级路径要清晰

第 7 章 · 数据治理

7.1 数据分级

• Public / Internal / Confidential / PII / Regulated
• 每个等级各自的模型 · 厂商 · 日志留存策略
• 用自动分类器（DLP）

7.2 用户同意

• 告知 AI 的使用，日志留存范围要透明
• 提供删除 · 导出请求的 API
• 遵守 GDPR 与个人信息保护法

7.3 PII 处理

• 输入时检测 PII → 掩码/假名化（pseudonymize）
• 输出时再次掩码
• 审计日志只保留哈希

7.4 许可

• 生成合成数据所用模型的条款
• 第三方数据使用合同
• 应对用户著作权问题（引用 RAG 检索结果）

第 8 章 · 失败案例 10 则

8.1 token 暴涨

系统提示词从 3000 更新到 8000 token 之后，成本急剧上升。

8.2 提示词无法回滚

用的是内联字符串而不是 Git，找不到之前的版本。

8.3 模型 deprecation

供应商公告模型下线，替代模型上出现回归。

8.4 一个区域故障导致整体宕机

依赖单一区域。没有多区域/多厂商的回退。

8.5 RAG 索引漂移

文档更新没有触发索引重建，答案陈旧。

8.6 用户日志留存过度

在合规审计中被指出，被罚款。

8.7 提示词注入

通过间接注入导致公司内部文档泄露。

8.8 False refusal 激增

护栏收紧之后，正常请求的拒绝率上升。

8.9 向量 DB 成本暴涨

生成的切片比预期多，月度成本翻倍。

8.10 A/B 结果解读错误

样本不足 · 忽视方差，把错误的版本推上了线。

第 9 章 · KPI 与 OKR

9.1 产品 KPI

• Task completion rate
• Time saved（按用户）
• NPS / Retention
• Adoption / Active usage

9.2 工程 KPI

• p95 latency
• Error rate
• Cost per request
• Availability (SLA)

9.3 AI Quality KPI

• Eval set score（周/月）
• Hallucination rate
• Safety violations
• False refusal rate

9.4 运维 KPI

• MTTR (mean time to recovery)
• 事故频率（周/季度）
• 发布周期（每周几次）
• 测试覆盖率

第 10 章 · 韩国与亚洲环境

10.1 云

• AWS · GCP · Azure · Oracle + 本土（NHN Cloud, KT Cloud, Naver Cloud）
• 依合规审计要求，可能必须用本土云/本地部署
• 为首尔 · 东京区域的延迟做准备

10.2 供应商多元化

• OpenAI · Anthropic · Google · Cohere · Mistral + 本土（Upstage, LG AI Research）
• 金融 · 公共部门: 对本土厂商有优待条件

10.3 员工培训与文化

• AI 使用指南（防止公司内部数据外泄）
• 提示词工程基础培训（1–2 小时）
• 新产品引入 AI 之前先做安全评审

第 11 章 · 工具集锦 (2025)

11.1 网关与路由

• LiteLLM, Portkey, Helicone, Martian, OpenRouter

11.2 可观测性

• LangFuse, LangSmith, Phoenix(Arize), Helicone, W&B Weave, Datadog/NewRelic LLM extensions

11.3 评测

• RAGAS, DeepEval, Promptfoo, Giskard, PyRIT（攻击）, OpenAI Evals, Confident AI

11.4 提示词注册表

• LangSmith Prompt Hub, Humanloop, PromptLayer, W&B Weave, Agenta

11.5 数据/特征

• Weights & Biases Artifacts, MLflow, DVC, LakeFS

11.6 服务部署

• vLLM, TGI, SGLang, TensorRT-LLM, Ollama, Modal, Anyscale, Together, Fireworks

11.7 护栏与安全

• NeMo Guardrails, Guardrails AI, Lakera Guard, Rebuff, Azure Content Safety, Google Cloud Model Armor

11.8 成本与资源

• Helicone Cost Insights, OpenMeter, CloudZero, Cast AI, Karpenter(K8s)

第 12 章 · 反模式 10 则

12.1 只换模型就发布

没有重新确认评测集与提示词就推全量。

12.2 依赖单一厂商

故障 · 涨价 · 条款变更的风险。

12.3 提示词放在 Git 之外

配置文件 · 内联代码 · 只在 SaaS 里 → 版本管理消失。

12.4 不用 Shadow 与 Canary

到生产环境才发现问题。

12.5 没有成本看板

月底看到账单才吓一跳。

12.6 评测集与训练数据混在一起

评测被灌水。

12.7 对厂商故障没有预案

用户体感强烈的宕机。

12.8 AI Platform 团队权力过大

压制了 Product AI 的自主性。

12.9 完全不考虑合规与审计

上线之后被罚款 · 被强制停用。

12.10 不写 Postmortem

同样的事故反复发生。

第 13 章 · 检查清单 — LLMOps 上线前的 12 项

• 三轴（模型 · 提示词 · 评测集）版本化，并固定发布元数据
• 搭好 Shadow + Canary + 自动回滚
• 成本看板（日/月，按功能 · 按用户）
• 多厂商的回退路径
• 评测框架 + CI 集成
• 可观测性（Trace/Metric）的标准埋点
• 护栏与 Red team CI
• SLI/SLO + on-call 体系
• 数据分级 · PII 掩码 · 删除 API
• 事故响应与 Postmortem 流程
• AI 平台与产品之间就责任 · API 达成一致
• 员工培训与安全指南

第 14 章 · 下期预告 — Season 4 Ep 12：“AI 产品设计”

如果工程侧已经稳定，剩下的就是用户体验。

• 确定性 UI 与生成式 UI 的边界
• 构建“信任”的设计（引用 · 不确定性 · 可编辑性）
• 反馈 UX: 👍/👎 之外的模式
• 流式 · 延迟 · 反馈的处理
• Agent UX: 进行 · 批准 · 中断 · 回放
• Voice UX 的深入（Ep 9 的延伸）
• 数据与学习的 UX
• 上手引导与第一印象的设计
• 失败与故障的 UX
• 无障碍与包容性
• 有伦理的 AI UX
• 面向韩语与韩国文化的定制

不是“好的 AI 产品 = 好的模型 + 好的 UX”，而是“好的 AI 产品 = 在约束之内建立信任的 UX 设计”。

下一篇再见。

总结: LLMOps 可以概括为三轴版本管理 · Shadow/Canary · 成本控制 · 平台团队 · 审计。它吸收了 MLOps 与 DevOps 的教训，但还需要针对 LLM 特有的概率性与厂商依赖的额外做法。做出来一次已经变得容易，但要做出“一年之内不停机、持续改进的 LLM 产品”，本文的 12 项检查清单是最低限度的起点。“AI 不是拿来发布的，而是拿来跑的”，这就是 2025 年的教训。