大模型微调入门

这篇适合谁、读完能做到什么

这篇适合已经用提示词或 RAG 做过原型、但效果还不够稳定的开发者。读完你能判断自己的场景要不要微调，知道一次微调需要哪些条件，并能按照 Microsoft Foundry 的流程准备数据、选择训练技术和基础模型，再评估结果。^[1]

微调是什么，和提示词、RAG 有什么不同

提示工程和 RAG 都是通过改变输入的提示，来提升模型的回答质量。微调换了一个思路：用额外的数据重新训练模型本身。^[1]

大模型先在大量文本上完成预训练。微调就是拿一个预训练模型，用一组精心挑选的示例对它重新训练，让它在某个任务或领域里更准确、更贴切，得到一个定制模型。^[1]

少样本提示（few-shot）是在提示里放入几个示例。它有两个限制：模型的 token 上限会限制能放进去的示例数量；每条提示都带上示例，token 费用也很高。微调的一个附带好处，是减少提示里需要的示例，从而节省 token 用量和相关成本。^[1]

这里说的微调是监督式微调（supervised fine-tuning），即加入模型此前训练数据里没有的新数据来重新训练。^[1]

什么时候值得微调

微调是一项高级技术，需要一定的专业能力。做得不对，可能没有效果，甚至会让模型在目标领域的表现变差。^[1] 所以在动手之前，先回答几个问题：^[1]

1. 用例：你希望改进模型的哪个方面？^[1]
2. 替代方案：提示工程和 RAG 试过了吗？先用它们做一个基线，作为比较的对象。^[1]
3. 成本：模型是否可以微调；准备训练数据、评估和改进模型需要多少人力；运行训练和部署需要多少算力；以及能否找到足够质量的示例数据。^[1]
4. 收益：微调后的效果能否超过基线；能否通过简化提示来减少 token 用量；基础模型能否复用到新的领域。^[1]

只有收益大于成本，微调才值得做。^[1] 决定做之后，还需要四样东西：一个预训练模型、一个数据集、一个运行微调任务的训练环境，以及一个用来部署微调后模型的托管环境。^[1]

在 Microsoft Foundry 上微调

Microsoft Foundry 是在 Azure 上微调、部署和管理定制模型的地方，它整合了原来的 Azure OpenAI Studio 和 Azure AI Studio。^[1] 它使用 LoRA（低秩适配）来高效地微调模型，训练比重新训练所有权重更快，也更省钱。^[1]

按下面的顺序做选择，可以把一次微调任务理清楚。

1. 选择训练技术。Foundry 支持三种：监督式微调（SFT）、直接偏好优化（DPO）和强化微调（RFT）。通常先从 SFT 开始，它覆盖的场景最广。^[1] - SFT 用输入和输出的示例对来训练，是大多数任务的默认选择，适合领域专业化、风格和语气、遵循指令等场景。^[1] - DPO 从「更好」和「较差」的回答对中学习，让输出更符合人的偏好，适合手上有对比反馈的场景。^[1] - RFT 用评分器给出的奖励信号，借助强化学习优化复杂的行为，适合数学、化学、物理这类有明确对错的推理任务，但需要更多的机器学习经验。^[1] 2. 选择训练层级。标准（Standard）层级在你的资源所在地区训练，并保证数据驻留，适合数据必须留在特定地区的情况。全球（Global）层级利用本地区之外的容量，排队更快、费用更低，数据和权重会被复制到训练地区。开发者（Developer）层级费用最低，使用空闲容量，没有延迟和服务等级保证，任务可能被抢占后再恢复，适合做实验。^[1] 3. 选择基础模型。可微调的模型包括 OpenAI 的 gpt-4o-mini、gpt-4o、gpt-4.1 系列、o4-mini 和 gpt-5，以及 Ministral-3B、Qwen-32B、Llama-3.3-70B-Instruct、gpt-oss-20b 等开源模型。不同模型支持的方法、地区和可用性各不相同，动手前应以官方的微调模型列表为准。^[1] 4. 选择使用方式。Foundry 有两种：无服务器（serverless），按用量计费，不需要管理 GPU 配额，适用于 OpenAI 和部分指定模型；托管计算（managed compute），可以通过 Azure Machine Learning 自带虚拟机，模型范围最广。多数人应先从无服务器开始。^[1]

准备数据和训练的注意事项

• 先建基线。微调前，先用提示工程和 RAG 测量基础模型的效果，才能证明微调确实带来了提升。^[1]
• 先小后大。先用 50 到 100 条高质量示例验证思路，正式上线时再增加到 500 条以上。质量比数量重要，低质量的示例应该删掉。^[1]
• 文件格式要对。训练文件和验证文件必须是 JSONL 格式、UTF-8 编码并带 BOM，单个文件不超过 512 MB，并使用 chat-completions 的消息格式。一定要准备验证文件，以便观察是否过拟合。^[1]
• 推理时保持系统消息一致。调用模型时，使用的系统消息应与训练时相同。^[1]
• 不要盲目部署最后一个检查点。Foundry 会保留最后三个 epoch 作为可部署的检查点，要通过 train_loss、valid_loss 和 token 准确率，挑出泛化最好的那一个。^[1]
• 成本和质量一起看。和基线比较时，要同时衡量 token 成本和输出质量。^[1]
• 可以继续微调。对于 OpenAI 模型，支持在已经微调过的模型上，用新数据继续微调。^[1]
• 留意托管费用。部署的定制模型按小时计费，不活跃的部署会在 15 天后被删除。不需要的部署应及时清理。^[1]

常见问题

如果微调后效果不如预期，常见原因之一是数据量或质量不够，另一个是没有基线可比。这是根据前面的建议推出的判断，不是官方的排错指南。^[1]

文中的模型列表、地区和用量数字会随平台更新而变化，动手前请以 Foundry 官方文档为准。^[1]

动手实践的几个选择

可以跟着做的实操资源包括：OpenAI 的 cookbook 中有「如何微调聊天模型」的示例，以一个食谱助手为例，涵盖准备训练数据、运行微调任务和推理。^[1] Microsoft Foundry 的「用微调定制模型」示例，在 Azure 上用 gpt-4.1-mini 完成上传训练和验证数据、运行任务、部署使用的全过程。^[1] Hugging Face 的一篇文章则使用 transformers 库和 TRL（强化学习训练库），在公开数据集上微调 CodeLlama 7B 这样的开源大模型。^[1]

如果你更想少写代码，可以看 AutoTrain。它是 Hugging Face 的 Python 库，也是一个无代码方案，可以在自己的云、Hugging Face Spaces 或本地运行，支持网页界面、命令行和 YAML 配置文件。^[1] Unsloth 则是一个开源框架，支持大模型微调和强化学习，并提供可直接使用的 notebook。^[1]

下一步

选一个实操资源完整走一遍，比只读概念更能看出微调的代价和收益。之后再回头看自己的数据，判断是否真的需要微调。^[1]

本文改编自 Microsoft 开源课程《Generative AI for Beginners》第 18 课^[1]，原文以 MIT 许可证发布。