P1-4.2 输入(input)、输出(output)与数据(data)¶

Section ID: P1-4.2 Version: v2026.07.20

4.1 已经把 model 说明成：它不是整个现实问题，而是为了某个目的而缩减出来的可计算表示。现在要进一步区分描述这个模型时最先拆开的三个元素：我们往里放什么、希望它产出什么、又需要收集哪些案例。

这一节整理 input、output 与 data。feature、representation 和 parameter 会在 4.3 再讲。

延续前面的例子，这里仍以 想用 AI 帮助处理客户支持消息 为主线。我们会不断轻微改写这个场景，去看输入、输出和数据是怎样彼此分开的。

在 Part 1 中，input、output、data、example 与 label 的基本区分会固定在这一节。model 与 system 的基本区分已经在 4.1 先整理过，feature、representation 与 parameter 的差异会在 4.3 继续细化。这里先专注于把 往里放什么、想得到什么 和 需要收集哪些案例 分开。

这时还不能算是建模任务，因为“帮助处理”这个说法太宽。必须先把这个宽泛说法拆成输入、输出和数据，模型才有可能接手一个更小的任务。

这一节整理以下问题：

• input、output 与 data 分别起什么作用？
• 为什么同一个现实问题，只要输入和输出定义不同，就会变成不同任务？
• 为什么 data 不能只被看成文件堆，而应该被看成一组 examples？

feature、representation 与 parameter 的关系会在紧接着的 4.3 回来，问题定义如何改变模型选择会延续到 4.4。输入和输出怎样进一步变成真正的特征与表征计算，则会在 Part 4 的机器学习章节和 Part 5 的神经网络章节里再次连接。这里先专注于分开 放进去什么 和 产出什么。

区分输入、输出与数据的基准¶

• 区分 input、output 与 data 的角色。
• 理解把现实问题读成“输入和输出之间的关系”这一视角。
• 看到：同一个现实问题，只要输入与输出定义不同，所需数据也会跟着改变。
• 理解数据不是单纯的文件集合，而是教模型学习标准的一组案例。
• 为 4.3 里的 feature 与 representation 做准备。

三个基准¶

当现实问题被缩减成可计算问题时，先要分开下面三个点。

input、output、data、example 和 label 是贯穿这一节的核心术语。现阶段只先留下一个大区分就够了：input 是放进去的信息，output 是想得到的结果，data 是案例集合，example 是其中一条，而 label 是期望答案的名称。下面正文会再把这些词绑一次。

这里尤其容易混淆的是 input 和 data。input 更接近模型现在为一次判断实际接收到的一条信息，而 data 更接近把许多这样的输入-输出案例收集起来形成的学习用集合。比如 配送什么时候到？ 这样一条消息可以是一条输入，而包含成千上万条此类消息及其正确分类的表格才是数据。

另外，一条输入并不一定只意味着一个值。我们可以只放入消息句子，也可以在需要时把 消息句子 + 订单状态 + 客户等级 + 最近配送事件 看成一次判断收到的一整组输入信息。在这一节里，只要把 input = 模型一次判断时看到的信息束 和 data = 许多这种输入束与输出案例的集合 分开，结构就会清楚很多。

把现实问题变成可计算形式¶

AI 模型不会直接处理整个现实问题。人必须先从现实里挑出一部分作为输入，再规定模型应该产出什么输出。

例如，我们想处理客户支持消息 还不是一个建模任务。它太宽、太模糊。

可以把它一步步收窄。

到了第三步，这件事才真正接近建模任务，因为这时我们终于能看见：什么是输入、什么是输出、需要什么过去案例。

要把它变成 AI 建模任务，通常要收窄成下面这样。

这样一来，现实任务就会被整理成下面这个结构。

input -> model -> output

flowchart TD
  R["现实世界问题"]

  R --> I["输入"]
  R --> T["目标输出"]
  R --> D["过去案例"]

  D --> L["训练"]
  L --> M["训练好的模型"]
  I --> M
  M --> P["对新案例的预测"]

这个图说明：我们不会把整个现实问题直接丢进模型，而是先拆成 input、target output 和 past examples，再通过学习和预测把它们连接起来。最上面的 real-world problem 仍然是宽泛现实问题，往下走时，模型真正会看到什么、又会被要求预测什么，都会变得更窄。读这个图时，最好不要把它看成“直接解决现实的机器”，而要看成“把现实问题切成可计算小任务的过程”。

Stanford Encyclopedia of Philosophy 的 AI 条目介绍了 Russell 和 Norvig 把智能体理解成“从环境接收 percepts 并执行 actions 的函数”的视角。这个视角在这里有帮助，因为它能帮助我们把 AI 问题读成输入和输出，或者说感知和行动之间的关系。

当然，这仍然只是为了学习而做的简化。真实服务里，输入之前可能还会有预处理、权限检查和个人信息去除；输出之后也可能接上人工复核、政策规则或业务系统联动。

input 是模型真正观察到的东西¶

input 是模型为作判断而接收到的信息。它可以是句子、图像、传感器值，也可以是表格数据。

定义输入时，一个重要点是：现实中重要的信息，不一定就是实际送进模型的信息。

把客服消息例子再展开一点。

如果是这样，模型就只能根据消息文本判断。即使配送状态对人很重要，只要它不在输入里，模型就无法使用。

例如，下面两条消息如果只看句子，可能会显得相似，但实际处理方式却可能不同。

所以，定义输入，就是在决定 要向模型展示什么。同时，也是在决定 不要向模型展示什么。

这就是为什么定义输入时需要追问下面这些问题。

模型实际上能看到什么信息？
这些信息足够支撑判断吗？
有没有重要但缺失的信息？
输入里是否包含个人信息或敏感信息？

input、output、data、example 和 label 很容易听起来差不多，所以这里先把它们按代表性基准绑一次，后面的输入与输出定义都以这个区分为前提继续阅读。

在这一阶段，只要先留下下面这个区分就够了：input 是放进去的信息，output 是想得到的结果，data 是这些案例的集合，而 label 是答案名称。

output 是交给模型的任务¶

output 是模型必须产出的结果。即使输入相同，只要输出定义不同，问题本身就会完全改变。

例如，同一条客户支持消息，也可以连接到很多不同输出。

所以，单说 用 AI 处理客户支持消息 还远远不够。还必须说清楚：模型到底要输出类别、数值、句子，还是一个是否复核的标记。不同输出形式会通向怎样的建模任务，会在 4.4 再单独整理。

假设输入句子是下面这样。

我昨天刚下单，但现在还查不到物流。

即使只是这一句，也会因为输出定义不同而变成不同任务。

这里真正重要的是：即使输入不变，只要输出变了，所需数据也会跟着改变。要做消息类型分类模型，就需要过去消息上有 配送、退款、换货 等标签；要做回复草稿生成模型，就需要高质量答复示例或答复编写标准。

定义输出时，需要追问下面这些问题。

模型是不是只要选一个类别就够了？
它需要输出数值分数吗？
它需要生成句子吗？
只给一个供人确认的中间结果是否已经足够？
这个输出真的和想解决的业务目标连接起来了吗？

data 是输入-输出案例的集合¶

data 是模型用来参考或学习的一组案例。在 supervised learning 中，通常会使用同时包含输入和期望输出的案例。

Google 的入门资料会把监督学习中的 example 解释成同时含有 features 和 label 的对象。在这一节里，可以先把它更简单地读成：一条 example 就是 input + desired output 的组合。

这个表虽然简单，但已经展示出很重要的结构。

example 1 = input 1 + output 1
example 2 = input 2 + output 2
example 3 = input 3 + output 3
...

如果把节奏放慢一点来说，数据就是展示给模型的一组过去案例。

当这种输入出现时，
人期待的是这种输出。

模型会通过这类重复出现的案例去调整输入和输出之间的关系。因为这一节还不会深入讨论特征，所以这里只要把数据理解成“把模型要看的输入和想得到的输出放在一起的案例”就够了。

创建数据时，同样需要把速度放慢。即使面对同样的客户支持消息，只要标签标准不断摇摆，模型就很难学稳。

像这样的数据也许作为文件是存在的，但很难算是好的学习数据，因为模型要学的标准一直在晃动。

更好的数据集，需要先把标签标准整理清楚。

学习式模型会利用这些案例去调整输入和输出之间的关系。但“有数据”并不自动等于“会得到好模型”。模型无法稳定学到数据里不存在的关系，也可能把错误数据中的错误关系一并学进去。我们需要检查数据是否代表真实使用环境、输出标签是否一致，以及有没有混入错误案例。

输入和输出一变，数据也会跟着变¶

一个现实问题并不总是对应一个固定数据集。数据集的形状会随着输入和输出的选择而改变。在这一节里，我们只先确认数据的形状；任务定义和评价标准会继续放到 4.4。

例如，想一想 我们想减少配送问题 这个目标。

这个例子说明：输入和输出的定义，会决定数据的形状。即使业务目标相同，不同的输入和输出选择也会需要不同数据。

换句话说，只说 多收集一些数据吧 还不够。必须先决定：这些数据到底是要教会模型哪一种输入和输出关系。

即使都挂在同一个“大配送问题”下面，只要交给模型的工作不同，数据形状也会随之改变。至于任务该如何定义、适合哪些模型候选、该用什么评价标准，会在 4.4 接着处理。

必须先检查输入和输出定义¶

模型出错的原因，并不总在算法上。输入或输出定义本身，可能从一开始就把问题框错了。4.2 这里只先把这一点作为预警来确认。

例如，假设目标是减少客户不满，但输入只使用消息文本，输出只预测消息类型。这个模型或许能完成消息分类，但它并不能直接解决客户不满到底是由配送延迟、商品质量还是退款政策造成的。

下面这些错误很常见。

数据是否贴近真实环境、部署后性能是否还能保持、敏感信息该怎么处理，会在后面的任务定义、评价和服务架构部分更详细展开。

用这种输入，真的能够判断这种输出吗？
这个输出和我们真正想解决的问题连得上吗？
这些数据真的代表模型将被使用的场景吗？

一个简短的角色区分练习¶

看下面这些案例，先判断它更接近 输入定义问题、输出定义问题，还是 数据定义问题。

这个练习的关键，不是把所有模型性能问题立刻看成算法问题。实际工作里，更早出问题的常常是 放进了什么、让模型去预测什么 以及 收集了哪些案例。

检查清单¶

• 我可以区分 input、output 与 data 的角色。
• 我可以把现实问题改写成 input -> model -> output 的结构。
• 我可以解释：即使输入相同，只要输出定义不同，所需数据也会变化。
• 我可以解释数据是一组输入-输出案例。
• 我可以解释数据会成为调整模型内部标准的依据。
• 我可以解释：如果输入和输出定义得不好，问题可能在准备数据之前就已经开始了。
• 我可以解释：现实问题不会立刻变成模型问题，必须先定义输入、输出和数据。
• 我可以解释：即使是同一个现实问题，只要输入或输出定义改变，所需数据也会跟着改变。

出处与参考资料¶

• Stanford Encyclopedia of Philosophy, Selmer Bringsjord and Naveen Sundar Govindarajulu, Artificial Intelligence, 2018-07-12, 确认日期：2026-06-22.
• Google for Developers, Supervised Learning, 确认日期：2026-06-22.