Google Cloud 为 AlloyDB 装上代理模型：数据库本地跑 AI 判断，最快提速 2.3 万倍

AlloyDB 是什么，把 AI 塞进数据库又意味着什么

要看懂这次更新的分量，得先弄清两件事：AlloyDB 是个什么东西，以及「把 Gemini 装进去」到底改变了什么。

AlloyDB 是谷歌云上的一款关系型数据库，兼容 PostgreSQL（世界上最流行的开源数据库之一，可以理解成 PostgreSQL 的谷歌云增强版）。企业用它存订单、用户、商品评论、系统日志这些业务数据，靠 SQL 语句来查。

传统数据库有个天生的局限：它只会按字面精确匹配。你能轻松查「价格低于 100 的商品」「状态是已完成的订单」，却没法直接查「差评里抱怨电池的」「语气愤怒的工单」，因为这要理解文字的意思，而数据库不懂意思。以前想做这种「按意思」的分析，只能把数据导出去、送进一套单独的 AI 管线跑一遍、再把结果导回来，既慢又得自己维护那套管线。

这次 AlloyDB 做的事，是把 Gemini 的理解能力直接做成一批 SQL 函数（就叫 AI 函数），嵌进数据库本身。于是你能在一句普通 SQL 里写下对「意思」的判断，数据库自己就懂，把符合的行挑出来，数据一步都不用搬出去。

这就是这次的意义：数据库从「只会按字面精确匹配」，升级成「能按意思查询」，而且语义搜索、结构化查询、AI 判断全在同一层 SQL 里完成。能力很强，但也带来一个新麻烦：每行都调一次大模型，行数一多就又慢又贵。所以这次发布真正的重头戏，不是这些函数本身，而是怎么让它们既强、又快、又便宜。

这次具体多了哪些 AI 函数

先看这套 AI 函数能干什么。最直观的一个用法：把又乱又难解析的原始文本，直接在 SQL 里变成结构化、可搜索的内容。

比如用 ai.generate 把一条报错日志自动拆成结构化字段：

一条乱糟糟的日志，被自动拆成错误码、服务名、根本原因三个字段，直接能查能筛。这次新增了三个函数：

• ai.analyze_sentiment：判断一段文字的情绪是正面、负面还是中性。
• ai.summarize：把长文压成摘要，保留原文的语气和分寸。
• ai.agg_summarize：聚合函数，把一组多行内容（配合 GROUP BY）合成一段统一摘要。

加上此前已经正式可用的 ai.generate、ai.rank、ai.if、ai.forecast，就是这套 AI 函数的全家福。比如 ai.agg_summarize 能把一个商品下的一堆评论合成一句总评：「多名用户称赞 4K 画质、120Hz 帧率和符合人体工学的手柄；也有人抱怨长时间游戏时风扇噪音偏大。整体是一款顶级主机，发热和噪音只是小瑕疵。」

以前为什么又慢又贵

把大模型的判断力用到整张表上，最直接的办法是给每一行都调一次大模型。行数一多，这个办法就撑不住了。

InfoQ 把问题说得很具体：一张有 10 万件商品的表，做一次全表判断，就是 10 万次发往 Vertex AI 的网络往返。每一次都带着同一份系统提示词，每一次都要等模型推理，每一次都按 token 计费。

数字来自谷歌今年 5 月的技术博客。结论很直白：对操作型数据库来说，这个速度太慢了；对分析场景来说，这个成本高到很多全表语义分析根本做不起。

谷歌用两招来破这堵墙。先给一张全景图，看清它们和逐行调用的关系：越往右，越少碰云端大模型，越快越省：

下面把这两招分别拆开看。

第一招：把很多行打包成一次调用

智能批处理（Smart Batching）的思路很朴素：既然每次都带同一份系统提示词，那就把很多行合并成一次请求，让这份提示词只发一遍。

为什么不在自己的应用层做批处理？因为批大小很难拿捏：估小了，省不下多少成本和延迟；估大了，塞进去的提示词膨胀，可能引发幻觉、或者超过模型的 token 上限。AlloyDB 会自动算出每次请求的最优批大小，还自动处理重试。

它还能理解数值约束，不只是找语义相近的。举个例子：用户在数码商城找一台「能潜到 60 米或更深」的相机。普通的混合搜索只会按语义和关键词找最接近的，抓不住数值硬约束，可能推给你一台只能到 20 米的。用 ai.if 做智能过滤，数据库真的理解「深度」这个约束，只返回满足或超过 60 米的产品。用 ai.if 时你也不用自己指定批大小，AlloyDB 在底层把优化都做了。

第二招：数据库自己训练一个替身模型来判断

批处理省的是重复开销；代理模型（proxy model）走得更远：让数据库自己训练一个能在本地跑的小模型，把大部分判断接管过来，连大模型都不用再问了。

代理模型是个专门为某个具体问题和具体数据训练出来的迷你模型，只用来快速回答「是 / 否」这类判断题，遇到判断不了的题，会自动转给大模型处理。

整个流程分两阶段：先训练，再执行

它靠两条 SQL 语句分工：PREPARE 负责在后台把模型训练好，EXECUTE 负责用训练好的模型跑线上查询。

训练发生在后台的 PREPARE 阶段，这一步的大模型开销是一次性的；线上 EXECUTE 阶段就直接用训练好的本地模型判断。只有当模型置信度低、或找不到对应模型时，才自动退回去调大模型兜底。这也是官方给出的一组两阶段 SQL 示例：

-- 第一阶段：用数据样本 + 云端大模型，训练本地代理模型
PREPARE underwater_suitability_proxy FROM
SELECT description FROM products;

-- 第二阶段：用本地代理模型，以数据库速度执行查询
SELECT * FROM products
WHERE ai.if(description, 'suitable for underwater use deeper than 60 meters')
USING proxy(underwater_suitability_proxy);

第二段里那句英文判断条件 suitable for underwater use deeper than 60 meters，意思就是「能用于 60 米以下的水下」，也就是前面那台潜水相机要过的判断。

InfoQ 把这个模式概括为数据库和大模型关系的一次反转：以前数据库是客户端，每做一个判断都要调用一次外部模型；现在数据库更像个学生，先在一批样本上学会模型怎么判断，再以数据库的速度在本地应用。大模型的角色，从每次查询都要依赖的运行时，变成了只在训练时出场的老师。

这个替身模型凭什么能懂语义

一个逻辑回归这么简单的模型，凭什么能读懂「情节有趣」这种语义？关键在于它吃进去的不是原始文字，而是已经带着语义信息的向量嵌入。

把这两件事接起来：Gemini、Gecko 这类嵌入模型，在生成向量时就把「有趣情节」「摄影出色」「乏味」「无聊」这些语义概念，编码进了向量的不同维度组合里（别指望有单独一维就叫「摄影」）。训练逻辑回归，相当于在这些嵌入构成的（超）球面上切一个平面，把语义分成两半：一边判 TRUE，一边判 FALSE。平面往哪个方向切，取决于训练时大模型给样本打的标签。

这也是谷歌博客里的招牌示意图，绿色平面切开蓝色的嵌入球面：

代理模型（绿色平面）通过切开嵌入空间（蓝色球面）来隔出与任务相关的语义。图：Google Cloud

由此，超低的延迟和成本就好理解了：嵌入只生成一次，之后的查询反复复用，把语义带进数据的这笔开销被摊薄成了一次性支出；而逻辑回归本身跑在普通 CPU 上，不需要专用硬件。

准不准？什么情况会失灵

代理模型是一种近似方法，能力比大模型更受限。它在能靠嵌入语义模式判断的问题上表现好，遇到复杂推理或样本极端不均衡就不适用。

先看准不准。SIGMOD 2026 论文在 10 个基准测试上比对，代理模型的 F1 是大模型 F1 的 90% 到 102%；在亚马逊评论情感分类测试里，代理模型 F1 达到 0.860，反超大模型的 0.739，也就是 116%。论文给的解释是：代理模型是在一批样本上训练出来的，见过全局；而大模型是把每一行都当成一道新题从头判断。

F1 分数取值 0 到 1，同时衡量「判得准不准」和「该找的有没有找全」，越接近 1 越好。下面是论文里公开的几个具体测试：

再看什么时候会失灵，主要是两类场景：

还有一点容易混：代理模型不等于向量搜索。它是个分类器，给每一行判 TRUE / FALSE（或归到某个类别）；向量搜索做的是另一回事，它按通用的距离函数（比如余弦距离）把结果排个先后。而且代理模型是针对你的具体数据和具体问题训练出来的，就算只想用向量搜索去模拟 ai.if，也很难搭好、效果打折。两者不是一码事。

数据规模越大，优势越明显

代理模型的省钱省时优势不是固定的：数据量越大，优势越明显。因为训练是一次性的，这笔开销会被摊到之后每一次查询上，查得越多，越划算。

论文给出的在线训练场景（BigQuery）数据是这样的：

规模从百万行涨到千万行，成本降幅和延迟提速都跟着放大。放到 AlloyDB 这边，逻辑还要更有利一层：PREPARE 阶段的大模型成本，可以摊到之后任意多次查询执行上，预先备好的模型跑得越多，单次成本越低。下图来自 SIGMOD 2026 论文，横轴是表的规模，成本降幅和延迟提速随规模一路上扬，到千万行时逼近约 600 倍成本、约 300 倍延迟：

成本降幅（token 消耗）与延迟提速（查询加速）随表规模增大而增长，到 1000 万行时约为 600 倍成本 / 300 倍延迟。图：Google Cloud / SIGMOD 2026 论文

现在能用到什么程度，对其他数据库意味着什么

这套能力现在能用到什么份上，得分清哪些已经正式可用、哪些还在预览。

要用代理模型，得手动打开一个数据库开关（google_ml_integration.enable_ai_function_acceleration），它默认是关的。InfoQ 也提醒：23,000 倍、6,000 倍这些是内部测试数字，只对预览中的 ai.if 成立，不代表所有 AI 函数的普遍表现，上生产前应该拿自己的数据分布和查询模式实测。

实践者怎么用它

Starburst 架构师 Raimundas Juodvalkis 在 LinkedIn 上给了一句定位：把它们当作「受治理的数据库扩展」，不是「魔法 WHERE 子句」。他的三条建议是：

• 先从读密集型的评论分析场景起步，别一上来就用它做重活。
• 把模型衍生出的字段写回核心系统之前要谨慎。
• 模型成本要和查询成本分开追踪。

对其他数据库意味着什么

InfoQ 指出，任何为每行判断都去调外部模型的数据库，都撞在同样的成本和延迟墙上。Aurora、Azure SQL、CockroachDB、PlanetScale 这些竞品会不会跟进类似的「查询时蒸馏」方案，还是继续让用户自己在应用层搭这套优化，目前还不确定。

这次发布里，AlloyDB 还配了托管 MCP 服务器，让 AI 智能体通过 Model Context Protocol（一种让 AI 直接调用外部工具和数据的开放协议）查询数据库内容，不用自己搭 MCP 基础设施；再加上已有的 ScaNN 向量索引（最高支持 100 亿向量）。InfoQ 认为，AlloyDB 是在把自己定位成一个让结构化查询、语义搜索和 AI 判断共存于同一层 SQL 里的 PostgreSQL 兼容数据库。