【新智元导读】最近，来自LMSYS Org的研讨人员不只一次发了两个支撑16k token上下文长度的开源大模型LongChat-7B和LongChat-13B。而且，他们还测验了声称支撑长上下文才能的几个大模型的实践体现，发现开源模型虚标严重。
早先发布Vicuna模型和大言语模型排位赛的LMSYS Org（UC伯克利主导）的研讨人员又开端搞工作了。
这次，他们开发出了一个支撑长上下文的开源大模型宗族LongChat-7B和LongChat-13B，支撑高达16Ktoken的上下文长度。
可是吧，其实市面上早已呈现支撑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来跑一下试试：
Pythonpython3 -m fastchat.serve.cli --model-path lmsys/longchat-7b-16k
在研讨团队的LongChat存储库中可以找到用于重现研讨成果成果的数据和代码，研讨人员还贴心地供给了可视化效果展现。
那么我们来看看LongChat是怎样一步一步从LLaMA的2048个token的上下文长度练习到16K的。
第一步：紧缩旋转嵌入（ Rotary embedding）
旋转方位嵌入是一种将方位信息注入Transformer的方位嵌入方法。
在Hugging Face的Transformer库中，它的完成方法如下：
Pythonquery_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()函数。
Pythonquery_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的开源爱好者发现（kaiokendev.github.io/context）并传播… 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）。
在这个测验中，谈天机器人需求精确地从长文档中检索一个数字，而不是从长对话中检索一个主题。
以下是一个示例：
Pythonline 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」）进行改进。
研讨人员发现这两个使命都具有这几预期的特点：
-
使命可以有用捕捉到文本生成、检索和长上下文信息相关的才能，终究反映在检索精确性上。
-
可以轻松将测验扩展到恣意长度，以测验模型在不同上下文长度下的才能。
-
研讨人员现已对这两个使命进行了检查，并调查到了预期的成果。
例如，关于运用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
RulinShao现在，被录取为华盛顿大学博士。她本科结业于西安交通大学，硕士结业于CMU机器学习专业。
Anze Xie
Anze Xie现在就读于加州大学圣地亚哥分校计算机专业，本科结业于维斯康星大学麦迪逊分校。
Xuezhe Ma
Xuezhe Ma现在是南加州大学计算机系的助理教授，本科和研讨生结业于上海交通大学，博士结业于卡耐基梅隆大学。他的研讨方向是提高表征学习的效率，有用性等。
团队的其他几位成员就是LMSYS Org发起人和老熟人了：盛颖，郑怜悯，Ion Stoica和张昊等。
参考资料：
lmsys.org/blog/2023-0…
