AI智能体处理结构化数据：Gemini + BigQuery文本转SQL实战
RAG处理文档。但针对BigQuery、Snowflake或PostgreSQL中结构化数据的问题呢？真正可用于生产的Gemini文本转SQL模式——以及仍需人工介入的环节。
Fabiano Brito
CEO & Founder
高管向"公司ChatGPT"提出的问题有一半是分析性的：对比、汇总、趋势、分群。没有文本转SQL，智能体只能回复"请查看BI工具"。有了良好构建的文本转SQL，智能体就能返回带图表的正确数字。
| 维度 | 传统知识库 RAG | 智能体 Text-to-SQL |
|---|---|---|
| 数据源类型 | 非结构化文档 (PDF, Word, Wiki) | 结构化数据库 (BigQuery, PostgreSQL) |
| 核心计算能力 | 语义检索与内容摘要 | 精确聚合、对比、趋势分析与计算 |
| 结果精准度 | 模糊匹配，存在幻觉风险 | 100% 确定性的 SQL 执行结果 |
标准架构（7步）
用户原始输入，含会话上下文。
智能体在目录中搜索涵盖该主题的表（语义层）。
Gemini 2.5 Pro以数据仓库方言生成参数化查询。
SQL解析器 + 操作白名单 + ACL + dry-run。
BigQuery/Snowflake/Postgres使用用户自己的身份，而非服务账号。
智能体格式化结果并建议可视化方式。
数字 + 表格 + 可选图表 + 所用查询（用于审计）。
核心组件：语义层
模型不会记忆你的数据仓库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 + 解释"。
更多模式见企业级提示词工程。
执行前的强制验证
- SQL解析器：确保是有效的SQL（不是注释，不是散乱文本）。
- 操作白名单：仅允许SELECT。
- 表白名单：智能体只能访问标记为"agent-accessible"的表。
- ACL检查：用户是否有该表的权限？
- BigQuery的dry-run（零成本，验证语法并估算字节数）。
- 已处理字节数上限（成本上限）。
- 执行超时。
SELECT * FROM events，DBA从此出名。Dry-run、表白名单和字节上限不是可选的——它们是生产中文本转SQL与BigQuery计费事故之间的区别。
混合"分析型智能体"模式
在实际案例中，最好结合：
- 预定义指标（语义层）：对于常见问题，使用参数执行现成查询。更快更可靠。
- 自由文本转SQL：对于目录之外的临时问题。需要额外验证。
- 字典RAG：智能体在生成SQL之前查阅业务文档（政策、定义）。
💡 架构师建议：混合路由策略
在实际生产中，建议将 80% 的高频业务问题（如“上月销售额”）通过语义层直接路由至预定义的 SQL 模板，仅将 20% 的长尾探索性问题交由 Gemini 实时生成 SQL，以最大化保障系统稳定性。
朴素文本转SQL的常见问题
遗忘的JOIN
"我们按地区卖了多少？"——智能体忘记与门店表做JOIN，返回错误数字。解决方案：在语义层中标注推荐的JOIN。
未声明的过滤器
"月度收入"——智能体没有过滤status="confirmed"。始终在语义层中包含默认过滤器。
时间粒度
"三月份的销售额"——哪一年的三月？没有上下文，智能体会做出错误假设。在提示词中包含当前日期 + 规则："如果未指定年份，使用当前年份"。
货币换算
跨国公司同一张表中有BRL、USD、ARS：智能体不转换直接相加。在语义层中使用衍生指标解决。
相似指标的混淆
"净收入"vs"毛收入"vs"GMV"——没有明确定义，智能体选择错误。带有规范定义的词汇表可以解决这个问题。
专项评估
文本转SQL的黄金测试集与RAG不同。结构：
- 自然语言问题。
- 期望SQL（规范）或一组等效SQL。
- 期望结果（数字）。
- 主要指标：执行匹配率
常见问题
使用 Gemini 和 BigQuery 的 text-to-SQL 的主要优势是什么？
通过精心设计的 text-to-SQL，代理会返回带有图表的正确数字，而不仅仅是指示查询 BI。
使用 Gemini 和 BigQuery 的 text-to-SQL 的标准架构有哪些步骤？
标准架构涉及 7 个步骤，从自然语言问题到可审计的答案，包括 schema 检索、SQL 生成、验证、执行和后处理。
为什么 'semantic layer' 是 text-to-SQL 架构中的关键组件？
如果没有 'semantic layer'，模型可能会猜测表名和列名，从而影响结果的准确性。
在 text-to-SQL 的上下文中，什么是 'semantic layer'？
'semantic layer' 是一个经过整理的目录，其中包含带有描述、同义词、表之间关系、预定义指标、标准过滤器以及时间和地理粒度的表和列。
使用 Gemini 和 BigQuery 的 text-to-SQL 的标准架构有哪些步骤？
标准架构涉及 7 个步骤，从自然语言问题到可审计的答案，包括 schema 检索、SQL 生成、验证、执行和后处理。
为什么 'semantic layer' 是 text-to-SQL 架构中的关键组件？
如果没有 'semantic layer'，模型可能会猜测表名和列名，从而影响结果的准确性。
在 text-to-SQL 的上下文中，什么是 'semantic layer'？
'semantic layer' 是一个经过整理的目录，其中包含带有描述、同义词、表之间关系、预定义指标、标准过滤器以及时间和地理粒度的表和列。
使用 Gemini 和 BigQuery 的 text-to-SQL 的标准架构有哪些步骤？
标准架构涉及 7 个步骤，从自然语言问题到可审计的答案，包括 schema 检索、SQL 生成、验证、执行和后处理。
为什么 'semantic layer' 是 text-to-SQL 架构中的关键组件？
如果没有 'semantic layer'，模型可能会猜测表名和列名，从而影响结果的准确性。
在 text-to-SQL 的上下文中，什么是 'semantic layer'？
'semantic layer' 是一个经过整理的目录，其中包含带有描述、同义词、表之间关系、预定义指标、标准过滤器以及时间和地理粒度的表和列。