负责人 何建力　·　状态 定稿　·　覆盖 27 个标书单元　·　 批注 4

数据集加工生产专项智能工具链按招标文件 3.2.3 节的要求建设：交付 9 类 25 个专项智能工具链，每个工具链满足其所属类别在 3.2.3.2 至 3.2.3.10 各节的功能与质量验收要求，并统一满足 3.2.3.11 节的通用接口、追溯与验收要求（b0915、b0917、b1146）。

25 个工具不是 25 个各自独立的程序，它们共用一套公共服务。统一任务编排层承担作业的受理、参数校验、调度、暂停与恢复、重试、取消、质量检查节点判定与结果发布（质量检查节点指设置在数据生产流程中的检查环节，依据质量规则判断数据是否符合进入后续工序或交付的条件，未通过不放行）；统一数据契约层承担字段模式、版本标识、内容指纹与血缘字段；统一评测回路承担质量判断的产生与回流；统一人工介入通道承担判定权的行使与留痕；统一模型网关是外部模型调用的唯一出口。招标文件 3.2.3.11 节要求的接口、数据格式、血缘、质量、安全与验收六项共同行为由公共服务实现，各工具只实现自身的业务算子。公共服务与 25 个工具同步版本管理，一并承载在为招标方建设的天地奔牛煤机装备数据智能平台（以下简称奔牛数据智能平台）之上。

各工具链的功能设计、处理流程与配置样例按类别分列：数据构建类见工具链（一），对齐与标注类见工具链（二），质量与验证类见工具链（三）。

1、智能工具链交付清单

1.1 交付构成

我方交付 9 类 25 个专项智能工具链，类别划分与工具名称与招标文件表列逐项一致（b0918r01—b0918r10），不合并、不改名、不以相近功能顶替。每个工具链满足其所属类别在 3.2.3.2 至 3.2.3.10 各节的功能与质量验收要求，并满足 3.2.3.11 节的通用接口、追溯与验收要求（b0917）。

表 1-1 是完整交付清单。表中「核心输入」与「核心产出」两列给出该工具在生产线上的接口形态，读表即可判断谁产数据、谁消费数据；「详述位置」列指向该工具功能设计所在的章节。逐工具的业务目的、源对象、输入输出格式、核心处理规则、运行依赖、调用权限、交付形态与验收证据在 1.2 至 1.4 逐项给出，交付范围与招标要求的对照在 1.5 给出。

表 1-1　9 类 25 个专项智能工具链交付清单（b0917、b0918r01—b0918r10）

凡涉及大模型调用的环节，一律经平台统一模型网关接入。网关侧采用当期能力评测领先的通用大模型，可替换、可评测、可随代升级。样本与血缘记录中只登记网关侧为该模型分配的标识与版本号，不绑定具体型号，模型换代后存量样本的血缘记录保持可追溯。

1.2 逐工具的业务目的、源对象与输入输出格式

每个工具的业务目的回答「它替现场解决哪一件事」，源对象回答「它从甲方的哪一类实物或记录取数」，输入输出格式回答「它在流水线上以什么形态接料与出货」。三者合起来即一个工具的对外规格，验收时按此核对，不按工具内部结构核对。格式名称按 3.2.3.11 节第（2）条的五种格式写法，输出的落盘格式随产物性质选定而非一律取同一种。

表 1-2　25 个工具的业务目的、源对象与输入输出格式

表 1-2　数据来源：业务目的与源对象依招标文件第五章 3.2.3.2 至 3.2.3.10 各节的工具功能要求与甲方现场数据形态；格式取值依 3.2.3.11 节第（2）条的五种格式。

1.3 逐工具的核心处理规则、运行依赖与调用权限

核心处理规则一列写的是该工具据以判断的办法，不是实现细节：凡能用确定性计算判定的一律用计算判定，模型只用在确定性办法覆盖不到的地方。运行依赖一列写的是该工具跑起来必须先有的外部条件，它同时是分批投产排序的依据。

调用权限按角色与数据域两个维度授予。角色有六类：加工作业岗提交与查看加工任务；标注管理岗提交标注与复核类任务并管理标注工位；质量管理岗提交质检、去重、分布与报告类任务；评测管理岗管理基准集与评测作业；裁决岗处理不一致裁决；安全审计岗对血缘与审计记录只读查询并审批敏感导出。数据域按供需计划、工艺设计、制造过程、质量四域分别授权，另按敏感级叠加一层授权；越域或越级的调用在编排层拒绝并记一条审计。规则库、模板库、阈值与门限的变更不属任何岗位的日常权限，一律走策略会签。

表 1-3　25 个工具的核心处理规则、运行依赖与调用权限

表 1-3　数据来源：处理规则依招标文件第五章 3.2.3.2 至 3.2.3.10 各节的功能要求；权限维度依 3.2.3.11 节第（5）条的授权校验与访问控制要求。

1.4 逐工具的交付形态与验收证据

25 个工具的交付形态有统一的部分与专有的部分。统一的部分是：算子实现、参数配置模板、接口说明、演示样例、输入输出样例与测试报告，即 3.2.3.11 节第（6）条要求的五件套加算子本体，按工具逐个提供，9 类 25 个共 25 套；每个工具在平台内可独立调用、可独立验收，不以「同属一个模块」为由合并验收。专有的部分是该工具随身带的规则与资产，它们决定了这个工具是否贴合矿装现场——离开这些资产，工具只剩通用能力。

验收证据一列写的是测试报告中必须含有实测记录的项。凡列为实测项的，验收时核对的是记录而非说明；指标值按本章 8.1 的基线、趋向、回退三段给出，具体数值在各工具的功能设计中逐项列明。

表 1-4　25 个工具的专有交付资产与验收证据

表 1-4　数据来源：交付形态依招标文件第五章 3.2.3.11 节第（6）条验收要求；实测项依各工具所属类别的质量验收要求。

1.5 交付范围、部署许可、可用节点与外部服务边界

工具链承载在奔牛数据智能平台上运行，这是运行形态，不是交付范围的缩减：招标文件要求的 25 个工具链的能力、接口与授权逐项交付，不因它们运行在平台之内而减少任何一项。表 1-5 按招标要求逐条对照，列明我方交付什么、可在哪些节点使用、授权到什么程度、哪一处是外部服务边界。

表 1-5　交付范围与招标要求的逐项对照

表 1-5　数据来源：对照项与要求列依招标文件第五章 3.2.3 节及 3.2.3.11 节原文；部署与授权口径为本方案承诺，随甲方环境确认后细化。

2、九类工具的分组与数据流向

甲方是矿山装备制造企业，产品为刮板输送机一类煤机装备。数据不缺体量，缺的是可用形态。板材备料共 28 道工序，历史工艺样本约 63 万张；每张图纸都配有一份已审核签发的工艺卡片，但这份配对关系落在文件目录和经手人的记忆里，不在任何系统字段中。设备运行的时序信号已采到秒级，却与具体工件、炉次、焊道对不上稳定主键。工单、检验结论、不合格品票与改造方案多为自然语言，表述自由、口径不一。

要把这些数据做成可训练、可评测的行业大模型数据集，须解决四件事：样本对不上、缺可用标签、规模不够且分布不均、结果不可验证。9 类 25 个专项智能工具链即按这四类缺口配置（b0915），在数据加工主线上分为三组工段。

三组工段的构成与产出如下，九类工具不是九个并列产品：

数据构建组（第 1—3 类，工具 1—8）把文本与文档变成样本。思维链构建解决推理过程不可见的问题，长上下文数据构建解决长文档不能整体入样的问题，多轮对话数据构建解决业务交互过程无样本的问题。这一组的输入是清洗后的语料与结构化业务记录，产出是推理样本、长上下文样本、检索增强三元组与多轮对话样本。

对齐与标注组（第 4—6 类，工具 9—18）把非文本载体接入主线并打上标签。多模态数据对齐解决「对不上」，智能标注解决「没标签」，数据生成与增强解决「不够与不均」（b0990、b1008、b1041）。这一组的产出是结构化图纸字段、图文与时序成对语料、标注结果与一致性指标、合成与增强样本。

质量与验证组（第 7—9 类，工具 19—25）对前两组的产出作判断，并用模型表现反向检验数据集。数据质量与分布控制判集合层面的重复、污染与形状，数据生成控制与评测管受控生成与切分冻结，数据集验证与归因用评测结果定位数据侧的问题（b1123）。这一组不生产数据，产出的是判断、证据与修订动作。

三组的关系是生产、把关、反馈。前两组构成生产链，第七、八类构成把关链，第九类构成反馈链：评测发现的错题经归因落回具体的标注批次、生成批次或覆盖盲区，转成修订工单回到生产链。该反馈回路使工具链可在建设期内持续修订提质，而非一次性加工。

图 2-1　九类二十五个工具在数据加工主线上的分组与数据流向

图 2-1　九类二十五个工具在数据加工主线上的分组与数据流向。实线为样本与数据集的正向流动，虚线为由评测与质量判断驱动的反向修订。数据来源：招标文件第五章 3.2.3.1 节工具链清单（b0918r01—b0918r10）、3.2.3.10 节验证与归因要求（b1123）；数据集规模取投标文件统一口径。

3、九类工具之间的供需关系与衔接口径

25 个工具的清单本身不构成一条生产线，把它们串起来的是数据供需关系与衔接口径：谁产的数据谁消费、在类的边界上以什么口径交接、同一个数据对象在整条链上靠什么保持同一个身份。

3.1 三条主干数据流

九类工具的产出与消费关系可归为三条主干。

文档线从技术手册、规程、标准与工艺文件出发。文档结构解析（工具 5）先把版面还原成章节树与结构化段落，切分与拼接（工具 3）据此产出长上下文样本与来源映射表，RAG 数据构建（工具 4）在同一份片段上建索引并产出查询—上下文—回答三元组。三元组一旦可用，就成为思维链自生成（工具 1）与对话模拟生成（工具 6）的背景材料来源——这两个工具不凭空生成内容，而是在检索到的材料上组织推理与对话。文档线的末端是长上下文语料进预训练数据集、三元组经格式转换进指令微调数据集。

多模态线从图纸、工艺卡片、过程视频与测点时序出发。图纸与工艺图结构化抽取（工具 9）把几何与符号抽成字段，视频—文本对齐（工具 10）把关键帧挂到设备运行事件与工艺阶段的时间轴上，时序—事件对齐（工具 11）把时序片段切到报警与维修工单的时间窗里。这三者的产出有两个去向：一是进智能标注类（工具 12—15）获得标签，二是作为素材进生成与增强类（工具 16—18）扩充样本量。多模态线解决的是「对不上」，它的产出质量决定了后续标注与生成的上限——对齐错误的素材标得再细也是错的。

合成线从种子素材与规则出发。指令数据生成（工具 16）按任务类型与难度层次扩充指令样本，工单与故障场景模拟生成（工具 17）按本体与历史工单分布构造长尾场景，文本重写与多样化（工具 18）在语义与事实不变的前提下产出多种表达，模板化数据生成（工具 21）在强约束下产出结构化合成样本。合成线的四个工具都受两道约束：配比上限由分布分析（工具 20）在生成前派发，合成标记随样本留存，评测集构造按该标记排除合成样本。

三条主干都汇入把关链。去重与相似度过滤（工具 19）是全部候选样本的第一道闸——重复在候选池建立的第一天就存在，污染的后果最严重，基准集一旦被污染且未被发现，后续全部评测结论不可用。分布分析与均衡（工具 20）在洁净集上看形状，长尾与盲区的识别结果转成补齐需求单回到标注与生成环节。切分与基准构建（工具 22）在洁净集上做三层切分并冻结基准集，这是训练与评测得以分离的前提。

反馈链由第九类承担。评测引擎（工具 23）在冻结基准集上按协议跑出模型表现，归因与错题溯源（工具 24）把错题关联到训练样本、数据来源、标注批次、生成批次、质量问题或知识覆盖盲区六类原因，并生成修订工单；血缘追溯（工具 25）提供从样本到数据集版本到训练任务的链路，使上述关联可查可审。六类原因中前五类是数据错了，第六类是数据没有，两者的处置动作完全不同——把覆盖盲区误判为质量问题，结果是反复返工已有样本而问题不解。

图 3-1　九类工具之间的供需关系（谁产数据、谁消费数据）

图 3-1　九类工具之间的供需关系。实线为样本与数据集的供给方向，细虚线为公共层与统一标识服务的支撑关系，粗虚线为由把关链与反馈链发出的回流单据。数据来源：招标文件第五章 3.2.3.1 节工具链清单（b0918r01—b0918r10）、3.2.3.11 节通用要求（b1146—b1158）。

3.2 类间衔接的六个口径

类间关系能否真正接上，取决于六个口径是否事先约定。这六项都是在类的边界上发生的，不属于任何单个工具，因此集中在本章交代；各节在实现时引用本节，不另立定义。

关联键统一。九类工具在读写数据时一律通过统一对象标识服务换取内部主键，不直接用源系统的业务编码做关联键。原因在前文已说明：施工号、产品号、图号、零件号、物料编码、工单号、炉次号、焊缝与焊道编号、设备编码之间没有稳定的主键关系。映射缺失时返回明确的未命中状态而非空值，由调用方记为待补映射并进人工对账队列。该服务由数据治理体系交付，工具链是使用方；映射的登记项、有效期、合并拆分、历史回放与冲突裁决的口径见 3.3。

时间基准统一。时间一律以协调世界时存储、按 ISO 8601 格式带时区偏移表达，展示层转为北京时间。设备侧时钟漂移在多模态对齐两个工具中专门处理。

血缘字段统一。九类工具的每条输出记录携带同一组血缘与版本字段，字段名跨类保持一致，使一条样本从原始文件到对齐、标注、增强、去重、切分的全过程能用同一组键串起来。字段的写入由公共层在每个环节追加完成，不由各工具自填——血缘这类横向要求一旦依赖各工具自觉实现，缺失是必然的。

置信度与人工介入统一。工具输出按高、中、低三档置信度分流：高置信入候选集并按比例抽检，中置信进人工复核队列并由工具给出修改建议，低置信进人工标注队列、工具输出仅作参考。各工具只调阈值，不改分档逻辑；阈值由试点批次上的标定集定出，按季度复标并留记录。

合成样本标记统一。合成线四个工具的产出一律携带合成标记与不可用于评测集的标记，评测集构造按该标记排除。这一条是评测集隔离的落实手段：评测集一旦混入合成样本，评测的是生成规则而不是真实业务能力。

配置即代码。提示词模板、输出结构定义、本体版本、采样策略、相似度阈值、改写比例等全部可调项以配置文件形式入库并纳入版本管理，运行时按版本号加载。配合血缘字段，任何一批样本都能在原配置版本下重跑一遍并比对差异。这项能力在三种情形下是必需的：甲方对某批样本质量提出疑问时用于复现，模型随代升级后用于评估新旧差异，验收阶段用于抽样复算。

3.3 统一对象标识服务的使用口径

甲方的同一个实物，在不同系统里有不同的编码：一件中部槽在设计侧是图号加版次，在物料主数据里是物料编码，在制造执行系统里是工单号加零件号，在质检记录里是件号，在设备台账里又是设备编码。这些编码之间没有稳定的主键关系，它们的对应关系落在文件目录、经手人的记忆和若干张离线对照表里。九类工具在读写数据时一律通过统一对象标识服务换取内部主键，不直接用业务编码做关联键，也不各自维护一份私有对照表——私有对照表的后果是同一个对象在不同工具里得到不同的身份，而这种错在合并数据时才会暴露。

映射的登记项。 每一条映射登记源编码类别、源编码值、映射到的内部对象、映射基数、生效时点与失效时点、登记依据与登记批次。映射基数一项不可省：一对一、一对多、多对一三种基数对下游的影响完全不同，把一对多当成一对一处理，结果是样本被静默地挂到了其中一个候选上而没有任何记录。表 3-1 给出本项目涉及的主要源编码及其映射形态。

表 3-1　多源编码到内部主键的映射登记

有效期与历史回放。 每条映射带生效时点与失效时点，解析时须同时给出业务发生时点，服务按该时点所处的有效区间返回当时的映射结果。不带时点的解析按当前时点处理并在返回中标注，调用方据此判断该结果是否可用于历史样本。这条约定的用处在回放：一批两年前的工单样本，若按今天的映射重新解析，可能被挂到一个当时还不存在的对象上，而样本的血缘里不会显示这次改挂——历史回放因此一律按样本的业务发生时点解析，不按加工时点解析。

合并、拆分与改挂。 映射关系会变，变的方式有四种，处置各不相同，见表 3-2。四种变更一律以追加新映射记录加失效旧记录的方式实现，不就地修改原记录；存量样本不追溯重写，需要统一口径的统计按主对象聚合并在报告中注明聚合依据。

表 3-2　映射关系的四类变更与处置

映射冲突与人工裁决。 冲突分四类：一对多且候选同质（两条候选在业务上是同一件）、一对多且候选异质（两条候选确为不同对象，须补充信息才能定）、互斥映射（两条登记给出相反的归属）、时点越界（样本的业务发生时点落在所有有效区间之外）。四类冲突都不由工具自行消解，工具返回明确的冲突状态并挂起该批样本，冲突进人工对账队列。表 3-3 是一次一对多且候选同质冲突的完整裁决过程，这类冲突在物料主数据中最常见。

表 3-3　一次映射冲突的裁决实例

工具链一侧的调用约定有三条：不得绕过标识服务直接用业务编码关联；未命中与冲突一律按明确状态返回并挂起样本，不以空值或任选其一的方式继续；每批样本在血缘中登记本批解析所用的映射版本号，使日后能回答「这条样本当时是按哪一版映射挂上去的」。

3.4 四处需要特别约定的衔接点

还有四处衔接点，是本项目数据特性带来的，不作特别约定就会出错；各工具按下列约定调整自身配置。

思维链样本的去重口径。推理样本的推理步骤句式相近，字面相似度天然偏高，直接套用通用近重阈值会误删正确样本。约定是只比对问题与结论，不比对推理过程文本。

长上下文样本的切分隔离。同一份长文档的不同片段必须整份归入同一集合，否则测试集中的片段与训练集中的片段同源，等于泄漏。约定是按文档标识归集。

跨模态重复的判定范围。语义相似比对在同模态内进行，跨模态的关联取自多模态对齐类的对齐结果；对齐关系缺失的样本，跨模态重复不作判定并在报告中标注未检，不以未检冒充无重复。

增强批次的可定位性。增强前后的分布比对由分布分析工具执行，偏移超限时要回看增强参数。约定是生成与增强类工具的产出携带批次标识，使比对能定位到具体批次。

这四处的共同点是：把关链不改变上游的产出规范，而是按上游的数据特性调整自身配置；配置差异记入各数据集类型的配置档，不靠实施时临场判断。

3.5 四个数据领域的完整工具调用链

前面几节给的是类与类之间的关系。落到具体一批数据上，走的是一条确定的调用链：从哪一类源对象起，依次经过哪几个工具，每一道在样本上留下什么。本节按供需计划、工艺设计、制造过程、质量四个数据领域各给一条完整调用链。

四条链上贯穿始终的是五项标识。它们不是元数据里可有可无的附加字段，而是后续每一道判断所依据的东西：没有来源家族标识就判不出切分泄漏，没有许可标识就拦不住出域，没有质量标识就构造不出干净的评测集。五项标识的写入时点、取值来源与缺失处置见表 3-4。

表 3-4　五项随样本贯穿的标识

四条链共用同一套排法，三点需要先说明。其一，行按环排而不按工具编号排：同一个工具在四个域里进入的时点并不相同，按编号列只能看出用了哪几件工具，看不出谁先谁后、谁在等谁的产出，而实施期真正会出事的恰恰是顺序——图纸还没配上工艺卡就先做了切分，切出来的片段归不了族，后面的切分隔离与去重就全是空转。其二，每一环除了写调用哪个工具、处理什么、产出什么，还单列一列写五项标识在本环的变化。这一列是四张表的分量所在：一条样本走完十环之后能不能用、能不能进评测集、能不能出域，取决于这十次写入有没有一次漏掉；标识的变化是跨工具累积的，若改按工具分节各写一段，这一列就写不出来，读者也就无从判断一条样本的「身份」是在哪一步残缺的。其三，四条链的环数与环序各不相同，不强行对齐成同一个模板——各域的源对象形态差异很大，硬凑成同构的流程图只能靠含糊措辞达成，反而掩盖了真正需要注意的那一两环。

供需计划域的调用链。 这一域的数据体量最大，源对象以文本与结构化记录为主：合同与订单、物料主数据、库存流水、采购与供应商记录、销售预测，以及供应链相关的制度与流程文件。它看上去是四个域里最好做的一个，而这正是它容易做坏的原因。甲方的供需口径实际散在三处：制度与流程文件里写的是应当怎么做，业务系统里存的是实际怎么做了，两者之间的差异——哪些物料走过特采、哪一批采购绕开了常规周期、某个备货口径是哪一年改的——只留在经办人的记忆里，没有一个字段记录它。若把库存流水直接拉出来做成语料，模型学到的是流水的格式而不是备货的判断；若只把制度文件切成片段，模型能背出条款却答不出「这一批为什么这么备」。

因此这一域的链路不是清洗、切分、入库三步了事，而是先把制度还原成带章节层级的条款，再把条款与业务记录在检索层挂上，最后才在挂好的材料上组织推理样本——推理的每一步都要指得回某一条条款或某一条记录，指不回去的样本就是编出来的，它在训练集里的作用是反向的。这一域的十环因此以第 3 环的检索构建为分水岭：之前都在把两种形态的材料整理到可以互相指认的程度，之后才开始生产真正的样本。链路见表 3-5。

表 3-5　供需计划域的工具调用链

工艺设计域的调用链。 这一域的源对象以图纸与工艺文件为主：板材备料 28 道工序的工艺卡片、约 63 万张历史工艺样本、工艺规程与设计标准。这是本项目资产最厚的一处，也是麻烦最集中的一处。63 万张图纸每一张都配有一份已审核签发的工艺卡片，这是极有价值的成对资料——图是输入，卡是经验证的输出，正是训练所需要的形态；但这份配对关系落在文件目录的层级和经手人的记忆里，没有进入任何系统字段。于是第一道工序不是「识别图纸」，而是把图与卡重新配成对，并且要配得经得起核对：同一图号往往有多个版次，版次配错的图卡对看起来完全正常，错误要到模型答出一个过时的加工要求时才暴露，而那时已无从追查是哪一批配错了。

第二处麻烦是数值。展开长一类几何量若交给模型从图上「读」出来，读错了没有任何环节会发现——它读出的数字在格式上无可挑剔。所以这一域把事情拆开：模型只负责把图上的要素抽成字段，数值一律由确定性计算得出，再与图卡上的原值互校，不一致的进冲突清单而不是自动采信任何一方。第三处麻烦是标签体系本身：28 道工序目前没有一份正式的工序字典，标准名称、编码与分档规则散在各分厂的习惯里，因此第 3 环的规则标注必须等工序字典成文后才按本项目规则资产运行，在此之前按通用规则运行并在批次质量报告中标注其配置来源。链路见表 3-6，它与供需计划域的差别集中在第 1 环——入口是图纸而非文本，且几何量不经模型。

这条链要带走的结论是：63 万张图纸不等于 63 万条可训练样本，从一张扫描件到一条带血缘、可入评测集的样本之间有十道确定的工序，每一道都有承办工具、有留痕、有不合格时的去处。

表 3-6　工艺设计域的工具调用链

制造过程域的调用链。 这一域的源对象是时序、视频与过程记录：热处理炉次曲线、焊接参数流、熔池与热成像帧、制造执行系统的过程记录与工单。这一域的数据采得最密——信号已到秒级——却最难直接使用，原因是时间轴上的东西与业务对象之间没有稳定的主键。焊接参数流是连续的，而工件与焊道是离散的：一件大型部件的焊缝可达数百条，一条焊缝多层多道，参数流若对不上具体哪一道，这段曲线就既不能用于同型部件的横向比对，也不能作为任何缺陷结论的证据。热处理一侧是另一种错位：同炉可以混装不同零件，中途可以补炉，一条炉次曲线对应的工件集合本身就是变动的。现场测点还有第三种情形——损坏期间无数据，损坏后未必补装，同一台设备在不同时段可用的测点集合并不一致；若不记录这一点，后面的处理会把「没有采到」当成「运行正常」，这是一类很难在抽检中发现的错误，因为它的表现是数据干净得过分。

正因如此，这一域把对齐放在第 1、2 环，而不是像通常那样先清洗再对齐：对齐做不实，后面八环做得再细也是在错配的素材上做功，而错配样本与正确样本在库里长得一模一样，靠后续质检分辨不出来。表中这两环的标识变化一列比其他域多出两项——时钟校准记录与锚点可靠性分档、校准偏差与对齐校验结论——写进字段的用意在于：对齐是会错的，错了要能查出是哪一次校准、哪一段时钟漂移导致，而不是只留一个「已对齐」的状态位。安防视频的许可标识在第 2 环即按甲方安保口登记，也是同一个道理：涉及人员影像的素材，许可一旦漏登记，后续任何一次经网关的调用都是越界，而越界是不可撤回的。链路见表 3-7。

表 3-7　制造过程域的工具调用链

质量域的调用链。 这一域的源对象是检验记录、不合格品票、返修与改造方案、质量标准与判据。它的体量不大，价值密度却最高——每一张不合格品票背后都是一次真实的判定过程，这正是模型最难从公开资料里学到的东西。难处有两层。第一层是表述：工单、检验结论、不合格品票与改造方案多为自然语言，表述自由、口径不一，同一种缺陷在三个班组笔下可能是三种写法，不先做本体归一，统计出来的缺陷分布反映的是写法分布而不是质量分布。

第二层更隐蔽，是时间。一张三年前的不合格品票，它的判废结论在当时是正确的；若拿今天这一版标准去核，它会被判成错标。这类样本若被当作噪声清掉，清掉的恰恰是最有价值的那一批——它们记录的是真实判据下的真实判断。本方案的处置是把时间绑进字段：第 1 环解析标准与规程时条款保留版次，第 5 环的推理样本其判据引用必须指向具体条款与版次，第 8 环冻结基准题目时判据版次随题目一并冻结。最后这一条尤其要紧——基准题目引用了条款却不冻结版次，标准一改，题目的标准答案就在无人察觉时变了，而评测分数的下降会被误判成模型退步，进而引发一轮方向完全错误的调优。此外，票面上有经手人与检验员姓名，第 2 环即在写出前完成脱敏，脱敏后方可进入任何经网关的调用环节。链路见表 3-8。

这条链要带走的结论是：质量域的样本不是对错两分的标签数据，它的正确性永远绑定一个时点和一版判据；本方案把这个绑定做成了可核对的字段，而不是做成一段说明。

表 3-8　质量域的工具调用链

四条链的共同点有三条，它们是四个领域能共用一套底座而不重复建设的原因。第一，入口不同而出口相同：四条链都在第 8 至第 10 环汇入同一组把关与反馈工具，质量检查节点、切分规则与评测协议是同一套。第二，五项标识的写入时点一致，因此跨域合并时不需要再做一次对齐。第三，领域特性只体现在配置上——工艺设计域按图号族判同族、制造过程域按炉次族判同族、质量域按票据族判同族，判定逻辑是同一套，配置差异记在各域的配置档里。

4、工具链技术架构与公共服务设计

招标文件 3.2.3.11 节的六条要求约束的不是某一类工具，而是 25 个工具的共同行为（b1146）。接口、数据格式、血缘、质量、安全与验收六项一律实现在工具运行的公共层，条款的逐项实现——接口定义表、格式约定表、血缘字段表、通用质量指标表、安全管控设计与验收五件套口径——见工具链（三）。

4.1 公共服务设计

25 个工具若各自定义接口、各自决定输出格式、各自实现血缘记录，结果是 25 套用法与 25 种口径，集成成本与验收成本全部落在甲方身上。我方的做法是把六条通用要求实现在工具运行的公共层：工具只实现自己的业务算子，接口、格式、血缘、质量上报、安全管控与验收材料由公共层统一承担。公共层承载在奔牛数据智能平台之上，与 25 个工具同步版本管理。

这一安排有一个必须守住的时序：公共层必须先于任何加工批次上线。血缘的写入能力若不随第一批工具同时具备，早期加工的样本就没有血缘记录，而血缘是不能事后补回的——样本经过了哪些算子、用了哪一版规则与提示词，当时不记，日后无从还原。把血缘整体推到后期是常见的失误，代价是前期数据全部缺证。因此本方案把公共层列为第零批交付，其验收判据与工具批次同等对待（见本章第 6 节）。

4.2 六条通用要求的总体做法与归属

六条通用要求在招标文件里是六段并列的文字，很容易被当成六件可以分头办的事，各交一份设计了事。实际工程里它们是同一件事的六个侧面，而且是串在一根绳上的：接口不统一，输出格式就统一不了——每个工具按自己的习惯决定什么时候给 Markdown、什么时候给 CSV；格式不统一，血缘里的字段就对不齐，同一个「工具版本」在甲处是字符串、在乙处是整数；血缘对不齐，质量报告按批次、按来源、按任务类型、按数据集版本的四维汇总就做不出来，只能出一张总数表；汇总做不出来，验收就只能看文档不能看数据，招标方拿到的是 25 份各讲各话的测试报告。六条里只要有一条留给各工具自行其是，另外五条都会跟着松掉，而且松在何处要到集成期才看得见。

因此六条一次性安排在同一层上，每一条都同时写定两件事：总体做法，以及明细成表的落点。明细——接口字段与错误码分类、格式约定、血缘八项字段清单、通用质量指标定义、安全管控设计、验收五件套口径——一律放在工具链（三）的对应小节，此处不重复。同一口径两处各写一遍，改了一处漏掉另一处，是这类方案在实施期最常见的返工来源，也是日后双方对账时最难理清的一类分歧。表中「对应单元」一列使核对可以逐条落回招标文件原文，不必通读全章；「详述位置」一列标明明细的落点，两列合起来使这张表既是总体安排，也是一份可按图索骥的索引。

表 4-1　3.2.3.11 节六条通用要求的总体做法与详述位置（b1146—b1158）

表 4-1 的第六条有一项全局安排在此说明：25 套五件套在整体验收前汇总成册并编制索引，索引按招标文件单元标识排序。这样做的用途是让验收方不必先理解工具的内部结构，就能按招标文件条目找到对应的测试证据。

图 4-1　公共层与业务算子的分层，以及血缘的写入点

图 4-1　公共层与业务算子的分层，以及血缘的写入点。血缘字段在公共层逐环节追加，业务算子不参与血缘填写。数据来源：招标文件第五章 3.2.3.11 节（1）—（6）条（b1147—b1158）。

4.3 系统架构的四个统一面

若按 25 个独立程序交付，常见后果是整体不成线：样本靠人工搬运、字段口径各工序重释、质量判断无法汇总、模型换代须逐工具回归。招标文件 3.2.3.11 节将接口、格式、血缘、质量、安全、验收六条统一约束（b1146），以避免分散实现导致失配。

我方的系统架构按四个统一面组织，每一面对应上述失败形态中的一种：任务编排统一的是作业的生命周期，使 25 个工具对调用方呈现同一套用法；数据契约统一的是字段模式、版本与指纹，使样本在工具之间流动时含义不漂移；评测回路统一的是质量判断的来源与去向，使数据侧的问题能被定位并转成有版本的修订；人工介入通道统一的是判定权的行使方式，使需要人来定的事情有固定的入口与留痕。四个统一面之外，模型调用经统一网关收口，整套系统承载在奔牛数据智能平台之上，共用其身份认证、权限控制、任务调度、版本管理与日志审计能力。

图 4-2　专项智能工具链的系统架构

图 4-2　专项智能工具链的系统架构。四个统一面自上而下为任务编排、业务算子、数据契约与评测回路，模型网关与人工介入通道纵贯其间，整体承载于奔牛数据智能平台。数据来源：招标文件第五章 3.2.3.11 节（b1146—b1158）、3.2.3.1 节工具链清单（b0917）。

4.4 统一任务编排层

编排层解决的是「25 个工具对调用方呈现同一套用法」。它承担一次加工作业从受理到发布的全过程：接收任务、校验参数、切分批次、调度算子执行、作质量检查节点判定、发布结果，其间按状态变更推送回调；作业可被暂停与恢复、可按批次重试、可在发布前取消。

调用契约。 公共层对 25 个工具提供同一组调用，调用方按同一套参数与返回结构编程，不为每个工具另学一套用法。招标文件 3.2.3.11 节第（1）条要求的六类调用，加上参数校验与能力描述两类辅助调用，构成表 4-1A。标准应用程序接口与平台内部服务接口两种形态同时提供，共用同一套参数与返回结构；接口的字段定义与错误码分类见工具链（三）。

表 4-1A　公共层对外提供的调用及其契约

作业契约的形态。 一次作业的输入不是一堆文件路径，而是三个引用：输入数据集的版本引用、参数集的版本引用、输出落点的声明。用引用而不用路径，作业才可重放——同一个作业在半年后按原引用重跑，得到的应是同一批输入与同一套参数。这项约定是「配置即代码」（见本章 3.2）在编排层的落实方式。

批次粒度的统一。 所有工具按批次执行，批次是重试、计量、质量检查节点判定与血缘登记的共同单位。粒度不统一会直接导致部分失败无法局部重试：若某工具以整任务为单位，一批十万条样本中失败两百条就要全部重算。批次大小按工具与数据类型配置，但「以批次为失败与重试单位」这一条不因工具而异。

质量检查节点的位置固定。 质量检查节点的判定排在结果发布之前，由编排层按集中登记的门限执行，算子只上报指标、不自判放行。这样门限不会散落在各工具的代码里，验收时在一处即可核对。门限配置集中登记，变更走策略会签（见本章 4.7）。

任务状态与合法迁移。 任务状态固定为八个，调用方按状态编程，不以自由文本判断进展。八个状态、各自允许的操作与合法迁移见表 4-1B。表中未列的迁移一律拒绝并返回状态冲突错误：这使「跳过质量检查节点直接发布」「对已发布结果就地改写」一类动作在接口层就不成立，而不是靠流程纪律约束。

表 4-1B　八个任务状态与合法迁移

两个终止标记不计入上述八态：参数不合法由参数校验中进入，不可恢复，须修正参数后新建任务；已取消由任何非终态进入，取消后不再调度新批次。

暂停与恢复。 暂停有三种触发：授权角色人工暂停、配额耗尽自动挂起、质量检查节点未过自动挂起。挂起不丢进度——已完成批次的产出与血缘记录保留，恢复后从下一个未完成批次续作，不从头重算。挂起状态一律不自动恢复，须显式恢复、重跑或放行；自动恢复会让一次本该有人看一眼的中断悄悄过去。

取消。 取消是显式动作，由提交方或授权角色发起并带取消理由。取消后不再调度新批次，在途批次按配置或立即中止或跑完当前批次再停。取消作业中已完成批次的产出保留但标记为取消作业产出，不进发布版本；确需使用的走例外放行审批（见本章 4.7）。取消理由、发起角色与中止方式一并记入批次审计。

运行时的八项约定。 状态机规定了一次作业能走哪些路，下面八项规定的是作业在并发、故障与版本变动中的行为。这八项不写明，25 个工具在实施时会各自给出一种做法，而它们之间的差异只有在压力下才暴露：队列堵住、重复提交多跑一遍、断点重来、超时静默失败。八项约定见表 4-1C。

表 4-1C　编排引擎的八项运行时约定

批次审计记录与血缘记录是两套，不互相替代：血缘记录的是一条样本经历了什么，审计记录的是一次作业发生了什么。两者按批次标识关联，一条样本出问题时可由样本查到批次，再由批次查到当时的执行情况与处置动作。

4.5 统一数据契约：字段模式、版本与指纹

数据契约解决的是「样本在工具之间流动时含义不漂移」。它由四件构成：字段模式、版本标识、内容指纹与血缘字段。八项血缘字段的定义见工具链（三）；字段模式、版本标识与内容指纹三件的约定如下。

字段模式是每一类产出的字段定义，含字段名、类型、取值域、必填性与语义说明。模式本身是受版本管理的资产，工具在输出中声明所用模式的标识与版本，下游按模式名读取字段而不按位置读取。模式的兼容性规则定为只增不改：新增字段须为可选，不删除既有字段，不改变既有字段的含义。确需变更语义时发布新主版本，旧版本在一个发布周期内保持可读，期间下游完成迁移。这条规则看着保守，但它是 25 个工具能够分批投产的前提——若模式可以随意改，先投产的工具每次都要跟着改一遍。

版本标识分五类，彼此独立编号、互不代替。混用版本号是数据加工中一类隐蔽的错误：规则库改了而数据集版本不变，半年后就无法回答「这批样本是按哪一版规则处理的」。五类版本的定义与变更规则如表 4-2。

表 4-2　五类版本标识的定义与变更规则

内容指纹是对一段内容按确定算法算出的摘要，用途有三：判两份导出件是否同源、判一次重放的结果与原结果是否一致、判一份交付物在流转中是否被改动。指纹算在三个层次上，分别是样本级、批次级与结果集级。层次分开的理由是粒度不同用途不同：核对一条样本的争议用样本级，核对一次重放用批次级，核对一份交付物用结果集级。

模式说明语义，版本说明批次，指纹核对是否被改动。三件齐备，样本跨工具全程可解释。

4.6 统一评测回路

评测回路解决的是「数据侧的问题能被定位并转成有版本的修订」。前三个统一面支撑作业运转；评测回路支撑数据侧问题定位与带版本修订。

回路由六个环节构成，起点是评测、终点是新版本的规则库或模板库，中间必经一次人工会签。六个环节与其产出见表 4-3。第五环节约定：改进建议不自动生效。评测与归因产出的是建议，建议须经人工会签后才形成新版本的规则或模板，发布时带版本号与回滚路径。把这一环写死，是因为自动采纳改进建议会制造一类很难查的问题——数据集的处理口径在无人察觉时发生了漂移，而漂移的起点无从追溯。

表 4-3　评测回路的六个环节

回路的有效性不以「回路跑通」为判据，而以版本间的对比为判据：每一次规则库或模板库发版后，在同一冻结基准集上以同一协议重跑一次，产出新旧两版的对比报告。首期以第一次完整回路的实测结果作为基线，此后各版与基线比对；若新版本在基准集上的表现未达上一版水平，按第 6 环登记的回滚路径回退到上一版，并把该次比对结论记入版本说明。本项目所称迭代限于：有界、留痕、可回退；不采用无人值守的自行演化。

回滚路径的具体内容在发版时写明，含回滚的触发判据、回滚后受影响的在途作业如何处置、以及已按新版本处理的样本是否需要重处理。最后一项按情形分别约定：若新版本只影响此后生成的样本，回滚不触发重处理；若新版本改变了判定口径并已回写到存量样本，回滚须同时撤销该次回写，撤销动作本身作为一条追加记录写入血缘而不是抹去原记录。

4.7 统一人工介入通道与智能体加速的边界

数据加工里总有一部分事情机器定不下来。一张年代久远的蓝图扫描件上那个数字到底是 8 还是 3；同一条焊缝的同一处缺陷，两名标注员一个判未熔合一个判夹渣；备料工序字典里没有的一道新工序，该不该为它新增一个标签；某一批数据质检没过，而下游训练已排好期，放还是不放。这类事情在实际项目里的通常处置方式是——找个人问一句，口头定了，接着干。代价要到很久以后才显现：半年后回看这条样本，没有人能说清当初是谁定的、按什么定的、同类情形后来是不是都这么定的。于是同一个口径在不同人手里慢慢分叉，而数据集已经按分叉后的口径生产了几十万条，返工的不是一个判断，是一整批数据。

所以人工介入不能是「随时可以找人」，必须是「需要人来定的事情有固定入口、固定承办、固定留痕」。四类通道按介入的性质划分，而不按组织岗位划分：组织会调整，岗位会换人，建设期跨两年多，按岗位写定的流程到中途就对不上号了；而「机器拿不准」、「两个人不一致」、「规则本身要改」、「不合规但确需放行」这四种情形的性质不会变，按性质划分的通道在人员与组织变动之后仍然成立。每类通道写明三件事——什么时候触发、谁承办、必须留下哪几项记录。第三件是关键：留痕字段若不事先写死，事后补记出来的只是一句结论，看不出当时的分歧在哪、依据的是哪一条规则、这个判断后来有没有被推翻。四类通道合起来要说明的是一件事——本方案里凡由人定的事，事后都查得到是谁定的、依据什么定的、波及哪些批次。

表 4-4　人工介入的四类通道

这一面还承担另一项职责：界定智能体加速的边界。招标文件在多轮对话数据构建类工具链中明确要求基于多智能体机制自动生成多轮对话（b0968、b0969），在项目目标中两处要求提升模型与智能体的能力（b0663、b0674）。我方据此在加工生产侧引入智能体协同，用途是候选生成与初筛——由智能体产出候选样本、候选标签、候选切分方案与候选规则建议，交由既有的质检与验证门控判定。

这项引入不改变任何门控：置信度分档逻辑不变，抽检比例不变，不一致裁决规则不变，质量检查节点的位置与门限不变，中置信与低置信样本仍进人工复核与人工标注队列。门限的任何调整都走策略会签，与是否引入智能体无关。

智能体仅改变候选产出方式，不改变判定口径来源。放宽门控等于以未验证变化抵扣已验证保障；口径漂移会进入训练集并传导至模型，回溯成本高。

智能体的边界同样逐环节写定，而不在正文里笼统写一句「智能体只做辅助」。要分环节写，是因为「引入智能体」这件事在不同环节的含义并不相同：在采集接入，它看的是批次与格式，拿不准的是「这一批是不是异常」；在智能标注，它看的是单条样本，拿不准的是「这个标签对不对」；在治理支撑，它产出的是文字草案，而草案算不算数取决于标准评审，与它写得像不像无关。笼统一句话对这三种情形给不出同一个答案，到实施期各人按各人的理解执行，边界就在无人察觉中移动了。

六个环节逐行写三件事——智能体在这一环具体产出什么、判定权实际落在哪一个既有机制上、门控有没有因此变化。第三列写的是既有机制的名字（接收校验与来源登记、策略会签、自一致性筛选与人工复核、置信度分档与一致性裁决、标准评审、质量检查节点与评测协议）而不是笼统的「人工」二字，第四列六行一律是「无变化」。这两列合起来要说明的是：引入智能体之后，决定一条样本去留的仍然是本方案此前已定下、并且可被逐项验收的那套判据，没有一条判据因为「有了智能体」而被替换或放宽。验收时可以逐行指着问「这一环的判定是谁做的、按哪一条做的」，而不是对着一句原则各自理解。

表 4-4A　智能体在各环节的职责界限

图 4-3　智能体加速与质检门控的职责分界

图 4-3　智能体加速与质检门控的职责分界。智能体的产出止于候选与排序，判定权保留在既有门控上。数据来源：招标文件 3.2.3.4.1 节多智能体对话生成要求（b0968、b0969）、项目目标中提升模型与智能体能力的表述（b0663、b0674）；置信度三档处置口径见本章 3.2。

智能体在加工生产侧的用途有一处范围边界：本包交付数据集加工生产、质量评测与场景验证服务，智能体限于加工生产侧的作业组织，不构成为甲方建设智能体应用。数据集运营服务管理平台中列明的智能体开发服务（b1810、b1811）是平台面向行业用户的服务供给能力，其服务形态与配额口径见数据集运营服务管理平台一节。

4.8 可替换、可评测、可随代升级落在哪一层

凡涉及大模型调用的环节一律经统一模型网关接入，网关侧采用当期能力评测领先的通用大模型，可替换、可评测、可随代升级。这三项不是一句表态，它们各自落在架构的具体位置上。

要把它们落到位，先要看清不落位的后果。本项目建设期至 2028 年中，其后还有服务期，通用大模型的能力在这段时间里几乎肯定要换代不止一次。若把某一个具体模型写进工具实现，到换代时要动的就不是一处配置：每一个调用它的算子都要改，而且已经写出的血缘记录里都留着那个模型的名字——存量样本的血缘要么被改写（于是「血缘只追加不修改」这条约定当场就破了），要么保留一个已经不存在的名字，半年后无人能解释它指的是什么。更现实的风险是反过来：因为换不动，索性不换，整个服务期用着一个落后两代的模型，随代升级这一条始终停在纸面上。

四列分别回答四个问题：这件事由架构的哪一层保证、具体怎么做、凭什么说做到了、以及——写在第四列里的——判据必须是可实测的动作而不是态度。替换模型不需改动算子实现、不需改动字段模式、不需回改存量血缘，这三句话在验收时可以当场演一遍；候选模型未达在用模型基线水平的不予切换，这句话对应的是一份有逐能力项差异的对比报告；灰度一个批次后再全量，对应的是一个可以指出来的批次号与一条登记在案的回滚路径。少了第四列，三项能力就只是三句表态。这张表要带走的结论是：换模型在本方案里是一次有判据、可回退的发版动作，不是一次需要重做数据的改造。

表 4-5　三项能力的实现位置与判据

模型换代后，存量样本的血缘记录保持可追溯：记录中的网关标识与版本号不随换代改写，使半年前的一批样本仍能回答「当时用的是网关登记的哪一个模型版本」。这一条与 4.5 的「血缘只追加不修改」是同一条约定在模型维度上的表现。

4.9 统一的统计判据：自动采纳门限、批次估计与比较口径

公共层上还有一组东西，比接口与字段更不显眼，但它决定了全部二十五个工具报出来的数能不能当证据用。那就是统计判据——门限怎么定、批次合格率怎么算、两个版本的差异怎么判断是真差异还是波动。这三件事若由各工具自行处置，二十五个工具就会有二十五套算法，报表汇到一处无法合并，验收时也无从复核。因此本项目把它们做成公共层的三条统一判据，一次定义、各工具调用。

第一条，自动采纳的门限由校准算出，不由人定。 工具的输出按置信度分三档，高置信档自动进入候选集，这件事的关键在于「高」从哪里划。常见做法是在试点批次上看一眼置信度与正确率的对应关系，取一个看起来合适的数。本项目把这一步做成可复算的标定过程：取一批已由人工确认的样本作校准集，把工具输出的置信度当作打分依据，在校准集上搜索门限值，使「置信度不低于该门限的样本，其标签错误率不超过设定上限」这一结论在给定的置信水平下成立。门限随校准集扩充自动重算，不由人临时调整。

这个做法与「抽检合格率达到某个数」的差别，在于它是事前保证还是事后统计。抽检是产出之后抽一部分看对不对，结论只覆盖抽到的那部分；校准是产出之前先把门限算出来，使门限以上的那一部分整体错误率有上界。验收时招标方问「凭什么说自动入库的那部分是对的」，可以出示校准集、搜索过程与门限值，第三方用同一校准集能算出同一个门限。

落实上有两处要讲清楚。一是校准集必须与生产批次同分布，所以每个业务域、每类任务单独校准——图纸要素抽取与工单实体抽取的置信度含义不同，不能共用一个门限。二是工具的输出记录要增加三个字段：校准集版本、错误率上限设定值、算出的门限值，使任何一条自动采纳的样本都能回答「它是按哪一次校准的哪一个门限进来的」。

落实上还有一处比门限本身更要先定下来：什么算一条样本错了。 错误率上限是对一个集合说的，集合里每一条的对错若无统一的判定规则，上限就无法验收——验收时招标方只要问一句「你说错误率不超过百分之五，什么算错」，就须当场答得出来。而七类适用环节的「错」彼此完全不同，不能共用一条规则，须逐环节写定，见表 4-6。判错规则一经确定即随门限一并版本化，变更走配置变更会签，不在校准过程中临时放宽——放宽判错规则可以让任何门限都「达标」，这正是这类保证最容易失效的地方。

判错分两类记账。一类是硬错：取值与原始凭据不符、标签与标注规范冲突、证据片段在原文中无法定位，这类直接计入错误率。另一类是可修复问题：字段缺项、格式不规范、表述不完整而取值无误，这类另立口径统计，不计入错误率，但按批次登记并纳入质量报告——把可修复问题混进错误率，会使门限被压得过低、自动采纳比例失去意义。

表 4-6　七类适用环节的判错规则与首期错误率上限

表 4-6　数据来源：打分依据与判错规则依各工具链分节的输出字段与质量口径；图纸要素抽取与语义级去重判定的上限从严，理由见下段；上限取值为本方案设定的首期目标，属待验证目标，随首轮校准实测结果调整后报招标方确认。

两处上限从严有具体理由。图纸要素抽取取百分之三，因为下料尺寸写错一条即是整张钢板的废料，错误代价不对称；语义级去重判定取百分之二，且判错方向定为误删，因为被误删的样本不会再被发现——它不进数据集，也不进问题清单，而漏删的重复样本尚可在后续批次中被查出。判错方向的选择本身就是一项工程决定，须写明而不是留给实现者。

门限的有效性还依赖一个前提：生产批次与校准集来自同一分布。这个前提在建设期内会被打破，而且打破时不会报错，因此要有监测。四项信号任一触发即挂起该环节的自动采纳、转为全部进复核队列，并启动重标定：置信度分布与校准集相比发生偏移；自动采纳比例相对近期批次突变；抽检实测错误率连续两批高于设定上限；输入构成发生已知变化——新增图纸类型、新上线设备、提示词模板或输出格式换版、模型经网关随代升级。前三项由工具自动监测，第四项由变更记录驱动，两条路径都登记在批次质量报告中。

重标定的代价是可控的，原因在于校准集不额外产生标注工作量：它复用人工复核与一致性裁决本就要做的确认结果，按业务域与任务类型分池累积，随建设推进越积越厚。首轮校准所需的样本量在数百条量级（取决于设定的上限与置信水平），这一批在试点阶段的复核产出中即可满足；不足时按前述口径取保守门限并在报告中注明。模型随代升级后不沿用旧门限，而是在新模型上重跑校准——门限属于「某个模型版本在某类任务上的」门限，不属于工具本身，这一点在字段上已由校准集版本与模型标识共同体现。

第二条，批次合格率报区间，不报单点。 批次质检的通常做法是抽二百到五百条双盲复核，用复核通过率作批次合格率。这个数的问题不是不准，而是它的不确定性没有被报出来——抽三百条得到 96%，真实值可能在 93% 到 98% 之间，而报表上只有 96% 这一个数。扩大抽检量可以收窄区间，代价是人工线性增长。

本项目的处置是把两种信息合起来用：工具对全量样本都有评分，这个评分覆盖面大但有系统偏差；人工对小样本有复核，这个结论可信但覆盖面小。做法是先用全量评分得出初始估计，再用人工复核样本上「模型判定与人工判定的差值」对初始估计做偏差纠正。得到的结果是一个无偏的点估计加一个置信区间，而且在同等人工投入下，区间比纯抽检更窄。换一个角度说，要达到同样的区间宽度，需要的人工复核量比纯抽检少。

这里有一条必须守住的前提：人工复核的样本要随机抽取。不能专挑难的，也不能专挑模型打分低的——一旦抽样有倾向，差值纠正项本身就带了偏，算出来的区间看着窄却是错的。确实需要按难度或来源分层抽取时，用分层的纠正口径，分层比例一并留档。另一条前提是全量模型评分与人工复核必须用同一张评分表、同一套判定口径，否则两者的差值没有意义。

第三条，版本之间的比较用配对口径。 评测结论要回答的常见问题是「这一版比上一版好了多少」。本项目对此固定三件事。一是基准指标一律报为均值与百分之九十五区间，区间按题目层面的自助重采样计算；二是两个版本或两个模型的比较用配对检验——拿同一批题目的逐题结果做配对重采样，而不是比较两个独立区间是否重叠，后一种做法会把本来能分辨出来的差异判成分辨不出；三是给出基准集规模与可分辨差异的对应关系，即零点九五万条基准在题目层面能稳定分辨多大的差异，写明这个量级，使「提升零点八个百分点」这类结论有判断依据。

自助重采样有一个容易做错的地方要点明：重采样要按题目簇而不是按单题进行。同一份文档或同一张工单派生出的若干道题彼此相关，若按单题独立重采样，算出来的区间会偏窄，看起来比实际更有把握。

这三条判据与本章 4.6 的统一评测回路是同一套东西的两面：评测回路规定了什么时候测、测什么、结论往哪走，统计判据规定了结论本身怎么算、精度怎么表达。三条判据的指标口径按本章 8.1 的三段式表述，汇总见表 4-7。

表 4-7　三条统一统计判据的首期基线、度量方式与回退

表 4-7　数据来源：适用环节依本章表 1-1 的工具清单与第 3 节的供需关系；基线取值为本方案设定的首期目标，属待验证目标，随首轮校准与首轮评测的实测结果调整后报招标方确认。

4.10 计算接地：叙述里的每一个数都能回指一次计算

工具链中有若干环节要输出文字说明，而不只是输出字段。时序对齐之后要出一段工况诊断说明，视频对齐之后要出帧级的事件描述，图纸要素抽取之后要把几何量组织成可读的条目，故障场景构建要把故障树与处置建议写成文本。这些文字说明里必然带数值——温度多少度、持续多少秒、偏差多少毫米、判定为哪一档。

这些数值的来源必须说清楚，因为它关系到招标方最在意的一件事：数据集里会不会有编出来的内容。本项目对此定一条公共层的格式约束：凡输出文本中出现的数值、单位、阈值与结论标签，一律来自确定性计算的结果，由模板填入；语言模型只负责把已经填好的事实组织成通顺的说明，不参与任何数值的产生。

落实的办法是在输出记录里保留一个计算事实字段，逐项登记本条说明所依据的计算结果——测点编号、时间区间、计算式名称、输入值与输出值。校验器机械比对说明文本中出现的每一个数字与该字段中的值，不一致即判不通过，退回重新生成。这道校验是逐字符比对，不依赖任何语义判断，因此可以全量运行而不只是抽检。

这条约束的作用有三层。对数据集本身，它使每一段诊断说明都可复算——招标方拿到一条样本，照着计算事实字段把计算重做一遍，应当得到说明里的同一个数。对加工过程，它把语言模型的职责限定在组织语言上，模型换代不影响数值的正确性，因为数值从来不由模型产生。对将来的使用方，它使说明文本可以安全地进入训练语料：一段数值可复算的工况说明，教给模型的是真实的工艺事实；一段数值由模型生成的说明，教给模型的可能是一个看起来合理的错数，而这种错在海量样本里不会被摊薄，只会被学会。

需要说明适用边界：这条约束管的是数值与结论标签，不管定性描述的措辞。一段说明里「焊接电流在第三道出现明显波动」中的「明显」二字由模板的档位规则决定，而「第三道」与波动幅值来自计算；模型可以调整句子的组织方式，不能改动这两项。校验器只比对数值，措辞层面的质量由抽检与人工复核把关。

5、与相邻建设内容的责任边界

本包交付的是数据集加工生产、质量评测与场景验证。工具链建设属其中的加工生产手段。我方在本章范围内不承担智能场景建设，不承担模型训练与推理服务部署；工具链产出训练与评测所需的数据与评测结论，由训练推理技术服务消费。工具链的运行承载在奔牛数据智能平台之上，共用平台的身份认证、权限控制、任务调度、版本管理与日志审计能力，不各自另建运行支撑。

5.1 边界划在数据的交接点上

本项目的交付物不止工具链一项：数据采集接入、数据治理体系、大模型训练推理、运营服务管理平台、质量评测与场景验证各有承建内容，而它们之间的数据是流动的，一批数据往往要经过其中三四处才变成可训练的样本。边界若按组织划——「这块归谁、那块归谁」——实施期一出问题就会变成立场之争：数据不好用，加工一侧说源头没清干净，采集一侧说清洗口径是加工侧提的；两边都有道理，谁也拿不出可核对的东西，于是问题挂在那里，而数据还在继续生产。

边界按数据的交接点划，争的对象就从立场变成字段：哪一个字段没填、哪一次比对不符、按哪条路径退回，三者都可以当场核对，当天就能定下由谁去补。交接点因此被定义为三样东西的合称——一组具体字段、一次可以演练的交接动作、一条不通过时的处置路径，责任随字段走而不随部门走。

表的三列是「交接的是什么」与两侧各自的责任，而不是各方的工作清单。工作清单只说明各干各的，看不出两者在哪里碰头，也就看不出中间地带归谁；按交接物组织，每一行的两侧责任是对着同一个对象说的，谁的责任到哪里为止一目了然。表末把不属于本包的内容也列进同一张表，使范围的外沿与内沿在同一处可查，不必在两份材料之间来回比对。四处交接密集的相邻内容在 5.2 至 5.5 逐一给出接口字段与交接用例。这张表要带走的结论是：本方案对「自己做到哪里」的回答不是一段范围描述，而是八组可以逐项核对的交接物。

表 5-1　工具链与相邻建设内容的责任边界

表 5-1 中下列两条边界实施阶段争议较多，展开说明：

与训练推理技术服务的边界按「工具产数据、训推消费数据」划分。工具链不写训练方案，训练推理一侧不写工具的功能设计。两者之间有三个接口是硬约束：被测对象经统一模型网关以同一种调用形式接入，工具链不感知对象差异；训练任务必须登记其使用的数据集版本，否则血缘链路在训练任务这一节点断开，缺血缘字段的训练作业不予调度；留出对比所需的额外训练轮次由训练推理一侧承担，工具链负责设计对比方案、提供子集划分与评测执行。贡献度估计的具体算法在验证与归因类工具中给出，两处使用同一套方法，不在两处给出不同算法。

与运营平台的边界按「工具提供能力、平台提供入口」划分。工具链不设计界面，平台不实现工具算子。两者之间的接口是公共层的六类调用、参数校验与能力描述调用。工具链能力的对外提供形态按数据集运营服务管理平台约定的平台能力租用与加工任务服务两种方式执行，基准测试数据集按评测服务方式提供而不交付题目与标准答案本身——理由与本章的评测集隔离原则一致：基准集的题目与答案一旦外流，它就不再具备评测效力。

5.2 与数据资源采集接入的接口字段与交接用例

实际项目里数据交接最常见的形态，是一个共享目录加一句「数据放这儿了」。目录里是几万个文件，文件名是源系统导出时的默认命名，没有任何一处说明这批数据取自哪个系统、截到哪一天、做没做过脱敏、能不能拿去调用外部服务。接下来发生的事是可以预见的：加工一侧凭文件名猜来源，猜错了整批样本的来源家族就是错的，而来源家族一错，后面的切分隔离与同族去重全部失效，泄漏要到评测分数异常好看时才被怀疑；没有完整性声明，少了三千条也没人发现，直到某个类目的样本量异常地少；没有许可标识，一批含人员姓名的票据被送去经网关的调用环节，等发现时数据已经出去了，这是不可撤回的。

所以交接的对象被定义成一个带完整声明的数据包，而不是一批文件；十个字段缺任一项，该批次不进加工。这些字段不是元数据的装饰，后面每一道判断都压在它们身上——没有业务发生时点就匹配不了条款版次，没有内容指纹就验不出中途是否被替换过，没有内部对象主键就关联不起跨系统的同一个对象。

第四列写的是「工具链一侧的校验」，而不是「要求采集侧保证」。写成要求是口头的，写成校验是可执行的：每一行都对应一个在接收时就会跑的检查，不符的结果是整批退回或逐条挂起，而不是「记录在案后继续」。这张表要带走的结论是：数据进加工域这道门是上了锁的，锁的齿是十个具体字段，不是一句「数据质量要好」。

表 5-2　采集接入向工具链交接的数据包字段

交接用例以一批热处理炉次记录与同期测点时序的交接为例。第一步，采集侧按上表字段打包并登记批次，给出完整性声明与内容指纹。第二步，工具链侧先校验完整性声明与指纹，条数或指纹不符即整批退回，不做部分接收——部分接收会切断来源家族，后续切分隔离无从判定。第三步，校验内部对象主键齐备性，未命中的条目不进加工，列入待补映射清单同时回传采集侧与治理侧。第四步，校验敏感信息初筛结论与许可标识，两项任缺其一，本批不得进入经网关的调用环节，只能走内网处理。第五步，接收后按来源出质量报告，报告中的问题类型与条数即向该源系统提取数改进要求的依据。整个交接过程的可核验之处在于：每一步比对的都是表 5-2 中的具体字段，退回与挂起都有对应的字段名与条数，不以「数据质量不好」这类结论交接。

5.3 与数据治理体系的接口字段与交接用例

甲方现有的编码体系里，施工号、产品号、图号、零件号、物料编码、工单号、炉次号、焊缝与焊道编号、设备编码之间没有稳定的主键关系：同一种物料在采购系统与库存系统里是两个编码，同一台设备在远程运维平台与制造执行系统里是两个编码，而把它们对上的那张表现在不存在。工具链在这件事上有一个很有诱惑力但不能走的近路——自建一套映射。自建的映射只在工具链内部成立，出了工具链就对不上；更麻烦的是它会与治理体系日后发布的正式映射长期并存，形成两套都「正确」的答案，而数据集已经按其中一套生产完了。因此工具链在标识、标准与本体这三件事上一律是使用方：提出接口要求，按返回结果处置，不另起炉灶。

三类资产分三行写而不合成一张笼统的治理接口表，是因为它们的使用方式完全不同。统一对象标识服务是运行时逐次调用的，一次调用对应一条样本；数据集标准是入库时一次性校验的，一次校验对应一个批次；术语与本体资产是加载进配置后长期生效的，一次加载管一个版本周期。合成一张表会把「调用」与「加载」混为一谈，而它们的失败处置相差很远：调用未命中只挂起这一条并进待补映射队列，本体版本不符则整批不得开工。这张表要带走的结论是：工具链与治理体系之间的往来已细到字段与状态一级——三种命中状态各有各的处置，不存在「先按空值跑着、回头再补」的口子。

表 5-3　数据治理体系向工具链交付的资产与接口字段

交接用例以本体发新版后的联动为例。治理侧发布本体新版本并给出变更清单，清单分新增类、改名类与约束变更项三栏。工具链侧按变更清单评估受影响的规则标注配置与标注规范文本，受影响的配置改版并登记其依赖的本体版本号。新版本生效后处理的样本按新版本加约束；已处理样本不追溯重写，其血缘中的规则版本字段保留原值。若变更涉及标签值域收缩，存量样本中落在被删值域上的标签进复核队列，复核结论作为追加记录写入，不抹去原标注。联动是否完成有一个可核验的判据：规则标注工具的配置版本、标注规范文本版本与本体版本三者能在同一张依赖表里对上，且抽样样本的规则版本字段指向正确的那一版。

5.4 与行业大模型训练推理技术服务的接口字段与交接用例

数据集与模型之间最容易断的一环，是「这个检查点是用哪一版数据训出来的」。训练一侧通常只记「用了某某数据集」，不记版本；等到评测结果不如预期，想回头查是数据的问题还是训练的问题，查不动——数据侧改过三版，训练侧跑过五轮，两边对不上账，最后只能重训一遍，而重训并不会告诉人原因。更隐蔽的是基准集污染：若某个检查点的训练集里混进了与基准题目同源的样本，它在基准集上的分数会很好看，而这个分数不代表任何能力；拿着这样的分数去判断数据集是否合格，整轮结论都是空的。

把这类事情挡住，靠的不是流程约定，而是几个必须回填的字段。表里既有工具链侧填写的行，也有训练推理侧填写的行：交接是双向的，只写自己给出什么等于只做了一半，对方必须回填的被测对象标识、推理接口契约与训练任务登记一并列进同一张表，这次交接才有闭合的检查点。第四列写的是「对方一侧的使用与核对」而不是字段含义，因为字段的价值在于它挡住了什么——未登记数据集版本的训练作业不进评测排期，缺血缘字段的训练作业不予调度，推理接口契约不符即退回而不在评测过程中临时适配。这张表要带走的结论是：数据与模型之间的账是能对上的，任何一个检查点都答得出「用的哪一版数据」，任何一次评测都答得出「题目有没有被训练见过」。

表 5-4　工具链与训练推理技术服务的交接字段

交接用例以一次版本对比评测为例。工具链侧提供冻结基准集版本与评测协议版本，训推侧提供两个检查点的推理接口并经网关接入，调用形式一致。评测引擎按同一协议、同一随机种子分别跑两次，逐题结果留档。比较用配对口径（见本章 4.9），结论含均值、百分之九十五区间与该基准集可分辨的差异量级。随后做一次交叉核对：取训推侧登记的训练数据集版本，与基准集做同族隔离核对——若被比较的检查点其训练集与基准集之间存在同族样本，本次对比结论作废并重做切分，而不是在结论里加一句说明。核对通过后，对比结论回到评测回路第四环，按归属分派：指向数据的转修订工单，指向模型的转训推侧改进建议。

5.5 与数据集运营服务管理平台的接口字段与交接用例

平台与工具之间最常见的耦合方式，是平台把每个工具的参数表抄一份写进自己的界面代码。25 个工具意味着 25 份抄件；任何一个工具加一个参数、改一个取值范围，界面就要跟着改一次、发一次版。建设期内工具本来就在迭代，这种耦合的后果是平台永远比工具慢一拍：用户在界面上配出来的作业，提交到工具侧才报参数错误，而界面上看不出哪里错了。更远一点看，这份抄件还会在验收之后继续产生维护成本，每一次工具升级都变成一次平台改版。

本方案把这件事反过来做：参数清单、取值范围、默认值、输出字段由工具自己描述出来，平台取回后生成界面。这条通道因此成为平台与工具之间最要紧的一组字段，排在表的第一行。

表按字段组分行而不按单个字段分行，是因为两者之间不是一次性交接一批数据，而是六条长期存在的通道——能力描述、任务提交、任务状态、导出、血缘与审计查询、计量，每条通道有自己的方向、自己的节奏和自己的失败处置。按字段平铺会把六条通道的边界冲掉，看不出哪些字段是一起用的、少一个会导致哪条通道不通。第三列标明方向，是因为同一张表里既有工具链给平台的，也有平台给工具链的，还有导出这类双向的；方向不标明，责任就落空。这张表要带走的结论是：平台与工具之间的往来——提交、看进度、取结果、导出、查血缘、算计量——六条通道全部落在表内，没有哪一类往来是靠约定俗成办的。

表 5-5　工具链与数据集运营服务管理平台的交接字段

交接用例以平台上线一个新工具的配置界面为例。平台调用能力描述接口取参数清单与取值范围，按返回结构生成界面；用户提交前平台调参数校验接口预检，不合法项直接在界面提示，不产生无效作业；作业提交后平台按状态字段渲染进度；工具升级导致参数清单变化时，平台重新取一次能力描述即自动更新界面。这条链路的可核验判据是一句可实测的话：平台上新增一个工具，前端代码不作改动。验收时按此实测，不以接口文档齐备代替。

6、建设节奏：公共层先行与分批投产

25 个工具不一次性全部投产。排序依据是数据流上的依赖关系与问题出现的时间先后，不按工具编号。

图 6-1　公共层先行与四个投产阶段

图 6-1　公共层先行与四个投产阶段。横轴为建设期时序，各批次之间有重叠，箭头表示前置依赖而非严格串行。数据来源：招标文件第五章 3.2.3 各节的能力依赖关系；批次内容与本章之后三节的分批安排一致。

分批的难处不在于排出一张先后顺序表，而在于说清每一批「之前必须有什么」和「之后能开始做什么」。本项目的前置条件有相当一部分不在我方手里：图纸与企业文档的只读接口要甲方开通，敏感字段的标定与授权矩阵要甲方确认，备料 28 道工序的工序字典和各场景的判据字典目前还散在经验里、要先成文，视频布点要等现场施工完成。这类事项若不在排期里显式占位，表面上的进度会相当好看——工具一个接一个按时上线，而真正的加工迟迟开不了工，因为缺的是接口和规则，不是工具。等到发现时，剩下的工期已经不足以把积压的加工量做完，这是数据类项目最典型的一种翻车方式。

因此每一批列四件事，而不是只列内容与时间。前置条件写明这一批在等谁的什么，等不到时双方都看得见责任落点；本批解锁的工作写明这一批上线之后下游能开始干什么，使「这个批次有没有必要排这么前」可以被讨论；判为可用的依据写明凭什么说这一批确实能用了。缺了前置条件一列，批次之间的依赖会被当成单纯的先后，调整起来好像只是挪一挪时间；缺了判为可用一列，「上线」就成了一个靠感觉认定的状态，而上线与可用之间往往隔着一轮实测——接口调得通不等于血缘字段写得全，解析跑得完不等于抽样准确率达得到基线。

这张表要带走的结论是：每一批的开工条件与收尾判据都已写定，批次之间的先后由依赖关系决定，不是一份可以按工作量商量的排期。

表 6-1　各批次的前置条件、解锁的工作与判为可用的依据

批次安排有三处时序不可调整：公共层先于一切批次，理由在 4.1 已述。去重与污染扫描排在第一批，因为重复在候选池建立的第一天就存在，而污染一旦进入基准集且未被发现，受影响的全部评测结论都要作废，返工代价是整条链路。切分与基准构建排在第二批末尾、首轮训练之前，它的前置是数据集已完成去重与同族登记；基准集的建设周期较长——题目要专家出、要经污染核验，所以须与切分工具并行准备。

四批之后进入持续生产与迭代期，直至建设期结束。迭代期以校准为主：阈值随人工复核反馈按季度反推调整，分布的最小可用量随场景验证结果调整，模板约束表随工艺口裁定逐条回写，评测协议随能力维度的区分度调整，基准集按期组织复核与补题。每一项调整都按本章 8.1 的三段式登记基线、趋向与回退，不作无判据的调参。

表 6-1 的前置条件中有四项取决于甲方业务规则的成文程度：备料分厂的正式工序字典（28 道工序的标准名称、编码与分档规则）、各场景的判据字典（热处理三级判定、焊接缺陷类别与检出手段的对应、故障名录与证据分级）、历史文档资源的清点结果（按类型、份数、页数、电子化程度与扫描质量分档）、源系统只读接口的开通范围与协议。这四项我方在蓝图设计阶段以工作坊形式逐项确认并成文，确认结果即成为规则资产的首个版本，后续按版本演进；确认完成之前，相关工具按通用规则运行，并在批次质量报告中标注其配置来源为通用规则而非本项目规则资产。把散见于经验的规则落成可执行、可版本化的规则库，本身就是一项交付价值，其用途不限于本项目。

7、工具链产出与四大数据集、场景验证的对应

工具清单本身不是交付目标，数据集与场景验证结论才是。25 个工具很容易被当成 25 件设备，验收时一件件点过去就算完；但甲方买的不是设备，是 615 亿 Token 的预训练语料、89 万条指令样本、6.6 万组偏好数据、0.95 万条基准题目，以及十一个场景的验证结论。工具只有落到「哪一类工具产出哪一个数据集的哪一部分」上，这份清单才与交付目标对得上。反过来看也成立：若某一类工具在四列里全是破折号，那它要么是多余的，要么是它的产出没有被算进任何一个数据集——两种情形都要在动工之前查清，而不是等到数据集规模对账时才发现缺口，那时补料已经来不及。

用九类乘四个数据集的网格而不是逐工具写一段贡献说明，是为了让两个方向都能读。按工具逐个写会写出 25 段文字，读完仍然答不出 89 万条指令样本究竟由谁产出；网格可以竖着读——一列就是一个数据集的全部产出来源，看得出有没有哪个数据集只靠一类工具支撑、风险过于集中；也可以横着读——一行就是一类工具的全部去向，看得出有没有哪类工具的产出无处可去。两个方向都对得上，缺口才看得见。

这张表要带走的结论是：每一个数据集都说得清它的规模由哪几类工具产出，每一类工具都说得清它的产出进了哪一个数据集；表中的空缺是经过判定的（见下段），不是尚未想清。

表 7-1　九类工具对四大数据集的类级贡献

表中第 6 类与第 8 类的「不参与」是评测集隔离的落实：生成类工具的产出一律带不可用于评测集的标记，评测集构造按该标记排除。预训练语料的实际 Token 量受甲方可用文档的实际体量约束——解析工具能把现有文档的结构还原出来，不能增加文档总量。我方的做法是先完成文档资源清点与解析覆盖度统计，按业务域给出可得 Token 量的实测值，与目标存在差距的域在数据卡中列明并提出补充来源建议，由项目组与甲方共同确定补充路径。逐数据集的规模对账与数据卡见四大数据集规模一节。

表 7-2　工具链对场景验证的支撑点（类级）

表 7-2 右列是工具链与场景验证之间的接口：验证时核对的就是这些口径，而口径的计算方式在各工具的质量口径表中已逐项定义。场景验证的组织方式、验证用例与验收流程见六个专业场景验证方案与五个通用场景验证方案两节。本包只提供场景验证所需的样本与评测口径，不承担场景建设。

8、工具链的总体验收口径

25 个工具链共用一套验收口径：指标一律按三段表述，验收分三类且三类不互相替代。具体指标值与回退动作在各工具的功能设计中逐项列明。

8.1 指标一律按基线、趋向、回退三段表述

工具链质量指标按作用对象分档约定：同一能力作用于电子版规程与陈旧扫描件，结果本不相同，故指标按资料品质分档给出，各档以首轮实测值作为基线。漏报一类指标以抽检复核的实测值呈现，并随样本积累逐轮更新。

因此每项能力按三段表述：基线说明首期可达到的水平及其测量方法；趋向说明服务期内随样本积累与阈值校准逐步接近的目标；回退说明达不到时的具体动作与兜底方。各工具的指标表均按这三段给出，且回退列写的是可执行动作——整批转人工复核、改以人工判定为准、退回上一稳定配置版本、批次不得出加工域、阈值调向保守侧并扩宽复核带——不是原则性表述。

验收时的用法随之明确：按基线值核对实测值，达到或超过基线即判通过；未达基线的，核对回退动作是否已执行并留有记录，回退已执行且未达项已登记的判为有条件通过并列入服务期校准计划；回退未执行的判不通过。趋向目标不作为验收判据，它在服务期的阶段性检查中核对改进趋势。据此在验收前约定未达标时的回退与登记动作。

8.2 三类验收的对象与依据不互相替代

实施期里「验收」这两个字会被用在三个地方：一个工具做完了要验，一版数据集发布前要验，整个项目交付时还要验。三者混用会生出两种方向相反的麻烦。一种是以工具验收代替数据集验收——25 个工具都测试通过了，于是认为数据可用；可工具跑通与数据合格是两件事，一个毫无缺陷的工具照样会因为配置取了默认值、或者源数据本身成色不足，产出一整批不能用的样本。另一种是以数据集验收代替整体验收——某一版数据集的质量报告很漂亮，于是认为项目可以收尾；而整体验收要看的还有工具链的数量与形态、运营平台的功能模块、治理文档的份数与质量、以及十一个场景的验证结论。两种混用都会在最后一个月集中爆发，而那时已经没有时间补。

三列分别是对象、依据与口径归属。验收争议几乎都起于前两件事不清：验的是哪一版、哪一个（对象），凭哪一份材料判定（依据）。把这两件事连同各自的口径出处一并写定，到验收时双方对的是同一份清单，而不是各自带着一份理解。这张表要带走的结论是：三类验收各有各的对象与证据，谁也替不了谁。

表 8-1　三类验收的对象、依据与归属

三类验收的证据链是串联的：工具验收合格的工具产出数据集，发布验收合格的数据集版本进入整体验收的交付清单，整体验收所需的质量证据由前两类的记录与第三方评测报告共同构成。第三方盖章的数据集质量评测报告不由本章的测试报告替代；两者的关系是本章提供过程证据——协议版本、冻结集、运行记录、指标与原始测试记录，第三方据此与自行抽测结论出具评测报告。为使第三方可复核，本方案承诺评测过程的可复现性：协议版本化、基准集冻结、随机种子固定、运行记录留存，第三方按同一协议与同一冻结集重跑应得到一致结果。