模型选择与训练实战

发布于 2025-09-23 分类: AI
系列文章: GRPO实战指南
第 1 部分: 从“代码补全”到“逻辑优化” 第 2 部分: 定义问题，项目成功的第一步 第 3 部分: GRPO的数据集，告别“标准答案” 第 4 部分: 奖励函数，模型能力的“铸魂师” 第 5 部分: 模型选择与训练实战 (当前) 第 6 部分: 评估、迭代与总结

第四步：模型选择与训练——启动“学习引擎”

我们已经完成了所有“运筹帷幄”的准备工作：定义了清晰的目标、准备好了独特的“原料”（数据集）、并精心设计了模型的“导航系统”（奖励函数）。现在，是时候进入“决胜千里”的实战阶段了——选择合适的模型，并启动训练引擎。

这一步看似是纯粹的工程操作，但其中依然充满了需要权衡的“艺术”和值得深思的“科学”。

1. 选择基础模型的重要性：GRPO是“因材施教”，而非“无中生有”

很多人会犯一个想当然的错误。认为：“既然强化学习如此强大，能够从零开始训练AlphaGo，那么它也应该能把一个普通的语言模型教会如何写SQL吧？” 于是，选择了一个通用的、未经过任何代码指令微调的基础模型（例如 Llama-7B 的原始版本）作为起点。

结果是灾难性的。

  • 教训：我们训练进行了数万步后，沮丧地发现，模型生成的SQL绝大多数仍然是语法破碎的“胡言乱语”。更糟糕的是，它在 <think> 标签中生成的“思考过程”也常常是颠三倒四、毫无逻辑的文字组合。模型似乎连最基本的SQL语法结构和关键字都难以掌握，更不用提什么查询优化了。

这次失败给了我们一个极其深刻的核心启示：
GRPO 不是“无中生有”的魔法，而是“因材施教”的催化剂。

它的核心作用是**“激发” (Elicit)** 模型在预训练阶段已经学到的潜在能力，并将其引导、强化到我们期望的方向上，而不是**“教会” (Teach)** 它一个全新的、从未接触过的技能。

  • 类比：你可以通过强化学习，把一个会下棋但水平普通的棋手，训练成世界冠军。但你很难通过同样的方法，教会一个从未见过棋盘的人什么是“将军”。
  • 对于我们的任务：如果你的基础模型在海量代码语料的预训练中，已经内化了SQL的语法、常见模式和一定的逻辑推理能力，那么GRPO就能有效地激发这些能力，并教会它如何“优化”。但如果基础模型连 SELECT ... FROM ... WHERE 的基本结构都没怎么见过，那么GRPO的奖励信号就像对牛弹琴，模型根本无法理解这些反馈的意义。

最终选择：吸取教训后，我们果断放弃了通用模型。我们转向了那些本身就为代码任务而生的模型，例如 CodeLlama, Qwen-Code, DeepSeek-Coder 等。这些模型在其预训练或指令微调阶段，已经“消化”了大量的代码数据，具备了强大的代码理解和生成能力。经过一系列实验对比，我们最终选择了 Qwen1.5-7B-Chat（在其发布后，Qwen2-7B-Instruct 成为更好的选择，因为它在代码和逻辑上更强）作为我们的基础模型。事实证明，这是一个至关重要的正确决策。

2. 训练过程详解：工具与技术的协同作战

要在有限的硬件资源上高效地进行GRPO训练，我们需要一个强大的工具组合。

graph TD
    subgraph "硬件层"
        A["消费级显卡 (e.g., RTX 3090/4090)"]:::hardware
    end

    subgraph "优化库"
        B[Unsloth]:::library
    end

    subgraph "训练框架"
        C["TRL (Transformer Reinforcement Learning)"]:::framework
    end

    subgraph "高效微调技术"
        D[QLoRA]:::tech
    end

    subgraph "基础模型"
        E[Qwen1.5-7B-Chat]:::model
    end

    A --> B;
    B --> C;
    C --> D;
    D --> E;
    C -- 调用 --> B;
    C -- 集成 --> D;
    D -- 应用于 --> E;

    %% 为增强对比度和可读性定义的样式
    classDef hardware fill:#f2f2f2,stroke:#555,stroke-width:2px,color:black
    classDef library fill:#e6ffed,stroke:#28a745,stroke-width:2px,color:black
    classDef framework fill:#d1ecf1,stroke:#0c5460,stroke-width:2px,color:black
    classDef tech fill:#fff3cd,stroke:#856404,stroke-width:2px,color:black
    classDef model fill:#f8d7da,stroke:#721c24,stroke-width:2px,color:black

  • TRL (Transformer Reinforcement Learning)：这是 Hugging Face 官方推出的、用于大模型强化学习的明星库。它将复杂的RL算法（如PPO，以及我们使用的GRPO）封装得非常易用，让我们不必从头实现复杂的数学逻辑，可以专注于奖励函数和训练流程本身。TRL是我们的“主引擎”。

  • Unsloth：这是一个令人惊艳的第三方库。它的核心价值在于通过底层优化（例如手动实现 Flash Attention 等技术）极大地降低了训练时的显存消耗和计算时间。根据其官方数据，它能让训练速度提升2倍，显存占用减少60%。这意味着，原本需要A100专业卡的训练任务，现在可能在单张RTX 3090或4090上就能跑起来。

    • 注意事项：虽然Unsloth非常强大，但作为第三方库，它有时可能存在一些兼容性问题或bug。例如，我们在实践中遇到过，用Unsloth保存的模型权重，无法被标准的transformers库直接加载，需要进行一些额外的转换。在使用时需要留意其文档和社区的最新动态，权衡其带来的性能优势和潜在的稳定性风险。

  • QLoRA (Quantization and Low-Rank Adapters)：这是一种极为高效的参数微调技术。它的思想是：冻结基础模型的绝大部分（超过99%）参数，只在一部分关键层（如注意力层）旁边增加一些小小的、可训练的“适配器”层。同时，它还对模型的主体参数进行4-bit量化，进一步压缩显存。通过QLoRA，我们将训练一个70亿参数模型的显存需求从几十GB降低到了10GB左右，使其在消费级硬件上成为可能。

核心参数：num_generations

在TRL的GRPOConfig中，有一个至关重要的参数：num_generations。我们将其设为8。

  • 含义：这告诉训练器，在每一步中，针对同一个prompt，模型需要生成8个不同的SQL变体。
  • 作用：这8个答案构成了一个临时的“学习小组”（Group）。奖励函数会给这8个答案打分，GRPO算法就在这个小组内部进行比较和学习。例如，如果8个答案中有2个获得了高分（比如90+），6个得了低分（比如0或40），模型就会学到：“哦，要尽量生成那2个高分答案的特征，避免生成那6个低分答案的特征。”
  • 权衡：num_generations 的值越大，提供给模型的学习信号就越丰富、越稳定，但相应地，训练速度也会成倍下降，因为每一步的生成和评估成本都增加了。8 是一个在效果和效率之间较为理想的平衡点。

3. 观察训练过程：从“胡言乱语”到“逻辑清晰”

训练大模型绝不是点击“运行”然后去喝咖啡那么简单。持续地、批判性地观察模型在训练过程中的实际产出，是至关重要的调试手段。 我们编写了回调函数，在每隔几百步训练后，就随机抽取一个验证集中的prompt，让当前的“学生”模型生成一个答案，并将其记录到日志中。

通过这些日志，我们能清晰地看到模型的“心智”成长过程：

  • 训练初期 (Steps 0-1000)：

    • <think>：胡言乱语，或简单重复问题。
    • <code>：生成的SQL常常有低级语法错误，如关键字拼错 (SEELCT)，括号不匹配。或者出现“幻觉”，凭空捏造出Schema中不存在的表名或字段名。
    • 奖励得分：绝大部分为0。

  • 训练中期 (Steps 1000-5000)：

    • <think>：开始能正确地识别出需要用到的表和字段，但逻辑规划比较简单、直接。
    • <code>：能生成语法正确、可以执行的SQL了。这是巨大的进步！但它的写法通常是比较朴素、效率不高的，例如，倾向于使用多层嵌套子查询，而不是更高效的JOIN。
    • 奖励得分：开始稳定地获得40分左右的correctness_reward，但efficiency_reward普遍不高。

  • 训练后期 (Steps 5000+)：

    • <think>：思考过程变得非常“有见地”。我们惊喜地发现，日志中开始出现这样的句子：“为了提高查询效率，我将使用 INNER JOIN 来连接 products 和 sales 表，而不是在 WHERE 子句中使用嵌套查询。” 或者 “约束条件禁止使用子查询，因此我将使用 Common Table Expression (CTE) 来分步处理逻辑。”
    • <code>：生成的SQL变得更加优雅、高效。它学会了使用JOIN，学会了遵循约束，甚至在某些情况下，生成了比我们人类最初设想的“黄金SQL”更简洁的查询。
    • 奖励得分：高分（80分以上）的样本比例显著增加。

这种持续的观察，不仅让我们对训练过程充满信心，也为我们提供了最直观的反馈。它让我们真切地感受到，模型不是在机械地“拟合”数据，而是在奖励信号的引导下，真正地“学习”和“理解”如何进行逻辑推理和查询优化。

当训练的损失曲线收敛，日志中充满了高质量的输出时，我们的“学习引擎”就可以暂时停下来了。接下来，我们将进入最后一步：用严格的、客观的评估来检验我们这位“毕业生”的真实水平。

-- 感谢阅读 --