微调——在自定义数据集上训练现有基础模型以改变其行为——通常是当通用LLM没有做完全符合要求的事情时团队首先想到的方法。它通常不是正确的第一步。以下是微调何时有帮助的诚实说明。
微调做什么和不做什么
微调根据示例调整模型的权重——它以不需要提示的持久方式改变模型”知道”什么或行为方式。微调适合的场景：教导模型一致的输出格式（JSON模式、特定写作风格、领域特定语言）；通过大量正确行为示例改善狭窄任务上的性能；使模型一致地表现得像特定角色；以及将较大模型的能力提炼到更小、更便宜、更快的模型中用于特定用例。微调不擅长的场景：添加基础模型没有的新知识（对于知识添加，RAG通常更有效且可更新）；修复基本推理限制（微调后推理不正确的模型通常仍然推理不正确）；或在大多数用例中替换精心制作的系统提示。最常见的错误：团队得出结论认为基础模型的输出不对，然后跳到微调，而真正的问题是写得不好的系统提示或上下文不足。提示工程和少量示例解决了人们最初归因于需要微调的80%的问题。
微调实际上有意义的情况
规模化的格式一致性：如果你的应用程序处理数千个请求并需要非常特定的输出格式（具有特定字段名的JSON模式、特定markdown结构），微调比单独提示产生更可靠的格式遵从性——特别是对于边缘情况和模糊输入。规模化的延迟和成本：针对特定任务微调的较小模型（例如，微调的Haiku 4.5或GPT-4o-mini）在特定任务上达到较大通用模型的水平，同时更快且更便宜。微调的经济论据在规模上改善。风格和角色：如果你的产品需要通过提示难以保持的非常特定的语气、词汇或角色（特别是对于简短或上下文稀少的请求），微调该风格产生更一致的结果。领域特定的准确性：在具有非常特定术语、缩写或推理模式的狭窄领域（医疗编码、法律引用格式、特定编程框架），对领域示例进行微调可以改善超出提示所能实现的准确性。分类任务：对特定类别的二元或多类别分类，其中你有标注示例——微调的较小模型通常与较大的通用模型匹敌，运行成本只是其一小部分。
实际的微调考虑因素
质量高于数量的数据集：500个高质量、多样、正确示例的微调数据集优于10,000个平庸示例的数据集。微调项目中最常见的失败是包含不一致性、错误或没有覆盖的边缘情况的低质量训练数据。微调前后的评估：在微调之前建立适当的评估基准；在留出示例上比较微调模型与基础模型；确保你没有在改善一个指标的同时降低另一个指标。训练/评估分割：永远不要在训练集的示例上进行评估。90/10分割是起始最低要求；对于小数据集，使用交叉验证。灾难性遗忘：在狭窄任务上微调可能降低模型在其他任务上的性能。这是针对特定用例进行微调的通用助手的真实风险。实际含义：微调模型最适合特定、有界的用例——而不是作为通用助手的替代品。提供商：OpenAI微调（GPT-4o、GPT-4o-mini）是最容易访问的托管微调服务；Anthropic为Claude提供微调（企业层级）；Hugging Face + Axolotl或LLaMA Factory用于在自己基础设施上的开源模型。
