DB-GPT Text2SQL 微调实战：从 Spider 数据集到 0.789 执行准确率

DB-GPT Text2SQL 微调实战从 Spider 数据集到 0.789 执行准确率【免费下载链接】DB-GPTopen-source agentic AI data assistant for the next generation of AI Data products.项目地址: https://gitcode.com/GitHub_Trending/db/DB-GPT通用大模型生成 SQL 的准确率为什么上不去如果你直接拿一个通用开源大模型去答自然语言转 SQL 的问题在 Spider 跨领域基准上大概率只拿到 50% 出头的执行准确率——这是 DB-GPT 官方基线表里 CodeLlama-13B 的 base 成绩0.539。同样的模型经过 LoRA 微调后能到 0.746。差距就藏在领域适配这四个字里。Text2SQL 微调就是补这一课的标准化流程喂给它数据库表结构 问题 标准 SQL 的三元组让模型学会看着 schema 写 SQL。DB-GPT 把这套流程做成了自动化框架数据预处理、LoRA/QLoRA 训练、预测、执行准确率评估全部脚本化单卡 A100 上 12 小时跑完一个 13B 模型的完整训练。上图是 DB-GPT 的分层架构最底部的 Train 层就是本文主角 DB-GPT-Hub它负责 Text2SQL、Text2DSL 等训练任务与上层的 ChatDB、RAG、Agents 模块解耦。这个框架是什么代码在哪先说清边界DB-GPT 主仓库负责推理与产品能力Web 界面、Agent、RAG而 Text2SQL 微调代码被拆到了独立子项目 DB-GPT-Hub 中主仓库里保留的是完整的操作手册见 text_to_sql.md 和 dbgpt_hub.md。对同类方案LLaMA-Factory、ChatPT 等通用微调工具来说DB-GPT-Hub 的差别在于两点数据侧内置了 Text2SQL 专用的预处理逻辑把 Spider 的表结构自动编织进指令模板不需要自己写 dataset 适配脚本评估侧直接对接执行准确率exec accuracyplug_value的 Spider 评测口径训练完一条命令出分数。它也发布了 pip 包dbgpt_hub不想拉整个仓库的可以用 Python API 直接调。最小可跑通路径从数据到分数这一节回答最少要跑哪几条命令。整条链路是数据准备 → 一键生成训练集 → LoRA 训练 → 预测 → 评估。上面这张官方流水线图概括了六个环节。落到命令上环境准备和数据生成合在一起只需要这些# 准备环境微调环境建议独立 conda git clone https://gitcode.com/GitHub_Trending/db/DB-GPT conda create -n dbgpt_hub python3.10 conda activate dbgpt_hub pip install dbgpt_hub # Spider 数据集放到 dbgpt_hub/data/spider 后一键生成训练/评估数据 sh dbgpt_hub/scripts/gen_train_eval_data.sh脚本产出example_text2sql_train.json8659 条和example_text2sql_dev.json1034 条数据集在dbgpt_hub/data/dataset_info.json里以example_text2sql为键注册后面训练参数--dataset传的就是这个键。训练脚本dbgpt_hub/scripts/train_sft.sh的官方推荐参数CodeLlama-13B LoRACUDA_VISIBLE_DEVICES0 python dbgpt_hub/train/sft_train.py \ --model_name_or_path /path/to/CodeLlama-13b-Instruct-hf \ --dataset example_text2sql_train \ --max_source_length 2048 --max_target_length 512 \ --finetuning_type lora --lora_target q_proj,v_proj \ --template llama2 --lora_rank 64 --lora_alpha 32 \ --per_device_train_batch_size 1 --gradient_accumulation_steps 16 \ --lr_scheduler_type cosine_with_restarts \ --learning_rate 2e-4 --num_train_epochs 8 --bf16这组参数在 A100(40G) 上约 12 小时。想省显存在脚本里追加--quantization_bit 4即切换为 QLoRA官方结论是 8 个 epoch 下效果与 LoRA 相差不大但训练时间可压缩到 8 小时左右。训练完成后依次跑预测和评估预测结果默认落在dbgpt_hub/output/pred/sh ./dbgpt_hub/scripts/predict_sft.sh python dbgpt_hub/eval/evaluation.py --plug_value --input Your_model_pred.sql--plug_value会把 SQL 里的常量替换成占位值再比较结果避免常量猜错但逻辑正确被误判。官方多次评估的执行准确率为 0.789 以上官方发布的CodeLlama-13b-sql-lora权重在 Spider 评估集上也复现了这个水平。不想敲 shell 的话同样四个阶段在dbgpt_hub包里是对应的四个函数from dbgpt_hub.data_process import preprocess_sft_data # 数据预处理 from dbgpt_hub.train import start_sft # LoRA/QLoRA 训练 from dbgpt_hub.predict import start_predict # 批量预测 from dbgpt_hub.eval import start_evaluate # 执行准确率评估数据、训练、预测、评估各传一个参数字典即可参数名与 shell 版一一对应。机制深潜数据怎么喂、参数怎么设、分数怎么算命令跑通只是第一步这三处决定了你的分数上限值得逐个拆开看。1. 表结构不是附属信息而是指令的一部分框架采用信息匹配生成方法先把 Spider 的tables.json解析成db_id → 表结构文本的字典再把表名、列名、主外键描述填进指令模板I want you to act as a SQL terminal in front of an example database, you need only to return the sql command to me. ##Instruction: department_management contains tables such as department, head, management. Table department has columns such as Department_ID, Name, Creation, ...核心处理代码在子项目的dbgpt_hub/data_process/sql_data_process.py入口是ProcessSqlData.decode_json_file()。设计动机很直接SQL 能不能写对一半取决于模型是否看见了正确的表和列。把 schema 写死在 instruction 里等于把检索这一步从推理时提前到了训练时模型学到的就是读 schema → 写 SQL的映射。最终每条样本是db_id / instruction / input / output / history五元组output即标准 SQL。2. lora_target 和 template 跟着模型走LoRALow-Rank Adaptation低秩适配只训练注入在注意力层旁的小型低秩矩阵基础权重冻结所以 13B 模型单卡可训。但注入哪一层、用什么对话模板因模型而异配错直接训废基础模型lora_targettemplateLLaMA-2 / CodeLlama-2q_proj,v_projllama2Baichuan2W_packbaichuan2Qwenc_attnchatmlChatGLM2query_key_valuechatglm2其余超参官方给的经验值lora_rank 64、lora_alpha 32、learning_rate 2e-4、num_train_epochs 8、max_source_length 2048多次实验后的最优输入长度因为 instruction 里塞了完整 schema太短会截断表结构、max_target_length 512覆盖绝大多数 SQL 长度。3. 执行准确率 ≠ SQL 文本匹配评估不是字符串比对而是把预测 SQL 在对应 SQLite 库上真实执行、比较结果集。这意味着同语义不同写法的 SQL 都能得分也更贴近线上真实表现代价是评估结果对temperature等生成参数有随机性官方口径是多次评估 0.789 以上而不是单一固定值。生成参数在子项目的dbgpt_hub/configs/model_args.py的GeneratingArguments里调。踩坑记录现象 → 原因 → 解法以下三条是官方文档明确提到的典型问题按现象→原因→解法对照现象A100 上要 12 小时机器不够或想快出结果原因13B 8 epoch 梯度累积 16显存和步数都是大头。 解法优先调低gradient_accumulation_steps官方文档原话的第一建议或直接切 QLoRA 加--quantization_bit 4官方实测 8 epoch 下精度损失很小。现象显存 OOM原因batch 和序列长度乘起来超出单卡容量。 解法per_device_train_batch_size压到 1用梯度累积补有效 batch再叠加 4-bit 量化。QLoRA 的完整配置NF4 量化、双量化、bfloat16 计算参考子项目文档中的示例。现象两次评估分数不一致原因LLM 生成与temperature相关默认多次评估的波动是正常现象官方给的是区间下限 0.789 而非单点值。 解法评估时固定生成参数多跑几轮取稳定值调参对比时用同一批预测结果别混用。现象复杂多表查询的 Hard/Extra 难度得分明显偏低原因Spider 分级结果显示微调后 Easy 能到 0.94 而 Extra 只有 0.4 左右难度分级下长尾查询是主要失分点。 解法这不是配置问题而是数据分布问题——需要补充多表关联、嵌套子查询类样本再训练即文档提示的按ProcessSqlData的逻辑自行扩充训练数据。各档位的实测分数exec accuracySpider你的基础模型微调方法EasyHardExtra总体CodeLlama-13Bbase不微调0.6980.4080.2710.539CodeLlama-13BLoRA0.9400.6840.4040.746CodeLlama-13BQLoRA0.9400.6260.3920.727Qwen-14BLoRA / QLoRA0.895 / 0.9190.552 / 0.5980.331 / 0.3670.663 / 0.701Baichuan2-13BLoRA0.9030.5690.3920.678结论一句话同规格下 LoRA 稳赢 QLoRA 但更吃显存CodeLlama 系是这套参数下成绩最好的基座换模型时别照搬参数lora_target/template必须按上一节的对照表改。选型与边界哪些事它做不了按显存档位给推荐你的显存推荐做法说明 16GB7B 模型 QLoRA4-bit7B 单卡约需 6GB 显存量化后 13B 也能勉强塞进 16GB16–32GB13B QLoRA官方实测与 LoRA 差距很小 32GB如 A100 40G13B LoRA复现 0.789 的执行准确率训练约 12 小时坦率说几个边界代码不在主仓库。sft_train.py、gen_train_eval_data.sh等路径都存在于 DB-GPT-Hub 子项目中主仓库里只有文档。环境搭建以pip install dbgpt_hub或拉取子项目为准别在主仓库里找训练脚本找不到就以为功能缺失。模型清单有天花板。官方基线覆盖了 CodeLlama、LLaMA-2、Qwen、Baichuan2、ChatGLM 等其他模型要自己查lora_target和template不保证开箱即用。指标口径。0.789 是 Spider 评估集 plug_value的执行准确率不是精确匹配换数据集WikiSQL、CHASE 等分数没有官方承诺需要自己跑start_evaluate验证。Hard/Extra 难度仍是短板0.4 左右如果你的业务以多表复杂查询为主这个基线模型可能不够得先扩充数据再谈上线。完整步骤和全部参数说明以 text_to_sql.md 为准Python API 版示例见 dbgpt_hub.md。跑通第一条链路、拿到 0.789 左右的分数之后再按你自己的业务库换tables_file数据源迭代就是这套框架最省时间的用法。【免费下载链接】DB-GPTopen-source agentic AI data assistant for the next generation of AI Data products.项目地址: https://gitcode.com/GitHub_Trending/db/DB-GPT创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考