SCALE:一个面向专业级任务的大语言模型 SQL 能力开源评测框架

随着大语言模型(LLM)在数据科学领域的应用日益广泛,学术界和工业界涌现出多种评测基准。然而,我们观察到,现有评测体系大多聚焦于 Text-to-SQL 的转换准确率,而这远不能全面反映模型在真实、复杂场景下的 SQL 处理能力。

为了弥补这一关键空白,我们经过深入研究,提出了 SCALE —— 一个面向专业级任务的大语言模型 SQL 能力开源评测框架。我们致力于通过开放、透明和社区驱动的方式,建立一个行业公认的评估标准。

https://sql-llm-leaderboard.com/

背景:现有 LLM-SQL 评测的局限性

近年来,大语言模型处理结构化查询语言(SQL)的能力取得了长足进步。一系列公开的评测基准(Benchmark)也应运而生,它们在很大程度上推动了模型在 Text-to-SQL 任务上的发展。

尽管如此,我们发现现有的评测体系仍存在显著的局限性。在专业的数据库管理和软件开发实践中,开发者面临的挑战远比“将一句话转为 SQL”要复杂得多:

  • 性能是生命线:一个能返回正确结果但执行耗时数分钟的查询,在生产环境中是不可接受的。现有评测很少关注模型生成 SQL 的性能和效率。

  • 环境是多样的:数据库迁移和跨平台适配是常见需求。但模型能否精准处理不同数据库(如 MySQL,Oracle,PostgreSQL)之间的“方言”差异,现有评测也鲜有涉及。

  • 理解是深度的:维护、审查和重构遗留代码是开发者的日常。这要求模型不仅能“写”代码,更能深度“理解”代码的逻辑、意图和潜在风险。这一点同样是当前评测的薄弱环节。

现有评测的单一视角,使得开发者和决策者在面对真实、复杂的业务需求时,难以选择出真正合适的模型。

我们的解决方案:SCALE 评测框架

为了系统性地解决上述问题,我们设计并实现了 SCALE (SQL Capability Leaderboard for LLMs) 大模型 SQL 能力排行榜

SCALE 并非对现有评测的简单复现,而是一个从数据库专家和资深开发者真实工作流出发,构建的全新、完全开源的评测框架。我们相信,只有 开放源代码、开放数据、开放方法,才能建立最广泛的行业信任。

评测基石:一个高质量、多层次的数据集

一个评测框架的公信力,源于其评测数据的质量与广度。为此,我们构建了一个高质量、多层次、贴近真实世界的数据集,并将其向社区完全开放。

  • 真实世界案例:我们收集并脱敏了来自不同行业的真实查询案例。这些案例作为数据集的基础,确保了评测内容与生产环境的实际挑战保持一致。

  • AI 辅助的典型场景构造:为提升测试集的覆盖深度,我们针对容易引发逻辑错误或性能问题的复杂场景,如子查询、多表连接、嵌套查询、存储过程等,利用 AI 辅助构造了大量细粒度的测试用例,旨在精准评估模型在处理复杂查询时的逻辑稳健性与准确性。

  • 评分权重设计:为区分不同任务的复杂度,我们为测试用例设置了不同的评分权重。通常,技术复杂度更高的用例会获得更高的权重。

  • 答案验证:所有测试用例的参考答案均经过交叉验证,以确保其准确性。

三大核心评测维度

基于这一强大的数据集,SCALE 通过三个相互独立的核心维度,深入考察模型在处理高价值、高复杂度 SQL 任务时的真实水平。

⚡ SQL 优化能力 (SQL Optimization)

  • 研究问题:模型是否具备数据库专家(DBA)的性能优化意识?

  • 评估方法:我们为模型提供一系列典型的低性能查询,评估其能否在保证逻辑等价的前提下,改写出性能更优的版本。评测指标不仅包含语法正确性,更引入了对优化规则复杂度的量化评估,以衡量其优化策略的优劣。

  • 应用场景:当您需要进行数据库性能调优或代码重构时,此维度的评测结果将为您提供关键参考。

🔄 方言转换能力 (Dialect Conversion)

  • 研究问题:模型能否成为一个可靠的、跨数据库平台的“代码翻译官”?

  • 评估方法:我们评估模型在多种主流数据库“方言”之间进行转换的逻辑保真度与语法准确性,确保其转换结果是“开箱即用”且完全可靠的。

  • 应用场景:对于面临数据库迁移、构建跨平台数据中台等挑战的团队,此维度的领先模型是首选。

📊 SQL 理解能力 (SQL Understanding)

  • 研究问题: 除了写代码,模型对 SQL 的理解有多深?

  • 评估方法: 我们从执行结果准确性、语法错误识别、执行计划分析、查询类型判断等多个角度,全面考察模型对 SQL 代码的深度分析能力。

  • 应用场景: 在进行代码审查(Code Review)、遗留系统维护、自动化代码分析等工作中,此维度的评测结果能帮您找到最“懂”SQL 的 AI 助手。

SCALE 的价值与应用

我们相信,一个严谨、贴近实践的评测框架,能为不同角色的专业人士创造价值:

  • 对于数据与软件开发人员:提升开发效率,保障交付质量。SCALE 能帮您快速找到最称手的 AI 工具,处理优化、迁移、代码审查等专业任务,将宝贵的精力聚焦于更有创造性的工作上。

  • 对于 AI 研究员与模型开发者:精准定位坐标,指明迭代方向。SCALE 透明的评测方法和开源的数据集,能清晰揭示您模型在专业 SQL 任务上的长处与短板,为下一阶段的优化和训练提供明确的、可量化的目标。

  • 对于企业 CTO 与技术决策者:降低技术风险,驱动业务创新。基于 SCALE 客观、中立的数据做出技术选型,能确保您为企业引入的 AI 能力是真正可靠、高效的,从而赋能团队,构建更健壮的数据基础设施。

结论与展望

我们推出 SCALE,旨在为社区提供一个更专业、更深入、更贴近真实需求的 LLM SQL 能力评估标准。

作为一个开源项目,我们深知社区的力量是其生命力的源泉。 我们不仅发布评测结果,更开放所有评测脚本、数据集和方法论。我们诚挚地邀请您探索 SCALE 的评测结果,利用这一工具为您的研究和工作做出更精准的技术判断。更重要的是,我们欢迎您 加入我们的社区,贡献代码、提交测试用例或提出宝贵建议。

让我们一同完善 SCALE 的评测体系,共同推动大语言模型在数据库领域的应用走向新的深度。

  • 探索 SCALE 实时排行榜 -> https://sql-llm-leaderboard.com/

  • 了解评测方法与技术细节 -> https://github.com/actiontech/sql-llm-benchmark

SCALE:为专业 SQL 任务,选专业 AI 模型。

数据集构造策略: [58]1、泛化问题自然语句和SQL语句构建流程: [59]1)、相关业务人员根据业务用户的需求功能点及使用情况提供问题表述。将相关问题、表结构信息、表中部分数据输入大模型,由具有开源商用协议的大模型产生对应的SQL语句。业务人员再结合业务数据库执行SQL查验结果,并人工标记修改错误的SQL,以确保其正确性和合规性,得到初始种子数据集。 [60]2)、由具有开源商用协议的大模型将不同的问题进行扩充,改变表述方法但不改变表述意思,新的问题在保持原意的基础上,对问题的表达方式的措辞进行微调,使其与原始问题意思相近但有所不同,确保它们在保持原意的同时,增加多样性和新颖性。一个原始问题扩充出新问题的数量由需要生成的目标数据集大小决定。人工对扩充后的问题进行核验,确保扩充后的语义与原始语义保持一致。 [61]3)、将问题、表结构信息(表字段、每个字段的类型及含义解释、主键外键关联关系)、相关业务背景知识包括业务场景下的名词解释以及生成SQL语句的规范要求,提供给由具有开源商用协议的大模型以成对应的SQL语句。 [62]4)、将扩充问题生成的SQL执行结果与种子问题执行的SQL结果进行对比,保留结果一致的问题和SQL一个种子问题对应多个扩写问题,且有多个候选的正确SQL。即得到泛化问题数据,构建数据集时,每个问题可从对应的SQL所属组的候选SQL中随机抽取。 [63]2、模版问题自然语句和SQL语句构建流程: [64]1)、相关业务人员根据业务需求提供实际场景中的问题表述,问题包括多种类别(明细类、趋势类、分布类、总数类)和多种维度(历史问题、实时问题)。将相关问题、表结构信息、表中部分数据输入大模型,设计构建prompt,调用具有开源商用协议的大模型自动生成符合语法和语义的SQL语句。 [65]2)、执行SQL,如果发现错误或不合规的SQL语句,业务人员再结合业务数据库对错误的SQL进行检查修正,得到初始模版问题和SQL语句。人工检查对大模型生成的SQL通过一定的规则进行逐一检查,确保语法正确、语义清晰,并且符合业务需求。如果发现错误或存在疑问,及时进行调整和修正。对SQL语句涉及的字段进行检查,确保其与数据库表结构一致,并且符合业务需求。如果发现错误或不一致的情况,及 [66]时进行调整和修正。 [67]3)、原始模版问题实例化,改成模版形式,写脚本随机抽取信息填充生成新的样本,根据示例问题、SQL模版,对SQL进行实例拼接,譬如时间、地点、类别的随机替换或者排序、条件比较的更改,以生成更多新的样本数据。 [68]4)、拼接完成后输入到数据库中执行查询,保留正确的问题及SQL [69]数据集, [70]得到检验后的标准化模版问题数据集。
10-24
<think>我们正在讨论数据集构造策略,特别是针对自然语言到SQL(NL2SQL任务。用户希望了解如何构建包含泛化问题和模板问题的数据集,以及自然语句与SQL语句的构建流程。 首先,我们需要明确几个概念: 1. 泛化问题:指那些能够覆盖多种场景、不局限于特定模板的自然语言问题,具有较好的多样性和泛化性。 2. 模板问题:基于预定义的模板生成的问题,通常结构固定,变化较少,易于生成大规模数据。 构建这样的数据集通常包括以下步骤: ### 1. 数据需求分析 确定数据集的用途(如训练NL2SQL模型),并据此设定数据集的规模和结构。例如,每个数据库模式(schema)需要对应多个自然语言问题及其SQL查询。 ### 2. 数据库模式设计 需要构建或选择一组数据库模式。这些模式可以来自真实场景(如金融、医疗等)或根据需求设计。每个模式包括多个表,表之间有外键关联,每个表有多个列,列有类型和约束。 ### 3. 问题生成 - **模板问题生成**:使用预定义的模板生成问题。例如,对于一个表`students`,可以设定模板:“查询所有{列名}”,然后替换列名生成多个问题。 - **泛化问题生成**:可以通过以下方式: a. **人工撰写**:由专业人员撰写多样性的问题,覆盖不同的表达方式和复杂的查询结构。 b. **基于规则生成**:设计更复杂的规则,允许在问题中引入条件组合、嵌套查询等。 c. **使用语言模型生成**:利用大语言模型(如GPT系列)根据schema生成自然语言问题,然后进行人工校验。 ### 4. SQL生成 每个自然语言问题需要对应一个正确的SQL查询。生成SQL的方法包括: - **人工编写**:准确但耗时。 - **基于规则生成**:配合模板问题,根据模板生成SQL。例如,模板问题“查询所有学生的姓名”对应SQL:`SELECT name FROM students`。 - **使用语义解析器**:利用已有的NL2SQL模型生成SQL,然后人工修正。 ### 5. 质量控制 - 验证自然语言问题是否清晰、无歧义。 - 验证SQL是否正确,并且与问题匹配。 - 验证生成的SQL是否可执行,并且在目标数据库上运行结果正确。 ### 6. 数据增强 - 同义替换:对自然语言问题进行同义词替换,以增加多样性。 - 添加噪声:模拟真实用户输入,可能包含拼写错误、语法错误等。 ### 7. 划分数据集 将数据集划分为训练集、验证集和测试集。注意确保同一数据库模式的问题不会同时出现在训练集和测试集中,以评估模型的泛化能力。 下面是一个简单的示例,展示模板问题和对应的SQL: 假设我们有一个数据库模式,包含两个表: - `学生表(students)`: 字段包括`学号(id)`, `姓名(name)`, `年龄(age)`, `班级(class_id)` - `班级表(classes)`: 字段包括`班级号(id)`, `班级名称(name)` 模板问题1:查询所有学生的姓名。 SQL:`SELECT name FROM students` 模板问题2:查询班级名称是'一班'的所有学生姓名。 SQL:`SELECT s.name FROM students s JOIN classes c ON s.class_id = c.id WHERE c.name = '一班'` 泛化问题示例1:给我一份所有学生的名单。 SQL:`SELECT name FROM students` 泛化问题示例2:列出所有属于一班的同学的名字。 SQL:`SELECT s.name FROM students s JOIN classes c ON s.class_id = c.id WHERE c.name = '一班'` 注意,泛化问题在表达上更灵活,但语义相同。 构建流程总结: 1. 确定数据库模式 -> 2. 生成或收集自然语言问题(模板+泛化)-> 3. 为每个问题生成正确的SQL -> 4. 数据清洗与验证 -> 5. 数据增强(可选)-> 6. 划分数据集。 参考文献: [^1]: Yu, T., et al. (2018). Spider: A Large-Scale Human-Labeled Dataset for Complex and Cross-Domain Semantic Parsing and Text-to-SQL Task. EMNLP. [^2]: Zhong, V., et al. (2017). Seq2SQL: Generating Structured Queries from Natural Language using Reinforcement Learning. arXiv. 下面生成相关问题: </think>### 数据集构造策略详解:泛化问题与模板问题的自然语句与SQL构建流程 在构建自然语言转SQL(NL2SQL)数据集时,核心策略分为**泛化问题**和**模板问题**两类,以下是分步构建流程: --- #### 一、泛化问题构建流程 **目标**:创建语义相同但表达多样的自然语言问题,提升模型泛化能力 **流程**: 1. **语义核心提取** - 确定SQL查询的核心逻辑(如`SELECT name, age FROM users WHERE country='CN'`) - 提取关键元素:目标字段、表名、过滤条件、连接关系 2. **自然语言多样化生成** - **同义替换**: - 原句:"列出中国用户的姓名和年龄" - 变体:"显示国籍为中国的用户姓名及年龄" - 变体:"获取所有中国用户的姓名与年龄信息" - **句式重构**: - 主动→被动:"姓名和年龄需要被提取给中国用户" - 疑问→陈述:"我需要中国用户的姓名和年龄" - **冗余信息注入**: 添加不影响SQL的修饰词(例如"请帮我"、"返回结果按字母排序") 3. **SQL对齐验证** - 使用SQL解析器(如`sqlglot`)确保所有变体生成相同语法树 - 人工校验语义一致性(覆盖率需≥95%) ```mermaid graph LR A[SQL逻辑核心] --> B[自然语言变体生成] B --> C{语法树一致性检测} C -->|通过| D[入库] C -->|失败| B ``` --- #### 二、模板问题构建流程 **目标**:通过预定义模板批量生成数据,保证结构覆盖度 **流程**: 1. **模板分类设计** | 模板类型 | 示例自然语句 | SQL结构 | |--------------|-----------------------------|-------------------------| | 单表查询 | “获取{table}的{col}” | `SELECT {col} FROM {table}` | | 多表JOIN | “查询{table1}和{table2}的关联{col}” | `SELECT ... JOIN ... ON` | | 聚合查询 | “计算{table}中{col}的平均值” | `SELECT AVG({col}) ...` | | 嵌套子查询 | “找出{col1}超过平均值的{col2}” | `SELECT ... WHERE > (SELECT AVG...)` | 2. **占位符填充策略** - **表名/字段名**:从数据库schema采样(确保外键关联) - **数值/字符串**: - 范围值:`age BETWEEN [20,30]` - 枚举值:`country IN ('CN','US')` - **逻辑运算符**:轮询`AND/OR/NOT`组合 3. **复杂度控制** - 初级:单表+单条件(覆盖80%简单查询) - 中级:JOIN+聚合(如`COUNT`+`GROUP BY`) - 高级:嵌套查询+多条件组合 --- #### 三、质量保障机制 1. **自动验证层** ```python def validate_pair(nl: str, sql: str) -> bool: # 1. SQL语法检查 if not sql_validator(sql): return False # 2. 执行结果一致性(连接测试DB) result1 = execute_sql(sql) result2 = execute_sql(generate_sql_from_nl(nl)) # 用基准模型生成SQL return result1 == result2 ``` 2. **人工审核重点** - 歧义表述(如“最新”需明确是`ORDER BY time DESC LIMIT 1`) - 领域术语一致性(如“用户”在DB中为`users`表) --- #### 四、典型数据集参考 1. **Spider数据集** - 泛化问题占比60%,覆盖138个领域数据库 - 使用同步语法树生成技术[^1] 2. **WikiSQL** - 纯模板生成,24,241种句式模板 - 基于表格标题自动映射字段[^2] ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值