预测性数据库查询能取代机器学习模型吗？

当今技术版图中最大的趋势之一是机器学习的民主化。因为这种商品拥有最先进的模型、更好的工具和更容易获得的硬件：机器学习正在成为公司工具箱中的日常工具。

ML民主化仍然是一个正在进行的趋势，考虑到这个领域的破坏，值得问一问：这种转变将把我们带到哪里？日常ML的未来会是什么样子？

预测性查询是机器学习的一种有趣的方式，特别是在ML民主化的上下文中。像麻省理工学院的BayesDB/BayesLite和Aito这样的解决方案提供了一种使用类似SQL的查询立即获得任意预测的方法。作为示例，下面是Aito中的一个预测性查询：

因此：预测性查询似乎是进行机器学习的一种更容易、更快且截然不同的方式。它们给出了一个未来的一瞥，在那里，任何人都可以像进行数据库查询一样容易地进行机器学习。

本文简要介绍了预测查询，并从3个不同的方面对预测查询和有监督学习进行了比较：

工作流，比较预测查询和有监督机器学习的简易性和代价。

该体系结构比较了使用预测性查询和使用监督模型之间的高级差异。

而作为质量的定性属性(比例、准确性)显然是新兴技术(如果前景看好)的一个关注点。

预测性查询类似于普通数据库查询，不同之处在于它们提供关于未知的预测，而传统的数据库查询提供关于已知的事实。以下是针对BayesDB/BayesLite数据库执行的BQL(贝叶斯查询语言)查询的示例：

本质上，预测性查询可以为受监督的ML模型提供非常类似SQL的替代方案，主要区别在于：

虽然有监督的机器学习模型需要在使用前配置、训练和部署，但预测性查询在数据库准备好数据后提供即时答案。因此：预测性查询具有不同的工作流程。

虽然有监督的机器学习总是专用于从A到B的单个预测，但是可以使用预测性查询a)基于任何已知的Y即时预测任何未知的X，并且b)还提供推荐、智能搜索和模式挖掘。因此，监督模型是狭窄的，而预测查询是多用途的，这对体系结构有影响。

在有监督机器学习的情况下，狭义模型在训练时显式形成，而预测查询在查询时进行多用途建模写入时或狭义建模。因此：预测性查询在技术上更具挑战性。

提供这种预测性查询的解决方案很少。一种是前面提到的BayesDB/BayesLite，它在特殊的准备阶段创建内存中的多用途模型。另一种解决方案是Aito.ai，它在没有显式准备的情况下进行查询时狭义建模。以下是Aito工作流的示例：

我们将重点放在爱藤身上进行以下比较。我们认为这一重点是合理的，因为在Aito，我们更熟悉解决方案，而且它已经足够成熟，可以在现场生产环境中为最终客户服务。虽然BayesLite令人印象深刻，它们的BQL接口和DB/ML集成值得羡慕：BayesLite似乎具有简单数据16分钟准备阶段的属性，这与所给出的论点不一致。

因此，接下来让我们更深入地挖掘预测性查询和监督ML模型在工作流、体系结构和质量方面的不同之处。

预测查询与传统监督模型的第一个不同之处在于工作流程和成本。

有监督的ML模型通常部署在数据科学项目中，这些项目有几个步骤，如移交给数据科学家、数据准备、特征工程、模型拟合、部署、集成、再培训以及监控和维护。作为这种线性过程的补充，您通常还会有一个迭代阶段，在该阶段中，通过细化数据、准备、功能、模型、部署或集成来改进结果。

把一个有监督的模型投入生产可能需要几周或几个月的时间，从一人到两人不等。这可以将每款车型的价位提高到10万欧元。如果您需要多个模型，则需要多个数据科学项目，从而导致成倍增加的费用和延误。

现在，如果您使用预测性查询实现机器学习功能，那么这个过程会发生相当大的变化。对于预测性查询，工作流程本质上如下：

准备一次辅助预测数据库(如果它不用作主数据库)。

编写测试/评估案例，将这些案例推送到Git，让CI处理回归测试。

如有必要：使用分析跟踪生产中的预测质量，并在产品仪表板中显示指标。

虽然将辅助数据库(如ElasticSearch)投入生产可能需要数周时间，但将每个查询投入生产的相关费用更接近使用搜索/数据库查询的费用。通常，这样的查询只占相关功能费用的一小部分，并且通常基于查询的功能可以在几小时内实现，并在几天内投入生产。

工作流和费用之间的巨大差异可以解释如下：a)部分原因是预测数据库的AutoML功能由专门的数据库加速，b)部分原因是部署和集成的需求减少，因为数据和ML已经集成到单个系统中。系统地消除或简化了数据科学项目的复杂阶段：

不需要将数据科学项目移交给数据科学家，因为预测性查询工作流程对于软件开发人员来说足够容易。

ML-数据库集成可以极大地消除数据准备和特征工程步骤。如果数据已经在数据库中，则不需要重新准备和重新上传数据。如果可以通过数据库引用进行推理，则不需要手动将数据聚合到平面数据框中。您也不需要手动对文本进行特色化，因为预测性数据库会像ElasticSearch一样自动分析文本。最后：如果数据库具有内置的功能学习功能，则不需要管理功能冗余。

建模阶段可以通过单个复杂的模型实现自动化，该模型可以为大多数应用程序提供足够好的结果。

对于每个模型云部署，模型的实时集成和再培训都会消失，因为您不需要“部署”或重新培训预测性查询。相反，您可以像集成ElasticSearch一样集成一个辅助预测数据库。如果您使用预测数据库作为您的主数据库，您甚至可以省略那个集成。

维护更容易，因为不需要为每个预测目标维护已部署的基础设施，而是像使用Git&；CI维护代码一样维护类似SQL的查询。

因此，通过预测性查询实现ML的工作流和成本与通过SQL实现普通业务逻辑的过程相似。

预测查询和监督模型的第二个不同之处在于其局限性及其对软件体系结构的影响。

1.预测设置的狭窄性。监督学习模型本质上是从A(例如文本)到B(类别)的狭义函数，这意味着如果你有10个不同的问题，你最终会得到10个不同的监督ML模型。预测功能类型的狭窄程度。一种单一的监督方法通常只能服务于一种预测。为此，您通常需要完全独立的系统或产品来实现预测、推荐、智能搜索和模式挖掘。d总共需要10个不同的监督ML模型。

这种综合的狭窄对建筑有负面影响。如果你有10种不同的预测功能，混合了预测、推荐和智能搜索的使用案例：你最终会在一个非常复杂的系统中苦苦挣扎。该系统可以包括具有六个部署模型的单独的监督模型平台、单独的推荐系统、单独的智能搜索产品和单独的模式挖掘工具。这种复杂性很难学习、掌握和维护。智能搜索和基于内容的推荐引擎通常会复制数据库的大部分内容，这会导致冗余。这些系统也可能不能很好地彼此集成，并且它们可能最终处于不一致的状态，其中智能搜索可能会返回旧信息，而推荐和预测可能会忽略新产品和数据。

另一方面，可以争辩说，预测性查询在这两个方面本质上都是多用途和非狭义的。首先：预测性查询没有固定的预测设置，它们不需要为10个不同的问题部署10个单独的模型。这10个问题可能需要10个预测性查询，这是一个明显的优势：虽然创建和维护10个不同的监督ML模型可能很困难，但大多数软件工程项目在创建、理解和维护数十个甚至数百个SQL查询时并不费力。

第二，关于预测类型的狭隘：对于预测数据库来说，多功能性是从这类系统中相当不可避免的设计选择中自然出现的。在某种程度上，它的出现与传统数据库中出现多用途的原因是相同的：数据库不能预先知道查询，因此根据其设计，它必须准备好满足任何通用需求。这推动了总体上的设计选择是通用的，而不是具体的。

作为一种不那么明显但不可避免的设计选择：教科书上的贝叶斯/概率方法最适合快速的统计计算，使预测数据库成为可能。这一点在BayesLite和Bayesian Aito中都很明显。同时，这种坚实的数学基础很容易进一步推广，以创建一个多用途的预测系统，这在这两个系统中都很明显。BayesLite和Aito都提供了广泛的智能功能组合。

在Aito的案例中，贝叶斯数学被推广到不仅服务于预测，还服务于推荐。因为搜索数学是基于贝叶斯二进制独立模型，并且预测数据库需要将所有文本索引到函数：扩展贝叶斯Aito以服务于传统搜索、匹配和个性化搜索用例是很自然的。此外，使用教科书数学来实现可解释的人工智能也非常简单。向需要快速模式挖掘才能正常运行的系统添加模式挖掘支持几乎是不可避免的。另一方面：BayesLite以广泛的分析能力、SQLite的广泛数据库功能和令人印象深刻的数据生成能力补充了Aito的功能组合。

因此，类似地，由于数据库对于已知数据是极其多用途和多功能性的，预测数据库对于未知数据也可以是极其多功能和多功能性的。现在，如果您将传统数据库和预测数据库功能结合起来，您将创建更多用途的系统，它可以灵活地服务于所有知识相关的需求，既包括已知的，也涵盖未知的。

因此，对于单个应用程序：您可能只需要一个预测数据库来满足您的所有需求。您可以从单一来源获取查询、自然语言搜索、预测、推荐、智能搜索等。不需要额外的服务器部署、自定义型号或数据集成，因为所有内容都由单个数据库提供服务。冗余、一致性和互操作性问题也消失了，因为所有功能都基于相同的事务数据。

面向预测查询的体系结构也更符合行业最佳实践。用查询替换预测服务器有助于用无服务器计算中的查询/代码替换基础架构，并将围绕数据(在数据库中)的关注点与查询/代码(在Git中)分开。用单个集成替换多个冗余数据集成符合DRY原则，并且该方法允许重用旧的数据集成。使用现成的解决方案通常比创建自定义解决方案更可取，以避免重复发明轮子，而不是在这里发明反模式。总体而言，该方法减少了维护的代码量、基础设施和复杂性，并且它与良好的旧软件体系结构目标和原则是一致的。

因此，面向预测查询/数据库的方法从根本上背离了传统方法，对该行业具有广泛的影响。就像思考游戏一样：如果您有一个既可以回答已知查询又可以回答未知查询的数据库：为什么要在另一边维护一个单独的普通数据库或部署大量冗余的ML模型/系统呢？

在人工智能的早期，你可以看到人们设想一个像系统一样的预测性数据库。一种设想是麦卡锡的认识论部分，它将机器学习、知识表示和推理无缝地结合在一起。这个认识论部分本质上是一个世界的模型，它将被用来查询已知和未知，就像一个预测性数据库一样。尽管如此，这一愿景从未完全实现，原因相当明显：创建一个基于查询的统计推理系统在算法和性能方面都极具挑战性。

最根本的问题是，预测总是需要一个模型，但如果你事先不知道预测的细节，你就只剩下3个相当有挑战性的选择：

“世界模型”，您可以在其中创建一个可以服务于任意查询的通用模型。这里的问题是，通常很难创建一个通用的ML模型来服务于任意预测，如果您不想降低编写/准备性能，就更难了。2.“特殊模型”，即您在现场为每个查询训练一个单独的监督模型。这里的挑战在于，在不降低查询延迟和吞吐量的情况下，创建高质量的模型查询时间是极其困难的。

第三个也是直观上最合理的选择是将这两种方法结合起来，因为这不仅应该提供最好的结果，而且还可以折衷最佳的写入和查询速度。在负面方面，它也结合了前面两种方法的挑战。

BayesLite是“世界模型”方法的一个很好的例子。它在额外的“创建群体”、“创建分析”和“分析”步骤中创建内存中的通用模型。虽然这种方法很优雅，但即使使用有限的数据集，建模步骤也可能需要10分钟以上的时间，这很好地说明了写入/准备时间方面的牺牲。不过，通过使用更专用的数据库(BayesLite基于SQLite)和不同的算法(查询时间表示学习可以像Aito一样加速到毫秒级，这意味着快速写时准备也是可能的)，准备速度可能会大幅提高。

另一方面，Aito使用“特别模型”方法，在这种方法中，性能影响发生在查询时。接下来，我将重点介绍我们如何使用此方法解决一些固有的性能挑战。

本质上，为特定查询创建“特别模型”通常需要1)几百个查询特定特征的温暖和快速的数据结构，2)几千个相关的统计测量和3)每个感兴趣的特征/检查的几千个相关样本。为了满足毫秒级的这些需求，AITO 1)为每个可能的特征快速准备了数据结构，2)使用专门的索引来计数微秒级的全部数据库统计数据，以及3)具有专门的数据结构以实现亚毫秒级的数据采样。

因此：预测性查询通常可以以毫秒为单位提供服务，如图1所示。您可以在此笔记本中找到有关基准测试的更多信息。

虽然大多数预测都能以低延迟提供服务：因为Aito当前使用完整的数据库统计数据，所以Aito的伸缩性有一个O(N)分量。这意味着一旦您开始接近百万个数据点：性能就会下降。此外，查询中的已知特征数量和预测类别中的备选数量也会影响图中可见的性能。

目前，这些性能特征对Aito的可能用途施加了一定的限制，因为大数据集和复杂的推理可能会影响延迟和吞吐量。然而，值得注意的是，对于基准SVM实现，受监督的机器学习性能和资源需求通常在百万样本规模或例如10k样本规模中开始下降。AITO查询性能对于数据集有限、延迟和吞吐量要求更宽松的应用程序来说也足够好了，就像在公司内部工具、POCS/MVP、后台进程、智能流程自动化和RPA中一样。

虽然性能质量足以满足许多用途，但我们确实希望它在未来会从根本上更好。使用更专业的数据库结构进行的早期实验表明，写入速度和采样速度仍然可以提高10-50倍。这可以使预测数据库具有a)与搜索数据库相当(或更好)的写入性能，b)更好的缩放，因为基于采样的推理缩放比O(N)类缩放更多O(1)，以及c)极大地提高了预测速度。将来，通过进行写时特征/表示学习来集成“世界模型”方法可以使预测速度更接近我们在传统监督学习中看到的速度，以换取写性能的一些下降。

最后，但并非最不重要的一点是：让我们考虑一下预测质量。在这个基准测试中，我们比较了Aito和7个ML模型，包括4个具有离散数据的不同分类数据集上的随机森林(Aito不做回归)。

就像我们在基准测试中看到的那样，尽管训练预测模型的预算只有几毫秒，但特别模型方法产生了非常好的预测质量。

在毫秒尺度上创建一个好的特别模型是可行的，因为创建服务于特定预测的特定模型比创建服务于通用预测的通用模型要快得多。如前所述，训练阶段不需要考虑可用的每百万个特征和百万个样本，只需要考虑与查询相关的几百个特征和几千个样本。降低了复杂性，加上专门的数据库，可以即时提供中等复杂的特定查询模型。

特别模型也可能出人意料地好，因为模型针对单个预测进行了微调。传统的监督模型可能会丢弃稀有特征，忽略数据中的稀有模式，以限制模型的复杂性，当预测必须基于稀有特征时，这就成为一个问题。有了预测性查询，问题就简单地消失了，因为查询时间训练允许选择最适合的要素和模型细节。

.