Google Cloud通过代理模型实现LLM驱动的SQL查询加速和成本降低

使用代理模型实现超快且经济的基于LLM的SQL查询

原文链接：https://cloud.google.com/blog/products/data-analytics/more-than-100x-faster-and-cheaper-llm-powered-sql-queries-with-proxy-models/

发布日期：2026-05-13

数据库引入了新的AI驱动的SQL函数，这些函数接受自然语言指令作为输入，并使用LLM进行评估。它们利用LLM的强大功能来回答新的查询类型：哪些产品评论关于耐用性是负面的？哪些客户支持工单是通过提供变通方案解决的？

这些新的AI功能通过将LLM的语义理解能力带到您的数据中，从而推动SQL查询引擎的可能性边界，使以前不可能的分析和应用成为可能。但是，它们的成本和性能限制了其适用范围。每次LLM调用都会将整体查询延迟增加10-100倍，成本则增加约1000倍。这对运营数据库来说太慢了。在分析中，对包含10-100百万行的数据进行中等大小的查询，对于某些应用程序来说，生成的令牌数量可能是过于昂贵的。

Google Cloud 发布了一篇新论文 SIGMOD 26，展示了如何通过使用代理模型加速并降低基于LLM的AI函数的成本。代理模型是针对特定查询（即提示）进行了成本优化的超轻量级模型，并针对您的数据进行了调整。在查询执行过程中，它们可以替代大多数LLM调用（因此称为代理模型），并且可以在查询执行时或提前进行训练。代理模型背后的基本思想在 NeurIPS 2024 的 Universal Query Engine (UQE) 中由 Google DeepMind 提出。

我们的论文表明，在许多情况下（但并非所有情况），代理模型都能非常准确地工作，有时甚至没有质量损失，有时则有轻微的质量损失，偶尔还能提高质量。BigQuery 和 AlloyDB 已经在 AI.IF （BigQuery 文档 和 AlloyDB 文档）和 AI.CLASSIFY （BigQuery 文档）的优化模式下实现了这一优化。本文是对 SIGMOD 论文的简要概述，提供了关于三个问题的关键直觉：

• 为什么代理模型能够在超低延迟和成本的情况下如此准确地工作？
• 它们是如何工作的？
• 在哪些应用场景中它们能提供准确的答案？在哪些情况下它们会失败，需要依赖LLM。

为什么代理模型能在超低延迟和成本下准确工作？

超轻量级的代理模型，例如目前在 BigQuery 和 AlloyDB 中使用的逻辑回归模型，是如何拥有与LLM相当的语义理解能力，从而实现准确的问题回答呢？关键在于这些代理模型输入了丰富的数据嵌入。默认情况下，我们使用 Gemini 嵌入生成器，当生成嵌入时，它会将语义带到您的数据中。

然后，超低延迟和低成本就变得显而易见了：由于嵌入只生成一次但可以多次使用，将语义带到数据中的成本被摊薄；现在只需生成一次，而不是每次查询都生成。此外，代理模型在CPU上运行得非常快——无需专用硬件。

我们希望您对代理模型为何有效有了很好的理解。但也需要注意一点：代理模型本质上是一种近似技术，其能力有限，不如LLM。代理模型在某些提示上表现良好，但在其他提示上可能不如LLM。例如，SIGMOD 26论文显示，在10个基准测试中，代理/LLM预测性能（以F1衡量）的比例范围从90%到116%。他们可能会在需要推理连接多个语义概念的问题上失效。相反，应将其视为专门化模型以适应您的查询和数据。

好消息是，查询处理器会自动检查通过代理模型实现AI函数的有效性和可行性。让我们看看它是如何做到的。

代理模型是如何工作的？

我们来看一个简单的语义过滤器（AI.IF）示例。我们的电影品味非常独特：我们喜欢有引人入胜的情节和出色的摄影的电影。下面的查询处理IMDb评论以找到这样的电影。

SELECT movie_id, review, review_embedded
FROM imdb.reviews
WHERE AI.IF(review_embedded, 'interesting_plot', 'not_interesting') = TRUE;

其中，review 列包含评论的自由文本内容，review_embedded 列包含 Gemini 嵌入。当您在 BigQuery 中运行此查询时，查询引擎会：

1. 对于第一个 AI.IF，创建一个包含输入关系大约一千行的训练样本集，即 imdb.reviews 表。
2. 使用LLM对第一个样本集进行标记，将每个评论标记为 TRUE（情节有趣）或 FALSE（情节不有趣）。
3. 使用上一步计算的标签训练第一个 AI.IF 的代理模型。
4. 创建第一个 AI.IF 的测试样本集，并在该测试集上评估代理模型的质量。
5. 根据评估结果，优化器会自适应地决定是使用代理模型进行推理还是回退到使用LLM进行推理。
6. 重复上述步骤以处理第二个 AI.IF。

在 BigQuery 中，所有步骤都在查询执行期间实时完成。AlloyDB 是一个针对亚秒级延迟的操作型数据库，因此避免了在线代理模型训练和在线评估的过程。相反，在 PREPARE 语句中会提前计算查询的代理模型，从而将采样、标注和训练的成本移出关键的查询路径。这使得可以在线下创建大量的 PREPARE 语句，而应用程序则选择合适的 PREPARE 语句并在在线路径中执行它。

让我们退一步看看第三步究竟发生了什么。代理模型使用每个评论嵌入的维度（来自 review_embedded）作为其特征。现代密集嵌入模型如 Gecko 或 Gemini 捕捉了大量的语义概念。在我们的电影评论示例中，从高层次抽象来看，相关的概念可能包括：“美学”，“引人深思的情节”，“平淡无奇的情节”，或者可能是“无聊的电影”。我们强调“高层次的抽象”，因为在基础模型的二进制“语言”中，所有这些概念（以及更多）都分布在密集嵌入的空间中。不要期望直接找到与摄影相关的维度。重要的是，嵌入空间包含了许多对我们任务无关的概念。代理模型的训练本质上是对高度相关概念给予重要权重，并丢弃无关概念。

代理模型（绿色平面）通过切割嵌入空间（蓝色球体）来隔离相关的语义概念

现在，让我们详细了解一下当前版本使用的特定代理模型：逻辑回归。为了可视化发生的情况，可以将嵌入视为单位向量形成的（超）球体。对于二元分类任务，代理模型实际上将球体切成两半。在我们的示例中，“美学”和“引人深思的情节”会落在一个平面上的一侧，而“平淡无奇的情节”和“无聊的电影”则会落在另一侧。从概念上讲，平面的方向决定了哪些语义概念更为相关。

重要的是，代理模型是根据您的数据和问题进行调整的：代理模型的训练使用高质量的LLM对您的数据样本进行标注，以回答特定的问题。

**重新审视代理模型何时有效**

我们现在可以更清楚地看到代理模型有效与无效的区别：代理模型适用于可以通过检测嵌入空间中的语义概念来决定提示的任务。但对于需要超出检测嵌入模型模式的复杂提示，它们将会失败。

好消息是，在实践中，我们观察到代理模型在大量 AI+SQL 查询中都能很好地工作。SIGMOD26论文提供了全面的评估，显示代理模型在11个基准测试中均有效。具体来说，在10个基准测试中，代理模型的F1值与LLM的F1值之比范围从90%到102%，而在第11个基准测试（亚马逊评论）中，这一比例为116%。请注意，代理模型甚至可能提供更好的准确性，因为它可以从多个样本中受益，而LLM则需要为每一行单独解决问题。

目前还存在第二个限制：极端的选择性。注意第一步收集样本。它需要收集许多TRUE的例子和许多FALSE的例子。即使TRUE的数量远多于FALSE或反之亦然，也采用了多种复杂的技巧来实现这一点。然而，没有任何纯粹基于采样的技术能够应对极端的选择性情况，即TRUE或FALSE数量非常少的情况。这就是为什么在极端选择性情况下不会使用代理模型的原因。但是，请注意，这个问题可以通过各种技术从根本上解决。

**为什么向量搜索不够？**

代理模型看起来……似乎与向量搜索非常接近。毕竟，它们也输入向量嵌入。为什么不直接使用向量搜索呢？有两个原因使向量搜索不够用：最明显的一个原因是代理模型不是排名器；它们是分类器：多类分类器（AI.CLASSIFY）或二元分类器（AI.IF）。但即使你只考虑AI.IF，试图用向量搜索模拟AI.IF也会既难以设置又会产生次优结果。虽然代理模型是针对您的数据和提示量身定制的，但向量搜索基于通用的距离函数（例如余弦距离）。

**实验结果**

这里我们展示 SIGMOD26论文 中的一部分具有代表性的基准测试。我们将代理模型的准确性与在所有行上使用LLM推理进行比较。在质量方面，相对准确性范围从0.92（最低）到1.16（最高），这意味着在某些任务中，代理模型的表现略优于直接的LLM推理。

数据集|提示|代理模型F1|LLM模型F1|相对F1（代理模型/LLM模型） ---|---|---|---|--- 亚马逊评论|10k 条评论的情感标签|0.860|0.739|1.163 银行业务77|意图是否为{意图标签}？思考步骤：{推理指令}|0.700|0.707|0.990 加利福尼亚住房|纬度和经度属于南加州|0.953|0.953|1.0 FEVER|声明是否由文本支持|0.782|0.853|0.917

从可扩展性和成本角度来看，BigQuery 和 AlloyDB 的架构差异导致了各自系统略有不同的结果。总体而言，代理模型将大型语言模型推理服务使用的专用硬件部分计算转移到普通数据库工作者上。这带来了成本大幅降低和查询延迟的显著减少。在 BigQuery 中采用在线训练的情况下，对于典型的百万行查询，代理模型消耗的令牌大约少 400 倍，查询延迟降低了 30 到 100 倍。而在 AlloyDB 中，准备语句的 LLM 成本与 BigQuery 类似，可以通过任意多次运行这些准备语句来摊销。

不同表大小下的成本降低（令牌消耗）和延迟改善（查询加速）情况。

结论

调用 LLM 的 AI 函数正在成为数据库中的常见现象。选择适合每个 AI 函数的适当模型是学术研究的一个活跃领域（例如 BARGAIN）。关键在于模型的适配：对于“简单”的问题使用性能好且成本低的模型，而对于复杂的问题则使用强大的推理模型。我们的工作正是基于这一原则，但学术研究仅限于利用 LLM 在性能谱系中导航，而非 LLM 的代理模型则通过使用超轻量级且高度专业化的模型，大大提升了性能，这些模型在许多问题上提供了令人惊讶的质量。然而，我们不应感到意外：毕竟，代理模型依赖于基础模型为嵌入带来的丰富语义，并且也依赖于 LLM 进行训练。随着嵌入模型的改进，能够从文本和多模态数据（图像、视频）中提取越来越丰富的语义，我们怀疑非线性分类器将有助于识别更复杂的语义模式，进一步扩大代理模型的应用范围（例如应用于 AI 连接），并探索性能/质量帕累托曲线上的更多点。

如果您想了解更多，请参阅我们的完整论文，该论文深入探讨了在线训练与离线训练之间的差异，并比较了不同嵌入模型以及各种代理模型（线性回归、SVM、XGB）的性能。

今天您可以在 BigQuery（文档）和 AlloyDB（文档）中尝试代理模型，显著加快您的 SQL 查询的 AI 函数并减少其令牌消耗。

• * *

我们衷心感谢来自 Google DeepMind 的 Bo Dai、Yuchen Zhuang、Xingchen Wan 和 Dale Schuurmans 在 UQE 中开发代理模型的基本原理，并在整个旅程中为我们提供持续的指导和支持，使这些模型能够服务于云客户。我们也感谢 Yeounoh Chung 和 Fatma Özcan，他们是我们在系统研究组的合作伙伴，以及 AlloyDB 和 BigQuery 工程团队。

发布于

• 数据可视化
• 人工智能与机器学习
• 数据库