一、一条链路上的七个环节

（一）数据采集与清洗

数据环节最容易被低估。采集时要记录来源、时间、采集方式，清洗时要记录过滤规则与丢弃量。这些元信息不记，后面出问题时无从查起。清洗规则本身也要版本化，同一份原始数据用不同规则洗出来的结果，必须能区分开。

（二）标注与版本管理

标注要记录标注人、标注时间、标注规范版本。规范变更时，历史标注是否重标要提前定规则。数据版本用内容指纹或递增编号标识，训练时把用到的数据版本写进实验记录，这是结果可复现的前提。

二、训练环节的关键动作

（一）预训练与微调的区别

预训练是从零学通用能力，算力消耗大，多数团队不会自己做；微调是在已有底座上适配特定任务，消耗小得多，是日常主力。两者对数据的要求不同：预训练看数据规模与覆盖度，微调看数据质量与任务匹配度。

（二）检查点与续跑

长时间训练必须保存检查点，间隔按单次可承受的损失时间定，一般几小时保存一次。有了检查点，中断之后可以从最近的节点继续，不用从头再来。检查点本身占空间，要配清理策略，只保留最近若干个和效果最好的几个。

三、评测环节常被省略

（一）自动指标与人工评测

自动指标跑得快、可对比，但和真实体验之间总有偏差。人工评测慢、贵，却是最终依据。可行做法是两者结合：用自动指标做日常筛选，人工评测按周或按版本做抽样，抽样结果反过来校准自动指标的阈值。

（二）回归集的作用

回归集是一组固定不变、覆盖典型场景与历史问题的样本，每次改动之后都跑一遍。它能挡住改好了一处又弄坏了另一处的情况。回归集要持续维护，线上发现的新问题及时补进去，否则会逐渐失效。

四、部署环节的接口设计

（一）灰度发布与回滚

新版本先放一小部分流量，观察指标无异常再逐步放大。回滚方案要在发布前就准备好，包括旧版本的镜像、配置和路由规则，做到出问题时几分钟内切回。灰度期间要能按版本分开统计指标，否则看不出差异。

（二）多版本并存

业务上常需要新旧版本并存一段时间：一部分场景用旧版本，一部分用新版本。接口设计上要把版本标识作为必填参数，路由层按标识分发。并存期间资源占用会上升，配额要提前留出来。

五、上线之后的监控

（一）输入分布漂移

上线之后，用户输入的分布会随业务变化慢慢偏移，模型效果随之下降，这种衰减往往悄无声息。做法是对输入做定期抽样统计，和训练时的分布对比，差异超过阈值就触发复检。

（二）成本与响应时延

成本和时延是上线后最直观的两个运营指标。按任务类型分别统计，能看出哪类任务的单位成本在上升、哪类任务的时延在恶化。天翼云数据库适合承接这类长期指标存储，方便按周、按月做趋势对比。

六、平台化的收益与代价

（一）统一元数据带来的好处

1. 追溯链条

数据版本、训练参数、评测结果、部署版本串成一条线，任何一个结果都能追溯到源头。

2. 定位时间

出问题时定位时间从几天缩短到几小时，这个价值在团队规模变大之后尤其明显。

3. 协作成本

元数据打通之后，跨团队协作的沟通成本也会下降，因为大家对着同一份记录说话。

（二）哪些环节仍然需要人工把关

① 数据质量的最终判断由人来做，规则只能筛出明显的坏样本。

② 评测集的更新需要业务方参与，纯技术视角选不出真正重要的场景。

③ 上线审批保留人工环节，自动化的应该是检查项，不是决策。

平台把重复劳动接过去了，判断仍然留在人手里，这个边界不要模糊。

环节之间的交接清单要写清楚交付物和验收标准，只说做完不说明做成什么样，等于没有交接。

实验记录建议直接填写数据版本和参数摘要两项，缺一项就不允许进入训练，这个约束能挡住大部分复现问题。

平台建设可以分阶段推进，先把数据版本和实验记录打通，再谈自动评测和自动部署。

七、常见问题的处理方式

（一）训练结果无法复现

多数情况是数据版本或随机种子没记全。把这两项设为必填，并在训练开始时打印到日志，能挡住大部分复现类问题。

（二）评测结果与体感不符

自动指标上升但用户反馈变差，通常是评测集与真实分布脱节。把线上抽样数据定期补充进评测集，能缓解这个偏差。

（三）部署之后效果下降

上线后效果不如离线评测，常见原因是输入预处理不一致。把预处理逻辑做成同一个模块，训练与线上共用，是最彻底的办法。

（四）排队拖慢迭代

团队共用一批资源时，迭代速度会被排队拖住。给关键实验留一份保障额度，能明显改善整体节奏。

（五）模型体积带来的部署难题

模型越大，部署与扩容越慢。可以在允许的范围内做量化或裁剪，换来更快的启动速度，具体取舍要看时延要求。

（六）跨团队协作的接口约定

跨团队协作时，接口和数据格式要写成文档并冻结版本，改动走评审。口头约定在人员变动之后最容易出问题。

八、推进顺序上的建议

（一）先打通数据与实验记录

最优先做的是数据版本和实验记录，投入不大但收益最直接。这一步做完，复现问题基本消失。

（二）再补自动评测

第二步做自动评测与回归集，让每次改动都有可对比的数字。没有这一步，改动只能凭感觉判断好坏。

（三）最后做自动部署与监控

自动部署和监控放在最后，因为前两步稳定之后，部署的改动频率才会降下来，自动化的收益才体现得出来。

（四）每一步都留人工确认

自动化推进时保留人工确认点，尤其是数据变更和上线发布两处。确认点不是效率负担，而是出事时能及时止损的地方。

（五）成本的分摊办法

链路打通之后，资源消耗可以按项目归集，让每个项目看到自己的真实开销。分摊规则要简单，复杂的规则没人愿意去算。

（六）文档与交接

每个环节留一份简短文档，说明输入、输出和常见问题。文档不在长，在于有人愿意看、能照着做。

（七）数据变更设固定窗口

数据变更是链路里风险最高的动作，建议设一个变更窗口，比如每周固定一个时段集中处理，其余时间只做只读操作。

（八）每个环节都要能单独重跑

链路上的每个环节都要能单独重跑，重跑的入口要统一。能做到这一点，出问题时就不用从头走一遍，排查时间能短很多。

结语：全链路平台解决的不是某个环节的技术难题，而是环节之间的交接损耗。数据版本、实验记录、评测结果、部署版本串起来之后，团队才有条件谈复现和迭代。需要注意的是，自动化覆盖的是流程，判断仍要人来做，这条边界守住了，平台才不会变成新的黑盒。