产品经理作为产品端到端负责人,由于机器学习产品的天生的一些特质决定了“端到端”过程中包含一些特殊的流程。从商用化难度、资源投入的预估以及对于过程管理在机器学习产品中都对产品经理提出了新的挑战。今天就来跟大家分享下我理解的机器学习产品经理的工作规范。本篇文章只是作为这类内容的开篇,不对每个环节的细节进行具体剖析,在之后的篇章中会针对每个环节进行具体的经验总结和分享。
设定清晰的目标
首先一个完整定义的机器学习产品或项目需要:
1、明确界定的任务和目标。
产品经理应该明确界定机器学习产品或功能的任务和目标,尽量在每个场景中都用量化指标界定,将抽象的需求定量分析是产品经理必须具备的能力,因为机器学习的功能目标如果不能量化,任何一个环节的准备、调试都无法实际展开。例如你在做一个事件结果预测的功能,如果不能将预测的准确度进行量化,就无法指导算法工程师进行调优(包括算法选择和数据集的选取等)。
2、性能度量标准
对学习算法的泛化性能进行评估,不仅需要有效可行的评估方法,还需要有衡量模型泛化能力的评价标准,这就是性能度量。注意将其与学习算法的目标函数区分开来,目标函数是在参数调整时使用的,虽然在有些情况下两者是一样的。
在对比不同模型的能力时,使用不同的性能度量时往往会导致不同的判断结果。这意味着模型的好坏是相对的,什么样的模型是好的,不仅取决于算法和数据,还决定于任务需求。
3、训练经验的来源
在很多行业应用的复杂场景中,人为标注数据通常需要行业专家亲自参与,而你在设计某个产品之前是否考虑到了这个行业你是否有专家储备或资源,如果没有,至少在监督学习(Supervised learning)中训练出成熟的模型是非常难的。
算法团队提前介入进行预研
在传统的软件工程中,产品经理或项目经理对于范围(Scope)的预估决定了项目在工作量、成本、功能或它们组合方面的规模。“软件估算的准确度取决于对软件定义的细化程度”(Laranjeira, 1990)。
而在机器学习产品设计中按照这样线性的标准显然不能满足需求了。产品经理需要预留足够的时间让技术团队进行充分的预研,在最初的需求设计后需要第一时间给算法团队而不是页面开发和数据库设计。算法团队评估当前掌握的数据质量以及算法模型在场景中的最佳应用效果,将范围缩小到指定的几个常用算法,然后通过测试集和训练集在这几个算法上做一些Demo,根据Demo输出结果的质量(第一步的目标)决定最终使用的算法那个。但是如果结果依然无法接近第一步的目标,就意味着该功能很可能根据目前资源无法商用化,产品经理需要判断是否还需要继续投入资源进行该功能的开发工作。
需求设计
产品的功能性需求和非功能性需求在设计的时候要充分考虑数据是否能支撑好算法,数据收集能力是否全面,算法大概精度是否产品需求。这里面有一部分产品经理可以让步(因为功能上线效果受到许多因素制约),但是有些功能或体验式绝不能让步的,有时甚至要跟技术团队进行反复讨论,因为客户不会体量你,你要把握住产品的底线,对市场负责。当然这也不是说有些精度不高的算法就无法投入商用化,因为不是所有功能对于用户来说都是非黑即白的关系,有一些功能即使精确度不高但提供了依据和参考也依然对于用户来说非常关键,而这些是需要产品经理精心包装、甚至通过其他功能弥补的,而在这种情况下才能看出一个产品经理的真实水准。
数据获取阶段
对接业务数据系统,收集、爬取外网数据,打破数据孤岛,这部分的工作在本篇不进行展开。
机器学习训练模型阶段
训练集(train_set),评估集(valid_set),测试集(test_set)的获取,以及获取后对于数据的治理(在某些情况下产品需要引入第三方数据清洗工具或自行开发类似功能)都是产品经理需要充分参与的过程。
测试、调优阶段
机器学习算法常用衡量指标,从返回效果看数据问题还是算法问题
常见衡量指标有:
1. FPR&TNR、TPR
2. 精确率Precision、召回率Recall、F1值
3. 综合评价指标F-measure
4. ROC曲线和AUC
如果是数据的原因需要返回第四步进行数据的重新获取和治理。如果是算法问题产品经理要了解技术团队通常可以通过以下常见的几种方式进行调试。
1、增加数据量
2、处理缺失值和异常值
3、特征工程学
4、特征选择
5、换其他算法尝试
6、调参:要调整这些参数,你必须对它们的意义和各自的影响有所了解。你可以在一些表现良好的模型上重复这个过程。
7、集成模型:这个技术就是把多个弱模型的结果组合在一起,获得更好的结果。
8、交叉验证技术(cross validation)
机器学习产品设计流程的理解和反复锻炼有助于每个产品经理形成自己的工作规范和流程。本篇文章希望对你有帮助。
你可能还想看
领取专属 10元无门槛券
私享最新 技术干货