正如一个后期数据启动公司的CTO所说，与软件工程相比，人工智能开发通常感觉“更接近于制药领域的分子发现”。

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

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

与软件工程不同，开发人员对AI应用程序的控制很少-系统的复杂性是训练数据本身固有的。对于许多自然系统，数据通常是凌乱的，拖尾的，不可预测的以及高度熵的。更糟糕的是，由开发人员编写的代码不会直接改变程序的行为–一位经验丰富的创始人使用了一个比喻，即“ ML本质上是创建代码的代码(根据输入数据的功能)……这将创建一个难以理解的附加间接层。原因。”

长尾与机器学习

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

尽管对该概念的正式定义可能非常密集，但其背后的直觉却相对简单：如果您从长尾分布中随机选择一个数据点，则很有可能(就本文而言，假设至少50 %，甚至可能更高)。

例如，这些图表显示了几个流行的AI研究数据集中的模型类别的频率。

当前的机器学习技术不能很好地处理这些类型的分布。监督学习模型往往在常见输入(即分布的开头)上表现良好，但在示例稀疏(结尾)的情况下会遇到困难。由于尾部通常构成所有输入的大部分，因此ML开发人员最终会陷入一个循环-有时似乎是无限的-收集新数据并进行再培训以解决边缘情况。忽视尾巴可能同样令人痛苦，导致错过客户机会，经济不佳和/或沮丧的用户。

对AI经济学的影响

长长的尾巴及其产生的工作被证明是建立AI业务的经济挑战的主要原因。

最直接的影响是对数据和计算资源的原始成本。机器学习的这些成本通常比传统软件要高得多，因为要获得准确的结果需要大量的数据，大量的实验和大量的参数。有趣的是，人工智能应用程序的开发成本和故障率可能比典型软件产品高3-5倍。

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

更糟的是，AI企业工作的长尾问题实际上可以显示不经济的规模-这意味着经济在相对于竞争对手的时间变得更糟。数据具有收集，处理和维护的成本。尽管此成本相对于数据量而言会随着时间的流逝而降低，但附加数据点的边际收益下降得更快。实际上，这种关系似乎是指数级的–在某些时候，开发人员可能需要10倍以上的数据才能实现2倍的主观改进。虽然很希望有一个与摩尔定律类似的AI能够大大提高处理性能并降低成本，但似乎并没有发生(尽管算法有所改进)。

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

简易模式：有限的问题

在最简单的情况下，了解问题意味着确定您是否实际上正在处理长尾分布。如果不是这样(例如，如果可以使用线性或多项式约束合理地描述问题)，则信息很明确：不要使用机器学习!而且特别是不要使用深度学习。

这似乎是一群AI专家的奇怪建议。但这反映了一个现实，那就是我们在上一篇文章中记录的成本可能是巨大的，而造成这些成本的原因很难解决。随着模型复杂度的增加，这些问题也趋于恶化，因为复杂模型的训练和维护成本很高。如果使用不当，它们甚至可能比简单的技术表现更差，往往会过分参数化小型数据集和/或生成在生产中会迅速退化的脆弱模型。

Shopify的工程师指出，当您使用ML时，逻辑回归和随机森林之所以流行，是有原因的-它们具有可解释性，可伸缩性和成本效益。更大，更复杂的模型在许多情况下的表现更好(例如，对于语言理解/生成或捕获快速变化的社交媒体趋势)。但是，重要的是要确定何时提高准确性才能使培训和维护成本大幅度增加。

正如另一位机器学习领导者所说：“机器学习不是宗教，而是科学，工程学和一点艺术。机器学习方法的词汇量很大，虽然我们的科学家倾向于将每个问题都看作是刚完成的锤子所适合的钉子，但如果我们看上去精确的话，问题有时可能只是螺丝钉。”

更难：全球长尾巴问题

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

在访问大型用户数据集的B2C技术公司中，我们最经常看到这种模式。对于B2B供应商来说，同样的优势通常适用于在相对较低的熵环境(例如自动驾驶汽车，欺诈检测或数据输入)中从事不受约束的任务，在这些环境中，部署设置对用户行为的影响相当弱。

在这种情况下，通常仍需要进行一些本地培训(例如，针对主要客户)。但是，您可以通过在全局范围内构建问题并在长尾巴上主动构建来最小化问题。为此的标准建议包括：

通过添加更多训练数据(包括客户数据)，调整超参数或调整模型体系结构来优化模型，这往往只有在您长篇大论之后才有用

通过明确限制用户可以进入系统的范围来缩小问题的范围，当问题“浮躁”(例如，专注于高价值联系人的数据供应商)或易受用户错误影响(例如，Linkedin)时，此方法最有用拥有17,000个与IBM相关的实体，直到他们实现自动完成)

将问题转换为单转界面(例如，内容提要，产品建议，“您可能认识的人”等)，或提示用户输入/设计人员故障转移以涵盖特殊情况(例如，自动驾驶汽车的遥控操作)

但是，对于许多现实世界中的问题，这些策略可能并不可行。对于这些情况，经验丰富的ML建设者共享了一种更通用的模式，称为componentizing。

例如，Cloudflare的ML工程师分享了一个与漫游器检测相关的示例。他们的目标是处理大量日志文件，以识别(并标记或阻止)数百万个网站的非人类访问者。将其视为单个任务在规模上是无效的，因为“机器人”的概念包括数百种表现出独特行为的不同子类型(搜索爬网程序，数据抓取程序，端口扫描程序等)。但是，他们使用集群技术并尝试了各种级别的粒度，最终发现了6-7类机器人，每种机器人都可以使用独特的监督学习模型进行处理。他们的模型现在在Internet的重要部分上运行，提供实时保护，并具有类似于软件的毛利率。

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

真的很难：本地长尾巴问题

许多问题并未显示出客户或其他用户群之间的全局一致性-与我们交谈的几乎所有ML团队都强调看到至少一些局部问题的变异是多么普遍。确定重叠也是很重要的，因为输入数据(尤其是在企业中)可能出于商业或监管原因而被隔离。

例如，一家大型音乐流媒体公司发现，他们需要针对每个运营国家/地区使用独特的播放列表生成模型。同样，工厂现场分析供应商通常会为他们服务的每个客户或装配线提供唯一的模型。尽管没有简单的解决方法，但是有几种策略可以帮助将全局模型的好处带入局部问题空间。

近期实用的选择是元模型模式，在该模型中，单个模型经过训练可以覆盖一系列客户或任务。在研究环境中(例如多任务机器人)，最经常讨论这种技术。但是对于AI应用程序公司来说，它也可以大大减少他们需要维护的模型数量。例如，一个成功的市场营销初创公司能够将数千个特定于客户的离线模型整合为一个元模型-总体而言，重新培训的成本要低得多。

另一个新兴的解决方案是转移学习。机器学习团队之间普遍存在着热情，即预先训练的模型(尤其是基于注意力的语言模型，例如BERT或GPT-3)可以减少和简化全面的训练需求，最终使为小客户细化每个客户的模型变得更加容易数据量。毫无疑问，这些技术的潜力。但是，如今很少有公司在生产中大量使用这些模型-部分是由于它们的庞大规模使其难以操作且成本高昂-并且在许多应用中仍需要针对客户的工作。这个有前途的领域的好处似乎尚未得到广泛认识。

最后，大型科技公司的一些从业者描述了一种基于主干模型的转移学习的变体。例如，Facebook维护着数千个ML模型，其中大多数是分别针对特定任务进行训练的。但是随着时间的流逝，可以将共享相似功能的模型与通用“主干”结合在一起，以降低复杂性。目标是使躯干模型尽可能“薄”(即完成大部分工作)，同时使任务特定的“分支”模型尽可能“薄”，而又不牺牲准确性。在一个公开的例子中，负责自动产品描述的AI团队将七个垂直特定模型(一个用于家具，一个用于时尚，一个用于汽车等)组合到一个单一的集群式架构中，该架构的精确度是前者的2倍，并且运行成本更低。

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

赌注：操作

最后，许多经验丰富的机器学习工程师强调了操作最佳实践对提高AI经济效益的重要性。以下是一些最引人注目的示例：

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

构建边缘案例引擎。如果看不到长尾巴，就无法解决。例如，特斯拉组装了庞大的怪异停车标志数据集，以训练他们的自动驾驶仪模型。对于大多数机器学习团队而言，以可重复的方式收集长尾数据是一项至关重要的功能–通常涉及识别生产中的失配数据(通过统计测试或通过测量异常模型行为)，寻找相似示例，标记新数据，并经常采用主动学习的方式进行智能再培训。

拥有基础架构。许多领先的机器学习组织运行(甚至设计)自己的机器学习集群。在某些情况下，这对初创公司也是个好主意-与我们交谈的一位首席执行官每年通过从AWS切换到托管在托管设备中的GPU盒，每年节省约1000万美元。创始人的关键问题是，确定节省多少成本才能证明维护负担合理，以及确定云价格曲线下降的速度如何。

压缩，编译和优化。随着模型的不断发展，支持有效推理和训练的技术(包括量化，蒸馏，修剪和编译)变得至关重要。通过预训练的模型或自动API，它们也越来越多。这些工具不会改变大多数AI问题的经济性，但可以帮助大规模管理成本。

测试，测试，测试。这听起来似乎很明显，但是一些专家鼓励ML团队将测试作为优先事项-而不是基于F分数之类的经典机制。机器学习应用程序通常以不确定的方式执行(并失败)。“错误”可能是不直观的，是由于不良数据，精确度不匹配或隐式侵犯隐私而引入的。升级通常还会涉及许多应用程序，并且不存在向后兼容性。这些问题需要对数据分布，预期的漂移，偏见，对抗策略以及其他尚待整理的因素进行可靠的测试。

人工智能和机器学习才刚刚从其形成阶段(以及炒作周期的顶峰)开始出现，进入一个更加实用，高效的开发和运营阶段。围绕长尾巴和其他问题，仍有大量工作要做，从某种意义上说，是在重新发明熟悉的软件开发结构。人工智能的经济状况不太可能会完全匹配传统软件。但是我们希望本指南将有助于推动对话，并传播经验丰富的AI构建者的一些宝贵建议。