1. 先理解“文本转SQL”和“人类基准”到底在说什么最近“首个文本转SQL模型超越人类基准”这个说法在数据库开发圈子里讨论得比较多。很多同学第一反应是自然语言直接生成SQL那以后是不是不用写SQL了这个理解方向不算错但和实际场景还有不少距离。先把这个技术点拆开看。文本转SQLText-to-SQL也叫NL2SQL指的是让大语言模型把一句自然语言问句转换成一条可执行的SQL查询语句。例如输入“查询2024年销售额超过100万的客户名称和销售金额”模型输出的目标是一条合法的SQL查询而不是一段解释文字也不是一个JSON结果。“人类基准”在这里通常指一个评测任务集合上由资深数据库开发人员编写SQL所达到的平均准确率。注意这里的“人类”不是泛指所有程序员而是经过训练、熟悉数据模型和SQL语法的专业人员。所以“超越人类基准”的意思是在特定评测集上模型生成SQL的准确度已经高于这些专业人员样本的平均水平。不过这里有三个必须说清楚的问题。第一评测准确率高不等于生产环境可以直接替代人工。评测集里的数据模型、字段命名、问题描述通常比较规范而真实业务里的表结构往往混乱字段含义靠文档甚至靠口头沟通才能确认。模型在评测集上超过人类不代表它面对一张几十个字段、命名随意、历史包袱很重的业务表也能稳定输出正确SQL。第二不同的评测集、不同的基准定义方式会导致结论差异很大。有的评测集偏向简单单表查询有的偏向多表关联和复杂聚合。有的基准是准确率有的是执行结果一致率有的是执行计划相近率。一个模型可能在准确率上超过人类但在复杂查询、长上下文、多轮追问场景里仍明显落后。第三“超越人类基准”指的是某个模型在当时公布的评测结果而不是“所有文本转SQL模型永远超过所有人类”。技术博客和新闻标题为了传播效果会简化表述落地做技术选型时还是要以自己业务数据集上的实测结果为准。那这篇文章为什么还要写因为无论“超越人类基准”这个表述是否绝对准确文本转SQL技术已经到了值得工程化验证的阶段。本文不讨论某个特定模型的排名而是围绕这个方向写清楚核心概念、环境准备、最小实现、评测方法、调优经验、常见坑和落地建议。读完你可以自己搭一套文本转SQL流程拿自己的表结构跑一次评测确认它到底能不能用于实际项目。2. 文本转SQL的核心机制与评测口径2.1 从自然语言到SQL模型到底在做什么很多人以为文本转SQL是模型直接“查数据库”实际上模型做的事是生成一条SQL字符串。真正的数据库连接、数据读取、结果返回仍然由传统数据库引擎完成。也就是说文本转SQL本质上是一个生成任务不是查询任务。完整链路通常是这样用户输入自然语言问题例如“各部门平均工资最高的员工是谁”。系统把问题、数据库表结构信息、字段说明、少量示例SQL一起拼成提示词。大语言模型根据提示词生成候选SQL。系统检查SQL语法必要时执行校验查询。校验通过后执行SQL返回结果给用户。关键点在于第2步。模型不知道数据库里有什么表、有什么字段除非你把表结构告诉它。很多初学文本转SQL的人会遇到“明明模型很聪明为什么生成的SQL表名都是编的”这个问题原因就是提示词里没有提供真实的 schema 信息。Schema 信息在文本转SQL里通常有两种组织方式。一种是直接把CREATE TABLE语句放到提示词里让模型自己读。另一种是先把表结构转换成专门的描述格式例如字段名、类型、主键、外键、字段注释、枚举取值再按固定模板注入提示词。后一种对模型更友好因为不是所有模型都能从 DDL 里准确理解业务含义。从生成策略上看文本转SQL可以分成两条路径直接生成模型一步生成最终SQL适合简单查询。中间表示生成先让模型生成语义解析树或中间查询语言再转换成SQL适合复杂查询但工程复杂度更高。目前主流大模型基本都采用直接生成配合足够好的提示词和示例。传统语义解析方法在特定领域仍有优势但通用场景下不如大模型灵活。2.2 模型评测为什么不能只看“是否生成成功”生成SQL的成功率是一个基础指标但用它衡量文本转SQL能力远远不够。一条SQL“能执行”和“结果正确”是两回事。评测时至少要区分四个层级第一层是语法合法。SQL能通过语法解析不会因为括号、引号、关键字错误而直接报错。第二层是执行成功。语法合法不代表一定能执行表名、字段名不存在也会执行失败。第三层是结果正确。在保证查询逻辑一致的前提下模型生成的SQL查询结果应该和人工编写SQL的查询结果一致。第四层是语义等价。有些SQL写法不同但结果一致例如用IN和EXISTS在特定场景下等价。评测系统需要识别这种等价性不能因为字符串不一样就判错。实际评测时最常用的是执行结果一致率也就是把模型生成的SQL和标准SQL放到同一个数据库上执行比较结果集是否一致。字符串完全匹配过于严格因为ORDER BY的字段顺序、别名命名、子查询结构都可能不同但结果集一样。还有一个容易被忽略的指标是“无结果错误率”。模型生成的SQL可能语法合法、执行成功但因为WHERE条件写错、连接条件缺失、聚合字段选错导致返回结果为空或返回错误数据。这种错误比语法错误更难发现因为系统不会报错用户看到的是“看似正常但实际不对”的结果。所以在评测文本转SQL模型时至少要记录四类指标指标含义为什么重要语法合法率生成SQL能通过语法解析的比例底层门槛不合法一定不可用执行成功率生成SQL能成功执行的比例表名、字段名、权限问题会影响结果一致率查询结果与标准SQL一致的比例核心质量指标完全正确率语法、执行、结果全对的比例工程可用性参考要注意结果一致率也不是绝对可靠。如果两条SQL在同一个数据集上执行结果相同但排序不同、字段精度不同、NULL 处理方式不同可能被误判为一致或不一致。评测任务设计时需要定义清楚比较规则。2.3 “人类基准”的构成为什么专业人员也会出错评测里所谓的人类基准通常不是找一个人写几条SQL取平均值而是有一套完整的构建流程。常见做法是从评测集里随机抽取若干问题交给多名数据库专业人员编写SQL然后对这些SQL做结果一致性校验通过校验的SQL作为标准答案。专业人员编写SQL也会出错原因包括对表结构理解偏差例如把customer_id当成订单表的业务字段结果却发现它其实是关联字段。对业务语义理解不一致例如“本月”是按自然月还是按财务月。对边界情况处理不统一例如是否需要包含 NULL 值、是否需要去重。多表关联时漏掉关联条件产生笛卡尔积得到异常大的结果集。所以“人类基准”并不是一个完美标准它只是提供了一个相对合理的参考线。模型要超越这个参考线意味着在大量问题上比平均值表现更好而不是在所有问题上都比最优秀的人类专家更强。理解这一点对工程落地很重要。如果项目的目标是“让模型在生成SQL上达到普通开发人员水平”那么“超越人类基准”的模型确实值得试试。如果目标是“让模型取代高级数据分析师”那就要在复杂业务上下文、多轮交互、数据权限控制等方面额外做大量工作。3. 从零搭一套文本转SQL验证流程3.1 环境准备Python、大模型接口和数据库在真实项目里落地前最好先搭一套最小验证流程用自己熟悉的表结构测试模型能力。这里推荐一个比较通用的技术栈Python 负责流程编排OpenAI 兼容接口调用大模型SQLite 或 MySQL 作为目标数据库。环境要求如下组件推荐选择说明Python3.10 或 3.11兼容主流大模型 SDK 和数据库驱动大模型OpenAI 兼容接口的模型可以是云端模型也可以是本地部署数据库SQLite 或 MySQL建议先用 SQLite 验证流程再切换 MySQL依赖库openai、sqlite3 或 pymysql、pandas负责接口调用和数据读取如果使用 OpenAI 兼容接口可以先安装基础依赖pip install openai pandas以 SQLite 为例不需要额外安装数据库服务Python 自带sqlite3模块适合做第一轮流程验证。如果目标数据库是 MySQL还需要安装驱动pip install pymysql环境准备好之后先确认三个检查点Python 版本是否符合依赖要求。大模型接口的 API Key 和 endpoint 是否可用。目标数据库是否能通过命令行正常连接。3.2 准备测试表和种子数据为了让验证流程可复现建议先建一个简单但有代表性的业务库。这里设计两张表部门和员工。创建表的 SQL 如下CREATE TABLE department ( dept_id INTEGER PRIMARY KEY, dept_name TEXT NOT NULL, location TEXT ); CREATE TABLE employee ( emp_id INTEGER PRIMARY KEY, emp_name TEXT NOT NULL, dept_id INTEGER, salary REAL, hire_date TEXT, FOREIGN KEY (dept_id) REFERENCES department(dept_id) );插入若干示例数据INSERT INTO department (dept_id, dept_name, location) VALUES (1, 技术部, 北京), (2, 市场部, 上海), (3, 财务部, 深圳); INSERT INTO employee (emp_id, emp_name, dept_id, salary, hire_date) VALUES (101, 张伟, 1, 15000, 2021-03-15), (102, 李娜, 1, 12000, 2022-07-01), (103, 王强, 2, 10000, 2020-11-20), (104, 赵敏, 2, 9500, 2023-01-10), (105, 刘洋, 3, 13000, 2019-05-06), (106, 陈晨, 3, 11000, 2022-09-12);这样一张表结构包含主键、外键、文本字段、数值字段和日期字段足够覆盖简单的单表查询、多表关联、聚合统计和条件过滤。3.3 构造 Schema 描述并注入提示词很多文本转SQL实现失败问题不在模型而在 schema 描述不够完整。模型需要知道每个字段的业务含义、是否允许为空、是否有默认值、有哪些枚举值。推荐把数据库表的 DDL 转换成对模型更友好的描述格式。例如表 department - dept_id: 主键部门ID类型 INTEGER - dept_name: 部门名称类型 TEXT - location: 部门所在城市类型 TEXT 表 employee - emp_id: 主键员工ID类型 INTEGER - emp_name: 员工姓名类型 TEXT - dept_id: 外键关联 department.dept_id部门ID - salary: 员工月薪类型 REAL - hire_date: 入职日期类型 TEXT格式 YYYY-MM-DD把这段描述放到系统提示词中比直接贴CREATE TABLE语句效果更稳定。原因在于模型能直接看到“外键”“主键”“部门所在城市”这类语义提示不需要自己从 DDL 关键字里推断。完整的提示词模板可以这样设计你是一名资深SQL开发人员。请根据数据库表结构将用户的中文问题转换成SQL查询。 表结构 {表结构描述} 注意事项 1. 只输出SQL语句不要输出额外解释。 2. 字段名和表名必须使用上面给定的名称不要添加反引号。 3. 如果问题涉及多表必须明确写出连接条件。 4. 如果问题没有明确要求排序不要添加ORDER BY。 5. 金额和数量字段为NULL时在聚合计算中默认按0处理。 用户问题{问题}其中{表结构描述}和{问题}是运行时动态填充的内容。这里的注意事項要根据实际项目调整不要盲目照搬。3.4 编写最小调用代码完成提示词构造后编写一个最小 Python 脚本来调用大模型生成SQL并在 SQLite 上执行。import os import sqlite3 from openai import OpenAI client OpenAI( api_keyos.getenv(OPENAI_API_KEY), base_urlos.getenv(OPENAI_BASE_URL), ) SCHEMA_DESC 表 department - dept_id: 主键部门ID类型 INTEGER - dept_name: 部门名称类型 TEXT - location: 部门所在城市类型 TEXT 表 employee - emp_id: 主键员工ID类型 INTEGER - emp_name: 员工姓名类型 TEXT - dept_id: 外键关联 department.dept_id部门ID - salary: 员工月薪类型 REAL - hire_date: 入职日期类型 TEXT格式 YYYY-MM-DD SYSTEM_PROMPT f 你是一名资深SQL开发人员。请根据数据库表结构将用户的中文问题转换成SQL查询。 表结构 {SCHEMA_DESC} 注意事项 1. 只输出SQL语句不要输出额外解释。 2. 字段名和表名必须使用上面给定的名称不要添加反引号。 3. 如果问题涉及多表必须明确写出连接条件。 4. 如果问题没有明确要求排序不要添加ORDER BY。 def generate_sql(question): response client.chat.completions.create( modelos.getenv(MODEL_NAME, gpt-4o-mini), messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: question}, ], temperature0, ) return response.choices[0].message.content.strip() def execute_sql(db_path, sql): conn sqlite3.connect(db_path) try: cursor conn.execute(sql) rows cursor.fetchall() columns [desc[0] for desc in cursor.description] return columns, rows finally: conn.close() if __name__ __main__: question 查询每个部门的员工数量按员工数量从高到低排序 sql generate_sql(question) print(生成SQL:, sql) columns, rows execute_sql(test.db, sql) print(列:, columns) print(结果:, rows)代码里设置了temperature0目的是让模型输出更稳定减少随机性。文本转SQL场景下多样性不是目标稳定性才是。执行结果生成SQL: SELECT d.dept_name, COUNT(e.emp_id) AS employee_count FROM department d JOIN employee e ON d.dept_id e.dept_id GROUP BY d.dept_name ORDER BY employee_count DESC 列: (dept_name, employee_count) 结果: [(技术部, 2), (市场部, 2), (财务部, 2)]这个最小闭环已经覆盖了从自然语言到SQL再到执行结果的全流程。后续的所有优化都在这个基础上扩展。3.5 表格对比直接贴DDL和结构化描述的区别很多开发者在第一次实现时会纠结到底是把CREATE TABLE原样塞给模型还是自己写字段描述这里给出一个经验性对比。方式优点缺点适用场景直接贴 DDL信息完整包含类型、约束、默认值模型需要自己推断语义字段无注释时效果差表结构简单、字段命名清晰结构化描述语义明确突出重点关系维护成本高表结构变化时要同步更新业务字段多、命名不规范、需要精确控制DDL 字段注释兼顾结构和语义提示词变长可能超过上下文限制数据库本身已有完整注释实际项目里推荐“结构化描述优先DDL 作为补充”。如果数据库已经维护了很好的字段注释可以直接读取元数据自动生成描述减少人工维护成本。4. 用评测脚本验证模型是否真的“超越了基准”4.1 为什么要在自己的数据上跑评测先说一个判断不要直接拿“超越人类基准”的新闻结论作为选型依据。原因有三个。第一公开评测集的问题分布和你的业务场景未必一致。电商、金融、教育、医疗的场景差异很大同一个模型在不同场景下的表现可能完全不同。第二公开评测集的标准答案不一定是你的业务规则。比如“活跃用户”的定义你可能是“最近30天有登录”评测集可能是“最近7天有购买”。第三公开评测集的表结构通常比较规整而真实业务的表和字段往往带着历史遗留问题。所以如果你想判断某个模型是否适合你们的业务正确做法是拿自己的表结构、自己的问题集、自己的标准SQL跑一轮本地评测。4.2 如何构造自己的评测集构造评测集不需要太多数据量但需要覆盖不同难度。建议按三个层次准备问题。第一层是简单查询覆盖单表过滤、排序、基础聚合。例如查询技术部所有员工姓名。查询薪资大于12000的员工人数。查询入职日期在2022年之后的员工姓名和部门名称。第二层是中等查询覆盖多表关联、分组聚合、条件组合。例如查询每个部门的平均薪资。查询员工人数超过1人的部门名称。查询每个部门薪资最高员工的姓名和薪资。第三层是复杂查询覆盖子查询、多级关联、去重、NULL处理。例如查询薪资高于部门平均薪资的员工姓名。查询在所有部门中薪资排名前三的员工姓名。查询没有员工的部门名称。每个问题都要编写一条标准SQL并记录预期结果。建议把评测数据保存成JSON或Excel方便脚本读取。最简单的格式如下[ { question: 查询技术部所有员工姓名, expected_sql: SELECT emp_name FROM employee WHERE dept_id 1, expected_result: [[张伟], [李娜]] }, { question: 查询每个部门的平均薪资, expected_sql: SELECT d.dept_name, AVG(e.salary) FROM department d JOIN employee e ON d.dept_id e.dept_id GROUP BY d.dept_name, expected_result: [[技术部, 13500.0], [市场部, 9750.0], [财务部, 12000.0]] } ]4.3 评测脚本实现结果集对比而不是字符串对比评测脚本的核心逻辑是对每个问题调用模型生成SQL在数据库里执行然后比较执行结果和标准结果。直接比较SQL字符串不推荐因为模型可能改写查询结构却得到相同结果。正确做法是比较查询结果集。import json import sqlite3 from openai import OpenAI client OpenAI( api_keyos.getenv(OPENAI_API_KEY), base_urlos.getenv(OPENAI_BASE_URL), ) def generate_sql(question): # 省略提示词构造复用前面代码 pass def execute_query(db_path, sql): conn sqlite3.connect(db_path) try: cursor conn.execute(sql) return cursor.fetchall() finally: conn.close() def normalize_result(rows): return sorted([tuple(row) for row in rows]) def evaluate(db_path, test_cases): total len(test_cases) correct 0 for case in test_cases: generated_sql generate_sql(case[question]) try: generated_result execute_query(db_path, generated_sql) except Exception as exc: print(f问题: {case[question]}) print(f生成SQL: {generated_sql}) print(f执行错误: {exc}) continue expected_result case[expected_result] if normalize_result(generated_result) normalize_result(expected_result): correct 1 else: print(f问题: {case[question]}) print(f生成SQL: {generated_sql}) print(f期望结果: {expected_result}) print(f实际结果: {generated_result}) print(f结果一致率: {correct}/{total} {correct / total:.2%}) if __name__ __main__: with open(test_cases.json, r, encodingutf-8) as f: test_cases json.load(f) evaluate(test.db, test_cases)normalize_result的作用是把结果行排序避免因为行顺序不同导致误判。如果查询结果包含浮点数还要考虑精度问题必要时用round统一精度。4.4 评测结果怎么看假设评测集有20条问题模型生成的结果一致率是85%那意味着有3条问题生成的SQL没有匹配预期结果。这时候要逐条分析失败原因而不是只看一个准确率数字。失败原因通常分几类模型对问题理解偏差。例如“近三个月”被理解成“最近90天”而业务定义是“按自然月计算”。模型缺少业务上下文。例如不知道“薪资”指的是税后薪资还是税前薪资。模型在复杂查询上退化。问题越长、表越多错误率越高。生成SQL语法正确但逻辑错误。例如遗漏了WHERE条件或者连接条件写错。这些失败案例是后续调优的重要输入。不要只追求整体准确率提升要具体看哪类问题反复失败。4.5 学习环境与生产环境的评测差异在本地用 SQLite 跑通的评测流程进入生产环境前还要补充几项能力。维度学习环境生产环境数据库SQLiteMySQL、PostgreSQL、SQL Server 等数据量几条示例数据千万级以上数据执行时间敏感权限控制无需要限制模型可访问的表和字段审计日志无需要记录问题、生成SQL、执行结果、用户信息安全策略无需要防止注入、防误操作、防敏感数据泄露回滚方案无查询超时、大结果集需要熔断生产环境不要直接把模型生成的SQL交给数据库执行建议至少增加一层人工确认或规则校验。后面会专门展开这部分。5. 提升生成SQL质量的五个工程手段5.1 增加字段语义注释和枚举值描述模型生成SQL时最容易错的是字段语义不明确。比如status字段不同表里含义可能不同。有经验的开发人员知道status1可能表示“启用”但模型如果没有上下文很可能猜错。解决方法是把字段注释和枚举值写进 schema 描述。例如表 order - status: 订单状态类型 INTEGER枚举值 0已取消1待支付2已支付3已发货 - total_amount: 订单总金额单位元类型 REAL - created_at: 订单创建时间类型 DATETIME枚举值信息特别重要因为模型看到status2时不知道2代表什么含义。有了枚举说明模型才能准确理解“查询已支付订单”应该写成WHERE status 2。5.2 少样本示例用几个经典查询约束模型输出格式除了系统提示词里的规则还可以加入少样本示例。少样本示例的作用是给模型一个“输出格式参考”让模型知道字段名怎么写、别名怎么起、多表关联用什么风格。例如在提示词中追加两个示例示例1 问题查询所有部门名称 SQLSELECT dept_name FROM department 示例2 问题查询每个部门的平均薪资按平均薪资降序排列 SQLSELECT d.dept_name, AVG(e.salary) AS avg_salary FROM department d JOIN employee e ON d.dept_id e.dept_id GROUP BY d.dept_name ORDER BY avg_salary DESC少样本示例不要太多2到5条足够。示例必须覆盖你最常见的查询模式而不是把各种复杂技巧都塞进去。示例太多会增加提示词长度还可能让模型过度模仿示例结构。5.3 对生成的SQL做语法校验和规则拦截模型生成SQL后不能直接扔给数据库执行。至少要做三层校验。第一层是语法校验。可以先用数据库的解析能力试执行也可以使用sqlglot这类库解析SQL语法。sqlglot的好处是不需要真实连接数据库纯文本校验。pip install sqlglotimport sqlglot sql SELECT * FORM employee try: sqlglot.parse_one(sql) print(语法合法) except Exception as exc: print(语法错误:, exc)第二层是规则校验。例如是否只查询了允许访问的表。是否包含DELETE、UPDATE、DROP等高危操作。是否包含SELECT *如果是生产环境建议拒绝。是否缺少WHERE条件防止全表读取。第三层是执行校验。在测试库上执行一次观察错误和返回行数。如果返回行数过大说明查询条件可能有问题。这三层校验在文本转SQL系统中必不可少尤其是在生产环境。模型再强也不能完全信任它生成的SQL。5.4 设置查询超时和结果集上限生产环境执行模型生成的SQL必须有超时机制。模型生成的SQL可能因为缺少过滤条件而执行全表扫描也可能因为关联条件写错产生笛卡尔积导致查询长时间不返回。以 MySQL 为例可以在连接层设置超时import pymysql conn pymysql.connect( hostlocalhost, useruser, passwordpassword, databasetestdb, connect_timeout5, read_timeout10, )SQLite 可以用timeout参数控制连接等待时间但真正处理慢查询还需要从SQL本身限制。推荐的思路是在生成的SQL外面包一层限制返回行数例如LIMIT 1000。使用数据库自带的执行超时配置。在应用层增加异步超时任务防止连接卡死。结果集上限也很重要。模型生成的聚合查询可能只返回几十行但漏了WHERE条件时可能返回几十万行。限制返回行数既能保护数据库也能避免接口响应过大。5.5 建立问题-标准SQL资产库文本转SQL不是一次性上线就结束它需要持续迭代。建议在项目早期就建立“问题-标准SQL”资产库把真实的业务问题沉淀下来。资产库字段建议包含字段说明question业务人员提出的原始问题standard_sql人工审核后的标准SQLtable_names涉及的数据库表biz_owner业务负责人created_at创建时间updated_at最后修改时间status有效、废弃、待确认这个资产库有多个用途作为评测集持续评估模型迭代效果。作为少样本示例的来源挑选典型查询加入提示词。作为回归测试集防止模型升级后在某些查询上效果退化。作为业务知识沉淀帮助后续开发人员理解每个SQL的来龙去脉。从实际经验看资产库规模达到200条时基本能覆盖多数业务场景的核心查询模式。6. 文本转SQL落地的三个典型坑6.1 坑一提示词里没给表结构模型乱编表名字段名这是最容易被忽视的问题。很多人第一次调用大模型做文本转SQL时直接把用户问题丢给模型没有附带任何数据库结构信息。结果模型生成SQL时使用了它“想象”出来的表和字段例如SELECT name FROM users而实际上你的表叫t_user。为什么会出现这种情况因为大模型在训练时见过大量通用数据库结构users、orders、products都是常见表名。你要求它针对当前数据库生成SQL却不告诉它当前数据库有什么表它只能按通用常识猜测。解决方式很简单在提示词中把当前数据库的 schema 信息完整提供给模型。这一点前面已经详细说明过但值得再强调一次因为大量实际项目翻车都倒在这一步。6.2 坑二多表关联查询缺少关联条件生成笛卡尔积多表查询是文本转SQL最常出错的场景。模型可能知道需要查询员工和部门两个表但生成的SQL没有写ON条件而是写成SELECT e.emp_name, d.dept_name FROM employee e, department d这种SQL在语法上合法但会返回两个表的笛卡尔积。如果员工表有10000条部门表有50条结果就是500000行。查询结果数量巨大还可能让应用卡死。出现这个问题的原因是模型只知道要关联两个表但不知道外键关系。所以在 schema 描述里显式写出外键非常关键employee.dept_id: 外键关联 department.dept_id少样本示例里也可以放一条带JOIN ON的查询帮助模型学习正确的关联写法。如果模型仍然经常漏掉关联条件可以在规则校验层检测如果一个SQL涉及多张表但没有JOIN或WHERE中的等值关联条件就标记为可疑SQL拒绝执行。6.3 坑三复杂问题生成内容正确但SQL有性能隐患有的SQL逻辑上没错结果也对但性能极差。例如SELECT * FROM employee WHERE salary IN ( SELECT MAX(salary) FROM employee GROUP BY dept_id )这条SQL能查出每个部门最高薪资的员工但写法上不是最优。如果员工表很大子查询和IN组合可能触发全表扫描。更优写法可以用窗口函数SELECT emp_id, emp_name, dept_id, salary FROM ( SELECT emp_id, emp_name, dept_id, salary, ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY salary DESC) AS rn FROM employee ) t WHERE rn 1但要求大模型总是生成最优性能的SQL并不现实。工程上的对策是把“结果正确”和“性能达标”分开看。先保证结果正确再对慢查询做人工介入优化。生产环境的文本转SQL系统最好把生成SQL的执行计划、执行耗时都记录下来定期分析哪些查询模式性能差然后针对性地在提示词或规则库里优化。7. 生产环境的安全与权限控制7.1 只读控制禁止生成写操作文本转SQL面向业务查询时系统只能执行SELECT查询不能允许模型生成INSERT、UPDATE、DELETE、DROP等语句。一旦模型在前面的系统提示词中理解有偏差可能生成写操作。安全做法是在代码层面加一道强制校验。生成SQL后先解析SQL类型只放行SELECT。import sqlglot def check_read_only(sql): try: expression sqlglot.parse_one(sql) except Exception: return False if isinstance(expression, sqlglot.exp.Select): return True return False如果SQL不是SELECT直接拒绝执行并记录日志。另外数据库账号也必须是只读账号从数据库权限层面再做一层兜底。这样即使应用层校验被绕过数据库也不会被破坏。7.2 数据权限不同用户只能查不同数据很多业务系统要求按用户权限过滤数据。例如销售主管只能看自己团队的销售数据不能全公司。这个问题不能只靠提示词解决因为模型生成SQL时并不知道当前用户是谁。工程做法是在SQL执行层统一注入权限条件。系统拿到模型生成的SQL后解析出主表或数据范围字段然后自动加上权限过滤条件。例如原始SQL是SELECT order_id, amount FROM orders当前用户只能访问sales_team 华东区的数据系统自动改写为SELECT order_id, amount FROM orders WHERE sales_team 华东区这种改写需要业务系统提供统一的权限模型不能零散地写在提示词里。权限条件注入应该由代码控制而不是交由模型自由发挥。7.3 敏感字段脱敏文本转SQL的真实业务中数据库里可能包含手机号、身份证号、银行卡号等敏感字段。模型根据自然语言生成SQL时不一定能识别哪些字段敏感哪些用户有权限查看。建议在 schema 描述里标记敏感字段- phone: 手机号敏感字段默认脱敏显示然后在执行层统一处理如果查询结果包含phone字段对返回数据做脱敏处理例如显示前三位和后四位。敏感字段的脱敏规则要符合数据安全规范不能把完整明文返回给前端。7.4 审计日志记录每一次生成与执行文本转SQL系统与应用系统集成的过程中审计日志是一个不可省略的环节。每条自然语言问题、生成的SQL、执行结果摘要、消耗时间、用户信息和系统反馈都要记录。建议的日志字段字段示例request_id8f3a1c9e2buser_id1001question查询华东区订单金额generated_sqlSELECT ...executedtrueerror_messagenullresult_rows200execute_ms345model_namegpt-4o-minicreated_at2025-01-15 10:22:33这些日志不仅是审计依据也是后续优化模型和提示词的素材。当某个问题生成SQL失败时可以回放日志重现场景。8. 大模型选型与部署方式对比8.1 云端API与本地部署的选型思路文本转SQL项目选模型时要先想清楚数据能不能出域。对很多企业来说数据库表结构、字段注释、业务问题本身可能属于敏感信息不能发送到第三方云端API。云端 API 和本地部署的对比维度云端API本地部署部署成本低接入快高需要GPU服务器数据安全数据发送到第三方数据不离开内部网络响应速度依赖网络受算力影响模型更新服务方维护需要自己升级成本按调用量计费固定硬件和运维成本离线支持不支持支持如果只是内部验证云端API更合适。生产环境涉及敏感数据优先考虑私有化部署。但私有化部署的模型能力通常落后云端最新模型需要在效果和合规之间做权衡。8.2 模型能力评估不要只看跑分选型时不要只看“准确率排行榜”。建议用前面建好的评测集在同样条件下对比候选模型记录每个模型在不同难度问题上的表现。可以先对比三个基础能力单表查询准确率。多表关联查询准确率。复杂子查询准确率。再对比工程相关指标平均生成耗时。失败率。是否容易生成不可执行的SQL。对提示词长度的敏感度。把结果整理成表格能更直观地看出每个模型的优劣。9. 文本转SQL的未来方向9.1 多轮对话先澄清条件再写SQL目前很多文本转SQL系统是单轮问答用户问一句系统生成一条SQL。但真实业务里用户往往需要多次追问才能把需求表达清楚。例如“查一下上个月销售额”之后可能会追加“不要包含退款订单”。多轮对话需要系统维护上下文记住前面的表名、条件和用户偏好。大模型天然支持对话上下文但要真正应用在文本转SQL中还需要设计状态管理机制。系统需要知道当前对话关联哪些表、之前已经确认了哪些查询条件、后续追问是修改条件还是新增条件。这个问题目前还在快速发展中。9.2 语义缓存避免重复调用模型同一类问题在业务系统中可能被反复提问。例如“查询今日订单量”每天都会被问很多次。每次调用大模型生成SQL既费时间又费成本。可以引入语义缓存对用户问题做向量化计算与历史问题之间的相似度。如果相似度高直接复用之前的SQL和结果不再调用模型。语义缓存要处理好数据时效性。订单量这类实时查询不能缓存太久但例如“部门列表”这类静态数据可以缓存较长时间。缓存策略要按业务场景配置。9.3 结合执行计划优化SQL文本转SQL可以继续扩展在生成SQL之后用数据库执行计划做二次优化。例如一些数据库支持EXPLAIN命令可以分析SQL的执行计划。如果发现全表扫描、缺少索引、代价过高可以自动改写SQL或提醒用户添加索引。这个方向已经有一些工具在探索但对小团队来说更实际的做法是先把“生成正确SQL”这件事做好再考虑自动优化SQL。执行计划自动改写的风险较高需要充分的规则验证。10. 可复用的文本转SQL项目检查清单最后整理一份项目落地检查清单适用于从验证阶段进入生产阶段的团队。检查项说明状态表结构描述是否完整每个表、字段、主键、外键、枚举值是否都说明了必查提示词是否包含少样本示例至少覆盖单表查询和多表查询建议是否设置了 temperature0保证生成结果稳定建议是否有语法校验使用 sqlglot 或数据库试执行必查是否禁止写操作SQL代码层和数据库账号层双重保护必查是否设置查询超时防止慢查询拖垮接口必查是否限制结果集大小防止笛卡尔积返回大量数据必查是否记录审计日志问题、SQL、结果、用户、时间建议是否建立评测集至少覆盖简单、中等、复杂三类问题必查是否有敏感字段脱敏手机号、身份证号等字段脱敏按业务需要是否做数据权限过滤不同用户只能看授权数据按业务需要是否评估过模型性能响应时间和准确率是否满足要求必查值得注意的是这份清单并不要求每个项目第一次就做到完美。如果只是做技术验证可以先保证前四项。进入生产环境后再逐步补齐安全和审计能力。文本转SQL的本质价值在于降低非技术人员获取数据的门槛但它背后仍然需要工程化的质量保障体系来兜底。所谓“超越人类基准”只是一个阶段性信号真正决定项目成败的是你在提示词设计、评测闭环、安全控制和生产运维上投入了多少持续优化。