一、确认范围先问三句话

1. 这个环节谁做

要问到具体角色，不能停在单位层面。「数据清洗由服务方负责」这句话背后要接着问：谁提供原始数据、谁定清洗规则、谁执行、谁验收。四个动作可以分属不同方，不写清就会出现四不管。

一个实用的判据是：凡是需要本单位业务知识才能判断的环节，通常仍在需求方；凡是需要算力与工程经验的环节，通常可以交出去。这条判据能快速划出大致的分界。

2. 交出什么

每个环节要有一个可检查的交付件。数据环节交的是数据集与数据说明；训练环节交的是权重、训练配置与训练日志；评测环节交的是题集与结果表；上线环节交的是服务地址、接口说明与监控看板。交付件不明确的环节，验收一定含糊。

交付件还要写形态：是文件、是记录、还是一份报告。同样叫数据说明，一份五行字与一份带统计口径的表格，作用差很远。

3. 做不到怎么办

这是容易被跳过的一问。精度没达标怎么办、工期延后怎么算、上线后效果衰减谁负责、资源不足谁补。这些都要在合作前有说法，否则每一次偏差都要重新协商。

可行的写法是给每个环节定一条退出条件：什么情况下继续投入、什么情况下停下来改方案、什么情况下认定不成立。有退出条件的项目，反而更容易做成。

二、数据环节：从接入到可训练

1. 接入与解析

服务方通常能承接多源数据接入，覆盖文本、图像、音频等形态。需求方要做的是把来源、格式、体量、更新频率讲清，并确认解析能力覆盖自己的格式。

扫描件与表格类文档是常出问题的地方：前者要看有没有文字层，后者要看表格结构能否还原。这两类解析不了，后面的清洗与训练都无从谈起。

2. 清洗、去重、脱敏、标注

这四件事经常被打包成一句「数据处理」，实际差异很大。清洗是按规则剔无效内容；去重是找出重复与近似重复；脱敏是处理个人信息与敏感字段；标注是给样本打上答案或标签。

其中标注的分量偏重，也容易出边界争议。多数服务说明里会明确：标注属于劳务外包性质的工作，服务方提供方案设计与指导，不代做采集与标注。这一条要在确认单里单独列出，别默认包含。

3. 数据集管理与版本

合格的做法是把数据集做成带版本、带权限、带说明的资产：每个版本对应一次训练，旧版本保留可回溯，权限按角色分。

没有版本管理，两个月后会出现「这批结果用的是哪份数据」说不清的情况。这一条要在确认单里作为数据环节的交付件之一。

4. 这一环的验收

抽一百条真实样本，检查解析是否完整、清洗是否按规则执行、标注抽检是否符合预期、数据集说明是否覆盖字段含义与统计口径。四项过关，数据环节才算交付。

三、训练与微调环节：从基座选择到效果可用

1. 基座选择与方案设计

这一环的产出是一份方案：选哪个基座、用什么训练方式、显存与卡数怎么配、预计训练多久。方案里尤其该写清的是不适用的场景，也就是这个方案在什么情况下会失效。

需求方要参与的部分是业务判断：模型要答什么、不能答什么、什么算答对。这部分交不出去，也不能交出去。

2. 训练方式的选择

全参数训练、增量训练、只训练少量参数的微调，三种方式的投入与效果差别很大。多数业务落地走第三种，成本可控、周期短；需要改变模型能力结构时才考虑前两种。

范围确认时要写明训练方式，因为这直接决定卡数与工期。写「视情况而定」的方案，工期一定会超。

3. 并行与容错

规模上去之后，分布式并行与断点续训属于必备能力。要确认三件事：单卡故障会不会拖垮整个任务、能否从近一个检查点恢复、恢复一次大概多久。

长周期任务尤其要把这条问清。没验过续训的配置，第一次真中断时往往发现存不出检查点，几天的算力就白花了。

4. 这一环的验收

验收看四件事：方案里的训练方式与实际执行一致；权重、配置、日志三样齐全；在固定题集上的指标达到方案约定；中断一次能恢复且指标接得上。

四、评测环节：容易被漏掉的一段

1. 题集谁出

评测题集要么由需求方出，要么由双方共同出。全交给服务方出的风险是题集与训练数据同源，指标好看而实际不好用。

稳妥的做法是三类题并存：业务真实问题、边界问题、故意设的陷阱题。三类各占一定比例，指标才有区分度。

2. 口径谁定

判断题怎么算对、部分正确怎么计分、拒答算对还是算错，这些规则要在评测前定。口径不同，同一份结果能差出十几个百分点。

可行的做法是把判定规则写成一张表，逐条列出情形与得分。表定下来之后再跑，结果才有可比性。

3. 谁来判

自动判分适合有标准答案的题，主观题要靠人。人的部分要定人数与仲裁规则，防止一个人说了算。

4. 这一环的验收

验收看三件事：题集来源与构成写清；判定规则成表；结果表能按题逐条回溯到原始输出，而不是只给一个总分。

五、部署上线环节：从权重到能被业务调用

1. 部署形态

同一份权重可以部署在多种形态上：共享环境、专有环境、本地设备。三种形态在隔离程度、运维责任、投入上差别很大。确认单里要写清选哪一种，以及谁负责部署。

隔离要求高的场景，部署方式还要确认能不能离线、能不能只走受控通道更新。

2. 性能目标

上线不是把服务拉起来就完事，要有一个明确的目标：在多少并发下、首字时延与整体时延控制在什么区间、错误率不超过多少。目标要能被压测验证，不能只写「响应快」。

3. 灰度与版本管理

新版本上线要能灰度：先切小比例流量、观察指标、再逐步放量，同时保留回退能力。这一条要写进范围，否则第一次换版本就会出事故。

4. 与业务系统对接

接口对接常被默认由需求方做。实际上多数服务说明里只承诺指导对接，业务系统本身的开发与维护不在范围内。这一条要单独确认，否则上线卡在收尾一步。

5. 这一环的验收

验收看四件事：目标并发下时延与错误率达到约定；灰度与回退演练过一次；接口说明完整可用；监控看板能看到调用量、时延、错误率三项。

六、运维迭代环节：上线之后谁负责

1. 监控与告警

要确认三件事：监控指标有哪些、告警发给谁、值班时段多长。三项不写清，出了故障会互相等。

2. 效果衰减的处理

上线一段时间后效果会衰减，常见原因是业务数据分布变了。要约定复查频率与处理方式：是重新训练、补数据，还是调提示与参数。

3. 迭代的责任划分

模型更新、参数调整、能力扩展，哪些包含在服务内、哪些需要另立项目，要在确认单里写明。含糊的说法会在第一次迭代时引发争议。

4. 这一环的验收

验收看三件事：告警实际触发过一次并有人处理；效果复查做过一轮并留下记录；迭代动作的责任方明确。

七、把范围写成一页确认单

1. 常见的不覆盖项先列出来

一是数据采集与标注的劳务工作，通常只给方案与指导；二是需求方自有业务系统的开发与维护；三是第三方组件的架构设计；四是超出约定工时的加急工作；五是兼容清单之外模型的部署。五项先摆上桌，能省掉大量后续解释。

2. 确认单的六列

第一列环节名，第二列谁做，第三列交出什么，第四列验收办法，第五列不在范围内的事项，第六列偏差处理。六列填满，一页足够。

填的时候只写可核对的内容。「提供技术支持」这种表述要换成「在什么时段、以什么方式、多长时间内响应」。

3. 签字前做一次反向测试

拿确认单去问三个具体场景：数据只有扫描件怎么办、精度没达标怎么办、上线后告警没人接怎么办。三个场景都能在单子上找到答案，这份单子才可用。

结语

确认服务范围，本质是把每个环节的四件事说清：谁做、交出什么、怎么验收、做不到怎么办。数据、训练、评测、上线、运维五段里，评测与运维容易被漏，而它们恰恰决定项目能不能真正用起来。

落地建议：先按六列把确认单填一遍，填不出来的格子就是要谈的地方；再拿三个具体场景做反向测试；末了把不覆盖项单独抄一页附在后面。判断范围是否确认到位，有个很实际的标准：项目进行到一半时，双方对「这一步该谁做」没有出现过分歧。