跳转至

P1-1.2 AI 处理的问题

Section ID: P1-1.2 Version: v2026.07.20

在 1.1 中，我们先整理了 AI 这个词的范围。这一节要继续往前走，看 AI 在这样一个宽广范围里，实际反复处理的是哪些类型的问题。

如果只把 AI 当成技术名字来读，规则式 AI、机器学习、深度学习、生成式 AI 彼此会像几个完全不同的世界。但如果改从问题形态来读，就会开始看见共同结构。大多数 AI 系统都会接收某种输入(input)，产生符合目标(objective)的输出(output)，并进一步影响人的判断或环境。

在 Part 1 中，分类、预测、推荐、生成等问题类型的基准区分，就固定在这一节。后面再出现这些词时，只会保留当前问题所需的最小连接；如果需要重新拆分问题类型本身，就回到这一节，以及 Concept Glossary (English)。

通过输入和输出划分 AI 问题

这一节整理以下问题：

  • AI 反复处理的典型问题类型有哪些？
  • 若从输入和输出来阅读问题，会看到什么共同结构？
  • 为什么同一份数据，只要问题一变，就会变成另一种 AI 问题？

这一节先固定 如何从输入和输出的角度划分 AI 问题。各类问题的算法与学习结构会在 Part 4、Part 5 和 Part 6 继续展开；这里集中建立 放进去什么、出来什么 这一问题定义标准。

区分问题类型的基准

  • 从输入与输出的角度区分 AI 问题。
  • 区分识别、搜索、预测、推荐、生成、控制等问题类型。
  • 理解同一个现实场景，会因问题定义不同而变成不同 AI 问题。

先连起来的概念

这一节也是和问题类型相关的术语第一次被系统放在一起的代表说明位置。下面这些概念先固定最短含义，之后再通过词汇表重新核对更完整定义。

概念 这里先固定的意思 为什么现在需要
recognition 从输入中读出对象或状态的问题 为了先区分比分类更宽的“读取”问题
classification 从预先给定的类别中选出一个的问题 为了固定一个“猜什么”很清楚的代表问题
prediction 根据当前信息估计未来值或结果的问题 为了区分“输出值或可能性”的问题与分类
recommendation 从多个候选中挑出接下来值得看的内容 为了看出 AI 不只是在生成答案
generation 生成新文本、图像、音频、代码的问题 为了固定为什么输出性质不同
input 系统接收的信息 为了从“放进去什么”开始阅读问题定义
output 系统产生的结果 为了按“出来什么”区分问题类型
goal 判断什么样的输出算好的标准 为了看到同样数据会因问题变化而变成别的问题

主要学习点

这一节先看问题的形状，再看算法名字。下面三条就是划分问题类型的基础地图。

基准 为什么重要 这一节需要达到的理解程度
AI 可以先通过 input 和 output 来读 这样即使出现完全不同的技术名字，也能先看见共同结构。 先能说清楚：放进去什么，出来什么。
同样的数据，只要 问题 一变，就会变成另一种问题 这样才看得见分类、预测、推荐、生成为什么会分开。 能区分：一份客户数据也能支撑好几类问题。
输出会对人或服务产生 impact 这样 AI 就不再只是抽象计算，而是现实判断结构。 能用一句话把输出和它被使用的地方连起来。

input、output、goal、impact 在上一节已经出现过，作为阅读 AI 系统的基本语言。这里则把它们重新接到问题类型上。输入是系统接收的信息，输出是系统产生的结果，目标是界定“什么样的结果算好”的标准，而 impact 则表示这个结果最后会碰到人的判断或环境变化的哪个位置。如果这些词再次不稳定，就回到上一节和 Concept Glossary (English)；在这一节里，它们主要是帮助我们把问题读成“放进去什么、拿出来什么”的结构。

细化学习

为什么先按问题类型来读

如果一开始就从算法名字重新学 AI，很快就会变得复杂。即使面对同样的图像数据，一个系统也许是在判断“是不是猫”，另一个系统是在找出物体位置，还有一个系统则是在生成新图像。

因此，第一问不该是“它用了什么技术”，而是“它接收什么作为输入，又想产生什么作为输出”。这个问题能让规则式系统、机器学习模型、深度学习模型和 LLM 服务重新坐在同一张地图上。

AI 常处理的问题类型

下表列出本书会反复用到的问题类型。它是一张学习地图，而不是完整分类表。

问题类型 英语表达 输入 输出 例子
识别 recognition 图像、音频、文本、传感器数据 对象、状态、意义 从图像中识别物体、理解语音命令
分类 classification 数据和候选类别 类别或标签 把邮件分成垃圾邮件/正常邮件
聚类 clustering 无标签数据 相似项目的分组 寻找客户群、文档归组
预测 prediction, regression 历史数据、当前状态 未来值、分数、概率 需求预测、故障风险预测
搜索与规划 search, planning 可能状态与目标 路径、顺序、行动计划 下棋找下一步、安排访问顺序
推荐与排序 recommendation, ranking 用户、项目、上下文 推荐列表、优先顺序 商品推荐、帮助文档排序
生成 generation 指令、条件、示例、上下文 新文本、图像、音频、代码 写句子、生成图像、生成代码草稿
控制与行动 control, action 状态观测、目标、反馈 行动、策略 机器人转向控制、红灯前减速、游戏角色移动

这张表最重要的一点，是 问题类型 不等于 实现方法。例如，分类 可以用人工写规则来做，也可以用机器学习模型做，还可以用深度学习模型做。反过来，一个 LLM 服务内部也可能同时串着生成、检索、推荐、工具调用和安全过滤。

初学者最容易混淆的一对，是 recognition 和 classification。识别是更宽的问题：从输入中读出“有什么”“是什么状态”“意味着什么”。分类则更像是在预先给定的类别里选一个结果。比如，看图片后回答“猫”，可以看成分类；但如果还要找出猫的位置、描述表情，或同时读出多种物体，那就更自然地属于更宽的识别问题。这里不需要把区分背成考试答案，但保留“识别更宽，分类是其中一个代表任务”的感觉，会在后面处理图像、音频和文本时派上用场。

本节不会把所有问题类型在这里一次性讲完，而是先连到它们在后面会被更完整重读的位置。

现在先固定的问题类型 之后更完整重读的位置 为什么在当前阶段要先记住
分类、预测、聚类 Part 4 因为机器学习最终就是在学习如何把问题改写成预测式问题
图像、音频、序列等复杂输入的识别 Part 5 因为深度学习结构为什么必要，会从数据结构角度再读一次
生成、检索结合、工具执行 Part 6 因为 LLM、RAG、agent 会在那里按“生成什么、从外面拿什么”继续展开
规划、控制、行动 Part 1 补充学习与 Part 7 的小系统视角 因为当前这本书更重视先抓住 input-judgment-action 结构，而不是立即进入完整控制理论

同样的数据也会变成不同问题

AI 问题并不是由“数据本身”直接决定的，而是由“你把它变成什么问题”来决定的。

假设我们有一份客户购买数据：

问题 问题类型 可能输出
这个客户是不是快要流失了？ 预测 流失概率
和他相似的客户买了什么？ 推荐 推荐商品列表
能把客户分成多少组？ 聚类 客户群组
下个月销售额大概是多少？ 预测 销售额估计值
能不能把客服对话总结出来？ 生成 摘要文本

这个视角会在 Part 2 与 Part 3 变得重要。在真正深入数学或软件之前，先练习把现实问题改写成有输入和输出的问题，是更基础的工作。

通过输入和输出来读

Poole 和 Mackworth 的开放教材，会把 agent 解释为在环境中行动的实体，并提供一种“黑箱(black-box)”视角：优先从输入和输出来阅读 agent。这种视角的价值，在于它让 AI 问题先以“放进什么、拿出什么”被看见，而不是先被技术名字盖住。

按照这个标准，AI 系统本质上仍然是带有输入和输出的计算结构。请求、观测值、传感器数据、网页请求等进入系统，随后在内部经过处理，变成回答、命令、推荐或行动等输出。

不过，AI 和普通软件函数往往不同的一点在于：输出规则未必全都由人显式写死。传统函数更依赖人写出的条件与流程，而学习型 AI 则更多依赖从数据中得到的模式、参数、统计关系和学到的表征。因此，即使表面上都符合 input -> processing -> output 结构，内部处理方式和验证方法仍会不同。

这里的重要点，不是夸张地说 AI 会 完整复制人的工作流程，而是要看：某个输入被转成了什么输出问题，以及这个结果究竟自动化到了什么程度。

问题定义先于模型

在构建或理解 AI 系统时，问题定义先于模型。若问题定义本身不稳定，就算模型很强，结果也很难解释。

最少应包含以下要素：

  • 输入：系统接收什么？
  • 输出：系统要产生什么？
  • 目标：什么样的结果才算好？
  • 约束：时间、成本、安全、隐私、版权等限制是什么？
  • 影响：输出会怎样影响人的判断或真实环境？

OECD 对 AI 系统的说明，也会把输入、目标、输出和对环境的影响放在一起看。沿着这个视角，本书读 AI 时，不会首先问“它像不像人”，而是先问“它把什么问题转成了可计算形式，又会输出什么”。

问题类型之间会相互重叠

真实 AI 服务往往并不只对应一种问题类型。

例如，一个帮助中心搜索服务，从外面看像一个整体，但里面可能已经串起了好几类问题：

阶段 问题类型 小型工作场景
读取问题句子 识别或语言理解 看懂“我的退款怎么还没到”表达的意图
找候选文档 搜索 先收集 20 篇相关帮助文档
决定显示顺序 排序 把退款政策文档放在最上面
写回答句子 生成 回答“退款通常会在三个工作日内完成处理”

控制与行动也是如此。与其从整个自动驾驶的大抽象开始，不如先从更小的场景读起：

情况 先看到的问题类型 小型工作场景
机器人移动 控制 沿地面线移动时稍微减速
驾驶辅助功能 预测 + 控制 因为前车可能会停，所以先开始减速
游戏角色移动 行动选择 为躲开障碍向左移动

因此，问题类型并不是僵硬的分类表，而是分析工具。只要你能看到一个系统怎样把多个问题绑进一条流程里，宽泛的 “AI” 就会变得更容易拆解和理解。

flowchart TD
  Reality[现实中的问题]
  Problem[问题定义]
  Input[输入]
  Model[计算过程]
  Output[输出]
  Impact[影响]

  Reality --> Problem
  Problem --> Input
  Input --> Model
  Model --> Output
  Output --> Impact

这张图表示：现实中的大问题，并不会直接变成模型问题，而是先被切成 问题定义、输入、输出，然后结果才会进一步影响人或环境。这里最核心的是三步：现实问题 -> 可计算问题 -> 结果影响。

案例与示例

案例 1. 同一份客户数据，不同问题

假设有一份客户购买数据。人最开始常会觉得：既然数据只有一份，那么 AI 问题也应该只有一个。但如果问“这个客户是否会流失”，它就是预测问题；如果问“类似客户买了什么”，它就是推荐问题；如果问“能不能总结客服对话”，它又变成生成问题。这个案例说明：决定问题类型的，不是数据长什么样，而是你向它提出了什么问题。

案例 2. 一个搜索服务里混着多个问题

假设用户在产品手册网站里提问：“我的退款什么时候完成？” 从外面看，这像一个搜索框；但内部可能已经串起了问题理解、文档检索、排序和回答生成。这个案例说明：真实服务经常不是在处理单一 AI 问题，而是在把多个问题类型绑成一条工作流。

本书会反复使用的问题

之后看到新的 AI 案例时，就按下面的顺序去读：

  • 这个系统要处理的现实问题是什么？
  • 输入是什么，输出又是什么？
  • 输出更接近分类、预测、推荐、生成、规划还是控制？
  • 正确性或评估标准是怎么定的？
  • 若结果出错，会带来什么风险？

这些问题并不是为了把技术说得过于简单，而是为了把复杂 AI 系统拆成多个问题类型，便于检查。

一个简短的问题类型判断练习

下面这些场景，是用来练习区分“放进去什么”“拿出来什么”“更接近哪一种问题类型”的：

场景 输入是什么？ 输出是什么？ 先尝试贴上的问题类型
用本周订单量估算下周库存 历史订单量、活动安排、当前库存 下周预期订货量 预测
从客户问题中先选出最相关的三篇帮助文档 问题句子、文档列表、搜索分数 顶部文档列表 搜索或排序
把客服通话记录压缩成三句话 原始通话记录、摘要指令 摘要句子 生成
根据工厂传感器值提醒异常状态 温度、振动、电流等传感器值 正常、警告、需检修 分类或识别

这个练习的重点，不是记住标准答案，而是亲自确认：即使面对同一类工作数据，只要问题从“预测数量”换成“排序优先级”“生成新句子”或“判断状态”，AI 问题就已经完全不同。

检查清单

  • 你可以用输入和输出的角度解释 AI 问题。
  • 你可以用例子说明识别、分类、预测、搜索、推荐、生成、控制之间的差异。
  • 你可以说明：同样的数据也会因问题不同而变成不同 AI 问题。
  • 你可以区分问题类型与实现方法不是一回事。
  • 你可以说明为什么应先检查问题定义，再去看模型。
  • 你可以说明：AI 问题应先按输入和输出来阅读。
  • 你可以说明：同样的数据，只要提问不同，就会变成预测、推荐、生成等完全不同的问题。
  • 你可以说明：真实服务会把搜索、排序、生成等多个问题类型放进同一条流程里。

来源与参考