知名风投机构：用“驯服长尾”的方式改良 AI 经济

神译局是36氪旗下编译团队，关注科技、商业、职场、生活等领域，重点介绍国外的新技术、新观点、新风向。

编者按：AI是最近很火的技术。似乎各行各业都可以应用AI。这么看来，做AI不仅很有前途，而且很有钱途吧？错了，人工智能公司的毛利率往往较低，很难规模化，而且未必总能具备牢固的护城河。那么怎么才能改善AI的经济效益呢？知名风投机构Andreessen Horowitz对众多经验丰富的从业者的意见进行了汇总，本领域的创业者可以借鉴一下。原文发表在官方博客上，标题是：Taming the Tail: Adventures in Improving AI Economics。

划重点:

人工智能公司的毛利率通常较低，很难扩大规模，并且未必总能具备有强大防御性的护城河。

跟软件工程相比，AI的开发感觉往往跟“制药里面的分子发现更相近”

要想解决AI经济性问题，对要解决的问题要有深刻的实践认识

AI的开发是一个实验过程，就像化学或物理一样，本质上是要控制现实世界的复杂性

有一点已经越来越明显，长尾分布在机器学习里面也非常普遍

长尾以及长尾制造出来的工作，是做AI业务遭遇经济挑战的主要原因

从某种意义上说，长尾是衡量要解决的问题的复杂性的标准，而且这也与解决该问题所需的工作直接相关

人工智能和机器学习才刚刚从形成阶段，进入到一个更加实用、高效的开发和运营阶段。

在传统上软件无法企及的市场上，人工智能具有巨大的颠覆潜力。这些一度要靠人类来驾驭自然语言、图像以及物理空间的市场，代表着一个巨大的机会，在全球潜在的价值高达数万亿美元。

但是，就像我们在上一篇文章《人工智能领域的新商业》中所讨论的那样，建设有着跟传统软件一样有吸引力的经济属性的人工智能公司可能会遇到挑战。人工智能公司的毛利率通常较低，很难扩大规模，并且未必总能具备有强大防御性的护城河。根据我们的经验，这些挑战当中有很多挑战似乎都是问题空间所特有的，而且我们还没有发现一种能保证传统软件经济性的，一体万用的简单手册。

话虽如此，相对于幼稚的做法，很多经验丰富的AI公司建设者在改善公司财务状况方面已取得了巨大进步。他们利用了包括数据工程、模型开发、云运营、组织设计、产品管理在内的众多领域的一系列方法来做到这一点。经常为他们提供指引的一个共同点是，对要解决的问题要有深刻的实践认识。

我们的上一篇文章对AI企业面临的挑战进行了概述，但本篇文章的目的是为如何应对这些挑战提供一些指导。我们跟几十家领先的机器学习团队进行了正式和非正式的对话，现在我们把他们总结出来的经验教训、最佳实践以及掌握的秘密分享给大家。在大多数情况下，本文列举的都是他们的话，而不是我们的话。在第一部分里，我们会解释为什么问题理解是那么的重要（尤其是在存在长尾数据分布的情况下），并将其与上一篇文章中提出的经济挑战联系起来。在第二部分里，我们会分享一些可以帮助ML团队开发性能更高的应用，建设更有利可图的AI企业的策略。

我们非常看好人工智能的业务潜力，并继续在这一领域进行大量投资。我们希望这项工作能不断引起讨论，并为建设有生命力的AI公司的创始人提供支持。

注：本文的重点是那些要靠机器学习（主要是有监督学习）来提供大部分核心功能的AI公司和产品，而不是那些依赖ML工具/基础设施或把ML当作附加功能的传统软件。

第一部分：理解要解决的问题是什么

开发 Vs. 实验（或软件 Vs. 人工智能）

就像一家数据方面的后期阶段初创企业的CTO所说那样，跟软件工程相比，AI的开发感觉往往跟“制药里面的分子发现更相近” 。

这是因为AI的开发是一个实验过程，就像化学或物理一样。AI开发人员的工作是将统计模型跟数据集拟合，测试该模型应用到新数据的表现如何，然后不断重复这个过程。这本质上是要控制现实世界的复杂性。

另一方面，软件开发是开发和设计的过程。把应用的规范和整体体系结构定义好之后，就可以逐步地添加新的特性和功能——一行一行地敲代码，一次写一个库，或者实现一个API调用——直至完整愿景成形。这个过程大部分都在开发者的控制之下，而所得到的系统的复杂性，往往用标准的计算机科学实践，比方说模块化、仪表化、虚拟化，或者选择正确的抽象就可以驾驭。

但AI跟软件工程不一样，开发人员对AI应用的控制几乎没有，因为系统的复杂性是训练数据本身固有的。至于众多的自然系统，其数据通常是凌乱的，严重的长尾化的，不可预测的，且熵非常的高。更糟糕的是，由开发人员编写的代码不会直接改变程序的行为，用一位经验丰富的创始人的类比来说：“ ML本质上是开发能写代码（作为输入数据的函数）的代码……这会建立一个难以推理的额外间接层。” 

AI开发人员的工作是将统计模型跟数据集进行拟合，测试该模型应用到新数据的表现如何，然后不断重复这个过程。这本质上是要控制现实世界的复杂性。

长尾与机器学习

面对（在许多自然和计算系统中都有详细记录的）长尾分布的数据时，要想建设一家高效的AI公司会遇到许多困难。

尽管这一概念的正式定义可能很难讲清楚，但长尾背后的直觉却相对简单：如果你从长尾分布里面随机选择一个数据点，则这个数据点很有可能（就本文而言，假设至少50 ％，甚至可能更高）就落在长尾之中。

就拿以互联网搜索关键字来说吧。落在长尾分布的“头部”和“中间部”的热门关键字（下方蓝色显示）所占的比例不到30％。其余70％的关键字都落在“长尾”之中，其每个月的搜索量不到100次。如果假设不管查询关键字落在在分布的任何位置，都需要花费相同的工作量来处理查询的话，那么在长尾型的系统里，大部分的工作都将落在长尾部分——每项查询的价值会相对较低。

搜素关键字的长尾效应

有一点已经越来越明显，长尾分布在机器学习里面也非常普遍，这是现实世界情况以及典型的数据收集实践的反映。比方说，以下图表展示了几个流行的AI研究数据集里面模型类别的出现频率。

AI的长尾效应

这些类型的分布未必就是糟糕的。但是，跟互联网搜索的样本不同的是，目前的ML技术还不能很好地处理这些情况。有监督学习模型对于常见输入（也就是分布的头部）的表现往往比较良好，但当样本是稀疏（尾部）的情况下就会遇到困难。由于尾部往往构占据了输入的大部分，所以ML开发人员最终会陷入到一个循环——有时似乎是无限循环里面——收集新数据并进行再训练来处理边缘情况。忽视长尾的结果可能同样令人痛苦，这回导致错过客户机会，经济性不佳及/或用户沮丧。

由于尾部往往构占据了输入的大部分，所以ML开发人员最终会陷入到一个循环——有时似乎是无限循环里面——收集新数据并进行再训练来处理边缘情况。

对AI经济性的影响

结果表明，长尾以及长尾制造出来的工作，是做AI业务遭遇经济挑战的主要原因。

最直接的影响是对数据和计算资源的裸成本的影响。机器学习在这方面的成本往往要比传统软件高得多，因为要想获得准确的结果，需要的数据、实验以及参数都太多了。有个佐证是，AI应用的开发成本和故障率可以比典型的软件产品高3到5倍。

但是，光是关注云成本的话会错过长尾巴带来的另外两个潜在的有害影响。首先，长尾会导致基础设施以外的高可变成本。比方说，如果发送给聊天机器人的问题会因客户而异，且差异较大的话（比方说，大部分查询都在长尾），则要想开发准确的系统可能需要针对每一位客户进行大量工作。不幸的是，这项工作和相关的COGS（销售商品成本）可能难以设计（要取决于解决方案空间的分布）。

更糟糕的是，解决长尾问题的AI企业可能会出现规模不经济，这意味着随着时间的推移，相对于竞争对手，其经济状况会变得越来越差。数据的收集、处理和维护是要成本的。尽管这方面的成本相对于数据量而言会随着时间的流逝而降低，但额外数据点的边际收益下降得更快。实际上，这种关系似乎是指数级的——到了一定时候，开发人员可能需要10倍以上的数据才能实现2倍的主观改善。虽然这个愿望很诱人——AI会出现一个类似于摩尔定律的东西，这个东西会极大提高处理性能并降低成本，但这个愿望似乎并没有实现（尽管在算法上有所改进）。

接下来，我们将介绍从众多的从业者那里收集到的有关如何思考和解决这些问题的指南。

第二部分：开发更好的AI系统

寻找解决方案

那么，很多AI系统都是为了预测在复杂底层系统当中的交互，从而导致了输入数据的长尾分布。开发人员往往没法对数据进行完全的特征化，因此他们通过一系列的（有监督）学习实验对其进行建模。这个过程需要大量的工作，在性能方面可能会触及渐近线，并导致或加剧AI公司面临的众多经济挑战。

这是AI企业困境的症结所在。如果经济性是问题的结果，而不是技术本身的话，那我们怎么才能改进它们呢？

这个问题没有简单的答案。从某种意义上说，长尾是衡量要解决的问题的复杂性的标准（也就是说，我们一开始之所以要自动化就是因为这个），而且这也与解决该问题所需的工作直接相关。但是，有一些方法可以把长尾看作是一阶问题，并针对它来加以开发。

关于这个问题，我们从ML工程师和研究人员那里听到了大量的宝贵建议。以下我们将分享其中一些最好的，最具创新性的指南。

从某种意义上说，长尾是衡量要解决的问题的复杂性的标准，而且这也与解决该问题所需的工作直接相关。但是，有一些方法可以把长尾看作是一阶问题，并针对它来加以开发。

简易模式：有界问题

在最简单的情况下，了解问题意味着要确定你是不是真的在处理长尾分布。如果不是这样的话（比方说，如果可以用线性或多项式约束合理地描述出问题的话），信息很明确：不要用机器学习！尤其是不要用深度学习。

一群AI专家提出这样的建议似乎很奇怪。但是，这反映了一个现实，那就是我们在上一篇文章里面所描述的成本可能是非常巨大的，而这背后的原因（在本篇文章的第一部分中已有介绍）很难绕开。随着模型复杂度的增加，这些问题往往会恶化，因为复杂模型的训练和维护成本很高。如果使用不当的话，它们的表现甚至可能比简单技术的性能还要糟糕，往往会对小型数据集过度参数化及/或生成在生产过程中会迅速退化的脆弱模型。

Shopify的工程师指出，在使用ML时，逻辑回归和随机森林之所以流行是有原因的——因为它们具备可解释性，可伸缩性以及成本效益。更大、更复杂的模型在很多情况下的表现更好（比方说，语言理解/生成，或捕获快速变化的社交媒体趋势）。但是，重要的是要确定准确性的提高什么时候可以证明训练和维护成本的显著增加是合理的。

就像另一位机器学习领导所说那样：“机器学习不是宗教，而是科学、工程学以及一点艺术的结合。机器学习方法的词汇量很大，虽然我们科学家倾向于把每一个问题都看作是正好用刚刚造出来的锤子可以锤的钉子，但如果我们仔细看一下的话，就会发现问题有时候可能只是一颗螺丝。”

更难模式：全局长尾问题

如果有个长尾问题（包括最常见的NLP自然语言处理问题,，计算机视觉以及其他的ML任务）要你解决，则确定该问题跨客户、区域、细分市场等用户聚类的一致性程度至关重要。如果重合度很高，就很可能可以用全局模型（或整体模型）来为大多数用户提供服务。这会对毛利率和工程效率产生巨大的积极影响。

在可以访问到大型用户数据集的B2C技术公司里面，这种模式最常见。对于在熵相对较低的环境（部署设置对用户行为的影响相当较弱），从事不受约束的任务（比方说自动驾驶汽车，欺诈检测或数据录入）的B2B供应商来说，同样的优势往往也适用。

在这种情况下，往往还是需要进行一些局部的训练（比方说，针对主要客户）。但是，通过将问题框定在全局范围内，并围绕着长尾主动开发的话，就可以将这种训练最小化。怎么做呢？标准建议包括：

• 通过添加更多的训练数据（包括客户数据），调整超参数，或者调整模型结构来优化模型——这一般只有在处理到长尾之后才有用

• 通过明确限制用户可以输入给系统的内容来缩小问题范围——当问题有一个“肥头”（比方说，专注于高价值接触点的数据供应商），或者容易受用户错误（比方说，LinkedIn本来有17000个与IBM相关的输入项，但后来他们推出了自动补全功能）影响的时候最有用

• 把问题变成单跳转界面（single-turn interface，比方说，信息流，产品推荐，“你可能认识的人”等），或提示用户输入/设计人工故障转移来应对特殊情况（比方说，自动驾驶汽车的远程遥控操作）

改善经济性的标准建议

但是，对于很多现实世界里面的问题来说，这些策略可能并不可行。对于这些情况，经验丰富的ML开发者分析了一种更加通用的模式，叫做组件化。

比方说，Cloudflare的ML工程师分享了一个跟bot检测有关的例子。其目标是对大规模日志文件进行处理，从中识别（并标记或屏蔽）数百万网站的非人类访客。把这个当作单个任务来处理在规模上是很低效的，因为“bot”这个概念涵括了数百种具有独特行为的不同子类型（搜索爬虫、数据爬虫、端口扫描程序等）。但是，他们运用了聚类技术，并尝试了各种级别的颗粒度，最终发现了6-7类的bot是可以利用独特的有监督学习模型来进行处理的。现在，他们的模型已经在互联网的重要部分上面运行着，提供实时保护，而且有着类似软件的毛利率。

改善经济性：组件化

组件化已在很多的大规模ML生产系统里面使用，包括广告欺诈检测，贷款风控，以及社交媒体内容审核等。其中的一个关键的设计元素是，每以个模型都处理一部分的全局数据切片，而不是局部数据，比方说特定客户，而且子问题相对有界且易于推理。结果表明，深厚的领域知识是没有替代品的。

在组件化的处理上，每个模型都处理一部分的全局数据切片，并且子问题相对有界且易于推理。

真的很难：局部长尾问题

很多问题都没有表现出跨客户或其他用户聚类之间的全局一致性——跟我们交谈过的几乎所有的ML团队都强调，至少在部分局部问题上存在差异是很普遍的。确定重合度也不是鸡毛蒜皮，因为输入数据（尤其是在企业的输入数据）可能会因为商业或监管原因而被隔离开。一般来说，全局问题和局部问题之间的区别就在于可用数据的范围。

局部ML问题往往也会出现长尾分布，也必须得到解决。但是，取决于局部变化的大小程度，这方面的工作很快就会成倍增加。比方说，一家大型音乐流媒体公司发现，自己需要针对每一个运营的国家/地区采用独特的播放列表生成模型。类似地，工厂现场分析供应商到头来往往要给自己所服务的每一位客户或装配线单独建立模型。尽管没有简单的解决方法，但是有几种策略可以帮助把全局模型的好处引入局部问题空间。

近期的一个实用选择是元模型（meta model）模式，也就是训练来覆盖一定范围的客户或任务的单个模型。对这种技术的讨论往往在研究环境下（比方说多任务机器人）最常见。但是对于AI应用公司来说，这还可以大大减少他们需要维护的模型数量。比方说，一家成功的市场营销初创企业可以将数千个跟特定客户相关的离线模型整合为一个元模型——总体而言，重新训练的成本要低得多。

还有一个新兴的解决方案是迁移学习。有一种狂热正在ML团队之间蔓延，那就是预训练的模型（尤其是基于注意力的语言模型，比方说BERT或GPT-3）可以减少和简化全面的训练需求，最终用小规模的数据量就可以搞定，使得针对每一位客户进行模型调整容易得多。毫无疑问，这些技术很有潜力。但是，目前还很少有公司在生产当中大量使用这些模型——这部分是因为它们的规模庞大，导致很难运营且成本高昂——而且很多应用仍然需要客户相关的工作。这个充满希望的领域的好处似乎还没有得到广泛认识。

最后，大型科技公司的一些从业者介绍了一种基于主干模型的迁移学习变体。比方说，Facebook就有数千个ML模型要维护，其中大多数都是分别针对特定任务来训练的。但是Facebook可以逐渐把有着相似功能的模型跟通用的“主干”结合到一起，以降低复杂性。这么做的目标是让主干模型尽可能的“粗壮”（也就是能完成大部分的工作），同时让跟特定任务相关的“分支”模型尽可能的“纤细”，但又不牺牲准确性。有这么一个公布的例子，有个做自动化产品描述的AI团队，他们七个跟特定垂直行业相关的模型（家具，时尚，汽车等）组合到一个集群式架构里面，其精度提高了1倍，运行成本却下降了一半。

在极限情况下，这种做法看起来跟全局模型模式很相似。但与此同时，这种模式又可以进行并行的模型开发，并且保证高度的局部精度。这种模式还为数据科学家提供了更加丰富的嵌入式数据，并可以把某些复杂度为O（n ^ 2）的问题（比方说语言翻译，你得把n种语言的每一种都翻译成其他n-1种语言）转换成O（n）的复杂度：做法是把语言翻译成中间表示。这也许是未来发展方向的一个风向标，有助于定义ML开发过程的基本建构块或者API。

有个做自动化产品描述的AI团队，他们七个跟特定垂直行业相关的模型（家具，时尚，汽车等）组合到一个集群式架构里面，其精度提高了1倍，运行成本却下降了一半。

筹码：运营

最后，很多经验丰富的机器学习工程师都强调，运营性的最佳实践对于提高AI经济效益非常重要。以下是一些最引人注目的例子。

整合数据管道。模型蔓延并未必就意味着管道的蔓延。当全局模型不可行时，通过以对系统延迟影响较少的方式将大多数客户组合到一个数据转换过程里面，一位创始人就实现了效率的提升。有的团队则通过降低再训练的频率（比方说，安排在晚上或在积累了足够的数据再训练），并用更接近数据的方式来进行训练，从而降低成本并进行更接近数据的培训来降低成本。

建立边缘案例引擎。如果看不到长尾，你就没法处理长尾。比方说，Tesla就建立了一个庞大的怪异停车标志数据集，然后用来训练他们的Autopilot模型。对于大多数机器学习团队来说，能够以可重复的方式收集长尾数据是一项至关重要的功能——这往往涉及到要（通过统计测试或通过识别异常模型行为）识别生产过程中处在分布区间以外的数据，寻找相似的样本，对新数据进行标记，并进行智能再训练（往往是采用主动学习的方式）。

拥有基础设施。很多领先的机器学习组织都跑有（甚至设计）自己的机器学习集群。在某些情况下，对于初创企业这也是个好主意——曾经有位CEO跟我们说，通过从AWS切换到自己放在主机托管处的GPU机器，他们每年节省了约1000万美元。对于创始人来说，关键的问题是，要确定成本节省多大的规模才能证明维护费用的合理性，还要确定云计算的价格曲线下降的速度有多快。

压缩，编译及优化。随着模型变得越来越大，支持高效推理和训练的技术（包括量化、提炼、修剪以及编译等）变得至关重要。这样的技术在预训练的模型或自动化的API帮助下在日益丰富。这些工具没法改善大多数AI问题的经济性，但可以规模化地帮助管理成本。

测试、测试，不断地测试。这听起来似乎是很显然的事情，但是一些专家鼓励ML团队要把测试作为优先事项，而不是基于F score这样的经典机制来看待。机器学习应用往往会以不确定的方式执行（并遭遇失败）。那些“bug”也许并不直观，因为坏数据、精确度不匹配或者隐性的隐私侵犯而被引入进来。升级通常还会涉及到很多的应用，而且缺乏向后兼容性。这些问题需要对数据分布，预期的漂移，偏见，对抗策略以及其他尚待梳理的因素进行可靠的测试。

人工智能和机器学习才刚刚从形成阶段（即炒作周期的期望膨胀期巅峰），进入到一个更加实用、高效的开发和运营阶段。围绕长尾等其他问题仍然有大量的工作要做，从某种意义上说，这是要对我们所熟悉的软件开发进行再造。人工智能的经济性不太可能会完全赶上传统软件。但是我们希望本指南能够帮助推动对话，并将经验丰富的AI建设者的一些宝贵建议提供给大家。

延伸阅读:

人工智能领域的新商业

译者：boxi。