机器学习想要转化价值，最关键的一步是什么？

一个业务问题，埋坑无数，该如何巧妙转化，转变为机器学习的问题？

要平衡机器学习开发人力和时间成本，怎样才能找到最优产出比？

在范式大学首节公开课上，针对以上问题，第四范式联合创始人，产品负责人田枫，基于丰富的专业从业经验，系统化梳理了解决之道。

大家好，我是第四范式的联合创始人田枫，很高兴在这里和大家分享机器学习的 MVP 模型！

文中的机器学习专家花了大量的时间搭建平台，做数据的清洗、处理与机器学习建模，却没有带来公司所期望的价值。问题出在哪里了呢？ 基于第四范式在机器学习工业应用方面的大量成功案例和经验，我们今天就来分析一下，想用机器学习提升业务价值，在搭建平台、处理数据、训练算法之前，真正要做的第一步应该是什么？ 我们今天不谈技术，不谈算法，不谈平台，但是今天聊的东西却是机器学习产生价值过程中，最关键的步骤之一。

这次分享我们会从几个方面分析这个问题：

第一，机器学习是不是万能良药？我们首先需要想清楚,机器学习作为特别牛的技术，它能解决什么样的问题。

第二，一个业务问题，可能有各种千奇百怪的坑，假设我们初步判定可以通过机器学习来解决他，那么应该通过怎样的转化，避开这些坑，把业务问题变成机器学习的问题。

第三，如果有一个好的可以转化成机器学习的问题，我怎么去设计机器学习的开发节奏，估算它的投入产出比，如何分阶段去推动问题的建模和应用。

这就是我今天要介绍的，机器学习的MVP。

机器学习的最小可用产品

现在的互联网技术，接受的一个概念是最小可用产品，MVP，就是开发团队、设计团队用最小的成本代价，最大程度去验证产品的可行性。这个产品的可行性，是指这个需求是否真实存在，一个产品满足需求的方式是不是对的。

机器学习也是一样的，我们做机器学习的投入是长期的、持续的，带来的收入和回报也是巨大的，在开始之前，我们一定会希望以比较低的成本知道：现在引入机器学习是否可以影响我们所面对的业务，产生价值的潜力有多大。

那么把一个业务真正用机器学习做之前，我们可以用两步，做一个机器学习的 MVP：

第一步：我们要选择正确的业务问题，并不是所有的问题都可以套在机器学习的框架里，有些适合机器学习解决，有些不适合机器学习解决。在任何的技术项目管理中，用差的方法解决好的问题，一定优于用好的方法解决错误的问题。

第二步：当我们找到一个机器学习可以解决的问题后，我如何通过最小的时间和人力代价，去证明机器学习可以解决它，带来满意的投入产出比。

选择正确的问题：从分类器开始

首先我们看看机器学习擅长解决什么问题。我举一个例子，就是周志华老师的西瓜书讲的例子，它很经典，也很简单，还很深刻，这个问题是说我要判断一个西瓜是好的还是不好的。

这个问题的业务场景是什么呢，一个西瓜，我怎么在不交易、不打开的情况下，就知道它是好的还是不好的。如果我知道，我就可以用同样的价钱买到更好的西瓜；而如果我是瓜商，有了一套标准之后，我就可以更好的管理我的货品。

回到这个问题，一个西瓜是好的还是不好的，这是典型的机器学习二分类问题。首先我们要找到，判断这个西瓜好不好有哪些可以用到的数据。我们不能把买卖西瓜之后的数据放进去分析，比如买了西瓜之后，我打开就知道好不好了，那么这个就没有价值。

所以我必须在不破坏西瓜的前提下，这时候能用到的数据是西瓜的产地、西瓜的纹路、重量、比重、敲击西瓜的声音是浑浊还是清脆、西瓜皮的质感等等，这些不打开西瓜的情况就知道的数据。

刚刚我们的目标已经讲得很清楚了，好的还是不好的，好的是 1，不好的是 0，甚至我还可以定义一个评分，0 到 1之间的一个数，但总体而言我可以设定一个机器学习的目标，我们称之为 Label。

选择正确的问题：真实世界模型

这看起来是一个很简单的场景，好像一旦我们具备了这样的数据，就可以尝试建立机器学习模型了。然而在现实中，当我们想用机器学习来解决实际问题时，也会这么简单么？真实世界中往往是有很多陷阱的。这些陷阱可能有什么呢？

第一，西瓜好不好，是怎么定义的？是大？还是甜？皮厚不厚？瓤脆不脆？如果建立这个模型是为了西瓜的售卖，这些可能都是评价因素，模型学习的样本也都需要基于这个标准来建立。如果我们仅仅是基于西瓜大不大来定义样本，而实际的应用场景是综合判断西瓜好不好，那么可能会得不到想要的好的结果。

第二，西瓜好不好，是以什么为标准的？是用科学方法和仪器测量的？还是专家评测？如果是后者，评测者是同一个人么？如果是不同的人，大家对好西瓜的判断标准一样么？现实情况中，很可能是不一样的，那就要想办法消除Label的偏差。

第三，互联网的场景下，往往是需要满足所有人个性化的需求的 ，有些人喜欢甜的西瓜，有些人喜欢脆的西瓜，那将问题定义为分辨好的西瓜是否还合适？因为每个人对好西瓜的定义不一样，这个问题可能就转化为了推荐一个西瓜给一个用户，他（她）会不会喜欢？

第四，真实的应用环境是怎样的？假设我们需要一个在线实时的西瓜分类器，拿到西瓜那一刻马上判断它好不好，那是不是有些当时不能马上拿到的特征就不能用了？如果好瓜的判断标准在不断发生变化，或者瓜本身的特性在不断变化，模型还需要能够跟得上这个变化，基于新的数据和反馈做自我更新迭代，这就是我们搭建模型更新的方法。

可见，即便是简单的问题，我们都需要思考一下业务的方方面面，理清哪些因素，边际，个性化要素和基础设施是要考虑进去的。

选择正确的问题：业务问题的本来面貌

我们从西瓜还原到业务，任何一个业务能不能做机器学习，我们要看三个要素。

第一，这个业务的目标值是什么，它不一定是唯一的，但一定有主次。这个目标是否可以量化、收集反馈、客观观测的。什么叫客观观测，我说甜和你说甜，这个事情就可能不客观，那有没有一个客观的东西可以反馈。

第二，样本应该如何构造，样本不应该违反因果关系,y=f(x),x一定是我们业务 场景中所能知道的信息。在西瓜的问题，就是打开西瓜之前我们能知道的信息，才可以作为x。同时，样本应该符合业务场景的真实情况，假设我们的业务是摸黑挑西瓜,我们看不见西瓜长什么样,我们只能敲,那西瓜的颜色就不能作为特征。 

第三，样本的每一行代表什么意思，每一行应该代表西瓜的每次测量，然后才是选择哪些数据作为x，这些我们已经讲得很清楚。

当西瓜的问题说完后，我们来看看真实的业务问题是怎样的。

1.点击率预估

比如说我们看到的推荐系统问题——点击率预估。

一个推荐系统的目标是什么？它的终极目标一定是用户体验，但这个目标很虚幻，我们要把它量化，变成一系列可以测量的数据，比如说点击、观看时长、购买、好评等，这些就是y。

然后我们看有哪些x，这些x代表的是我做出推荐排序的一瞬间，当客户请求时，在那个瞬间我知道的事情。我能知道客户的属性、特征，我能知道内容特征、上下文特征，但不知道最终这个内容是否有被展现和点击。我可以知道内容在这一瞬间之前被点击了多少次，但一定不是这个瞬间之后被点击了多少次，因为这样就穿越了。 

有了y和x，就可以构造样本了。我的样本比如说，我给用户展现了 10 条推荐的内容，这个的反馈可能是点击和观看，那么每一次的样本展现就是一个样本。 

这里我们可以思考一个有趣的问题，当我们思考不同的特征对问题的影响时，比如说我们把展现作为一个样本，一个避免不了的问题是，我怎么知道这个内容是否被用户看到。

一种做法是我不去想这件事情，那么模型可能就是有偏的，比如说你认为这个样本没有被点击，但也有可能是没有被看到，但最理想的是把推荐到用户手机屏幕上的作为一条样本。 

退一步，还有一个办法，就是把展现的位置补充回来，作为一个特征。然后请求的时候虽然没有这个特征，但是这个特征吸收了位置对于展现和反馈的偏差。

2.简历匹配

再举一个场景的例子 —— 简历匹配。简历匹配是什么意思？它其实想预测的是，我给企业推荐了一个简历，这个人有没有被企业聘用，这看起来是个简单的机器学习问题。但是回到业务场景思考，这个问题有没有这么简单？对于内容推荐来说，用户有没有点击这个内容，点击后看多久，都是用户单方面的选择。 

但是简历有两个选择，第一个选择是企业通过面试、简历的选择，判断这个人是否适合企业。第二个选择是应聘者，他会不会去企业面试，而即便拿到了企业的offer，会不会被打动加入企业。

所以这就变成了多点、双向的问题，在这样的情况下，就需要对问题进行拆解。我们可以不直接做个人被企业招聘的事情，而是分开来做，比如说企业会不会邀请这个人去面试，以及这个人会不会接受企业的面试邀请，这样就能把问题做的更好。

选择正确的问题：小结

总结一下我们刚刚所介绍的MVP第一步：做机器学习，首先不是着急去建机器学习的模型，而是认真思考这件事情的业务场景到底是怎么样的。

总结下来一个机器学习能解决的业务问题，有这么几个点：

第一它是否能转化成分类/回归的问题。

第二目标是否是容易获取、客观无偏差的数据。

第三是问题的预测目标，因果关系是什么，因果关系越简单越好，如果是多因多果，或者说描述“因”的相关信息不方便获取，那是否可以拆分成多个模型。特征往往是因的数据，或者是一些不是直接原因的数据，只要它不破坏这个因果关系。

第四是我们刚刚没具体去描述的, 就是这个问题是不是一个真的业务需求。

一个真的业务需求是指，在我们用机器学习做出预测后，业务能否可以根据这个预测结果而受到影响？这个影响点是否足够清晰、有效？因为业务人员会用对业务影响的结果来评估我们项目的效果，如果我们预测的结果并没有有效影响业务，即使这个模型再好，也不会发挥作用。

比如说推荐系统，我预测了新的点击率后，可以按照点击率倒排来影响业务结果。但如果是游戏呢？如果我们预测这个人明天有30%的几率付费，我该如何影响到他，我能不能影响他？

所以你一定要思考，你的预测结果会怎么在业务中使用，这个使用会不会对业务产生提升。如果你发现提升本身是很难的，那这本身就是个伪需求。然后你还需要思考，现在没有用机器学习的业务，它是用了什么方法和数据，现在的方法和数据有什么缺陷，哪些是机器学习可以帮到的。

当以上的问题都有清晰的回答后，这时候你就可以提出一个好的问题了。这时候你就成功 80% 了，而剩下的问题都相对简单了。 

机器学习的投入

这就是我们MVP的第二步：在可控的人力、金钱投入下，构建一个有效的机器学习模型。

那什么是可控呢？1-3人月的投入，更多就会风险太高。我们会期望获得什么提升？Case by case，不同的业务不一样，有些业务比如说广告，1%的收入就是好几百万，而有些问题可能要提升好几倍才有商业价值。

在机器学习成本分配中，最大比例在机器学习本身，调参、特征工程、模型评估、模型上线这些工程的事情占了大量的时间，而问题的定义、数据的采集占的时间非常小，我们认为这是有问题的。我们认为一个机器学习的项目，无论通过合作还是使用第三方平台的方式，应该把大钱花在采集好的数据，定义好的问题上去，甚至这要超过一半的时间。而另一半的时间，才是真正做机器学习模型的时间。

降低数据的成本

那我们怎么降低数据的成本呢？我给大家一些思考。

第一，除非必要，只使用采集好的数据。因为数据采集是一个有成本的事情，当一个公司的体系越复杂，它采集数据的成本就越高，所以除非这个数据采集起来很轻松，或者已经有了，你才会去考虑。

第二，如果你要开发新的数据，首先要考虑的是成本。开发新的数据源是有风险的。机器学习最怕的是说不清楚这是算法的问题，还是数据问题，还是问题定义的问题，所以让 MVP 环节中能出问题的环节越少越好。

前面我们介绍了问题定义的问题如何避免，而算法一般是不太容易出问题的，除非用错，而数据其实是很容易出问题的，所以我们尽量用简单、可靠、成熟的数据。

第三，我们讲到在建模的过程中，尽量使用成熟的工具。真正在数据处理，特征计算，和算法训练的这些过程中，大量的工作是可标准化，甚至可以用算法自动优化的，大量的坑其实也是可总结，或者说可以在产品引导中避免的。我们一直在研发的第四范式先知建模平台，就是在努力将建模过程中的know-how封装到产品中，让用户操作更简单，而且少踩坑，更有效的获得好模型。

总结一下，这一步总的思想是，能不制造新的风险点，就不制造风险点，能降低不确定性就降低不确定性。

如何Review机器学习的模型？

好了，做好了前面介绍的两步，我们已经有了机器学习的MVP，机器学习对业务的影响已经初见结论，如果业务有明显提升，那么祝贺你，找到了新的价值增长点，优化后一定还会有更大的提升潜力；而如果效果不明显，我们这里再给大家一些关于如何review，如何检查MVP的建议：

首先要 Review 问题的方向是不是对的，模型的效果是否符合预期，模型的优化目标是否有明显的变化，比如优化的目标是西瓜好不好，优化之后是不是买到的西瓜好的变多了。

如果不是，那就是这个问题没有解决。那还会有什么原因？是不是指定了错误的目标，用在了错误的环境，或者数据有问题。其实说白了，要么是目标有错，要么是模型用错，要么是数据有问题，基于这 3 点来检查。

在现实业务中，解决了一个问题，有时也会带来新的问题。比如说新闻推荐的系统，现在点击的人多了，那么是不是由于推荐，新闻变得更加娱乐化了，是不是新闻的点击变得更集中化了，这可能并不是业务上非常希望的，需要继续想办法来优化。第二步是 Review 数据，这些数据里面哪些起了关键作用，哪些数据是经验上认为会有作用的，但实际上没有的。那么重新检查这些数据，看是不是数据质量的问题，使得没有发挥应该发挥的作用。还可以看下一步我们可以引入哪些新的数据，数据最好一批一批引入，我加入一批，一次性开发结束。 

第三步，当我 Review 上面的事情后，我要制定下一步的方案，往往是我会有新的、更多的数据。我也可能会调整目标，有可能是目标错了要改，也可能是增加目标，原来一个目标不够了，我要加入好几个新的指标，使模型变得更平衡。还有就是在工程上，看性能能不能优化等。