数据库schema
要让大模型能够写出SQL，前提肯定是让它先理解数据库的表结构是什么样子的。获取数据库表结构当然并不是什么难的事情，比如在Mysql中直接使用以下命令就能生成数据表的DDL语句:
SHOW CREATE TABLEuser
# 输出结果如下：
CREATE TABLE `sys_user` (
`id` varchar(255) NOT NULL COMMENT '用户id',
`account` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NOT NULL COMMENT '登录名',
`nickname` varchar(255) DEFAULTNULL COMMENT '昵称',
`password` varchar(255) NOT NULL COMMENT '密码',
`phone` varchar(255) DEFAULTNULL COMMENT '手机号',
`email` varchar(255) DEFAULTNULL COMMENT '邮箱',
`rental_id` varchar(32) DEFAULT'' COMMENT '组织id',
PRIMARY KEY (`id`),
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4DDL语句是表示数据库schema的基本形式，很多text2sql框架也是直接使用DDL sql喂给大模型的。比如Chat2db，它的提示词看起来非常简单：
请根据以下table properties和SQL input将自然语言转换成SQL查询.
MYSQL SQL tables, with their properties:
["CREATE TABLE `driven_distance` (\n `id` bigint(20) NOT NULL AUTO_INCREMENT,\n `organization_id` bigint(20) DEFAULT NULL,\n `vehicle_id` bigint(20) DEFAULT NULL,\n `license_plate` varchar(255) DEFAULT NULL,\n 。。。"]
SQL input: 2023年，每个季度的加油金额各是多少元？但这种表现形式其实存在一些缺陷：
1. 冗余干扰：DDL语句中包含了一些对于text2sql这个场景并没有用处的信息，比如字符集，表引擎等。 2. 方言差异：不同数据库的DDL语句也有较大的差异，比如数据类型，同样是字符串，有些是varchar，有些直接叫做string，有些又叫text，这些情况都不利于让大模型能够稳定的理解相关的表结构 3. 关系缺失：DDL语句中并没有包含表与表之间的关系信息（虽然也包含外键信息，但是由于数据管理和性能等方面的原因，外键现在相对比较少见了），常规的text2sql框架一般是通过语义检索，比较用户问题与表名之间的相似度，然后选取相关的数据表schema注入到提示词中，至于数据表之间的逻辑联系只能靠大模型自行去理解了，如果是简单查询，检索命中的表数量相关较少的情况下，效果还行。但是如果需要复杂的多跳关联，那么就非常考验大模型的能力了，输出的稳定性也会直线下降
针对这些问题，业界最新提出了一种叫做M-Schema的数据库结构表示方式，它以半结构化格式展示了数据库、表和列之间的层级关系：
这种表现形式完全按照LLM最容易理解的markdown格式来组织表结构，剔除了各种对于text2sql场景无效的信息，并加入两项关键的信息扩展：
• 表数据抽样： DDL语句只有某个列字段的数据类型，比如string，但是具体的数据格式却无从得知。如果是一些强模式的数据，比如user的account字段，数据格式其实是用户的手机号，如果大模型能够获取这种潜在的模式信息，对于其生成SQL的质量也是更加有保障的。而真实的业务数据抽样，恰恰能揭示很多类似这样的，并没有明确在文档和注释中写明的业务规则。 • 字段到其它表的映射关系： 这个信息的重要性毋庸置疑，涉及到多表连接的场景明确指定连接字段和关联表能够显著的提高的大模型输出正确SQL的概率。
数据表关系抽取
在M-Schema扩展的信息中，表数据抽样的数据相对比较好处理。但是在表之间的关联关系就不是那么容易了，如果有明确的文档或者定义了外键还好办，但是实际业务项目钟大多数数据库其实文档是非常有限的，最多也就只有表和字段的寥寥几笔的说明而已。那么如何在没有文档的情况下获取数据库中表与表之间的关联关系呢？这里其实可以借鉴一点GraphRAG的思路。
我们设计表关联的时候，通常都会将关联字段命名为一些特定的格式，比如：user_id, order_code，这类关联字段通常的命名格式都是
{关联表对应的实体名}_{关联表中字段名}有了这样的对应关系，我们就可以尝试通过字段名和表名的模式匹配来确定表与表是否存在关联了。具体方法是：
1. 首先需要借助大模型的能力，从表名中提取最能代表该表实体的一些实体名词，去掉一些无意义的前缀或者后缀，比如t_base_organization，提取的实体名就是organization; 2. 然后获取该表的主键，比如叫做id，接着就去循环去比较其它表中是否存在类似organization_id的字段，如果存在，且字段类型与源表的id字段类型是一致的，那我们就可以基本认为这两张表存在关联关系了。 3. 可以再做一些进一步的确认，比如t_user表有一个字段是organization_id，我们可以通过SQL抽样一些organization_id看看是否都能够和t_base_organization的id字段相匹配。
当然这种方式依赖于数据库设计时遵守相应的约定和规则，也不能保证100%的正确。比如有些实体名称在关联业务表中可能使用简称或者别名，比如organization_id 可以简写为org_id。对于一些例外的情况，目前暂时也没有太好的解决方案，还是依赖于人工对关系进行补充。
SQL示例
如果仅仅只提供数据库的schema，即使schema完全准确，对于一些需要连接多张表的复杂的查询大模型输出的SQL质量也是非常不稳定的，容易出错。这个时候可以在知识库中适当的通过人工构建一些符合当前业务场景的常用SQL作为示例，增强大模型对于复杂业务场景的SQL输出成功率。在Vanna框架中，每次大模型输出的SQL语句如果不符合业务需求，可以人工再进行订正，并把订正的结果再次放入向量数据库中作为示例。这样在下次遇到同样的需求场景时，就能够从示例中学习到如何构建正确的SQL。
# 修正错误SQL并存入知识库
vanna.train(
question="近三月各区域销售额？",
sql="SELECT region, SUM(sales) FROM orders WHERE..."
)约束输出
虽然现在大模型在结构化输出上的能力进步非常明显，但是对于SQL这种高度结构化的数据，有时候还是会翻车的，比如输出时额外又附加了一些不必要的解释和说明，或者没有为子查询没有生成别名。另外真实业务场景中，我们通常需要SQL遵循一些特定的条件约束，比如查询语句必须添加limit限制查询数量，必须带上有效的数据权限标识等。这些约束如果是通过提示词的方式来影响大模型的输出，效果并不好，输出会非常不稳定，这对于需要精确执行的SQL语句来说是致命的。
目前解决的方式大致有两种：
1. 使用约束解码器对大模型的输出进行约束，确保其输出的格式满足预先定义的标准。比如vLLM推理引擎支持通过 EBNF 语法来确保大模型输出特定语法格式的SQL：
simplified_sql_grammar = """
root ::= select_statement
select_statement ::= "SELECT " column " from " table " where " condition
column ::= "username " | "email "
table ::= "users " | "roles "
condition ::= column "= " value
value ::= [a-zA-Z_] [a-zA-Z0-9_]*
"""
completion = client.chat.completions.create(
model="Qwen/Qwen2.5-3B-Instruct",
messages=[
{
"role": "user",
"content": "Generate an SQL query to show the 'username' and 'email' from the 'users' table.",
}
],
extra_body={"guided_grammar": simplified_sql_grammar},
)
print(completion.choices[0].message.content)EBNF的语法格式非常灵活，你甚至可以自己定义一种SQL语言的子集，用于限定大模型的输出。但是这玩意强大归强大，非常难学也难用。主要还是用来保证一些大的模式的正确性，比如只允许输出查询语句，禁止DDL等，如果想进行精细控制，那么可能会花费大量的精力在编写EBNF语句上。
2. 对于精细控制的需求，可以使用目前已经比较成熟的SQL解析框架，比如java的jsqlparser框架进一步对大模型输出的SQL结构进行改造，添加需要的约束条件等。这个模式当前已经非常成熟了，有很多的框架可以进行选择，稳定性也非常高。
// 使用jsqlparser自动添加LIMIT
Select select = (Select) CCJSqlParserUtil.parse(sql);
select.setLimit(new Limit().withRowCount(new LongValue(100)));模型能力
模型能力对于text2sql效果的影响当然是最大的，目前主流的模型对SQL理解和输出的效果相对已经不错了。但是如果需要更进一步的提升在复杂场景下的成功率和稳定性，还是需要针对业务场景进行进一步的微调训练的，不过成本相对比较高。社区也有一些专门针对text2sql场景进行预训练的模型，比如阿里开源的析言SQL系列模型，可以在模型参数量较小的情况下，获得比主流模型更稳定的输出效果。
总结
在底层模型能力尚未取得突破性进展的当下，Text2SQL的效果提升本质上仍是一场工程化能力的较量。其核心优化路径始终未脱离RAG应用的基本逻辑——通过构建更完整的数据库文档、优化检索召回算法、扩充高质量SQL示例，均可显著提升系统输出质量。而其中对数据库Schema的深度挖掘尤为关键：只有充分揭示字段与表之间的内在业务联系，才能让底层模型真正理解复杂场景的领域知识，从而实现准确率的跃升。
