何时应微调，何时不应？大型语言模型微调策略深度解析
亲爱的朋友们，
在过去半年中，小型语言模型（SLM）的微调技术日益受到关注。鉴于我在多家公司所观察到的情况，我想分享我对何时应采用此技术以及何时应避免使用的见解。
尽管微调是一项重要且有价值的技术，但许多目前正在使用它的团队或许可以通过更简单的方法获得良好的结果，例如提示工程（包括编写大型提示）、少量样本提示或简单的 Agentic 工作流程。简而言之，Agentic 工作流程是指利用 LLM 驱动的自主代理来执行任务，这些代理能够分解复杂目标、制定行动计划、利用工具并与环境互动，从而以最有效的方式实现既定目标。
那么，为什么这些团队不应该进行微调呢？原因在于微调需要收集训练数据，然后找到一个可以协助运行微调的提供商（除非您想自己实现微调），最后找到一种部署微调模型的方法。因为它在训练和部署中都增加了额外的复杂性，所以我通常只有在发现提示和简单的 Agentic 工作流程无法胜任一项任务时才会求助于此技术。
也就是说，在某些应用中，微调是适当且有价值的。LoRA（通过修改有限数量的参数而不是整个模型进行学习）和相关方法使得微调变得相当经济实惠，特别是对于小型模型（例如，13B 或更少的参数）。而且，开始所需的数据量比大多数人想象的要少。根据应用的不同，我见过使用 100 个甚至更少的示例就能获得良好结果的情况。以下是我见过微调成功应用的一些示例：
提高关键应用的准确性
在许多应用中，Prompting 已经可以帮助你走得很远。但有时，微调有助于挤出最后一点准确性。例如，如果您正在构建一个客户服务聊天机器人，并且需要它可靠地调用正确的 API（例如，执行交易、发放退款等），那么 Prompting 也许可以使其在 95% 的时间内调用正确的 API。但是，如果您即使通过修改 Prompt 也难以提高准确性，并且您确实需要 99% 的准确性，那么在对话和 API 调用的数据集上进行微调可能是帮助您实现目标的好方法。对于难以仅使用语言指定明确规则来决定该怎么做的任务而言，尤其如此。例如，当客户感到沮丧时，聊天机器人应该升级到经理还是直接发放退款？团队通常会编写标准操作程序 (SOP) 供人工遵循，而这些 SOP 可以进入模型的 Prompt 中。但是，如果难以指定明确的 SOP，以至于即使是人类也需要查看大量示例才能学会该怎么做，那么微调可能是一种好方法。对于许多文本分类应用，微调也效果良好，例如，将医疗记录分类为健康保险索赔的诊断和程序代码。
案例分析：
某金融机构的客户服务聊天机器人，在处理客户咨询时，经常出现API调用错误，导致交易失败或退款错误。即使经过多次prompt优化，准确率仍停留在95%左右。为了解决这个问题，该机构采用了微调策略，收集了大量的客户对话和对应的API调用记录，构建了一个微调数据集。通过LoRA技术，对小型语言模型进行微调，最终将API调用准确率提升至99%以上，显著降低了交易失败率和客户投诉。
学习特定的沟通风格
正如我在“人人可用的生成式人工智能”中所解释的那样，我的团队对一个模型进行了微调，使其听起来像我。许多人（包括我自己）都有特殊的语言使用习惯。我倾向于说某些词，而不倾向于说另一些词，而且这些特殊习惯很多，很难在文本 Prompt 中指定。（顺便说一句，deeplearning.ai/avatar 上的头像使用 RealAvatar 构建，出于这个原因，它使用了微调。）要让系统以某种风格进行交流，微调通常是优于单独 Prompt 的解决方案。
案例分析：
一位知名作家希望创建一个AI助手，能够以他的独特文风进行写作。该作家收集了自己大量的作品，包括小说、散文、博客等，构建了一个微调数据集。通过对小型语言模型进行微调，使AI助手能够模仿作家的语言风格、用词习惯和表达方式。最终，AI助手生成的文章，几乎可以与作家的原创作品相媲美，极大地提高了写作效率。
降低扩展期间的延迟或成本
我见过一些应用，其中开发人员已成功地 Prompt 大型模型来执行复杂的任务。但是，随着使用量的增加，如果大型模型太慢（这种情况经常发生）或太昂贵（这种情况也发生，但频率较低），团队可能希望使用较小的模型。但是，如果较小模型的性能不够好，那么微调它可以帮助将其提升到大型模型在该狭窄应用中的性能。此外，大型模型（或某种 Agentic 工作流程）还可以用于生成数据，以帮助微调该任务的小型模型。
案例分析：
一家电商公司最初使用大型语言模型来生成商品描述，效果非常好。但是，随着商品数量的快速增长，大型模型的生成速度越来越慢，成本也越来越高。为了解决这个问题，该公司决定采用小型语言模型，并使用大型模型生成的商品描述作为训练数据，对小型语言模型进行微调。通过这种方式，小型语言模型在保持较高生成质量的同时，显著降低了生成时间和成本。
处于研究前沿的一些团队正在微调模型，以使其更擅长某种语言。但是，除了少数例外情况，如果目标是让 LLM 更好地理解其训练数据中没有的知识体系，我发现使用 RAG（检索增强生成）是一种简单得多的方法，而且我仍然偶尔会遇到一些团队使用微调，而我认为 RAG 会更有效。
总的来说，我的感觉是，在我看到的所有使用微调的团队中，也许 75% 的团队可以使用更简单的技术（如 Prompting 或 Agentic 工作流程）获得良好的结果，但在 25% 的情况下，我知道没有更好的方法来实现他们的目标。
实施微调、获得正确的超参数、优化计算资源等在技术上仍然具有挑战性。我们很幸运，越来越多的公司努力优化这些并提供高效的微调服务。他们中的许多人允许我们微调开放权重模型，还可以下载微调后的权重。有些允许我们微调他们的封闭模型，并继续保持调整后的权重封闭。两者都可能有用，但前者具有明显的便携性优势，而且不必担心提供商会停止提供特定模型，从而导致我们软件中的关键组件被弃用。
总之，在微调之前，请考虑是否应该在 Prompting 或 Agentic 工作流程中再多尝试一下，这可以带来更易于维护的更简单的解决方案。我的团队构建的绝大多数应用根本不使用任何微调，但它是其中一小部分的关键部分。
保持学习！
安德鲁
