一、数据集准备
1.1 数据集介绍
本次微调采用 Hugging Face 平台上的 fahmiaziz/text2sql-dataset
(https://huggingface.co/datasets/fahmiaziz/text2sql-dataset)数据集。该数据集包含 126,642 条样本,每条样本包含三列:
prompt
: 用户用自然语言描述的查询需求。context
: 查询目标数据库的表结构语句(DDL)。answer
: 对应的标准 SQL 查询语句。
1.2 数据集多样性分析
为评估数据集任务覆盖范围,分析统计了以下五类 SQL 任务的出现频率:
- 聚合统计 (Aggregation): 查询包含
SUM
,AVG
,COUNT
,MIN
,MAX
等聚合函数。 - 多表关联 (Multi-table):
FROM
子句后包含多个表名(通过识别表名数量 >= 2 判断)。 - 子查询 (Subquery): 查询包含子查询(通过检测
FROM (SELECT ...)
或WITH
子句判断)。 - 时间范围筛选 (Time Filter): 查询包含
DATE
,MONTH
,YEAR
,BETWEEN
等与时间筛选相关的关键词。 - 唯一值提取 (Distinct): 查询包含
SELECT DISTINCT ...
。
分析方法: 编写 Python 脚本(关键逻辑见下方代码框)遍历数据集中的每条 answer
(SQL 语句),利用正则表达式识别上述特征并计数。
|
分析结果:
- 聚合统计 (Aggregation): 68,533 条
- 多表关联 (Multi-table): 119,092 条
- 子查询 (Subquery): 370 条
- 时间范围筛选 (Time Filter): 22,953 条
- 唯一值提取 (Distinct): 3,997 条
结论: 数据集在聚合、多表关联和时间筛选任务上分布广泛。子查询样本量显著偏少,推测可能由于多数子查询逻辑可通过多表连接实现转换。总体而言,该数据集具备任务多样性特征,适合用于 Text2SQL 模型微调。
1.3 数据预处理(适配百炼平台格式)
百炼平台微调要求输入数据为两列 Excel 文件:
Prompt
: 输入提示词。Completion
: 期望的模型输出(目标 SQL)。
原始数据集包含 prompt
, context
, answer
三列,需进行转换:
Step1:提示词拼接: 将 prompt
(用户问题) 和 context
(表结构) 按以下模板组合成完整的 Prompt
:
|
Step2:列重命名与导出: 保留拼接后的 Prompt
和原始 answer
列,将 answer
重命名为 Completion
,导出为 Excel 文件。
完整代码如下:
|
预处理后的数据格式符合百炼平台要求。
1.4 导入数据集
将生成的 train_text2sql_prompt_with_context_en.xlsx
文件导入百炼平台数据集管理模块,并完成发布操作,使其可用于模型训练。
二、模型微调任务配置
2.1 模型选择
- 基础模型: Qwen2.5-7B
- 训练方式: 高效训练
2.2 建立验证集
采用百炼平台提供的自动切分功能,由平台在训练时自动从导入的数据集中划分出一部分作为验证集。
2.3 参数调整
- 关键调整: 将默认的训练轮数 (Epochs) 由 3 调整为 1。
调整依据: 在首次尝试训练(Epochs=3)过程中,观察到训练损失 (Training Loss) 在早期即迅速收敛。为避免后续轮次带来的不必要计算开销和成本,手动终止了该次训练任务,并在新任务中减少了 Epochs。
三、训练过程与结果
3.1 训练资源消耗
- 训练时长: 15 小时 02 分 55 秒
- Token 消耗: 21,292,839 Token
- 费用估算: 按平台单价 0.006 元/千 Token 计算,费用约为 127.76 元 (21,292,839 / 1000 * 0.006 ≈ 127.76)。
3.2 训练效果评估
- 训练损失 (Training Loss): 如损失曲线图所示,损失值在训练早期即快速下降并趋于稳定,最终收敛至 0.09左右。这表明模型较快地学习到了数据中的模式。
-
- 注:平台未提供手动停止训练功能,导致训练持续完成整个设定的轮数(1 Epoch),尽管损失已提前收敛。
- 验证损失 (Validation Loss): 损失曲线显示验证损失持续稳定下降,最终达到 0.093 左右,表明模型在未见数据上具备良好的泛化能力
- 验证集准确率 (Validation Accuracy): 达到 0.96,表明模型在验证集上生成正确 SQL 的比例很高。
四、心得体会
- 监控损失收敛: 在模型微调过程中,密切监控训练损失曲线的收敛情况至关重要。本次训练在早期轮次即表现出显著收敛迹象。
- 动态调整 Epochs: 基于实时的损失收敛趋势,适时调整训练轮数 (Epochs) 是优化成本效益的关键策略。本次通过将 Epochs 从默认值 3 降至 1,有效避免了资源浪费(尽管平台未支持提前停止导致首个任务部分轮次浪费)。