高质量数据集建设经常从数据盘点开始：有哪些业务系统可以接入，能够汇聚多少历史记录，哪些字段需要清洗，标注需要投入多少人力。数据规模、处理效率和标注数量由此成为项目启动阶段最先被讨论的问题。

这些问题固然重要，却不是高质量数据集建设真正的起点。

如果项目尚未说明数据究竟要支撑什么业务判断、形成什么模型能力，即使数据采集得再全面、治理得再规范、标注得再精细，也可能只是形成一个质量较好的数据集合，而不是一个真正面向任务的高质量数据集。

第一篇文章已经建立了高质量数据集建设的总体框架：以业务问题为起点，经过任务建模、证据设计、数据准备、样本建构、答案构造和能力验证，将分散的数据持续转化为可以被模型学习和应用的能力。本篇继续向下展开其中的第一个关键环节——任务建模。

任务建模要解决的，不是给项目起一个更专业的名称，而是完成从业务世界到数据世界的第一次转换。

现实项目通常沿着一条看似自然的路径启动：先盘点现有数据，再分析这些数据可以支持哪些应用，随后选择算法、组织样本并开展模型训练。

这种路径容易推进。数据库、业务表、系统接口和历史记录都是现实存在的，围绕现有数据开展工作，可以快速形成数据清单和阶段成果。但它也隐藏着一个根本性问题：项目可能逐渐从“业务需要解决什么问题”，转向“现有数据能够做什么”。

建设边界开始由数据资源决定，任务目标则在实施过程中不断迁就现实条件。最终形成的模型也许能够完成某种分类、预测或生成，却未必真正对应业务中的关键问题。

例如，“提升设备运行安全”是一项业务目标，“建设设备故障预测模型”看似已经进一步明确，但它仍然不能直接指导数据集建设。建设者还需要知道：预测对象是一台设备、某个部件，还是一次运行事件；模型在什么时间点作出判断；需要预测哪一类故障；预测提前量是多少；结果用于安排检修、调整运行参数，还是仅供人工参考。

这些问题没有回答之前，“故障预测”仍然只是一个能力方向，而不是一个完整的数据集任务。

任务定义不清，并不意味着后续工作无法开展。相反，数据采集、清洗、标注和模型训练往往都可以正常推进。真正的问题在于，各个环节可能分别完成了自己的工作，却共同生产出一个无法支撑真实业务决策的数据集。

业务目标、应用场景、决策问题、模型任务和数据集任务，在项目实践中经常被混合使用。它们彼此关联，却解决不同层面的问题。

“降低运营风险”“提高服务效率”“提升产品质量”属于业务目标。它们说明组织为什么要开展建设，但并没有说明问题发生在哪里，也没有规定模型具体承担什么作用。

“设备运行监测”“客户服务”“智能审核”属于应用场景。场景限定了问题发生的业务环境、参与主体和流程条件，但一个场景中通常包含多个不同的判断和操作，仍然不能直接对应一个数据集。

“异常识别”“风险预测”“知识检索”“方案生成”属于模型任务。它们确定了模型参与业务的能力形式，却还没有明确模型面向什么对象、能够使用哪些信息、需要输出什么结果，以及在什么条件下运行。

只有当任务对象、输入条件、输出形式、时间范围、使用条件和评价目标进一步明确后，模型任务才真正转化为数据集任务。

因此，从业务问题到数据集任务，不是一次简单的语言翻译，而是一个连续收敛的过程：业务目标确定建设方向，应用场景限定问题环境，决策问题定位模型作用点，模型任务确定能力形式，数据集任务建立数据生产边界。

图中所呈现的并不是一条普通项目流程，而是业务问题逐步提高确定性的过程。越靠近业务目标，问题范围越宽泛；越靠近数据集任务，对象、输入、输出和时间条件越具体。

能力验证目标也应当在任务建模阶段同步考虑。它不是当前阶段立即开展的模型评测，而是提前明确：未来以什么指标、什么场景和什么业务结果证明任务成立。验证目标不清，数据集任务仍然缺少可被检验的终点。

业务问题通常具有综合性。它可能同时涉及效率、质量、安全、成本和服务体验，也可能横跨多个部门、系统和流程。数据集任务则必须足够具体，否则无法确定数据边界、样本单位和正确答案。

任务建模首先要把业务目标放入具体场景。脱离场景讨论“风险”“质量”或“效率”，这些概念往往过于宽泛。只有进入具体流程，才能识别问题发生的主体、条件和环节。

其次，需要寻找真正的决策节点。人工智能并不是在整个业务过程中抽象地发挥作用，而是在某个时间点帮助人或系统完成判断、选择或执行。模型是在事件发生之前预警，还是在事件发生过程中识别状态；是在人工决策之前提供建议，还是在操作完成后进行复核，都会改变数据集的结构。

在此基础上，决策问题还要被转化为模型能够处理的能力形式。识别、预测、检索、排序、生成、推荐和工具调用，对数据的组织方式并不相同。

最后，模型任务继续收敛为数据集任务。数据集不能只写明“进行风险预测”，而要进一步说明针对什么对象、观察多长时间的信息、预测什么结果、结果对应哪个时间范围，以及怎样判断预测有效。

一个任务只有名称还远远不够。数据集任务必须建立一组相互关联的基本边界。

任务对象决定一条样本围绕什么形成。对象可以是人员、设备、订单、事件、文档，也可以是一段完整的任务执行过程。对象不清，数据关联关系和样本粒度就无法稳定。

输入条件决定模型在真实运行时能够看到什么。这里不仅要规定可以使用哪些信息，还要明确哪些信息在判断时点尚未产生，哪些信息会直接透露结果，哪些信息虽然历史上存在，却无法在实际运行环境中持续获得。

输出形式决定什么样的结果被视为任务答案。类别、分数、排序、文本、方案、工具动作和执行轨迹，对答案构造的要求完全不同。

时间关系决定观察窗口、判断时点和结果窗口之间的边界。尤其在预测类任务中，时间边界一旦模糊，结果发生后形成的信息便可能被错误地放入模型输入，造成答案泄漏。

使用条件限定任务由谁使用、在什么系统和业务环境中运行，以及在哪些对象、地区、规则和数据条件下有效。

评价目标则回答如何证明任务成立。不同任务对误报、漏报、事实错误、错误推荐和错误执行的容忍程度不同，不能用单一指标覆盖所有业务后果。

除了上述边界，还必须明确排除范围，即当前任务不解决什么、不覆盖哪些对象、不适用于哪些场景。

任务边界并不是为了增加项目文档，而是为了建立后续数据生产共同遵守的范围。边界越清楚，证据设计和数据准备越容易收敛；边界越模糊，数据集越容易在建设过程中不断扩张。

真实业务问题往往无法由一个模型任务独立解决。

“提升设备安全管理能力”可能同时包含运行状态识别、故障风险预测、异常原因分析、维修知识检索、处置方案生成、工具调用和结果复核。“提高客户服务能力”也可能涉及意图识别、知识检索、答案生成、业务办理和服务质量复核。

如果把这些能力全部压缩进一个“大而全”的数据集中，不同任务所需的输入、答案和评价方式就会相互混合。模型即使取得较高的总体分数，也很难说明究竟形成了哪一种能力，更难定位问题来自哪一个环节。

因此，复杂业务问题不是一个更大的任务，而是一组相互关联、边界不同的任务。

有些任务负责识别当前状态，有些任务预测未来结果，有些任务补充知识依据，有些任务形成行动建议，还有些任务直接调用业务系统完成操作。它们可能串联运行，也可能并行提供能力，还可能根据业务条件被选择性触发。

图中的设备安全管理只是用于说明任务体系的通用逻辑，而不是限定方法论的行业范围。无论面对工业、医疗、金融、政务还是知识服务场景，都需要区分不同任务的输入输出、数据特征和评价方式。

对于智能体场景，这种拆分更加重要。智能体完成一个任务，可能需要理解目标、补充条件、规划步骤、检索依据、调用工具、处理异常并复核结果。最终答案只是任务结果的一部分，过程中的状态和动作同样需要被数据化。

任务建模不是数据准备之前的一次需求确认，而是后续整个数据生产过程的约束来源。

任务对象决定需要关联哪些数据主体；输入边界决定证据设计需要寻找什么信息，同时排除哪些不能使用的信息；时间边界决定数据如何截取和组织；输出形式决定答案如何构造；评价目标决定验证集和测试集如何设计。

任务建模对后续环节的约束并不是一次性传递，而应当贯穿整个建设过程。

在证据设计阶段，需要根据任务输入和判断逻辑识别模型应当依赖的信息；在数据准备阶段，需要依据任务对象、来源范围和时间条件组织现实数据；在样本建构阶段，需要围绕任务粒度和观察窗口形成问题单元；在答案构造阶段，需要根据输出形式和正确性要求建立答案标准；在能力验证阶段，则要检验数据集是否真正支撑了预期任务。

如果验证结果不达标，问题并不一定只出在模型或数据质量上。它也可能意味着最初的任务边界不合理、决策节点选择错误，或者预期输入在真实业务中无法获得。此时，验证结果需要重新返回任务建模，推动任务定义再次收敛。

这也是任务建模与普通项目需求分析之间的重要区别。需求分析往往在项目启动后逐渐退出，任务建模则必须伴随数据集版本持续存在。业务场景、数据条件或模型使用方式发生变化时，任务边界也需要被重新审视。

高质量数据集建设并不从数据开始。

在数据被采集、治理和标注之前，建设者首先需要明确：模型将在什么业务环境中，面向什么对象，在什么时间点，完成什么判断或行动；真实运行时能够看到什么信息，需要输出什么结果，又将在什么条件下证明能力成立。

只有业务目标经过场景定位、决策分析和任务收敛，才能成为真正的数据集任务。也只有任务边界稳定之后，数据集的质量才不再是抽象的数据属性，而能够体现为对特定模型能力的有效支撑。

从业务问题到数据集任务，是高质量数据集建设发生的第一次关键转换。