早先发布Vicuna模型和大语言模型排位赛的LMSYS Org（UC伯克利主导）的研究人员又开始搞事情了。
这次，他们开发出了一个支持长上下文的开源大模型家族LongChat-7B和LongChat-13B，支持高达16K token的上下文长度。
但是吧，其实市面上早已出现支持65K（MPT-7B-storyteller）和32K（CHatGLM2-6B）token的选手了。
图片
抱着一边向他们虚心学习一边质疑的研究者心态，他们设计一个专门评估大语言模型处理长上下文任务的性能的工具，测了测一众号称支持长上下文的模型们性能到底怎么样。
不测不知道，一测发现之前宣称能支持长上下的开源模型几乎水平都不怎么样，而自家的LongChat在一众「开源李鬼」里才是真的李逵。
而商业闭源大模型的长上下文能力，是真的不错，各个都很能打。
图片
在长距离主题检索任务上比较LongChat和其他模型
长上下文「打假」
根据研究人员测试的结果，闭源的商业长上下文模型确实能兑现它们的承诺：gpt-3.5-16k和Anthropic Claude在基准测试中几乎都达到了完美的性能。
然而，现有的开源模型在长上下文长度方面的表现却比自己「声称」的要差很多。
图片
大语言模型支持长上下文能力的等级
全新LongChat开源模型，支持16k上下文
LongChat模型不仅可以处理高达16k token的上下文长度，而且还能准确地遵循对话中的人类指令，并在人类偏好基准MT-Bench中展示出强大的性能。
预览版本可在HuggingFace上获得：
- lmsys/longchat-13b-16k
- lmsys/longchat-7b-16k
感兴趣的同学可以在命令行界面或Web界面中使用FastChat来跑一下试试：
Python
python3 -m fastchat.serve.cli --model-path lmsys/longchat-7b-16k在研究团队的LongChat存储库中可以找到用于重现研究结果结果的数据和代码，研究人员还贴心地提供了可视化效果展示。
那么我们来看看LongChat是怎么一步一步从LLaMA的2048个token的上下文长度训练到16K的。
第一步：压缩旋转嵌入（ Rotary embedding）
旋转位置嵌入是一种将位置信息注入Transformer的位置嵌入方法。
在Hugging Face的Transformer库中，它的实现方式如下：
Python
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之间。
直观地说，研究人员假设这种压缩可以最大程度地重用在预训练阶段学到的模型权重。
他们通过将目标新上下文长度y除以2048来定义压缩比率。
然后将每个position_ids除以这个比率，并将其输入apply_rotary_pos_emb()函数。
Python
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，而相邻的token10001变为10001 / 8 = 1250.125。
这个技术最先由开源社区的一个叫Kaiokendev的开源爱好者发现（https://kaiokendev.github.io/context）并传播和讨论。LMSys Org的研究人员发现这个技术确实很好使，而且这一步只需要改一行代码，不需要进行训练。
第二步：微调精选的对话数据库
在压缩嵌入之后，研究人员使用他们精心挑选的对话数据集执行微调过程。
研究团队重新使用了先前用来训练Vicuna的用户分享对话数据。
使用FastChat数据处理流程清理数据，截断了这些对话，使其长度不超过16K。
然后再使用标准下一个token预测损失对模型进行微调。
最后他们分别使用80,000个和18,000个对话对7B和13B模型进行微调。
假设在云上使用A100花费每小时3美元，7B模型的成本约为300美元，而13B模型的成本约为700美元。
上下文能力验证工具：LongEval
为了验证商业闭源和开源模型宣传支持的长上下文能力（从8K、32K到100K）到底有多强，研究团队开发了一套验证工具包。
不同的模型作者可能对所谓的「长上下文能力」对有着不同的理解。
举个例子，MPT-7B-StoryWriter所宣称的65K上下文长度是否与OpenAI的ChatGPT在16K上下文长度下具有相同的性能？
在LongChat开发过程中，同样的问题也困扰着研究团队。
如何迅速有效地确认一个新训练的模型是否能够真地有效处理预期的上下文长度？
为了解决这个问题，研究团队可以基于需要LLM处理长上下文的任务进行评估。
例如文本生成、检索、摘要和长文本序列中的信息关联。
受最近的研究启发，研究人员们设计了一个名为LongEval的长上下文测试套件。
这个套件包括两个难度不同的任务，提供了一种简单快捷的方式来衡量和比较长上下文的性能。
任务一：粗粒度主题检索
在现实世界的长对话中，用户通常与聊天机器人的讨论会在多个主题间跳转。
研究团队使用主题检索任务来模拟这种场景。
这个任务会要求聊天机器人检索由多个主题组成的长对话中的第一个主题，来模拟这种情景。
示例任务如下：
Python
… (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组成的对话，并随机组合它们达到到想要测试的长度，将组合出来的长文本作为 Prompt.
所以，这是一个粗粒度的对话，因为当模型能够定位到距离正确位置不太远（<500个token距离）的位置时，它可能会给出正确的预测。
任务二：细粒度检索
为了进一步测试模型在长对话中定位和关联文本的能力，研究人员引入了更精细的行检索测试（Line Retrieval test）。
在这个测试中，聊天机器人需要精确地从长文档中检索一个数字，而不是从长对话中检索一个主题。
以下是一个示例：
Python
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的测试输入，准确性几乎为零。
研究人员通过这个原理，就能检测不同模型对于不同上下文长度时，执行信息检索和关联相关信息的能力。
测评结果
图片
根据粗粒度的主题检索测试结果，团队观察到开源的长上下文模型的性能似乎没有自己宣称得那么好。
例如，Mpt-7b-storywriter声称具有84K的上下文长度，但即使在它声称的上下文长度的四分之一（16K）处，准确率也仅达到50%。
Chatglm2-6B在长度为6K（46%准确率）时无法可靠地检索第一个主题。
当在大于10K的上下文长度上进行测试时，其准确率几乎为0%。
另一方面，研究人员观察到LongChat-13B-16K模型可靠地检索到第一个主题，并且准确率与gpt-3.5-turbo相当。
图片
在更细粒度的行检索测试中，Mpt-7b-storywriter的表现甚至比粗粒度情况下更差，准确率从约50%下降到约30%。
Chatglm2-6B也出现了下降，在研究人员测试的最短长度（5K上下文长度）上表现也不太好。
相比之下，LongChat-13B-16K表现可靠，在12K的上下文长度内接近gpt-3.5/Anthropic-claude的能力。
解开LongEval中与LLM能力无关的因素
在主题和行检索测试中，研究人员观察到一些错误是由与长上下文能力无关的因素引起的，比如指令跟随能力。
例如，在行检索测试中，模型可能会简单地回答「当然，我会告诉你这个数字」，而不是按照要求回答实际的数字。
为了进行公平比较，研究人员采取了两个措施来避免与长上下文能力无关的因素：
1）设计适当的提示词
2）仅在模型按照研究人员的指令执行的情况下计算准确率。
人类偏好基准（MT-bench）
在前面的部分中，研究人员观察到LongChat模型在长距离检索任务上表现良好，但这是否会导致人类偏好显著下降呢？
为了测试它是否仍然符合人类的偏好，研究人员使用了GPT-4评分的MT-bench，这是一组具有挑战性的多轮对话问题。
研究人员发现，LongChat-13B-16K与其最接近的替代模型Vicuna-13B相比，确实在MT-Bench分数上略有下降，但在可接受的范围内，这表明这种长距离能力并没有显著牺牲其短距离能力。
同时，LongChat-13B-16K与其他相同规模的模型相比也具有竞争力。
图片
讨论分析
研究人员发现，当上下文长度接近16K时，LongChat-13B-16K在细粒度的行检索任务上出现了准确率下降的情况。
在他们的初步尝试中，研究人员猜测这是因为接近最大的微调长度。
例如，使用更大的长度（例如32K）进行训练可以缓解这个问题。
研究人员正在积极努力解决这个问题，并计划在不久的将来发布中解决。
研究人员用表格形式定性地说明了性能水平，并且希望提出他们的最终思考：能够在一个上下文范围内生成文本，和真正的具备在宣称的上下文长度上能进行reasoning和检索，这两种能力是有很大差距的。
模型提供者通畅需要对模型进行良好的训练（例如使用高质量的长序列数据，或者像研究人员探索过的进行压缩），以实现良好的长上下文文本生成、检索和推理能力。
虽然闭源模型基本在研究人员设计出的检索测试上都能达到要求，但开源模型提供者在自己宣传支持的长下文长度上，水分很大。
研究人员呼吁社区为长上下文聊天机器人贡献更多的评估基准，并进一步理解和填补这一差距。
团队介绍
共同一作Dacheng Li
Dacheng Li目前是加州大学伯克利分校的博士生。本科毕业于加州大学圣地亚哥分校，硕士毕业于卡耐基梅隆大学机器学习专业。他的主要研究方向是机器学习和分布式系统的交叉领域。
共同一作Rulin Shao
Rulin Shao 目前就职于亚马逊AWS人工智能研究和教育中心，被录取为华盛顿大学博士。她本科毕业于西安交通大学，硕士毕业于CMU机器学习专业。
Anze Xie
Anze Xie目前就读于加州大学圣地亚哥分校计算机专业，本科毕业于维斯康星大学麦迪逊分校。
Xuezhe Ma
Xuezhe Ma目前是南加州大学计算机系的助理教授，本科和研究生毕业于上海交通大学，博士毕业于卡耐基梅隆大学。他的研究方向是提高表征学习的效率，有效性等。
团队的其他几位成员就是LMSYS Org发起人和老熟人了：盛颖，郑怜悯，Ion Stoica和张昊等。
参考资料：
https://lmsys.org/blog/2023-06-29-longchat/
