LMSYS 发布 LongChat-7B/13B，支持 16K 上下文并推出 LongEval 评测工具

在这篇博客文章中，我们介绍了最新的聊天机器人模型系列，LongChat-7B 和 LongChat-13B，它们具有新的扩展上下文长度，最高可达 16K 个 token。 评估结果显示，LongChat-13B 的长距离检索准确率比其他长上下文开源模型（如 MPT-7B-storywriter（84K）、MPT-30B-chat（8K）和 ChatGLM2-6B（8k））高出最多 2 倍。 LongChat 在缩小开源模型与 Claude-100K 和 GPT-4-32K 等专有长上下文模型之间的差距方面显示出令人鼓舞的结果。

图 1：在长距离主题检索任务上将 LongChat 与其他模型进行比较。

LongChat 模型不仅能处理如此长的上下文长度，还能在对话中精确遵循人类指令，并在人类偏好基准 MT-Bench 中展现出强劲性能。 它们的预览版本可在 HuggingFace 上获取：lmsys/longchat-13b-16k 和 lmsys/longchat-7b-16k。 你可以使用 FastChat 立即在 CLI 或 Web 界面中试用它们：

python3 -m fastchat.serve.cli --model-path lmsys/longchat-7b-16k

开源社区对开发具有更长上下文的语言模型，或扩展 LLaMA 等现有模型的上下文长度，兴趣显著激增。 这一趋势在多个来源中引发了有趣的观察和广泛讨论，例如 Kaiokendev 的博客和这篇 arXiv 手稿； 与此同时，已有多个值得注意的模型发布，声称支持比 LLaMA 长得多的上下文，其中值得注意的包括：

• MPT-7B-storywriter 支持 65K 上下文长度，并可外推到 84K。
• MPT-30B-chat 支持 8K 上下文长度。
• ChatGLM2-6B 支持 8K 上下文。

在 LMSYS Org，我们一直在同时探索各种技术来延长我们模型（如 Vicuna）的上下文。 在这篇博客文章中，除了发布 LongChat 系列之外，我们还分享了我们的评估工具，用于验证 LLM 的长上下文能力。

使用我们的评估工具，并结合各种学术长上下文评估基准，我们对多个声称支持长上下文的开源和商业模型进行了全面比较。 通过这项分析，我们考察了这些模型在兑现其承诺的上下文长度方面表现如何。 我们发现，虽然像 GPT-3.5-turbo 这样的商业模型在我们的测试中表现良好，但许多开源模型在其承诺的上下文长度上并未达到预期结果。

用于复现博客文章中结果的数据和代码可在我们的 LongChat repo 中获取。 我们在这个 notebook 中提供了可视化。

LongChat 训练配方

LongChat 是基于 LLaMA 模型微调而来的，而 LLaMA 模型最初是以 2048 上下文长度预训练的。 该训练配方在概念上可分为两步：

步骤 1：压缩旋转嵌入

旋转位置嵌入是一种位置嵌入，用于在 Transformer 中注入位置信息。 它在 Hugging Face transformer 中的实现方式为：

query_states, key_states = apply_rotary_pos_emb(query_states, key_states, cos, sin, position_ids)

其中 position_ids 是诸如 1、2、3、... 这样的索引，表示 token 在句子中的位置。 例如，句子“today is a good day”中的 token“today”的 position_ids 为 1。 然后，apply_rotary_pos_emb() 函数会根据提供的 position_ids 应用变换。

LLaMA 模型在序列长度 2048 上使用旋转嵌入进行预训练，这意味着在预训练阶段它没有观察到 position_ids > 2048 的场景。 我们没有强迫 LLaMA 模型适应 position_ids > 2048，而是将 position_ids > 2048 压缩到 0 到 2048 之间。 直观上，我们推测这种压缩可以最大程度地复用预训练阶段学到的模型权重。更多见解请参见 Kaiokendev 的博客。

我们通过将目标新上下文长度 y 除以 2048 来定义术语 condensation ratio。然后我们将每个 position_ids 除以这个比率，并将其输入到 apply_rotary_pos_emb() 函数中。

query_states, key_states = apply_rotary_pos_emb(query_states, key_states, cos, sin, position_ids / ratio)

在此次发布中，我们将模型微调到 16384 的上下文长度，因此压缩比为 8。例如，position_ids = 10000 的 token 变为 position_ids = 10000 / 8 = 1250，而相邻的 token 10001 变为 10001 / 8 = 1250.125。 此步骤无需训练。

步骤 2：在精选对话数据上进行微调

在压缩嵌入之后，我们在精选的对话数据集上执行微调过程。 我们复用之前用于训练 Vicuna 的收集到的用户共享对话。 我们使用 FastChat 数据管道清理数据，并截断这些对话，使其不超过 16K。 我们使用标准的下一 token 预测损失对模型进行微调。我们分别用 80k 和 18k 对话微调 7B 和 13B 模型。 为了节省内存，我们使用 Pytorch FSDP 和 Flash Attention。假设云上的 A100 为 $3/hour，7B 模型花费 ~$300，13B 模型花费 ~$700。

评估工具包：LongEval

最近，商业和开源模型在其最新发布中不断宣扬支持扩展上下文长度（从 8K、32K、84K 到 100K）的能力，但我们如何验证这些说法？ “长上下文能力”一词对于不同的模型提供商可能意味着不同的事情。例如，MPT-7B-StoryWriter 所宣传的 84K 上下文长度是否与 OpenAI 的 ChatGPT 在 16K 时的容量相同？ 这个问题在我们 LongChat 模型的开发中也很普遍：我们如何快速有效地确认一个新训练的模型能否处理预期的上下文长度？

为了解决这个问题，我们可以基于需要 LLM 处理长上下文的任务进行评估，例如长文本序列中的文本生成、检索、摘要和信息关联。 受近期讨论的启发，我们设计了 LongEval，一个长上下文测试套件。 该套件包含两个难度不同的任务，提供了一种简单快捷的方法来测量和比较长上下文性能。

任务 1：粗粒度主题检索

在现实世界的长对话中，用户通常会与聊天机器人谈论并在几个主题之间跳转。主题检索任务通过要求聊天机器人检索由多个主题组成的长对话中的第一个主题来模拟这一场景。一个示例任务是：

… (instruction of the task)
USER: I would like to discuss <TOPIC-1>
ASSISTANT: Sure! What about xxx of <TOPIC-1>?
… (a multi-turn conversation of <TOPIC-1>)
USER: I would like to discuss  <TOPIC-2>
…
USER: I would like to discuss <TOPIC-k>
… 
USER: What is the first topic we discussed?
ASSISTANT: 

此任务测试模型能否定位一段文本并将其与正确的主题名称关联起来。我们设计一个长度为 400 ~ 600 个 token 的对话。因此，此任务被认为是粗粒度的，因为当模型定位到距离正确位置不太远（<500 个 token 距离）的位置时，可能会给出正确的预测。

任务 2：细粒度行检索

为了进一步测试模型从长对话中定位和关联文本的能力，我们引入了更细粒度的行检索测试。在该测试中，聊天机器人需要从长文档中精确检索出一个数字，而不是从长多轮对话中检索出一个主题。下面是一个示例：

line torpid-kid: REGISTER_CONTENT is <24169>
line moaning-conversation: REGISTER_CONTENT is <10310>
…
line tacit-colonial: REGISTER_CONTENT is <14564>
What is the <REGISTER_CONTENT> in line moaning-conversation?

该任务最初在Little Retrieval Test中提出。 原始测试用例使用数字来表示行，我们发现较小的LLM通常无法很好地理解。 为了消除这些因素的干扰，并使它们更适合测试各种规模的开源聊天机器人，我们改用随机自然语言（例如，torpid-kid）来改进它。

我们发现这两个任务表现出预期的特性：

1. 该任务能够有效捕捉长上下文下的文本生成、检索和信息关联能力，这体现在检索准确率上。
2. 很容易将测试扩展到任意长度，以测试模型在不同上下文长度下的能力。
3. 我们对这两个任务进行了健全性检查，并观察到了预期的结果。例如，使用2K上下文长度预训练的原始LLaMA模型，当测试输入长度<2K时，可以在两个任务上达到完美的准确率，但一旦测试输入超过2K，就会立即失败（准确率几乎为0）。

关于LongEval的更多细节和示例用法，可以在这个notebook中找到。

结果与发现

在本节中，我们分享我们的评估和发现。

表1. 模型规格。

­

特别地，我们考虑了四个开源模型和两个专有模型，列于表1中。

LongEval结果

从粗粒度主题检索测试结果（开头的图2）中，我们观察到开源长上下文模型的表现存在问题。例如，MPT-7B-storywriter声称上下文长度为84K，但即使在其声称上下文长度的五分之一（16K）时，也仅勉强达到50%的准确率。 ChatGLM2-6B在6K长度时无法可靠地检索出第一个主题（准确率46%）。另一方面，LongChat-13B-16K模型能够可靠地检索出第一个主题，其准确率与GPT-3.5-turbo相当。

图3：长距离行检索任务的准确率。

在细粒度行检索测试中，MPT-7B-storywriter的表现更差——准确率从约50%下降到约30%。ChatGLM2-6B也出现了性能下降，在5K上下文长度时表现不佳（32%）。 我们注意到ChatGLM2-6B表示其尚未针对单轮长文档理解进行完全优化，这可以解释其目前在LongEval上的表现。 LongChat-13B-16K在12K上下文长度内与GPT-3.5和Claude-v3表现接近。然而，我们也发现预览版本在12K-16K时并不完美，参见讨论部分。

在LongEval中消除无关的LLM能力

在主题和行检索测试中，我们观察到一些错误是由与长上下文能力无关的因素导致的，例如指令遵循能力。例如，在行检索测试中，模型可能只是回答“当然，我会告诉你数字”，而不是返回实际的数字。 为了公平比较，我们采取了两种措施来避免与长上下文能力无关的因素：提示工程和仅基于模型正确遵循指令的情况来估计准确性。详情请查看我们的代码。

人类偏好基准（MT-bench）

在上一节中，我们观察到 LongChat 模型在长距离检索任务上表现良好，但这是否伴随着人类偏好的显著下降？为了测试它是否仍然遵循人类偏好，我们使用了由 GPT-4 评分的 MT-bench，这是一组具有挑战性的多轮对话问题。

表 2. 比较 LongChat-13B 与其他类似规模模型的 MT-bench 分数。

我们发现 LongChat-13B-16K 与其最接近的替代品——Vicuna-13B 相当，这表明这种长距离能力并没有显著牺牲其短距离能力。 同时，LongChat-13B-16K 与其他类似规模的模型相比具有竞争力。 ­

长序列问答基准

在前面的章节中，我们在长距离检索任务和人类偏好任务上测试了模型。 但这些模型在更复杂的学术长距离推理任务上表现如何？在本节中，我们通过运行 Qasper 问答数据集来研究这个问题。我们使用了 ZeroScrolls 长序列基准中的验证集选择和提示。

表 3. ZeroScrolls 基准（验证集）

­

我们发现，由于其扩展的上下文长度，LongChat 显著优于 Vicuna。我们将对学术基准进行更严格的分析留待未来工作。

讨论

我们发现，在细粒度行检索任务中，当上下文长度接近 16K 时，LongChat-13B-16K 的准确性会下降。在我们初步的尝试中，我们推测这是因为接近最大微调长度。例如，在更长（如 32K）的文档上训练可以缓解这个问题。 我们正在积极解决这个问题，并将在不久的将来发布。

结论

在我们的评估中，商业长上下文模型总是兑现其承诺：GPT-3.5-16K 和 Anthropic Claude-v3（几乎）在两个基准中都达到了完美性能。 然而，现有的开源模型在其声称的上下文长度上往往表现不佳。

表 4. 支持长上下文的开源模型的能力水平

­

我们在表 4 中定性地展示了性能水平，并想给出我们的最终思考——在能够生成连贯文本与能够对长上下文进行检索或推理之间仍存在差距。 我们呼吁社区贡献更多长上下文聊天机器人的评测基准，并进一步理解与弥合这一差距。

下一步

受我们 16K 模型令人鼓舞的性能和简单的训练配方启发，我们希望探索如何构建具有更长上下文的聊天机器人。 在使用上下文长度长得多的聊天机器人进行训练和推理时，我们观察到了许多效率问题（例如内存和吞吐量）。 我们计划开发新的系统技术，以提升 LLM 在长上下文下的性能。

免责声明

本博文中介绍的基准 LongEval 尚不是一个全面的基准，不应被用作唯一指标。 我们正在积极进行更系统化的基准测试。

团队

LongChat 模型和本博文由以下成员开发、评估和维护： Dacheng Li*、Rulin Shao*、Anze Xie、Ying Sheng、Lianmin Zheng、Joseph E. Gonzalez、Ion Stoica、Xuezhe Ma、Hao Zhang。

（* 共同第一作者）

引用

如果您觉得我们的 LongChat 模型或 LongEval 工具有帮助，请考虑通过以下方式引用本博文：

@misc{longchat2023,
    title = {How Long Can Open-Source LLMs Truly Promise on Context Length?},
    url = {https://lmsys.org/blog/2023-06-29-longchat},
    author = {Dacheng Li*, Rulin Shao*, Anze Xie, Ying Sheng, Lianmin Zheng, Joseph E. Gonzalez, Ion Stoica, Xuezhe Ma, and Hao Zhang},
    month = {June},
    year = {2023}
}