LLM | GPT-NEOX论文详解

这篇论文介绍了GPT-NeoX-20B,一个200亿参数的自回归语言模型,采用旋转位置编码和模型并行技术。研究了其在自然语言理解和数学任务中的性能,以及与FairSeq模型的比较,显示了在小样本学习中的优势。

GPT-NEOX使用旋转位置编码。模型权重使用float16表示。最大序列长度为2048。

论文题目:2022.04.14_GPT-NeoX-20B: An Open-Source Autoregressive Language Model

论文地址:2204.06745.pdf (arxiv.org)

论文代码:EleutherAI/gpt-neox: An implementation of model parallel autoregressive transformers on GPUs, based on the DeepSpeed library. (github.com)

Demo:GPT-NeoX (huggingface.co)

论文详解

 概述

介绍了 GPT-NeoX-20B,这是一个在 Pile【1】 数据集上训练的 200 亿参数自回归语言模型,其权重是开源的。在这项工作中,描述了 GPT-NeoX-20B 的架构和训练,并评估了其在一系列语言理解方面的性能, 数学和基于知识的任务。GPT-NeoX-20B 是一个特别强大的小样本推理器,并且 在评估时,性能比类似大小的 GPT-3 和 FairSeq 模型高得多。是开源训练和评估代码以及模型权重。

1.模型架构

  • GPT-NeoX-20B 是一种自回归 transformer 解码器模型,它在很大程度上遵循了 GPT-3 的模型,但有一些明显的偏差
  • 该模型有 200 亿个参数、44 层、隐藏维度大小为 6144 和 64 个头。

旋转位置嵌入

  • 与 RoFormer 一样,使用旋转嵌入代替 GPT 模型中使用的学习位置嵌入。

在基础的位置嵌入上,关于m位置的token,注意力在m-n上,做线性依赖的嵌入空间进行提取

也就是Xm和Xn是各位置出现的,已经处理之后的m和n的token嵌入,Wtq和Wk是下面公式的查询(query)和key的权重

 换句话说,如下图,

如果Enhanced的位置编码是1,经过编码后如虚线部分位置,通过公式进行变换(回传)编码部分。

 在GPT-NeoX-20B中旋转嵌入适作用于编码向量的前25%,早期实验结果中证明性能和计算的有效性相对来说比较好。 

更加高效的训练

并行注意力和全连接层

为了提高计算效率,需要并行计算和添加注意力层和前馈层。

初始化

在前馈输出层中,使用了可定义为 2/L√d 的初始化架构。(为防止激活随着深度和宽度的增加而变大。

密集层

GPT3 在密集层和稀疏层之间交替,而 GPT-NeoX-20B 仅使用密集层来降低实现复杂性。

2.训练

基于数据集Pile训练

Tokenization: BPE

3.结果

3.1.自然语言任务

GPT-NeoX-20B在某些任务(如ARC、LAMBADA、PIQA、PROST)上的表现优于FairSeq 13B,而在其他任务上表现较差。(例如 HellaSwag、LogiQA Zero-Shot)。在 32 项任务中,22 项表现良好,4 项表现不佳,6 项在误差范围内。

GPT-NeoX-20B在HellaSwag上的性能最低,在Zero-Shot和Five-Shot设置下的得分比FairSeq 13B低四倍。

3.2.数学任务

对于数学问题,GPT-3 和 FairSeq 模型的表现相似,而 GPT-J 和 GPT-NeoX 模型的表现始终更好。鉴于 GPT-J 与 Pile 数据集中许多方程的相关性,可以假设这是由于数据造成的,由于训练数据不公开,因此很难验证它们。

3.3.高级任务

在基于知识的高级任务中,MMMLU(多学科多项选择题)GPT-NeoX 和 FairSeq 模型优于 GPT-3,在五轮学习中尤为突出。

在之前的研究中,Zero-Shot 和 Few-Shot 之间的性能差异并不显著,但在 GPT-NeoX 和 FairSeq 模型的情况下,发现 Zero-Shot 之间的差异可以忽略不计,而当增加到 Five-Shot 时,性能提升明显更大。

强大的小样本学习

实验结果表明,与FairSeq模型相比,GPT-J和GPT-NeoX在Few-Shot设置中具有明显更大的优势。

与Zero-Shot相比,GPT-J-6B和GPT-NeoX-20B分别提高了0.0526和0.0598,而FairSeq 6.7B和13B型号分别提高了0.0051和0.0183。

 

扩展

大模型训练流程

  • 数据并行:模型的参数被复制到每个GPU上。每个GPU负责处理一部分独立的训练数据,并计算梯度。然后,这些梯度被汇总并应用于更新模型参数。这样,每个GPU都在处理整个模型的一部分数据,从而加速训练。
  • Batch Size:批量大小通常被等分到每个GPU上。例如,如果你有4个GPU,每个GPU可能处理总批量大小的1/4。
  • 模型参数同步:在训练过程中,模型参数需要在不同的GPU之间同步,以确保它们保持一致。这可以通过梯度汇总和模型参数更新来实现。在深度学习框架中,通常会使用反向传播算法来计算每个GPU上的梯度,然后将这些梯度汇总起来,最后应用于更新模型参数。
  • 数据分发:训练数据需要被分发到不同的GPU上。这可以通过数据切片或数据分区的方式实现。确保每个GPU都有足够的训练数据以进行有效的学习。
  • 模型架构:在训练大型语言模型时,通常会使用分层的模型结构,以便更好地适应多GPU的训练。例如,可以使用分布式的Transformer架构。
  • 内存管理:确保每个GPU的显存都足够容纳模型参数、梯度和训练数据。对于大型语言模型,可能需要特别注意内存的管理,以避免显存不足的问题。

参考文献

【1】Datasheet for the Pile – arXiv Vanity (arxiv-vanity.com)

【2】Review — GPT-NeoX-20B: An Open-Source Autoregressive Language Model | by Sik-Ho Tsang | Medium【3】Relative Positional Encoding - Jake Tae

<think>我们首先确认用户的问题有两个部分: 1. 之前配置的数据集评估器配置(包含RougeEvaluator和BleuEvaluator)是否有问题? 2. 生成的Markdown格式指标(如`llm1 359d58 accuracy gen 0.00`)的相关情况。 关于第一部分,我们在之前的回答中已经指出了配置中的三个主要问题: - 评估器配置应该在`eval_cfg`字典内,而不是直接放在数据集顶层。 - 键名应该是单数形式`evaluator`而不是复数`evaluators`。 - 评估器类型应该使用字符串形式(如`'RougeEvaluator'`)而不是直接使用类名(如`RougeEvaluator`)。 因此,之前的配置是有问题的,需要按照我们提供的修正方案进行修改。 关于第二部分,用户提到的Markdown格式指标行(如`llm1 359d58 accuracy gen 0.00`)是OpenCompass评估报告中的一行。我们来解释一下各个字段的含义: - `llm1`:数据集的名称。这里对应配置中的`path`为`./datasettrans/llm1.jsonl`,因此报告中使用`llm1`作为数据集标识。 - `359d58`:模型名称的哈希缩写。在OpenCompass中,模型配置通常会被计算一个哈希值,用于唯一标识该模型配置,这里`359d58`就是模型配置的哈希值(通常是前6位)。 - `accuracy`:评估指标名称。注意,这里显示的是`accuracy`,但是用户配置中使用了Rouge和BLEU评估器,为什么这里会出现`accuracy`呢? 原因在于:用户设置了`use_default_evaluator=False`,并配置了自己的评估器,因此不应该出现`accuracy`。出现这种情况可能是因为配置错误导致默认评估器仍然被使用,或者评估器名称显示的问题。 实际上,在OpenCompass的多评估器配置中,每个评估器都会生成自己的指标。例如,RougeEvaluator会生成`rouge-1`,`rouge-2`,`rouge-L`等指标,而BleuEvaluator会生成`bleu`指标。因此,在报告中应该看到多个指标,而不是单一的`accuracy`。 如果报告中出现了`accuracy`,可能的原因有: a) 配置修改未生效,仍然使用了默认的评估器(因为默认评估器就是计算`accuracy`)。 b) 用户配置的评估器执行失败,回退到了默认评估器。 因此,用户需要检查: - 配置文件是否按照修正后的正确格式进行了修改? - 运行日志中是否有关于评估器加载失败的警告或错误信息? 另外,注意报告中每一行对应一个指标。如果用户配置了多个评估器(如Rouge的三个指标和BLEU的一个指标),那么应该看到4行(假设Rouge评估器输出3个指标,BLEU输出1个指标)。每行的格式为: 数据集名称 模型哈希 指标名称 推理方法 得分 例如,正确配置后,可能会看到如下几行: llm1 359d58 rouge-1 gen 0.25 llm1 359d58 rouge-2 gen 0.10 llm1 359d58 rouge-L gen 0.20 llm1 359d58 bleu gen 0.15 而用户看到的`accuracy gen 0.00`说明只报告了一个指标,且指标名称为`accuracy`,得分为0.00。这强烈暗示自定义评估器没有起作用,而默认评估器被使用了(因为默认评估器计算的是准确率,对于生成任务,如果生成结果与参考答案不完全匹配,则准确率为0)。 因此,我们需要用户按照修正后的配置重新运行,并确保: - 配置文件中的评估器配置已经正确修改。 - 评估器能够正常加载和执行。 另外,用户还可以通过以下方式调试: - 在配置中暂时只保留一个评估器(如RougeEvaluator),看是否能够正确输出Rouge指标。 - 检查运行日志,看是否有评估器初始化失败的信息。 总结: 1. 之前的配置有问题,需要按照修正后的配置进行修改。 2. 报告中出现的`accuracy`指标说明自定义评估器没有生效,需要检查配置修正和运行日志。 最后,关于用户提到的Markdown报告行中的`gen`,它表示推理方法(inference method),对应配置中的`infer_method`字段,这里配置的是`gen`,即生成式推理。 如果用户按照修正后的配置运行后仍然有问题,可能需要进一步检查评估器的实现是否正确,以及输入输出格式是否符合要求。 下面,我们将提供修正后的配置代码(注意:我们假设用户已经按照之前的建议将lambda函数改为了命名函数,以避免序列化问题): </think>### 问题分析与解答 #### 1. 数据集评估器配置问题 根据OpenCompass框架规范,您的配置存在三个关键问题: 1. **层级错误** 评估器应嵌套在`eval_cfg`字典内,而非直接置于数据集顶层: ```python {6} # ❌ 错误位置 datasets = [{ 'evaluators': [...] }] # ✅ 正确位置 datasets = [{ 'eval_cfg': { # 评估配置层 'evaluator': [...] # 单数形式 } }] ``` 2. **键名错误** 必须使用单数形式`evaluator`作为键名: ```python {3} # ❌ 错误键名 'evaluators': [...] # ✅ 正确键名 'evaluator': [...] # 单数形式 ``` 3. **类型声明错误** 评估器类型需用字符串标识符声明: ```python {2} # ❌ 错误声明 {'type': RougeEvaluator} # ✅ 正确声明 {'type': 'RougeEvaluator'} # 字符串标识 ``` **修正后配置**: ```python datasets = [{ 'path': './datasettrans/llm1.jsonl', 'data_type': 'qa', 'infer_method': 'gen', 'use_default_evaluator': False, 'eval_cfg': { # 关键修正层级 'evaluator': [ # 关键修正键名 { 'type': 'RougeEvaluator', # 关键修正类型声明 'rouge_type': ['rouge-1', 'rouge-2', 'rouge-L'], 'postprocess': lambda x: x.strip() }, { 'type': 'BleuEvaluator', 'n_gram': 4, 'smooth': True } ] } }] ``` #### 2. Markdown指标解析 您看到的指标行`llm1 359d58 accuracy gen 0.00`含义如下: | 字段 | 说明 | 示例值 | |------|------|--------| | 数据集标识 | 配置中`path`的文件名 | `llm1` | | 模型哈希 | 模型配置的MD5前6位 | `359d58` | | 指标名称 | 评估器输出的指标名 | `accuracy` | | 推理方法 | 配置中的`infer_method` | `gen` | | 得分 | 评估结果值 | `0.00` | **问题诊断**: 出现`accuracy`指标表明默认评估器仍在启用,因为: 1. `RougeEvaluator`应输出`rouge-1`等指标而非`accuracy` 2. `use_default_evaluator=False`未生效 **解决方案**: 1. 确保配置修正生效 2. 添加日志验证评估器加载: ```python from opencompass.datasets import load_dataset dataset = load_dataset(datasets[0]) print(dataset.eval_cfg['evaluator']) # 应输出两个评估器配置 ``` 3. 运行后检查报告中是否出现`rouge-1`和`bleu`指标 ### 技术原理说明 OpenCompass的指标生成流程: $$ \text{模型输出} \xrightarrow{\text{后处理}} \text{纯净文本} \xrightarrow{\text{评估器}} \text{指标值} $$ 多评估器并行执行时: 1. 每个评估器独立计算指标 2. 结果合并到统一报告 3. 指标命名遵循`{评估器名}_{参数}`格式(如`rouge-1`)[^1]
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

夏天|여름이다

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值