ab-mapping

# A→B 映射 — 监督学习的核心心智模型 ## R — 原文 (Reading) > "最常见的机器学习类型是一种能够学习从输入到输出映射的AI。" > > — 吴恩达, p02 --- ## I — 方法论骨架 (Interpretation) 所有监督学习在结构上是同一件事：给定输入 A，预测输出 B。 这个看似简单的框架具有惊人的统一力——垃圾邮件过滤器、语音识别、机器翻译、广告点击率预测、视觉质检，它们的底层结构完全相同。 AI 项目失败的首要原因不是技术不够，而是没把问题正确地框成"A→B"的形式。 一旦你能清晰地回答"我们的输入是什么"和"我们想要预测什么"，问题就从一个模糊的业务诉求变成了一个可执行的机器学习任务。 这个框架的作用是强制你做问题形式化：把现实世界的混乱提炼成两个明确定义的变量，以及它们之间的映射关系。 --- ## A1 — 书中的应用 (Past Application) ### 案例 1: 垃圾邮件过滤器 - **问题**: 如何让邮箱自动识别垃圾邮件 - **方法论的使用**: 输入 A = 一封邮件的内容，输出 B = 是/否为垃圾邮件 - **结论**: 明确的 (邮件→标签) 对，监督学习直接适用 - **结果**: 成为监督学习最经典、最成功的应用之一 ### 案例 2: 语音识别 - **问题**: 如何让机器听懂人说话 - **方法论的使用**: 输入 A = 一段音频波形，输出 B = 对应的文字 - **结论**: 音频到文本的映射，结构清晰 - **结果**: 现代语音助手的技术基础 ### 案例 3: 房价预测（两种方向） - **问题**: 如何用AI做房产估价 - **方法论的使用**: 正向 A = 房屋面积，B = 预测价格；反向 A = 预算，B = 推荐面积 - **结论**: 同一个业务问题可以定义出不同的 A→B 映射，选择取决于实际数据可用性 - **结果**: 说明 A→B 框架需要结合数据现实来灵活定义 ### 案例 4: 自动驾驶中的车辆定位 - **问题**: 自动驾驶汽车如何知道周围车辆的位置 - **方法论的使用**: 输入 A = 摄像头拍摄的图像，输出 B = 周围车辆的位置坐标 - **结论**: 图像到坐标的映射，结构明确 - **结果**: 自动驾驶感知系统的核心模块 --- ## A2 — 触发场景 (Future Trigger) ★ ### 用户会在什么情境下需要这个 skill? 1. 业务团队提出一个模糊的"想用AI"的想法，需要把它转化为具体的技术问题 2. 技术团队在评估一个需求是否属于监督学习范畴 3. 产品经理在写AI需求文档，需要明确输入输出定义 4. 创业者在构思AI产品，需要验证问题结构是否成立 ### 语言信号 (用户的话里出现这些就应激活) - "AI能不能做这个" - "这算不算机器学习问题" - "我们的场景适合用AI吗" - "能不能用AI预测X" - "怎么把这个问题变成AI问题" ### 与相邻 skill 的区分 - 与 `one-second-rule` 的区别: 一秒法则判断"这件事技术上是否可行"，A→B 映射则是把问题形式化为可执行的结构。先映射，再判断可行性。 - 与 `ml-feasibility` 的区别: 双因素框架是完整的可行性评估（概念+数据），A→B 映射只是第一步——把问题框成输入输出对。 - 与 `automate-task` 的区别: 任务分解是"把岗位拆成任务"，A→B 映射是"把任务框成输入输出"。 --- ## E — 可执行步骤 (Execution) 当 skill 被激活后, agent 应按以下步骤执行: 1. **定义输入 A** - 向用户提问："你拥有什么数据？这个AI系统的输入是什么？" - 完成标准: 用户能用一句话描述输入（如"一封邮件"、"一张产品图片"、"一段客户对话"） 2. **定义输出 B** - 向用户提问："你希望AI给你什么？是一个类别、一个数字、还是一段文字？" - 完成标准: 用户能用一句话描述期望输出（如"是否为垃圾邮件"、"缺陷类型"、"预测价格"） 3. **验证 (A, B) 标注对的可获得性** - 向用户提问："你手上有多少已经标注好的 (输入, 输出) 样本？" - 完成标准: 用户能给出大致的数据量级（如"1000条已标注邮件"、"没有历史标注数据"） - 判停条件: 若用户无法定义清晰的 A 或 B，则提示"这个问题可能还不适合监督学习，建议先做问题澄清" --- ## B — 边界 (Boundary) ★ ### 不要在以下情况使用此 skill - 问题没有明确的输入和输出（如"我想了解客户行为模式"——这是数据科学/探索性分析，不是监督学习） - 问题需要复杂的长程推理（如"制定明年市场战略"——无法定义单一输出 B） - 问题属于无监督学习范畴（如聚类、降维、异常检测——没有明确的 B） - 用户只是想了解数据，不需要做预测 ### 作者在书中警告的失败模式 - 把问题框错了 A 或 B，导致后续所有工作建立在错误的形式化上 - 混淆了"预测"和"推荐"——推荐系统的 A→B 定义比监督学习更复杂 ### 作者的盲点 / 时代局限 - A→B 框架假设你能清晰地定义"正确的输出 B 是什么"——现实中很多业务问题是模糊的（如"好的客户服务"、"有创意的广告"），无法简单标注 - 该框架主要适用于监督学习，对强化学习、生成式AI的适用性有限 - 书中未充分讨论：当 B 本身需要人来主观判断时（如"美不美"、"好不好"），标注一致性会成为瓶颈 ### 容易混淆的邻近方法论 - 与"数据科学流程"的区别: 数据科学不一定需要 A→B，它更关注从数据中发现洞察 - 与"推荐系统"的区别: 推荐系统的输入输出结构更复杂，不完全等同于简单的 A→B 映射 --- ## 相关 skills - **ml-feasibility** (depends-on): A→B映射定义问题后,需要用双因素框架评估可行性 - **one-second-rule** (composes-with): 一秒法则帮助判断B是否足够"简单"可被学习 - **ml-workflow** (depends-on): 定义A和B后,进入ML四步流程执行 --- ## 审计信息 - **验证通过**: V1 ✓ / V2 ✓ / V3 ✓ - **测试通过率**: 待测试 - **蒸馏时间**: 2026-06-29