Table of Contents
小型语言模型微调的适用场景
亲爱的朋友们，
在过去半年中，小型语言模型的微调技术越来越受欢迎。基于我在多家公司观察到的情况，我想分享一下我对何时使用这种技术以及何时不应使用的看法。
首先，虽然微调是一种重要且有价值的技术，但目前许多使用它的团队可能通过更简单的方法就能获得良好的结果，例如提示工程（包括编写超长提示）、少样本提示或简单的智能体工作流程。
为什么这些团队不应该进行微调？因为微调（即在特定应用的数据上进一步训练预训练模型）实施起来相对复杂。你需要收集训练数据，然后（除非你想自己实现微调）找到提供商帮助运行微调，再找到部署微调模型的方法。由于它在训练和部署方面都增加了额外的复杂性，通常我只有在发现提示工程和简单的智能体工作流程无法胜任任务时才会采用这种技术。
话虽如此，也有一些应用场景下微调是适当且有价值的。LoRA（通过修改有限数量的参数而不是整个模型来学习）和相关方法使微调变得相当经济实惠，尤其是对于小型模型（比如13B或更少参数的模型）。而且开始所需的数据量比大多数人想象的要少。根据应用情况，我已经看到用100个甚至更少的示例就能获得良好的结果。以下是我见过成功应用微调的几个场景：
提高关键应用的准确性。对于许多应用来说，提示工程可以让你走很远。但有时，微调有助于提高最后一点准确性。例如，如果你正在构建一个客户服务聊天机器人，并需要它可靠地调用正确的API（比如执行交易、发放退款等），也许提示工程可以让它95%的时间做出正确的API调用。但如果你即使修改提示也难以提高准确性，而你确实需要99%的准确性，那么对对话和API调用数据集进行微调可能是一个好方法。这对于那些难以仅用语言指定明确规则来决定做什么的任务尤其如此。例如，当客户感到沮丧时，聊天机器人应该上报给经理还是直接发放退款？团队通常会为人类工作者编写标准操作程序（SOP），并将这些SOP放入模型的提示中。但如果很难指定一个明确的SOP，甚至人类也需要看到大量示例才能学会如何操作，那么微调可能是一个好方法。对于许多文本分类应用，微调也效果良好，例如，将医疗记录分类为健康保险索赔的诊断和程序代码。
学习特定的沟通风格。正如我在《人人可用的生成式AI》中解释的那样，我的团队微调了一个模型使其听起来像我。许多人（包括我自己）都有使用语言的特殊习惯。有些词我倾向于说，有些词我倾向于不说，这些特点很多，很难在文本提示中指定。（顺便说一下，deeplearning.ai/avatar上的头像，用RealAvatar构建，就是出于这个原因使用微调的。）要让系统以某种风格进行沟通，微调通常是比单纯提示更好的解决方案。
在扩展时减少延迟或成本。我见过一些应用，开发人员成功地提示大型模型执行复杂任务。但随着使用量的增加，如果大型模型太慢（这种情况经常发生）或太昂贵（这种情况也会发生，但不太频繁），团队可能想使用较小的模型。然而，如果较小模型的性能不够好，那么对其进行微调可以帮助它在该特定应用中达到与大型模型相当的性能。此外，大型模型（或者可能是智能体工作流程）也可以用来生成数据，帮助微调小型模型完成该任务。
在研究的前沿，一些团队正在微调模型以更好地掌握某种语言。但除了少数例外，如果目标是让LLM更好地理解其训练数据中没有的知识体系，我发现使用RAG（检索增强生成）是一种更简单的方法，我仍然偶尔会遇到一些团队使用微调，而我认为RAG可能会效果更好。
总的来说，我的感觉是，在所有我看到使用微调的团队中，大约75%可以使用更简单的技术（如提示工程或智能体工作流程）获得良好的结果，但在25%的情况下，我不知道有比微调更好的方法来实现他们的目标。
实施微调、调整超参数、优化计算资源等仍然具有技术挑战性。幸运的是，越来越多的公司努力优化这些过程并提供高效的微调服务。它们中的许多允许我们微调开源权重模型并下载微调后的权重。有些允许我们微调他们的闭源模型并继续保持调整后的权重闭源。两者都有用，但前者明显具有可移植性的优势，并且不必担心提供商会停止提供特定模型，导致我们软件中的关键组件被废弃。
总结一下，在进行微调之前，考虑一下是否应该在提示工程或智能体工作流程上多下些功夫，这可能会带来更简单、更容易维护的解决方案。我团队构建的绝大多数应用根本不使用任何微调，但它是少数应用中的关键部分。
继续学习！
Andrew