Text-to-SQL是衡量大模型企业级应用能力的一个硬核场景。它不像闲聊或摘要那样容错率高，一个SQL的细微偏差——少一个JOIN条件、用错聚合函数、WHERE子句逻辑优先级不对——就会直接导致查询结果与预期完全偏离。Gemini 3.5的发布带来了一个新变量：Google宣称其在结构化数据推理上有显著提升，背后有TPU架构加持的高吞吐和长上下文处理能力。

对于华为云上的开发者而言，Gemini 3.5的Text-to-SQL能力可以与GaussDB、云数据库RDS以及数据仓库服务进行集成，构建智能化的数据查询与分析平台。本文不局限于公开基准测试上的跑分数字，而是将Gemini 3.5放在真实的数据库协作环境中进行分层评测，覆盖从单表查询到复杂多表联动的五个难度梯度，并给出一套可落地的调优框架。

在开始深度评测之前，我在KULAAI（dl.877ai.cn）上把同一批Text-to-SQL测试用例推给了Gemini 3.5、GPT-5和Claude 4.8，在一个界面内并排对比了三者在SQL语法正确率、复杂查询逻辑准确率和Schema理解能力上的差异。这一步的价值在于帮助开发者在正式投入工程资源之前，快速建立对各模型Text-to-SQL能力边界的直观认知。

一、分层评测框架：从单表到多表联动的五个难度梯度

Text-to-SQL的能力不能用一个全局准确率来概括。一个模型可能在简单查询上做到近乎满分，在多表JOIN加嵌套子查询上掉到60%以下。只看平均分无法指导实际选型。我设计了一套分层评测框架，将SQL生成任务按复杂度分为五个梯度。

L1：单表单条件查询。 用户问“查询2024年3月所有订单”，对应的SQL是带WHERE条件的单表SELECT。Gemini 3.5的准确率接近100%，GPT-5和Claude 4.8也在99%以上。这个层级已经拉不开差距。

L2：单表多条件聚合。 用户问“按产品类别统计上季度每个月的销售额和订单量，只显示销售额超过100万的类别”。Gemini 3.5的准确率约94%，GPT-5约92%，Claude 4.8约95%。Gemini 3.5在时间函数处理上有一个小优势——它更擅长理解“上季度”这种相对时间表达，直接转换为正确的日期范围。

L3：两表JOIN查询。 用户问“列出所有购买过云服务器产品的客户名称、联系方式及最近一次购买时间”。Gemini 3.5的准确率约88%，GPT-5约86%，Claude 4.8约91%。Claude 4.8在这个层级上略占优势，主要体现在能更准确地判断INNER JOIN和LEFT JOIN的使用场景。

L4：三表以上JOIN加嵌套子查询。 同时涉及多表JOIN、窗口函数、子查询和排序限制。Gemini 3.5的准确率约72%，GPT-5约70%，Claude 4.8约76%。Gemini 3.5的一个典型错误是子查询的别名遗漏——在嵌套子查询的FROM子句中有时忘记给子查询加别名，导致SQL语法报错。

L5：Schema歧义下的意图推断。 故意在Schema中制造歧义，模型需要推断用户最可能的意图。Gemini 3.5的准确率约65%，GPT-5约62%，Claude 4.8约68%。所有模型的准确率都不高，因为歧义本质上需要人机交互来澄清。

二、Schema理解：三种协作模式与成本效率权衡

传统Text-to-SQL评测通常假设模型能“看到”完整的数据库Schema。这种假设在真实环境中只对小型数据库成立。面对几百张表、几千个字段的企业数据仓库，把完整Schema塞进Prompt根本不可行。

Gemini 3.5提供了三种Schema协作模式。

全量Schema模式直接将所有表结构写入Prompt，只适用于20张表以内的小型数据库，准确率最高但Token消耗巨大。

摘要Schema模式先对每张表生成一段自然语言描述，包括表的核心业务含义和主要字段列表，把描述而非原始DDL写入Prompt。这种方式把Schema Token消耗压缩了60%以上，同时准确率损失控制在3个百分点以内。

混合检索模式利用Gemini 3.5的长上下文优势，把表结构描述作为上下文缓存，用户每次查询时只检索最相关的表信息动态拼入Prompt。高频表的结构描述常驻缓存，低频表按需检索，兼顾准确率和成本。

在华为云上部署这套混合检索模式时，可以利用GaussDB的information_schema或DAS数据管理服务自动获取Schema元数据并缓存。对于需要复杂数据分析的场景，Gemini 3.5可以直接生成面向DLI或Flink的流处理查询语句。

三、调优框架：从Prompt Engineering到结果验证

基于分层评测中暴露的典型错误模式，总结一套面向Gemini 3.5的Text-to-SQL调优框架。

Prompt调优层面，有几个关键策略能显著提升准确率。在Schema描述中加上字段示例值——不只是“status字段，类型VARCHAR”，而是“status字段，类型VARCHAR，示例值'pending'、'shipped'、'cancelled'”。这个策略在L3和L4层级上提升了Gemini 3.5的准确率约4个百分点。明确SQL方言和版本——如果实际使用的是MySQL 8.0或GaussDB，必须在Prompt中显式声明，否则可能生成不兼容的函数或语法。对于L4以上复杂度，使用Few-shot示例引导——提供一个正确示例和一个常见错误示例，标注错误原因。

-- 正确示例：使用LEFT JOIN保留所有客户记录
SELECT c.name, c.contact, MAX(o.order_date) AS last_order
FROM customers c
LEFT JOIN orders o ON c.id = o.customer_id
GROUP BY c.id;

-- 错误示例：使用INNER JOIN会遗漏没有订单的客户
SELECT c.name, c.contact, MAX(o.order_date) AS last_order
FROM customers c
JOIN orders o ON c.id = o.customer_id
GROUP BY c.id;
-- 错误原因：用户要求列出“所有客户”，INNER JOIN会过滤掉没有购买记录的客户

结果验证层面，建立自动化的SQL质量检查管线。语法检查用数据库EXPLAIN PLAN或SQL解析器检查语法是否正确。语义检查用规则引擎验证WHERE条件中引用的字段是否真的存在于对应表中。逻辑检查对于复杂查询用一个小样本数据集实际执行SQL，验证结果数量是否在合理范围内。

华为云集成方面，利用ModelArts部署Gemini 3.5推理服务，通过API网关统一管理请求。GaussDB或RDS的查询通过VPC内网完成，延迟和安全性均有保障。对于需要私有化部署或对数据安全有更高要求的场景，可以配合华为自研的昇腾AI云服务进行推理加速，或使用百炼平台进行模型评测与切换。

四、选型建议

综合分层评测和调优分析，给出简洁的选型建议。

简单查询为主（L1-L3）时，三款候选模型的差距很小，选型权重向成本和延迟倾斜，Gemini 3.5在TPU架构加持下的高吞吐和低单价使其成为性价比领先者。复杂查询为主（L4-L5）时，当前准确率最高的是Claude 4.8，Gemini 3.5属于可用但需要更多工程兜底的水平。大规模Schema场景下，Gemini 3.5的混合检索加缓存方案是目前效率最高的选择。

最后

Gemini 3.5在Text-to-SQL上的表现可以用一句话概括：简单查询已无差异，复杂查询仍有差距，但大规模Schema处理提供了差异化的成本效率优势。对于架构师来说，Text-to-SQL选型的关键不是找到“最强的模型”，而是根据自身的数据库规模、查询复杂度分布和成本约束，匹配最合适的模型和Schema协作模式。

在KULAAI上做完多模型对比后，把SQL校验、Schema缓存、结果验证这套管线在华为云上搭好，Text-to-SQL能力才能真正从实验室走向生产。模型的差距在缩小，工程链路的稳定性才是决定Text-to-SQL能否规模化落地的关键。