Hugging Face：100步 GRPO 微调，让350M小模型的结构化输出通过率提升至29.7%

Hugging Face 社区发布可复现指南，展示用约500条样本和100步 GRPO 微调，使 Liquid AI 的 350M 模型 LFM2.5-350M 在 IFStruct 基准的结构化输出通过率从22.6%提升到29.7%。该方法以 LoRA + GRPO 对结构合规性进行奖励优化，显著改善 JSON 和顶层数组场景，但对 YAML 则变化有限，提示小模型在可验证任务上能用低成本微调获得实用改进。

Hugging Face 社区近日发布一份可复现的微调指南，展示如何用约500个训练样本和100个 GRPO 步骤，改善 Liquid AI 旗下 3.5亿参数模型 LFM2.5-350M 的结构化输出能力。在该指南采用的相同本地推理环境中，模型在 IFStruct 基准上的通过率从22.6%升至29.7%，提升7.1个百分点。

这项工作并不是发布一个新的基础模型，也不是声称重新实现了 Liquid AI 官方训练出的强化学习版本。文章的作者 Leonie Monigatti、Ben Burtenshaw 和 Sergio Paniego 将其定位为一套面向小模型的公开实验配方：当任务有清晰、可程序化验证的目标时，开发者是否能用有限的计算资源，对模型进行有针对性的强化学习微调。

结构化输出为何成为独立的模型能力

对于许多企业应用而言，模型能否生成一段内容只是第一步。下游系统还需要确认它返回的是可解析的 JSON 或 YAML，字段名称和类型正确，数组数量符合要求，并且没有混入额外说明。任何一个环节出错，都可能让自动化流程无法继续。

Liquid AI 发布的 IFStruct 基准正是为了测量这类能力。它不主要判断内容是否有创意或事实是否正确，而是逐项检查模型是否遵守输出格式、顶层结构、字段数量、枚举值、数值范围和嵌套结构等要求。测试题覆盖 JSON 和 YAML，也会要求模型处理代码块、禁止额外评论以及字符串转义等常见问题。

IFStruct 的开源仓库将一次通过定义为严格的二元结果：只要有一项约束不满足，样本就算失败。测试集包含2000个样本，题目来自24类实体，包括食谱、发票、临床试验、旅行安排以及需要处理转义字符的代码和日志场景。

这与依赖约束解码的方案有所不同。约束解码可以在生成阶段帮助模型产生语法有效的内容，却不能保证模型选择了正确字段、满足数量要求，或者理解了提示中以自然语言表达的结构约束。因此，IFStruct试图把“格式是否可用”从更宽泛的推理和抽取能力中单独分离出来。

训练配方把奖励直接对准格式错误

这份 Hugging Face 指南使用 LFM2.5-350M 作为基础，并通过 LoRA 训练约600万个参数，约占模型规模的1.66%。训练数据来自 NVIDIA 发布的结构化输出指令数据集，规模约500条。由于训练数据与 IFStruct 的评测分布并不完全相同，作者又对部分提示进行了改造：约40%的样本增加了代码块要求，另有一组不重叠的样本被改造成顶层数组任务，以覆盖裸数组和项目数量遵循等情况。

奖励函数没有试图评价答案内容是否“好”，而是围绕结构合规性设计了三项指标：

• json_format_reward 检查输出能否解析，以及是否采用题目要求的代码块或原始格式；
• field_count_reward 检查顶层字段数量是否准确；
• schema_validation_reward 根据 JSON Schema 检查字段、类型、枚举值、数值范围和嵌套结构。

三项奖励按1.0、0.5和2.0的权重合并。训练使用 Hugging Face 的 TRL 库和 GRPO Trainer，设置每组生成8个候选答案，运行100步，并在一张可使用16GB显存的 GPU 上完成。LoRA 适配器随后被合并回模型，保存为可以进一步转换成 GGUF 的完整检查点。

GRPO，即 Group Relative Policy Optimization，会针对同一提示生成一组回答，再根据回答之间的相对奖励计算更新方向。它不需要单独训练一个奖励模型，适合答案可以由规则或程序验证的任务。Hugging Face 的 TRL GRPO 文档将其描述为一种在线学习方法：模型持续生成自己的回答，并在奖励函数指导下调整策略，同时可以用 KL 惩罚限制模型偏离参考策略的幅度。

JSON提升明显，YAML几乎没有变化

作者首先用 llama.cpp 在本地运行 BF16 版本的 LFM2.5-350M，并对 IFStruct 的全部2000个样本进行评测。结果是452个样本通过，通过率22.6%。这一结果略高于 Liquid AI 官方 IFStruct 文章公布的21.1%，但指南强调，两者使用的评测服务和运行设置不同，因此更适合把22.6%视为本实验的基线，而不是对官方数字的修正。

完成 GRPO 微调后，模型通过594个样本，通过率升至29.7%。变化并不平均：

这些结果与训练目标基本一致。训练重点加入了 JSON 代码块和裸数组任务，因此 JSON 和顶层数组的提升尤其明显；YAML 得分几乎没有变化，说明这次训练更多是在强化特定格式和结构模式，而不是普遍提高所有结构化输出能力。

从绝对表现看，29.7%仍意味着多数测试样本没有完全满足要求。错误数量最多的项目仍包括缺少必需字段、项目数量错误和类型不匹配。换句话说，微调让模型更可靠，但尚未让它成为可以不经检查接入生产系统的结构化输出引擎。

小模型路线的价值与边界

这项实验最重要的信号，可能不只是通过率提升，而是训练成本和任务范围之间的关系。模型只有350M参数，训练样本约500条，训练步数100步；评测则可以使用配合 llama.cpp 的本地机器完成。这降低了开发者针对某一类下游任务进行定制的门槛。

LFM2.5-350M 的官方模型页将其定位为适合设备端部署的混合架构模型，支持32,768个 token 的上下文长度，并提供 Transformers、vLLM、llama.cpp、MLX、ONNX 等多种运行路径。Liquid AI 建议将它用于数据抽取、结构化输出和工具调用，但不建议把它作为知识密集型任务或编程任务的通用模型。模型信息可在 LFM2.5-350M 的 Hugging Face 页面查看。

这也解释了为什么结构化输出是一个适合小模型微调的切入点：它的目标相对窄，错误可以被明确分类，奖励可以由解析器和 Schema 验证器直接给出。与要求模型掌握开放领域知识相比，模型需要学习的是一组更具体的输出习惯。

但这并不意味着小模型可以简单替代大模型。IFStruct只检查结构，不检查事实、语义和内容质量。一个模型可能返回字段齐全、格式合法的 JSON，却填入错误信息。官方基准也承认，若只针对结构分数进行强化学习，训练过程最好同时加入内容质量或事实正确性的奖励，否则模型可能学会“通过验证器”，而不是完成完整任务。

近期 AIFlux 对 Hugging Face 使用 TRL 与 OpenEnv 训练代码绘画模型的报道，也显示了同一条技术路线的另一面：GRPO可以把环境反馈转化为奖励，但最终学到什么，取决于奖励函数、训练数据和评测环境如何定义目标。结构化输出的规则较为清晰，而主观创作任务的奖励则更容易受到评分器和参考数据的影响。

评测分数还需要更多验证

这份指南的结果来自一次短程、任务专用的实验，不应直接外推为 LFM2.5-350M 在所有结构化输出场景中的能力提升。首先，训练数据来自 Nemotron 的结构化输出指令集合，评测则使用 IFStruct；二者分布不同。其次，文章只报告了同一评测集上的前后结果，没有显示跨领域数据、不同采样温度或重复训练运行的方差。

AIFlux 对 BenchMIRT 的报道所讨论的正是这类问题：一个总分可能混合多个能力信号，题目构成和评测方式会影响人们对分数的解释。对本次实验而言，后续更值得关注的不是29.7%这个单独数字，而是模型在哪些约束类型上取得了进步，以及这种进步是否能迁移到真实企业数据、真实工具调用和未见过的 Schema。

目前仍有几个问题没有答案：更大的训练集是否会继续提高通过率，还是会导致模型过拟合；加入内容质量奖励后，结构合规性是否会下降；不同 JSON Schema 复杂度下的增益是否一致；以及同一套 LoRA 适配器能否同时服务于数据抽取、工具调用和多轮代理任务。

这项公开配方的意义因此较为具体：它没有证明“350M模型已经解决了结构化输出”，却证明了小模型在一个边界清楚、可验证的任务上，可以通过少量数据和短程 GRPO 微调获得可测量的改善。对于需要在本地设备或低成本 GPU 上运行模型的开发者而言，真正的机会或许不在追逐一个更大的通用模型，而在于先把最容易验证、最直接影响系统可靠性的那一小段能力训练好。

来源：Hugging Face 社区文章《Fine-tuning a 350M Model for Better Structured Outputs in 100 GRPO Steps》；Liquid AI《IFStruct: Measuring structured-output compliance》；Liquid4All/ifstruct 开源仓库。