创业干货确保搞砸人工智能项目的10种方法

　　「创业干货」：确保搞砸人工智能项目的十种方法

　　 16:05来源://

　　原标题：「创业干货」：确保弄砸人工智能项目的10种方法

　　 | 都保杰

　　作者介绍：鲍捷，文因互联 ceo，拥有20年学术界和工业界的相干经验。美国iowa state university人工智能博士，rpi博士后，mit访问研究员，w c owl(web本体语言)工作组成员，前三星美国研发中心研究员，三星问答系统svoice第二代系统核心设计师。主要研究领域涵盖人工智能的诸多分支，包括机器学习、神经络、数据发掘、自然语言处理、情势推理、语义和本体工程等，发表了70多篇领域内相干论文。

　　干货分享：

　　我今天的题目是《确保弄砸人工智能项目的十种方法》，按照这十种方法，基本上可以弄砸项目。之所以能够讲这个题目，是由于我自己之前也搞砸过很多项目，下面列表里超过一半的项目最后是失败的：

　　我开始想，为何大部分的项目最后做不成？

　　我经历了好几次很痛苦的时刻，比如刚到rpi（伦斯特理工学院）做博士后，这个学校有全美做知识图谱最好的实验室，实验室的james hendler和deborah mcguinness，都是这个领域最好的老师。

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

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

　　我不停地在想，人工智能项目失败的核心缘由到底有哪些？

　　固然，后来经历了更多的失败。基于这些直接或者间接失败的经历，我逐步总结出来确保一个项目会失败的一些原因。这些缘由很多时候看起来是反直觉的，我会逐一地跟大家讲。在最后，我也会总结如果想要避免这10个坑，应当做甚么。

　　no.1 一下子砸很多的钱

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

　　我目前也在创业，有vc问我：“你们做的这个事，如果bat砸很多的钱，是否是就一下子能赶上你们？”

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　也有一些大公司投比这还多得多的钱来做ai项目。这些都不一定让事情更容易成功。这是第一种方法，一下子砸很多钱。

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

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

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

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

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

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

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

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

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

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

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

　　no. 脱离真正的应用场景

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

　　这里我用owl2来说明。owl2是一种语言，对于做语义的同学们很熟习了。

　　在web上所知道的所有的这些标准化的格式，比如说html都是w c，即万维联盟设计的。万维同盟也会负责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，以更加结构化的方式来进行描述。然后再找了学生来分别阅读前两组学生的描写，最后让他们来做题，看哪个组能够更精准地来复原电视剧情节。最后得到的结果发现是用自然语言描写是更容易，就是描述得更精准，速度更快。

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

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

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

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

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

　　no.7 专业性不足

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

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

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

　　我也经历了很多这样的事情，在曾做过的一个语义理解系统里面，也经历了这样的问题。我想能够完成这样一个系统，实际上是要综合很多不同的算法，不是一个算法就能够解决掉的。比如说，从正面的例子来看，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 工程能力不足

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

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

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

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

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

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

　　no.9 阵容太豪华

　　第九点，阵容太奢华。

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

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

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

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

　　no.10 时机不到，运气不好

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

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

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

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

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

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

　　总结

　　让我们来取个反，做个总结：

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

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

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

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

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

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

　　场景跃迁理论

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

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

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

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

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

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

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

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

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

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

　　：

　　声明：该文观点仅代表作者本人，搜狐号系信息发布平台，搜狐仅提供信息存储空间服务。

　　浏览 ()