文因互联 CEO 鲍捷:确保搞砸人工智能项目的十种方法

本文转载自机器之心

做成一件事儿不容易,而坑恒在。

鲍捷博士于5月10日在将门创投的线上 talk 中盘点了人工智能项目的大坑小坑,选出了看上去非常反常识的十个经典坑

这是一篇大实话合集,但别绝望,最后将会放出从二十年踩坑经验中总结出的彩蛋,共勉。

作者介绍

鲍捷博士,文因互联 CEO。拥有20年学术界和工业界的相关经验。美国Iowa State University人工智能博士,RPI博士后,MIT访问研究员,W3C OWL(Web本体语言)工作组成员,前三星美国研发中心研究员,三星问答系统SVoice第二代系统核心设计师。主要研究领域涵盖人工智能的诸多分支,包括机器学习、神经网络、数据挖掘、自然语言处理、形式推理、语义网和本体工程等,发表了70多篇领域内相关论文。是中文信息学会语言与知识计算专委会委员,中国计算机协会会刊编委,W3C顾问会员会代表。2010年以来关注金融智能化的研究和应用,成果有XBRL语义模型,基于知识图谱的基本面分析、金融问答引擎、财务报告自动化提取、自动化监管等。

 

以下为演讲原文:

鲍捷博士:我今天的题目是《确保搞砸人工智能项目的十种方法》,按照这十种方法,基本上可以搞砸项目。(笑)

之所以能够讲这个题目,是因为我自己之前也搞砸过很多项目,下面列表里超过一半的项目最后是失败的:

我开始想,为什么大部分的项目最后做不成?

我经历了好几次很痛苦的时刻,比如刚到RPI(伦斯特理工学院)做博士后,这个学校有全美做知识图谱最好的实验室,实验室的James Hendler和Deborah Mcguinness,都是这个领域最好的老师。

我在那里做了一个知识管理系统,在我看来,我们是世界上最好的语义网实验室,也是最专业的一群人,不用这个技术来武装自己好像说不过去,所以我就做了一个语义检索系统,但是后来没有人用。

我就在反思到底问题在哪,为什么这行真正最好的专家,做出这样一个系统,连自己都不用?

我不停地在想,人工智能项目失败的核心原因到底有哪些?

当然,后来经历了更多的失败。基于这些直接或者间接失败的经历,我逐渐总结出来确保一个项目会失败的一些原因。这些原因很多时候看起来是反直觉的,我会逐一地跟大家讲。

在最后,我也会总结如果想要避免这10个坑,应该做什么。

 

NO.1 一下子砸很多的钱

第一种确保你的项目失败的方法:一下子砸很多的钱。

我目前也在创业,有VC问我:“你们做的这个事,如果BAT砸很多的钱,是不是就一下子能赶上你们?”

我说不会,通常举的例子,就是日本的五代机。当初日本举全国之力,砸了几百亿日元,最终没有做成。

五代机是什么?1970年代末是人工智能的第一次冬天开始回升的时候。80年代开始进入人工智能第二个高峰。这时候,日本启动了一个新的项目,叫第五代计算机。

什么叫第五代计算机?前四代计算机,分别是电子管的、晶体管的、集成电路的,和大规模集成电路的。日本到第五代计算机的时候,他们认为要想做人工智能,就必须用人工智能的专有硬件。

《知识信息处理系统的挑战:第五代计算机系统初步报告》中第五代计算机系统概念图

这个话是不是听起来很耳熟?最近在做深度学习的时候,看到了很多关于深度学习芯片的想法。这个想法并不新,因为在30年前,日本人在五代机的计算里,就已经有这样的想法了,只是当时的人工智能芯片,不是现在深度学习的芯片,而是Prolog的芯片。

Prolog是人工智能的一种语言,主要是一种逻辑建模语言。如果能够用Prolog来建计算机,计算机就可以进行思维,可以处理各种各样认知的任务。这是一个非常大型的国家项目,最终花了几百亿日元,耗掉10年时间以后,在1992年,终于胜利地失败了。

这不是个例,很多大型的项目,最后都失败了。

一开始砸很多钱,为什么还会失败?你要想,做一个项目,通常是有目标的。当你有一个大预算的时候,你的目标通常也定得很高。像五代机的目标,不单当时是做不到的,三十年后的今天,也是做不到的。

虽然五代机失败了,但是日本的人工智能技术,在五代机的研发当中得到了很大的提升,所以到了20年后,语义网兴起的时候,日本的语义网研究水平还是相当好的,那些钱没有白花,它培养了很多的人才。

在日本做五代机的同时,美国也有类似的研究,主要是LISP machine,LISP是人工智能的另外一种语言,也是逻辑建模的语言。其中有一个公司叫think machine。当时至少有100家LISP公司。

为什么单独要提到think machine?创始人在失败之后沉寂了一段时间,开了一个新的公司叫MetaWeb,MetaWeb是2005年的时候成立的,这个公司有一个产品叫Freebase,用Wikipedia做了一个很好的知识库。

2010年这个公司被谷歌收购,改名叫谷歌知识图谱。所以今天谷歌的知识图谱有很多历史渊源,可以追溯到30年前LISP machine的研究里面。

罗马不是一天建成的,所以一下子砸很多钱,就会导致项目的目标过高,从而导致这个项目有极大的失败概率。

我曾经遇到过一个大型国企的人,他跟我说,他们要花3000万建一个企业内部知识管理系统。我就问他,你那个3000万是怎么投的?他说我第一年就要投3000万。然后我没说话,因为我的想法是这个项目一定会失败。后来这个项目的的确确失败了。

也有一些大公司投比这还多得多的钱来做AI项目。这些都不一定让事情更容易成功。

这是第一种方法,一下子砸很多钱。

NO.2 根据最新论文来决定技术路线

第二种方法:根据最新的论文来决定技术路线,这可能也是一个反常识的事情。

因为最新的技术不是最好的技术,要注意,在工程领域里面,通常面临着实际的约束来解决问题的。而论文是一种实验室的环境,是不一样的。

比如说实验室里,可以假设有一些数据,可以假设这些数据已经被集成了,被清洗了,是没有噪声的。可以假设目标是清晰的,但所有的这些假设在现实中都不一定成立的。

最好的例子,就是信息抽取,这是2013年的EMNLP上的一篇文章,我拆出来的图。

这个图告诉我们做NLP的论文和实际的工业系统所采用的技术路线有什么不一样的地方。

从2003年到2012年整整10年,学术界所发表的自然语言处理论文的实体抽取子领域里,完全用机器学习的方法论文占到了75%,混合机器学习和基于规则的方法论文占到了21%,完全只用规则方法的论文,只有百分之一点几,非常低的比例。但是当看到工业界的实际应用的时候,发现了完全不同的技术占比分布,用规则方法的占到了45%。

如果光看大型的供应商,比如说IBM这样的公司,67%的软件是完全基于规则方法的。完全基于统计方法即machine learning方法的软件,在所有的供应商那里占33%,在大型的供应商那里只占了17%。

所以从学术界的研究到工业界的实践,有一个非常巨大的差异。为什么会有这样的差异?就是我刚才提到的,在发表论文的时候,完全不需要考虑现实中所会遇到的那些约束条件。在知识提取、实体提取领域,尽管现在从理论上来说,已经解决了,比如说实体识别问题、NER问题、分词问题,但是到了真正现实的语料中,发现这些方法都不好用。这也可以用另外一个问题来验证这一点,就是问答系统。

今天看到大部分的论文——我没有做精确的统计,只是基于模糊定性的看法——能看到大部分发表的问答系统的论文都是基于统计方法的。特别是这两年基于NLP的方法,尤其是基于端到端的方法的。无一例外,能够真正在工业中应用起来的问答系统,除了小冰这样的闲聊系统之外,真正的面向解决任务型的问答系统,全部都是用规则系统的。我还不知道哪一个是用深度学习的,当然也可能有用在某一个具体的细节,或者某一个组件上面,我没有见到过用于整体架构上。

所以当决定一个工程问题技术路线的时候,不一定要按照最新的论文趋势来做这件事情,甚至,论文和十年之后的技术都不一定有相关性。一定要根据现实的情况,根据现实的约束,来决定技术路线。

NO.3 脱离真正的应用场景

第三种方法:如果脱离了真正的应用场景,项目就注定会失败。

这里我用OWL2来说明。OWL2是一种语言,对于做语义网的同学们很熟悉了。

在Web上所知道的所有的这些标准化的格式,比如说HTML都是W3C,即万维网联盟设计的。万维网联盟也会负责Web上其他的协议,其中有一个协议叫OWL。它是在讲,在互联网上如何表达我们的知识。

比如说,一个餐馆要发布它的菜单,该用什么样的格式来发布?或者我现在要在网上发布我的简历,希望被谷歌更好地检索到。我要告诉谷歌,我是一个人,我姓什么,叫什么,出生年月是什么,我应该用什么样的格式发布这样的数据。其中一个格式就是OWL。OWL的第一个版本在2004年发布,第二个版本是在2010年发布。

OWL WORKING GROUP比较活跃的工作组的成员里面,有相当多的知名大学的老师,还有一些知名公司的科学家,包括IBM、Oracle、惠普。你们注意到,我刚才提到这些大公司的时候,有一些名字没有出现,比如说谷歌和Facebook。

OWL2本来希望想做的事情,是设计如何在网上表达并发布日常生活衣食住行信息的。但是,最终工作组成员的构成,一种是大学研究人员,另外一种是大公司做企业级应用的,大部分是远离场景的。

最终设计出来的产品,也就是OWL2语言,脱离了真正想去服务的那个场景。OWL WORKING GROUP在开会的时候,写了大概好几十个应用案例,但是大部分的案例都是这样的:一个制药公司要做一个药,应该怎么表达制药的知识,或者一个医生如何表达病历、疾病或基因,大体上都是这样的应用。没有任何一个案例是在讲述在网上如何找一个朋友,或者如何跟朋友聊天,或者如何去订餐,日常生活中的案例都是没有的。

OWL2最终写出来以后,有600页纸,这是一个非常复杂的语言。事实上,也就是在一些少量的企业级应用里面被用到了,在真正的日常应用当中,成功的案例几乎没有。这就是个典型的脱离了应用场景的项目,所以这个项目,花了很多钱,最终没有达到真实想达到的目标。

NO.4 使用过于领先的架构

第四种方法,使用过于领先的架构。

这也是跟前面第二种方法相呼应的,第二种方法说,你不能根据最新的论文来决定你的技术路线。第四种方法是在讲,如果你使用了一种特别先进的架构,反而有可能导致你的项目失败。

Twine在2007年被称为世界上第一个大规模的语义网的应用。当时是一个明星企业,这个公司到了2010年的时候关门了。为什么?Twine在成立的时候,想做一个语义书签的应用。比如说我读了一篇文章,我觉得很好,把它保存下来,留着以后再读。Twine的机器人就会分析我保存下来的这篇文章到底在说啥,然后给这个文章一个语义标签。如果有人订阅了我的标签,他就可以不断地看到我这个标签下收藏的好东西,就这么一个想法。

Twine在底层用了一个叫RDF的新数据库,RDF是一种语义网的语言,比关系数据库增强很多,它是可以进行推理的数据库。但是当Twine用户量达到200万的时候,它就遇到了一个瓶颈,数据库的性能不够。所以Twine的CEO就决定,开发一个新的数据库。

当时这个公司大概是40个人,用20个人来研发基础性的东西——一个新的语义数据库。2008年的时候,情况还不错,他们发现自己做的东西是个很好的东西,突然就在想,我们做的东西为什么只搜索书签?完全可以搜索整个Web上的东西。于是他们就做了一次转型,去做整个Web的语义搜索。步子太大,就把公司拖死了。到了2008年经济危机爆发的时候,资金链断裂,撑了一年以后就死了。

在死的时候,Twine的CEO Nova Spivack ,是我们领域非常值得尊重的一个先行者,也是一个技术大拿,同时也是一个非常成功的投资人。他就检讨了Twine的失败。他说我试图在太多的地方进行革新,我应该要么革新一个平台,要么革新一个应用,要么革新一个商业模式,但是我似乎在太多的地方都进行革新了,而且我使用了一种非常超前的架构,就是RDF数据库,导致了我要追求的目标太大,我无法达到这个目标。

我想他说的这个话,即使到今天,也是非常值得思考的。

这个项目相关的分析文章,我差不多每过两年都要仔仔细细地看一遍。Twine失败了以后, Nova Spivack 对公司进行了一次转型,成立了一个新的公司叫 Bottlenose,还是用了同样的技术,用在了更聚焦的应用场景上,从2C的服务转到2B的服务上去。

Bottlenose这个公司,到目前为止已经8年时间了,还是很成功的。2B的应用相对而言不太需要这么大量的数据,不用解决系统可伸缩性问题,突出了这个系统最核心的优势,即语义分析和理解能力。

像Twine这样失败的例子是不罕见的。用一个过于先进的架构的时候,通常会面临一开始很难去预期的一些风险,甚至不仅仅是像RDF数据库这样的小众的产品,更加大众的产品,也有可能会遇到这样的情况。

比如说有人经常会问我说,你们做知识图谱的应用,是不是一定要用图数据库?我就通常回答说不一定。

如果你熟悉图数据库,比如说你对 Neo4j 整个运维都非常地熟悉了,你知道它的JAVA虚拟机如果出错的时候,该如何处理;你知道它内存不够的时候,该怎么办;你知道怎么进行数据的分片,知道怎么进行主从的复制……所有这些运维问题都很熟悉的时候,你就可以试一试上这个应用。

在上应用的时候不要太着急,如果你只是一个在线应用,可以放一放,先把离线的这部分运维的工作搞清楚以后,然后再上线,也可以先用一个小数据集试一试。总之,步子不要太大。

NO.5 不能管理用户预期

第五种方法,不能管理用户预期。

这是一个特别常见的项目失败的原因,甚至不是因为技术上做不到,而是用户预期更大。

我先说一个技术上完全做不到的,比如说有一个银行,他们推出了所谓的机器人大堂经理,你可以跟一个机器人对话办理业务。显然,这个东西如果真的能够做到,应该是非常令人吃惊的事情,这已经远远超出当前技术边界。

最近有一个比较有名的骗局,就是机器人索菲亚。沙特阿拉伯还给了它第一个公民的身份,这是一个非常典型的诈骗。

这种类型的机器人是不太可能出现的。

在其他应用当中也会遇到这样的情况,尤其是对话机器人是最容易引起用户的图灵测试欲望。当用户发现跟他对话的是一个机器人的时候,他就会试图去调戏这个机器人。比如很多人都会去调戏siri,所以siri积累了很多段子,准备应对大家调戏。

如果你是提供了一个搜索引擎,那么大家的预期是比较低的。但如果你以一个问答引擎的形式,提供同样的内容,大家的预期就会高很多。

我们最早提供了一个终端级产品,用户的评价就不是特别好,后来我们调整了一下定位,把它调整成用搜索界面来提供服务,系统顶层的智能程度没有太大改变,但是用户的预期和评价马上就好起来了,因为用户预期降低了。这样的语义搜索引擎,相比其他的搜索引擎,其实还是好一些的。

对话机器人其实也一样,如果你给用户的预期,是能够跟他平等对话的机器人的话,通常是很难达到的。用户通常玩一玩就会发现好傻,然后就不玩了,所以大家注意到谷歌机器人跟Apple的siri机器人定位有很大区别,谷歌机器人不仅仅做对话,它能够预先帮你去做一些事情,甚至主动地去帮你做一些自动化的事情,其实这是非常聪明的选择。

目前能够跟人长期进行交互的机器人,其实是一个更加偏秘书型的,或者说它就是一个帮助你进行任务自动化的机器。如果你是立足于对话,其实很难满足用户预期,但是如果你立足于自动化,就比较容易达到用户预期。同样的技术,你用不同的方法去服务用户,用户预期不一样,用户的感觉就完全不一样。所以要尽可能地让用户感知到产品的成熟度,在他的预期之上,这个产品才有可能成功,他才愿意付费。

NO.6 不理解认知复杂性

第六点叫做不能理解认知复杂性。

这个事情我在刚开始的时候就提到了,这个例子就是Semantic Wiki,我写了很多个这样的系统,Semantic Wiki是什么呢?大家肯定都用过维基百科或者百度百科,这只是一个典型的维基系统,有很多人去写一个页面。Semantic Wiki也是基于协作的,也是一个Wiki,只不过在这个Wiki的页面上,你可以打一些标签,加一些注释。

它可以解决什么问题呢?比如可以解决页面之间的数据一次性问题,就是一个页面上的数据,可以流到另外一个页面上去,举个例子,比如说在维基百科上面,可以看到很多国家的GDP,就是国民生产总值,在中国的页面上,会有中国GDP,在亚洲国家的GDP列表上面,也会有中国GDP,然后在世界国家的GDP列表上,也会有中国GDP,那么是不是可以有一个机制,比如在一个页面,写下中国的GDP是多少,只要这个数字改变,其他所有页面上的数字会同步改变,用Semantic Wiki技术就可以做到这一点。当然Semantic wiki还可以做很多很酷的其他的事情,很强大。

我从2004年开始就开始写Semantic Wiki系统,前前后后写了三个Semantic Wiki系统,后来我加入了一个开源社区,叫 Semantic MediaWiki, 基于这样的系统,我做了一个很好的知识管理系统。

2010年我们试图来推广这个系统,当时是做了一个实验,也是一个美国的国家机构委托我们做的,就是要测试用这种协作的知识管理系统来记录一些事件,能不能记录得很好,好到可以后面让机器自动进行处理。

当时做的对比实验是找了一群RPI的计算机系本科生,让他们来看电视连续剧,看完以后描述情节。一部分人用自然语言来进行描述,一部分人用Semantic Wiki,以更加结构化的方式来进行描述。然后再找了学生来分别阅读前两组学生的描述,最后让他们来做题,看哪个组能够更精准地来复原电视剧情节。最后得到的结果发现是用自然语言描述是更容易,就是描述得更精准,速度更快。

然后我们仔细去看那些学生写的结构化的描述,发现是错误百出,比如说张三拥抱了李四,对于一般的所谓有过知识工程训练的人来看,很明显拥抱应该是一个关系,张三和李四应该是两个人,一个是主语,一个是宾语,那么就应该是主谓宾,张三拥抱李四是很清楚的一个知识建模,但是相当多的学生,他们把这么一个特别简单的建模就给搞错了,他们没有办法理解什么叫概念?什么叫关系?什么叫属性?甚至他们不知道什么叫主语和宾语?然后发现在一开始设想这件事情的时候,忽视了绝大多数的人,在他们的教育生涯中比如高中教育里面,是没有结构化思维的训练的,这是一种事先无法意识到的认知复杂性。

由于我们都经过十年以上的训练,所以就完全把这些东西当成是天然的事情。后来在OWL WORKING GROUP也遇到了同样的事情,有人说这个东西太复杂了,其中有一个逻辑学家就抗议说,这东西不复杂,这东西在计算机上跑的时候,它的算法复杂性只是多项式复杂性而已,然后我听了这句话以后,突然意识到了一个事情,就是在这些逻辑学家的脑子里面,他们所提到的复杂性是指一个语言对于机器的复杂性,所以我们通常把它称为计算复杂性。

但是实际上普通人所理解的复杂性不是这样的,比如说你半页纸就能说明白的东西,那是一个简单的东西,如果让我看到20页纸,才能看明白,那这个东西是一个复杂的东西。所以一个技术,你能不能够让程序员用起来,能不能让用户用起来,最核心的事情,你是不是能够让他们在认知上面觉得这东西,一看就懂,一听就懂,一打开就懂,不用解释,这才叫简单。

在很多算法的设计上面也好,文档的设计上面也好,应用的设计上也好,它最终能不能用得好,关键是让人感觉到它简单好用,这就是一个很重要的因素。斯坦福Parser,为什么在NLP领域里面被用的这么广,一个很重要的原因,它的文档写的好,每一个类都有文档,提供了足够多的案例。

所以好的文档可以极大地降低一个产品的认知复杂性,即使你的产品本身是复杂的,你把文档写好,也足以有助于推广这个产品,所以尽可能地让能够接触到你产品的人,不管是搞语言的,搞技术的,搞算法的人都感觉到这东西简单,是保证你的产品成功的一个关键。

NO.7 专业性不足

第七点,这一点就很好理解了,专业性不足。

我经常会遇到这样一些人,说某某公司现在想做一个问答系统,希望投入三五个人,可能大多数情况下没有博士,多数情况下可能就是一个工程人员,试图很快的时间,两三个月之内,甚至三五个月之内,把这样一个东西做出来,也是一种幻想。当然我不会直接说破。

人工智能产品,的的确确是有它的专业性的。很多机构想试图自己去做这样的事情,花了1000万、2000万、3000万冤枉钱,结果做不到。确实,如果没有一个足够专业的人是很难把这种事情给做成的。

我也经历了很多这样的事情,在曾经做过的一个语义理解系统里面,也经历了这样的问题。我想能够完成这样一个系统,实际上是要综合很多不同的算法,不是一个算法就能够解决掉的。比如说,从正面的例子来看,IBM Watson 系统里面有几十种不同的算法,有机器学习的算法,有自然语言处理的算法,有知识图谱的算法。你要把所有的这些算法恰到好处地组合在一起,拿捏的尺度就是一个特别重要的能力。你该用什么样的东西,你该不用什么样的东西。

比如说规则系统,任何一个人都可以写10条正则表达式,这是没有问题的。但是如果你能够写好100条正则表达式,那你一定是一个非常优秀的工程人员,你的软件工程能力很过硬。如果你能够管理好1,000条正则表达式,那你一定是一个科班出身的,有专业级的知识管理训练的人。如果你能够真正地管理好10,000条正则表达式,那你一定是一个有非常丰富的规则管理经验的人。

当然我说的1,000条、10,000条,并不是说你 copy paste 10,000次,改其中几个字,那个不算。人工智能的很多事情,困难就在这儿。你到网上去拿一个什么开源包啥的,你把它做到80%,都很容易做得到。但难度就在于最后的20%,通常可能需要98%、99%的正确率,才能够满足用户的需求,但是如果专业性不够,最后的这些点是非常难的。

打个比方说,你要登月的话,你需要的不是梯子,是火箭。你搬个梯子,最后只能爬到树上去,再也没办法往上走了。你需要的是停下来造火箭,造火箭就是专业性,如果专业性不足,你永远只是停留在80%的水平上,再也升不上去。

回到刚才讲的语义理解的项目。当时就遇到了蛮多困难,要能够集成规则的方法,集成统计的方法,集成自然语言处理的方法。当时全球有很多实验室一起来做这件事情,但缺这样一种角色,能够把所有的尺度拿捏得特别好的。

其实IBM把Watson系统做出来,也是经历了很多内部变迁,包括项目管理人的变化,包括各种技术选型的变化,能够做到这一些,这种人才是非常短缺的。在中国,能够真正从头到尾把一个语义的理解系统架构做好的人,是非常非常少的,也许10个,也许20个,数量确实不多。我相信在其他人工智能领域,也面临着同样的情况。

专业性也不会仅仅只局限于程序或者技术这一块,人工智能的产品经理,人工智能项目的运营,还有整个后面的知识系统,数据的治理,都是需要很专业的人来做,现在这些人才都非常地短缺。

NO.8 工程能力不足

第八种方法就是工程能力不足。

我的博士论文是一个分布式推理机,但因为编程能力不够,一直到我毕业为止,都没有能够把它实现出来。当然后来到了2012年、2013年之后,图计算,包括基于消息交换的图计算出来之后,那时候我再来做分布式推理机就比较容易了。

但这是我特别大的一个教训。

在这之后,我就比较关注,如果做一件事情,先能够把我的工程能力补足。这个工程能力,包括软件工程能力,如何写代码,如何管理代码,如何做系统集成,还有回归测试,如何进行代码的版本控制等等。后来我面试人的时候,也比较关注这些东西。

一个人工智能的技术能不能做得好,核心往往不仅仅是算法,而是底下的架构,还有系统。比如论文中其实是很好的分布式推理算法,但是我因为缺少这个架构,就没有办法把这个东西实现出来。后来像深度学习也是这样的。最近看到陈天奇他们的实验室,把算法、架构、操作系统都放在一个实验室里面来运作,觉得这是一个特别好的事情。目前算法和架构之间的裂缝太大了。

工程是解决人工智能的核心钥匙。如果代码能力不行,架构能力不行,工程能力不行,在这个情况下,根本就不应该去谈算法。优先应该把工程能力补起来,然后再谈算法。

NO.9 阵容太豪华

第九点,阵容太豪华。

这一点不太好说具体的项目是什么,太敏感了。

但是我就从逻辑上给大家讲一下。因为一个项目如果太豪华,核心的问题就是沉没成本。

我们也经常看到一些初创公司,不管是从商务上,还是从技术上,特别优秀的人组成了一个公司,最后还是会失败。为什么?因为比较优秀的人,就是想要做大的事情。一个大的事情,很难一下子就做对。通常大的事情,是从小的事情成长起来的。如果我们不能够让豪华的阵容,从小事做起,通常这样一个事情是会失败的。

逻辑很简单,我就不多说了。

NO.10 时机不到,运气不好

第十点,我可以把所有其他的因素丢到这儿,就是时机不到、运气不好。

其实可以把所有其他的事情都归结为运气不好。

比如说我们现在看深度学习,比如像attention、卷积、LSTM、联想记忆等等所有这些概念在90年代,我读研究生的时候,这些概念都已经有了,但是当时是做不到的。当时即使有了这些算法,也没有这样的算力,即使有了这样的算力,没有这样的数据。

在2000年的时候,我在硕士毕业之后,就在研究一种分层的多层神经网络。我们把它称为hierarchical neural network,跟后来深度学习的想法非常接近。我带着这个想法,去见我的博士导师。说我想继续沿着这个方向往前走,但他说现在整个神经网络都已经拿不到投资了,你再往前走,也走不下去,所以后来就放弃了这个方向,准备做语义网了。10年之后,这个方法终于找到了机会,后来就变成了深度学习的东西。

很多时候,时机不到,即使你有这个算法,你也做不到。90年代的神经网络,差不多花了10年的时间,才等到了自己的复苏。

知识图谱也是一样的,知识图谱大概也等了十几年的时间,到了最近这几年才真正地得到了大规模的应用。

总结

让我们来取个反,做个总结:

最后一点,时机和运气再啰嗦一下。

很多时候,我们是真的不知道这件事情能不能做得成,也真的不知道,自己处于什么样的历史阶段。很难预言未来是什么,但是至少有一点,如果我们多去了解一些算法层面的发展,包括人工智能的发展史,包括相关的这些技术的发展史,能够更好地理解未来。

所以我也推荐一下尼克老师的《人工智能简史》这本书。我看了两遍都挺有收获的。看了这东西,能更多地理解什么是时机,什么是运气。

有时候我也经常会读一些经典的文章,十年前或20年前的书,我读了还是挺有启发的。比如说,今年我又把Tim Berners-Lee《编织万维网》那本书又重新读了一遍,读了一遍以后,我就坚定信心了。

知识图谱这样一个互联全世界的记忆的系统,大概率到2030年能够实现,这还是一个很遥远的时间,但是根据历史规律,应该到2030年能实现了。

一方面,降低我们现在的预期,另一方面也给我们前进更大的鼓励。

场景跃迁理论

刚才反反复复提到了,要控制用户的预期,控制自己的预期。做一个项目,要从小到大,循序渐进。最后把所有的东西抽象到更高层面上,我自己总结为一个理论,叫场景跃迁理论。

这个理论的核心,是说一个人工智能的公司需要多次的产品市场匹配,就是Product-Market Fit。如果提供了一个产品,市场恰恰需要,而这个市场恰恰又很大,就说得到了一个产品市场匹配。

经典的互联网创业,通常做一次产品的市场匹配,就可以成功了。但人工智能往往要做好几次,互联网公司和人工智能公司很不一样。

一个称为养鸡场模式,一个称为养小孩模式。

互联网公司是一种养鸡场模式,它是一个大规模的复杂系统Complex system。它的关键是可扩展性。我养了一只鸡,我发现这只鸡不错,我养1万只鸡,这就是养鸡场模式。核心就是如何能养一万只鸡,这就叫可扩展性。

人工智能应用是另外一种类型的复杂系统,叫Complicated system,它是有非常多的组件,通常是上百种奇奇怪怪的组件组合在一起。它的核心并不是养一万只鸡,更多像养小孩一样,生完孩子,从小给他换尿布,给他喂奶,教他走路,教他说话,逗他玩,小学、中学、大学,一路把他养大,每一个阶段所面临的主要任务都不一样。你如何能够让这小孩成长,我们把它称为可演进性,这才是AI公司最核心的因素。

把一个AI的公司给养大,其实是特别不容易的事情。就跟养小孩一样,往往前5年的时间,都在搭团队,搞基础,特别辛苦。公司存活的观念就是,如何能够在演进的过程中,逐步地挣钱,而不是试图一步到位地找到市场产品结合点。不仅仅是在人工智能的阶段要挣钱,在人工智障的阶段,也要能够挣钱。

没有一个完整的系统,怎么能挣钱?只能够把系统中的某些组件拿出去,做部分的商业化。就好像毛毛虫到蝴蝶一样,毛毛虫要蜕皮,蜕好几次,才能变成一个蝴蝶。毛毛虫阶段,它要吃树叶子,在蝴蝶那个阶段,它是要吃花蜜,所以它在两个不同的阶段,它的商业模式是完全不一样的。人工智能公司也要蜕好几次皮。在早期的时候,因为产品还不够完善,所以人工智能公司早期都是外包公司,这是正常的,就应该接受,这是发展必经的阶段。

总结今天所说的一切,人工智能是一种新兴的事物,它是非常复杂的东西。很难用传统的旧经验来套这样一种东西的发展,必须经过很长时间的演化,才能够达到成熟的状态。而这个演化力才是我们想做一个成功的商业的尝试,最关键的因素。如何保证在一次又一次的场景跃迁当中,团队不散架,这样的能力,才是决定了某一个商业上面能不能成功的最大的关键。

我觉得不仅仅是商业,不管是在学校里做研究也好,还是在大型跨国公司里做研究也好,很多道理都是一样的。就是如何能够循序渐进地,从小到大地来做,谢谢大家!

 

来自:机器之心

https://www.jiqizhixin.com/articles/Ten-Ways-to-Die-in-AI-Startups

打赏作者
很喜欢这篇文章,赞赏一下作者,以激励其创作出更多好文!

您的支持将鼓励我们继续创作!

[微信] 扫描二维码打赏

[支付宝] 扫描二维码打赏

分享到社交网络:

发表评论

电子邮件地址不会被公开。 必填项已用*标注