抱抱脸Open了OpenAI的秘密武器,网易参与复现

人工智能
InstructGPT的结构和训练技术与ChatGPT大差不差,所以也被称为是ChatGPT的兄弟模型。而此后OpenAI并未放出ChatGPT论文,所以有不少学者从InstructGPT出发探索ChatGPT的内核。

OpenAI的秘密武器、ChatGPT背后功臣RLHF,被开源了。

来自Hugging Face、加拿大蒙特利尔Mila研究所、网易伏羲AI Lab的研究人员从零开始复现了OpenAI的RLHF pipeline,罗列了25个关键实施细节。

最终成功展示了随着模型大小的增加,响应质量显著提升的scaling行为,其中2.8B、6.9B的Pythia模型在性能上超过了OpenAI发布的1.3B checkpoint。

图片

没有写在论文中,但被作者在推文中po出来的,还有一个初步的Pythia 1.4B实验,根据GPT-4的数据显示,这个1.4B模型非常接近OpenAI的1.3B性能(由于GPT4成本过高,只进行了一次评估)

图片

研究人员表示,他们的这一“配方”的独特之处在于对SFT、RM和PPO使用了单一的学习率,所以再重现他们的工作会变得更加简单。

作者已公开发布了训练好的模型checkpoint和代码。

图片

顺便一提,Huggingface最近上了一把新闻,抱抱脸现在是正式译名了:

图片

写在前头

大语言模型的功能实质上就是在玩“词语接龙”——以给定的前面的token,预测下一个token。

为了让输出的下一个token符合人类意愿,人类反馈强化学习(RLHF)这一方法理念逐渐被引入pipeline,用于收集成对的人类偏好,训练奖励模型(RM)来对这些偏好进行建模,并使用强化学习(RL)创建一个模型来输出人类喜欢的内容。

OpenAI对RLHF的探索一直走在前头。

在2020年“Learning to summarize from human feedback”这项工作中,OpenAI研究员将RLHF应用到了捕捉原始文本主要信息和意图的摘要任务中。

这种人类反馈训练的模型在英文摘要任务上显著优于人类参考摘要和仅使用监督学习的更大模型。且具有较强的泛化能力,在没有特定领域微调的情况下,也能生成高质量的文章摘要,接近人类参考摘要的质量。

图片

在2022年“Training language models to follow instructions with human feedback”这项工作中,RLHF再次被使用,为指令遵循任务而专门设计的InstructGPT诞生。

这也是GPT-3到ChatGPT的过渡论文。

图片

InstructGPT的结构和训练技术与ChatGPT大差不差,所以也被称为是ChatGPT的兄弟模型。而此后OpenAI并未放出ChatGPT论文,所以有不少学者从InstructGPT出发探索ChatGPT的内核。

其中秘密武器RLHF,开源界围绕着它做了不少工作,不过想要重现OpenAI的RLHF pipeline很是困难。

主要有这么几个原因:

  • RL和RLHF有许多微妙的实现细节,这些细节对训练稳定性有很大影响;
  • 对于指令遵循任务,如评估一个编码任务中生成的800行代码片段的质量,评估模型的表现不太行;
  • 模型需要长时间的训练和迭代。

考虑到以上原因,加之总结任务比一般的指令任务更容易评估,所以Hugging Face最新的这项工作选择退后一步,从OpenAI早期的RLHF工作(也就是上面第一篇论文的摘要任务)中,探寻OpenAI的RLHF的真面目。

25个细节深度复现

RLHF通常包括以下三个步骤。

步骤1:训练SFT(监督微调)策略

使用下一个词预测损失对预训练的LLM进行微调,这些微调数据基于人类示范。

在这项复现工作中,人类示范数据与OpenAI的工作保持一致,选自过滤后的Reddit TL;DR(Too Long; Didn’t Read)数据集(当时OpenAI还Open了他们的人类反馈数据集)

步骤2:收集偏好对并训练RM(奖励模型)

使用SFT策略等采样不同完成序列,让人类标注员指出他们较偏好的序列。

基于这些偏好数据,通过在SFT策略上添加一个随机初始化的线性头来初始化RM,并优化交叉熵损失函数进行训练,目标是预测人类标注员更倾向于接受哪种完成序列。

步骤3:针对RM训练RL(强化学习)策略

从SFT策略初始化,RL策略根据RM对采样的完成序列给出奖励分数,同时加上一个KL惩罚项以防止过度偏离SFT策略。然后使用PPO算法最大化这个RLHF目标函数。

研究人员针从数据集到SFT、RM、OPP,共介绍了25个复现细节,深入分析了TL;DR数据集的规格、分词过程和分词长度分布。同时,详细描述了SFT和RM组件的训练设置、实施细节和结果。

感兴趣的家人们可以划到最后查看论文,这里罗列了作者认为有趣的细节。

数据预处理阶段:

对于RLHF的提示查询,OpenAI在最后一段进行截断,而不是使用硬性的截断限制;同时确保“TL;DR:”之后没有多余的空格。

图片

始终在reference completions前加上前导空格,在reference completions后添加`<|endoftext|>`,并使用单独的[PAD] token填充。

图片

SFT和偏好数据集的tokenization length不同,因此在SFT和RM训练期间分别设置最大token长度时需要注意。

图片

RM的验证集非常有趣,因为它包含更多独特的策略对进行比较,所以它有很多超出分布的数据。

图片

SFT阶段:

SFT阶段没有太多的实现细节,只需要标准的下一个token预测损失就可以了。除了使用了不同的学习率之外,研究人员的设置几乎与原始设置相同。

损失下降,ROUGE分数在4个随机种子和3个模型checkpoint大小上都有所提高。

图片

RM训练:

RM训练更有趣。例如,研究人员发现RM只在EOS token处提取奖励。此外,在检查奖励的logits时,除了EOS token外,几乎所有的logits都是负数。

图片

结果非常不错,验证准确率提高了,RM几乎完美地转移到了偏好数据集验证集中的CNN/DM子集上。

图片

他们计算了SFT demonstration的平均奖励——标量值看起来有些随意;还计算了OpenAI偏好数据集中每个批号和置信度的验证准确率。

值得注意的是,不同的批次/置信度可能会有截然不同的准确率。

图片

研究人员也测量了RM与GPT3.5和RM的一致性率(agreement rate),并发现一致性率有所提高,但在6.9B级别时有所减弱。

并绘制了AnthropicAI所做的RM校准,发现RM通常校准不足。

图片

研究人员将验证准确率与DPO的隐式RM进行了比较,发现出于某种原因DPO的验证准确率较低。

几个不同点:

  • RM训练只在EOS token处应用损失,而DPO在每个完成token处应用损失。
  • DPO还有一个可能影响训练的$beta参数,RM则没有。
  • 研究员Michael Noukhovitch提出了个有说服力的观点:DPO的目标可能更难优化,因为你需要使你的logprobs与基本模型有足够大的不同才能更改奖励,而RM可以学习一个线性头,可以更容易/更快地改变奖励的值。

图片

PPO训练:

有趣的是,学习值函数的行为与RM截然不同。例如,值函数logits通常更为正,因为在每个时间步长,它都试图对最终分数进行建模。

图片

PPO也使用了EOS技巧。在PPO训练中,研究人员通常采样固定数量的token,比如48个。如果完成不以EOS token结束怎么办?前面已经提到了,非EOS token的logits几乎总是负的(并且可能无效)

EOS技巧基本上用恒定的-1奖励取代了不以EOS token结尾的完成的奖励。有几个目的:

图片

研究人员还尝试了PPO的奖励白化处理,并发现这样使得与参考摘要的胜率略有降低,以及完成token的长度略微缩短。

图片

长度在这里是一个混杂因素,所以研究人员引导了OpenAI进行的长度控制分析,通过将x轴设置为模型摘要长度与参考摘要长度之比的对数来执行。

当长度得到控制时,研究人员发现比较奖励白化的结果更具挑战性,但尽管如此,在每个摘要长度上,PPO模型几乎总是优于SFT模型。

图片

PPO 的训练曲线如下所示。值得注意的是,几个1B型号的KL值爆炸了。从优化的角度来看,这并没有什么问题,因为RLHF奖励一直在上升,这些1B模型对应于“奖励黑客”/过度优化的模型。

图片

为了更好地理解模型的行为,研究人员还可视化突出显示了经过微调的模型在生成文本时总会以一个EOS token结束。为了进一步探索这一点,原论文附录部分提供了更多类似的可视化效果。

图片

论文链接:https://arxiv.org/abs/2403.17031。
GitHub链接:
[1]https://github.com/vwxyzjn/summarize_from_feedback_details。

[2]https://github.com/vwxyzjn/summarize_from_feedback_details/blob/main/visualize_tokens.py。
参考链接:https://x.com/vwxyzjn/status/1773011925666050313?s=20。

责任编辑:姜华 来源: 量子位
相关推荐

2013-10-16 09:28:14

亚马逊AWSSDN

2013-10-16 09:33:36

亚马逊AWSSDN

2011-08-11 17:05:26

2014-01-07 10:46:39

2024-07-11 08:34:48

2022-02-11 10:47:17

CIOIT团队企业

2019-11-27 10:40:34

数据工具CIO

2023-05-08 14:54:00

AI任务HuggingGPT

2009-07-28 10:36:58

云计算Google秘密武器

2019-11-27 10:38:37

数据分析数据准备工具

2023-02-24 10:26:34

语音AI人工智能

2011-06-02 10:24:11

iTravel苹果

2024-07-01 12:54:39

2015-03-30 16:58:05

秘密武器华为

2023-09-25 15:29:44

Go并发Goroutines

2015-06-08 09:50:07

Android M谷歌

2019-02-27 09:44:01

CIO秘密武器顾问

2024-09-11 12:43:59

2017-09-25 18:33:00

美国硅谷互联网

2024-03-15 08:32:20

JavaScriptRust系统编程
点赞
收藏

51CTO技术栈公众号