[论文阅读] 人工智能 | 机器学习系统构思新方法：Define-ML 解决传统 ideation 痛点

机器学习系统构思新方法：Define-ML 解决传统 ideation 痛点

论文信息

@article{alonso2025define-ml,title={Define-ML: An Approach to Ideate Machine Learning-Enabled Systems},author={Alonso, Silvio and Santos Alves, Antonio Pedro and Romao, Lucas and Lopes, H{\'e}lio and Kalinowski, Marcos},journal={arXiv preprint arXiv:2506.20621},year={2025}
}

研究背景：当传统方法遇上机器学习的「水土不服」

想象你要开发一个智能客服系统，传统的产品构思方法会让你先画用户画像、列功能清单，却很少问：「训练对话模型需要哪些数据？现有客服日志的数据质量够吗？」这就像盖房子时只画设计图，却不检查水泥和钢筋是否可用——最终可能导致房子地基不稳。

在机器学习（ML）渗透各行业的今天，传统 ideation 方法（如 Lean Inception）暴露出三大痛点：

数据依赖模糊：不知道「推荐算法」需要用户行为数据还是商品属性数据，以及数据是否合规、是否有缺失。
技术可行性盲盒：业务想做「销量预测」，但没考虑现有数据能否支撑时序模型训练，最终模型准确率可能不如简单统计方法。
目标与现实脱节：产品经理希望 ML 系统「100% 识别欺诈订单」，却不懂概率模型天生有误差，导致预期落空。

这些问题的核心在于：传统方法没把「数据」和「ML 技术特性」纳入早期构思，就像用造车的蓝图造飞机，必然漏洞百出。

创新点：Define-ML 如何让 ML 构思「脚踏实地」

论文提出的 Define-ML 框架，像给传统 ideation 装上了「ML 导航仪」，通过三个独创活动让构思过程数据驱动：

1. 数据源映射：给数据「盘家底」

怎么做：用表格梳理企业现有数据（如ERP系统、用户数据库）和需要的数据（如第三方市场数据），按「公开/私有」「是否受企业管控」分类，并用颜色标签标记数据质量（高/中/低）🔶1-58🔶。
类比：像整理厨房食材，清楚哪些食材（数据）新鲜可用，哪些需要采购（获取新数据）。

2. 特征-数据源映射：给功能「找粮食」

怎么做：把产品功能（如「个性化推荐」）和所需数据来源（如「用户浏览历史」「购买记录」）连线，确保每个功能都有数据支撑。
类比：就像菜谱（功能）对应食材（数据），没洋葱就做不了法式洋葱汤，没用户点击数据就做不好推荐。

3. ML 映射：给问题「配钥匙」

怎么做：用「ML 能力卡片」（如分类、预测、生成）匹配数据类型（如图像、文本、时间序列），再关联业务目标。比如「用户流失预测」需要时间序列数据+预测算法。
类比：像根据锁的类型选钥匙，不同数据和业务问题需要匹配特定的 ML 技术。

研究方法：三步验证 Define-ML 的「实战力」

论文采用「技术转移模型」分阶段验证，就像新药研发先做动物实验，再做临床试验：

1. 实验室验证：用「玩具问题」打基础

让18名学者用 Define-ML 构思「智能银行贷款系统」，优化活动细节（如数据质量标签设计）。

2. 静态验证：在企业「模拟考」

找11名能源行业从业者，用虚拟的「智能贷款审批」场景测试，91%的人认为数据源映射有用，100%认可特征-数据映射。

3. 动态验证：去真实场景「闯关」

在跨国饮料公司开展3天工作坊，解决真实的「零售需求预测」问题。89%的参与者认为框架有效，所有人都想继续用。

主要贡献：Define-ML 给行业带来了什么？

填补方法论空白：首次将「数据约束」和「ML 技术可行性」融入 ideation，让团队从一开始就避免「数据空想」。
提升协作效率：业务、数据、技术团队通过「可视化映射」对齐认知，减少后期因数据问题导致的返工。
降低落地风险：某零售案例中，团队通过 Define-ML 发现现有销售数据缺失天气变量，提前规划数据采集，避免模型上线后准确率不足。

思维导图

在这里插入图片描述

深入探究

一、研究背景

机器学习应用挑战：机器学习在软件系统中日益普及，但早期构思面临数据依赖、技术可行性、业务目标与概率系统行为对齐等特定挑战，传统方法如Lean Inception缺乏针对性支持，可能导致产品愿景不一致和不切实际的期望。
现有方法不足：传统构思方法未提供评估数据准备或使功能想法与机器学习能力对齐的明确机制，而管理客户期望和使需求与数据对齐是工程化机器学习支持系统的主要痛点之一。

二、研究目标

提出Define-ML框架，通过数据源映射、特征到数据源映射和ML映射这三个定制活动扩展Lean Inception，系统地将数据和技术约束整合到早期机器学习产品构思中，确保构思的机器学习能力与业务目标对齐且技术可行。

三、研究方法

遵循技术转移模型：包括识别问题、制定研究问题、制定候选解决方案、进行实验室验证、静态验证、动态验证和发布解决方案七个步骤。
验证方法：
- 静态验证：在巴西能源行业公司进行三小时会议，使用玩具问题（智能银行贷款批准系统）验证，11名从业者参与。
- 动态验证：在跨国能量饮料公司进行三天工作坊，处理零售需求预测实际问题，11名公司专业人员和5名ML专家参与，9人完成问卷。

四、Define-ML框架

核心活动：
- 数据源映射：映射组织使用的主要数据源和产品相关的期望数据源，按公共/私有和是否受企业治理分类，用颜色区分现有和期望数据源，用圆圈表示数据质量（高、中、低）。
- 特征到数据源映射：将特征与开发所需数据源连接，提供数据如何支持特征实现的基础理解。
- ML映射：将特征分为机器学习密集型和非密集型，将机器学习密集型特征与业务目标连接，使用Mix & Match ML工具包的令牌对数据源分类并匹配适当模型类型，ML专家参与确保技术可行性。
其他调整：引入ML专家参与工作坊，替换传统角色定义活动为简化的关键角色识别活动。

五、验证结果

验证类型	参与者数量	关键活动有用性同意率	整体有用性同意率	意图采用率
静态验证	11	数据源映射：91%（10/11）特征到数据源映射：100%（11/11） ML映射：82%（9/11）	91%（10/11）	100%
动态验证	9	数据源映射：89%（8/9）特征到数据源映射：67%（6/9） ML映射：67%（6/9）	89%（8/9）	100%

参与者反馈：
- 认为框架有效澄清数据问题、对齐机器学习能力与业务目标、促进跨职能协作。
- 指出ML映射活动存在学习曲线，建议简化数据分类过程，有效 facilitation 可减轻难度。

六、结论与未来工作

结论：Define-ML提供了一个公开可用、经过验证的机器学习产品构思方法，在Lean Inception的敏捷性基础上，使功能与可用数据对齐，增加技术可行性意识，所有参与者都表示有采用意图。
未来工作：计划扩展Define-ML的范围，以适应生成式AI和智能代理等新兴人工智能范式。

关键问题

1. Define-ML框架的核心创新点是什么？

Define-ML的核心创新点在于其通过三个定制活动扩展了Lean Inception：数据源映射帮助识别和评估数据来源与质量，特征到数据源映射将产品功能与数据需求连接，ML映射则将机器学习能力与业务目标和数据类型匹配。这些活动系统地将数据和技术约束整合到早期机器学习产品构思中，解决了传统方法缺乏机器学习特定支持的问题。

2. 在动态验证中，参与者对Define-ML的接受度如何？

在动态验证中，参与者对Define-ML的接受度很高。89%（8/9）的参与者认为该方法有效支持机器学习支持系统的产品构思，67%（6/9）的参与者认为其易用（在适当 facilitation 下），并且100%（9/9）的参与者表示有意愿采用该框架。参与者强调了其在结构化协作、加速价值实现和跨职能对齐方面的优势。

3. Define-ML未来的发展方向是什么？

作为未来工作，Define-ML计划扩展其范围以适应新兴的人工智能范式，如生成式AI和智能代理。这将使框架能够更好地应对不断发展的机器学习技术和应用场景，保持其在机器学习产品构思领域的先进性和实用性。

总结：Define-ML 让 ML 产品构思「有章可循」

这篇论文提出的 Define-ML 框架，就像一本「ML 产品构思操作手册」：通过三步映射活动，让团队在 ideation 阶段就把「数据家底」「功能-数据匹配」「技术选型」想清楚。两次企业验证显示，它能有效减少构思歧义，促进跨部门协作，且所有参与者都打算在实际项目中采用。未来，团队还计划将其扩展到生成式 AI 等新兴领域。