Meta-llama3.1大模型是否需要微调探讨分析

这是关于采用开源大型语言模型 (LLM) 的系列博文中的第二篇。在这篇文章中，我们将讨论以下问题：“我们何时应该进行微调，何时应该考虑其他技术？”

• 在第 1 部分中，我们研究了将语言模型适应领域数据的流行方法。
• 在第 3 部分中，探索一些策划良好训练数据集的经验规则。

介绍

在 LLM 出现之前，微调通常用于较小规模的模型（100M – 300M 个参数）。最先进的领域应用程序是使用监督微调 (SFT) 构建的，即使用带注释的数据为您自己的领域和下游任务进一步训练预训练模型。

然而，随着更大模型（> 1B 个参数）的出现，微调的问题变得更加微妙。最重要的是，大型模型需要更大的资源和商业硬件来进行微调。

下表 1 列出了在三种情况下微调 Llama 2 7B 和 Llama 2 13B 模型的峰值 GPU 内存使用情况。您可能会注意到，QLoRA等算法使得使用有限资源微调大型模型变得更加容易。

例如，表 1 显示了 Llama 2 7B 上三种微调模式（完全微调、LoRA 和 QLoRA）的峰值 GPU 内存。据报道，Llama 1的参数高效微调 (PEFT) 或量化也会导致内存减少。除了计算资源之外，灾难性遗忘（有关详细信息，请参阅本系列第 1 部分）也是全参数微调的常见陷阱。PEFT 技术旨在通过对少量参数进行训练来解决这些缺点。

表 1：LLama 2 7B 上不同微调方法的内存（来源），单位为 Gb。QLoRA 使用 4 位 NormalFloat 量化。

微调可能有益的原型

我们已经确定以下场景是可以从微调中受益的常见用例：

1. 语气、风格和格式定制：用例可能需要能够反映特定角色或服务于特定受众的 LLM。通过使用自定义数据集对 LLM 进行微调，我们可以调整聊天机器人的响应，使其更符合受众的特定要求或预期体验。我们可能还希望以特定方式构造输出 – 例如 JSON、YAML 或 Markdown 格式的输出。
2. 提高准确性和处理极端情况：微调可用于纠正幻觉或错误，这些幻觉或错误很难通过提示工程和情境学习来纠正。它还可以增强模型执行新技能或难以在提示中表达的任务的能力。此过程有助于纠正模型无法遵循复杂提示的问题，并提高其产生所需输出的可靠性。我们提供两个示例：
   • Phi-2对金融数据情绪分析的准确率从34%提升到了85%。
   • ChatGPT 仅使用 100 个示例就将 Reddit 评论情绪分析的准确率提高了 25 个百分点（从 48% 提高到 73%）。
     通常，对于较小的初始准确率数字（< 50%），使用几百个示例进行微调就能取得很大的进步。
3. 解决代表性不足的领域：尽管法学硕士接受了大量通用数据的训练，但他们可能并不总是精通每个细分领域的细微行话、术语或特性。对于法律、医疗或金融等不同领域，微调已被证明有助于提高下游任务的准确性。我们提供两个示例：
   • 正如这篇文章所指出的，患者的病史包含高度敏感的数据，这些数据通常不会出现在公共领域。因此，基于 LLM 的病史总结系统需要进行微调。
   • 对于印度语等代表性不足的语言，使用 PEFT 技术进行微调有助于完成这些语言的所有任务。
4. 降低成本：微调可以将较大的模型（如 Llama 2 70B/GPT-4）中的技能提炼到较小的模型（如 Llama 2 7B）中，从而在不影响质量的情况下降低成本和延迟。此外，微调减少了对冗长或特定提示（如提示工程中所用）的需求，从而节省代币并进一步降低成本。作为示例，本文展示了如何通过提炼更昂贵的 GPT-4 模型来微调 GPT-3.5 法官，从而节省成本。
5. 新任务/能力：通常，新功能可以通过微调来实现。我们提供了三个示例：
   • 对 LLM 进行微调，以便更好地利用给定检索器的上下文或完全忽略它
   • 对 LLM 评判员进行微调，以评估其他 LLM 的指标，例如基础性、合规性或帮助性
   • 微调 LLM 以增加上下文窗口

与其他领域自适应技术的比较

微调与上下文（小样本）学习

上下文学习 (ICL) 是提高基于 LLM 的系统性能的有效方法。鉴于其简单性，应在进行任何微调活动之前先尝试使用 ICL。此外，ICL 实验可以帮助您评估微调是否会提高下游任务的性能。使用 ICL 时的常见注意事项包括：

• 随着需要展示的示例数量的增加，推理和延迟的成本也会增加。
• 随着例子越来越多，LLM 通常会忽略一些例子。这意味着您可能需要一个基于 RAG 的系统，根据输入找到最相关的示例。
• LLM 可能会把提供的知识作为例子吐出来。在微调时也存在这种担忧。

微调与RAG

普遍的共识是，当 LLM 基本性能不令人满意时，您可以“从 RAG 开始，评估其性能，如果发现不足，则转向微调”，或者“RAG 可能比微调更有优势”（来源）。但是，我们认为这种范式过于简单，因为在某些情况下，RAG 不仅不是微调的替代方案，而且更像是微调的补充方法。根据问题的特点，应该尝试其中一种或两种方法。采用本文的框架，以下是您可能会问的一些问题，以确定微调或 RAG（或两者）是否适合您的问题：

• 您的应用程序是否需要外部知识？微调通常无助于注入新知识。
• 您的应用程序是否需要自定义语气/行为/词汇或风格？对于这些类型的需求，微调通常是正确的方法。
• 您的应用对幻觉的容忍度有多高？在抑制虚假信息和虚构内容至关重要的应用中，RAG 系统提供了内置机制来最大限度地减少幻觉。
• 有多少标记的训练数据可用？
• 数据有多静态/动态？如果问题需要访问动态数据语料库，微调可能不是正确的方法，因为 LLM 的知识很快就会变得陈旧。
• LLM 申请需要有多透明/可解释？RAG 本身可以提供参考，这对于解释 LLM 输出很有用。
• 成本和复杂性：团队是否具有构建搜索系统的专业知识或之前的微调经验？
• 你的应用程序中的任务有哪些多样性？

在大多数情况下，微调和 RAG 的混合解决方案将产生最佳结果——问题变成了同时进行这两项操作的成本、时间和额外的独立收益。参考上述问题来指导您的决策，以确定是否需要 RAG 和/或微调，并进行内部实验以了解通过分析错误可能获得的指标增益。最后，微调中的探索确实需要强大的数据收集和数据改进策略，我们建议将其作为开始微调的前提。

致谢

我们要感谢 Suraj Subramanian 和 Varun Vontimitta 对这篇博文的组织和准备提出的建设性反馈。

转载自：https://ai.meta.com/blog/when-to-fine-tune-llms-vs-other-techniques/