cn-sqlite-4b：中文问题 → SQLite 查询

English | 简体中文

一个能在自己电脑上离线运行的 4B 小模型：给它建表语句和一句中文问题，它写出能直接执行的 SQLite 查询。在一个从没见过的 14 张表业务库上答对 64%，比参数大近一倍、不微调的 Qwen2.5-Coder-7B 高 36 个点；配合 ask.py 使用时，没把握会直接说明，不硬给答案。

效果

宽松准确率（执行结果和标准答案一样就算对，多返回几列也算对），5 份现生成的数据上都要对：

测试集	题数	底座 Qwen3-4B	第一轮微调	这一版	Qwen2.5-Coder-7B（不微调）
城市公交（14 张表，行业不在训练数据里）	64	26.6%	46.9%	64.1%	28.1%
零售难题（12 张表）	100	42%	69%	74%	55%
健身房（5 张表）	40	75%	92.5%	92.5%	85%
图书馆（4 张表）	40	80%	90%	92.5%	77.5%

• 比底座在三个集子上的提升显著（配对 McNemar 检验 p < 0.05），图书馆 p = 0.125；比第一轮在公交集上显著（p = 0.043）
• 出训练数据的 DeepSeek 用同样的 prompt 做公交集：deepseek-chat 89%，deepseek-reasoner 97%。这个模型离它还有距离
• 推理时让它「跑不通就改、多写几条投票」还能再涨，见下面「推理时补救」一节

文件

文件	用途
adapter_model.safetensors、adapter_config.json	LoRA（约 270MB），叠在 Qwen/Qwen3-4B-Instruct-2507 上用
cn-sqlite-4b-Q4_K_M.gguf、cn-sqlite-4b-Q8_0.gguf	LoRA 合并进底座后的量化版，给 llama.cpp / Ollama 本地跑，分别约 2.5 GB 和 4.3 GB

想要合并好的完整权重（bf16），用数据集仓库里的 export_gguf.sh 第 2 步自己合并，几分钟。

代码（ask.py、评测、训练）在数据集仓库 YukiKaze1337/cn-sqlite-sft 的 scripts/ 里。

用法

prompt 格式必须和训练时一样（scripts/prompt.py）：系统提示固定是

你是 SQLite 查询专家。用户会给你建表语句和一句中文问题，你要写出一条能回答它的 SQLite 查询。只输出 SQL，不要解释。

用户消息里放建表语句、可选的「部分字段的取值」、问题：

建表语句：
CREATE TABLE orders (...);

部分字段的取值：
- orders.status：已取消、已完成、待支付
- orders.channel：APP、线上、门店

问题：上个月线上渠道取消了多少单？

「部分字段的取值」是状态、类型这类分类字段在库里实际有的值，prompt.values_from_db(conn) 能从库里现取。 不给也能用，但在没见过的库上会掉分（公交集 64.1% → 54.7%），因为模型得猜库里存的是 '已完成' 还是 'completed'。

最省事的是用数据集仓库里的 scripts/ask.py，建表语句、取值都从库里现读，库以只读方式打开，默认开出错重写：

python scripts/ask.py --db shop.sqlite --model Qwen/Qwen3-4B-Instruct-2507 --adapter YukiKaze1337/cn-sqlite-4b \
  --question "上个月线上渠道取消了多少单？"

用 transformers 自己调：

from peft import PeftModel
from transformers import AutoModelForCausalLM, AutoTokenizer
from prompt import build, values_from_db          # 数据集仓库 scripts/prompt.py

tok = AutoTokenizer.from_pretrained("YukiKaze1337/cn-sqlite-4b")
base = AutoModelForCausalLM.from_pretrained("Qwen/Qwen3-4B-Instruct-2507", torch_dtype="auto", device_map="auto")
model = PeftModel.from_pretrained(base, "YukiKaze1337/cn-sqlite-4b").merge_and_unload()
msgs = build(ddl, "上个月线上渠道取消了多少单？", values_from_db(conn))   # ddl 是建表语句，conn 是 sqlite3 连接
ids = tok.apply_chat_template(msgs, add_generation_prompt=True, return_tensors="pt").to(model.device)
print(tok.decode(model.generate(ids, max_new_tokens=512, do_sample=False)[0][ids.shape[1]:], skip_special_tokens=True))

用 Ollama / llama.cpp 跑 GGUF 时，系统提示要设成上面那句，用户消息照上面的格式拼。仓库公开后 Ollama 可以直接拉：

ollama run hf.co/YukiKaze1337/cn-sqlite-4b:Q4_K_M

量化版抽查过一道公交库的题：Q4_K_M 写出的 SQL 和 bf16 版一字不差，结果正确；完整评测没跑。

推理时补救（不用重训）

同一个模型、同一天评（数据集仓库的 scripts/infer.py，结果在 results/infer/）：

测试集	直接生成	出错重写	投票 + 重写
零售难题（100 题）	74%	77%	82%
城市公交（64 题）	62.5%	65.6%	64.1%
健身房（40 题）	92.5%	92.5%	95.0%
图书馆（40 题）	92.5%	92.5%	92.5%

• 出错重写：SQL 跑不通就把 SQLite 的报错原文发回给模型改，最多 2 次。能跑通的 SQL 从 89% 升到 94% 左右，只在跑不通时才多花时间
• 投票：贪心 1 条 + 采样 4 条，在你自己的库上执行，结果一样最多的那组胜出。难题集上比直接生成多对 9 题、多错 1 题（p = 0.021）； 公交集上没有比只重写更好。批量评测时慢 4 倍左右
• 两样都只看你自己库上的执行结果，不需要标准答案。ask.py 默认开出错重写，有 GPU 时再开投票
• 把握不够就不答：投票的一致程度能看出把握大小。两个难题集上，5 条全一致的答对 91%，3-4 条一致的 78%，2 条及以下只有 31%。 所以 ask.py 在少于 3 条一致、或者改完还跑不通时不给结果，只说明原因。这样少答约两成的题，给出去的错答案从 41 题降到 17 题。 全一致也会错（89 题里错 8 题），在没见过的库上更常见，所以结果最好还是有人看一眼

训练

• 底座：Qwen/Qwen3-4B-Instruct-2507（非思考模式）
• LoRA：r = 32，alpha = 64，全部线性层；bf16；只在 SQL 上算 loss
• 有效 batch 16，lr 2e-4 余弦，3 个 epoch，按长度分组，最长样本 2678 token
• 数据 10557 条，全部是合成数据，生成流程由作者设计：作者手写了 8 个业务库的表结构，制定了出题规范和筛选流程； 问题和 SQL 由 DeepSeek 按规范生成（31 个库，4-15 张表），再经过执行检查、独立重答比对、口语改写后复核等几道关卡筛选。 数据和筛选记录见 YukiKaze1337/cn-sqlite-sft
• 两个难题测试集（零售、城市公交）由 Claude 编写，没有参与训练数据的设计
• 一张 RTX 4090 上训了 2 小时 7 分钟

局限

• 只支持 SQLite 方言；RIGHT JOIN / FULL JOIN 被刻意排除在训练数据外（老版本 SQLite 不支持）
• 所有训练库和测试库都是合成的，表名列名大多是规整的英文，问题也比真实用户问得清楚。真实业务库上的效果没测过
• 复杂库上剩下的错，一半多是逻辑写错（一对多连接、时间顺序等），约三分之一是记错某列在哪张表（零售难题集剩下的 26 道错题里，逻辑错 14 道、列名错 8 道）
• 训练时最长的样本 2678 token；几十张表的大库会超出这个长度，需要先挑出相关的表
• 模型会照着问题写查询，不会说「这个库回答不了」

许可

模型跟底座走 Apache 2.0。训练数据由作者设计的流程生成（题目和 SQL 由 DeepSeek 生成），数据和代码 MIT。数据里没有真人信息。