NSDT工具推荐： Three.js AI纹理开发包 - YOLO合成数据生成器 - GLTF/GLB在线编辑 - 3D模型格式在线转换 - 可编程3D场景编辑器 - REVIT导出3D模型插件 - 3D模型语义搜索引擎 - Three.js虚拟轴心开发包 - 3D模型在线减面 - STL模型在线切割

在过去几天里关注Llama 2 的所有新闻已经超出了全职工作的范围。 信息网络确实充满了拍摄、实验和更新。 至少还要再过一周，但已经有一些关键点了。

在这篇文章中，我将澄清我对原始帖子中有关 Llama 2 的所有内容所做的一些更正，然后我将继续我的分析。 文章的前半部分将是迄今为止模型中存在争议和/或受到质疑的部分，最后，我将包括我的其余技术笔记（关于进一步的强化学习细节和新的上下文管理方法 Ghost Attention） 。

首先，两个快速更正：

  • 它是开源的吗？ 我原来的标题中错误地包含了“开源”一词。 从技术上讲，该模型不是开源的，因为它的开发和使用并未完全向全体公众开放。 它对于开源社区仍然有用，但它只是一个开放发布/开放创新[这里有更多内容，我很快就会重新讨论这一点]。
  • 偏好数据的成本：我曾指出，为训练而收集的偏好数据大约花费 2000 万美元，但我错过了提示与回合的划分因素（每个提示有 4 个回合），所以我预计他们支付了大约 800 万美元的费用。 尽管如此，我预计该项目的总成本将在 2000-4500 万美元之间。

1、通过无害来逃避

人们发现 Llama-2-chat 的安全过滤器表现出喜欢触发的行为。 要求一些无辜的东西，例如如何制作辛辣的蛋黄酱或如何杀死一个进程，会导致模型疯狂地声明它无法做到这一点。 以下是当今领先的开源人工智能工程师 Anton 的一个例子：

我不需要因为这件事有多烦人而大吵大闹。 这用起来非常烦人。

关于为什么会出现这种情况，有很多流行的理论——大多数都指出使用 RLHF Hammer的时间太长。 这一缺陷的原因说明了当今大型语言模型的大趋势。 对于 RLHF，训练期间使用的主要性能指标是偏好模型奖励的单调增加。 这遇到了两个直接问题：a）我们使用的奖励模型不完整，b）我们错过了中间训练技术的有用评估技术。

只要我们仅在验证集上训练的奖励模型能够达到 65-75% 的准确率（因为训练数据是不同人类偏好的嘈杂集合，很难建模），那么你的模型就会出现 RLHF 过长的情况。 当一个模型对奖励模型采取太多优化步骤时，它就会过度索引该模型喜欢的行为，即使对模型的更全面的评估会表明情况并非如此。

目前还没有立即彻底的解决方案，但我的团队正在尝试在 MT Bench 和其他自动 NLP 评估上为 RL 训练的每个时期调度运行。 目前的LLM培训，至少在聊天领域，与用户的期望极不相符。

与往常一样，附录中隐藏了有关此内容的详细信息。 最终，Meta 的评估表明，聊天模型在评估中可能存在两个潜在的致命弱点：

  • 该模型被发现拒绝回答高达 27% 的临界问题！ 这与 Anthropic 的工作思路密切相关，他们建议首先开发一个有用的语言模型，然后开发一个无害的语言模型，因为同时这样做会导致回避行为。 事实上，这已经在论文中出现并且众所周知，这意味着 Meta 肯定正在努力解决这个问题。

这种有益与有害的权衡是开源社区面临的一个基本问题。 训练和发布仅有用的模型对那些希望以 Meta 不希望且无法真正执行的方式使用这些模型的负面行为者有利。 如果我们不能发布这些内容，我们最终会陷入困境，就像有些人查看Llama 2一样。期待继续关注这件事的进展。

下图显示了“边界数据集”模型拒绝的疯狂增加。

  • 奖励模型集成技术存在一个问题，即存在高度分歧的区域，即当有用性高且安全性低时该怎么办，反之亦然。 他们利用这个集成的方法显然需要做一些工作，即使我发现这是一项了不起的技术创新。

下图显示了这一点。 我主要包含它，因为它是我几个月来在 ML 中看到的最酷的可视化之一！

尽管这些模型存在一些粗糙的缺陷，但我们可以预见，一家大公司会因过于谨慎而犯错。 我们还从论文中缺乏训练数据细节中看到了这一点。 这篇论文虽然有近 40 页，但缺少大量关键细节。 这是考虑到 Meta 因原始 LLaMA 中的数据而被起诉，但如果 Meta 说的是“公开可用数据”以外的其他内容，那就太好了。 如今，人工智能中的公众概念被严重滥用。 公共广场上对于信息的讨论太多，互联网上的数据也是公开的。 Meta 无法明确说明他们是否像许多闭源合作伙伴一样犯下了可疑的版权或服务条款违规行为，但 Meta 可以在数据访问和文档使用的分类法方面做得更好。

关于安全的最后一点也许我错过了。 为了安全起见，Meta 是否真的没有对其基本模型进行大量的人类和模型评估？ 我觉得这很奇怪，因为这些模型现在将成为大量微调实验的起点。 由于 RLHF 模型没有通过很多人的嗅探测试，它们几乎变得更加重要。

2、推理和Llama

在不实际操作的情况下建立直觉的最困难的事情之一是了解各种模型大小和吞吐量要求的 GPU 要求。 有很多优秀的人分享了针对不同用例的最小可行计算机。

以下是用于理解推理和微调（主要是PEFT-参数高效指令调整）的资源集合。

2.1 推理注意事项

似乎有很多路径可以在大多数 GPU 上适配 7b 或 13b 模型。 这些很快就会在 iPhone 上运行。

70b 变体有点棘手。 例如，一项讨论展示了 70b 变体在以 4 位量化加载时如何使用 36-38GB VRAM。 如果将量化加倍为 8 位 (float16)，则可以预期内存会按比例变化。 在任何单个 GPU 上使用完整的非量化模型都非常困难。

HuggingFace 对一些下游用户在文本生成推理方面的一致建议如下（不那么关注量化）：

  • 对于 7B 模型，我们建议你选择“GPU [中] - 1x Nvidia A10G”。
  • 对于 13B 模型，我们建议你选择“GPU [xlarge] - 1x Nvidia A100”。
  • 对于 70B 模型，我们建议你选择“GPU [xxxlarge] - 8x Nvidia A100”。

另一个例子是，社区成员重写了 HuggingFace Transformers 的一部分，以便仅针对 Llama 模型提高内存效率。 可以在此处查看 ExLlama 或在此处查看其速度摘要。 结果非常快（并且支持通过 RoPE 缩放扩展上下文长度）：

llama-2 70b seq 长度 4096 的速度为 10.5~ tokens/sec。没有 oom，也尝试了 seq length 8192，没有 go oom 计时为 8 tokens/sec。 70b 原始模型的输出非常出色，是我从原始预训练模型中看到的最佳输出

2.2 微调注意事项

微调示例很快就会出现——我找到它们并不容易，但我已经看到了更多。 TRL 已经可以非常轻松地运行有监督微调，你可以在 Google Colab 上免费获得的 T4 GPU 上训练 Llama 2 7B，甚至在单个 A100 上训练 70B 模型”。 这显然是一个有偏见的 HuggingFace 观点，但它表明它是相当容易理解的。 大多数消费级 GPU 可以微调 7B 或 13B 变体。

RLHF 则不同，你需要在内存中存储更多的梯度计算。 这些数字可能会在下周陆续公布。

有关高效部署大型模型的更多信息，我喜欢 Finbarr 的这篇文章。

3、其他值得关注的事情

这里还有很多事情要介绍。 我将做一个快速部分，并期望将来听到更多关于这些的信息：

  • Open LLM 排行榜的顶部仍然是从 LLaMAv1 微调的模型，这是为什么？ 有一些内部讨论，这似乎是由于排行榜上没有足够的评估类型（很快就会改变）的结果：很容易在评估集（或接近它的东西）上微调模型并获得更高的分数 表现。 顶级模型不仅注重结果，而且处于边缘状态。 随着时间的推移，这种情况将会变得平滑，并且 Llama 2 上的相同数据集几乎肯定会更高。
  • 工具使用出现：“Llama 2-Chat 能够仅通过语义理解工具的应用程序和 API 参数，尽管从未接受过使用工具的培训。” 正如我在 LLM 代理帖子中所写，LLM-for-tools 非常有前途。 为了看到这个爆炸，我们需要一些标准环境来进行评估。
  • 提示问题：我和其他一些人想知道提示是否是导致回避行为的问题。 其中，我想知道系统提示是否在论文中，是否在A.3.7人工评估中列出。 我会密切关注这个故事，因为 LLaMA 1 评估的不一致结果有很大的推动作用。
  • 尽管 Yann Lecun 在帖子中暗示他们可能会发布代码，但代码微调的机会还是非常高的。 本着这种精神，我希望看到特定领域的奖励模型，例如代码。 Llama 2 的代码还不够好，我的大多数观众都无法使用它来代替 ChatGPT，但竞争压力是存在的，而且这种情况会很快改变。
  • Miles 有一个很好的主题，讨论了 Meta 围绕模型的开放版本缺乏直接表达价值观的问题。 如果Meta直接说出他们的观点就更好了，这样我们就不用去推测了。 不管怎样，下一个问题是：如何通过微调来解除安全限制？ Llama 2 正在开辟一个新的研究方向。
  • 许可证太搞笑了 它指出，发布时活跃用户超过 7 亿的公司不能将该模型用于商业用途。 真是太小气了 另外，我喜欢这种模式对苹果的帮助（就像他们集成了稳定扩散），但这两家公司如果尝试的话就不可能成为朋友。 能够与AppleGPT在同一周进行是非常光荣的。

4、附加技术说明

这些是我从原来的文章中得到的，但在过去几天里，通过与 🤗 同事进行更多的内部讨论，它们也得到了改进。

4.1 幽灵注意力聊天技巧

该模型有一个很酷的技巧，可以帮助它在遵循多轮方向时发挥作用。 许多语言模型都存在一个问题，如果你告诉他们在第一轮做某事，比如“以海盗的方式回应”，他们会在一两轮后忘记。 这是 Meta 决定解决的一个非常高级的功能（即使这不是开源面临的最大问题）。 这种类型的东西让我很高兴 Meta 作为这个领域的参与者——他们追求一切，这是开源的一个好兆头。

Meta 为论文中的问题奠定了基础，解释了这种多轮指令的风格：

在对话设置中，一些指令应该适用于所有对话回合，例如，简洁地回应，或“扮演”某个公众人物。 当我们向 Llama 2-Chat 提供此类指令时，后续响应应始终遵守该约束。 然而，我们最初的 RLHF 模型在几轮对话后往往会忘记最初的指令。

为了解决这个问题，作者提出了 Ghost Attention (GAtt)，这是一种类似于上下文蒸馏的技术：在长提示上训练模型，然后使用较短的系统提示对输出运行监督学习

大致而言，该方法的工作原理如下：

  • 将此首轮字符样式指令连接到带有隐藏标记的对话的所有用户消息。
  • 接下来，他们从最新聊天模型的综合训练风格中进行采样——传入修改后的提示。 这需要 RLHF 中训练数据的一组爱好、语言风格和角色。
  • 使用此更重提示的数据进行指令微调（多轮）。 在训练中，他们将添加数据的中间回合的损失设置为 0，这在论文中没有得到很好的解释。 我认为他们在对合成数据链上的自回归预测损失进行微调时忽略了对中间回合梯度的影响，因此他们在“充当角色”的指令和之前的一堆填充文本上进行微调。 最后一回合。

本质上，他们在训练推理时添加更多提示，然后使用该数据并在将来删除提示。 他们评论说，这使得长时间的对话在遵循指令方面更加一致：

我们在 RLHF V3 之后应用了 GAtt。 我们报告的定量分析表明，GAtt 在 20 多个回合内保持一致，直到达到最大上下文长度（参见附录 A.3.5）。 我们尝试在推理时设置 GAtt 训练中不存在的约束，例如“始终用俳句回答”，对此模型保持一致，如附录图 28 所示。

归根结底，GAtt 并不是一个需要实施的重要事物。 这是学习该领域新主题的绝佳练习。

5、强化学习的额外内容

作者提供了有关 RLHF 流程的许多其他详细信息。 上次我介绍了高级别的内容。 以下是我的一些补充说明。

5.1 拒绝采样详细信息

拒绝采样（类似于 best-of-n 采样，带有损失更新）可能是 RLHF 更简单的起点，因为它是从奖励模型中提取信息的更温和的方法。

  • 训练过程：使用的损失函数其实不是那么清楚。 在论文中，他们说他们使用了迭代训练，因此实际结果与 PPO 没有太大不同，但他们不包含损失函数。 我觉得这有点令人头疼，因为如 果不学习价值函数（PPO 的内部部分），他们就无法使用该损失函数，因此作者几乎肯定会使用 LLM 的标准自回归预测损失 - 奖励样品，影响巨大！
  • 通过使用 RS 重新训练样本，发现能力有所下降。 为了解决这个问题，他们重新引入了所有过去版本的顶级样本，从而提高了性能（关于这种效果的文档很少）。 这是 RLHF 技术中常见的奖励模型过度拟合的一种形式。
  • 聊天模型的所有较小变体都根据最大模型的数据进行训练（蒸馏）。 一般来说，ChatGPT 很可能也是这样训练的。 最好的机器学习组织希望利用出色的推理能力来构建他们最大、最好的模型，然后这种好处将以多种方式体现出来。
  • 在采样过程中，他们使用高温来获得不同的输出，并增加一批样本的最大奖励。 他们将探索作为一种机制进行讨论，我喜欢这一点，但没有任何测量准确地表明这一点。
  • 必须根据模型和批大小逐步改变温度。 这篇论文有很多关于温度的内容，目前还不清楚有多少是专门针对它们的。
  • 为了实现这一点，你所需要的只是像这个笔记本这样带有反馈循环的东西来采取训练步骤，但如果没有一个很好的奖励模型，你就会陷入困境。

5.2 PPO 详细信息

PPO 的实现从文献中汲取了一些罕见的东西，并继续简化流行的 RLHF 公式。

  • 使用 InstructGPT 中提出的 SFT 约束项来保持模型分布接近人类书面演示。 这是损失函数中的一个额外项，用于比较人类注释者编写的文本与模型生成之间的距离。
  • 使用首选项集合中的安全标记将这些代传递到安全首选项模型（或者如果安全模型标记来自非标记提示的代）。 未来这很可能会扩展到更多模型和元数据，或者已经通过 GPT4 完成。
  • 白化最终的线性层分数以稳定训练。 本质上，他们正在创建一个不同的线性层，以帮助奖励模型中的梯度表现得更好。 一个有趣的技巧。

原文链接：Llama 2 follow-up: too much RLHF, GPU sizing, technical details

BimAnt翻译整理，转载请标明出处