BigQuery AI.AGG 深度解析：当 GROUP BY 开始调用 Gemini

传统 SQL 聚合有一个不容商量的规矩：输入可以是几千万行，输出必须是确定的。COUNT 不会临场发挥，SUM 不会因为提示词写得漂亮就多算两块钱。

Google 现在把一个概率模型塞进了这个位置。

AI.AGG 看起来像普通聚合函数：它可以跟在 GROUP BY 后面，对一组文本或图片执行分析，每组返回一个 STRING。但它实际做的事情，是把数据分批交给 Vertex AI 上的 Gemini，再对批次结果继续聚合，直到压成一个自然语言结论。数据库不再只回答“有多少”，而是开始回答“这些记录共同说明了什么”。

这比给 BigQuery 增加一个 LLM 调用入口更重要。它改变的是分析链路的边界：过去需要导出数据、切分上下文、编排多轮模型调用、合并结果的工作，现在可以被压进一条 SQL。不过，能写成一条 SQL，并不等于它突然拥有了 SUM 那样的确定性、成本模型和可审计性。

AI.AGG 解决的不是生成，而是压缩

BigQuery 原来已经提供 AI.GENERATE 和 AI.GENERATE_TEXT。它们适合逐行任务：给每条评论分类、为每条工单生成摘要、识别每张图片里的对象。输入有多少行，通常就会产生多少份模型结果。

这种模式一旦遇到全局问题，很快就会变得别扭。

假设数据表里有 5 万条商品评论，我们要知道某个产品最常见的优点、缺点，以及用户对价格和质量的整体态度。逐行生成只能先得到 5 万份局部判断。开发者仍然要自己处理三个问题：如何把数据切进模型上下文、如何合并批次结论、如何避免中间输出再次超过上下文窗口。

AI.AGG 针对的正是这层归约工作。Google 官方文档明确说明，它会自动执行多级聚合：先批处理原始数据，再聚合各批次的结果。因此，待分析的数据可以超过单次 Gemini 的标准上下文窗口，而开发者不必自己实现树状摘要或 MapReduce 式归并。

从这个角度看，它更像一个由 LLM 驱动的 REDUCE，而不是一个更方便的文本生成函数。

三类函数的语义差异可以这样理解：

真正的变化不在“SQL 会写文字”，而在于数据库开始原生承接以前属于应用层的上下文编排。

一条 SQL 背后发生了什么

AI.AGG 的语法并不复杂：

AI.AGG(
  [ DISTINCT ] INPUT,
  INSTRUCTION
  [, connection_id => 'CONNECTION']
  [, endpoint => 'ENDPOINT']
)

INPUT 可以是字符串，也可以是由字符串、Cloud Storage 对象引用及其数组组成的 STRUCT。对象引用由 OBJ.GET_ACCESS_URL 生成，因此同一套聚合逻辑既能处理评论和日志，也能处理图片或文档。

INSTRUCTION 是聚合提示词；connection_id 决定 BigQuery 如何连接 Vertex AI 与 Cloud Storage；endpoint 用来选择 Gemini 模型。如果不显式指定连接，系统会使用最终用户凭证；如果不指定端点，BigQuery 会代为选择模型。

最简单的评论分析大致如下：

SELECT
  product_id,
  AI.AGG(
    review,
    '''
    Summarize the overall sentiment for this product.
    List the top three positive themes and top three complaints.
    Separate observations about price, quality, and usability.
    '''
  ) AS review_summary
FROM `analytics.product_reviews`
WHERE review IS NOT NULL
GROUP BY product_id;

表面上，这和 STRING_AGG 没有太大区别。执行语义却完全不同。

可以把内部过程理解成一棵归约树：

1. BigQuery 根据分组收集输入行；
2. 系统将大组拆成多个可推理批次；
3. Gemini 分别生成批次级结论；
4. 中间结论再次被批处理与聚合；
5. 每个输入组最终返回一个字符串。

这也是它能绕过单次上下文限制的原因。但这里的“绕过”不是免费扩容。官方文档特别提醒：因为多级批处理和汇总会重复向 Gemini 发送中间结果，实际发送给模型的 Token 总数会高于源数据本身的 Token 数。

也就是说，AI.AGG 消除了手写编排代码，却没有消除编排成本，只是把它藏进了查询执行计划。

它最适合哪四类任务

Medium 原文列出了评论、图片、日志和 Agent 审计四类场景。对开发者来说，更有用的判断标准不是数据属于哪个业务，而是问题是否同时满足两个条件：答案需要跨越大量记录，并且答案无法被确定性聚合表达。

评论与工单：从计数变成主题

传统 SQL 可以统计一星评论数量，也可以按关键词计算出现频率，却很难识别“用户认为价格合理，但对安装过程普遍不满”这种跨句、跨记录的组合判断。

AI.AGG 可以按产品、版本或渠道分组，把大量自然语言反馈压成主题、情绪与例证。它适合做探索性归纳，但不该取代原始指标。更稳妥的查询应同时保留评论数、评分均值和差评比例，让自然语言结论旁边始终有确定性数据作为锚点。

日志分析：找行为模式，不是查故障码

应用日志里最有价值的问题，未必是“错误码 500 出现了多少次”，而可能是“用户退出前最常做的几个动作是什么”。前者应该交给 COUNTIF 和时间序列，后者需要跨多条事件重建行为模式。

这类分析适合 AI.AGG，前提是先在 SQL 层完成过滤、会话化和字段裁剪。如果直接把整张日志表交给模型，不仅费用难以控制，噪声也会吞掉真正的行为信号。

多模态数据：让对象表参与聚合

通过 BigQuery 对象表和 OBJ.GET_ACCESS_URL，输入可以引用 Cloud Storage 中的图片。官方示例会让 Gemini 汇总一批商品图的主要类别；类似方法也能回答相机数据中常见动物、用户图片中高频品牌等问题。

官方文档同时列出了硬边界：单行包含 10 张或更多图片时，该行可能被跳过；单行超过 10 MiB 可能触发内部错误；部分通过 OBJ.GET_ACCESS_URL 创建的图片对象也可能无法处理。多模态支持已经进入 SQL，但离“把整个图片桶扔进去就完事”还有距离。

Agent 运行审计：把交互日志变成改进方向

如果 Agent 平台记录了任务类型、工具调用、人工介入与完成结果，AI.AGG 可以按 Agent 版本或任务类型聚合，回答哪些任务完成最快、哪些步骤最常需要用户接管、失败前出现了什么共同模式。

这比单纯计算成功率多了一层解释，但也有一个风险：模型很容易把相关性写成因果关系。因此，AI 结论应该用来生成调查假设，而不是直接触发模型回滚或生产配置变更。

20 万行能跑，不代表应该直接跑

Google 给出的推荐上限很宽：单次查询不超过 2000 万行，不同分组不超过 1000 个；超过这些范围的查询可能超时。每组输出还有 10000 Token 的上限。

这些数字说明系统追求的是仓库级聚合，而不是在客户端拼几段文本。但它们不是成本承诺，也不是结果质量保证。

官方成本建议非常值得重视：复杂查询如果包含 JOIN 或 ORDER BY ... LIMIT，真正被模型处理的行数可能和开发者预期不同。要严格控制推理规模，应先将数据写入一张单独的物化表，再在该表上调用 Gemini。

我会把生产查询拆成两步：

CREATE OR REPLACE TABLE `analytics.ai_agg_input` AS
SELECT
  product_id,
  review
FROM `raw.product_reviews`
WHERE created_at >= DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)
  AND review IS NOT NULL
QUALIFY ROW_NUMBER() OVER (
  PARTITION BY product_id
  ORDER BY created_at DESC
) <= 5000;

然后才执行推理：

SELECT
  product_id,
  COUNT(*) AS sampled_reviews,
  AI.AGG(
    review,
    'Summarize recurring themes. Do not infer facts absent from the reviews.'
  ) AS summary
FROM `analytics.ai_agg_input`
GROUP BY product_id;

这样至少可以在调用前回答：有多少行、多少组、采样规则是什么。再配合 AI.COUNT_TOKENS 估算文本输入，成本才不至于完全变成黑箱。

“聚合函数”这个名字最容易让人误判

AI.AGG 的外形会诱导开发者把它当成 SUM、AVG 的自然语言版本。但两者有三个根本差异。

第一，结果不保证稳定。模型、端点、提示词和批次路径都可能影响最终措辞，甚至影响主题排序。如果结果参与报表，应保存提示词、模型端点、查询版本和生成时间，而不是每次打开页面都现场重算。

第二，失败语义不是全有或全无。官方文档写得很清楚：部分 Vertex AI 调用失败时，函数可能返回部分结果；只有全部调用失败或所有输入行无效时才返回 NULL。这意味着“返回了字符串”不等于“完整处理了全部输入”。目前的输出又只是一个字符串，没有逐批状态表可供审计。

第三，它不适合承担精确计算。订单金额、风险阈值、SLA、用户计数都应继续由确定性 SQL 完成。AI.AGG 更适合回答开放问题，或者为人工分析提供候选结论。

一个实用边界是：凡是答错后会自动扣钱、封号、报警或改配置的场景，都不要让 AI.AGG 单独做最终裁决。

上生产之前，我会补上四层护栏

固定输入集

先物化、再推理。将过滤、采样、去重和权限控制留在普通 SQL 阶段，使每次 AI 查询都能追溯到明确的数据快照。

固定输出契约

虽然函数只返回字符串，提示词仍可以要求稳定格式，例如 JSON。不过模型生成的 JSON 必须经过 SAFE.PARSE_JSON 或应用层 Schema 校验，解析失败要进入错误队列，不能静默吞掉。

AI.AGG(
  TO_JSON_STRING(STRUCT(review_id, rating, review)),
  '''
  Return valid JSON with keys:
  overall_sentiment, positive_themes, negative_themes, uncertainties.
  Do not include markdown fences.
  '''
)

建立小型评估集

从真实数据中挑出一批覆盖正常、长尾、冲突和脏数据的固定样本，为人工基准答案或验收标准。提示词、模型或数据预处理变更后，先跑这批样本，再决定是否扩大范围。

把结论和证据分开保存

自然语言摘要应与原始数据快照、确定性指标、查询文本、模型端点和生成时间一起保存。模型说“价格投诉最多”时，分析者必须能够回到对应评论与统计分布，而不是只能相信一段流畅文字。

现在还不该忽略的限制

Google 官方页面目前仍将 AI.AGG 标记为 Preview，适用 Pre-GA 条款，并提示支持可能有限。这一点与 Medium 原文所称的“已正式可用”存在冲突。对准备采用它的团队来说，应该以当前官方文档和所在项目实际可见能力为准，而不是根据二手文章判断发布阶段。

此外，端点并非完全自由：只能使用不要求 thinking budget 的 Gemini 模型；Gemini 3 的 Agent Platform 不支持区域端点，需要使用 global、us 或 eu。跨区域选择还可能影响数据治理与合规评估。

已知问题还包括：部分图片对象可能处理失败、Workforce Identity Federation 的长查询可能意外失败，以及某些 DISTINCT 聚合组合会触发内部错误。这些都说明它现在更适合受控试验与辅助分析，而不是直接替换成熟的数据产品链路。

数据仓库正在变成推理运行时

AI.AGG 最值得关注的地方，不是 Google 又给 BigQuery 加了一个 AI 函数。真正的信号是：数据不再需要先离开仓库，才能进入模型归纳流程。权限、过滤、分组和推理开始出现在同一份 SQL 里。

这会减少一批应用层胶水代码，也会把新的责任推回数据工程：Token 成本如何估算，概率输出如何版本化，部分结果如何识别，提示词如何审计，模型升级是否改变历史报表。

过去我们相信聚合函数，是因为同样的输入必然得到同样的答案。现在，一条看起来像 GROUP BY 的 SQL，背后可能跑过多轮 Gemini 推理，最后交回一段很像答案的文字。

当数据库开始替我们“理解”数据，真正稀缺的能力也许不再是把模型接进 SQL，而是知道哪一部分仍然必须由确定性计算和人来负责。

参考资料

• Google Cloud：The AI.AGG function 外部链接
• Google Cloud：BigQuery release notes 外部链接
• Christianlauer：Google launched the AI.AGG Function for BigQuery 外部链接