跳转至

P1-4.4 问题定义如何决定模型

Section ID: P1-4.4 Version: v2026.07.20

4.1 把模型看成是为了某个目的而缩减出来的可计算表示；4.2 整理了输入、输出和数据；4.3 则说明输入会被转成特征和表示，再和内部参数一起参与计算。

这一节把前面的脉络收束成一个问题：现实目标应该怎样被定义成一个 AI 问题？

问题定义看起来像是在建模之前做的文档工作，但实际上，它会一起决定模型类型、需要什么数据、用什么评价标准，以及输出怎样接到真实业务流程里。如果问题定义本身摇摆不定，就算用了很强的算法，结果也可能偏掉。

在 Part 1 里，task definition 以及“如何把现实目标改写成建模任务”的基本基准，就在这一节固定下来。model、input/output/data、feature/representation/parameter 的基础意义已经在 4.1 到 4.3 先搭好了；这里则把注意力放到：这些元素应该被组合成什么任务，以及什么才算做得好。

4.4 不是用来计算模型评价指标公式的章节。准确率、精确率、召回率、损失函数等指标的详细计算，会在 Part 4 处理。

4.4 也不是设计完整 AI 服务架构的章节。路由、权限检查、人工复核、工具调用和上线后的监控，会在 P1-14 和 Part 7 处理。

这里先只处理更前面那一步：把现实目标定义成哪一种输入-输出问题，以及决定什么才算做得好。

把现实目标转成建模任务的基准

  • 区分现实目标和建模任务。
  • 理解同一个现实目标也可能拆成多种不同的 AI 问题。
  • 看到输出定义会连带改变数据、模型和评价标准。
  • 理解模型表现和业务表现并不总是一回事。
  • 在 Chapter 4 的结尾，整理“把问题变成模型”到底是什么意思。

三个基准

在挑算法之前，先把下面三件事分开。

基准 为什么重要 这一节需要达到的理解程度
现实目标和建模任务不是同一个东西 这样才不会夸大 AI 真正解决的范围。 把 提升客户满意度 和 给客服消息分类 区分成不同层级。
同一个目标可以变成多种输出定义 这样能看清分类、分数预测和生成为什么会分岔。 固定“必须先决定模型要输出什么”这一点。
输出定义会连带改变数据和评价标准 这说明在选模型之前，问题设计本身就已经很关键。 理解只要输出改变，所需案例和成功标准也会一起改变。

现实目标、建模任务、输出定义、评价、业务表现 彼此关联，但它们不是同一个东西。

术语 很短的意思 这一节里的角色
现实目标 我们真正想改善的外部问题 说明模型为什么需要存在的起点
建模任务 被缩窄后交给模型处理的计算问题 分类、分数预测、生成等形式
输出定义 模型必须产出的结果格式 决定要收集什么数据、看什么指标的基准
评价 检查模型输出有多准确的标准 准确率、召回率、分数误差等判断框架
业务表现 模型接入后真实工作有没有变好 速度、成本、安全性、客户体验等外部结果

这里最重要的位置区分是：现实目标是外部问题，建模任务是缩窄后的计算问题，输出定义是我们让模型做的事，评价是检查模型，业务表现是真实结果。

现实目标还不是建模任务

我们想把客服消息处理得更好 是一个现实目标。但只有这句话，还不能直接告诉模型它该做什么。

要变成建模任务，它必须被改写成更具体的形式。

现实目标 改写后的建模任务表达
我们想把客服消息处理得更好 根据客服消息文本分类消息类型
我们想减少配送问题 根据订单信息预测配送延迟风险
我们想减少重复客服工作 根据消息和政策生成回复草稿
我们想减少风险交易 根据交易信息输出风险分数

Google 的 Machine Learning Glossary 把 task 说明成：可以用机器学习方法解决的问题，并举出分类、回归、聚类、异常检测等例子。

所以，问题定义做的，就是把现实目标变成这样的任务形式。

real-world goal -> modeling task -> input / output / data / evaluation

这不只是一个规划句子，而是后面用来稳定模型候选和数据收集范围的基准。这里最核心的理解是：现实问题不会被直接塞进模型里，中间一定先有一次任务定义。

同一个目标也可以变成很多不同任务

即使目标同样是“帮助处理客服消息”，只要我们要求模型产出的东西不同，它就会变成不同问题。

交给模型的任务 输出 任务性质
选出消息类型 退款、配送、换货、其他 classification
预测紧急程度 1 到 5 的分数 regression 或分数预测
推荐负责团队 物流、支付、客服 classification 或 recommendation
写回复草稿 自然语言句子 generation
判断是否需要人工复核 是 / 否 binary classification

Google 的 Machine Learning Glossary 把分类模型说明成预测类别的模型，把回归模型说明成预测数值的模型。这个区分在入门阶段非常重要。因为当输出是类别、数字或句子时，模型需要学到的是不同类型的关系。

例如，就算输入句子相同，只要输出定义改了，问题就会完全不同。

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

输出定义 可能输出 所需数据
消息类型分类 配送 消息文本和消息类型标签
紧急程度预测 2 消息文本和紧急程度分数
回复草稿生成 物流信息同步可能需要一些时间…… 消息、订单状态、政策和好回复样例
是否需要人工复核 否 这条消息以及“自动处理是否安全”的标签

即使输入句子相同，只要输出改变，需要的数据和评价方式也会一起变。所以在问 该用什么模型？ 之前，必须先问 模型到底应该输出什么？

在实际工作里，就算目标相同，不同团队也常常会先想到不同的输出。运营团队可能会想：先自动打上消息类型；管理者可能会想：先把紧急消息顶上来；写作支持团队可能会想：先生成回复草稿。这三种想法都来自同一个“把消息处理得更好”的目标，但真实的建模任务会分成分类、分数预测和生成。这样的分岔不是问题，问题定义真正要做的，就是把这些差别明确写下来。

输出定义会改变评价指标

一旦决定了模型要输出什么，接下来就必须决定什么才算做得好。

Google 的 Machine Learning Glossary 把评价解释成：测量模型质量或比较不同模型的过程，也把指标解释成我们关心的统计量。

scikit-learn 的模型评价指南则指出，选择评价函数时，应从最终目标和预测被使用的语境出发。它还区分了 prediction 和使用该预测进行的 decision making。4.4 接受这个视角，把指标不仅和模型输出联系起来，也和输出会被用在什么地方联系起来。

在客服消息例子里，评价标准会随着输出定义改变。

输出定义 可能看的评价标准
消息类型分类 准确率、精确率、召回率、混淆矩阵
紧急程度分数 真实紧急程度与预测分数之间的差距
回复草稿生成 事实性、政策合规、语气、安全性、人工复核结果
是否需要人工复核 模型能否抓住那些绝不能漏掉的案例

这里最重要的是：评价指标不只是一个数字。选择某个指标，也是在决定 哪一类错误更危险。

例如，把需要人工复核的消息直接送去自动处理，风险可能很高；相反，把本来可以自动处理的消息送给人工，主要可能只是成本增加。两者都是错，但业务影响不同。

错误 业务影响
把高风险消息自动处理了 可能导致客户损害、政策违规或安全问题
把安全消息送去人工处理 处理成本增加，响应变慢

所以问题定义不仅要包含输出本身，也要包含错误代价。

问题定义也会决定数据收集范围

问题定义还会决定应该收集什么数据。即使数据很多，只要和模型要解决的任务不匹配，也可能没有多大用处。

例如，把 我们想减少配送问题 这个目标改写成三种不同任务：

任务 需要的输入数据 需要的输出数据
配送延迟预测 下单时间、发货时间、地区、商品、物流状态 是否延迟或预计到达时间
配送消息分类 客服消息文本 消息类型标签
配送回复生成 消息文本、订单状态、配送政策 好回复样例或回复标准

即使都是配送问题，数据形状也会完全不同。只收集了消息分类数据，就很难直接做配送延迟预测模型；反过来，就算有很多订单日志，也不一定能直接学到高质量的客服回复。

所以在收集数据之前，先要问下面这些问题：

我们想预测或生成的输出到底是什么？
为了产出这个输出，模型实际能看到什么输入？
我们有没有同时包含这些输入和输出的历史案例？
标注标准在不同人之间是否一致？

模型选择发生在问题定义之后

在这个阶段，人很容易先被模型名字吸引，比如线性模型、树模型、神经网络或 LLM。但如果先有模型名字，人就容易反过来把问题硬塞进模型里。

更安全的顺序是：

  1. 先定义现实目标
  2. 再定义建模任务
  3. 再定义输入和输出
  4. 再定义数据和标注标准
  5. 再定义评价标准
  6. 最后再挑模型候选
  7. 再确认输出会怎样被使用

例如，客服消息分类并不天然要求用 LLM。如果消息类型很清楚、数据也整理得好，一个更简单的分类器，甚至规则和模型信号混合的方式，可能就足够。相反，如果任务是生成自然语言回复草稿，那才更可能需要生成式模型或 LLM。

模型选择当然重要，但它代替不了问题定义。如果问题定义本身不清楚，就算用了大模型，也很难判断它到底应该把什么做好。

模型表现和业务表现可能不同

即使模型指标提高了，也不能自动下结论说真实业务效果一定变好了。因为模型只是更大 system 里的一个部件。

例如，假设消息类型分类准确率变高了，但下面这些问题依然可能存在：

模型做得不错，但…… 真实工作里仍可能出现的问题
它把消息类型分得很准 路由规则仍可能把案例送错团队
它能很好判断是否适合自动处理 政策更新没有同步，导致给出错误说明
它生成的回复草稿很流畅 草稿可能因为缺乏依据而被人工打回
它能准确预测延迟风险 预警发送太晚，客户体验仍未改善

Google 的 Machine Learning Glossary 也提到，LLM 评价不只是用来比较性能，也有助于检查是否安全、是否符合伦理。这个话题会在生成式 AI 部分展开。对 4.4 来说，只要先记住：输出改变了，评价标准也会跟着改变。

所以必须把模型评价和业务评价区分开。

区分 问题
模型评价 模型输出和答案或标准有多接近？
业务评价 把模型接入后，真实工作有没有变好？
安全评价 错误输出会不会给用户或组织带来风险？

即使是同一个模型，这两种评价也可能不同步。比如消息类型分类准确率很高，但如果路由规则过时，或者负责团队接收到结果太晚，业务表现仍未必显著改善。反过来，就算模型准确率并不是特别高，只要 system 很会拦住高风险消息并转给人工，实际业务安全性也可能明显提升。

问题定义文档里应该写什么

即使只是一个很小的建模任务，只要把下面这些项写下来，混乱就会少很多。

项目 要问的问题 客服消息例子
现实目标 为什么需要这个模型？ 缩短消息处理时间
建模任务 模型要解决什么问题？ 消息类型分类
输入 模型真正看到什么？ 消息文本
输出 模型必须产出什么？ 退款、配送、换货、其他
数据 过去案例是什么？ 消息文本和人工标签
标注标准 不同人能按同样标准标注吗？ 退款、配送、换货、其他的定义
评价标准 怎样才算做得好？ 准确率、召回率、人工复核结果
错误代价 哪类错误更危险？ 把高风险消息自动处理掉
使用位置 输出会被用在什么地方？ 路由、自动回复支持、人工复核输入
排除范围 模型不负责什么？ 最终退款审批和政策责任

这样的文档并不是什么宏大的规划书，而是界定模型世界的最小地图。没有这张地图，就很难判断模型是否变好了、数据是否足够。至于是否真的能部署，还要到后面章节再看，因为安全、权限、复核流程和运行责任都必须一起考虑。

Checklist

  • 我可以区分现实目标和建模任务。
  • 我可以说明同一个目标会变成分类、回归、推荐或生成等不同任务。
  • 我可以说明输出定义会连带改变数据、模型候选和评价标准。
  • 我可以说明模型表现和真实业务表现可能不同。
  • 我可以把输入、输出、数据、标注标准、评价标准、错误代价和排除范围写进问题定义说明里。
  • 我可以说明：问题定义不是模型前的附属准备，而是决定模型看什么、输出什么、怎样判断成功的核心阶段。
  • 我可以自己补完整这句话：我们要使用什么输入来生成什么输出，并用哪些指标和复核标准确认这个输出是否有助于哪个业务目标。

出处与参考资料