• 作者:老汪软件技巧
  • 发表时间:2024-09-18 21:56
  • 浏览量:

一、“2% GPT size, yet powerful.”模型简介

Index-1.9B-32K 是一个拥有 1.9B (19亿)参数并具备 32K 上下文长度的语言模型(这意味着,这个超小精灵可以一次性读完 3.5 万字以上的文档)。

在多项长文本评测任务中,该模型在相近尺寸的模型中表现突出。以极小的体积和算力开销(仅仅约为 GPT-4 的 2%),实现了出色的长文本处理能力。 如下图所示,我们的 1.9B 模型得分甚至远超 7B 大小的模型。以下是与 GPT-4、千问Qwen2 等模型的对比:

Index-1.9B-32K与GPT-4、Qwen2等模型长文本能力对比

该模型针对 32K 长文本进行了持续预训练(Continue Pre-Training)和监督微调(SFT),训练数据主要来源于我们精心清洗的长文本预训练语料以及自建的长文本指令集。

Github上模型、技术报告等下载应用示例(英文财报翻译&总结)

运行我们已开源的交互工具,翻译并总结哔哩哔哩公司于2024.8.22发布的英文财报(英文财报原文:*/bilibili/In…

二、训练过程

Index-1.9B-32K基于我们已经开源的 Index-1.9B 进行继续训练,进行了额外两个阶段的训练:

1. Long PT:Long continue Pre-Training,长文本继续预训练,基于长数据进行持续预训练。

2. Long SFT:长文本监督微调,基于长指令进行 SFT。

*(RLHF / DPO) :尽管我们已经具备强化学习(RLHF)、DPO 等对齐训练的经验,但是这个版本还未经过RLHF/DPO训练(后续版本将补充RLHF/DPO),我们仍然优先集中精力攻克模型在长文本处理方面的深层次能力上。

Index-1.9B-32K的训练流程

模型超参数Context长度相关的参数Rope Base 的确定

Rope Base与困惑度关系

阶段1:继续预训练(32K)

我们基于自建的长文本语料库进行了持续预训练。我们精心清洗了 100B+ 的长文本数据,在训练了 10B 之后,模型的长文本性能提升已比较显著。

Long PT训练参数长文本语料

我们基于自建的海量语料池,构建了长文本预训练语料库。互联网上搜集到的大多数语料的 Token 量比较短,我们进行了统计,不同Token数量的区间统计如下:

我们的语料库 Token 长度分布

阶段2:SFT(32K)

SFT 训练损失曲线

Long SFT训练参数三、 效果与评测长文本能力评测NeedleBench(大海捞针)

大海捞针评测

_开源文本模型能装站长软件吗_开源文本编辑器

LongBench和LEval

评测分数对比如下图,我们1.9B尺寸的模型分数甚至远超7B尺寸的模型:

Index-1.9B-32K与GPT-4、Qwen2等模型长文本能力对比

Alignment和短能力评测

虽然Index-1.9B-32K的长文本能力获得极其优异的结果,但短文本能力有所下降。我们使用了基于自建 benchmark 的评测,结果显示模型的“短文本能力”在多个评测指标上均有下降。在自建 benchmark 的评测中,性能下降了约 25%,因此,平衡模型的“长短文本能力”也将是我们未来的一个主要工作。

对 OpenCompass 的优化

在进行长上下文相关的评测时,我们遇到以下问题并进行了优化,这一优化已被 OpenCompass 合并到官方最新仓库,详见 opencompass/commit(*/open-compas… 。

问题

在评估过程中,序列长度可能会超过模型的 max_seq_len,尤其是在长上下文评估中,这导致两个问题:

prompt被截断,只有一部分进入模型,导致关键信息(例如关键问题)丢失,模型无法理解prompt的意图。

在继续生成时,总长度超过max_seq_len 并出现以下警告:This is a friendly reminder - the current text generation call will exceed the model’s predefined maximum length (32768). Depending on the model, you may observe exceptions, performance degradation, or nothing at all.

解决方案

保留前 (0.5 * max_prompt_len) 的 tokens 和后 (0.5 * max_prompt_len )的 tokens,丢弃中间部分,因为Prompt中的问题通常位于开头或结尾。

四、其他上下文扩展技术的研究

我们对比了免训练的上下文长度扩展方法,例如 Dynamic NTK 、Naive Extrapolation(直接外推)等。

Dynamic NTK(Neural Tangent Kernel)是一种可用于扩展大模型上下文窗口长度的方法,主要原理是随着上下文长度的变化而动态地调整位置编码,以适应新的上下文长度,该方法不需要进行训练便能达到扩展上下文长度的目的。其中,我们对 Dynamic NTK 使用了多种 scaling factor,本文评测时使用的 scaling factor 为 8。各种技术的长上下文效果对比如下图。

各种Long Context方法的效果对比

五、讨论

当然,我们还进行了很多失败的尝试,不完全列举如下。

失败尝试1:上下文长度预热(Context Length Warmup)

我们最初认为 LLM 对文本长度的感知能力应当逐步从短到长提升,因此尝试构建长度递增的数据集并按顺序进行训练。模型的损失(Loss)在初期下降迅速,但随后出现反弹且无法进一步下降。我们推测这可能与数据分布不均有关,后续将对此展开更深入的研究。

上下文长度预热训练的验证集损失曲线

失败尝试2:Packing VS Non-Packing

我们认为Doc Packing 方式的训练可能会影响梯度下降,特别是在混合不同长度指令时。然而,实验结果显示,两种训练方式的差异极小(小于 1%)。

失败尝试3:1‰ 长指令 SFT

我们注意到 LLaMA 3 的Paper中提到他们只使用了 1‰ 的长指令进行微调,我们对这一结果感到好奇,于是进行了实验,实验结果为负向。

写在最后

本文对我们的长文本大模型(Long Context)工作做了简略介绍,我们仍在持续更新、升级 Long Context 能力,请关注后续进展,欢迎交流。