什么是 LLMOps？
LLMOps（大语言模型运维）是对大模型应用的完整行为进行开发、评估、发布、观测和持续改进的工程与治理体系。
快速了解
| 全称 | 大语言模型运维（Large Language Model Operations） |
|---|---|
| 规范文档 | 官方规范 |
工作原理
先定义发布单元，再建设流水线
创建一个不可变 Release ID，使其能够解析到源码与构建、Prompt、模型快照、生成参数、检索语料与索引、工具 Schema 与授权、输出解析器、安全策略、评估器和路由策略。可变 Alias 可以选择发布，但不能充当身份。还要明确模型风险、应用正确性、数据治理、安全和事故指挥的 Owner。[NIST 生成式 AI 风险管理框架](https://doi.org/10.6028/NIST.AI.600-1)把风险管理视为全生命周期活动，因此上线前测试、发布决策与上线后事故需要使用连贯证据，而不是彼此割裂的 Dashboard。
通过分层证据晋级候选版本
先执行确定性检查：Manifest 完整性、Hash、Schema、授权、工具 Allowlist、隐私策略和回滚兼容性。随后在代表性任务、语言、租户与对抗切片上对比获批基线，严重失败应作为硬门禁，不能被平均分掩盖。Shadow 流量验证集成且不向用户暴露输出；受限 Canary 再验证真实 Latency、Cost 与已验收结果。每次决策都要记录数据集、评估器、Runner、阈值、审批人与 Release ID。
观测行为，但不默认采集原始内容
让 Release ID 贯穿 Request、Retrieval、Model、Tool 与 Policy Span，并按该身份衡量健康、任务结果、安全决策和完整成本。优先记录事件类型、Hash、计数、Duration 与脱敏 Attribute；只有在目的、权限与删除规则明确时才采样或保留原始 Prompt 和输出。OpenTelemetry 的[生成式 AI 语义约定仓库](https://github.com/open-telemetry/semantic-conventions-genai)说明这些 Attribute 仍在演进，因此应固定 Convention Revision 并维护转换层，不能把字段名视为永久契约。
回滚完整发布包并对账副作用
只回滚模型可能让 Prompt、索引、解析器或工具策略继续以不兼容版本运行。应保留经过演练的 Known-good Bundle，定义流量排空与状态兼容策略，并证明外部可见动作具有幂等、可逆或可对账能力。事故期间先冻结高风险自动化，保存带 Release ID 的证据，恢复服务，并清点已发出的消息、支付、工单或其他动作。最后把已确认故障沉淀为回归用例，并更新门禁、Runbook 与责任记录。
主要特点
- 以端到端应用行为而非单个 Prompt 或模型作为发布单元
- 统一版本化代码、Prompt、模型、检索、工具、策略、输出契约、评估器和路由
- 区分确定性契约、离线评估、线上实验和生产监控的证据边界
- 让不可变候选版本经过风险专项审批、Shadow 流量和受控 Canary 晋级
- 把 Trace、被验收用户结果、策略决策和成本关联到准确发布身份
- 将完整发布包回滚与副作用对账、事故驱动评估集更新结合
常见用途
- 复现某次回答使用的模型、Prompt、索引、工具策略和解析器
- 阻断违反输出、授权、安全、延迟或预算契约的候选版本
- 在代表性任务和风险切片上比较候选发布与获批基线
- 在不默认记录完整 Prompt 的情况下诊断生产回归
- 事故后恢复兼容的已知良好发布，并对外部动作进行对账
示例
Loading code...常见问题
LLMOps 与 MLOps 有什么区别？
MLOps 运营数据、训练流水线、模型制品、Serving 和漂移控制。LLMOps 继承这些实践，并把 Prompt、检索快照、工具、授权、输出契约、安全策略、评估器和路由纳入需要发布和运营的行为范围。
LLMOps 只是 Prompt 管理吗？
不是。Prompt Registry 只管理一种制品，生产行为还取决于代码、模型修订、生成参数、检索、工具、授权、解析器、策略、评估器和路由。LLMOps 治理的是这些制品的兼容组合。
LLMOps 需要版本化哪些内容？
应版本化每项影响行为的依赖：源码与构建、Prompt、模型、参数、语料与索引、工具 Schema 与策略、输出 Schema 与解析器、安全策略、路由、评估数据集、评估器和 Runner。
LLMOps 团队应监控什么？
应监控服务健康、发布身份、模型与检索行为、工具和策略结果、被验收用户结果与完整成本。原始内容只有在明确的隐私、访问、留存和采样控制下才应采集。
LLMOps 必须使用专用平台吗？
不必。团队可以从经过 Review 的发布清单、CI Job、评估报告、Dashboard 和 Runbook 开始。只有平台能消除已经证实的协作或规模瓶颈，并保留可迁移身份和可导出证据时，才值得引入。