Wiki Notes

Appearance

01. LLMOps 与生产化详解 ​

1. 什么是 LLMOps ​

最实用的理解是：

  • LLMOps 是围绕大模型应用从设计、评测、发布、监控、回滚到持续优化的一整套工程体系

它解决的不是“怎么第一次把 API 接通”，而是：

  • 如何让系统在真实流量里稳定运行
  • 如何让变更可追踪、可比较、可回退
  • 如何让成本、质量、安全和延迟长期可控

传统 Demo 常常只证明一件事：

  • 这个想法能跑

LLMOps 要证明的则是：

  • 这个系统能上线、能维护、能扩容、能复盘

2. 为什么 Demo 一到生产就突然变难 ​

很多本地 Demo 看起来都没问题，因为它只需要：

  • 跑通 happy path
  • 给出几次像样的结果

但一进入生产，系统马上会面对：

  • 输出波动
  • 成本失控
  • 延迟抖动
  • 检索和知识库不同步
  • 工具调用副作用
  • 高风险样本翻车
  • 模型版本热切换带来的行为变化

OpenAI 的 production best practices 一直在强调，生产化不是“多包一层接口”，而是要同时考虑：

  • 安全
  • 可观测性
  • 发布治理
  • 成本控制
  • 恢复能力

这也是 LLMOps 真正的工程价值所在。

3. LLMOps 到底在管什么 ​

一个成熟的 LLMOps 体系，至少会覆盖这些对象：

  1. Prompt 与系统指令
  2. 模型与模型路由
  3. 知识库、索引与检索配置
  4. 工具定义、Agent 工作流与审批策略
  5. 数据集、评测集和基线结果
  6. 发布、灰度与回滚
  7. 线上观测、成本和事故响应

也就是说，LLMOps 不是单点能力，而是一张控制面。

4. LLMOps 和传统 MLOps 的区别 ​

传统 MLOps 更多围绕：

  • 训练数据
  • 特征工程
  • 训练流水线
  • 模型注册
  • 批量推理

LLMOps 更多围绕：

  • Prompt
  • Context assembly
  • Retrieval
  • Tool calling
  • Agent workflow
  • 在线评测与行为回归

二者不是对立关系，而是关注点不同：

  • MLOps 更像广义模型工程体系
  • LLMOps 更像大模型应用时代的在线工程化分支

5. 生产化系统通常由哪些层组成 ​

一个现实的 LLM 应用，往往至少包含这些层：

text
Application / UI
 -> Orchestration / Prompt Layer
 -> Model Invocation Layer
 -> Retrieval / Tool Layer
 -> State / Memory Layer
 -> Observability Layer
 -> Eval / Release Layer

如果是 Agent 或 RAG 系统，还会额外有：

  • 审批链路
  • 长任务后台执行
  • 知识库更新流水线
  • 事故回放与人工纠偏

所以很多项目失败，不是因为模型不行，而是因为系统层没有一起建。

6. 一套最小可用的 LLMOps 飞轮长什么样 ​

对多数团队来说，起步并不需要先买一套大平台。更重要的是先把下面这个闭环跑起来：

text
需求
 -> Prompt / Workflow 设计
 -> 样本与评测集
 -> 离线评测
 -> 小流量验证
 -> 线上监控
 -> 失败样本回流
 -> 继续优化

只要这个飞轮能持续转，系统就会越来越稳；如果没有这个飞轮，系统就只能靠临时感觉调参。

7. LLMOps 的七个核心支柱 ​

7.1 配置与版本管理 ​

至少要能追踪这些对象的变更：

  • 模型版本
  • system prompt
  • tool schema
  • 检索配置
  • chunking 策略
  • rerank 配置
  • 风险规则和审批策略

如果这些对象的版本不可追踪，系统行为一旦波动，团队几乎不可能快速定位原因。

7.2 数据集与评测体系 ​

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

至少要建立：

  • 离线回归样例
  • 高风险样例集
  • 明确的通过标准
  • 基线版本比较

7.3 发布与回滚 ​

成熟系统不只要能上线，还要能安全撤回：

  • 灰度
  • shadow
  • A/B
  • prompt 回滚
  • 模型回退
  • 工具关停

7.4 可观测性 ​

线上至少要能看到：

  • 请求量
  • 成功率
  • 延迟
  • token 使用
  • 成本
  • 工具调用情况
  • 拒答与安全拦截情况

7.5 成本治理 ​

成本不是上线后再看月报，而是要在设计阶段前置：

  • 模型路由
  • token 预算
  • 缓存
  • batch
  • background mode
  • 异步化

7.6 数据与知识流水线 ​

RAG 系统里，知识库本身就是线上行为的一部分。需要治理：

  • 文档入库
  • chunking
  • embeddings
  • 索引重建
  • 权限变更
  • 删除与失效

7.7 事故响应与持续优化 ​

系统上线后，问题不可能完全消失。真正成熟的团队会把：

  • 告警
  • 复盘
  • 失败样本回流
  • 规则更新

全部纳入固定节奏。

8. Prompt 不是临时文案，而是生产配置 ​

很多团队还把 Prompt 当成聊天窗口里临时试出来的一段文本，这在生产环境里会非常危险。

更稳妥的做法是把 Prompt 当作正式配置资产管理，至少具备：

  • 版本号
  • 变更记录
  • 对应评测结果
  • 回滚路径

因为在 LLM 系统里，一句 Prompt 的变动就可能带来：

  • 风格变化
  • 工具选择变化
  • 成本变化
  • 安全边界变化

9. 模型选择在生产中是一条运行时策略 ​

很多系统一开始会默认：

  • 全量固定用一个模型

但成熟系统通常会把模型选择做成运行时策略：

  • 简单任务走小模型
  • 默认任务走中模型
  • 高风险或复杂任务升级到强模型
  • 失败或超时后有 fallback

这意味着模型管理本身就是 LLMOps 的一部分，而不是初始化设置。

10. RAG 和知识库流水线为什么也属于 LLMOps ​

很多团队会把检索和知识库问题单独看成“数据问题”，这在工程上是不够的。

因为线上输出质量经常直接受这些因素影响：

  • 文档有没有入库
  • 索引是不是最新
  • chunking 是否改变
  • 权限标签是否正确
  • rerank 是否退化

所以 RAG 生产化至少要能回答：

  • 这次答案使用了哪一版知识
  • 文档什么时候更新进索引
  • 权限变更是否已经生效

11. Agent 场景下，LLMOps 会再多几层要求 ​

如果系统里有 Agent，就不只是：

  • Prompt
  • 模型
  • 检索

还会新增：

  • 工具 schema 管理
  • 工具权限沙箱
  • 审批链路
  • 长任务恢复
  • 人工纠偏
  • 状态机与回放

这也是为什么很多“看起来只是加了个 Agent”的项目，运维复杂度会上一个量级。

12. 发布策略不要只靠“手动试几下” ​

更稳妥的上线策略通常包括：

12.1 离线评测 ​

先在固定样例上看质量、成本和安全边界。

12.2 Shadow 流量 ​

新版本不直接对用户生效，只在旁路运行，比较行为差异。

12.3 小流量灰度 ​

只放一小部分真实流量，观察：

  • 成功率
  • 延迟
  • 成本
  • 高风险样本表现

12.4 可回滚发布 ​

上线前就确定：

  • 怎么切回旧 Prompt
  • 怎么切回旧模型
  • 怎么关闭高风险工具

13. 回滚对象不能只盯代码 ​

AI 系统回滚往往比普通后端更复杂，因为可能需要回滚的不只是代码，还有：

  • 模型版本
  • Prompt 版本
  • 工具 schema
  • 检索配置
  • rerank 配置
  • 索引版本
  • 审批规则

如果团队只会 git revert，很多线上问题依然无解。

14. 线上监控看什么才真正有意义 ​

只看 API 成功率远远不够。

建议至少监控：

  • 请求量
  • 失败率
  • P50 / P95 延迟
  • token 使用
  • 单任务成本
  • 模型路由分布
  • 工具失败率
  • 安全拦截率
  • 人工接管率

对于 RAG 和 Agent，还建议额外看：

  • 检索证据质量
  • 工具调用正确率
  • 回合数
  • approval timeout rate

15. 成本治理为什么必须前置 ​

OpenAI 的 cost optimization、prompt caching、batch、background 等资料都指向一个现实：

  • 成本优化不是“上线以后少花点钱”，而是会直接改变架构设计

常见前置手段包括：

  • 减少无关上下文
  • 控制输出长度
  • 用缓存复用稳定前缀
  • 用 batch 处理离线任务
  • 用 background mode 承接长任务
  • 把高复杂度步骤和低复杂度步骤拆开路由

如果不前置，系统一旦放量，账单和延迟会一起爆。

16. 延迟优化也不是模型单点问题 ​

很多团队一提延迟，就只想到：

  • 换个更快模型

但真正的端到端延迟通常来自整条链路：

  • 输入预处理
  • 检索
  • rerank
  • 模型 prefill
  • 输出生成
  • 工具调用
  • 后处理

所以延迟治理往往要同时做：

  • 少发请求
  • 并行工具
  • 缩短上下文
  • 缩短输出
  • 合理拆分同步和异步步骤

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

没有评测，系统就没有稳定的质量基线。

更重要的是，评测不应只依赖某一个托管入口。到了 2026-07-07 这个时间点，OpenAI 官方资料已经说明：

  • 旧的 Evals API / dashboard 处于迁移阶段
  • 2026-10-31 进入只读
  • 2026-11-30 关闭

这对工程的直接启示是：

  • 评测思想必须保留
  • 但评测资产、数据集、grader 逻辑和 CI 集成不能被单一旧入口绑死

这里关于时间节点的说法，是依据官方迁移说明做出的当前日期判断。

18. 一次发布最好是“配置快照”，不是一句“我改了 Prompt” ​

成熟的 LLMOps 发布对象，通常不只是代码版本，而是一份可追踪的 release bundle。

建议至少把这些对象绑定到同一个发布单元里：

  • 代码版本
  • 模型版本或路由策略
  • prompt / developer instructions
  • tool schema
  • 检索配置
  • index / knowledge snapshot
  • 风险规则与审批策略
  • 评测结果摘要

这样做的收益很实际：

  1. 线上退化后能知道到底变了哪一层。
  2. 灰度时能精确比较 bundle A 和 bundle B，而不是笼统比较“新旧版本”。
  3. 回滚时能整套切回，而不是只回一部分。

如果发布单元里只包含代码，而不包含 Prompt、检索和策略配置，那么很多所谓“回滚成功”的状态，其实只是代码回去了，线上行为并没有真的回去。

19. LLMOps 要有运行手册，不只是监控大盘 ​

很多团队会做：

  • 日志
  • 指标
  • trace

但一出事故仍然慌，因为没有把“看到异常后怎么判断、怎么止损、怎么回滚”写成操作手册。

一个最小 runbook 至少应覆盖：

场景值班人第一动作
质量骤降先比对最近 release bundle、评测基线和失败样例分桶
成本飙升先看 token、工具、检索和模型路由哪层异常
延迟抖动先区分模型生成、工具链路、检索还是外部依赖
高风险误放行先关闭高风险工具或切严审批策略
知识库污染先冻结索引切换和文档发布入口

根据 OpenAI Production best practices 文档在 2026-07-07 可访问的说明，进入生产阶段需要同时考虑架构健壮性、速率限制、成本和运维策略，而不仅仅是把原型代码部署出去。

这意味着真正的 LLMOps 不只是“知道问题发生了”，而是：

  • 团队能在十几分钟内找到最近可回滚的安全状态

20. 成本和延迟策略应该提前进入设计评审 ​

OpenAI Cost optimization 文档在 2026-07-07 可访问的说明提到，降成本常常依赖减少请求、减少 token、选更小模型，以及使用 Batch API 和 flex processing。

OpenAI Latency optimization 文档在 2026-07-07 可访问的说明也强调，流式输出、并行步骤和减少生成 token 数，往往比单纯减少一点点 prompt token 更有效。

Anthropic Prompt caching 与 Context windows 文档在 2026-07-07 可访问的说明则进一步说明：

  • 缓存命中依赖稳定前缀
  • tools、system、messages 都会进入上下文和缓存边界
  • 随着上下文增长，准确率和召回会下降

这些资料共同指向一个很实际的结论：

  • 成本和延迟不是“上线后再优化”的附属题，而是设计阶段就该决定的系统形状

例如在评审时就应该问：

  1. 这个步骤真的需要 LLM 吗。
  2. 这个步骤必须同步返回吗。
  3. 这部分规则是否能缓存或预计算。
  4. 这批工作更适合实时、background 还是 batch。
  5. 这次新增的工具 schema 会不会把每次请求的 token 固定成本抬高。

20.1 先把任务分成三类，再谈优化 ​

OpenAI 当前把 Background mode 和 Batch 分成单独能力，本质上是在提醒你：

  • 实时任务：更看重首字节、端到端响应和交互体验
  • 后台任务：更看重状态恢复、重试、长任务可观测性
  • 批处理任务：更看重吞吐、单价和离线窗口利用率

如果所有任务都默认走同步在线链路，团队后面通常会同时付出三种代价：

  • 用户端等待时间变长
  • 系统状态管理更混乱
  • 成本缺少明显下降空间

20.2 发布评审时最好把“固定成本”单独拿出来看 ​

很多时候单次调用的成本抬升，不是因为用户问题更长，而是因为：

  • system 前缀变长
  • tools schema 变多
  • 检索证据注入更多
  • 历史会话装配更重

这些变化如果只在代码评审里看功能正确性，往往要到线上放量后才暴露。

21. 推荐的最小可用生产清单 ​

如果团队还很早期，至少先做到这些：

  1. Prompt、模型配置和工具配置都进版本管理。
  2. 有离线回归样例。
  3. 每次变更都跑自动评测。
  4. 线上保留 trace 和关键输出证据。
  5. 有明确的回滚路径。
  6. 有成本和延迟告警。

这六条不算豪华，但基本决定了系统是不是“能真正上线维护”。

21.1 如果要把这六条真正做实 ​

通常还要补三个最小动作：

  1. 每次发布都生成一份可回放的配置快照。
  2. 每个高频任务都至少保留一组稳定回归样例。
  3. 值班同学能在告警触发后十几分钟内定位到最近一版变更。

22. 一个现实的组织分工视角 ​

很多 LLM 项目失败，不是因为技术方案一定错，而是因为没人清楚谁负责什么。

生产化至少应明确：

  • 谁负责 Prompt 与工作流变更
  • 谁负责模型路由与成本
  • 谁负责知识库更新
  • 谁负责高风险审批
  • 谁负责线上事故与值班

没有责任边界，LLMOps 很容易退化成“大家都懂一点，但谁都接不住”。

23. 常见反模式 ​

23.1 只记录 Prompt，不记录检索和工具配置 ​

这样一旦系统波动，根本无法比较。

23.2 只有 Demo 验证，没有线上监控 ​

上线之后等于盲飞。

23.3 只看成功样本，不看失败样本 ​

系统会持续重复在同一类坑里摔倒。

23.4 只看模型，不看系统 ​

很多退化根因其实在检索、工具、审批或上下文装配。

23.5 成本和回滚在上线后才补 ​

这通常补不回来。

24. 推荐搭配阅读 ​

25. 重点官方资源 ​

以下资源是本次补写时重点参考的官方资料，适合继续补强评测、发布、成本、后台执行和生产治理设计：

26. 一句话总结 ​

LLMOps 不是把模型接进系统后的附属运维，而是把大模型应用从“能跑的 Demo”变成“可评测、可发布、可回滚、可监控、可持续优化”的生产能力。