Skip to content
←

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

中文
0%
정확도 0%
💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

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

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 年的教训。

현재 단락 (1/191)

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

작성 글자: 0자원문 글자: 5,708자작성 단락: 0/191