原贴链接

嗨！ 我开始进行大型语言模型（LLM）的细调工作比我认识的其他人都要晚，而且我一直都在努力理解自己这么做的原因。我整理了一小份自己所知道的有关针对特定用例对LLM或Transformer模型进行细调的所有知识。我想听听你们对这些内容的看法！ 此外，请也分享一下你们的经验！我更想听到这些。

不应该进行细调的情况：

  • 当希望模型在极少数情况下以“特定”方式响应时。那是提示工程的用途！别用推土机来打苍蝇。
  • 为了让模型学习“新知识”
  • 当数据过少时。（不过，低数据量在数学推理方面比高数据量表现更好这一观点正在被证伪！仍处于研究阶段！）

选择正确的数据

  • 你希望模型学习模式，而非单词。你需要足够多样的样本，而非大量同类数据。
  • 更多的数据并不总是更好。不要把你拥有的所有数据都倾倒给模型。
  • 每个训练示例都需要一个明确的输入和一个明确的输出。并且可选择添加上下文文本以提供额外信息。
  • 数据集必须包含足够的常规情况、边缘情况以及介于两者之间的所有情况。你也可以使用来自更大LLM的数据来扩充数据集。
  • 整理你的数据集！这会有帮助！
  • 确定你是否正在执行开放式、指令式或基于聊天的文本生成。

选择正确的模型：

  • 你不需要对每个任务都使用100B的模型。对于实际应用，1 - 13B的模型更实用。
  • 你必须检查许可情况，看是否能将模型用于商业用例。有些模型有非常严格的许可要求。
  • 一个不错的起始点？Llama - 3.1 - 8B。

一般细调：

  • 一个8B的模型需要约16GB的内存来加载。所以，在内存受限的情况下，会使用混合精度和量化来初始化模型。
  • 如果批处理大小不能增加，就使用梯度累积方法。一般的累积是针对16、32、128的总体批处理大小进行的。
  • 定期保存检查点，并在需要时使用resume_from_checkpoint = True。
  • 考虑使用模型并行或数据并行技术在多个设备上进行大规模训练。
  • 文档在非常奇怪的情况下会有帮助。维护好它。

LoRA细调：

  • 不要对所有情况都使用QLoRA。只有当你意识到模型无法适配你的设备时才使用它。使用QLoRA大约会增加39%的训练时间，同时节省大约三分之一所需的内存。
  • SGD+学习率调度器很有用。但是将学习率调度器与其他优化器（如AdamW/Adam）一起使用似乎收益递减。（需要检查sophia优化器）
  • 大量的训练轮次对LoRA细调来说不是好兆头。
  • 尽管普遍认为lora_alpha约为2*lora_rank，但有时也最好检查一下其他值！这两个参数需要精心调整。
  • 在外面找到的训练时间可能会让人困惑。在你的电脑上可能会花费很长时间，但在报道的网站上看起来很快。嗯，你对GPU的选择也会影响速度。所以要记住这一点。
  • LoRA正在积极变化。不要忘记检查和测试它的不同版本，如LoRA - plus、DoRA、LoFTQ、AdaLoRA、DyLoRA、LoRA - FA等。（仍然需要检查其中的很多版本…）

选择细调策略：

  1. 确定正确的任务：
    1. 你必须为特定任务的细调“调整”模型，如代码生成、文档摘要和问答。
    2. 对于医疗、金融、法律等特定领域的需求，你需要促使模型更新其知识 => 在适用的情况下使用RAG或者对整个模型进行细调。（编辑：这应该是重新训练，而非细调。）
  2. 根据你正在尝试执行的任务类型利用剪枝。一般来说，在生产环境中，推理速度越快，性能就越好。在这种情况下，剪枝+细调会有帮助。我们需要记住这一点。

讨论总结

原帖对LLMs微调相关知识进行了综合概述，包括何时不应微调、数据和模型选择、一般微调、LoRA微调以及微调策略等。评论者的回应多种多样，有的指出原帖遗漏编写评估工具的内容，有的对原帖表示赞赏并希望补充微调时机内容，还有人分享自己在微调方面的经验如数据处理时间占比大等，也有人针对原帖中的矛盾之处或特定表述提出疑问，同时也有一些人向原帖作者寻求建议。

主要观点

  1. 👍 编写评估工具对验证微调效果很重要
    • 支持理由：有助于选择要微调的模型并比较超参数。
    • 反对声音：无。
  2. 🔥 任务适配是进行微调的常见原因
    • 正方观点：基础模型不完全符合需求时，微调可让模型满足要求。
    • 反方观点：无。
  3. 💡 数据在微调中占据主导地位，数据处理应占据大部分精力
    • 理由：数据的好坏很大程度上决定了微调效果。
  4. 💡 若无大量时间在大型集群恢复模型，剪枝不会有好结果
    • 理由：剪枝操作需要特定条件支持，否则难以达到预期。
  5. 💡 改变输出语气或适应特定用例的领域模型可进行细调
    • 理由：如对ChatGPT回复语气不满或针对特定医疗诊断模型等情况。

金句与有趣评论

  1. “😂 你忘记了最重要的部分：编写一个评估工具来验证你的微调比基准表现更好。”
    • 亮点：直接指出原帖遗漏的重要部分。
  2. “🤔 Appreciate the info on when to not fine tune but it would also be good to learn when to fine tune.”
    • 亮点：肯定原帖同时提出补充需求。
  3. “👀 数据是王 - 我怎么强调都不为过，你的微调效果永远取决于数据。”
    • 亮点：强调了数据在微调中的关键地位。

情感分析

总体情感倾向积极，大多数评论者对原帖表示感谢、赞赏或者认可原帖的价值。主要分歧点在于原帖中的一些表述，如关于新知识与微调的关系，以及部分技术操作的适用性（如剪枝）等。可能的原因是原帖内容较为宽泛，部分表述不够细致深入，而不同评论者基于自身的经验和理解对这些内容有不同的看法。

趋势与预测

  • 新兴话题：特定领域（如医学）的LLMs微调、不同模型（如2 - 3B、8B等）在不同场景下的适用性。
  • 潜在影响：有助于推动LLMs在更多特定领域的应用，提高微调的效率和效果，为相关从业者提供更多实践参考。

详细内容：

《关于微调 LLM 的热门讨论》

在 Reddit 上，一篇题为“A comprehensive overview of everything I know about fine-tuning.”的帖子引起了广泛关注。该帖获得了众多点赞和大量评论，引发了一场关于微调大型语言模型（LLM）的热烈讨论。

帖子中提到了多个关键方面，包括何时不应微调、选择合适的数据、合适的模型、一般微调要点、LoRA 微调以及选择微调策略等。比如，在不应微调的情况中指出，在罕见情况下想要模型以特定方式响应时不应微调，也不应通过微调让模型学习新知识，以及数据过少时不宜微调。

讨论的焦点集中在以下几个观点。有人认为写评估工具来验证微调效果比配置更重要，且数据至关重要，应在数据处理上花费大量时间。还有人指出模型大小很重要，不同规模的模型在性能上有差异。同时，关于何时进行微调也存在多种看法，比如改变输出的语气、适应特定领域的模型等。

例如，有用户分享道：“数据是王道，我在微调项目上花费的时间 80%/20%用于数据收集、准备等和微调。可能现在更像是 90/10，因为我有了非常可靠且经过实战检验的微调脚本。”

然而，讨论中也存在一些争议点。比如对于模型规模的选择，有人认为应根据任务而定，大型模型在某些情况下并非经济的解决方案；对于微调新知识，也有不同的观点和实践经验。

总的来说，这次关于微调 LLM 的讨论呈现出观点的多样性和复杂性，为深入理解和应用微调技术提供了丰富的参考。

那么，在实际应用中，如何根据自身需求和资源条件，选择最合适的微调策略，仍是一个值得深入探讨的问题。