LLMOps 落地指南：从评估、追踪到发布与故障恢复

对一个 3 人团队来说，LLMOps 应先做好四件事：发布版本可追溯、评估能拦住不合格版本、请求链路可查、出了问题能回滚。再围绕这套流程补齐路由、费用控制和安全护栏；等到具体故障或协作问题出现，再考虑添置基础设施。

真正需要运维的是面向客户的功能。客服助手即使回答流畅，也可能检索到另一位客户的记录、调用错误的工具，或耗尽重试额度。模型接口可用，并不代表整个功能正常。

下文涉及的产品能力和依赖管理建议，已于 2026 年 10 月 23 日依据当时可查阅的官方一手文档核验。文中的团队规模和评估算例均为规划场景，并非厂商限制，也不是生产环境的实测结果。

LLMOps 是什么？

LLMOps 要让大语言模型应用的每次变更都可观测、可测试、可恢复。它的全称是 large language model operations，即大语言模型运维，涵盖提示词、模型版本、评估、链路追踪、成本、安全护栏、网关，以及出问题时由谁负责。

可以把它想成一座正在通车的桥。桥体固然重要，改造前的检查、通行限制、运行监测，以及关闭危险路段的手段也同样重要。换一座更坚固的桥，不能替代这些运营职责；换一个更强的模型，也一样。

以客服助手为例，完整流程是：修改退款指令，用有代表性的对话评估候选版本，逐步发布，检查实际效果，再把失败案例变成回归测试。回归测试要确认的是：新的改动没有让以前解决过的问题再次出现。

这套流程的价值，在于能明确回答客户投诉背后的问题：这次请求由哪个版本处理，中间发生了什么，以及怎样修改才安全。提示词工程让指令更好用；LLMOps 则让这项改进在交付给用户后，仍然能够持续维护。

LLMOps 和 MLOps 有什么区别？

LLMOps 在机器学习运维（MLOps）的基础上，进一步管理 LLM 应用的行为。两者都需要版本管理、评估、部署控制和监控。两者都不天然具有确定性，也都离不开常规的软件工程实践。

本文讨论的生产功能，通常不需要团队亲自训练模型。团队选择现成模型，管理提示词、上下文、模型更新、工具访问及周边软件。以训练为中心的 MLOps 还要管理训练数据、实验、模型产物和重新训练。如果需要微调模型，或自行托管推理基础设施，这些职责也会纳入 LLMOps 的工作范围。

先看眼前的失败原因。缺少企业内部知识，可能需要改进检索，也就是向模型提供相关文档的过程。反复出现的行为问题，可能需要调整提示词，最终也可能需要微调。无论是哪一种，都不必先重建一套训练平台，才能把现有功能管好。

为整次发布建立版本记录

只有知道还有哪些输入影响了模型行为，提示词版本才有追溯价值。为每次发布保存一份发布清单，列出一同上线的配置：

• 应用代码版本、提示词版本，以及选定的提供商和模型标识。
• 生成参数；如果提供商会返回模型标识，也记录下来。
• 检索配置，以及文档或索引版本。
• 工具定义、输出结构和授权策略。
• 依赖锁文件，以及已部署镜像的标识。
• 用于批准这次变更的评估数据集、评分标准和评判模型配置。

将清单与部署记录一起保存，并在生产链路记录中附上清单标识。不要把密钥写进去。提供商支持时，应指定明确的模型版本，并根据其停用通知安排迁移。

假设退款助手的提示词完全没变，文档更新仍可能带来新的政策，工具参数结构的变更也可能改变某项操作接受的输入。只回滚提示词，这两处变化都会保留下来。因此，回滚目标应对应一套彼此兼容的应用配置，其中也包括相关的检索版本和策略版本。

Langfuse 是一个应用链路追踪与评估平台，其文档介绍了提示词集中存储、版本管理、部署标签，以及提示词与链路记录的关联。这些机制有助于将提示词版本与实际效果对应起来。但部署标签仍然是可变的指针：应记录每次请求实际使用的版本，并让指针变更遵循发布策略。参见 Langfuse 提示词管理文档。

如果所有改动都由工程师负责，先把提示词放在现有代码仓库中即可。 当非工程人员需要在受控流程下编辑提示词，或多个服务需要共用同一已批准版本时，再引入提示词注册表。增加一个组件，应当有明确的协作问题作为理由。

让大模型评估成为发布门槛

评估结果能够阻止发布，评估才真正成为运行控制的一部分。仪表盘上的分数，如果没人必须据此采取行动，就只是一个测量值。

从有代表性的请求、已知失败和滥用尝试中构建测试用例，并删除或替换敏感数据。每个用例都需要预期结果或明确标准，例如：找到正确政策、引用所提供的证据、返回有效的操作提案，以及拒绝访问调用者账户之外的记录。另留一组保留测试集，避免提示词作者反复针对它进行优化。

从一套小而明确的准入标准开始

假设先准备 50 个用例：30 个常规请求、10 个边界情况和 10 次滥用尝试。这只是用于说明如何起步的练习，并不意味着 50 个样例就足以覆盖你的风险水平。

对于必填字段、允许的工具参数和权限边界，使用确定性检查，也就是能明确判定通过或失败的规则。对于回答是否忠于证据等质量问题，结合人工审核和语言模型评判。比较候选版本时，固定评判模型的评分标准与配置，并在关键样例上对照模型判断和人工判断。LLM-as-a-judge 指南介绍了这一校准过程。

候选版本的通过率即使从 46/50 提升到 49/50，也就是从 92% 提升到 98%，仍可能不能上线：只要剩下的失败会泄露私密记录，就不能接受。总体质量指标不能掩盖关键请求类别的问题。

针对这个例子，可以设置以下发布门槛：

1. 权限与操作测试中没有严重失败。
2. 每类重要请求的质量都达到已批准的基线，并审核结果不确定或存在争议的用例。
3. 延迟和资源消耗均在该功能约定的运行限制内。
4. 保留上一个兼容版本，并明确由谁决定回滚。

如果输出的波动可能影响结论，就重复运行重要用例或临界用例。通过所选测试，只能为这次发布提供依据，并不能证明生产环境不会出问题。

评估与可观测性平台 LangSmith 的文档区分了两类评估：在整理好的数据集上开展离线评估，以及对真实交互开展在线评估。评估方式包括代码检查、人工审核、LLM 评判和成对比较。两者在运维中的职责不同：离线检查决定候选版本能否发布；在线检查帮助发现数据集遗漏的问题。参见 LangSmith 评估文档。

通过发布门槛后，先让候选版本承接少量流量，并持续观察评估时关注的那些请求类别。新的模型路由或备用方案，也应视为行为变更；让生产流量依赖它之前，同样需要验证依据。

大模型可观测性：沿请求链路追到实际结果

一条链路记录（trace）应能解释，请求是怎样一步步得到答案的。链路中的一个操作称为 span，例如检索文档、调用模型或执行工具。

记录发布标识、允许保留的请求元数据、检索引用、模型调用、工具操作提案及其结果、校验决策、重试、耗时和 token 用量。也要记录选择了哪条路由，以及为什么选择它。将链路与产品结果关联起来：客户是否接受了答案，是否需要纠正，或者是否需要转人工？

例如，一次缓慢的退款答复，可能只有很少的时间花在模型上，大部分时间都在反复重试不可用的订单服务。模型延迟图表无法解释这一点；包含服务调用、重试和最终结果的完整链路可以。

Langfuse 的链路追踪文档涵盖提示词、响应、token 用量、延迟，以及中间的工具调用或检索步骤。其数据集文档也支持从生产链路记录构建用例。利用这条连接，让每次排查过的失败都能改进下一次发布的评估门槛。参见链路追踪和数据集文档。

只记录有权保留的内容。遥测数据离开应用前，先对凭据脱敏；限制链路记录的访问权限，并明确设置保留期限。调试记录可能包含与产品本身相同的客户信息。不适合保存完整内容时，可以保留引用、结构化决策，以及经批准的脱敏样本。

先明确响应动作，再设置告警：操作失败增多、重试过量、资源消耗异常或答案接受率下降时，由谁处理？没有负责人的信号，无助于改善故障处置。需要进一步选型时，可参考按团队规模划分的可观测性工具指南和 LangSmith 与 Langfuse 对比。

管住路由、重试和费用

优化模型选择之前，先限制一次请求最多能触发多少工作。为输出长度、总耗时、重试次数、并行任务和智能体步骤设置上限。将用量归属到具体功能和租户；这里的租户，是指共用应用的某个客户或组织。

各组件的职责不同。网关集中管理模型提供商的访问；路由器选择符合条件的模型或部署实例；缓存在适合复用时返回之前的结果。这些组件都不会自动替应用制定质量标准。

LiteLLM 是模型网关与代理，其文档涵盖统一接口、身份认证、费用追踪、预算和负载均衡；路由文档则介绍重试、故障切换和超时。使用这些能力时，应将规则写成明确的策略：接口不可用可以成为切换备用路由的理由，但备用路由的行为和数据处理要求必须已获批准。参见网关文档和路由文档。

使用并发请求和实际用到的接口测试限制。分清告警与阻断控制，检查执行中的任务、重试和备用调用如何影响总量。即使网关已经追踪费用，应用层仍应保留单次请求的限制。

路由可以先从一条范围很小的规则做起：只把分类明确、风险较低的一类请求交给较小的模型，而且前提是它已通过相关评估。难以判断的任务继续使用已批准的更强模型路由。模型路由器指南介绍了如何测试这类选择策略。

语义缓存按含义而非完全相同的文本复用结果，只有语义等价的问题可以安全共用答案时，才应引入。相比账户余额，公开帮助中心的说明更适合作为起点。按照权限、相关版本和时效性限定复用范围；这些前提变化时，及时使缓存失效。不要根据缓存答案再次执行退款之类的操作。添加语义缓存前，先理清语义缓存的适用边界。

在操作执行前设好安全护栏

即使模型十分肯定地提出某项操作，也必须由应用判断调用者是否有权执行。安全护栏是围绕输入、输出和操作设置的检查与约束，内容分类器只是其中一部分。

对于退款助手，应在执行前，根据已认证客户的权限校验操作提案及其参数。只给工具必需的权限。对于后果需要审慎处理的操作，设置相应的审核；输出进入其他系统之前，也要再次校验。将检索到的文档和模型输出都视为不可信内容。这些原则来自 OWASP 的提示词注入防护指南。

检查失败时怎么办，也要事先定义。必需的授权检查不可用时，操作就不应继续；可选的质量评分稍有延迟，则未必需要阻止一份无害草稿的生成。明确写出哪些检查必须阻断执行，哪些情况可以降级为人工处理。

攻击请求和正常请求要一起测试，避免过于宽泛的过滤规则悄悄让产品失去可用性。AI 安全护栏指南将这些检查对应到小团队可以优先落实的系统边界。

把故障处置纳入整个生命周期

选择恢复动作前，先判断发生的是行为退化、服务故障，还是安全入侵。三者需要不同的处理方式。

出现行为退化时，停止放量，保留有代表性的链路记录，回到上一个兼容版本，并将失败加入评估集。提供商服务中断时，使用经过评估的备用方案，或明确返回暂时不可用的响应。怀疑遭到入侵时，隔离受影响的执行环境，并让安全负责人介入；修改提示词无法让被入侵的主机重新变得可信。

LiteLLM 安全事件：以当时的报告为例

2026 年 10 月 21 日，LiteLLM 报告称，1.107.0 版本包含窃取凭据的恶意软件和远程代码执行工具。受影响的容器标签包括 v1.107.0、latest、main-latest 和 main-stable，其私有企业镜像仓库未受影响。官方源码标签中没有恶意文件；被分发的构建产物来自攻击者控制的仓库。参见 LiteLLM 事件报告。

报告提醒受影响用户，不要先运行 pip install，因为 Python 启动钩子可能再次执行恶意代码。报告更倾向于重建环境，并轮换被入侵主机能够访问的凭据。本文核验时，调查仍标注为进行中；若自己的安装环境受影响，应以报告中最新的影响范围和修复说明为准。

这件事带来的运维教训并不限于网关：需要记录和批准的是实际部署的构建产物，不能只看审核过的源码版本。

固定依赖版本，也要持续维护

固定已批准的依赖版本，并保留其哈希值；容器镜像则按摘要固定，摘要就是镜像内容的标识。启用哈希校验的安装方式，需要固定依赖版本并提供哈希；按摘要引用镜像，可以避免在容器标签变化时悄悄跟随新内容。参见 Python 包安装指南和容器镜像固定指南。

这些控制能确认产物身份，不能证明它无害。把恶意产物固定下来，保留的依然是恶意产物。应审查来源信息和安全公告，在隔离环境中测试更新，并在各部署阶段沿用同一份已批准产物。明确由谁更新固定版本，避免为了可复现而无限期推迟安全维护。

处置手册要短到能在压力下直接使用，写清负责人、停用手段、受影响产物清单、最近一次已批准版本、凭据范围、沟通渠道，以及恢复服务的条件。用无害故障演练整条流程。

LLMOps 工具怎么选：3 人团队的最小配置

沿用现有部署流程，再选一个可以集中查看链路记录和评估结果的地方。生命周期的每个环节都配一款独立产品，往往还没带来更好的控制，就先增加了集成工作。

这是五项职责，不是要招聘五个人。人员可以兼任，但每项职责仍需有明确归属。

如果希望在同一系统中管理链路、提示词和数据集，Langfuse 是一个较为精简的选择，也支持自托管。 其文档列出的能力能够支撑这种整合。但什么样的答案可以接受、什么情况下必须停止发布，仍需要团队自己决定。参见 Langfuse 的能力范围。

如果工作流程需要离线实验、在线评估和生产链路审查，可以考虑 LangSmith。 它的可观测性文档还介绍了仪表盘、告警和反馈。实际使用时，它同样绕不开测量本身的局限：即使应用的观测点很齐全，数据集仍可能缺乏代表性。先选定一个系统，让其中发现的失败能够推动具体行动，再考虑重复建设遥测系统。参见 LangSmith 可观测性文档。

当共享模型提供商访问和统一策略的需求足以支撑网关运维成本时，再引入 LiteLLM。 只使用一个提供商的单个应用，可以先在自身后端实现控制。一旦多个服务需要统一凭据、预算或已批准路由，集中管理这些策略就更有理由。也要将网关的数据库、凭据和更新纳入运维工作。

团队扩大到 30 人后，重点会怎样变化？

到了 30 人规模，主要问题会变成不同负责人之间如何协调变更。再多仪表盘，也无法决定谁能将提示词版本上线、谁能批准备用路由、谁能查看客户的链路记录。

产品小组继续负责自己的数据集、验收标准和实际效果。由平台负责人管理共享网关配置、部署产物标识、链路访问和数据保留。明确谁批准模型与策略变更，谁接收每一类告警，以及谁有权执行停用操作。

统一发布元数据和链路字段，让故障排查能够贯穿多个服务。隔离不同环境和客户的访问范围。为存在争议的评判建立审核队列。定期检查模型停用通知、依赖安全公告和数据集漂移，也就是产品实际收到的请求发生了哪些变化。

什么时候值得引入 LLMOps 平台？

如果反复发生的协作问题，其成本已经超过平台运维成本，就值得采用共享平台。这类问题包括：提示词发布版本不兼容、评估基础设施重复建设、访问策略不一致，以及故障跨越多个服务却无人负责。

团队规模只是规划场景，并非技术门槛。处理高影响操作的小团队，可能从一开始就需要严格控制；人数更多的团队，如果只有一个边界明确的内部功能，仍可能只需要精简的工具组合。控制力度应与故障影响范围和职责划分问题相匹配。

哪些说法被夸大了？

训练模型不是入场券。 只要使用托管模型，就已经有一个需要评估和运维的系统。先建立发布闭环，再判断微调能否解决已经证实的问题。

评判模型给出高分，不等于质量获得全面保证。 分数只回答了你所选样例在所给评分标准下的表现。错误决策会带来明确后果的地方，仍应保留人工审核和确定性检查。

自动路由不代表所有备用模型都可以互换。 路由变化可能改变输出行为、工具使用方式和数据去向。这些变化都需要明确审批。

可观测性不等于把所有内容都存下来。 有用的链路记录应提供足够的上下文，以便排查失败，同时按照这些内容的性质设置访问权限和脱敏措施。

学 LLMOps，读书还是上课？

根据自己尚不能完成的生产任务选择学习材料。书籍可以帮助理解架构；课程是否有用，要看练习能否让你亲手构建数据集、排查链路、设置发布门槛并从故障中恢复。对于基于 API 的功能，只讲模型训练的课程大纲会留下重要缺口。

下周一就能开始的行动

如果客户已经依赖这个功能，就应立即补齐发布门槛、操作权限和恢复路径。如果手上只有一个隔离的原型，既不涉及客户数据，也不会执行外部操作，那么在保证实验可复现的前提下，可以暂缓共享网关和平台管理工作。

1. 1

   选定一个功能，写清失败条件

   选择最重要的生产流程，写出可接受的结果、禁止的操作、负责人，以及必须停止发布的条件。

2. 2

   让当前发布版本可追溯

   记录提示词、模型、上下文、工具、策略和依赖的标识，并把这份记录关联到一条已脱敏的请求链路。

3. 3

   把已知失败变成发布门槛

   构建有代表性的评估用例，以当前版本的运行结果为基线；关键类别如果出现退化，必须先经审核才能接受。

4. 4

   实际演练恢复流程

   在安全环境中验证回滚和停用流程。增加新平台之前，先安排好下一次问题调查和依赖更新审查的负责人。

LLMOps 常见问题

LLM 和 LLMOps 有什么区别？

LLM 是生成输出的模型。LLMOps 则是围绕使用该模型的应用开展的运维实践，包括控制变更、检查行为、观测请求，以及从故障中恢复。

LLMOps 的全称是什么？

LLMOps 的全称是 large language model operations，即大语言模型运维。对应用团队而言，它还涵盖模型周边的提示词、上下文、工具和发布流程。

LLMOps 和 AgentOps 的主要区别是什么？

AgentOps 更关注多步执行，包括工具操作、持久化状态、权限、步骤上限和任务完成情况。智能体是利用模型选择操作的系统；这些操作同样应纳入发布控制和故障处置流程。

怎样选择适合的 LLMOps 课程？

对本文面向的读者，适合的课程应在考核项目中涵盖评估、链路追踪、部署和恢复。只讲模型训练的课程，无法覆盖现有生产功能的运维职责。

有免费的 MLOps 认证吗？

是否提供免费认证，以及考试条款如何，要看颁发机构；报名前应核实其当前的认证页面。落实本文所述的发布控制，并不以取得认证为前提。

3 个月能学会机器学习吗？

可以用这段时间完成一个范围明确的学习项目，但不要把它当成掌握生产实践的保证。对于已有的 LLM 功能，一个有用的项目是：构建具备版本管理、评估、链路追踪，并经过恢复流程验证的应用。

机器学习岗位薪资高吗？

薪酬取决于岗位、地区和资历；仅凭 LLMOps 这个职位名称，无法判断收入。招聘时，更应考察候选人能否解释一次评估失败，并安全地运维由此形成的发布版本。

30 岁开始学 Python，晚不晚？

不晚。选一个小型实践项目，并保持稳定的练习节奏。不必先成为模型研究人员，也能学会这一生命周期所需的应用开发工作。

AI 和机器学习是不是很难学？

关键在于学习范围。运维一个调用现成模型的功能，与研究一个新模型，是两类不同的学习项目。先从现有功能已经需要承担的软件开发和评估职责学起。

想了解构建与运维 AI 功能的实用指南，可以订阅邮件通讯。