在过去几天里关注Llama 2 的所有新闻已经超出了全职工作的范围。 信息网络确实充满了拍摄、实验和更新。 至少还要再过一周,但已经有一些关键点了。
推荐:用 NSDT设计器 快速搭建可编程3D场景。
在这篇文章中,我将澄清我对原始帖子中有关 Llama 2 的所有内容所做的一些更正,然后我将继续我的分析。 文章的前半部分将是迄今为止模型中存在争议和/或受到质疑的部分,最后,我将包括我的其余技术笔记(关于进一步的强化学习细节和新的上下文管理方法 Ghost Attention) 。
首先,两个快速更正:
人们发现 Llama-2-chat 的安全过滤器表现出喜欢触发的行为。 要求一些无辜的东西,例如如何制作辛辣的蛋黄酱或如何杀死一个进程,会导致模型疯狂地声明它无法做到这一点。 以下是当今领先的开源人工智能工程师 Anton 的一个例子:
我不需要因为这件事有多烦人而大吵大闹。 这用起来非常烦人。
关于为什么会出现这种情况,有很多流行的理论——大多数都指出使用 RLHF Hammer的时间太长。 这一缺陷的原因说明了当今大型语言模型的大趋势。 对于 RLHF,训练期间使用的主要性能指标是偏好模型奖励的单调增加。 这遇到了两个直接问题:a)我们使用的奖励模型不完整,b)我们错过了中间训练技术的有用评估技术。
只要我们仅在验证集上训练的奖励模型能够达到 65-75% 的准确率(因为训练数据是不同人类偏好的嘈杂集合,很难建模),那么你的模型就会出现 RLHF 过长的情况。 当一个模型对奖励模型采取太多优化步骤时,它就会过度索引该模型喜欢的行为,即使对模型的更全面的评估会表明情况并非如此。
目前还没有立即彻底的解决方案,但我的团队正在尝试在 MT Bench 和其他自动 NLP 评估上为 RL 训练的每个时期调度运行。 目前的LLM培训,至少在聊天领域,与用户的期望极不相符。
与往常一样,附录中隐藏了有关此内容的详细信息。 最终,Meta 的评估表明,聊天模型在评估中可能存在两个潜在的致命弱点:
这种有益与有害的权衡是开源社区面临的一个基本问题。 训练和发布仅有用的模型对那些希望以 Meta 不希望且无法真正执行的方式使用这些模型的负面行为者有利。 如果我们不能发布这些内容,我们最终会陷入困境,就像有些人查看Llama 2一样。期待继续关注这件事的进展。
下图显示了这一点。 我主要包含它,因为它是我几个月来在 ML 中看到的最酷的可视化之一!
尽管这些模型存在一些粗糙的缺陷,但我们可以预见,一家大公司会因过于谨慎而犯错。 我们还从论文中缺乏训练数据细节中看到了这一点。 这篇论文虽然有近 40 页,但缺少大量关键细节。 这是考虑到 Meta 因原始 LLaMA 中的数据而被起诉,但如果 Meta 说的是“公开可用数据”以外的其他内容,那就太好了。 如今,人工智能中的公众概念被严重滥用。 公共广场上对于信息的讨论太多,互联网上的数据也是公开的。 Meta 无法明确说明他们是否像许多闭源合作伙伴一样犯下了可疑的版权或服务条款违规行为,但 Meta 可以在数据访问和文档使用的分类法方面做得更好。
关于安全的最后一点也许我错过了。 为了安全起见,Meta 是否真的没有对其基本模型进行大量的人类和模型评估? 我觉得这很奇怪,因为这些模型现在将成为大量微调实验的起点。 由于 RLHF 模型没有通过很多人的嗅探测试,它们几乎变得更加重要。
在不实际操作的情况下建立直觉的最困难的事情之一是了解各种模型大小和吞吐量要求的 GPU 要求。 有很多优秀的人分享了针对不同用例的最小可行计算机。
以下是用于理解推理和微调(主要是PEFT-参数高效指令调整)的资源集合。
似乎有很多路径可以在大多数 GPU 上适配 7b 或 13b 模型。 这些很快就会在 iPhone 上运行。
70b 变体有点棘手。 例如,一项讨论展示了 70b 变体在以 4 位量化加载时如何使用 36-38GB VRAM。 如果将量化加倍为 8 位 (float16),则可以预期内存会按比例变化。 在任何单个 GPU 上使用完整的非量化模型都非常困难。
HuggingFace 对一些下游用户在文本生成推理方面的一致建议如下(不那么关注量化):
另一个例子是,社区成员重写了 HuggingFace Transformers 的一部分,以便仅针对 Llama 模型提高内存效率。 可以在此处查看 ExLlama 或在此处查看其速度摘要。 结果非常快(并且支持通过 RoPE 缩放扩展上下文长度):
llama-2 70b seq 长度 4096 的速度为 10.5~ tokens/sec。没有 oom,也尝试了 seq length 8192,没有 go oom 计时为 8 tokens/sec。 70b 原始模型的输出非常出色,是我从原始预训练模型中看到的最佳输出
微调示例很快就会出现——我找到它们并不容易,但我已经看到了更多。 TRL 已经可以非常轻松地运行有监督微调,你可以在 Google Colab 上免费获得的 T4 GPU 上训练 Llama 2 7B,甚至在单个 A100 上训练 70B 模型”。 这显然是一个有偏见的 HuggingFace 观点,但它表明它是相当容易理解的。 大多数消费级 GPU 可以微调 7B 或 13B 变体。
RLHF 则不同,你需要在内存中存储更多的梯度计算。 这些数字可能会在下周陆续公布。
有关高效部署大型模型的更多信息,我喜欢 Finbarr 的这篇文章。
这里还有很多事情要介绍。 我将做一个快速部分,并期望将来听到更多关于这些的信息:
这些是我从原来的文章中得到的,但在过去几天里,通过与 同事进行更多的内部讨论,它们也得到了改进。
该模型有一个很酷的技巧,可以帮助它在遵循多轮方向时发挥作用。 许多语言模型都存在一个问题,如果你告诉他们在第一轮做某事,比如“以海盗的方式回应”,他们会在一两轮后忘记。 这是 Meta 决定解决的一个非常高级的功能(即使这不是开源面临的最大问题)。 这种类型的东西让我很高兴 Meta 作为这个领域的参与者——他们追求一切,这是开源的一个好兆头。
Meta 为论文中的问题奠定了基础,解释了这种多轮指令的风格:
在对话设置中,一些指令应该适用于所有对话回合,例如,简洁地回应,或“扮演”某个公众人物。 当我们向 Llama 2-Chat 提供此类指令时,后续响应应始终遵守该约束。 然而,我们最初的 RLHF 模型在几轮对话后往往会忘记最初的指令。
为了解决这个问题,作者提出了 Ghost Attention (GAtt),这是一种类似于上下文蒸馏的技术:在长提示上训练模型,然后使用较短的系统提示对输出运行监督学习
大致而言,该方法的工作原理如下:
本质上,他们在训练推理时添加更多提示,然后使用该数据并在将来删除提示。 他们评论说,这使得长时间的对话在遵循指令方面更加一致:
我们在 RLHF V3 之后应用了 GAtt。 我们报告的定量分析表明,GAtt 在 20 多个回合内保持一致,直到达到最大上下文长度(参见附录 A.3.5)。 我们尝试在推理时设置 GAtt 训练中不存在的约束,例如“始终用俳句回答”,对此模型保持一致,如附录图 28 所示。
归根结底,GAtt 并不是一个需要实施的重要事物。 这是学习该领域新主题的绝佳练习。
作者提供了有关 RLHF 流程的许多其他详细信息。 上次我介绍了高级别的内容。 以下是我的一些补充说明。
拒绝采样(类似于 best-of-n 采样,带有损失更新)可能是 RLHF 更简单的起点,因为它是从奖励模型中提取信息的更温和的方法。
PPO 的实现从文献中汲取了一些罕见的东西,并继续简化流行的 RLHF 公式。
原文链接:Llama2:GPU硬件要求等 — BimAnt