## 项目实施路线与工作思路
本包的交付物是四类高质量数据集及其质量证明：按供需计划、产品工艺设计、制造过程、产品质量四个业务领域，各自形成预训练、有监督指令微调、人类偏好对齐、基准评测四种用途子集，合计十六个用途子集，规模为预训练 615 亿 Token、指令微调 89 万条、偏好数据 6.6 万组、基准评测 0.95 万条；为其配套 9 类 25 个专项智能工具链、17 项功能模块的数据集运营服务管理平台（招标文件要求不少于 14 个功能模块，服务采购清单实列 16 项，我方另增「平台服务与 SLA 保障」1 项，合计 17 项）、不少于 25 份治理文档；并以依据《高质量数据集质量评测规范》（TC609-5-2025-04）出具的盖章评测报告与 11 个场景的验证结论证明其可用。这批成果不是一次产出，而是在合同签署至 2028 年 5 月的建设周期内分批形成、逐批放行的（b2155、b2156、b0518）。
分批形成就要回答三个问题：先做什么后做什么，凭什么判断一个阶段可以结束，每个阶段结束时甲方手上应当拿到什么、据什么判断它合格。这三个问题的答案分别是实施路线、阶段关口与交付物验收判据。本部分给出贯穿全程的工作思路与这三者的统一口径；日历排期、工作分解、资源曲线与里程碑付款节点的管理办法在服务方案卷项目管理措施一节；各项成果的完整清单与数量在项目交付成果一节。
### 1、工作思路
#### 1.1 六条作业原则
实施路线按下列六条作业原则编排。每条对应具体做法与可核查痕迹，并针对数据集加工中常见的一类失控。
**其一，口径先行——先把口径定死，再动手作业。** 本项目需要事先定死的口径有五类：业务对象的主键映射与时间基准、工序字典与部件层级、标注规范的标签集与判定规则、质量指标的定义与阈值、场景验证协议的题型与判分规则。每一类口径都安排一次正式评审并出具书面结论，结论发布之后才开工对应的作业。这条原则的分量来自返工的量纲：口径一旦在作业开工后修订，返工规模等于已完成的全部作业量，而不是出错的那一部分。备料的 28 道工序字典若在标注开工之后调整分段方式，此前完成的工艺类标注须逐条回看；63 万张历史工艺样本的时间基准若在关联之后改口径，跨系统关联结果要整体重算。甲方口径确认逾期时，我方不停工等待，也不先标后改，而是按我方建议口径先行并把该批数据标注为待确认状态，确认后批量复核——待确认状态的批次在版本检查节点之前必须转为已确认，不会流入交付版本。
**其二，门控前置——检查放在缺陷产生的那一道，不放在交付之前。** 招标文件把质检定为训练前门控、把验证定为训练后终验（b1215）。我方在此基础上把检查拆到加工链的七个位置：入口、预处理、口径、终审、标注、合成增强、版本。缺陷的修复成本随它在链路上走过的环节数递增，这是把检查前移的全部理由。一条授权不完整的样本在入口被拦下，处置的是这一条；同一条流到版本封装才被发现，要回溯的是整个批次的血缘、已经引用它的知识条目、以及据此训练出的模型版本。七道节点的判定规则与质量评测的指标定义取自同一套指标体系，不另立一套内部标准，这样内部放行与外部评测不会出现两种结论。
**其三，以批次为推进单位。** 批次是进度、质量与责任三者共用的粒度。进度不以「完成百分之多少」上报，而以「第几批通过了第几道节点」上报，理由是前者由执行人自报、无法核查，后者有节点记录可查。批次粒度还决定了返工的局部性：某一批次质检不通过，退回的是这一批次，同一数据集版本内的其他批次不受影响，不必整版重做。批次台账登记领域、用途子集、计量单位、状态、来源时间、模态与去重结果，规模统计直接由台账的对象明细生成，分项与合计、增量与存量、合格与剔除之间的关系在生成时即校验。
**其四，共享底座、不重复建设。** 招标文件对此有明文：四类数据集在同一生产逻辑上各走专属路径，共享底座能力与门控规则，避免重复建设（b1215）。落到做法上，知识本体、九业务域知识库、标签体系、质量规则库、评测指标体系都只建一套，四类数据集按用途引用其中的不同部分。最典型的一处是指标体系一套两用：依 TC609-5-2025-04 建立的说明文档、数据质量、模型应用三维度指标，既是外部质量评测的打分表，也是加工链上数据集质检的门控规则库。两处引用同一套定义，省下的不只是编制工作量，更重要的是内部质检结论与外部评测结论可以直接对账。
**其五，证据随作业产生，不在验收前补。** 血缘、质检记录、评测日志、审批留痕都在作业发生的同时写入，时间戳与作业时间戳一致。这条原则在贯标工作上的分量最重：DCMM 三级与二级的差别不在文档厚度，而在能否证明「不是写了一套、做了另一套」，评估师的典型取证动作是随机抽一个业务域、抽一个时间段，调出该时段内这一过程的全部执行记录，核对责任人、时点与结论是否与制度一致。补记的材料在这种核对下对不上时间。同样的道理适用于质量评测：检测日志、实验记录与复核材料是评测结论可追溯、实验可复现的唯一依据（b2109），事后整理的记录无法支撑复现。
**其六，回流定向，不全量重做。** 血缘追溯驱动定向回流，构成有向无环的生产逻辑（b1215）。回流分三类，去向各不相同：质检不通过的，按不通过项定位到具体环节与算子，退回预处理或标注重做后重新质检；验证不通过的，按错样归因结果区分脏数据、覆盖盲区、歧义标注、难度缺口四类成因，分别退回质检、采集、标注、合成；场景验证未达判据的，形成结构化整改任务单进入下一期加工计划，若属数据不足则先补采集。三类回流都要求归因落到唯一的环节，跨环节的连锁失败按最上游的那一处归因，避免同一缺陷被重复计数、也避免以放宽判据的方式通过。
六条原则各自留下的痕迹不同，核查的方式也不同。下表把原则、做法、痕迹与放弃该条的后果并列，用途是在阶段检查与过程审计时据以逐条核对：看某一条原则有没有真的在执行，查的是「痕迹」一列列出的那些对象是否存在、是否与作业时间一致，而不是问执行人是否遵守。
表 1 六条作业原则、落地做法与可核查的痕迹
| 原则 | 落地做法 | 可核查的痕迹 | 放弃该条的后果 |
|---|---|---|---|
| 口径先行 | 五类口径各设一次正式评审并出具书面结论；结论发布后开工对应作业；逾期未确认的按建议口径先行并标为待确认 | 口径评审纪要与书面结论、口径版本号与生效日期、待确认批次清单及其转正记录 | 返工量等于已完成作业量，而非出错部分 |
| 门控前置 | 七道质量检查节点分布在加工链上；判定规则取自统一指标体系；质检为训练前门控、验证为训练后终验 | 各节点的判定记录、不通过项清单、节点阈值配置版本 | 缺陷在版本封装时才暴露，回溯范围扩大到批次血缘与已训练模型 |
| 以批次为推进单位 | 进度以批次过节点计；批次台账登记领域、用途、状态、来源时间、模态与去重结果 | 批次台账、节点通过记录、规模统计的对象明细与执行版本 | 进度口径不可核查，返工范围无法局部化 |
| 共享底座、不重复建设 | 本体、知识库、标签体系、质量规则库、指标体系各建一套；四类数据集按用途引用 | 本体与知识库版本、标签集发布记录、指标定义引用关系表 | 内部质检与外部评测出现两套口径，结论无法对账 |
| 证据随作业产生 | 血缘、质检、评测、审批记录在作业发生时写入；时间戳与作业一致 | 带时间戳的执行日志、稽核台账、审批流水、血缘登记 | 贯标抽样与评测复现均无证据支撑 |
| 回流定向 | 三类回流各有去向；归因落到唯一环节；连锁失败按最上游归因 | 整改任务单及其指向的环节与算子、复测记录、错因分类统计 | 整改沦为全量重做，或以放宽判据的方式通过 |
表 1 数据来源：门控与回流的设定依招标文件 3.2.6 实施服务要求总则（b1215）；指标体系依《高质量数据集质量评测规范》（TC609-5-2025-04）；贯标取证口径依 GB/T 36073—2018 对三级的要求。
#### 1.2 三条由此而来的进度约束
上述原则落到排期上，形成三条不可让步的进度约束如下。
第一条，知识底座不就绪不开标注。本体类目、工序字典与部件层级未通过口径检查节点之前，标注作业即便开工也会返工。排期上的后果是：准备期必须为本体建设、术语与编码核验、专业评审留出完整周期，这段时间不能靠增加标注人力来压缩。
第二条，首批不通过不转全面加工。首批加工的作用是把十个环节的流程跑通、把各环节的参数标定下来、把口径问题暴露出来；跳过首批直接放量，等于把口径问题放大到四类数据集的规模。排期上的后果是：试产批次必须单列一段工期，并为首批的整改与重新送审留出余量。
第三条，评测与整改复测的时长不可压缩。首轮全量评测之后要逐项立单整改、再行复测，复测重新抽样而不复用首轮样本。等级保护测评、商用密码应用安全性评估与贯标评估还受第三方机构档期约束。排期上的后果是：机构对接与预评估要在全面加工阶段的中段即启动，把正式评测排在整改期之前，留出至少一轮复测的余量；压缩这一段会直接损害结论的可靠性，而结论是本包的交付物之一。
这三条约束与下文五个阶段的划分互为因果：阶段的边界就划在这三处，关口的通过条件也据此设定。
### 2、实施路线的时间基准与总体分期
#### 2.1 时间基准与验收形态
建设周期为合同正式签署后至 2028 年 5 月（b2155、b2156），交付时间为 2028 年 5 月前完成终验收（b0518）。我方以合同正式签署日为时间零点，全部实施安排按相对时序表达，合同签署后一次折算为日历计划并发布基准版本；折算办法、工作分解、关键路径与资源安排在服务方案卷项目管理措施一节。采用相对时序的理由是签约时点由签约程序决定，而 2028 年 5 月这一终点不随签约时点移动，两者之间的工期必须在签约当日即可重新折算，不必整体重排。
验收形态对实施路线有直接约束。招标文件规定本项目采用二次验收模式，即竣工验收与最终验收：项目实施完毕由我方提出申请、经招标方讨论通过后进行竣工验收；系统试运行一段时间并调试至稳定，且满足招标文件、投标文件、技术协议、合同、蓝图设计方案等要求后，由我方提出申请，招标方进行总体成果评估，评估通过后组织最终验收；最终验收在竣工验收的基础上，侧重实施效果与运行、维护质量的评价（b2226）。合同另约定系统所有功能上线试运行无问题后方可申请终验收（b0545）。这三句话决定了实施路线末段的形状：竣工验收之前要把建设内容建成并通过数据集首轮评测与整改复测，竣工验收之后还须留出一段真实运行期供试运行与稳定性观察，终验收不是竣工验收的顺延。
质保期为 12 个月，自甲方终验收合格之日起计算（b0541、b2215）。质保期单独成段，自有节奏与判据，内容见第 6 节。
#### 2.2 五项建设内容与五个阶段的关系
招标文件把本项目划分为基础设施及数据资源建设、数据集加工生产运营平台建设、数据集加工生产实施、数据集场景验证、数据集运营推广五项建设内容，并写明各项建设内容协同推进、在时间上相互衔接、任务上互为支撑（b2156）。这五项是按建设内容划分的，不是按时间先后排列的工序，两者不能混为一谈：若把它们当作五段依次推进，数据集加工生产实施要等平台建设全部完成才能开工，场景验证又要等加工生产全部完成才能开工，总工期排不进建设周期。
实际的对应关系是多对多。基础设施及数据资源建设集中在第一、二阶段，但源系统的分批开通与设备侧采集范围的扩展延续到第三阶段。运营平台建设跨第一至第四阶段：公共层与基础功能在第一阶段上线，17 项功能模块在第三阶段开发与集成，第四阶段上线试用。加工生产实施从第二阶段的首批试产起，贯穿到第四阶段的整改回流。场景验证从第二阶段的基准构建起步，主体落在第三、四阶段。运营推广集中在第五阶段，但其所依赖的登记、确权与挂牌能力在第三阶段即随平台模块建成。
五项建设内容回答「做哪几件事」，五个阶段回答「什么时候做到什么程度」，两套划分各有用途、不互相替代。关口与判据按阶段设定，用以判定能否进入下一阶段。
#### 2.3 五个阶段与阶段目标
据此划分五个实施阶段。划分的依据是交付物成形的先后，而不是工种的先后——按工种串行排期排不进建设周期，按交付物成形排期才能让治理、加工、平台、评测、验证五路工作并行推进而各有出口。
第一阶段准备与底座，目标是把后续全部作业所依赖的口径与底座立起来：需求细化与蓝图确认、源系统授权与接口开通、对象主键映射与时间基准统一、知识本体类目与关系定义、数据标准首轮发布、为招标方建设的天地奔牛煤机装备数据智能平台（以下简称奔牛数据智能平台）的基础功能与工具链公共层上线。第二阶段首批加工与首轮验证，目标是把十个加工环节的流程在真实数据上跑通一遍并标定参数，产出首批冻结的数据集版本与首轮质检、验证报告。第三阶段全面加工与场景验证，目标是四类数据集并行放量、25 个工具链分波次投产、11 个场景分批验证、治理九大能力域落地。第四阶段外部评测与整改复测，目标是取得合格的质量证明：首轮全量评测、缺陷逐项立单整改、复测，同期完成等级保护测评、商用密码应用安全性评估与贯标评估。第五阶段运营上线与移交，目标是让数据集进入可对外服务的状态并完成移交：版本登记与目录上线、确权挂牌与交易通道启用、接入国家数据基础设施的准备、成果移交与培训。
相邻阶段允许重叠：蓝图设计在需求调研后半段启动；首批加工在工具链公共层交付后开始；场景验证在首批数据集通过预评测后启动。重叠期内下游仅做不依赖未定口径的部分，可开工范围在例行计划会上逐项确认。图 1 给出五阶段、六作业线与五道关口的时间关系。
##### 图 1 五个实施阶段、六条作业线与五道关口
图 1 五个实施阶段、六条作业线与五道关口。数据来源：阶段划分依本方案技术方案总论的实施安排；建设周期与终点依招标文件 b2155、b2156、b0518；二次验收形态依 b2226；质保期依 b0541、b2215。横轴不标注绝对月份，日历排期在合同签署后一次折算。
#### 2.4 阶段与交付期的对应
阶段是按工作推进划分的，交付期是按成果交到招标方手上的时点划分的，两套划分指向同一条时间轴，不是两套计划。交付期按四期组织，时点分别为合同生效起 3 个月内、至第 9 个月、至第 18 个月、至 2028 年 5 月，各期的累计达成下限、应交交付物与进入下一期的通过条件在项目交付成果一节逐期给出。实施路线上的阶段与关口按下表落到这四个时点上，排期、核对与验收都以这一组时点为准。
表 2 五个实施阶段与四个交付期的对应
| 交付期与时点 | 落在该期内的实施阶段 | 该期末要过的关口 |
|---|---|---|
| 第一期 口径与基线（合同生效起 3 个月内） | 阶段一准备与底座；阶段二首批加工在本期末启动 | 底座关 |
| 第二期 主体加工（至第 9 个月） | 阶段二首批加工与首轮验证；阶段三全面加工在本期内转入放量 | 首批关 |
| 第三期 补齐与均衡（至第 18 个月） | 阶段三全面加工与场景验证；阶段四外部评测在本期末启动 | 规模与版本关 |
| 第四期 达成与复测（至 2028 年 5 月） | 阶段四外部评测与整改复测；阶段五运营上线与移交 | 整改关、验收关 |
表 2 数据来源：四个交付期的时点与各期通过条件依项目交付成果一节的分期交付安排；阶段划分依本卷技术方案总论的实施安排；建设周期终点依招标文件 b2156、b0518。
### 3、六条作业线在五个阶段上的落点
五路工作并行，难点不在各自怎么做——各节已分别写明——而在它们彼此之间的时序依赖：治理的标准什么时候发文，决定标注什么时候能开工；工具链第一波次什么时候交付，决定首批加工什么时候能开始；首批数据集什么时候冻结，决定场景验证的基准什么时候能构建。下表把六条作业线逐阶段摊开，每一格写该线在该阶段的主要动作与它交出的东西，读法是横着读看一条线如何推进、竖着读看同一时段有哪些工作在抢同一批资源与同一批口径。
表 3 六条作业线在五个阶段上的落点
| 作业线 | 一 准备与底座 | 二 首批加工与首轮验证 | 三 全面加工与场景验证 | 四 外部评测与整改复测 | 五 运营上线与移交 |
|---|---|---|---|---|---|
| 数据治理与贯标 | 九域四维现状调查与资产盘点；差距分析；第一批制度与标准起草送审 | 第一批制度与标准发文生效；治理平台上线，审批流与稽核规则启用 | 九项治理内容在九个业务域按批次落地；决策数据指标体系构建；执行记录持续积累 | 内部审核抽样核对记录与制度一致性；发现项整改闭环；自评报告出具 | 评审证据包整理；配合甲方向认定机构申报并应答问询 |
| 数据加工生产 | 源系统授权与接口开通；主键映射与时间基准统一；本体类目与关系定义；知识库首批条目终审 | 产品工艺设计数据集首批加工；标注规范发布与标注队伍培训考核；十环节流程跑通并标定参数 | 四类数据集十六个用途子集并行放量；分批冻结版本；血缘与数据卡随版本生成 | 按评测与验证的整改任务单定向回流；补采、重标、重合成后重新质检 | 正式版本封装与接收核验；移交运营服务管理平台并完成登记 |
| 工具链与平台 | 工具链公共接口层与平台基础功能上线；硬件到货安装与国密联调 | 第一波次工具交付：文档结构解析、智能预标注、一致性校验，直接支撑首批加工 | 第二、三波次工具投产，9 类 25 个工具逐一完成实测验收；运营服务管理平台 17 项功能模块开发与集成 | 平台上线试用；接口与权限的异常流程测试；缺陷闭环 | 目录与检索上线；确权、挂牌与交易通道启用；国家数据基础设施接入准备 |
| 数据集质量评测 | 数据集台账、业务规则与涉密边界清单；离线评测环境部署与隔离实测；抽样策略制定 | 指标打分表搭建；静态与动态一体化执行方案编制；缺陷分级与合格标准确定 | 按批次开展预评测，暴露结构性问题并反馈加工侧；标定样本集建立与工具校准 | 首轮全量评测：静态检测与基准模型动态验证并行；缺陷分级立单；整改后重新抽样复测 | 分项与综合评分汇总；正式盖章评测报告与完整质量档案交付 |
| 场景验证（11 个） | 场景接入条件与责任边界核定；验证所需数据、知识与接口清单提出 | 基准分册构建：题面与标准答案取自真实业务，经业务专家终审后冻结 | 评测协议冻结；六个专业场景与五个通用场景分批执行，四层并行观测 | 错样归因到唯一观测点；整改任务单下发加工侧；按错因类别整批复测 | 各场景可用性结论与未结项清单归档；结论随数据集版本封存 |
| 安全与非功能验证 | 安全基线与密码应用方案确定；国产化适配路线与核算口径确定 | 功能上线前评审闸门启用；界面与文档中文化、浏览器与终端兼容走查 | 性能、压力、稳定性与容量测试；故障注入与隔离演练；渗透测试与漏洞闭环 | 等级保护测评与商用密码应用安全性评估；问题整改与复核；国产化率实测核算 | 上线验收实测；非功能指标符合性说明与各项报告交付 |
表 3 数据来源：治理线依本卷数据治理规划和实施服务一节的四段路径与七个执行阶段；加工线依招标文件 3.2.6 实施服务要求（b1215）与本卷数据集加工生产各节；工具链与平台线依服务采购清单（b0689）与本卷相应各节；评测线依招标文件 3.2.8.2.4 实施过程五阶段（b2108 及以下）；场景验证线依 b0684 的 11 个场景与本卷场景验证各节；安全与非功能线依招标文件 3.1.2.2 与 3.2.6.12。
表 3 竖读可见三处资源与口径交汇，排期安排如下。
第一处在第二阶段：治理线的第一批标准发文与加工线的标注开工落在同一时段，而标注用的标签必须取自已发布的参考数据码表与数据元标准，两者之间是硬依赖而非并列关系。排期上的安排是把第一批标准的送审时点压在首批加工开工之前，并为发文程序留出余量；发文确有延期的，先以项目联合工作组决议作为临时依据并登记在案，发文后追认，不以未发布的草案开工。
第二处在第三阶段：工具链二三波次投产、四类数据集放量、11 个场景分批验证三件事同时进行，对工艺、焊接、热处理、设备诊断等专业人员的占用在此叠加。排期上的安排是把专业人员的三类用途——标注仲裁、规范评审、场景基准出题与终审——提前排进同一张档期表，按场景的验证批次倒排出题时点，避免同一批专家在同一周被三条线同时约用。
第三处在第四阶段：首轮全量评测、等级保护测评、商用密码应用安全性评估与贯标评估四项外部活动集中在同一段时间，四者都依赖第三方机构的档期，且都要求被检对象在受检期间处于稳定状态——评测期间继续向数据集写入新批次，会使检测结果与送检版本对不上。排期上的安排是把机构对接与预评估提前到第三阶段中段，把正式评测排在整改期之前，并在各项受检期间对相应对象设置变更冻结窗口，窗口内的变更申请统一排到窗口之后执行。
### 4、阶段关口与通过条件
#### 4.1 关口、里程碑与验收的关系
本项目的推进有三层把关，三层各有主体与效力，不能互相替代。
最里一层是各节自设的检查点，判的是单批、单件、单项是否合格，由承办岗位与质量岗判定，不通过的就地回流，不惊动阶段推进。中间一层是本节的阶段关口，判的是一个阶段能否结束，由评审组判定、需要双方代表同时在场，不通过的阶段不往下走。最外一层是合同约定的验收，本项目采用竣工验收与最终验收的二次验收模式（b2226），由招标方组织，是取得阶段性与总体成果认可的法定程序。
三层之间是逐级汇总关系：检查点的结论汇成关口的判据，关口的结论汇成里程碑的达成依据，里程碑再支撑验收的申请。项目管理层面设六个一级里程碑，其达成需甲方签认，不由我方自行宣布，其设置与付款节点的对应在服务方案卷项目管理措施一节。本节的五道关口与里程碑的对应关系见下表，读法是：关口是技术上的放行条件，里程碑是管理上的确认事件，前者达成才有后者的签认依据。
表 4 五道技术关口与管理里程碑、合同验收的对应
| 技术关口 | 对应的管理里程碑 | 对应的合同验收环节 | 两者的差别 |
|---|---|---|---|
| 一 底座关 | 需求基线与设计基线的确立 | — | 关口判的是本体、口径与授权是否足以支撑开工；里程碑确认的是需求与设计文件经签认 |
| 二 首批关 | 设计基线确立之后的首个交付确认 | — | 关口判的是流程是否跑通、参数是否标定；里程碑确认的是首批成果已提交 |
| 三 规模与版本关 | 联调测试通过 | — | 关口判的是当期数据集版本能否送检；里程碑确认的是平台与工具链具备可用状态 |
| 四 整改关 | 竣工验收 | 竣工验收（项目实施完毕，我方申请、招标方讨论通过） | 关口判的是评测与验证结论是否达标、缺陷是否闭环；验收确认的是阶段性工作的总结 |
| 五 验收关 | 最终验收 | 最终验收（系统试运行稳定、总体成果评估通过后组织） | 关口判的是移交条件是否齐备；验收侧重实施效果与运行、维护质量的评价 |
表 4 数据来源：二次验收模式与两次验收的触发条件依招标文件 b2226；终验申请条件依 b0545；里程碑设置依服务方案卷项目管理措施一节的里程碑安排。
三层分别处理不同性质问题：批次级指标不达标在检查点内整改；阶段级普遍性缺陷在关口拦住并整体补齐；建设内容是否建成、实施效果是否达标由招标方在验收判定。不得将三类问题混在同一场合讨论。
#### 4.2 关口的设定办法
阶段衔接以关口条件达成为准，不以日历到点为准。关口按阶段设置：前期口径或抽样策略错误会导致后期检测或标注整体不可用，故须在各关口完成确认后再进入下一阶段。
关口条件的写法遵循三条。第一，条件必须可逐条核对，写成「某项清单齐备」「某项记录覆盖不少于两个考核周期」「某项指标达到约定判据」这类能够当场比对的句子，不写「质量良好」「基本具备条件」这类需要再解释一次的判断。第二，每一道关口的判定主体唯一；需要双方共同判定的，双方代表须同时在场，任一方缺席的判定不成立，结论书面留档。第三，关口条件与关口交付物配对使用——交付物是证据，条件是判据，证据齐备且满足判据方才放行，二者缺一不成立。
表 5 给出五道关口。读法是先看「通过条件」一列判断能不能过，再看「应到场的证据」一列核对据以判断的材料在不在，最后看「不通过的处置」一列确认下一步往哪里走。这三列合起来回答的是同一个问题：这一阶段算不算完。
表 5 五道阶段关口的通过条件、证据与不通过的处置
| 关口 | 位置 | 通过条件 | 判定主体 | 应到场的证据 | 不通过的处置 |
|---|---|---|---|---|---|
| 一 底座关 | 准备与底座 → 首批加工 | 首批加工所需的数据源授权齐备且可取回样本；本体首版与工序字典通过口径检查节点；对象主键映射表与时间基准折算规则发版且可被各层调用；第一批数据标准与分类分级结论发布并生效 | 口径评审组（双方共同判定） | 源系统授权与接口开通清单、本体首版与评审纪要、主键映射表、时间基准折算规则、数据标准首批发文件 | 未开通的源系统启用离线导出过渡通道，所涉对象在数据卡登记为过渡来源；本体未过门的，相关批次暂不进标注，不以推定口径开工 |
| 二 首批关 | 首批加工 → 全面加工 | 首批冻结版本通过版本检查节点；十个加工环节的参数完成标定并写入作业规程；标注员间一致率达到约定下限；首轮质检与验证报告出具且结论指向明确 | 版本评审组（双方共同判定） | 首批冻结数据集版本及数据卡、质检报告、血缘清单、参数标定结论、一致率统计与仲裁记录 | 按归因定向回流整改后重新送审，放量计划相应顺延；不以降低门控阈值的方式放行首批 |
| 三 规模与版本关 | 全面加工 → 外部评测 | 当期承诺量达成且四个业务领域、四类用途子集逐格达标；数据卡字段齐备并与版本一致；血缘可追溯到源对象、规则与工具版本；送检批次清单与实际封装内容一致 | 版本评审组，评测组复核 | 按期冻结的版本及数据卡、规模统计的对象明细与计量规则版本、血缘清单、送检批次清单 | 当期未达量的在后续期补足并登记未达原因与补足计划；数据卡不齐备的退回补齐，不先送检后补 |
| 四 整改关 | 评测与验证 → 运营上线 | 高风险缺陷按招标文件要求全量检测并逐条关闭，未关闭即不予放行；中低风险缺陷整改任务逐条闭环；三个维度得分均达最低合格标准且综合总分不低于 85 分；复测重新抽样且原错例不再复现；11 个场景的可用性结论出具，未结项有责任人与期限 | 评测组与场景验证组，甲方会签 | 盖章评测报告、缺陷清单与整改台账、复测报告与抽样清单、场景验证报告与整改任务单、未结项登记表 | 复测未通过的继续立单，不进入移交；归因不明确的转专家库裁定，裁定后仍不明确的转入观察清单并在下一轮复验 |
| 五 验收关 | 上线试运行 → 最终验收与移交 | 建设内容建成并通过竣工验收；系统所有功能上线试运行无问题；数据集版本完成登记与挂牌，目录可检索、交付通道可用；非功能指标按承诺值实测达标；移交清单、培训记录与全过程资料齐备 | 招标方组织总体成果评估 | 竣工验收报告、试运行记录、登记与挂牌记录、非功能指标符合性说明与各项测试报告、移交清单、培训与考核记录、质量档案 | 继续完善直至验收合格；验收过程中双方存在分歧的，按合同约定友好协商解决 |
表 5 数据来源：关口位置依表 3 的阶段划分；底座与首批两关的判据依招标文件 3.2.6 总则的门控要求（b1215）；整改关的判据依 3.2.8.2.4 第四、五阶段（b2131 及以下）与综合总分要求（b2145）；验收关的判据依二次验收模式（b2226）与终验申请条件（b0545）。表中「全量检测」「逐条关闭」为招标文件对高风险缺陷的原文要求，我方以全量检测、台账逐条关闭、未关闭即阻断放行、人工审核兜底四项措施承接，并保留应急通道作为回退。
#### 4.3 各节自有关口如何汇入总关口
本卷各节分别设有自己的检查点：加工链上有七道质量检查节点，治理贯标有七个阶段的通过条件，标注规范分册有三道评审与培训准入，工具链按波次实测验收，质量评测有五道阶段关口，场景验证有五个把关点，非功能要求有三类验证时点。这些检查点各自成立，但若不说明它们与项目阶段的关系，阶段推进时就会出现两种结果：要么某一道检查在阶段关口上被遗漏，要么同一件事在两处被判两次而结论不一。下表给出对应关系，每一行回答两个问题——这一组检查点汇入哪一道总关口，以及它在总关口上以什么形式出现。
表 6 各节既有检查点与五道总关口的对应
| 各节既有的检查点 | 所属作业线 | 该节的判据要点 | 汇入的总关口 | 在总关口上的呈现形式 |
|---|---|---|---|---|
| 加工链七道质量检查节点（入口、预处理、口径、终审、标注、合成增强、版本） | 数据加工生产 | 各节点按统一指标体系判定，不通过项定位到环节与算子 | 口径节点汇入底座关；预处理、终审、标注三节点汇入首批关；合成增强与版本两节点汇入规模与版本关；入口节点贯穿各关 | 以节点通过记录与不通过项清单的形式呈现，作为版本可否送检的前置 |
| 贯标七个阶段的通过条件（现状调查、差距分析、制度发布、实际运行、内部审核、改进、正式评价） | 数据治理与贯标 | 过程域取证不少于两条独立证据；执行记录覆盖不少于两个考核周期；发现项全部有责任人与整改时限 | 前两阶段汇入底座关；制度发布汇入首批关；实际运行汇入规模与版本关；内部审核与改进汇入整改关；正式评价汇入验收关 | 以诊断报告、发文件与生效日期、运行记录抽样结论、内审发现项闭环率的形式呈现 |
| 标注规范十份分册的三道评审与培训准入 | 数据治理与贯标 | 三道评审依次通过不跳道；标注员试标一致率达准入门限方可上岗 | 通用分册汇入首批关；模态分册按加工批次顺序汇入规模与版本关 | 以分册发布版本与生效日期、培训考核记录的形式呈现，作为该模态标注可否开工的前置 |
| 9 类 25 个工具的分波次实测验收 | 工具链与平台 | 逐工具验证所需功能，检查任务创建、查询、结果、重试、导出、回调等接口与权限、异常、版本和追溯；以可运行实例的实测结果为准 | 第一波次汇入首批关；第二、三波次汇入规模与版本关 | 以逐工具的实测记录与验收结论的形式呈现 |
| 运营服务管理平台 17 项功能模块的上线前评审闸门 | 工具链与平台 | 功能上线前评审通过，整改单关闭 | 模块评审汇入规模与版本关；平台整体上线试用汇入验收关 | 以评审结论、整改单与关闭记录的形式呈现 |
| 质量评测五阶段的五道关口 | 数据集质量评测 | 准备经甲方确认、方案经审核、无指标漏检、高危清零、整体验收硬性标准 | 关口一、二汇入规模与版本关；关口三、四汇入整改关；关口五汇入验收关 | 以阶段产出物与关口条件配对核对的形式呈现 |
| 场景验证五阶段的把关点（基准终审、协议冻结、判分复核、归因确认、闭环签署） | 场景验证 | 基准题取自真实业务且不含合成数据；协议冻结后本轮不改；每个错样只归一个观测点 | 基准终审与协议冻结汇入规模与版本关；判分复核、归因确认、闭环签署汇入整改关 | 以基准分册冻结版本、评测协议版本、归因结论与闭环签署记录的形式呈现 |
| 非功能要求的三类验证时点（模块评审、上线验收、质保期复测） | 安全与非功能验证 | 按承诺值逐项实测，偏离承诺值按既定回退流程处置 | 模块评审汇入首批关与规模与版本关；上线验收汇入验收关；质保期复测在质保期内按节奏执行 | 以各项测试报告与符合性说明的形式呈现 |
表 6 数据来源：各节判据取自本卷与服务方案卷相应各节的原文口径；七道质量检查节点的设置依本卷技术方案总论；评测五阶段关口依招标文件 b2116、b2122、b2130、b2137；场景验证把关点依 3.2.6.3.9 与 3.2.3.10.1。
阶段检查会按表 6「汇入」列逐组点名核对：各节检查点是否已出结论、是否通过、不通过项去向是否已定。各节只判定一次，总关口做汇总与放行，不重复判定。
#### 4.4 不通过时的处置
关口不通过有三条处置原则。
第一条，不以降低阈值的方式放行。门控阈值、合格标准与指标判据一经确认即在本轮内固定，遇到不达标先走整改，整改确实不可行的走正式变更程序并说明影响，不在执行中悄悄调低。中途放宽的判据在验收时仍会被按原值核对。
第二条，关口不过不进，但下游可以做不依赖该关口结论的部分。整体停工等待的代价往往大于局部返工。做法是在关口未过时划出「不依赖该结论」的工作范围，在例行计划会上逐项确认后开工；划不出来的，如实延后并登记影响天数。
第三条，有条件通过只在明确界定的范围内适用，且必须带着未结项进入下一关口。某一项主要指标达到下限值但未达目标值时，可判有条件通过，但须同时登记差距、可用与不可用的范围、未结项、责任组与期限，并在下一道关口上重新核对其闭环情况。有条件通过不等同于验收通过，缺口在报告中明列，不以静默缩小范围的方式达成指标。涉及越权放行、引用不实、以已废止内容作为执行依据这三类情形的，不设有条件通过一档，出现即判不通过，整改后重测——这三者的后果不随比例递减。
下图把判据的来源与不通过时的去向画在一起：左侧是各节检查点，中部是总关口的汇总与放行，右侧是三类定向回流的去向。
##### 图 2 关口判据的来源、放行与不通过的回流去向
图 2 关口判据的来源、放行与不通过的回流去向。数据来源：三类定向回流依招标文件 3.2.6 总则（b1215）；有条件通过的登记要求依本卷场景验证各节的三级判据设置；处置原则依表 5 各关口的不通过处置栏。
#### 4.5 关口的核对方式
关口判定按清单核对，不以会议表态代替。核对输入为表 3 本阶段动作、表 6 汇入检查点结论、表 5 通过条件与应到场证据；按作业线逐组点名后对照通过条件勾选。
核对结论仅三种：通过，进入下一阶段并书面留档；不通过，阶段不结束，同时划出不依赖该关口结论的下游可开工范围；有条件通过，按第 4.4 节登记差距、适用范围、未结项、责任组与期限，并在下一道关口复核闭环。三种结论均须写明判定日期、在场双方代表与所依据证据清单；缺任一项则判定不成立。
核对会的召集、频次与会议记录格式纳入项目例会体系，在服务方案卷项目管理措施一节统一规定，此处不另设会议制度。关口核对会与阶段计划评审会分开召开且先后次序固定：前者未得出通过或有条件通过结论前，后者不发布阶段计划。
### 5、阶段交付物的验收判据
关口判的是阶段能否结束，交付物判的是单件成果能否被接收，两者是不同的判断。一批数据集版本可以在规模上达标而数据卡字段不全，一份评测报告可以结论齐备而原始记录不可复现——这类情形在阶段关口上容易被放过，因为关口看的是清单齐不齐，而不是每一件的内容立不立得住。各项成果的完整清单、数量、分期交付时点与各期的通过条件在项目交付成果一节逐件给出；此处给出的是接收任何一件成果时共同适用的判据，以及同一类成果多次提交时的版本口径。
无论哪一类成果，接收时都核三件事。其一可复算：成果中出现的每一个数字，都能由随附的明细与规则版本重新算一遍得到同一结果，算不出来的数字不接收。其二可对账：成果内部各项之间、成果与台账之间、成果与上一版本之间的关系能够逐项对上，分项与合计、增量与存量、合格与剔除三组关系在接收时即校验。其三可追溯：成果中的每一条记录都能指回它的来源对象、处理规则与执行版本，指不回去的记录按未完成处理，不计入合格量。
这三条看似抽象，落到每一类成果上核的是具体对象。下表按成果类别把三条判据各自要核的东西写明，用途是接收时照着核，不必每次重新商量「算不算合格」。表的读法是横着读：一类成果的三格都核得通，这一件才算接收；任一格核不通的，按该类成果在项目交付成果一节约定的退回口径处理。
表 7 三条共同判据在各类成果上的具体核法
| 成果类别 | 可复算：核什么 | 可对账：核什么 | 可追溯：核什么 |
|---|---|---|---|
| 数据集正式版本 | 按对象明细与计量规则版本重算 Token 数、条数、组数与各项占比，结果与数据卡所载一致 | 分项与合计、增量与存量、合格与剔除三组关系；封装清单与实际内容；数据卡字段与版本内容 | 每个样本可指回源对象标识、处理算子与参数版本、批次与执行实例 |
| 质检报告与血缘清单 | 各节点的通过率与不通过项计数可由节点判定记录重算 | 报告中的批次与台账登记的批次一一对应；不通过项计数与整改台账条数相符 | 血缘链条从样本到源记录主键或事件标识不断链，中间产物逐跳可查 |
| 质量评测报告与质量档案 | 分项得分与综合总分可由指标打分表与原始检测记录重算 | 复测结论对应重新抽取的样本清单；缺陷清单条数与整改台账关闭条数相符 | 每项结论可指回受检版本、检测方法、工具校准记录与复核人 |
| 场景验证报告与整改任务单 | 各项指标可由判分明细与抽样清单重算；同协议重跑机器判分部分结果一致 | 任务单条数与归因明细条数、复测记录条数相符 | 结论绑定基准分册版本、评测协议版本、模型与知识库版本 |
| 治理文档 | 份数与引用关系表所列一致，拆分合并有逐项对应 | 文档条款与治理平台的流程配置、稽核规则逐项对应 | 每份文件可查到送审稿、评审意见处理表、发文件与生效日期 |
| 工具链与平台交付件 | 实测结果可按同一组用例重跑得到同一结论 | 文档描述的接口与实例实测行为一致；平台的登记内容、权限、订单与审计记录相互对账 | 每次验收可指回被验的实例版本、部署环境与用例集版本 |
| 安全与非功能测试报告 | 报告中的指标值可由原始采样数据重算 | 测试环境配置与上线环境配置的差异逐项列明 | 每项实测可指回执行时间、负载配置、采集点与执行人 |
| 移交与培训资料 | 移交数量与交接清单、资产台账三处一致 | 移交清单与实际交付内容逐项核对；培训记录与考核结果对应到人 | 每项移交可查到点验记录、接收结果与接收时间 |
表 7 数据来源：三条判据依招标文件 3.2.6.3 对规模统计可复现、逐项对账与追溯关系的要求；血缘与版本绑定要求依 3.2.6 总则（b1215）；评测结果可追溯与实验可复现要求依 b2109。
#### 5.1 交付物的提交次序与版本管理
同一类交付物在建设期内会提交多次：数据集版本按期冻结、治理文档分批发文、工具链分波次交付、验证报告按场景分册出具。多次提交带来两个需要事先定死的问题——后一次提交与前一次是什么关系，以及验收时以哪一次为准。
关系上分三种。替换式提交，后一版整体替代前一版，适用于数据卡、数据字典、接口文档这类描述当期状态的件；提交时登记版本号与变更点，旧版留档备查但不再作为依据。累加式提交，各次提交互不覆盖、合并成册，适用于质检报告、验证报告、巡检记录这类按批次或按时点产生的件；合并后须保证各分册之间的编号连续、无缺号。修订式提交，在原件上出修订版并保留差异说明，适用于治理文档与标注规范这类发文件；修订版带新的文号与生效日期，已按旧版执行的记录不追溯作废，但受影响的在产对象按变更影响分析的结论处理。
验收时以哪一次为准，按交付物类别分别约定：数据集以最后一次封装并通过复测的正式版本为准，此前各期版本作为过程成果留档；治理文档以终验时生效的版本为准；工具链与平台以终验时实际运行的版本为准，其间的升级记录随附；报告类以最终汇总的完整册为准，各分册不单独验收。这一约定写在此处，是为了避免终验时出现「交过但不是这一版」的争执——交付记录证明的是提交行为，验收依据的是终验时的有效版本，两者在多次提交的情形下并不自动重合。
### 6、与质保期的衔接
#### 6.1 终验与质保期的交接
质保期为 12 个月，自甲方终验收合格之日起计算（b0541、b2215）。终验合格之日既是建设期的终点，也是质保期的起点，两段之间要交接的是三样东西：数据集的正式版本及其完整质量档案、平台与工具链的运行基线、终验时尚未关闭的未结项清单。前两样决定质保期内的技术工作以什么为基准，第三样决定质保期开始时手上还欠什么。
未结项清单这一项需要在终验时单独核对。建设期内按有条件通过放行的项、按范围回退单列的对象、以及在观察清单中待复验的归因争议，在终验时不会自动消失，它们随清单进入质保期并各自带着责任组与期限。终验时清单为空当然最好；不为空的，逐条写明当前状态、计划关闭时点与关闭判据，由双方签认后转入质保期跟踪，并随整改台账一并移交，台账的登记格式与移交办法在项目交付成果一节。这样做的用意是让质保期的工作有确定的起点，而不是在质保期内重新讨论建设期遗留了什么。
#### 6.2 质保期内的技术性持续工作
招标文件规定，服务周期内同步配套增量数据抽检与合规巡检常态化服务（b2109）。这类工作不占据实施路线上的某一段，而是与阶段三之后的全部工作并行，并在终验之后延续到质保期。我方在此基础上把质保期内与数据集和平台技术状态直接相关的工作归为五项，各自给出频次与判据。
归为五项而不是逐事罗列，依据是这些工作各自回答的问题不同：抽检回答新进数据的质量是否仍在合格线上，巡检回答数据的使用是否仍在授权范围内，复测回答系统的运行指标是否仍达承诺值，版本维护回答已交付的数据集是否需要修订，结论复核回答场景可用性结论是否仍然成立。五个问题互不替代，因此不能以其中一项的结果推断其余各项。
表 8 质保期内的技术性持续工作、频次与判据
| 工作项 | 频次 | 判据 | 不达标的处置 | 记录去向 |
|---|---|---|---|---|
| 增量数据抽检 | 按批次，并按月汇总 | 沿用评测期的分层抽样口径但重新抽样，不复用历史样本；抽检结果的各维度得分不低于交付版本的对应取值 | 低于交付版本取值的，按错因定位到环节并定向回流修复，修复后对该错因类别涉及的对象整批复检 | 进入质量档案的质保期分册，并在月度运行报告中列明 |
| 合规巡检 | 季度 | 数据来源授权在有效期内；分类分级标注与现行目录一致；出域记录与授权范围一致；第三方组件与模型的许可未到期 | 授权失效的对象暂停使用并通知甲方，补办授权后恢复；分级结论变更的，按新口径重新核定脱敏与出域范围 | 合规巡检记录，异常项进入整改台账 |
| 非功能复测 | 月度做备份恢复验证与运行指标巡检；季度做性能复测、容量复盘与安全复扫；半年度做故障注入演练与故障隔离复测 | 各项指标达到承诺值；复测方法与建设期一致，测法变更须单独记录并说明影响 | 指标偏离承诺值的按既定回退流程处置，先定位后整改，整改后复测；连续两次偏离的提交专项分析 | 运行报告，原始采样数据随报告留存 |
| 数据集版本维护 | 按触发事件 | 质保期内发现的数据缺陷按与建设期同一套错因分类与回流路径处置；修订后发布新版本并同步更新数据卡、血缘与登记信息 | 修订影响范围跨批次的，按血缘追踪全部受影响对象并整体复检；已被引用的版本采取受控暂停并通知使用方 | 版本变更记录与差异说明，旧版本与审计记录保留 |
| 场景验证结论复核 | 数据集版本变更时触发 | 按原评测协议、原基准分册版本对受影响场景复测；同协议重跑机器判分部分结果应一致 | 结论发生变化的，更新该场景的可用性结论并说明变化原因；不以口径调整的方式维持原结论 | 场景验证报告的质保期补充分册 |
表 8 数据来源：增量数据抽检与合规巡检依招标文件 b2109；非功能复测节奏依本卷非功能性技术要求一节的验证时点汇总；版本维护与结论复核的处置路径依 3.2.6 总则的定向回流要求（b1215）。
#### 6.3 质保期工作的边界与收口
上述五项是质保期内与数据集、平台技术状态直接相关的工作。质保期内的服务响应时限、三包范围、驻场陪产安排、免费技术服务期与后续年度技术服务，以及面向甲方各层级的培训安排，在服务方案卷售后服务方案一节给出；交付物的清点、移交与台账办理在项目交付成果一节给出。三处不重复约定，遇有交叉以售后服务方案的服务条款为准、以本节的技术判据为准。
质保期届满时出具质保期服务报告，内容为五项工作的执行记录汇总、期内发现与处置的问题清单、数据集版本的变更历史、以及期末的未结项状态。未结项在期满前逐条关闭；确有不能关闭的，写明原因、影响范围与后续安排，由双方签认后移交后续技术服务。质保期的结束以该报告经甲方确认为准。
### 7、与其他章节的边界
实施路线涉及的各项具体做法在本投标文件相应各节给出，此处只作时序与判据上的统一，不重复各节的方法论述。数据加工十个环节的作业方法与工具调用在本卷数据集加工生产各节；治理四段路径与七个执行阶段的详细安排在数据治理规划和实施服务一节；9 类 25 个工具的功能与验收口径在专项智能工具链各节；运营服务管理平台 17 项功能模块的设计在数据集运营平台一节；11 个场景的验证方案在专业场景与通用场景验证各节；质量评测的依据、指标、方法与实施过程在服务方案卷数据集质量评测方案一节；日历排期、工作分解、关键路径、资源曲线、里程碑与付款节点的对应在服务方案卷项目管理措施一节；各项成果的完整清单与数量在项目交付成果一节。
遇有同一事项在两处出现的，按就近原则处理：涉及做法的以该方法所属节为准，涉及时序与关口判据的以本节为准。
### 本稿待补材料清单
本节的结构与判据不依赖实名实据，可随卷提交。下列事项须在合同签署后、实施计划基准版本发布前由相应方确认，确认结果写入基准计划，本节的关口条件与判据不因此改变。
| 待补事项 | 需要谁提供 | 用途 |
|---|---|---|
| 合同正式签署日 | 招标方与我方商务 | 作为时间零点，据以把本节的相对时序折算为日历计划 |
| 竣工验收与最终验收的申请时限、确认方式与时限 | 甲方项目管理部门 | 关口五的判定程序与内部控制日期的设定 |
| 甲方口径确认方的部门与责任人设置（工序字典、部件层级、缺陷判定依据、指标定义） | 甲方数据管理办公室 | 关口一的判定主体与逾期处置的触发条件 |
| 第三方测评与认证机构的受理档期（质量评测盖章、等级保护测评、商用密码应用安全性评估、贯标评估） | 具备资质的承做机构 | 第四阶段的排期与复测余量的核定 |
| 甲方现行数据管理制度清单及版本号 | 甲方数据管理部门 | 合规巡检的判据基线 |
| 质保期内甲方的运行环境变更计划 | 甲方信息部门 | 非功能复测的环境基线与复测时点安排 |