DevOps：做了四年CI/CD，我转型做了LLMops

关注

原创最新推荐文章于 2026-11-14 16:33:19 发布 239 阅读 AI 写同款· GEO 优化 ›

Linux内存压力测试工具【memtester】详且精对Linux下的压力测试工具memtester有一个比较人性化的概述，以及避坑心得。阅读详情

那天晚上十一点，我在值班群里看到一条消息：“线上客服机器人回答质量明显下降，很多回答驴唇不对马嘴。”

我第一反应是去查发布记录。但打开GitLab，最后一笔代码提交是三天前的。再查模型服务部署记录，也没看到今天有变更。我继续翻，终于在LangSmith里发现了一条实验记录：Prompt工程师小李昨天下午上线了一个新版本的Prompt，在线上做了一小流量A/B测试。

我打电话给小李。他声音有点懵：“我就改了一句引导语，想着流量小应该没事。”

"但线上回滚要回滚哪个版本？"我问，“模型版本没变，代码没变，只有Prompt变了。我们的回滚脚本只能回滚Docker镜像。”

电话那头沉默了很久。那天我意识到，做了四年CI/CD的我，面对大模型应用时，手里那套工具链突然不够用了。版本对象不再只是代码，还有模型、Prompt、数据集、评测结果。这是另一个世界。

一、那一次回滚，我找不到回滚点

那件事之后，我花了一周时间梳理AI系统的发布对象。列出来吓了自己一跳：

代码：Flask/FastAPI服务、Agent框架、业务逻辑
模型：基座模型版本、LoRA适配器、Embedding模型
Prompt：系统Prompt、业务Prompt、Few-shot示例
数据：训练数据、评测数据、向量库索引
配置：温度值、Top-P、Max Tokens、路由策略

在传统DevOps里，代码版本有Git，配置有配置中心，模型如果有变更通常也只是镜像。但在LLM应用里，一次产品效果变化，可能跟代码完全无关，而是Prompt里改了一个词。

"你这意思是，Prompt也是生产环境的配置项？"运维主管老王听完我的汇报，眉头皱成一团。
"是核心配置项。"我说，“而且它比代码变更更频繁，效果影响更直接。”
“那你怎么保证回滚？”
“这就是我们要解决的问题。”

我开始在团队里推LLMops。名字听起来新，但核心思想和DevOps一模一样：自动化、版本化、可观测、可回滚。只是对象扩展了。

二、LLMops到底在管什么

我给团队画了一张LLMops的版图，分成四层：

第一层：数据层。 训练数据、微调数据、评测数据、用户反馈数据。要有版本、有血缘、有采样和脱敏策略。

第二层：模型层。 基座模型、微调模型、Embedding模型、重排序模型。要记录模型来源、训练参数、评估指标、部署位置。

第三层：Prompt层。 系统Prompt、业务Prompt、工具描述、Few-shot示例、输出Schema。要走版本控制，能A/B测试，能一键回滚。

第四层：应用层。 服务代码、Agent工作流、业务逻辑、网关配置。这块和传统DevOps最像。

LLMops的本质，是让这四个层级的变更都能被管理、被追踪、被回滚。

我选的第一批工具链是这样的：

代码版本：GitLab（不变）
数据版本：DVC（Data Version Control）
模型版本：MLflow
Prompt版本：Git + YAML配置文件 + PromptHub
实验追踪：LangSmith + Weights & Biases
CI/CD：GitLab CI
监控报警：Grafana + 自定义LLM指标

工具不是最重要的，流程才是。我定了三条铁律：任何进入生产环境的Prompt必须有版本号；任何模型上线必须有基线评测；任何A/B测试必须有明确的回滚策略。

三、模型与Prompt的版本管理：不能只有一个latest

Prompt版本管理是我们最先落地的。我们把所有Prompt都拆成YAML文件，按业务模块组织，每个文件包含版本号、适用模型、基础模板、变量说明、Few-shot示例、输出Schema和评测用例。

# prompts/customer_service/v2.3.1.yaml
name: customer_service_main
version: 2.3.1
model: gpt-4-turbo
system_prompt: |
  你是一位专业的客服助手。请根据用户问题，从知识库中检索信息并作答。
  如果无法确定答案，请回答"我需要为您转接人工客服"。
  回答必须简洁，不超过100字。
user_template: |
  用户问题：{{question}}
  相关知识点：{{retrieved_context}}
schema: schemas/customer_service_response.json
few_shots: shots/customer_service_v2.json
eval_cases: eval/customer_service_v2.csv

YAML文件进Git，修改走PR。每个版本发布时，CI自动跑评测用例，生成准确率、幻觉率、平均token数等指标。只有不劣化才允许合入。

Prompt的回滚也简单了很多。生产环境里Prompt版本号存在配置中心，发现异常时，改一个版本号就能切回上一版。这比"让Prompt工程师赶紧改回来再发布"靠谱一百倍。

模型版本我们用MLflow管理。每个模型artifact记录：训练脚本版本、训练数据DVC版本、超参数、评测结果、部署状态。模型上线时，部署系统从MLflow拉指定版本的模型文件，而不是拉latest。

"为什么不能直接拉latest？"实习生问。
"因为latest是不可复现的。"我说，“今天你拉是v3.1，明天可能就是v3.2。出了线上问题，你都不知道跑的是哪一版。”

这个习惯和代码部署一样：永远指定明确版本，永远能追溯。

四、实验追踪：让每次改动都可解释

大模型应用的调试，比传统软件痛苦十倍。传统软件出bug，你可以打断点、看日志、复现路径。大模型应用出效果问题，可能是Prompt改了、模型版本变了、温度值调了、检索结果顺序变了，甚至是随机种子导致输出不同。

我们必须追踪每一次实验。我要求团队所有实验都走LangSmith或W&B，记录：

使用的Prompt版本
使用的模型版本
输入输出样本
中间链路的每一步（检索结果、工具调用、模型输出）
评测指标
实验人员和时间

LangSmith在这方面做得很好。你可以看到一次请求完整的trace：用户输入是什么，RAG检索回了哪些片段，Prompt拼接后的完整内容是什么，模型输出了什么，后处理怎么解析的。出了问题，顺着trace就能定位。

# LangSmith trace示例
from langchain.callbacks import LangChainTracer

tracer = LangChainTracer(project_name="customer_service_v2")

chain.invoke(
    {"question": "我的订单什么时候到？"},
    config={"callbacks": [tracer]}
)

有一次线上客服的回答突然变得特别啰嗦。我查LangSmith，发现是某个业务Prompt里加了一句"请详细解释"，本来只用于教学场景，但配置时误用到了主流程。没有trace的话，这个问题可能要查半天。

我还建立了一个实验对比看板。每次要上线新Prompt或新模型，先在测试集上跑一遍，把结果和当前线上版本并排展示。不是"感觉更好"就能上，而是要有指标支撑。

五、自动化评测流水线：CI/CD for LLM

传统CI/CD跑的是单元测试、集成测试、构建、部署。LLM应用也需要类似的Pipeline，只是测试内容不同。

我们设计的LLM应用CI/CD流程是这样的：

代码提交：触发常规lint、单元测试
Prompt变更：读取变更的Prompt文件，跑对应评测集
模型变更：从MLflow拉模型，跑推理测试和效果评测
集成测试：端到端跑一批真实场景的case
A/B配置生成：自动生成灰度发布配置
部署：按版本号部署，先5%流量，再逐步放大
效果监控：上线后持续监控核心指标，异常自动告警和回滚

评测集是关键。我们建了一个共享的评测库，按业务模块组织，每个case包含输入、期望输出、评分标准。评分分两类：

规则评分：JSON格式是否正确、字段是否齐全、输出长度是否合规
模型评分：用GPT-4做LLM-as-a-Judge，从相关性、准确性、流畅度、安全性几个维度打分

# .gitlab-ci.yml 片段
llm_eval:
  stage: test
  script:
    - dvc pull data/eval/customer_service
    - python -m eval.run --prompt prompts/customer_service/$PROMPT_VERSION.yaml --model $MODEL_VERSION --dataset data/eval/customer_service
    - python -m eval.compare --baseline outputs/baseline.json --current outputs/current.json
  rules:
    - changes:
        - prompts/customer_service/*
        - models/customer_service/*