没有合适的资源?快使用搜索试试~ 我知道了~
首页人工智能的产品和工程视角.pdf
人工智能的产品和工程视角.pdf
需积分: 9 11 下载量 108 浏览量
更新于2023-05-17
评论 1
收藏 709KB PDF 举报
两大主题: 产品视角:如何认识和管理人工智能的产品化路径 工程视角:与人工智能相关的系统架构有哪些典型的设计模式 总的来说,人工智能落地有两大难题,一是产品化和商业化路径,一是科研算法向工程领域的转化。
资源详情
资源评论
资源推荐
每年暑期,创新工场举办的DeeCamp大学生人工智能训练营,我都会给学生们讲课。我是
工程师出身,并不专精理论研究。何况,2019年的DeeCamp,我们请到了吴恩达、周志
华、张潼、俞勇、孙剑等顶级学者来讲机器学习的理论与发展,更不需要我来班门弄斧。所
以,我的课程更多是从人工智能的产品研发和系统工程角度,帮学生梳理一下,如何将一个
前沿人工智能技术变成一个具有商业价值的产品或解决方案。这方面的方法论、知识体系,
学生在学校期间并不能经常接触到。
我在2017年DeeCamp讲的课程,后来简单整理成了一篇《为什么AI工程师要懂一点架
构?》,其中的架构讲解以离线的大数据流程和机器学习训练架构为主。2018年我在
DeeCamp讲的课程则偏重人工智能的商业化路径,商业案例讲得比较多。今年,我把前次
内容重新组织并大幅扩充、更新,变成两大主题:
1.产品视角:如何认识和管理人工智能的产品化路径
2.工程视角:与人工智能相关的系统架构有哪些典型的设计模式
总的来说,人工智能落地有两大难题,一是产品化和商业化路径,一是科研算法向工程领域
的转化。因此,新课程的题目就叫《人工智能的产品和工程视角》。
一、从AI科研到AI商业化
今天,AI商业落地是一个反复被讨论甚至被质疑的话题。一方面,AI在许多场景和平台上实
现了巨大的价值——Google、Facebook、Amazon、阿里、腾讯等早已熟练地在搜索引
擎、广告推荐、商品推荐等领域广泛使用机器学习并创造巨大营收,另一方面,大批怀着科
技改造世界的美好梦想,在医疗、金融、制造、零售、能源、交通、仓储等垂直领域耕耘的
创业者们却发现:理解客户场景和需求难,找到技术和业务的结合点难,实验结果和客户需
求之间差异巨大,单项AI技术难以解决客户的综合问题,概念验证(POC)或科研项目极
难转化为实际采购需求,实际项目的实施复杂度和定制化程度远超预期,技术和产品的可复
制性不强,难以形成稳定的产品和可持续的销售……
的确,科研与商业化存在巨大鸿沟。科研的关注点(技术突破、论文水平、数据指标等)与
商业化的关注点(能不能赚钱,能不能持续赚钱,能不能轻松持续赚钱)之间,存在较大差
异。从更本质的层面来分析,大概有两个原因:
第一,今天的AI技术有非常明显的边界:在涉及浅层信息到知识映射的任务时,或单纯的数
据建模任务时,往往表现得性能出众甚至超过人类平均水平。例如,今天的AI可以轻松快速
识别人脸,可以快速完成语音到文字的转换,可以快速从大数据(如广告点击日志)中总
结数学模型并用于预测(如广告点击率预估)。但是,在涉及深层知识表示和知识理解(或
者说基于符号语义的建模任务)时,今天的AI幼稚得像一个两三岁的小孩。例如,今天最顶
级的AI连预定一个餐厅这样的限定领域任务,都还需要人类配合才能完成(Google发布的
Duplex辅助预定服务在效果上非常亮眼,但其实有相当一部分对话是在真人参与下完成
的,参见纽约时报的报道:
https://www.nytimes.com/2019/05/22/technology/personaltech/ai-google-
duplex.html)。简单会话尚且如此,对于更复杂的知识理解和推理任务,我们可能需要相
当长时间,才能看到AI的进步。
第二,今天的AI技术在搜索引擎、广告推荐等有限领域,可以真正成为核心业务的支柱技
术。但在更广泛的领域里,很多AI公司的产品和解决方案还停留在帮助客户公司塑造一
个“拥抱新技术”的良好形象,或为客户的非核心业务提供一些“有用但非亟需”的工具,
而不是深入到客户的核心业务内部,帮助客户获得更大的盈利及成长空间。如何用技术帮助
客户提升价值,这件事往往是学生和科研人员很难理解的——没有在商业环境打拼过,就
很难意识到到底什么样的技术对企业的生存(或者说赚钱)最重要。因为这种认知,更多需
要的不是计算机科学知识,而是具体行业内的领域知识。
因此,如何从产品视角来认识和管理人工智能产品或人工智能商业化的整个生命周期,这是
本文要重点讨论的第一个问题。
另一方面,对计算机或相关专业的在校学生来说,学校里学到的学科知识和工程上实现一个
真正可用、好用的人工智能系统之间,同样存在着不小的鸿沟。学科教学强调的是离散的知
识点,而产业实践强调的是完整的系统工程,或者说完整的技术栈。学生们在校学过机器学
习、计算机体系结构、操作系统和分布式系统……但如果没办法把这些知识融会贯通起来,
构建一个解决真实问题的系统逻辑,那是没法将人工智能变成工程产品的。也只有接受过灵
活运用学科知识解决真实问题的专业训练,学生们毕业后才能成为高水平的算法工程师、系
统工程师或架构设计师。
真实人工智能产品或系统,往往由一个完整技术栈组成,大致会涵盖硬件架构、操作系统、
分布式架构、核心算法、应用逻辑、部署和维护等多个层次的技术框架与技术组件,其中,
每一个技术框架或组件又可能是由学校里学过的多种学科知识共同支撑的。比如我们要做一
个图像识别系统用于超市的商品监控,缺乏经验的算法工程师可能认为,商品识别不过就是
objectdetection和objectclassification这两个任务,这又可以借助一系列通用算法,如
FasterR-CNN、YOLO、SSD等来完成。但一个有经验的系统工程师则会在算法之外,提
出更多的问题,例如:
我们需要多少训练数据?数据从哪里来?
模型是否有定期或实时更新的需求?如何更新?
推断计算(Inference)部署在哪里?终端上?还是云端?
终端计算和存储能力是否有限制?是否需要对模型进行压缩?
AI算法本身是否有分布式的需求,如分布式的训练?
图像如何采集?采集到的图像如何传输到运行算法的计算结点?
识别结果和操作日志如何保存并用于后续的算法优化?
……
这些问题看似是工程问题或系统架构问题,但其实也和AI算法本身的息息相关。
如何用一个专业系统架构师的视角看待AI系统的设计与实现,这是本文将重点讨论的另一个
问题。
二、产品经理视角:数据驱动的产品研发
产品经理最重要的素质是严密的逻辑思维和系统化的方法论。不同领域的产品设计和产品管
理,在方法论上不尽相同。对于人工智能和大数据相关的产品和解决方案,数据驱动的理念
和方法论也许最为重要。
EricSchmidt与JonathanRosenberg合著的《HowGoogleWorks》一书中提到了
Google“依数据决策”(Decidewithdata)的做法,“互联网时代最有变革意义的发展
之一是,我们具备了用定量的方式来分析商业流程中几乎每个层面的能力。……如果你没有
数据,你就无法决策。……这就是为什么大多数Google的会议室都有两个投影仪的原因
——其中一个用于不同办公室间的视频会议或投影会议记录,另一个用于展示数据。”
数据驱动的思路,从根本上说,就是用可度量的方式来指导产品定义、产品设计和产品开
发。大数据工程师和AI算法工程师应该非常熟悉数据驱动的基本思想:在机器学习领域,为
了验证一个新算法,需要有数据集,有方法和指标来度量算法在数据集上表现出的性能,有
作为参照的基线(baseline)。机器学习领域有关数据驱动的核心思想完全可以用于指导产
品管理——这差不多就是数据驱动的产品思维了。
实际执行角度讲,就是要在产品管理的每一个环节,用可度量的数据指标来指导产品决策:
用户需求是否存在?我们需要精准的用户调研数据;
市场空间是否足够大?我们需要客观的市场调研数据;
产品是否应该包含某个功能特性?可以针对这个功能特性做小规模实验并收集实
验数据;
产品是否有可能在竞争中胜出?竞品分析数据同样重要;
营销和推广渠道如何搭建?这就要做对比测试并获得客观的渠道转化率数据;
产品的用户界面是否美观易用?这也可以通过对比实验的结果数据来判定。
数据驱动的核心是相信数据具有可评估、可管理、可改进、可持续的属性,与我们通过“拍
脑袋”做的主观判定相比,数据更客观,也较少偏见。当然,熟悉统计和机器学习的同学很
清楚,统计数据里貌似客观、实则偏颇的事情也挺多,比如著名的“幸存者偏差”。但严密
的逻辑加上科学的度量方法,还是可以更大概率地保证数据的客观性,为决策提供更好的支
持。
上图右边是维基百科对于ROC曲线相关的评估指标的一个总结,参见:
https://en.wikipedia.org/wiki/Receiver_operating_characteristicen.wikipedia.org
学过机器学习或统计学的同学对这个表格应该非常熟悉。其中,ROC曲线反映的是伪阳性
率(FPR)和真阳性率(TPR)之间的关系。大家应该都清楚,在多数真实系统中,必须在
算法的伪阳性率(假警报比率)和真阳性率(敏感度)之间做一个折中或权衡。
类似的,当我们用数据驱动的方式去思考一个产品定义或产品设计的时候,也需要懂得取舍
或权衡的艺术。例如,一个知识社区类的产品,如果增加一个一句话吐槽(类似日式冷吐
槽)的功能,那多半可以增加新注册的用户数量、活跃用户数量和平均用户使用时长;但这
样偏娱乐向的功能,却多半会造成娱乐型用户占比的增加,这是否会进一步影响有价值知识
内容的积累,或影响付费类知识课程的转化率,就需要产品经理通过对比实验,仔细收集分
析数据,并做出最优的折中或权衡了。
一个典型的C端产品(直接面向最终用户且主要是个人使用的产品)的研发过程如上图所
示。因为市场机会、市场容量、竞品态势瞬息万变,今天的互联网和移动互联网产品尤其强
调快速迭代的产品研发模式。可以说,今天中国的C端产品市场里,根本没有所谓的“蓝
海”,几乎每个战场/赛道初具规模的时候,就会有大批强有力的竞争者参与进来,形
成“红海”。“红海之战”里,快速迭代的思想无论如何强调都不为过。因为快速迭代可以
更早地获得用户反馈数据,更早地指导和修正产品设计,更早做出符合市场规律的正确决
策。
具体执行层面,很多C端产品的产品经理都非常熟悉两件事:一个是“数据埋点”,一个
是“A/B测试”。
“数据埋点”指的是在产品的前后端逻辑里,加入特定的日志代码,记录与用户操作或系统
功能有关的事件。通过埋点所记录的信息被存储在系统的前后端日志中,而产品经理则经常
需要从这些日志中寻找数据的规律,挖掘数据背后的价值。比如,一个电子商务网站或APP
可以通过数据埋点,了解到某用户在浏览商品时,曾把一件商品加入购物车但后来又删除的
行为,甚至可以有针对性地记录商品被加入购物车直到最终删除之间用户又执行了哪些操
作,然后根据用户交互日志,分析在什么情况下用户更容易放弃一个订单,并据此改进产品
设计,提高购物车中商品的实际转化率。知乎有关数据埋点的问题中有一些不错的答案值得
参考:
数据埋点是什么?设置埋点的意义是什么?www.zhihu.com
图标
图标
“A/B测试”是指将不同版本或不同迭代周期的功能按照一定的用户触达比例同时发布,比
如,针对一个实时通信工具,我们想在新版本迭代中测试一个根据用户输入提示合适的表情
包的功能,但又不确定这个功能是否会得到用户认可。那我们可以通过前后端软件的设置,
将特定比例(如1%)的用户使用流量导流到带有新功能的版本,剩余99%的用户流量仍然
使用不含新功能的版本。将用户导流到不同版本时,既可以根据一个预先的条件(如某地域
符合某年龄段的用户)来选择新版本的测试用户,也可以随机选择新版本的测试用户。这种
有对比的测试,可以很容易得到新版本用户相对于旧版本用户的变化,例如聊天的平均时长
和对话轮次有无提升,原有的输入功能是否受到影响,新功能的使用频次是否达到了预期等
相关数据。
总体上,评估一个C端网站、APP或小程序产品的数据指标有很多,大致可以分为渠道转化
效率、用户活跃度指标、用户使用率、用户留存率等几个大类,每个大类中又有一系列的常
用指标。需要强调的是,不同类型的网站、APP或小程序,决定它们价值的核心逻辑并不一
定是相同的。例如,对于一个搜索引擎来说,用户在产品上的停留时间(平均单次使用时
长)并不一定能反应系统的真正价值,因为好的搜索引擎通常能更快地帮助用户找到目标,
并将用户带到目标网站或APP,这时的平均使用时长反而较低。但对一个内容类的网站或
APP,例如短视频应用、新闻聚合应用等,用户的平均使用时长就特别重要,这个时长再乘
以用户的活跃度(例如月活跃用户MAU),然后再乘以一个平均的广告转化率,就大致是
内容类应用最基本的收入模型了。
剩余20页未读,继续阅读
醉若初
- 粉丝: 23
- 资源: 9
上传资源 快速赚钱
- 我的内容管理 收起
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
会员权益专享
最新资源
- zigbee-cluster-library-specification
- JSBSim Reference Manual
- c++校园超市商品信息管理系统课程设计说明书(含源代码) (2).pdf
- 建筑供配电系统相关课件.pptx
- 企业管理规章制度及管理模式.doc
- vb打开摄像头.doc
- 云计算-可信计算中认证协议改进方案.pdf
- [详细完整版]单片机编程4.ppt
- c语言常用算法.pdf
- c++经典程序代码大全.pdf
- 单片机数字时钟资料.doc
- 11项目管理前沿1.0.pptx
- 基于ssm的“魅力”繁峙宣传网站的设计与实现论文.doc
- 智慧交通综合解决方案.pptx
- 建筑防潮设计-PowerPointPresentati.pptx
- SPC统计过程控制程序.pptx
资源上传下载、课程学习等过程中有任何疑问或建议,欢迎提出宝贵意见哦~我们会及时处理!
点击此处反馈
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功
评论0