5.将相似事物归类到一起？这属于聚类问题（clustering problem）。亚马逊的相关商品顾客提示语（customers-also-bought）依然个瞩目的案例，还有我们刚刚提到的Spotify的歌单推荐，你应该还没忘吧。

　　6.发现系统异常？这叫做异常检测（anomaly detection）。很多有关热门产品（如上述提到的Foursquare、Twitter、Facebook等），对异常检测的要求更高。

　　你发现了吗？案例1-4属于监督学习，5和6属于无监督学习。在实际应用中也会出现出现一定的交叉范围。

　　Part 2 机器学习在产品实践中的应用

　　通常来讲，做机器学习产品的技术团队注重的是发掘和分析数据、建立数据管道、特征工程、选择及优化算法、避免过拟合、运行离线评估、并将机器学习运用至在线测试中等等。但作为一个产品经理，还需要重点关注下面七个问题。

　　1. 机器学习是否匹配产品目标

　　2006年，Netflix曾斥资百万美元举办大赛，要求参赛者开发一个可以预测用户为影片评分的监督学习算法。当时，Netflix主要是想通过预测用户对影片的评分，来更好地进行推荐。可实际上，Netflix想要解决的问题，和他们在大赛中用机器学习来解决的问题本是不同维度的，在开发新产品时，你更需要想清楚机器学习是否可以解决你的问题。

　　2. 产品运营，机器学习就够了？

　　这里又得重提“每周发现”了，它的播放列表就是机器学习的产物。同时，还需要产品经理来决定它的适用范围。是产品经理决定了它需要每周一更新，最近的播放列表会随着新歌单的产生消失。产品经理有参与决策的部分，并不仅仅依赖机器学习。分别定义机器学习和产品经理的作用是一件至关重要的事情。

　　3. 产品如何开始使用机器学习？

　　一个困扰机器学习产品开始的问题就是，它看起来像巨大的、无法逾越的、需要数月时间的工作才能填补的“鸿沟”。对此，Google大数据研究科学家Martin Zinkevich曾在论文《机器学习法则：机器学习工程最佳实践》中进行了最佳机器学习工程的描述——不必要对运用机器学习本身犯怵，很多产品可以用简单基线从收集用户反馈开始。

　　“如果你需要通过几十个柱状图才能讲清你的非机器学习产品是干什么的，可能你在设计的是一个复杂的过度解决方案。换句话说，如果你可以一句话概括产品功能（“我们就是来解决低价问题的”，“我们给你最流行的趋势”），恭喜你，你拥有了一个良好开始”。

　　4. 你需要和什么对比？

　　问题接踵而至，如果单单从最小化可行产品（Minium Viable Product, MVP）来看，这里并不需要基线。但要设计机器学习产品，你就需要设立条简单的基线了。

　　机器学习产品的不同就体现在它的运行情况不是数值可以体现的，是与基线对比出来的。你想将算法的准确率在基线为94%的情况下提高到95%，虽然仅仅为1%，但你可能也需要相当大的工作量来完成。如果你的基线值设定到50%，而算法目前的准确率为75%，这就变成一步巨大的飞跃了。

　　这里有两点需要特别注意的是：首先，产品性能的好坏是相对的，你需要建立一个基线。其次，为了能有效进行比较和测评，定基线还得“走心”呀。在机器学习产品中，通常会将线上和线下指标分离。例如“算法预算历史数据的准确率”和“这种算法下的产品转化率是多少”就分属为不同的问题。

　　5. 产品的更新速度有多快？

　　机器学习产品的输出对你的构建会产生很大的影响。比如美国在线出版平台Medium（类似国内简书）的推荐邮件或者是Quora的摘要邮件，可能都隐藏着机器学习。由于它的产品就是邮件，所以这里不需要适应用户的实时活动。但像Foursquare这种基于地理位置而运算得到的数据，或者类似Google搜索引擎这类产品，用户活动都会导致不同的输出结果。

　　所以，你要意识到产品的更新速度不仅仅要适应你的系统架构，还会影响用户体验。

　　6. 用户拥有什么样的交互、活动和管理权限？

　　数据学家喜欢先着眼于数据获取的难易程度，之后基于此创建学习算法。然而当创建一个新产品时，产品团队更愿意在设计用户交互时来定义数据的获取范围，这些数据将来有可能都会用到。如果你前期准备不周，那么没有记录早期产品数据将成为很多数据学家感到沮丧的原因。