AI智能体处理结构化数据：Gemini + BigQuery文本转SQL实战

高管向"公司ChatGPT"提出的问题有一半是分析性的：对比、汇总、趋势、分群。没有文本转SQL，智能体只能回复"请查看BI工具"。有了良好构建的文本转SQL，智能体就能返回带图表的正确数字。

标准架构（7步）

核心组件：语义层

模型不会记忆你的数据仓库Schema。没有语义层，它只会猜测表名和列名。

语义层是一个精心策划的目录：

• 附有PT/EN描述的表和列。
• 同义词（"receita" = "revenue" = "faturamento"）。
• 表间关系（显式外键）。
• 预定义指标（"平均客单价 = SUM(金额)/COUNT(订单)"）。
• 默认过滤器（"仅已确认订单"）。
• 时间和地理粒度。

工具：dbt + Looker语义层、Cube.js，或自定义YAML定义。在Autenticare项目中，我们统一使用版本化的YAML。

文本转SQL的提示词模式

提示词中始终包含：

• 相关表的Schema（完整DDL）。
• 3–5个问题→格式良好SQL的示例。
• 明确方言（"PostgreSQL 15"、"BigQuery Standard SQL"）。
• 限制："始终使用LIMIT 1000"、"禁止DELETE/UPDATE/DROP"、"使用命名参数"。
• 输出格式：代码块内的纯SQL，无多余注释。
• 不确定性规则："如果没有数据可以回答，返回null + 解释"。

更多模式见企业级提示词工程。

执行前的强制验证

1. SQL解析器：确保是有效的SQL（不是注释，不是散乱文本）。
2. 操作白名单：仅允许SELECT。
3. 表白名单：智能体只能访问标记为"agent-accessible"的表。
4. ACL检查：用户是否有该表的权限？
5. BigQuery的dry-run（零成本，验证语法并估算字节数）。
6. 已处理字节数上限（成本上限）。
7. 执行超时。

混合"分析型智能体"模式

在实际案例中，最好结合：

• 预定义指标（语义层）：对于常见问题，使用参数执行现成查询。更快更可靠。
• 自由文本转SQL：对于目录之外的临时问题。需要额外验证。
• 字典RAG：智能体在生成SQL之前查阅业务文档（政策、定义）。

朴素文本转SQL的常见问题

遗忘的JOIN

"我们按地区卖了多少？"——智能体忘记与门店表做JOIN，返回错误数字。解决方案：在语义层中标注推荐的JOIN。

未声明的过滤器

"月度收入"——智能体没有过滤status="confirmed"。始终在语义层中包含默认过滤器。

时间粒度

"三月份的销售额"——哪一年的三月？没有上下文，智能体会做出错误假设。在提示词中包含当前日期 + 规则："如果未指定年份，使用当前年份"。

货币换算

跨国公司同一张表中有BRL、USD、ARS：智能体不转换直接相加。在语义层中使用衍生指标解决。

相似指标的混淆

"净收入"vs"毛收入"vs"GMV"——没有明确定义，智能体选择错误。带有规范定义的词汇表可以解决这个问题。

专项评估

文本转SQL的黄金测试集与RAG不同。结构：

• 自然语言问题。
• 期望SQL（规范）或一组等效SQL。
• 期望结果（数字）。
• 主要指标：执行匹配（结果匹配，即使SQL写法不同）。
• 次要指标：逻辑形式匹配（正确的SQL结构）。

在100–300个问题的语料库中，执行匹配召回率达到90%+是现实目标。详情见生产中的智能体评估。

需要控制的成本

• BigQuery字节数：每次查询和每用户/天的限制。
• Gemini tokens：提示词中的大型Schema会消耗tokens。通过第一次路由调用只选择相关表。
• 查询缓存：短时间窗口内的相同问题 = 从缓存返回结果，无需重新执行。

治理

• 审计日志：问题 + 生成的SQL + 已处理字节数 + 结果 + 用户。
• 真实身份：查询以用户自己的权限运行，而非服务账号。
• PII处理：在聚合回答中绝不暴露CPF/电子邮件——敏感列必须聚合。
• DPIA针对个人数据分析——见Gemini Enterprise项目DPIA。

何时不使用文本转SQL

• 需要判断的问题（"我们应该怎么做？"）：结合补充分析。
• 关键决策（价格、客户报价）：智能体建议，人工决定。
• 具有深层业务逻辑的复杂多表分析：最好用传统BI + 智能体来总结。

文本转SQL在智能体知道自己不能触碰什么时才有效。精心策划的语义层 + 白名单 + dry-run >> 塞入200张表的巨型提示词。