文因互联 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年的时间，都在搭团队，搞基础，特别辛苦。公司存活的观念就是，如何能够在演进的过程中，逐步地挣钱，而不是试图一步到位地找到市场产品结合点。不仅仅是在人工智能的阶段要挣钱，在人工智障的阶段，也要能够挣钱。

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

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

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

—完—