核心摘要

企业级 LLMOps 是运营生成式 AI 应用完整行为的工程体系，而不是某类平台或 Prompt 管理系统。一次生产发布必须把代码、Prompt、模型修订、检索数据、工具、授权、输出契约、安全策略、评估器和路由绑定为同一可审计身份，再通过确定性测试、风险专项离线评估、受控发布、隐私友好观测和完整发布包回滚推进生命周期。

目录

核心要点

  • 发布完整行为，而非孤立文件。 相同 Prompt 在模型、索引、工具、解析器、策略或路由变化后可能产生不同结果。
  • 确定性控制必须留在确定性系统中。 身份、授权、Schema、预算和高风险动作审批不能依赖模型是否听从指令。
  • 不同证据层不能混用。 单元契约、离线评估、线上实验和生产监控分别回答不同问题。
  • 带着隐私预算追踪决策路径。 运维遥测需要发布身份和组件结果，但采集完整内容应是例外。
  • 回滚是兼容性操作。 必须恢复已知良好的完整发布包并处理外部副作用，只切换 Prompt 指针并不充分。

什么是 LLMOps？

LLMOps 是在大语言模型应用全生命周期中进行开发、评估、发布、观测和持续改进的一组工程与治理实践。它扩展 DevOps 和 MLOps，因为生成式系统的行为不仅由源代码或模型权重决定。

可以把它概括为：

LLMOps 在明确的质量、安全、可靠性、隐私和成本目标下，运营一个经过版本化的应用行为。

这一定义比 LLMOps = Prompt + RAG + Evaluation + Guardrails 更完整。后四项固然重要，但工具权限、供应商别名、解析器、路由规则、记忆策略或索引重建同样可能改变生产行为。

LLMOps 与相邻工程体系的边界

工程体系 主要运营对象 独特职责
DevOps / SRE 软件服务与基础设施 构建、交付、可靠性、容量和事故处理
MLOps 数据、特征、训练流水线和模型制品 可复现训练、验证、部署与漂移治理
LLMOps 生成式应用端到端行为 版本化全部行为依赖，评估概率路径，治理发布与反馈
Prompt CI/CD Prompt 相关行为变更 为完整 Prompt 行为发布包建立回归门禁与交付
RAGOps 检索语料、索引、排序和 Grounding 数据血缘、检索质量、权限过滤与索引迁移
AgentOps Agent 轨迹、工具、记忆与审批 步骤级控制、授权、副作用和轨迹评估
LLM Gateway 运维 共享模型访问平面 身份、配额、协议适配、韧性、路由和计量

这些边界会重叠。LLMOps 应复用成熟的软件交付、安全、数据和可靠性控制，而不是用 AI 专属平台重新发明一套平行体系。

Google 的 MLOps 架构指南 强调，真实 ML 系统需要围绕模型建设配置、自动化、验证、元数据、Serving 和监控。LLMOps 是在这一基础上加入生成式应用制品和评估路径。

定义完整行为发布包

行为发布包是能够被完整评估、批准、部署、归因和恢复的最小单元。单个 Git Commit 或 Prompt 版本都不足以识别它。

盘点所有影响行为的制品

至少记录以下内容：

制品 为什么会改变行为 稳定身份
应用与工作流代码 控制分支、重试、状态和副作用 源码 Commit 与构建摘要
Prompt 模板与示例 改变指令和上下文构造 内容摘要
模型与供应商 改变能力、拒答、延迟和 Tokenization 不可变修订或供应商快照
生成配置 改变随机性、长度和工具选择 规范化参数摘要
检索语料与索引 改变可用证据和排序 语料修订、Embedding 修订、索引构建号
工具与授权 改变可执行动作和受影响资源 Schema 摘要与策略摘要
输出契约与解析器 改变下游兼容性 Schema 与解析器修订
安全与合规策略 改变允许、拒绝、复核和留存行为 策略修订
路由与降级策略 改变实际执行路径 签名配置修订
评估制品 改变批准版本所依据的证据 数据集、评估器、Rubric 和 Runner 修订

latest、production 或浮动模型名称可以作为便捷别名，但审计和回滚记录必须把它们解析为不可变身份。

使用发布清单

供应商无关的发布清单让依赖与证据可以被 Review：

yaml 
release:
  id: support-assistant/184
  sourceCommit: 3cb44d...
  buildDigest: sha256:4c8e...

behavior:
  promptDigest: sha256:92af...
  modelRevision: provider/model/snapshot-17
  generationConfigDigest: sha256:ed21...
  retrieval:
    corpusRevision: support-docs/63
    embeddingRevision: embedder/snapshot-8
    indexBuild: support-index/447
  tools:
    schemaDigest: sha256:18b7...
    authorizationPolicyDigest: sha256:f11a...
  output:
    schemaDigest: sha256:05ec...
    parserRevision: parser/21
  safetyPolicyRevision: safety/34
  routingPolicyDigest: sha256:70bd...

evidence:
  datasetRevision: support-eval/52
  evaluatorRevision: evaluator/19
  runnerDigest: sha256:bc09...
  reportDigest: sha256:70de...

rollback:
  knownGoodRelease: support-assistant/179
  reconciliationRunbook: runbook://support-assistant/reconcile

发布清单不是制品仓库，而是一张经过签名的地图：它把单一发布身份指向不可变制品、评估证据、责任人和恢复说明。

建立 LLMOps 生命周期

可靠的 LLMOps 生命周期是一个在每个转换点明确责任的受控反馈循环。它从用例契约开始，而不是从采购技术开始。

flowchart LR A["定义用例、责任人与风险"] --> B["开发版本化行为"] B --> C["执行契约与离线评估"] C --> D{"风险责任人批准？"} D -- "否" --> B D -- "是" --> E["影子或灰度发布"] E --> F{"线上护栏通过？"} F -- "否" --> G["回滚并对账副作用"] G --> H["事故复盘与评估集整理"] H --> B F -- "是" --> I["推广不可变发布"] I --> J["观测结果与漂移"] J --> H

1. 定义用例契约

写清目标用户、决策范围、数据类别、禁止结果、人工升级、延迟目标、预算边界和风险责任人。客服回复草稿与可自主退款的工具即使都调用 LLM，也不应共用同一批准策略。

2. 保持开发与生产对称

开发和评估应解析与生产相同类型的制品并使用同一策略引擎。测试凭证和隔离数据是合理差异，但如果评估时悄悄替换了解析器、检索过滤器或工具契约，证据就不能代表生产系统。

3. 把证据绑定到候选版本

评估报告应包含候选与基线清单、数据集和评估器修订、样本切片、重复运行策略、失败项、不确定性、批准人和证据失效条件。只有一个被复制到 Dashboard 的分数，不能构成发布证据。

4. 晋级、观测与学习

生产 Trace 和已复核失败只有经过隐私审查、去重、标注和训练测试泄漏控制，才能成为评估候选样本。用户点赞或点踩是有价值的上下文，但不是无需解释的质量标签。

NIST 生成式 AI 风险管理框架 把治理、部署前测试、生命周期风险和事故披露放在同一风险模型中。其行动建议是自愿性框架，需要按应用场景调整，并未规定一个通用分数或统一平台。

用四层证据评估发布

LLMOps 评估应组合四层证据，不能把正确性、安全性和业务价值压缩成一个 Judge 分数。

第一层：确定性契约

优先运行低成本、可重复的检查：

  • Prompt 变量与配置能正确解析。
  • 输出满足 JSON Schema、类型、枚举和业务不变量。
  • 工具调用只使用允许的操作，并通过服务端授权。
  • 检索在排序前应用租户与文档权限过滤。
  • Token、延迟、重试和成本预算均有上限。
  • Secret、禁用数据和危险 Markup 不穿越接口。
  • 破坏性动作满足审批与幂等契约。

这些控制回答系统在结构上是否有权继续执行。概率模型不能给自己的授权打分。

第二层：任务与风险评估

在代表性生产切片上比较候选版本与已批准基线：

  • 常见、边缘、对抗和近期失败案例；
  • 语言、租户、产品和用户群体；
  • 分开评估检索 Recall、排序与答案忠实度；
  • 工具选择、参数精度、轨迹和副作用；
  • 延迟、Token 用量与被验收结果成本；
  • 隐私、安全、合规与安全性场景。

当模型随机性会影响决策时执行重复运行。报告配对差异、切片失败和不确定性，而不是只给平均分。

第三层：经过校准的人工与 Judge 证据

LLM-as-a-Judge 可以扩展比较、分类和基于 Rubric 的 Review，但它只是评估器输出，不是真值。应以目标领域的盲测人工标签校准每个 Judge 和 Rubric，并追踪分歧、位置偏差、冗长偏差、评估器漂移，以及必须交由人工裁决的切片。

OpenAI 的评估最佳实践建议使用反映真实生产分布的任务专项数据集、持续评估，并以人工反馈校准自动评分。文档中的示例阈值只用于解释具体任务，不能直接作为通用发布门槛。

第四层：线上证据

离线门禁通过后，选择风险最低且能回答剩余问题的线上方法：

方法 用户影响 最适合验证
Replay 无实时用户影响 在受控依赖下复现历史流量
Shadow 候选版本接收复制流量但不能执行动作 集成、延迟、成本和策略决策
Canary 少量真实流量并可回滚 发现仅在生产出现的回归
A/B 实验 对合格流量随机分组 估计产品指标的因果影响

预先声明主要指标、护栏、资格规则、分组单元、停止规则和回滚触发条件。解释实验结果前，先检查样本比例异常和日志完整性。

通过受控环境晋级版本

环境晋级必须让同一不可变发布身份通过越来越接近生产的控制。若每个环境重新构建或解析浮动依赖，证据链就会断裂。

flowchart LR A["Pull Request"] --> B["确定性 CI"] B --> C["隔离离线评估"] C --> D["安全与风险评审"] D --> E["预发布 Replay"] E --> F["生产 Shadow"] F --> G["受控 Canary"] G --> H["扩大流量"] H --> I["持续监控"]

按后果分离职责

至少定义以下责任：

  • 应用行为和产品结果；
  • 数据与检索血缘；
  • 安全、隐私和安全策略；
  • 评估数据集与评估器；
  • 基础设施可靠性与成本；
  • 发布审批与事故指挥。

小团队可以由同一人承担多个角色，但仍需记录这次决策履行了哪项责任、采用了什么证据。

把回滚当作需要测试的操作

晋级前验证已知良好版本仍然可用、依赖仍可解析、数据契约向后兼容，且值班人员具备流量切换权限。对于有状态 Agent，回滚还需要处理排队任务、外部写入、重复动作，以及故障版本已经创建的会话。

设计可观测性契约

LLMOps 可观测性必须把用户结果连接到准确的发布版本和执行路径，同时避免遥测系统变成不受治理的敏感会话副本。

追踪端到端执行路径

有用的 Trace 应连接：

text 
请求
→ 发布清单
→ 路由与供应商
→ Prompt/模板修订
→ 检索查询、过滤器和文档标识
→ 模型调用与用量
→ 工具决策、授权和结果
→ 策略决策
→ 解析器与输出验证
→ 用户可见结果
→ 被验收结果或人工升级

OpenTelemetry 的 GenAI Semantic Conventions 正在为模型操作、检索、记忆、工具、Token 和延迟定义约定。接入时必须固定使用的约定版本：当前 GenAI 文档仍标为 Development，字段名称和要求可能继续变化。

使用三类信号

信号类型 示例 回答的运维问题
服务健康 错误、饱和度、排队时间、TTFT、Token 间延迟 应用是否可用并满足 SLO？
行为与策略 Schema 失败、检索缺失、工具拒绝、危险动作尝试、人工升级 发布版本是否在契约内行动？
产品与成本 被验收的解决结果、任务完成、放弃、Token、供应商费用、人工复核量 结果是否有用且经济可持续？

除非已经定义可观测评估器、采样规则、证据来源和分母，否则不要创建名为 hallucination_rate 的指标。同样，模型自报置信度也不是经过校准的正确概率。

默认不采集完整内容

完整 Prompt、回答、检索段落和工具参数可能包含个人数据、Secret、受限文档或攻击者输入。默认优先记录标识、摘要、有限标签和派生指标。只有调试或评估确有必要时，才在脱敏、访问控制、加密、限期留存、采样、租户隔离和访问审计下采集内容。

运营安全、隐私与事故响应

LLMOps 安全是贯穿生命周期的属性：发布门禁、运行时强制、遥测和事故恢复必须覆盖模型周围的完整应用。

把控制放在模型外部

应用必须强制执行：

  • 身份与对象级授权；
  • 最小权限工具和短期凭证；
  • 出网地址与目标 Allowlist；
  • 输出验证与安全渲染；
  • 高影响动作人工审批；
  • 请求、Token、并发和费用限制；
  • 检索、记忆、缓存和 Trace 的租户隔离；
  • 模型、数据、依赖和策略的来源与签名验证。

OWASP GenAI 指南把 Prompt Injection、敏感信息泄露、供应链风险、不当输出处理、过度代理权和无界资源消耗视为应用风险。System Prompt 不是安全边界，模型拒绝执行也不等于授权控制。

NIST SP 800-218A 把安全软件开发实践扩展到 AI 模型生产者、AI 系统生产者和采购者。因此，LLMOps 应把 AI 专项证据接入现有安全开发生命周期，而不是创建一条平行发布流程。

准备事故契约

事故等级应按影响定义，而不是按模型是否返回 HTTP 错误定义。未授权动作、跨租户检索、策略绕过、系统性错误信息、成本失控、供应商行为变化或无法复现的输出都可能构成事故。

Runbook 应回答：

  1. 涉及哪个发布版本、租户、供应商、模型、索引、工具和策略？
  2. 能否停止流量、进入安全降级模式或恢复已知良好发布包？
  3. 哪些副作用需要取消、补偿或人工对账？
  4. 如何保全证据而不扩大隐私事故？
  5. 需要通知哪些用户、责任人、供应商或主管机构？
  6. 哪条回归用例和控制变更可以防止问题再次发生？

回滚并不总能解决问题。若故障版本已发送消息、修改记录或泄露数据，恢复代码不会撤销这些结果。

把成本归因到被验收的结果

LLMOps 成本控制应把完整运营成本归因到具体发布版本和有用结果，而不是只展示供应商 Token 账单。

按租户、功能、发布、路由、模型和环境记录成本：

text 
完整运营成本 =
  推理与 Embedding
  + 检索与存储
  + Gateway 与可观测系统
  + 评估与人工复核
  + 安全与合规控制
  + 闲置与预留容量
  + 事故与副作用对账

单个被验收结果成本 =
  完整运营成本 / 被验收结果数

根据用例定义「被验收结果」。它可能要求任务成功、Schema 有效、证据充分、动作已授权、安全检查通过且延迟达标。这样可以避免一个便宜但低质量的路由仅因生成大量 Token 或回答而被误判为高效。

实时估算和供应商账单用途不同：前者用于预算和准入，后者用于最终对账。未知价格或用量缺失必须进入异常台账，不能静默按零成本处理。

按成熟度建设 LLMOps

LLMOps 成熟度取决于控制闭环强度，而不是部署了多少平台。小型系统也能用简单、可 Review 的制品实现高质量运营。

阶段 最小能力 成熟证据
1. 可复现 版本化代码、Prompt、模型、数据、工具、策略和输出契约 每个回答能追溯到不可变发布
2. 可评估 确定性契约加代表性任务与风险测试 候选与基线报告可复现
3. 受控交付 审批、环境晋级、Shadow/Canary 和 Kill Switch 故障发布可被限制并恢复
4. 可观测运营 端到端 Trace、SLO、行为信号与隐私控制 无需开放全部内容日志即可诊断发布
5. 受控学习 反馈整理、事故用例、评估器治理与成本归因 生产证据改善系统且不污染评估

第一项投入通常应是制品盘点和发布契约，而不是集中式 Prompt Registry。当 Registry、评估服务或可观测平台能消除已证实的协作瓶颈，并继续提供可迁移制品身份和可导出证据时，再引入平台。

常见失败模式

只版本化 Prompt

失败方式： 模型别名、索引或工具策略已经改变，Prompt 版本却保持不变。

修正： 在发布清单中解析全部行为依赖，并把该身份写入 Trace 和评估报告。

把单个 Judge 分数当成质量

失败方式： 一个 1–10 平均分掩盖授权、安全、语言或边缘案例回归。

修正： 先运行确定性门禁，再使用任务专项评估器、切片、重复运行、不确定性和经过校准的人工裁决。

为了可观测而记录全部内容

失败方式： Trace 系统成为客户数据和 Secret 的第二个无治理存储。

修正： 默认记录元数据；完整内容采集必须限定范围、最小化、访问受控并限期保留。

在不兼容模型之间自动降级

失败方式： 降级路由缺少必需工具、Schema、上下文长度、地域边界或安全能力。

修正： 按显式能力契约验证路由，并在生产前测试降级行为。

回滚后不处理副作用

失败方式： 已恢复旧版本，但故障版本已经执行的动作仍然存在。

修正： 将回滚与幂等、动作台账、取消或补偿，以及不可逆结果的人工复核结合。

常见问题

LLMOps 与 MLOps 有什么区别？

MLOps 运营数据、训练、模型制品、Serving 和漂移控制。LLMOps 继承这些实践，并加入生成式应用的行为依赖：Prompt、检索快照、工具、授权、输出契约、策略、评估器和路由。二者区别在于运营范围，不是用 LLMOps 替代 MLOps。

企业实施 LLMOps 的第一步是什么？

先定义用例契约和完整发布身份：明确责任人、用户、禁止结果、数据类别、目标、审批策略和回滚目标，再盘点每项可能改变行为的依赖。若边界尚未定义就先购买 Prompt Registry，往往只会集中管理问题的一小部分。

LLM-as-a-Judge 能自动批准生产发布吗？

不能单独批准。只有 Rubric 明确且以代表性人工标签校准后，Judge 才适合自动化比较或分类。安全不变量、授权、Schema、预算和高影响决策仍需确定性强制或可问责的人工审批。

LLMOps 应如何监控幻觉？

不要从通用「幻觉率」开始。先定义可观测失败，例如回答中的主张缺少引用证据、与权威数据源冲突、缺少强制引用或任务结果错误。每个指标都要说明评估器、样本、分母、不确定性和人工抽查流程。

每个团队都需要企业级 LLMOps 平台吗？

不需要。每个生产系统都需要责任边界、发布身份、评估、交付控制、可观测性和恢复能力，但早期可以用经过 Review 的清单、CI Job、Dashboard 和 Runbook 实现。只有规模或协作产生可测量瓶颈时，才需要引入平台。

总结

企业级 LLMOps 把不断变化的模型、Prompt、数据、工具和策略组织为可审计的生产体系。其核心单元是带可复现证据和已测试恢复路径的不可变行为发布包。应组合确定性契约、离线评估、受控线上交付、隐私友好遥测与事故对账，而不是依赖单个 Registry 或 Judge 分数。

相关资源