大模型应用CI/CD全流程解析：打通模型训练、评估、部署自动化，应用持续迭代实践23.7

​一、前言

传统软件的CI/CD大家都已经非常熟悉，写业务代码、提交代码后流水线自动做编译、单元测试、集成测试，通过之后直接部署上线，整个流程高度标准化。但当业务从普通后端业务转向大模型应用之后，我们会发现老一套CI/CD直接水土不服。

普通软件交付的核心产物是代码二进制包，逻辑是确定的，输入固定就会输出固定结果；而大模型应用的交付物不再只有代码，还包含权重文件、Prompt模板、向量知识库、微调数据集、工具配置等大量资产。大模型本身具备生成不确定性，同样输入，模型每次返回结果可能存在差异，传统单元测试很难直接套用。

我们早期做大模型项目，大都是本地调试Prompt，手动导出向量库，手动调用微调脚本，人工简单看几条样例效果之后就直接上线。上线之后经常遇到问题：Prompt改完没有版本记录；微调之后模型效果退化；知识库更新没有校验；线上大模型输出幻觉、回答跑偏；出问题之后无法复现是代码、Prompt、数据集还是模型权重导致的故障。这些问题本质就是缺少适配大模型特性的CI/CD流水线。

大模型应用CI/CD，并不是把传统CI/CD直接复制粘贴过来，而是在原有代码持续集成基础之上，新增模型资产版本管理、模型自动化评估、Prompt测试、数据集校验、向量库版本管控、安全对齐检测、模型灰度发布这一系列全新环节。今天我们详细探讨如何搞懂如何搭建一套可用的LLM CI/CD，解决大模型项目迭代混乱、上线风险高、问题难以复现的工程难题。

二、传统CI/CD基础介绍

在深入大模型专属CI/CD体系之前，我们必须夯实传统软件CI/CD的核心基础。大模型CI/CD并非凭空诞生，而是在传统CI/CD工程理念上的迭代与扩容，只有吃透传统流水线的设计逻辑、核心流程和适用场景，才能精准理解大模型场景下的改造差异和优化思路。

CI/CD是现代软件工程的核心基石，全称持续集成（Continuous Integration）、持续交付（Continuous Delivery）/持续部署（Continuous Deployment），是一套标准化、自动化的软件研发交付体系，彻底解决了传统手工开发、测试、部署模式的各类痛点。

1. 传统CI/CD核心概念

在早期软件研发模式中，开发人员各自在本地编写代码，项目迭代末期统一合并代码、集中测试、手动打包部署。这种模式极易出现代码冲突、隐藏Bug堆积、部署环境不一致、上线耗时久、故障难溯源等问题。而CI/CD通过自动化流水线，规范了代码从提交、校验、构建、测试到上线的全流程，实现研发交付的高效、稳定、可追溯。

其中CI持续集成和CD持续交付/部署各司其职，形成完整闭环，三者定义边界清晰、分工明确：

持续集成（CI）：核心是“代码频繁合并、自动校验”。

• 开发人员高频次将本地代码提交至主干代码仓库，流水线自动触发代码拉取、合并、校验、构建、测试等一系列操作，每次提交都要完成全套集成校验。
• 核心目的是尽早发现代码Bug、格式问题、依赖冲突、编译报错等问题，避免问题堆积，保证主干代码始终处于可编译、可运行的健康状态。

持续交付（CD）：核心是“制品可控、按需发布”。

• 在CI校验通过的基础上，自动将合格的代码构建为标准化制品，比如Docker镜像、Jar包、压缩部署包等，并统一归档至制品仓库。
• 全程自动化完成测试、预发环境部署，生产环境上线需人工审核触发，兼顾交付效率和上线安全性，是企业最常用的交付模式。

持续部署（CD）：核心是“全自动化、无人值守上线”。

• 是持续交付的终极形态，所有前置校验、构建、测试流程全部自动化通过后，无需人工干预；
• 直接自动部署至生产环境，适用于迭代频率高、风险极低的互联网轻量业务场景。

2. 传统CI/CD完整流程

传统软件CI/CD流水线是一套标准化、固定化的流程体系，所有业务代码迭代都遵循统一流程执行，无特殊定制逻辑，整体分为六大核心步骤，全程可自动化执行，适配所有后端、前端、客户端常规软件项目。

• 步骤一：代码提交触发：开发完成功能开发、Bug修复后，通过Git提交代码、发起合并请求，代码仓库监听分支变更，自动触发CI流水线启动，无需人工手动启动任务。
• 步骤二：代码静态校验：流水线拉取最新代码，执行全维度静态检查，包含代码格式规范校验、语法错误检测、代码重复率扫描、安全漏洞扫描、依赖包风险检测等。不通过规范的代码会直接拦截流水线，强制开发整改，保障代码仓库质量统一。
• 步骤三：自动化测试校验：这是CI阶段的核心质量关卡，依托确定性测试用例完成自动化校验。主要包含单元测试、接口集成测试、自动化UI测试等，所有测试用例结果具备唯一性、确定性，固定输入必然产出固定输出，只要用例失败、断言不通过，流水线直接终止，禁止进入后续环节。
• 步骤四：项目制品构建：所有校验、测试全部通过后，流水线执行项目编译、打包、镜像构建操作，生成统一标准化交付制品。制品会携带唯一版本标签、提交记录、流水线ID等溯源信息，保证每一份交付产物可追溯、可复刻。
• 步骤五：制品仓库归档：将构建完成的Jar包、Docker镜像、配置包等制品上传至专属仓库，统一存储管理，避免本地打包产物不一致、丢失等问题，为后续多环境部署、版本回滚提供标准化制品支撑。
• 步骤六：多环境部署发布：按照开发、测试、预发、生产的环境层级，依次自动化部署制品。测试、预发环境自动部署用于验证功能可用性，生产环境根据团队策略选择人工审核部署或全自动部署。

3. 传统CI/CD核心特性

传统CI/CD能够成为软件工程通用标准，核心在于其高度标准化、自动化、可控化的特性，完美适配确定性软件的交付需求，核心优势体现在四个方面。

• 结果确定性强：传统软件代码逻辑是固定的，代码变更可精准溯源，测试结果、运行效果、输出结果完全可控、可复现。相同代码、相同环境、相同配置，运行结果百分百一致，不会出现随机误差，这是传统CI/CD最核心的底层特性。
• 全程自动化降本提效：彻底替代人工编译、打包、部署、测试的重复工作，将原本数小时的上线流程压缩至分钟级，极大降低人工操作失误概率，提升研发迭代效率，适配高频迭代的业务场景。
• 质量卡点严格可控：流水线设置多层强制卡点，代码不规范、测试不通过、存在安全漏洞都会直接阻断发布，从流程上杜绝劣质代码上线，统一团队研发规范，降低线上故障概率。
• 版本可追溯可回滚：所有代码变更、制品版本、流水线执行记录全程留存，一旦线上出现故障，可快速定位问题代码版本，一键回滚至上一稳定版本，故障修复高效可控。

4. 传统CI/CD主流工具栈

传统CI/CD工具生态成熟、选型稳定，各行各业通用，无技术壁垒，核心工具分为流水线编排、代码管理、制品管理三大类，搭配即可搭建完整交付体系。

• 流水线编排工具：Jenkins、GitLab CI、GitHub Actions、Gitee Go，主要负责流水线流程调度、任务编排、步骤执行，是CI/CD体系的核心调度中枢。
• 代码版本管理工具：Git，统一管理所有业务代码、配置文件，实现代码版本追踪、分支管理、变更记录留存。
• 制品仓库工具：Harbor（镜像仓库）、Nexus（依赖包、程序包仓库），统一归档存储各类交付制品，保障制品标准化、可复用。

5. 传统CI/CD固有局限性

传统CI/CD是为确定性代码软件设计的标准化体系，适配常规业务系统、互联网服务、后端接口等项目，但存在天然局限性，这也是其无法直接适配大模型应用的核心原因。

• 传统流水线仅聚焦代码和配置的变更校验，交付对象单一，仅覆盖代码、程序包、镜像等静态确定性产物，无法管理模型权重、数据集、Prompt、向量库等动态AI资产。
• 同时仅支持确定性测试断言，无法适配大模型语义生成、效果优劣、幻觉概率等非确定性指标校验，没有模型评估、安全对齐、资产版本管控等AI专属能力。

三、大模型CI/CD迭代设计

1. 传统软件CI/CD风险

传统软件CI/CD面向确定性程序逻辑，交付主体为源代码、配置文件、编译产物。整个流水线围绕代码变更驱动。

• 持续集成CI：开发提交代码，流水线执行代码拉取、语法检查、代码规范扫描、单元测试、集成测试、构建镜像。所有测试用例结果具备确定性，同样输入一定得到相同输出，测试失败直接阻断流水线，不允许进入下一环节。
• 持续交付CD：测试通过之后，把制品推送到镜像仓库，支持手动触发部署到测试、预发、生产环境。
• 持续部署：在交付基础上，满足条件自动完成线上环境发布。

传统流水线风险点主要来自代码Bug、配置错误、依赖冲突。所有资产都可以放在Git仓库中进行版本追踪，回滚简单，直接切换镜像版本即可完成回滚操作。

2. 大模型应用新增交付资产

大模型应用是代码+模型资产的混合系统，很多资产无法直接存入Git仓库，这也是最大的区别，主要包含下面几类资产：

• 1. 业务代码：Agent逻辑、RAG检索逻辑、API服务代码、工具调用代码，这部分和传统软件一致，可以Git管理。
• 2. Prompt资产：系统提示词、Few‑shot样例、Agent指令模板，频繁修改，直接影响模型输出质量。
• 3. 数据集：微调训练集、评估测试集、知识库原始文档。
• 4. 模型制品：基础模型权重、LoRA微调权重、量化后模型。
• 5. 向量库制品：文档切片、Embedding向量索引、知识库快照。
• 6. 配置资产：模型参数temperature、top_p、最大输出长度、限流、提示词安全规则。

这里要注意的是大权重模型文件体积巨大，不能直接提交Git，需要借助模型版本仓库做版本管控。

3. 与传统CI/CD核心差异

实际项目中常见痛点：

• 1. 只对业务代码做CI，Prompt、数据集修改不走流水线，无版本记录；
• 2. 缺少自动化模型评估，全靠人工抽样看效果，上线才发现效果变差；
• 3. 向量库更新直接操作线上库，没有快照，出问题无法回滚知识库；
• 4. 微调完成没有对比基线模型指标，模型退化直接发布线上；
• 5. 缺少安全检测，更新Prompt之后出现越狱、敏感输出风险。

4. 大模型CI/CD设计原则

基于以上差异，设计LLM CI/CD流水线需要遵守几条核心原则：

• 一切可变更资产都要版本化，不仅仅是代码；
• 代码做确定性测试，模型做自动化效果评估，评估不通过阻断发布流程；
• 所有制品可追溯，每一次流水线执行绑定代码版本、Prompt版本、数据集版本、模型版本；
• 支持多资产一键回滚，代码、模型、知识库协同回滚；
• 分层环境隔离：开发、测试、预发、生产，严禁资产直接改动生产环境。

四、大模型CI/CD整体架构

1. 流水线总览

完整的大模型CI/CD流水线分为5大阶段：

触发阶段 → 持续集成CI阶段 → 模型专项校验阶段 → 持续交付CD阶段 → 线上运维观测闭环。

触发源不再仅仅是Git代码提交，还包含：Prompt仓库变更、数据集版本更新、微调任务完成、知识库文档更新。简单理解整个流程：

• 当任意一份受控资产发生变更，自动启动流水线；
• 先做传统代码层面检查；
• 再做大模型专属校验，包含数据集校验、Prompt测试、模型评估、安全检测；
• 全部校验通过之后，打包全部制品；
• 先部署测试环境验证，预发做灰度验证；
• 最终上线生产；
• 上线之后持续采集线上真实用户Query反馈，回流数据集，形成闭环，反哺下一轮流水线迭代。

2. 依赖的基础工具栈

大模型CI/CD需要在传统CI工具之上补充LLM专用工具，这里给出工程落地常用选型，不绑定某一套，可按需替换。

• 1. 通用CI编排：GitLab‑CI / GitHub Actions / Jenkins，负责流水线流程调度。
• 2. 代码版本：Git，存放业务代码、Prompt模板、评估脚本。
• 3. 模型&数据集版本管理：DVC / MLflow / Hugging Face Hub，管理大权重、数据集，解决大文件无法存入Git的问题。
• 4. 模型评估：LangSmith、DeepEval、Ragas，实现RAG、Agent自动评估。
• 5. 制品仓库：容器镜像仓库存储服务镜像；模型仓库存储LoRA、权重快照；对象存储存放向量库快照。
• 6. 向量库：Chroma / Milvus / Qdrant，向量快照导出保存至对象存储。
• 7. 可观测：Langfuse，采集线上大模型调用日志、用户反馈。

3. 流水线输入与输出制品

流水线输入（触发变更源）

• 1. 业务代码提交MR/PR
• 2. Prompt模板修改提交
• 3. 微调数据集更新版本
• 4. 知识库原始文档更新
• 5. 微调任务产出新LoRA权重版本

流水线输出制品，每一次运行全部打版本标签

• 1. 业务服务Docker镜像（带版本tag）
• 2. Prompt模板打包包（版本记录）
• 3. 数据集版本元信息
• 4. 模型/LoRA权重版本标识
• 5. 向量知识库索引快照备份
• 6. 本次运行完整评估报告（json/html）
• 7. 安全扫描报告

这里需要注意的是每一个制品之间通过同一个run_id关联，后续排查问题输入run_id，即可找到本次上线所有资产版本。

五、持续集成CI阶段实现细节

1. 触发与前置检查

• CI阶段第一步接收变更触发，做前置校验，区分变更类型。
• 如果是代码变更：执行代码静态检查；
• 如果是Prompt、数据集变更：不改动业务代码，依然需要完整跑模型校验，很多团队会忽略这点，以为没改代码就不用走流水线。

前置检查包含：

• 1. 代码语法、格式、依赖漏洞扫描；
• 2. Prompt模板语法校验，检测变量占位符缺失，模板渲染报错；
• 3. 数据集格式校验，检查微调集、评估集格式、字段缺失、脏数据；
• 4. 知识库文档格式校验，文档是否损坏。

GitHub Actions极简示例：做前置校验片段 .github/workflows/llm_ci.yml

name: LLM应用CI流水线
on:
  push:
    branches: [ main, dev ]
  pull_request:
    branches: [ main, dev ]
  # 支持手动触发
  workflow_dispatch:

jobs:
  pre_check:
    runs-on: ubuntu‑latest
    steps:
      - name: 拉取代码
        uses: actions/checkout@v4
      - name: Python环境准备
        uses: actions/setup‑python@v5
        with:
          python‑version: "3.11"
      - name: 安装依赖
        run: |
          python -m pip install --upgrade pip
          pip install flake8 pydantic
      - name: 代码静态检查
        run: flake8 ./src --max‑line‑length=120
      - name: 执行Prompt模板校验脚本
        run: python ./scripts/prompt_validate.py
      - name: 数据集格式校验
        run: python ./scripts/dataset_validate.py

配套简单校验脚本：scripts/prompt_validate.py

"""Prompt模板校验脚本：检查模板占位符是否合法"""
from pydantic import BaseModel
import jinja2
import os

PROMPT_DIR = "./prompts"

def validate_prompt_template(file_path: str):
    with open(file_path, "r", encoding="utf‑8") as f:
        content = f.read()
    try:
        env = jinja2.Environment()
        env.parse(content)
        print(f"✅ {file_path} 模板语法正常")
    except jinja2.exceptions.TemplateSyntaxError as e:
        print(f"❌ {file_path} 模板语法错误 {e}")
        raise SystemExit(1)

if __name__ == "__main__":
    all_files = [os.path.join(PROMPT_DIR, f) for f in os.listdir(PROMPT_DIR) if f.endswith(".jinja2")]
    for fp in all_files:
        validate_prompt_template(fp)
    print("全部Prompt模板校验通过")

2. 单元测试与集成测试

这一部分和传统CI类似，针对确定性逻辑做测试，不要尝试在这里测试大模型生成效果。可以测试的内容：

• 工具调用解析逻辑；
• 文档切片、文本处理函数；
• 参数解析、限流逻辑；
• 量库增删改查基础接口；

调用真实大模型判断回答好不好，不需要在这里测试，这类放到后续模型评估阶段。

3. 构建制品

前置检查、单元测试全部通过之后，开始构建全部制品：

• 1. 编译构建业务服务Docker镜像，打上流水线run_id作为版本标签；
• 2. 将Prompt目录、配置文件打包为制品包，上传制品仓库；
• 3. 如果本次变更涉及知识库：执行文档切片、Embedding向量化，生成向量索引快照，备份到对象存储；
• 4. 如果是微调任务触发：下载产出LoRA权重，记录版本元数据，上传模型仓库。

这里需要注意，向量库不直接写入线上向量库，只生成快照制品，交付阶段再部署，防止CI阶段直接污染生产知识库。

六、大模型专项校验阶段

1. 数据集质量校验

数据集是大模型效果根源，很多上线故障来自脏数据集。校验分为格式校验与样本质量校验。

格式校验：字段完整性、json格式、文本非空，前面脚本已经覆盖。

样本质量校验：

• 1. 检测样本重复，过滤大量重复问答；
• 2. 检测样本存在敏感内容、违规文本；
• 3. 评估集样本数量是否满足最低规模，避免几个样本就判定模型合格。

简易数据集检测示例：

import json
from collections import Counter

def dataset_check(dataset_path: str, repeat_threshold: float = 0.2):
    with open(dataset_path, "r", encoding="utf‑8") as f:
        data = json.load(f)
    texts = []
    for item in data:
        q = item.get("instruction","") + item.get("input","") + item.get("output","")
        texts.append(q.strip())
    # 重复样本检测
    counter = Counter(texts)
    repeat_count = sum([cnt for cnt in counter.values() if cnt>1])
    repeat_rate = repeat_count / len(texts)
    print(f"数据集总样本：{len(texts)}，重复率：{repeat_rate:.2%}")
    if repeat_rate > repeat_threshold:
        print("❌ 数据集重复样本过高，流水线阻断")
        raise SystemExit(1)
    print("✅数据集质量校验通过")

if __name__ == "__main__":
    dataset_check("./data/eval_dataset.json")

2. Prompt自动化冒烟测试

修改Prompt模板之后，不能靠人肉眼看，流水线自动传入一批固定冒烟Query，渲染Prompt，调用测试环境大模型，快速看是否发生严重异常。

冒烟测试目标不是评估效果好坏，而是拦截严重故障：模板渲染报错、输出全部为空、全部乱码、完全不遵循指令。执行逻辑：

• 1. 读取一批固定冒烟测试Query集合；
• 2. 使用本次变更后的Prompt模板渲染请求；
• 3. 调用隔离的测试大模型服务；
• 4. 判断输出是否为空、长度异常，出现异常直接阻断流水线。

3. 模型自动化效果评估

这是整套LLM CI最核心的环节，也是和传统CI最大区别。当微调权重更新、Prompt更新、知识库更新之后，必须运行评估集，对比历史基线指标，判断是否发生效果退化。评估分为两类：

• 1. 客观指标：RAG的检索召回率、答案与参考答案相似度；
• 2. LLM as Judge评估：交给评估大模型，判断回答是否准确、是否存在幻觉、是否完整回答用户问题。

指标对比逻辑：流水线会读取上一个稳定版本的基线指标，当新版本指标下降超过设定阈值，流水线直接失败，禁止继续发布。

基于Ragas评估的示例：

演示流水线如何做评估，实际流水线会输出评估报告json保存为制品：

from ragas import evaluate
from ragas.metrics import faithfulness, answer_relevancy, context_recall
from datasets import Dataset

# 模拟评估数据集，流水线从eval_dataset读取
eval_data = {
    "question": [
        "大模型CI/CD包含哪些阶段？"
    ],
    "answer": [""],
    "contexts": [[]],
    "ground_truth": ["大模型CI/CD分为触发、CI、专项校验、CD、线上观测闭环五个阶段"]
}

def run_llm_eval():
    ds = Dataset.from_dict(eval_data)
    result = evaluate(
        ds,
        metrics=[faithfulness, answer_relevancy, context_recall]
    )
    df = result.to_pandas()
    print(df)
    # 将评估结果保存为制品
    df.to_json("./artifacts/eval_report.json", force_ascii=False)
    avg_score = result["answer_relevancy"]
    baseline = 0.70
    degrade_threshold = 0.05
    if avg_score < baseline - degrade_threshold:
        print(f"❌效果退化！当前分数{avg_score:.2f}，基线{baseline}，流水线终止")
        raise SystemExit(1)
    print("✅模型评估通过，效果未明显退化")

if __name__ == "__main__":
    run_llm_eval()

根据实际需要判断是否使用生产大模型做流水线大规模评估，建议使用独立的评估模型实例，避免占用生产算力；评估集需要持续积累，样本越多评估结果越可信。

4. 安全与对齐检测

大模型资产变更，尤其是Prompt、微调数据集更新之后，必须执行安全检测，拦截越狱提示、敏感输出风险。

流水线输入一批安全测试用例：越狱Prompt、敏感问题，检测模型输出是否输出违规内容。一旦命中风险，流水线阻断发布，避免上线之后出现安全事故。

5. 专项校验失败处理策略

专项校验环节任意环节失败，流水线直接终止，不会进入发布环节。

• 1. 数据集校验失败：需要开发修正数据集，重新提交变更触发流水线；
• 2. Prompt冒烟失败：检查模板变量、指令逻辑；
• 3. 模型评估指标退化：排查是Prompt改动、知识库切片变化还是微调数据集引入噪声；
• 4. 安全检测命中风险：修正Prompt或者数据集。

所有评估报告作为流水线制品留存，即使失败也可以下载报告，定位哪里出了问题。

七、持续交付CD阶段：模型应用部署与灰度

1. 环境分层策略

大模型应用环境必须严格隔离，不同环境使用独立的模型实例、独立向量库，禁止测试直接操作生产。

• 开发环境：开发人员本地调试；
• 测试环境：CI流水线自动部署，跑自动化评估；
• 预发环境：和生产配置对齐，执行小流量灰度验证；
• 生产环境：对外提供服务。

特别注意向量库不要多环境共用，每个环境有独立向量实例，通过流水线生成的快照制品部署，而不是直接复制线上向量。

2. 制品部署流程

CI和专项校验全部通过之后，进入CD交付。部署不再只是部署容器镜像，需要同步部署多份资产：

• 1. 部署新版本业务Docker镜像；
• 2. 加载对应版本Prompt包；
• 3. 如果有LoRA权重变更，模型服务加载对应版本LoRA；
• 4. 如果知识库变更，把流水线生成的向量快照导入环境向量库；
• 5. 完成服务健康检查：接口连通性、简单query返回验证。

3. 灰度发布策略

大模型绝对不建议一次性全量切流量。模型输出具有不确定性，即使自动化评估全部通过，依然可能存在评估集没有覆盖到的bad case，必须灰度。

常用灰度策略：

• 1. 按流量比例灰度：先切5%流量到新版本，观察一段时间；无异常再提升至30%，最后100%；
• 2. 按用户ID灰度：指定部分内部测试用户访问新版本；
• 3. A/B分流：新旧版本同时并行运行，同一批用户query同时送入新旧版本，对比两者输出效果，采集对比日志。

灰度阶段观测指标：接口QPS、错误率、超时率；业务指标：幻觉占比、用户负面反馈率、拒绝回答异常案例数量。一旦指标恶化，立刻执行回滚。

4. 大模型应用回滚机制

传统业务只需要回滚镜像。大模型回滚需要多资产协同回滚，这是工程应用的核心关键点。回滚操作清单：

• 1. 业务服务镜像回退到上一个稳定tag；
• 2. Prompt模板回退旧版本；
• 3. LoRA模型权重切回旧版本；
• 4. 向量库恢复上一版快照备份；
• 5. 确认全部资产全部回到旧版本，缺一不可。

所以流水线每一次发布都要完整保存全部制品快照，保存run_id，回滚时输入run_id一键恢复整套资产。

八、线上观测与迭代闭环

1. 线上可观测采集

流水线上线完成不是工作结束，需要把线上真实业务数据回流，形成闭环。需要采集的数据：

• 1. 用户原始Query、模型回答、检索出来的上下文片段；
• 2. 用户显式反馈：点赞、点踩，标记回答不好、幻觉；
• 3. 链路元数据：本次请求使用的Prompt版本、LoRA版本、知识库版本、run_id；
• 4. 异常案例，例如模型拒绝回答、超时、输出乱码。

推荐使用Langfuse、LangSmith记录链路，每一条trace绑定本次上线全部资产版本，线上出现bad case，就可以追溯是哪一次流水线引入问题。

2. 数据回流反哺流水线

采集线上负样本之后，做人工清洗，补充到评估数据集，部分优质样本加入微调数据集。数据集更新提交版本仓库，会自动触发新一轮CI流水线，跑完整评估，验证新版本是否修复线上发现的问题。

这样就形成闭环：线上真实问题 → 沉淀数据集 → CI流水线自动评估验证 → 发布新版本上线。避免只靠开发人员自己造测试样本。

3. 定期基线重跑

除了变更触发流水线，还建议配置定时流水线任务，每周自动跑一遍全套评估集。

• 如果基础底层大模型服务本身版本升级，即使业务代码、Prompt什么都不改，底层模型能力发生变化，也会造成业务效果退化。
• 定时任务定期对比基线，提前发现底层模型变更带来的业务影响。

九、最佳实践记录

1. 高频踩坑问题

• 1. 将大模型权重直接放入Git仓库：仓库膨胀，提交缓慢，必须使用DVC、模型版本仓库管理大文件。
• 2. Prompt不纳入流水线管理：开发本地改Prompt直接上线，没有版本，出问题无法回滚，Prompt和代码一样要走MR/PR。
• 3. CI流水线直接操作生产向量库：一旦切片逻辑bug，直接破坏线上知识库，CI阶段只产出快照，CD阶段部署导入。
• 4. 把大模型完整生成断言写单元测试：模型输出语义相同但是文字不一样，会导致单元测试大量随机失败，单元测试只测确定性逻辑。
• 5. 跳过灰度直接全量上线：自动化评估集永远无法覆盖全部真实用户场景，必须灰度观察。

2. 轻量化实践建议

在早期接触，或没有实践经验是，不需要一步搭建超级复杂完整系统，可以分阶段落地。

• 阶段一：基础能力。把Prompt、数据集纳入Git版本；CI做代码校验、Prompt语法校验；向量更新导出快照备份；禁止手动改线上Prompt、向量库。
• 阶段二：增加冒烟测试、简单自动化评估，评估不通过阻断发布。
• 阶段三：完善灰度、观测链路，线上样本回流数据集。
• 阶段四：完整自动化微调流水线，微调完成自动触发LLM‑CI校验。

不要追求一步到位，优先解决最痛的痛点：资产无版本、手动上线。

十、总结

传统软件CI/CD聚焦代码，而大模型应用CI/CD本质是一套“代码+模型全资产”的持续工程体系。它不是把传统流水线抛弃，而是在传统CI基础之上扩展了模型资产版本管控、数据集校验、Prompt测试、自动化模型评估、向量制品管理、灰度回滚、线上数据闭环这一整套全新能力。

早期刚接触做大模型项目，容易把大量精力花在调Prompt、调微调参数，却忽略工程交付体系。当项目规模小，只有少量Query，手工处理尚可；业务规模扩大之后，没有LLM‑CI/CD就会面临版本混乱、上线风险高、故障无法复现，迭代效率急剧下降。核心做到所有会影响输出的资产全部版本化；能自动化校验就不要人工；上线一定要灰度，线上真实数据要回流给流水线。这样的大模型项目就可以像传统软件一样，安全、可控、可追溯的持续迭代，告别“本地效果很好，上线就翻车”的行业常见困境。