目标：让结构化输出在未见过的说法上更稳。泛化不是玄学，是「覆盖 + 消歧 + 约束」的工程问题。文中规则与样例均为示意，不对应真实业务语料。

为什么「只靠再训几轮」往往不够

轮数增加主要加强记忆与收敛；对「近义混淆 / 覆盖不足 / 格式漂移」帮助有限。更有效的组合通常是：

1
2
3
模型能力（SFT + LoRA）
    + 消歧数据与统一 schema
    + 推理侧校验 / 修复

把 100% 理解成「生产链路对结构化请求的可靠交付」，而不是「裸模型在任意开放域永远完美」。

第一层：统一 schema 与提示

  1. 维护一份合法枚举表（类别 → 允许取值）；
  2. system 提示与数据标签使用同一套拼写；
  3. 对易混对写清规则（抽象示意）：
1
2
3
标签 A ≠ 标签 B：
- 表达族 X → A
- 表达族 Y → B

第二层：消歧与对比样本（仍保留互斥验证）

为易混标签构造成对样本：相近说法映射到正确且不同的结构化结果。
注意：补充的是新说法，不要直接污染验证集原句，否则「泛化」再次变成「背题」。

第三层：推理侧后处理

推荐流水线：

1
2
3
4
5
6
用户输入
  → 模型生成（低温度）
  → 尝试解析 JSON
  → schema 校验 / 别名归一化
  →（可选）与轻量语义规则对齐，仅在高置信冲突时纠偏
  → 输出合法结构化结果或走拒答 / 追问

设计要点：

  • 优先信任合法的模型 JSON；规则用于兜底与少数高混场景；
  • 避免误伤开放文本：仅在「确认是结构化意图」或「模型已输出疑似 JSON」时介入；
  • 规则应可配置、可单测；每加一条规则都要测误触发。

第四层：评估要报告两行数字

指标 含义
模型原始结构化匹配率 纯模型能力
后处理后匹配率 生产链路能力

两者都要看：只报后者会掩盖模型弱点；只报前者会低估可上线质量。

工程落点（示意）

仓库中可拆成：

  • action_schema 一类模块：枚举、校验、归一化、规则；
  • infer：生产推理入口（默认启用后处理）；
  • test_model：评估时可开关后处理，并分别统计。

具体实现以你的代码库为准；此处不粘贴业务规则全文。

小结

泛化不是玄学，是「覆盖 + 消歧 + 约束」的工程问题。

语言模型微调实战第 08 篇完。下一篇收束到部署产物、复盘清单与可继续探索的方向。