详解AI公司三大类别，哪种商业模式将成为最后赢家？

转载时间：2022.03.28（原文发布时间：2017.09.09）

转载作者：36氪企服点评小编

阅读次数：48次

大数据文摘作品，作者 | Catherine Lu，编译 | 元元,白丁,笪洁琼,钱天培

在AI型公司的混战中，我们已看到了数不胜数的公司相继倒下。在剩下的AI巨头和后起之秀中，哪类公司又能成为最终的赢家呢？

从Element AI，Databricks到DigitalGenius，AI型公司铺天盖地席卷而来。各类公司分化出了不同的特性，也选择了不同的战略发展方向。

在他们中，我们能够看到为客户提供定制解决方案的“数据科学咨询公司”，为AI解决方案提供底层基础构架的“AI平台公司”，以及通过产品化解决方案解决某个特定商业问题的“垂直整合AI公司”。

在我看来，能够突破这一三足鼎立的局面笑到最后的，应当是垂直整合AI公司。

为什么这么说呢？

首先让我们从这三类公司的定位讲起。

数据科学咨询公司：产品化程度低
AI平台公司：产品化程度高，解决方法针对用例数多
垂直整合AI公司：产品化程度高，解决方法针对用例数少

详解AI公司三大类别，哪种商业模式将成为最后赢家？图片纵轴：(下)定制；(上)产品化

图片横轴：(左) 单个用例；(右)多个用例

图片内容：(左上)垂直整合AI公司; (右上)AI平台公司;(下)数据科学咨询公司

任何一类公司都有自己的优势和劣势。任何一个类别中也都有最优秀的公司。但是我认为最成功的公司会集中在垂直整合AI公司中。让我们一个个来分析看。

数据科学咨询公司

数据科学咨询公司的产品化程度较低。由于AI模型极其依赖于客户提供的数据，这类公司的主要优势在于他们更容易交付给客户更好的结果。这类公司的劣势在于不能很快的规模化。如果公司期望迅速增长，他们应该设法向其他类别的方向发展。

现在这类公司的数量越来越多。很多公司甚至并没有意识到他们已陷入了这个类别——直到他们发现公司规模化出现困难或者很难找到可以重复的用例。这些公司也许有独一无二的技术，可以获得很多客户，甚至有别的公司愿意高价收购。但是，要想发展超出一定的规模，他们一定要“成长”，并且把解决方案产品化。AI解决方案产品化是极其困难的，有两个主要原因。首先，如上文所述，很多AI产品极其依赖数据，而每个客户提供的数据各不相同。更进一步说，客户的确切需求也有很大差别。

Element AI是一家典型的数据科学咨询公司，这家公司今年夏初拿到了高达1亿200万美元的A轮投资。但目前为止，这家公司还没有一个具体的产品或者解决方法。他们的“解决方法组合”网页列出了15条不用的用例; “解决方法” 网页介绍说他们“构建易于整合入现有流程的定制应用程序”。基于他们获得的大量投资，Element AI未来应该会有所“成长”，并将他们的AI解决方案产品化。

产品化究竟是什么意思？如果一个解决方法可以多次安装，过程中几乎不需要定制，就可以说这个解决方法已经产品化了。产品化可以让公司收入增长速度远超成本增长速度。相反的，一个咨询公司雇佣的员工数量与公司同期的业务数量是大致成正比的。

幸运的是，对于Element Al和与其类似的公司而言，他们不需要做到完全产品化(即解决方案安装时完全不用定制)。举个例子，某AI公司决定要在产品化上投入工程师人力资源，目标是解决方案每次安装时定制成本降低80%。与达到完全产品化相比，完成80%的目标可能只需要20%的人力资源。剩下20%的解决费用可以作为合理的一次性安装费用转嫁给客户。因此，实现80%产品化的目标或许足以达到产品规模化的目的。

详解AI公司三大类别，哪种商业模式将成为最后赢家？

图表横轴：工程师人力；总轴：产品化

产品化还有其他好处。产品化可以给其他新入行的公司设置障碍。在其他新公司努力解决规模化问题的时候，本公司可以更快的整合，技术团队也可以把工作重心投入到开发公司的核心知识产权上。

AI平台公司

AI平台公司提供底层基础构架，而具体的AI解决方案可以在上面运行。AI平台允许终端客户导入数据，清理和变换数据，训练模型和验证模型。AI平台公司的例子包括H2O.ai公司, Skytree公司, 和 (最近转型的) Databricks公司。

这类公司有不少独特的优势。首先，他们面向的市场巨大。任何企图扩充自己AI工具的公司都是他们的潜在客户。除此之外，AI平台公司产品化程度高，因为平台仅仅基于底层运算构架，操作系统，和支撑硬件。最后，他们有一个产品粘性优势，意思是一旦某个公司依赖这个平台，该公司就很难离开这个平台了。

但是，大多数AI平台公司的生存空间也受到威胁：

开源AI项目数量和质量增长
会使用这些开源项目的程序员数量增长

近年来，开源项目在质量和可选性上取得了令人震惊的进步。谷歌TensorFlow库最初仅专注于深度学习，现在其覆盖范围已经拓展到训练、测试和机器学习模型维护等领域，并获得了广泛认可。TensorFlow一方面能够轻松训练出好用的模型，另一方面还能够凭借各种特性将模型应用到生产环境中（比如TensorFlow Serving）。此外，众多其他公司和个人的贡献也是开源环境发展的一大助力。雅虎旗下的一个开源项目就在Apache Spark上运行TensorFlow。脸书此前已经开放了其内部AI平台FBLearner Flow的代码，对开源机器学习库Torch也贡献良多。开发者David Cournapeau 于2007年创立的Scikit-learn也是大热的AI库之一，目前平台贡献者数量已超过900名。

越来越多的程序猿能够得心应手地使用这些开源工具。供给在需求的刺激下不断攀升，而未来五年，数据科学相关岗位需求量预计将增长15%。此外，新一代数据科学家相比“前辈”分析人员也刷新了不少技能点：前者能够熟练运用数据科学课程中涉及的标准化开源AI工具，而后者主要是通过SAS、Excel、Alteryx和MATLAB等封闭式平台来学习数据操作和建模。

在上述两大趋势的推动下，大多数企业都会投向开源工具的怀抱，有些还会聘请咨询顾问来协助工具的具体落实；而真正的AI平台公司可以施展拳脚的余地也就所剩无几了。

AI平台公司的日子并不好过，市场上已经出现了这方面的迹象。H2O.ai在2016年9月裁员10%，力图从“广撒网”式销售模式转型为针对少数精选客户的“深耕细作”。公司有可能沿着产品化轴线深入发展，推出的解决方案在定制化色彩更加浓厚的同时也能为公司带来更大的订单（销售团队规模也更小）。另一个比较常见的发展方向是专注某一个用例集，最终演变为垂直AI公司。

Databricks凭借其全球领先的Apache Spark专业知识和人才，有可能打造出无与伦比的AI平台。举例来说，他们可能会专为推动AI而对Spark进行重大改进，而这正是其他公司很难复制的。在与开源解决方案难分伯仲的情况下，Databricks的竞争对手就会变成采用开源解决方案的内部团队和其他公司（比如IBM的Data Science Experience就推出了在Spark上运行的Jupyter笔记本电脑）。换个思路，Databricks也可能专攻垂直AI解决方案，并将之作为主要收入来源。

垂直AI 公司

垂直AI 公司通过产品化的解决方案解决某一个或一系列的商业问题，帮助他们的企业客户借助AI实现进一步提升，而无需企业在内部构建或维护模型。这类案例不胜枚举，比如提供客户支持服务的DigitalGenius，提供招聘服务的Entelo，提供网络安全服务的Cylance，以及提供欺诈识别服务的DataVisor（我所在的公司）。

今年早些时候，Andrew Ng在《为什么AI是新电能》一文中也提到这一情况。在文中他这样写道：

正如电能为上个世纪带来了翻天覆地的变化，几乎没有事物没有被这一浪潮裹挟；如今我绞尽脑汁，也想不出几年后还有什么行业是AI改变不了的。

AI的强化范围不仅包括现有企业的核心技术，支持运营也被纳入到了羽翼之下，具体包括销售、营销、客户支持、内部通信、金融等不一而足。然而上述领域并非核心IP，因此企业也不会煞有介事地将之列为AI解决方案的优先改善对象，而是会采取购买解决方案的方式。垂直AI公司的机遇正在此处。

因此，垂直AI企业能够充分发挥产品化解决方案的作用来扩大公司体量，却无需头疼困扰AI平台企业的生存问题。然而相比AI平台企业，垂直AI企业的短板在于这块市场蛋糕更小，同行竞争也更加激烈。但如果包括Andrew Ng在内的等人是正确的，这块还在不断变大的蛋糕还是能够容纳所有市场的垂直AI公司佼佼者的。也正基于这一点，我认为AI领域的大多数赢家都将是垂直AI公司。

当然，并不是所有垂直AI公司都能笑到最后。赢家必须满足三个主要条件。

首先，公司的解决方案必须能够解决实际问题，并有强有力的成功案例作为背书。确实有一些垂直AI公司靠一些酷炫名词来唬人，然而他们的解决方案事实上根本无法发挥AI的作用。对于那些挂羊头卖狗肉的AI公司来说，他们的问题在于凭借三寸不烂之舌，把那些差强人意的解决方案卖给不太懂技术的消费者。

其次，公司的解决方案不论是现在还是未来，都切忌与公司内部团队竞争。如果公司的内部团队已经在着手解决这个问题了，那么想要把你的AI解决方案再卖给他们简直比登天还难。进一步来看，把AI解决方案卖给想要内部消化这个问题的公司具有长期性风险，可能会导致教会徒弟、饿死师傅的局面发生，最终还是由公司内部团队取代你的解决方案。

第三，整合工作应控制在合理范围内。“合理”的定义取决于解决方案的投资回报率以及终端客户的身份。有些客户认为“合理的”整合时间是一天，而其他人会认为如果投资回报率很高的话，一年也是合理的。如果不存在重大的制约因素，那么解决方案的整合工作就不是什么大事；如果解决方案依赖于客户数据或基础框架，那么就必须严肃认真地加以考虑。