使用Qwen-Agent将LLM从8 k推广到1 M上下文

TLDR：我们使用具有8 k上下文大小的Qwen 2模型创建了一个代理，以理解具有1 M个令牌的文档，超过了RAG和原生长上下文模型。该代理还用于生成数据以训练新的长上下文Qwen模型。介绍最近，可以本地处理数百万个代币序列的LLM出现了炒作趋势。

大多数工作都集中在复杂的数学调整上，例如基于RoPE的外推或架构改革，例如非变压器LLM。然而，准备足够长的微调数据是一个较少讨论但同样重要的话题。我们采取以下方法：- 我们使用弱8 k上下文聊天模型来构建能够处理1 M上下文的相对强大的代理。

- 随后，我们使用代理合成微调数据并应用自动过滤以确保质量。- 最后，我们使用合成数据来微调预训练的模型，从而产生强大的1 M上下文聊天模型。该博客主要关注第1步，后续步骤的详细信息将在未来几周或几个月内公布。

构建代理我们正在构建的代理由三个复杂级别组成，每个级别都建立在前一个级别的基础上。1级：检索增强一代处理1 M令牌上下文的一种简单方法是简单地使用检索增强生成（RAG）。

例如，RAG将上下文分为较短的块，每个块不超过512个令牌，然后仅保留8 k令牌上下文中最相关的块。挑战在于如何确定最相关的区块。经过多次尝试，我们提出了一个基于关键字的解决方案：- 第一步：指示聊天模型将用户查询中的指令和非指令信息分开。

例如，转换用户查询“你应该回复2000字，并且尽可能详细。我的问题是，自行车是什么时候发明的？用英语回复。

"进入{“信息”：[“自行车是什么时候发明的”]、“说明”：[“回复2000字”、“尽可能详细”、“用英语回复”]}. - 第2步：要求聊天模型从查询的信息部分推断出多语言关键词。

例如短语“自行车是什么时候发明的”将被转换为{“keywords_en”：[“bicycle”，“invented”，“when”]，“keywords_zh”：[“自行车”，“发布”，“时间”]}. - 第3步：

使用BM 25算法（一种传统的基于关键词的检索方法）来定位与提取的关键词最相关的块。我们还尝试了基于载体的检索。然而，在大多数情况下，它并没有提供足够显着的改进来抵消因部署单独嵌入模型的必要性而产生的额外复杂性。

RAG CodeLevel 2：逐块阅读上述RAG方法速度很快，但当相关块与用户查询没有足够的关键字重叠时，通常会失败，导致这些块无法被检索并因此无法提供给模型。尽管从理论上讲，载体检索可以缓解这个问题，但在实践中，它通常不会。

为了解决这一限制，我们采用暴力策略来减少错过相关上下文的机会：- 第1步：对于每个512个令牌块，我们要求模型评估其与用户查询的相关性，并输出“没有”如果被认为不相关，或者如果被认为相关，则输出相关句子。

这些块并行处理，以避免长时间等待。- 第2步：然后我们获取不包含的输出“没有”(the相关句子），并将它们用作搜索查询，使用BM 25检索最相关的块（在8 k上下文限制内）。- 第3步：最后，我们以与RAG相同的方式根据检索到的上下文生成最终答案。

第3级：逐步推理基于文档的问答中的一个经典挑战是多跳推理。例如，考虑回答这样的问题：“什么车辆是在创作第五交响曲的同一个世纪发明的？“当得到一份包含相关事实的长文件时。该模型首先需要确定子问题的答案“第五交响曲创作于哪个世纪？

“那是19世纪。

然后，它可以意识到包含“自行车是在19世纪发明的”的块实际上与原始问题相关。工具调用（也称为函数调用）代理或ReAct代理是经典的解决方案，具有内置的问题分解和逐步推理功能。因此，我们将上述Level-2代理包装为工具调用代理所调用的工具。

工具调用代理进行多跳推理，如下所示：向Lv 3-Agent提问。而（Lv 3-Agent无法根据其内存回答问题）{Lv 3-Agent提出一个要回答的新子问题。Lv 3-代理向Lv 2-代理询问子问题。

将Lv 2-Agent的响应添加到Lv 3-Agent的内存中。}Lv 3-Agent提供了原始问题的最终答案。例如，Lv 3-Agent最初向Lv 2-Agent提出了一个子问题：“贝多芬的第五交响曲是在哪个世纪创作的？

“在收到“19世纪”的回复后，Lv 3-Agent制定了随后的子问题：“19世纪发明了什么车辆？通过整合来自Lv 2-Agent的所有反馈，Lv 3-Agent可以回答最初的问题：“在创作第五交响曲的同一个世纪，发明了什么样的交通工具？

”

”实验我们对为256 k上下文设计的两个基准进行了实验：- NeedleBench是一个基准，旨在测试模型是否能够在充满众多不相关句子的上下文中识别出最相关的句子，就像大海捞针一样。回答一个问题可能需要同时发现几个“针”并执行多跳推理。

- LV-Eval是一个具有挑战性的基准，需要同时理解多个证据。我们修改了LV-Eval原始版本的评估指标，因为它过于严格，导致大量假阴性。

我们比较了以下方法：- 32 k模型是一个7 B聊天模型，主要对8 k上下文样本进行微调，其中有一些32 k上下文样本，使用基于RoPE的外推等免训练方法扩展到256 k上下文。

- 4k-RAG，使用与32 k-Model相同的模型，但应用Lv 1-Agent RAG策略。它只检索和处理最相关的4k上下文。- 4k代理使用与32 k模型相同的模型，遵循上述更高级的代理策略。

代理策略每次只使用模型的4k上下文。经验数据揭示：- 在上下文较短的情况下，4k-RAG的执行效率可能低于32 k模型。这可能是由于检索正确的信息或理解多个部分遇到困难。

- 相反，随着文档长度的增加，4k-RAG的表现更有可能优于32 k-Model。这一趋势表明32 k模型没有经过处理长上下文的最佳训练。- 值得注意的是，4K-Agent始终优于32 k-Model和4k-RAG。

它能够读取块中的所有上下文，这使得它能够避免训练不足的上下文长度带来的限制。总体而言，如果接受适当的培训，32 k型号在理想情况下应该会脱颖而出。然而，由于实践中训练不足，32 k型号的表现低于4k代理。

最后，我们还对该代理进行了100万个代币的压力测试（在100万个代币的大海捞针），并发现它功能正常。然而，我们仍然缺乏更可靠的量化基准来评估其在现实世界应用程序中处理100万个代币的上下文中的性能。

结论在这个博客中，我们介绍了如何建设这个时代