跳转至

P3-1.2 数据建模按什么顺序推进

Section ID: P3-1.2 Version: v2026.07.20

一旦理解了数据建模到底想达成什么，接下来的问题就会立刻出现：实际工作应该按什么顺序推进？在样本单位还没定下来之前，特征没法先做；如果没有比较基准，连 output structure 也会跟着晃动。所以，数据建模最好被读成一种前段顺序：把后面会用到的结构，从前往后逐步固定下来。

在现实里，源数据一拿到手，人很容易先想把学习问题的外框定成 预测问题、分类问题、异常检测问题 之类的熟悉名字。但这种顺序常常会出问题，因为 一行到底表示什么、样本单位、比较基准、输出结构 都还没有先定住。

一般的机器学习工作，常被描述成问题定义、数据理解与准备、建模、评估这样的大流程。Part 3 聚焦的是其中更靠前的一段，尤其是 在 AI 学习开始之前，先把问题结构立起来的前段。所以这里把前段需要一起检查的内容归成下面六项来看。

  1. 先决定问题句。
  2. 先决定样本单位。
  3. 把原始日志重新整理成可比较的表。
  4. 设计特征和基准线。
  5. 区分输出结构和目标标签候选。
  6. 决定解释边界和保守表述。

这里最先要固定的是 样本、表、特征、比较、输出结构 彼此按什么顺序咬合。源数据收集、更完整的探索性数据分析、统计检验形式、模型训练与评估实验，后面都会再出现，但这些说明也要在这个前段结构先立住之后，才不会显得零散。

在官方文档里，这六项通常不是作为一个固定流程名一起给出，而更常以 task、example、feature engineering、label/target、preprocessing、classification threshold 这样的分散概念来解释。Part 3 做的事情，就是把这些分散概念重新收束成 学习开始之前如何阅读问题结构的顺序。

如果把这六项之间的连接压成一行，就是下面这样。

flowchart TD
    A[问题] --> B[样本单位]
    B --> C[汇总表]
    C --> D[特征与基线]
    D --> E[输出结构]
    E --> F[保守解释]

如果这组内容看上去还太抽象，和现实中很常见的 错误起步顺序 放在一起比较，会更容易理解。

起步方式 为什么一开始看起来像是合理的 很快会出现的实际问题
先定学习问题框架，而不是先定问题结构 预测、分类、异常检测这些熟悉词最先跳出来 因为还没定好一行到底是一个时间点还是一次动作，输入 X 本身就会摇摆
先急着抽特征 先把均值、最大值、标准差做出来，看上去像是进度很快 没有样本单位，就会不清楚这个值说的是 整个动作 还是 某一小段区间
先定阈值 业务里常常希望尽快定一个告警标准 没有基准线，就分不清 这个值本身大不大 和 它是否比平时不同
先固定问题和样本 一开始看上去会比较慢 后面的表、特征、基准线、输出结构都站在同一套标准上，晃动会少很多

Part 3 之所以先把这个顺序立起来，是因为后面的说明经常默认前面的判断已经做完。最常见的失败，就是 先把学习问题框架定好，再回头硬塞样本单位进去。一旦这样做，后面往往要把表重做、把特征重抽，连输出结构也得跟着重定义。比起这样来回返工，先在前面把判断标准整理好，通常反而更稳。

每个阶段各自在做什么，可以这样读。

阶段 核心问题 代表产物
决定问题句 想知道什么？ 比较问题或预测问题
决定样本单位 什么算一条案例？ 动作单位、区段单位、实体单位
重新整理表 原始日志应该怎样重新表达？ 摘要表、聚合表
设计特征和基准线 哪些值要留下，拿什么比较？ 特征列、基准线比较列
区分输出结构 人工复核和预测目标要怎样分开？ 告警、复核候选、目标标签候选
决定解释边界 该说到哪里，又该在哪里停下？ 保守表述、需要复核 标记

这些项目必须绑在一起，因为后面的说明经常默认前面的判断已经成立。样本单位没定，特征也会晃；特征一晃，基准线比较也会晃；比较结构一晃，连 需要复核 和 目标标签 都很难区分。

看一个小例子会更清楚。

  • 问题：最近的动作是不是比平时更不稳定了？
  • 样本：一次完整动作
  • 表：按动作汇总的均值、斜率、波动性摘要表
  • 特征：mid_flow_mean、late_drop_rate、flow_std
  • 基准线：比较最近 20 次和此前 200 次
  • 输出：需要复核 或 正常范围

在这个例子里，还没有出现任何具体的学习问题名称。即便如此，重要的数据建模决定其实已经几乎都放进来了。因为什么算一条案例、哪些值要留下、拿什么比较、最终产出什么结果，都已经定下来了。

如果再把同一个例子重新套回这六个阶段，就会更清楚每个阶段到底在决定什么。

阶段 这个例子里实际做出的决定
决定问题句 先决定我们要知道的是：最近动作是否比平时更摇晃
决定样本单位 不把单个传感器时刻当成一行，而是把一次完整动作当成一行
重新整理表 把逐时刻日志改造成按动作汇总的均值、斜率、波动性表
设计特征和基准线 建立 mid_flow_mean、late_drop_rate、flow_std 以及和平常区段对比的列
区分输出结构 把 review、normal 这样的复核结果，与后续目标标签候选分开
决定解释边界 不说成 已经确认异常，而说成 需要复核 这样的保守表述

读这张表时最关键的一点是：只要前面的判断有空缺，后面的判断通常也会一起变模糊。比如说，在样本单位还没定之前就先做特征，那么这个特征到底描述的是 某一个时点的波动，还是 整个动作的波动，就会开始含糊。

这六项并不是要替代后面说明的目录，而是为了让后面的说明不至于摇摆的顺序准绳。因为只要某一阶段空着，下一阶段也很容易跟着变模糊，所以 Part 3 最稳妥的读法，是先把 问题 -> 样本 -> 表 -> 特征和基准线 -> 输出结构 -> 解释边界 这一串咬合顺序固定住。也正因为如此，Part 3 与其说是在 学数据科学，不如说是在 设计一个可以学习的数据问题。这个视角一旦立住，后面会出现的样本设计、摘要表、特征设计、基准线比较，就不会再像零散技巧，而会开始被读成同一个问题设定流程。

来源与参考资料

  • Google for Developers, Machine Learning Glossary 中的 labeled example、feature engineering、label、label leakage。它说明 example、feature、label 的角色必须分别定住，因此支持本节的核心判断：问题、样本、表、特征、输出结构应该按顺序咬合来读。 https://developers.google.com/machine-learning/glossary / 确认日期: 2026-07-20
  • W3C, PROV-Overview. 它说明 identifying an object 和保留 derivation 都应可追溯，因此强化了这个上位框架：样本单位、派生表和结果结构应该能够按顺序解释清楚。 https://www.w3.org/TR/prov-overview/ / 确认日期: 2026-07-20
  • Usama M. Fayyad, Gregory Piatetsky-Shapiro, Padhraic Smyth, From Data Mining to Knowledge Discovery in Databases. 它解释了数据选择、预处理、转换、解释连续相连的更大流程，因此为 Part 3 的定位提供一般背景：这里聚焦的是 在学习之前按顺序固定问题结构的前段。 https://www.kdnuggets.com/gpspubs/aimag-kdd-overview-1996-Fayyad.pdf / 确认日期: 2026-07-20