350M 模型 100 步 GRPO 微调：结构化输出合规率从 22.6% 抬到 29.7%

LoRA 目标模块。LFM2.5-350M 是液态神经网络（Liquid AI 的混合注意力+卷积架构），所以模块命名与常规 Llama 不同：

LoraConfig(
    r=16, lora_alpha=32, bias="none", task_type="CAUSAL_LM",
    target_modules=[
        "q_proj", "k_proj", "v_proj", "out_proj", "in_proj",
        "w1", "w2", "w3",
    ],
)

可训练参数约 6M，占全模型 1.66%——在结构化输出这种“形式对齐”任务上，动这么点就够。这也是全流程能塞进 16GB 免费 GPU 的关键：不训主干、不改嵌入。

三条 reward 函数，都归一到 [0, 1]：

1. json_format_reward：能否被解析。要的形式（围栏 vs 裸 JSON）给满分 1.0；错形式但可解析给 0.2；完全解析不出来给 0.0。这个二档设计比“能解析就 1，不能解析就 0”要好——它显式惩罚“输出对但形式错”。
2. field_count_reward：顶层字段数是否对得上。exact match 给 1.0，差得越多线性衰减。这个直接对应“wrong item count”那类错。
3. schema_validation_reward：完整走一遍 JSON Schema 验证。计违反数、必填项没盖住的部分不给分。这是最重的一档。

加权比 [1.0, 0.5, 2.0]：schema 验证权重最高（合规率就是它），json_format 次之，field_count 最轻（因为它相对好学）。权重分配本身也是工程判断——如果你的下游对字段数极其敏感，就该抬 field_count 的权重。

训练参数：

GRPOConfig(
    learning_rate=5e-5,
    max_steps=100,
    warmup_steps=10,
    num_generations=8,             # 每个 prompt 组的采样数
    per_device_train_batch_size=4,
    gradient_accumulation_steps=8,
    max_completion_length=1024,    # 嵌套 JSON 要留空间
    temperature=1.1,               # 多样性采样
    beta=0.01,                     # KL 惩罚，防止漂离基础模型
    reward_weights=[1.0, 0.5, 2.0],
)

100 步、500 条数据、免费 GPU——总算力开销小到可以在一次咖啡时间里跑完。GRPO 每步会给每个 prompt 采 8 条 completion，用 reward 排序算相对优势，KL 惩罚（beta=0.01）把偏移拉住。

结果的信号在细分里，不在总分里

训好之后同一套 llama.cpp 栈复测：

看总分是 7 个点的稳步涨幅，看细分能一眼看出训哪儿涨哪儿——JSON 和 Bare list 都涨了 13 个点以上，正对着前面数据增强动的那两处；YAML 几乎没动（训练数据里没针对 YAML 增强）；Wrapper key 微涨（原本就相对好）。这是一次训练目标非常清晰的对齐。

实体粒度也一样能对上：test__event_ticket_booking 从 45.8% 涨到 57.9%，log_parser_examples 从 29.2% 涨到 45.8%，rental_car_booking 从 34.2% 涨到 46.8%。而低分类目里，test__recipe 只有 4.3% 的起点，训练后仍旧是尾部——本轮增强没覆盖到“复杂嵌套配料表”这类 schema，指望它自动涨是幻觉。

但也别只报好消息

有两处细节这篇教学没回避，值得复述：

没超过大模型。GRPO 之后的 350M 是 29.7%，IFStruct 官方榜里 Qwen3.5-2B 是 33.15%。“逼近”不等于“超越”——如果你的产线对合规率要求是 95%+ 那种硬指标，350M+GRPO 也顶不上单机部 2B/7B 的一次调 API。这篇教学的价值不是“用 350M 替代 2B”，是“在受限硬件/延迟预算里，把小模型往上抬到值得考虑的位置”。

有些错反而涨了。GRPO 后 required field missing 从 7228 变成 7331，wrong item count 从 738 变成 890，还多出来 102 例“该给数组给了 wrapper”——这类是过度矫正带来的新错。reward 权重把 schema 抬到 2.0 之后，模型更倾向于“猜出更多字段”，结果里错必填的绝对次数没降，甚至微升。这不是失败，是提醒：单一 reward 权重是全局配置，会同时移动多个错误类型的曲线，做产品的人要预留一轮回归看新错分布，不能只看总分。

这个闭环为什么值得抄

把上面几段拼起来，你会看到一个和“再拿更大模型试一下”完全不同的做法：

1. 基线不是别人报的分，是你自己的服务栈跑出来的分。同一套 llama.cpp + BF16 GGUF，训练前跑一次，训练后跑一次，中间不换环境。这一条就能挡掉大部分“我训了但看不出提升”的乌龙——多半是 eval 换栈了。
2. 错误分布决定训练目标。少填、错数、错顶层结构——不同的错误对应不同的数据增强策略。不看 base 错误就动手做数据，等于蒙眼训练。
3. 数据增强用比例混，而不是整包换。40% 加围栏、20% 改数组、剩下 40% 保持原样——每一档都对准一类错，同时保住原分布不塌。
4. 奖励函数按“能不能上线”的粒度写。能解析、字段数、schema 通过——三档从粗到细覆盖真实故障，权重按项目痛点调。
5. 训练规模匹配任务。100 步、500 样本、6M 可训参数——形式对齐用不着大动干戈，动多了反而砸掉本来能答对的部分。这也是为什么用 GRPO 而不是全量微调：形式对齐是“教它按模具倒”，不是“教它一件新事”。

对于产线里已经用小模型（3B 以下）做结构化抽取的团队，这套流程可以直接搬：把你的 schema 拿出来做 IFStruct 风格的评测集（哪怕只有 200 条起手），跑一次基线，把错误分布贴到 issue 里对着看，一周之内就能把合规率抬 5-10 个百分点。省下的算力和延迟预算，够你把更贵的推理能力留给真正需要推理的环节。

复现要点

跑一遍教学作者需要的最少条件：

• 一台带 GPU 的机器：训练 16GB 显存起（Colab/Kaggle 免费档合格），评测在 M 系列 MacBook 也能跑（llama.cpp 走 Metal 后端）。

• 依赖：uv（Python 环境）、llama.cpp（模型服务）、TRL/PEFT/Transformers。

• 代码与数据：训练 notebook 在 Liquid4All/cookbook；IFStruct 评测器在 Liquid4All/ifstruct；训练数据 nvidia/Nemotron-RL-instruction_following-structured_outputs；基础模型 LiquidAI/LFM2.5-350M-GGUF。

• 训练后合并 LoRA + 转 GGUF：trainer.model.merge_and_unload() → save_pretrained → python llama.cpp/convert_hf_to_gguf.py ... --outtype bf16，之后就能挂回 llama-server 复测。

从“看不见的合规率”到“看得见、可复现、能对着错误清单调”的工程闭环——这才是这篇教学里最耐得住抄的一段。