企业官网建设流程全解析

1. 为什么大模型CI/CD不能直接套用传统软件的流水线

1.1 模型不是一个能在单元测试里通过或失败的程序

传统CI/CD的核心是代码。代码是确定性的，编译一次得到同样的产物，单元测试通过就是通过，失败就是失败。模型不是这样。模型是一堆权重文件，同样的训练脚本，换一批数据、换个随机种子，出来的模型效果差异可能很大。更麻烦的是，大模型应用里“这个模型好不好”本身不是布尔值，而是要同时看它在目标任务上的表现、在边界情形上的处理、在用户反馈中的接受度。

我们团队最开始也想直接套传统软件那套流水线：代码提交，拉代码，跑测试，构建镜像，然后部署。结果第一次尝试就卡住了。训练一个模型跑了七八个小时，训练完之后的“测试脚本”只能检查输出字段是否完整、格式是否合法，对模型质量几乎没有判断能力。整个流程看起来很自动化，实际作用却非常有限。

后来我才逐渐明白，大模型应用的CI/CD要解决的核心问题不是“自动化”，而是“让一次模型迭代的完整链路可追踪、可验证、可回滚”。代码只是这条链路里很小的一部分，数据版本、训练参数、评估结果、部署状态都必须纳入流水线的视野，否则所谓的自动化只是一个空壳。

1.2 四座大山：数据、参数、评估、漂移

我习惯把大模型CI/CD要面对的挑战归纳成四座大山。你和团队聊明白了这四件事，后面的工程化设计基本就能顺着走。

第一座大山是数据。模型的质量上限由数据决定。用什么版本的数据训练过，这个数据集包含哪些新样本，哪些旧样本被删掉了，数据文件本身的哈希是什么，这些信息如果不记录，后续排查线上问题的时候会毫无头绪。我们见过不少团队，一个数据集文件夹在共享盘里翻来覆去地覆盖，最后谁都不知道线上模型到底是拿哪一份数据练出来的。

第二座大山是参数。训练脚本、学习率、Batch Size、LoRA的rank值、Prompt模板、推理时的采样温度，这些全都会影响模型行为。同样一份数据，参数配比不同，产出的模型行为差异很大。参数不记录，实验不可复现。不可复现意味着你永远无法判断上一次成功到底是靠什么取得的。

第三座大山是评估。代码测试是检查是否符合预期，模型评估是衡量输出好坏的程度。而“好坏”的标准是会变的。今天你觉得回答长度重要，明天觉得严谨性重要，后天又希望语气更亲切。评估口径不稳定，模型之间就没法横向比较，更不要说自动化的门禁了。

第四座大山是漂移。代码部署之后行为基本稳定，除非有bug。模型部署上线之后，用户输入分布会随时间变化，业务场景会调整，模型效果会逐渐下降。传统CI/CD没有“运行时质量监控加自动回炉训练”这个概念，但大模型应用必须有。这也是为什么后面说的监控和数据回流，是整个闭环里最不能省的一环。

理解了这四座大山，你再看训练、评估、部署、监控这条链路，很多设计选择就变得顺理成章了。

2. 训练阶段自动化：数据、实验、产物的管理闭环

2.1 数据版本管理与触发策略

训练流水线的第一步不是点开训练脚本，而是先回答一个问题：当前要基于什么数据训练？

我们用的是类似DVC的数据版本管理方案。数据集本身存放在对象存储里，Git仓库只维护数据目录的元数据。每一条数据变更都会产生新的文件哈希，流水线把这个哈希当作最重要的触发信号之一。数据有变化，说明可能有新东西可以学了。

这里有一个很容易忽略的细节：训练触发需要节制。大模型训练成本摆在那里，不可能数据一变就启动全量训练。我们会在触发训练之前，先让流水线跑一个低成本的“数据变化摘要”任务，统计新增样本量、类别分布变化、文本长度变化、脏数据比例。只有这些指标超过预设阈值，或者数据变更提交里带了“重要更新”标签，才真正去触发训练任务。

这个摘要任务我们内部叫“训练闸门”。它的作用就是过滤掉大量无意义的实验，避免GPU动不动就被无价值的训练任务占住。尤其是当一个项目经历了几个月持续迭代后，数据回流会非常频繁，没有这一层闸门，整个集群资源都会被浪费在“练一下看看”的实验上。

2.2 训练任务的编排与资源调度

数据准备好之后，训练任务本身要有一个稳定的编排方式。我们用的是Kubernetes集群加基于工作流的方式，把一次训练拆成几个独立阶段：数据预处理、数据切分、模型训练、模型导出。

每个阶段都是独立运行的任务，前一个阶段成功才进入下一个阶段。失败自动重试，最多重试两次，超过就标记失败并通知到群里。阶段产物都会分别保存，尤其是数据预处理后的结果，是下一次训练可以直接复用的，不需要每次重新处理。

资源调度方面，我们有三个优先级。线上推理服务最高，必须保证足够的GPU额度；灰度和影子服务第二；批量训练任务最低。低优先级的任务在集群资源紧张时会被挂起，等到有资源了再继续跑。说起来简单，但这套优先级策略救过我们不止一次，因为一旦训练任务把推理服务的资源抢占了，线上延迟会立刻飙升，用户投诉马上就来。

编排工具本身不是重点，重点是每个阶段要可观测、可重试、可输出独立产物。这样当某个环节出错时，不需要从头再来，而是从出错的阶段续跑。

2.3 实验追踪与产物管理的具体做法

训练阶段的第三个关键设计是实验追踪。我们要求每个训练任务必须把完整信息写入实验追踪平台：Git提交号、数据版本哈希、超参数、训练指标、模型文件路径、Tokenizer路径、依赖环境信息。没有记录完整的训练任务，流水线直接判定为无效，不允许进入评估环节。这个规则一开始觉得繁琐，但它保证了我们任何时候回看一个实验，都能知道它到底是怎么产生出来的。

训练完成后，模型产物会进入模型注册表。注册表是后续评估和部署的入口，每次训练产生一个版本号，版本号关联模型文件、训练配置、数据版本、评估结果。部署和回滚都以注册表为准，不再依靠任何人的口头约定。

这里分享一个我们踩过的坑：模型文件和代码版本产生错位。训练脚本更新了，但模型还是旧脚本生成出来的，部署时却配了新代码的推理解析逻辑，结果输出行为完全错乱。现在的做法是，训练脚本所在仓库的Git提交号也会写进注册表，部署时根据这个提交号拉取对应的推理代码和依赖版本。模型、代码、数据、配置都从同一棵树上长出来，排查问题时就能顺着关系链一路查下去。

3. 评估关卡：把“感觉还行”变成可量化的放行标准

3.1 离线评估：多维指标加上回归测试集

训练完成后的第一道关是离线评估。这一关要回答的问题只有一句：新模型相对线上模型，到底是提升了还是退化了？

为了回答这个问题，我们维护了一套独立的评估数据集。这套数据集的版本是冻结的，不能每次评估前都往里塞新样本，否则就失去了对比基准的意义。评估数据分为两部分：通用能力集和业务专属集。通用能力集覆盖常识问答、指令遵循、文本生成质量等基础能力；业务专属集是从真实用户请求中挑选出的高频和重要场景，按季度整体更新一次。

评估指标不能只看单个数字。对生成类模型，ROUGE和BLEU这类文本相似度指标只能做粗参考，真正重要的是任务成功率、答案正确率、关键信息覆盖率、有害内容率这些业务相关指标。每次评估，我们会让候选模型和线上模型在同一套数据集上跑，输出一张对比表。只有新模型在大部分维度上胜出，同时没有在某个关键维度上明显劣化，评估才算通过。

关于评估报告，我强烈建议不要只保留总分。模型质量不均衡是常态，常见的情况是模型总分很高，但某个用户量不小的子场景里质量严重下降。总分会被其他场景的平均表现掩盖。所以要按子场景分维度列清楚，一旦发现有劣化，必须由负责人解释理由，不能只是“总体提升了，可以上”。

3.2 人工评估与安全防线：红队测试不能省

大模型应用和传统推荐系统有个很大区别：模型的输出内容不受模板控制，恶意输入可能诱导出有害、违规或者越权的回答。所以评估关卡不能只看正常输入下的输出质量，还必须专门测异常输入下的防护能力。

我们在评估阶段会固定跑几次安全测试任务。样本库包含提示注入攻击、越狱短语、隐私泄露诱导、角色混淆引导等等。每一位新模型候选都要在样本库上跑一遍，看安全拒绝率、违规输出比例这些指标。这个样本库同时和线上监控联动：线上发现新的攻击模式，经过确认后加入样本库，下一次评估规则就会覆盖到。

人工评估也很重要，尤其是模型输出自然度、专业性这些自动化指标很难衡量的维度。每个模型候选在通过自动化指标后，我们会安排至少三到五名标注人员对一批随机抽样样本打分。所有打分样本全部进行匿名化处理，评估人员不知道哪个回答来自哪个模型，以避免主观偏好。

人工评估环节建议在流程里设置成“强制卡点”，不能因为进度压力就跳过。模型上线以后才发现回答风格、安全行为上踩线，代价比晚几天上线要大得多。

3.3 在线评估：影子部署的实际配置

离线评估通过之后，新模型只证明了它在静态数据上表现不错，还没经历真实流量的检验。所以在正式放量之前，我们通常会让模型以影子模式运行。

影子部署的基本原理很简单：线上用户的请求正常走老模型，网关在转发的同时复制一份到新模型，新模型的结果不返回给用户，只写进日志做分析。这样新模型被打了一轮真实流量，但用户完全无感，风险是零。

影子部署的配置并不复杂，关键在于流量复制。我们在网关层把请求转发到用户服务的同时，异步发一份到影子推理服务。影子服务把预测结果、置信度、耗时、输入指纹写进日志。数据量大的时候按比例采样，比如百分之五到十的用户请求进入影子模式，保证样本量够用又不浪费资源。

我见过有的团队在这一步试图用一个大模型去给另一个大模型打分，省掉人工评估。自动判官适合做大规模初筛，但我不建议把它作为最终结论，因为它本身也有偏好和幻觉问题。最稳的做法还是自动对比初筛加人工抽查关键样本，两边互相验证。

影子阶段通常跑两到三天，攒够真实样本后，把同一批请求同时给线上模型和影子模型跑对比。重点观察新模型在真实输入分布上的回答质量、输出长度、延迟表现。这一步通过后，新模型才真正具备进入灰度发布的资格。

4. 部署自动化：灰度、回滚与推理服务的高可用保障

4.1 从评估通过到服务上线的最后一公里

评估通过后的模型要从注册表走向部署。这个过程我们分成三步：打包、发布、切换。

打包是指把模型文件、Tokenizer、推理代码、运行依赖一起构建成一个不可变的镜像，镜像标签就是模型版本号。任何一次部署都能通过这个标签追溯到模型由什么代码和数据构建而来。镜像构建后要过一遍安全扫描，检查基础镜像漏洞和依赖风险，再推送到制品仓库。

发布阶段是把镜像部署到目标环境。我们的部署目标基本上是Kubernetes推理服务。这里有一个需要提前设计好的点：每个推理服务都要支持版本切换状态，新模型接入时老模型不能立刻下线，要保留一段切换窗口，线上出异常时可以快速回退。

关于推理服务的高可用，有三个容易被忽略的细节。第一是并发上限，大模型推理非常吃显存，服务副本数和GPU资源必须提前配置清楚，否则冷启动时资源竞争很容易把集群打崩。第二是动态批处理，在线推理应该把同一时间段内的请求合并成一个批次，吞吐量能提升好几倍。我们在网关层设置了最大批次大小和最大等待时间两个参数之后，实测推理吞吐提升了将近一倍。第三是冷启动探针，推理服务启动时需要加载模型权重，比较慢，如果健康检查配置得不合理，服务会被反复杀掉重建，永远起不来。

4.2 灰度发布策略与自动回滚

模型上线不能一刀切。我们采用金丝雀发布方式，新模型先接百分之一的流量，观察一段时间，再逐步提升到百分之十、百分之三十、百分之五十，最后全量。每一步切换之间留有观察窗口，短则一小时，长则一天，具体看模型本身的风险等级。

灰度为什么必须做？因为离线评估和影子部署虽然覆盖了真实请求，但覆盖不到完整的线上交互链路。模型输出要经过后处理、提示词拼装、多轮对话上下文管理，这些链路中的问题和模型纯质量问题不是一回事。只有真实流量在完整链路上跑过一遍，问题才会暴露出来。

流水线里还设置了自动回滚逻辑。回滚触发条件主要看三类信号：服务错误率超阈值、P95延迟超阈值、监控看板被人工标记异常。一旦触发，网关自动把流量切回上一个稳定版本，同时记录回滚原因。回滚能力一定要在灰度阶段之前就准备好，而不是等人肉去改配置，等反应过来的时候用户已经受影响很久了。

关于模型回滚，这里想提醒一个特别重要的情况：模型回滚不只是切换模型版本，很多情况下还涉及向量库、缓存、会话状态的兼容性。如果新模型改了Embedding计算方式，新模型写入的向量，旧模型部署时可能读不了，表现的后果就是线上答案质量莫名下降。所以每次模型发布前，部署清单里都要检查关联组件变更。凡是改了Embedding，发布计划就必须包含向量库重建或者双写方案，否则回滚本身就是一次事故。

4.3 一套部署流水线的配置参考

下面是我们部署流水线的大致阶段结构，你可以参考，具体阶段和参数根据自己的场景调整。

1. 从模型注册表拉取模型版本信息和制品
2. 构建推理镜像，包含模型文件、Tokenizer、推理代码
3. 推送镜像到制品仓库，跑安全扫描
4. 生成Kubernetes部署清单，指定镜像版本、GPU资源、副本数
5. 部署到灰度环境，先接入1%流量
6. 运行健康检查，观察延迟、错误率、吞吐指标
7. 分步提升流量比例，每步都有观察窗口
8. 全量切换后保留上一个版本服务二十四小时
9. 确认稳定后清理旧版本服务

流水线里一定要有人工确认的步骤，不能全自动化。模型质量有很多问题是无法用指标预判的，留一个环节让人去看评估报告和灰度表现，点击确认后流水线才继续。全自动听起来很高效，但在大模型发布这个场景里，保留人类判断反而是更可靠的做法。

5. 线上监控驱动再训练：持续迭代的真正引擎

5.1 不只盯延迟和QPS，更要盯质量指标

线上监控是模型应用持续迭代闭环里最容易被忽视的环节。很多人觉得模型上线就结束了，其实上线那一刻，真正的“使用后验证”才刚刚开始。

基础层面的监控大家都懂：CPU、内存、GPU利用率、推理延迟、QPS、错误率。但大模型应用要稳定迭代，还得多盯几个业务质量层的信号。

第一个是输出质量信号，例如用户点踩率、举报率、重问率、投诉率。这些信号能直接反映模型在真实环境中的表现。第二个是输入特征分布，统计用户请求长度分布、关键词频率、意图类别占比。一旦输入分布和训练数据分布发生明显偏移，说明数据漂移已经开始影响模型效果了。第三个是模型置信度变化，对分类和检索任务来说，置信度均值持续下滑往往也是模型退化的早期信号。

这些监控数据要汇总到同一个看板上，并且和流水线打通。日活、任务成功率、安全拦截率、异常比例出现异常时自动触发告警，通知到值班人。这里我建议按分位数来观察，不要只盯平均值。大模型场景很容易出现整体平均值正常，但P99用户已经被糟糕体验折磨半天的情况。

还有一个容易被忽视的细节：监控配置要在模型发布前就检查一遍。我们曾经上线次日才发现新模型的监控项没有配置完整，错失了一整天的异常观察窗口。

5.2 数据回流与标注闭环

持续迭代离不开新数据，没有数据的闭环，所有自动化最终都会变成死水一潭。

我们设计了完整的数据回流链路。线上产生的负样本，包括用户点踩、举报、安全系统拦截的正经请求、人工修正过的回答，都会自动进入一个待标注池。每周会对标注池按优先级处理一轮，标注完成后经过质量审核，进入下一个训练周期的新数据集。正样本同样会回流，但会做去重和去噪，防止少数重复反馈把模型带偏。

这个闭环是整个持续迭代链路里最值钱的部分。训练、评估、部署的方法都可以从公开资料学到，但数据回流是模型团队自己积累出来的业务财富。把回流机制跑顺之后，每一轮新训练用的数据都比上一轮更接近真实业务，模型能力的增长才有持续动力。

5.3 持续训练的触发节奏

理论上最理想的状态是数据一更新就自动触发训练、评估、部署。但在成本约束下，强制全自动并不是一个聪明的选择。

我们用的是计划训练加手动触发混合模式。计划任务每两周自动触发一次周期训练，用来吸收常规数据回流的积累。手动触发则用于重大数据更新或者紧急安全修复。每一次训练都必须过完整的评估门禁，不存在跳过评估直接上线的例外，最多是根据场景微调评估严格度。比如紧急修复时只跑红线样本和核心回归集，而正常迭代必须跑全量评估。

另外想特别强调一点：持续训练习惯不等于每个模型都要发布。评估之后发现新模型并没有明显优于线上版本，该放弃就放弃，该调整数据配比再来一轮就再来一轮。训练行为可以很频繁，但发布决策必须谨慎。把这两件事拆开之后，团队压力小很多，线上稳定性也明显提升。

6. 落地过程中踩过的五个典型坑

6.1 评估集被新数据污染，指标虚高一截

这个坑我们踩得最早，也最隐蔽。评估数据集原本是从历史数据里抽出来的一份独立集合，后来做数据回流时，新样本被顺手加进了评估集。结果新模型的评估指标一下子变得非常好看，上线之后在真实场景里却表现平平。排查了很久才发现，评估集和训练集存在重叠，评估分数被污染了。

现在我们强制规定：评估集只允许每季度按固定流程更新一次，更新时必须检查与近期训练数据集的相似度，重叠率超标就拒绝更新。这条检查项被写进流水线，每次评估前先跑数据签名校验。

6.2 模型版本和代码版本错位，推理行为无法解释

有段时间我们同时开了好几个实验分支，不同分支有不同Prompt处理逻辑，模型的推理行为表现得很奇怪。排查下来发现，有些分支的模型文件是用旧代码训练的，部署时却配了新代码的Tokenizer和推理逻辑，输出质量自然乱七八糟。

从那以后，每个模型版本必须绑定源码仓库的Git提交号。训练环境、评估环境、推理环境的代码保持一致。模型文件本身只存权重，关联的代码版本全部进注册表。这个改动增加了部署时的校验步骤，但省下来的是大量排查问题的时间。

6.3 回滚时才发现向量库和模型不匹配

一次涉及Embedding升级的模型发布，灰度过程中线上质量下降明显，我们紧急回滚。结果回滚之后问题依旧，甚至更严重了。最后定位到的原因很扎心：新模型已经用新的Embedding把一部分用户请求写进了向量库，回滚到旧模型后，旧模型读不懂这些向量的语义，检索质量反而变差了。

这次事故之后，我们把“Embedding版本与向量库同步”列为发布检查固定项。凡是改动Embedding模型的发布单，必须附上向量库重建或双写兼容方案，没有这个方案，流水线不允许进入部署阶段。

6.4 灰度流量比例太小，问题要到全量后才暴露

我们一开始做灰度，流量切到1%就停下观察。1%看起来安全，但在流量足够大的业务里，1%的流量覆盖不了多少长尾场景。有一次新模型在低频用户群里表现极差，因为流量占比太小，整体统计指标毫无波动，直到全量之后才被用户集中投诉。

后来调整了灰度策略：流量比例只是一个维度，另外还会针对核心用户类型做定向灰度。例如先让一定比例的新用户、高活跃用户、复杂任务用户进入新模型，确保关键子群体在灰度阶段就被覆盖到。

6.5 多个训练任务抢占GPU，线上服务直接被打崩

还有一次，我们同时跑了几个训练和评估任务，加上线上推理服务，集群GPU资源紧张，训练任务和推理服务开始抢资源，推理延迟飙升。资源配置上没有做好优先级隔离，最后线上体验受损。

那次之后做了严格调整。线上推理服务有保留额度，灰度服务中等，批量训练最低。训练任务随时可以被挂起或抢占，低优先级任务在高优先级任务需要资源时主动让路。训练流水线还必须支持断点续跑，挂起后被重新调度，能够从最近一阶段继续，而不是从零开始。

最后再分享一个经验。CI/CD这套体系，做成什么样并不取决于用了多少高级工具，而是取决于数据、代码、模型产物的关联性有没有被完整记录。训练、评估、部署、监控四个环节能拧成一股绳，靠的是每时每刻都能回答：当前线上运行的模型是什么版本，它由什么代码和数据产生，评估结果是什么。把这几个问题的答案变成流水线里的强制记录，大模型应用的持续迭代才算真正闭环。这套实践我们迭代了多个版本，每一次改进都是在踩坑之后完成的，希望你能少踩几个。