LLMOps：大模型应用的生产运营
把 demo 做上线只是开始：prompt 改一个词全链路行为变了怎么管？成本突然翻倍怎么查？答错的 case 怎么变成资产？LLMOps 就是回答这些问题的体系——也是「有没有真把 LLM 应用跑在生产上」的面试照妖镜。
LLMOps 和 MLOps 的区别（必考）
| 维度 | 传统 MLOps | LLMOps |
|---|---|---|
| 模型来源 | 自己训练、版本化模型 | 多用 API/开源基座，很少从零训 |
| 「代码」是什么 | 特征工程 + 模型代码 | Prompt、RAG 配置、工具定义也是代码，要版本化 |
| 评估 | 确定性指标（AUC/F1） | 非确定性输出，需评估集 + LLM judge + 人评 |
| 成本模型 | 训练贵、推理便宜 | 按 token 计费，推理成本是大头且随用量线性涨 |
| 失败模式 | 数值漂移、特征腐烂 | 幻觉、注入、跑偏、上游模型悄悄变更 |
| 迭代单元 | 重训模型（周/月） | 改 prompt/检索/路由（小时/天） |
生命周期全景
开发期 发布期 运行期 反馈期
评估集建设 ──► 影子流量/灰度 ──► 监控+护栏+成本 ──► bad case 回流
prompt/RAG 调优 A/B 实验 告警与降级 评估集扩充/微调数据
▲ │
└───────────────────── 数据飞轮 ◄───────────────────────┘核心思想：评估驱动 + 闭环。没有评估集的 LLM 应用 = 没有测试的代码（评估方法详见 模型评估）。
Prompt 工程化管理
- 版本化：prompt 与代码分离存储（配置中心/专门平台），带版本号，可 diff、可回滚——「prompt 上线后发现变笨了」必须能一键回到上一版。
- 回归测试：每次改 prompt 跑评估集对比，CI 里挡住「改好了 A 场景、改坏了 B 场景」的隐性回归。
- 环境隔离：dev/staging/prod 的 prompt 独立发布，与代码发布同等纪律。
- 上游模型变更管理：API 模型升级/微调版本切换都可能改变行为，切换前全量跑评估集，灰度放量。
监控：三层指标体系
| 层 | 指标 | 用途 |
|---|---|---|
| 系统层 | TTFT、整体延迟、错误/超时率、token 用量与成本 | 和传统服务监控同构，按链路归因 |
| 质量层 | LLM judge 抽样评分、幻觉/忠实度、拒答率、工具调用成功率、护栏拦截率 | LLM 特有，靠抽样 + 自动评估 |
| 业务层 | 任务解决率、转人工率、用户点踩率、留存 | 最终裁判 |
实施要点：全链路 trace（每步 prompt/输出/token/延迟，工具如 LangSmith/Langfuse，见 应用框架）；质量层用采样评估控制成本（如 5% 流量送 judge）；告警阈值盯「变化率」而非绝对值（成本日环比 +50% 比绝对数字更有信息量）。
成本治理
成本失控是 LLM 应用最常见的生产事故，抓手按性价比排序：
- 缓存：前缀缓存（稳定 system prompt，见 上下文工程）+ 精确/语义缓存（重复问题直接回答）；
- 模型路由：简单请求走小模型，复杂才上旗舰（分级路由，见 SLM）；
- 上下文瘦身：历史压缩、检索 top-k 控制、工具结果截断；
- 输出控制：max_tokens 上限、要求简洁、结构化输出省废话；
- 批处理：离线任务走 Batch API（通常半价）；
- 预算与熔断：按用户/租户设 token 配额，异常调用熔断——防止循环 Agent 烧穿预算。
发布与可靠性
- 灰度发布：新 prompt/模型先 1%~5% 流量，质量+业务指标达标再放量；高风险改动先跑影子流量（新旧并行执行、只记录不生效，离线对比）。
- 降级链：主模型超时/失败 → 备用模型 → 缓存答案 → 兜底话术；多供应商容错。
- 护栏（Guardrails）：输入侧注入检测/敏感词，输出侧内容审核/PII 过滤/格式校验，Agent 侧步数与权限限制（见 大模型安全）。
数据飞轮：把 bad case 变成资产
线上交互 ──► 采集（点踩/低分/转人工/护栏命中） ──► 人工标注归因
│
微调数据集 ◄── 高质量问答对沉淀 ◄── 修复验证 ◄── 加入评估集- 每个 bad case 归因到环节（检索没召回？prompt 歧义？模型能力？）再修，不要上来就改 prompt；
- 评估集随业务演化持续扩充，这是团队最值钱的资产之一；
- 积累的优质交互数据后续可用于 SFT/DPO（见 微调工具链），形成「越用越好」的飞轮。
上线前检查清单（面试可直接背）
- 评估集与基线分数（质量有数）
- 全链路 trace 与三层监控告警（出事能看见）
- prompt 版本化与回滚方案（改坏能回退）
- 成本预算、配额与熔断（钱有上限）
- 降级链与多供应商容错（挂了有兜底）
- 输入输出护栏与权限边界（安全有闸门）
- bad case 回流通道（问题能变资产）
高频追问
Q：LLMOps 和 MLOps 最大的区别？ 迭代单元变了：MLOps 围绕「重训模型」，LLMOps 围绕「改 prompt/检索/路由配置」——快但同样危险，所以 prompt 要像代码一样版本化、测试、灰度；同时评估从确定性指标变成「评估集 + judge + 人评」的组合。
Q：线上怎么发现「模型变笨了」？ 分层告警：质量层（judge 抽样分、拒答率、工具成功率）突变 + 业务层（点踩率、转人工率）趋势 + 主动哨兵（定时跑固定评估集对比基线）。只靠用户投诉发现 = 已经晚了。
Q：成本突然翻倍，怎么排查？ 按归因链查：trace 按链路/租户聚合 token 用量 → 定位是调用量涨（业务/滥用/Agent 死循环）还是单次变贵（上下文膨胀、缓存命中率跌、路由失效全走了大模型）。预防靠配额 + 熔断 + 缓存命中率监控。
Q：prompt 变更怎么安全上线？ 评估集回归（挡隐性回归）→ 影子流量对比（高风险改动）→ 灰度放量盯指标 → 可一键回滚。核心观念：prompt 就是代码，享受同等的发布纪律。
Q：怎么从零搭一个最小可用的 LLMOps？ 不需要大平台：① 50~200 条评估集 + 一个 judge 脚本；② Langfuse 等开源 trace 自部署；③ prompt 进配置中心带版本；④ 成本日报 + 阈值告警；⑤ 点踩按钮 + bad case 表格。一周能搭完，覆盖 80% 价值。