如何在 2026 年微调 LLM

Akshay 🚀 (@akshay_pachaar) 2026-03-04 D 原文
EN Markdown

每个用 LLM 构建产品的团队，迟早都会撞上同一堵墙。

你写了详细的系统提示词，加了 few-shot 示例，调了 temperature，但你的 agent 仍然有 30–40% 的时候会做错。

最糟的是？它永远不会从这些错误里学习。

微调就是你突破这堵墙的方式。

如果你在使用 GPT 或 Claude，你用的是和所有人一样的模型：能力一样，成本一样，也没有竞争优势。

但如果你拿一个小型开源模型，在你的特定任务上微调呢？它可以超过一个体量大 100 倍的模型，而且成本和延迟都只是后者的一小部分。

大多数开发者一想到微调，就会联想到一套痛苦的准备工作：整理数据集、标注输出、手写奖励函数。

到了 2026 年，情况已经不是这样了。

使用 GRPO 和 RULER 的现代微调，已经改变了可能性的边界。现在，你可以训练出真正能通过经验改进的 agents，而不需要写任何奖励函数，也不需要收集任何带标签样本。

这篇文章会一步步讲清楚具体怎么做。

SFT 与强化微调

大多数开发者都知道监督微调（Supervised Fine-Tuning，SFT）。你收集输入—输出对，然后让模型学习模仿它们。

问题是，SFT 教模型的是该说什么，不是怎样成功。

对于会搜索、调用 API、跨多个步骤推理的 agents 来说，单纯模仿还不够。你想要的是通过试错来改进。

可以这样理解：

  • SFT = 读教材（记住已知问题的答案）
  • RL = 在岗训练（从试错和反馈中学习）

这就是强化微调（Reinforcement Fine-Tuning，RFT）。你给模型一个奖励信号，然后让它自己发现最好的策略。

GRPO 如何工作

那么，这背后的算法是什么？

GRPO（Group Relative Policy Optimization，组相对策略优化）是当下最流行的 RFT 算法。DeepSeek-R1 的推理能力背后，用的就是同一个算法。

核心思想很简单。GRPO 不训练一个单独的模型来给回答打分，而是生成多个 completion，并让它们彼此相对评分。

对每个 prompt，它的工作方式如下：

  1. 采样一组： 从当前模型生成 N 个 completion
  2. 给每个结果打分： 奖励函数评估每次尝试
  3. 在组内归一化： 计算相对于组平均值的相对优势
  4. 更新模型： 强化高于平均水平的行为，抑制低于平均水平的行为

GRPO 只需要相对排序，不需要绝对分数。completion 得分是 0.3、0.5、0.7，还是 30、50、70，并不重要。驱动学习的只有排序。

ART：Agent Reinforcement Trainer

GRPO 很强大，但你要怎样把它真正应用到一个现实世界里的 agent 上？

ART（Agent Reinforcement Trainer）是一个由 OpenPipe 开源的 100% 开源框架，它把 GRPO 带到了任何 Python 应用里。

大多数 RL 框架都是为简单的聊天机器人交互构建的：一个输入，一个输出，任务结束。真实的 agents 从根本上不同。它们会搜索文档、调用 API，并在给出答案之前跨多个步骤推理。

ART 正是为此而构建的。它提供：

  • 对工具调用和多轮对话的原生支持
  • 与 LangGraph、CrewAI 和 ADK 的集成
  • 训练期间高效利用 GPU

架构

ART 分成两部分：Client 和 Backend。

Client 是你的 agent 代码所在的地方。它向 backend 发送推理请求，并把每个动作记录进一条 Trajectory，也就是一次 agent 运行的完整历史。

Backend 是繁重工作发生的地方。它运行 vLLM 来做快速推理，并使用 Unsloth 驱动的 GRPO 来训练。每完成一个训练步骤，一个新的 LoRA checkpoint 就会自动加载到推理服务器里。

完整训练循环是这样的：

  1. Client 发送推理请求
  2. Backend 生成模型输出
  3. Agent 在环境中采取行动（工具调用、搜索等等）
  4. 环境返回奖励
  5. Trainer 通过 GRPO 更新模型
  6. 新的 LoRA checkpoint 加载到推理服务器
  7. 重复，每个循环都会让模型比之前好一点

RULER：不再手写奖励函数

这是大多数人最害怕的部分。

定义一个好的奖励函数，一直是 RL 里最难的部分。训练一个邮件 agent，需要带标签的正确答案。训练一个代码 agent，需要测试套件。每一种都是独立的工程项目。

RULER（Relative Universal LLM-Elicited Rewards）完全消除了这个瓶颈。它使用 LLM-as-judge 来比较多条 agent 轨迹，并对它们排序，不需要任何带标签数据。

它之所以有效，是因为两个关键洞察：

  • 让 LLM “给这个结果打 0–10 分”，会产生不一致的结果
  • 问“这 4 次尝试里，哪一个最成功地达成了目标？”要可靠得多

而且既然 GRPO 只需要相对分数，绝对值本来就不重要。

这个过程分三步：

  1. 为一个场景生成 N 条轨迹
  2. 把它们交给一个 LLM judge，由它给每条轨迹打 0 到 1 分
  3. 在 GRPO 中直接把这些分数作为奖励使用

不用写奖励函数。也不用收集带标签数据。

放在一起：一个实践示例

我做了一个完全可运行的 notebook，用 ART 通过强化学习训练一个 3B 模型，让它掌握如何使用任意 MCP server。

只要提供一个 MCP server URL，这个 notebook 就会：

  1. 查询这个 server 的工具
  2. 生成一组会使用这些工具的输入任务
  3. 使用自动 RULER 评估，在这些任务上训练模型

你可以在 ART 的 GitHub repo 里找到更多示例，用来改造并开始上手。

仓库链接 →

（别忘了点 star 🌟）

感谢阅读！