Wiki Notes

Appearance

LLMOps 专题 ​

版本：v1.7

最后更新：2026-07-08

状态：已并入 LLM 与生产化总目录

这一页现在保留为 生产化与治理 子目录首页，方便历史链接继续可用。

如果你从新的统一目录进入，建议把这里看成：

  • LLM 主线之后的第二层

前面先理解模型、RAG、Embedding、Evals、Token、参数、协议和成本； 这里开始讨论如何把这些能力稳定运行在真实系统里。

一、这一组内容主要解决什么 ​

LLMOps 讨论的不是：

  • 怎么第一次把模型 API 接通

而是这些更接近真实生产的问题：

  • Prompt、模型、工具、检索和审批策略改了以后，怎么知道到底哪一层变差了
  • 为什么离线看起来能跑，线上一放量就开始成本抬升、延迟抖动、质量波动
  • 评测、发布、灰度、回滚、告警和 runbook 应该怎么接成闭环
  • 为什么 LLM / RAG / Agent 系统不能只靠代码版本管理，还要管理配置快照和运行时策略

OpenAI 当前 Production best practices、API deployment checklist、Evaluation best practices、Prompt caching、Background mode、Batch、Flex processing、Priority processing、Conversation state 和 Trace grading 都在说明一件事：

  • 生产化不是给 Demo 套一个 Web 接口，而是把运行、评测、回退、恢复、成本和治理都做成系统能力。

二、最适合先看这一组的几种场景 ​

1. 每次改 Prompt 都像盲改 ​

更适合先看：

2. 线上质量波动，但说不清是模型、检索还是工具的问题 ​

更适合先看：

3. 成本一放量就上涨，延迟也跟着抖 ​

更适合先看：

4. 想把 Agent 或 RAG 系统真正上线 ​

更适合先看：

三、推荐阅读路径 ​

1. 从 Demo 到第一版生产系统 ​

  1. 01-LLMOps与生产化详解
  2. 03-评测门禁、回放与版本基线
  3. [05-可观测性、Tracing与Trace Grading](./05-可观测性、Tracing与Trace Grading)
  4. 04-Evals与评测体系详解
  5. 06-模型选择、成本与延迟
  6. 可观测性与tracing专题
  7. 企业AI交付清单专题

2. 从可上线到可持续迭代 ​

  1. 01-LLMOps与生产化详解
  2. 02-发布、灰度与回滚治理
  3. 03-评测门禁、回放与版本基线
  4. [05-可观测性、Tracing与Trace Grading](./05-可观测性、Tracing与Trace Grading)
  5. 06-缓存、Batch、Flex与后台任务编排
  6. 评测运营与案例
  7. 平台工程
  8. 安全治理

3. 从单轮应用扩展到长工作流系统 ​

  1. 07-LLM参数与采样控制
  2. 08-LLM协议、消息与工具交互
  3. AI Agents 与工作流总目录
  4. 02-发布、灰度与回滚治理
  5. [05-可观测性、Tracing与Trace Grading](./05-可观测性、Tracing与Trace Grading)
  6. 06-缓存、Batch、Flex与后台任务编排

三点五、这一组现在包含什么 ​

  1. 01-LLMOps与生产化详解：负责总论，把 Prompt、模型、检索、工具、评测、发布、成本和事故响应放进同一条生产主线。
  2. 02-发布、灰度与回滚治理：负责解释 release bundle、canary、shadow、分层回滚和值班 runbook。
  3. 03-评测门禁、回放与版本基线：负责解释评测桶、失败样例回流、基线比较、回放证据和发布门禁。
  4. 04-成本、延迟与异步运行策略：负责解释 prompt caching、batch、background、flex、priority、状态分层和任务分级。
  5. [05-可观测性、Tracing与Trace Grading](./05-可观测性、Tracing与Trace Grading)：负责解释 trace 结构、trace grading、版本绑定、事故复盘和可解释发布证据。
  6. 06-缓存、Batch、Flex与后台任务编排：负责解释同步、后台、批处理、priority、flex、conversation state 和任务编排矩阵。

四、和其它专题的关系 ​

一句话理解：

  • LLMOps 是把模型能力、平台工程、评测运营和安全治理拧成一条发布与运行主线。

五、做 LLMOps 最该先建立的几个共识 ​

1. 生产化不是“把原型代码部署出去” ​

只要系统开始接真实流量，问题就不再只发生在模型回答上，而会扩散到缓存、限流、工具调用、异步任务和数据闭环。

2. 评测、trace 和发布应该一起设计 ​

每次改 Prompt、模型、检索或工具时，最好都能关联到：

  • 评测集
  • 发布批次
  • trace 数据

3. 成本治理通常比“降模型单价”更依赖调用结构 ​

很多时候真正有效的优化来自稳定前缀、减少重复调用、把长任务异步化、把可离线工作批量化。

更系统的展开建议继续看：

4. LLMOps 迟早会和 AgentOps、RAGOps 合流 ​

一旦系统接入检索、工具和长工作流，生产治理就会同时覆盖：

  • 模型
  • 知识
  • 工具
  • 审批
  • 会话状态

如果你现在更卡在“怎么发布、怎么过线、怎么回滚”，更建议继续看：

六、企业里最容易低估的四个生产分界线 ​

1. 评测不是发布前最后点一下 ​

评测应该进入日常变更流，而不是上线前临时抽几条样本看一下。

2. 发布对象不是只有代码 ​

真正影响结果的往往还包括：

  • Prompt 和 system 指令
  • 模型路由策略
  • 工具 schema
  • 检索、rerank、过滤配置
  • 审批规则和人工接管策略

3. 实时、后台和批处理不是同一类任务 ​

有些任务适合同步返回，有些任务适合异步运行，有些任务更适合离线批量计算。

4. 运行手册和监控大盘一样重要 ​

很多团队已经有日志、指标和 trace，但事故发生时仍然接不住，本质上是没有把：

  • 先看什么
  • 先关什么
  • 先回滚什么

写成值班手册。

七、当前官方资料最值得补上的三个运行判断 ​

1. 先把同步、后台、批处理、flex、priority 分成不同 lane ​

OpenAI 当前官方资料其实已经把几种运行形态分得很清楚：

  • Standard / synchronous：适合需要即时返回的普通在线请求
  • Background mode：适合长任务，重点是避免客户端超时和连接中断
  • Batch：适合离线批量任务，官方当前说明有 50% lower costs、独立高配额池和 24-hour turnaround time
  • Flex processing：适合低优先级、可等待、允许偶发资源不可用的任务
  • Priority processing：适合高价值、稳定流量、强时延目标的用户面请求

这背后的工程含义很重要：

  • 不同 lane 不只是价格不同
  • 它们对应的是不同的 SLO、失败处理方式和用户预期

更稳妥的做法通常不是“所有调用都走同一条路”，而是先把任务分成：

  • 用户正在等待的
  • 用户可接受稍后回来的
  • 完全离线跑也可以的
  • 关键流量需要更强时延保障的

2. Prompt caching 的收益首先取决于前缀稳定，而不是“打开开关” ​

OpenAI 当前 Prompt caching 文档明确强调：

  • cache hit 依赖 exact prefix matches
  • 静态内容应尽量放在前面
  • 动态内容应尽量放在后面

这意味着很多团队以为自己“用了缓存却没省钱”，问题常常不是平台没生效，而是：

  • system prompt 经常改
  • few-shot 示例顺序经常变
  • 工具定义或 schema 没有稳定前缀
  • 用户态信息被提前塞进请求开头

所以生产里更应该单独盯：

  • cache hit rate
  • cached tokens 占比
  • 哪些模板版本把缓存打碎了

3. 发布对象最好冻结成 release bundle，而不是只记代码版本 ​

OpenAI 当前 Production best practices、Deployment checklist、Evaluation best practices 和 Trace grading 这些资料放在一起看，最值得直接吸收的一条经验是：

  • 真实影响效果的对象远不只代码

更稳妥的 release bundle 通常至少要冻结：

  • Prompt / system instruction 版本
  • 模型与路由策略
  • tool schema / MCP 配置
  • 检索、rerank、filter 配置
  • grader / eval dataset / 基线版本
  • 人工审批与风险路由策略

如果这层不冻结，线上出了问题时你经常只能看到：

  • “是这几天某个东西变了”

却说不清到底是哪一个对象改变了结果。

八、上线前最值得过一遍的检查清单 ​

  • 评测集是否覆盖真实高频任务和高风险失败样例
  • trace 是否能定位到模型、检索、工具和审批环节
  • token、缓存、延迟和成本是否有统一口径
  • 发布、灰度、回滚是否有清晰流程
  • 长任务、异步任务和人工接管是否有状态模型

九、上线前最值得补齐的五项口径 ​

1. 成本口径 ​

要统一：

  • 单请求成本
  • 单任务成本
  • 人工接管后的真实成本

2. 延迟口径 ​

要区分：

  • 模型生成
  • 检索
  • 工具调用
  • 审批等待
  • 端到端耗时

3. 质量口径 ​

要明确到底看：

  • answer quality
  • citation quality
  • tool success
  • approval success
  • task completion rate

4. 版本口径 ​

至少要能说清楚这次流量对应哪一版：

  • Prompt
  • 模型
  • 工具 schema
  • 检索配置
  • 审批规则

5. 故障口径 ​

要先定义什么叫：

  • 质量下降
  • 成本异常
  • 高风险误放行
  • 长任务丢失状态

十、不同系统形态更适合先看什么 ​

1. 文本问答 / 总结 / 抽取系统 ​

更应该先看评测、成本、缓存和输出协议，重点是怎么把高频任务稳定下来。

2. RAG / 知识库系统 ​

更应该先看知识更新、索引版本、引用质量、检索 trace 和失败复盘，而不只是模型表现。

3. Agent / 工作流系统 ​

更应该先看工具权限、审批、人机接管、长任务恢复和状态机回放。

4. 多模态或实时语音系统 ​

更应该先看：

  • session state
  • realtime / background 分层
  • turn detection
  • trace 与成本口径

十一、不同角色更适合怎么读 ​

1. 应用工程师 ​

更适合先看：

  1. 01-LLMOps与生产化详解
  2. 04-Evals与评测体系详解
  3. 06-模型选择、成本与延迟

2. 平台或架构同学 ​

更适合先看：

  1. 平台工程
  2. 01-LLMOps与生产化详解
  3. [05-可观测性、Tracing与Trace Grading](./05-可观测性、Tracing与Trace Grading)

3. 业务负责人或交付负责人 ​

更适合先看：

  1. 06-模型选择、成本与延迟
  2. 06-缓存、Batch、Flex与后台任务编排
  3. 安全治理

十二、重点官方资源 ​

以下入口在 2026-07-08 检查时可访问：