数据采购
Agent 训练数据试采应该如何验收
试采应先判断数据是否适配当前流程以及能否可靠验收 同时明确哪些问题需要另行训练实验才能回答 一个展示效果良好的 Demo 无法直接证明后续模型提升
先写一页能力需求
说明目标行为 当前失败模式与计划用途 明确需要专家示范 任务包 轨迹还是可运行环境 同时写明接入格式以及样本进入处理流程前所需证据
不要只按总量描述需求 应先定义计数单位 一个任务 一次尝试 一条成功轨迹和一个环境实例并不能直接等同计算
按关键维度组织试采样本
| 维度 | 为什么需要覆盖 |
|---|---|
| 任务类型 | 观察修复 创建与恢复任务的差异 |
| 环境复杂度 | 检查简单环境与多依赖环境的初始化 |
| 结果状态 | 检查完成 失败与中断记录 |
| 证据形式 | 检查日志 截图 文件与验证结果的接入 |
| 来源与用途范围 | 确认是否覆盖计划使用场景 |
独立完成接入与复验
从约定矩阵选择样本并通过真实流程加载 检查 Schema 证据引用 任务版本和缺失字段 对可运行交付还需恢复环境并执行约定检查 记录人工修补步骤 不要默默修好后再报告成功
将发现的问题分为交付缺陷 任务设计歧义 环境故障和 Agent 结果 便于供应商采取对应修正 避免把环境缺陷误认为模型能力不足
把数据验收与模型实验分开
交付验收可以检查必需字段是否齐全 引用是否有效以及约定检查能否复现 这些属于数据交付属性 模型提升则需要另行实验 并明确基线 训练设置与留出评测
应在检查最终批次前约定阈值并解释分母 例如区分可正常启动任务占交付任务的比例 与完成目标的尝试占已启动尝试的比例 本文提出审核方法 并未报告实测试采结果
形成可以执行的试采结论
结论应记录已接受范围 待解决问题 所需修正及下一批次需要的证据 小范围试采成功只支持已验证条件内的扩展 可通过 Demo 沟通约定这些条件以及新增任务类型的审核方式