改进人工智能经济学的冒险之旅

人工智能具有巨大的潜力，可以扰乱传统上软件无法企及的市场。这些市场一直依赖人类在自然语言、图像和物理空间中导航，它们代表着一个巨大的机会，在全球范围内潜在价值数万亿美元。

然而，正如我们在前一篇文章The New Business of AI中所讨论的那样，建立与传统软件一样具有吸引力的经济属性的人工智能公司可能是一个挑战。人工智能公司的毛利率往往较低，规模可能更难扩大，而且并不总是拥有强大的防御护城河。从我们的经验来看，这些挑战中的许多似乎都是问题空间特有的，我们还没有找到一个在所有情况下都能保证传统软件经济学的简单策略。

也就是说，许多经验丰富的人工智能公司建设者在改善他们公司的财务状况方面取得了巨大的进步，而不是天真的做法。他们使用跨越数据工程、模型开发、云运营、组织设计、产品管理和许多其他领域的一系列方法来做到这一点。经常指导他们的共同主线是对要解决的问题的深刻而实际的理解。

因此，虽然我们之前的帖子概述了人工智能企业面临的挑战，但这篇帖子的目标是提供一些如何应对这些挑战的指导。我们分享了通过与数十个领先的机器学习团队进行正式和非正式对话而学到的一些经验教训、最佳实践和获得的秘密。在很大程度上，这些是他们的话-不是我们的。在第一部分中，我们将解释为什么问题理解如此重要-特别是在存在长尾数据分布的情况下-并将其与我们上一篇文章中提出的经济挑战联系起来。在第二部分中，我们将分享一些可以帮助ML团队构建更高性能的应用程序和更有利可图的AI业务的策略。

我们非常看好人工智能的商业潜力，并继续在这一领域投入巨资。我们希望这项工作将继续引发讨论，并支持创始人建立持久的人工智能公司。

注意：这篇文章的重点是依赖机器学习(主要是有监督的学习)来交付其核心功能的重要部分的人工智能公司和产品，而不是依赖ML工具/基础设施或包括附加ML功能的传统软件。

正如一家后期数据初创公司的首席技术官所说，人工智能开发经常让人感觉“更接近制药领域的分子发现”*，而不是软件工程。

这是因为人工智能的发展是一个实验的过程，很像化学或物理。人工智能开发人员的工作是将统计模型匹配到数据集，测试模型在新数据上的执行情况，然后重复。这本质上是试图控制现实世界的复杂性。

另一方面，软件开发是一个构建和工程的过程。一旦定义了应用程序的规范和总体架构，就可以逐步添加新的特性和功能-每次添加一行代码、库或API调用-直到形成完整的愿景。此过程在很大程度上由开发人员控制，生成的系统的复杂性通常可以通过使用标准的计算机科学实践(如模块化、仪表化、虚拟化或选择正确的抽象)来控制。

与软件工程不同，人工智能应用程序很少由开发人员控制-系统的复杂性是训练数据本身固有的。对于许多自然系统来说，数据通常是杂乱的、厚尾的、不可预测的和高度熵的。更糟糕的是，开发人员编写的代码不会直接改变程序行为--一位经验丰富的创始人使用了这样的类比：“ML本质上是创建代码(作为输入数据的函数)…的代码。这又增加了一层很难理解的间接性。“**。

人工智能开发人员的工作是将统计模型匹配到数据集，测试模型在新数据上的执行情况，然后重复。这本质上是试图控制现实世界的复杂性。点击Tweet建立高效的人工智能公司的许多困难都发生在面对长尾数据分布时，这些数据在许多自然和计算系统中都有很好的记录。

虽然概念的正式定义可能相当密集，但其背后的直觉相对简单：如果您从长尾分布中随机选择一个数据点，它很可能(对于本文的目的，假设至少为50%，可能更高)处于尾部。

以互联网搜索词为例。分布的“头”和“中间”中的流行关键词(如下蓝色所示)在所有术语中所占比例不到30%。剩下的70%的关键词都在“尾部”，每个月的搜索量不到100次。如果您假设处理查询所需的工作量是相同的，而不管它位于分布中的什么位置，那么在重尾系统中，大部分工作将在尾部-在那里每个查询的值相对较低。

越来越明显的是，长尾分布在机器学习中也非常常见，它反映了现实世界的状态和典型的数据收集实践。例如，这些图表显示了几个流行的人工智能研究数据集中模型类的频率。

这些类型的分发不一定是不好的。但是--与互联网搜索的例子不同--当前的ML技术并不能很好地处理它们。有监督的学习模型往往在公共输入(即分布的头部)上表现良好，但在示例稀疏的地方(尾部)表现不佳。由于尾部通常占所有输入的大部分，ML开发人员最终陷入了一个循环中--有时似乎是无限的--收集新数据并重新培训以解决边缘情况。忽略尾部同样会带来痛苦，导致错失客户机会、糟糕的经济效益和/或沮丧的用户。

由于尾部通常占所有输入的大部分，ML开发人员最终陷入了一个循环中--有时似乎是无限的--收集新数据并重新培训以解决边缘情况。点击在Twitter上发布长尾-以及它创造的工作-被证明是建立人工智能业务经济挑战的主要原因。

最直接的影响是数据和计算资源的原始成本。ML的这些成本通常比传统软件高得多，因为需要如此多的数据、如此多的实验和如此多的参数才能获得准确的结果。据传闻，人工智能应用程序的开发成本和失败率可能比典型软件产品高出3-5倍。

然而，对云成本的狭隘关注忽略了长尾带来的两个更有害的潜在影响。首先，长尾可能会导致基础设施以外的高可变成本。例如，如果发送给聊天机器人的问题因客户而异-即很大一部分查询在尾部-那么构建一个准确的系统可能需要每个客户大量的工作。不幸的是，根据解决方案空间的分布情况，这项工作和相关的COGS(商品销售成本)可能很难设计出来。

更糟糕的是，致力于长尾问题的人工智能企业实际上可能会表现出规模不经济-这意味着相对于竞争对手，随着时间的推移，经济状况会变得更糟。数据的收集、处理和维护是有成本的。虽然相对于数据量，此成本往往会随着时间的推移而降低，但增加数据点的边际收益下降的速度要快得多。事实上，这种关系似乎是指数性的-在某个时候，开发人员可能需要10倍以上的数据才能实现2倍的主观改进。虽然人们很容易希望人工智能类似于摩尔定律，能够显著提高处理性能并降低成本，但这似乎并没有发生(尽管有算法上的改进)。

在接下来的内容中，我们将介绍从许多从业者那里收集的关于如何思考和解决这些问题的指导。

因此，许多人工智能系统都是为了预测复杂底层系统中的交互而设计的，从而导致输入数据的长尾分布。开发人员通常不能完全描述数据的特征，所以他们通过一系列(有监督的)学习实验对数据进行建模。这一过程需要大量的工作，可能会在业绩方面达到渐近线，并导致或加剧人工智能公司面临的许多经济挑战。

这是AI业务进退两难的症结所在。如果经济是问题的函数，而不是技术本身，我们如何改善它们？

没有简单的答案。在某些方面，长尾是对正在解决的问题的复杂性的衡量-即这是我们首先需要自动化的原因-并与解决它所需的努力直接相关。然而，有一些方法可以将长尾视为优先考虑的问题，并为其建立基础。

在这个主题上，我们从ML工程师和研究人员那里听到了很多很棒的建议。下面我们分享一些最好的和最具创新性的指导。

在某些方面，长尾是对正在解决的问题的复杂性的衡量，并与解决问题所需的努力直接相关。然而，有一些方法可以将其视为第一要务，并为其建设。点击Tweet在最简单的情况下，了解问题意味着确定您是否真的在处理长尾分布。如果不是-例如，如果问题可以用线性或多项式约束很好地描述-信息就很清楚：不要使用机器学习！特别是不要使用深度学习。

这可能看起来像是一群人工智能专家给出的奇怪建议。但它反映了一个现实，即我们在上一篇文章中记录的成本可能是巨大的-以及本文第一部分涉及的背后原因很难解决。随着模型复杂性的增加，这些问题也往往会变得更糟，因为复杂的模型的培训和维护成本很高。当使用不当时，它们甚至可能比更简单的技术执行得更差，倾向于过度参数化小数据集和/或产生在生产中迅速降级的脆弱模型。

Shopify的一位工程师指出，当你使用ML时，逻辑回归和随机森林之所以流行是有原因的--它们是可解释的、可伸缩的和经济高效的。更大、更复杂的模型在许多情况下确实表现得更好(例如，在语言理解/生成方面，或者在捕捉快速变化的社交媒体趋势方面)。但是，重要的是要确定何时精确度的提高可以证明培训和维护成本的大幅增加是合理的。

正如另一位ML领导人所说，“ML不是一种宗教，而是科学、工程和一点艺术。ML方法的词汇量相当大，虽然我们科学家倾向于将每个问题都看作是适合我们刚刚完成的锤子的钉子，但如果我们仔细观察，有时问题可能只是一个螺钉。“*。

如果您正在处理一个长尾问题(包括最常见的NLP(自然语言处理)、计算机视觉和其他ML任务)，那么确定跨客户、区域、细分市场和其他用户群的一致性程度至关重要。如果重叠度很高，您很可能可以为大多数用户提供全球模式(或整体模式)。这可能会对毛利率和工程效率产生巨大的积极影响。

我们在能够访问大型用户数据集的B2C技术公司中最常看到这种模式。同样的优势通常也适用于在相对低熵的环境中执行不受约束任务的B2B供应商，如自动驾驶车辆、欺诈检测或数据录入-在这些环境中，部署设置对用户行为的影响相当弱。

在这些情况下，通常仍需要进行一些本地培训(例如，针对大客户)。但是，您可以通过在全球范围内框定问题并围绕长尾主动构建来将其最小化。执行此操作的标准建议包括：

通过添加更多培训数据(包括客户数据)、调整超参数或调整模型体系结构来优化模型-只有在遇到长尾时才会有用

通过明确限制用户可以进入系统的内容来缩小问题的范围-这在问题有“胖头”(例如，专注于高价值联系人的数据供应商)或容易受用户错误影响时最有用(例如，在实施自动完成之前，LinkedIn假定有17,000个与IBM相关的实体)。

将问题转换为单转界面(例如，内容馈送、产品建议、“您可能认识的人”等)或提示用户输入/设计人工故障转移，以涵盖特殊情况(例如，自动车辆的远程操作)。

然而，对于许多现实世界的问题来说，这些策略可能并不可行。对于这些情况，经验丰富的ML构建器共享一种更通用的模式，称为组件化。

例如，Cloudflare的一位ML工程师分享了一个与机器人检测相关的示例。他们的目标是处理大量的日志文件，以识别(并标记或阻止)数百万网站的非人类访问者。把它当作单一的任务在规模上是无效的，因为“机器人”的概念包括数百个不同的子类型-搜索爬行器、数据刮取器、端口扫描器等-表现出独特的行为。使用集群技术，并对不同级别的粒度进行实验，他们最终找到了6-7类机器人，每个类别都可以用独特的监督学习模型来解决。他们的模型现在运行在互联网的一个有意义的部分，提供实时保护，具有软件般的毛利率。

组件化在许多大型生产ML系统中使用，包括广告欺诈检测、贷款承保和社交媒体内容审核。关键的设计元素是每个模型解决一个全局数据切片-而不是一个特定的客户-并且子问题相对有限且易于推理。事实证明，没有什么可以替代深厚的领域专业知识。

在组件化中，每个模型处理一个全局数据切片，子问题相对有限，易于推理。点击Tweet许多问题在客户或其他用户群中没有显示出全局一致性-几乎所有与我们交谈过的ML团队都强调，至少看到一些局部问题变化是很常见的。确定重叠也很重要，因为出于商业或监管原因，输入数据(特别是在企业中)可能是分开的。通常，全局问题和局部问题之间的区别在于可用数据的范围。

本地ML问题仍然经常具有必须解决的长尾分布。但这项工作可以根据局部变化的程度迅速增加。例如，一家大型音乐流媒体公司发现，他们在每个运营的国家都需要独特的播放列表生成模式。同样，工厂车间分析供应商通常会为他们服务的每个客户或装配线提供一个独特的模型。虽然这个问题没有简单的解决办法，但有几种策略可以帮助将全局模型的好处带到局部问题空间。

近期、实用的选择是元模型模式，在该模式中，单个模型经过培训以覆盖一系列客户或任务。这项技术往往是在研究环境(例如，多任务机器人)中最常讨论的。但对于AI应用公司来说，这也可以大幅减少他们需要维护的模型数量。例如，一家成功的营销初创公司能够将数以千计的线下、特定于客户的模型组合成单个元模型-这一模型总体上再培训的成本要低得多。

另一个新兴的解决方案是迁移学习。ML团队普遍热情地认为，预先培训的模型-特别是像BERT或GPT-3这样基于注意力的语言模型-可以全面减少和简化培训需求，最终使使用少量数据对每个客户的模型进行微调变得更加容易。这些技术的潜力毋庸置疑。然而，今天在生产中大量使用这些模型的公司相对较少-部分原因是它们的庞大规模使得它们难以操作且成本高昂-许多应用程序仍然需要针对客户的工作。这一前景看好的领域的好处似乎还没有被广泛认识到。

最后，几位大型科技公司的从业者描述了一种基于主干模型的迁移学习变体。例如，Facebook维护着数千个ML模型，其中大多数都是针对特定任务单独培训的。但随着时间的推移，共享相似功能的模型可以与公共的“主干”结合在一起，以降低复杂性。目标是使主干模型尽可能“粗”(即完成大部分工作)，同时使特定于任务的“分支”模型尽可能“薄”-而不牺牲精确度。在一个已公布的例子中，一个致力于自动化产品描述的人工智能团队将七个垂直特定的模型-一个用于家具，一个用于时尚，一个用于汽车等-组合成一个树干架构，其精确度是前者的2倍，运行成本也是前者的2倍。

在极限情况下，这种方法看起来很像全局模型模式。同时，它允许并行模型开发和高度的局部精度。它还为数据科学家提供了更丰富的嵌入式数据来处理，并将一些O(n^2)问题-如语言翻译，您必须将n种语言中的每种语言翻译成n种其他语言-转换为O(N)复杂性-其中每种语言都可以被翻译成中间表示。这可能预示着未来的发展方向，有助于定义ML开发过程的基本构建块或API。

一个致力于自动化产品描述的人工智能团队将七个垂直特定的模型-一个用于家具，一个用于时尚，一个用于汽车等-组合成一个树干架构，其精确度是前者的2倍，运行成本也是前者的2倍。最后，许多经验丰富的ML工程师强调了运营最佳实践对改善人工智能经济的重要性。这些是几个最令人信服的例子。

整合数据管道。模型的蔓延并不一定意味着管道的蔓延。当全局模型不可行时，一位创始人通过将大多数客户合并到一个对系统延迟影响相对较小的数据转换过程中，实现了效率提升。其他小组通过减少再培训的频率(例如，通过夜间队列或在积累足够的数据时)并在更接近数据的情况下执行培训来降低成本。

构建边缘案例引擎。如果你看不到长尾，你就不能解决它。例如，特斯拉(Tesla)组装了一个巨大的奇怪停车标志数据集，以训练他们的自动驾驶模型。以可重复的方式收集长尾数据是大多数ML团队的关键能力-通常涉及识别生产中的非分布数据(通过统计测试或通过测量不寻常的模型行为)、寻找类似的示例、标记新数据，以及智能地重新培训(通常使用主动学习)。

拥有基础设施。许多领先的ML组织运行(甚至设计)自己的ML集群。在某些情况下，这对初创公司来说也是个好主意-我们采访的一位CEO从AWS转向托管在托管设施中的自己的GPU盒，每年节省约1000万美元。创始人的关键问题是确定成本节约在多大程度上证明维护负担是合理的-以及如何。

.