大语言模型

Qwen-Agent，开启LLM长文本处理新纪元

2024 年 6 月 8 日

Qwen-Agent + RAG：用8k上下文模型打造百万Token巨兽

大型语言模型（LLM）领域正在经历一场技术革命，百万级Token的处理能力成为新的角逐点。传统的LLM受限于上下文窗口大小，难以有效处理超长文本。如何突破这一瓶颈？智源研究院Qwen团队另辟蹊径，他们没有执着于复杂的数学技巧或架构调整，而是巧妙地将目光投向了Agent技术。

Qwen团队用实际行动证明：仅凭8k上下文窗口的Qwen2模型，也能构建出理解和处理百万Token文档的“强力巨兽”，其性能甚至超越RAG和原生长文本模型！ 更令人振奋的是，这项技术还能用于生成训练数据，助力打造更强大的长文本Qwen模型，为LLM领域开辟了全新的可能性。

Agent + RAG：化解百万Token挑战的利器

一直以来，LLM处理超长文本的能力都是一大难题。现有的解决方案主要集中在模型结构的改进上，例如基于RoPE的扩展或非Transformer架构。然而，高质量的长文本训练数据的获取却常被忽视，成为制约LLM性能提升的关键瓶颈。

针对这一难题，Qwen团队另辟蹊径，提出了一种新颖的解决方案：

1. 以弱胜强： 利用8k上下文窗口的“弱”聊天模型构建一个能够处理百万级Token的“强”Agent。
2. 数据驱动： 利用Agent合成高质量的微调数据，并进行自动化过滤，为模型训练提供充足的“养料”。
3. 能力跃迁： 利用合成数据对预训练模型进行微调，最终得到一个能够处理百万级Token的“强”聊天模型，实现性能的质的飞跃。

本文将重点介绍第一步，即如何构建Agent。

Qwen-Agent三级进阶：步步为营，攻克长文本难题

Qwen团队构建的Agent共分为三个复杂度等级，每个等级都建立在之前的基础之上，逐步提升模型处理长文本的能力，最终实现百万Token的终极目标。

第一级：检索增强生成 (RAG)

处理百万级Token上下文的一种简单方法是使用检索增强生成（RAG）。RAG将长文本划分为多个短片段（例如，每个片段不超过512个Token），然后只保留与用户查询最相关的片段（例如，保留在8k上下文窗口内）。

RAG的关键在于如何准确识别最相关的片段。经过多次尝试，Qwen团队提出了一种基于关键词的解决方案：

1. 指令解析： 指示聊天模型区分用户查询中的指令信息和非指令信息。例如，将用户查询"我希望你用2000字回答，并且尽可能详细。我的问题是，自行车是什么时候发明的？请用中文回答。"转换为{"information": ["自行车是什么时候发明的"], "instruction": ["我希望你用2000字回答", "并且尽可能详细", "请用中文回答"]}。
2. 关键词提取： 要求聊天模型从查询的信息部分推导出多语言关键词。例如，将短语“自行车是什么时候发明的”转换为{"keywords_en": ["bicycles", "invented", "when"], "keywords_zh": ["自行车", "发明", "时间"]}。
3. 精准检索： 使用传统的基于关键词的检索方法BM25算法，找到与提取的关键词最相关的片段。

检索增强生成的数据流

Qwen团队也尝试了基于向量的检索方法，但实际应用中，向量检索方法的效果提升并不足以弥补其部署单独嵌入模型所带来的额外复杂性。

第二级：逐块阅读

上述RAG方法速度快，但当相关片段与用户查询的关键词重叠度不足时，这些片段可能无法被检索到，导致模型无法获取完整信息。虽然向量检索在理论上可以缓解这个问题，但在实践中往往效果不佳。

为了解决这一局限性，Qwen团队采用了一种“暴力”策略，以降低遗漏相关上下文的概率：

1. 逐块评估： 针对每个512 Token的片段，要求模型评估其与用户查询的相关性，如果认为不相关，则输出"None"，如果认为相关，则输出相关的句子。这些片段会被并行处理，以避免长时间等待。
2. 精准定位： 将输出中不为"None"的内容（即相关的句子）作为搜索查询，使用BM25算法检索最相关的片段（限制在8k上下文窗口内）。
3. 整合输出： 最后，基于检索到的上下文，以与RAG相同的方式生成最终答案。

逐块阅读的数据流

码

第三级：逐步推理

基于文档的问答系统中，一个典型的挑战是多跳推理。例如，假设文档中包含“第五交响曲是在19世纪创作的”和“自行车是在19世纪发明的”两句话，当被问及“与第五交响曲创作于同一个世纪的交通工具是什么？”时，模型需要先确定子问题“第五交响曲是在哪个世纪创作的？”的答案（即19世纪），然后才能意识到包含“自行车是在19世纪发明的”这句话与原始问题相关。

工具调用（也称为函数调用）Agent或ReAct Agent是解决这类问题的经典方法，它们内置了问题分解和逐步推理的能力。因此，Qwen团队将上述第二级Agent包装成一个工具，供工具调用Agent调用。工具调用Agent执行多跳推理的过程如下：

向Lv3-Agent询问一个问题。
当(Lv3-Agent无法根据其记忆回答问题)时{
    Lv3-Agent提出一个新的子问题需要回答。
    Lv3-Agent向Lv2-Agent询问子问题。
    将Lv2-Agent的回答添加到Lv3-Agent的记忆中。
}
Lv3-Agent提供原始问题的最终答案。

逐步推理的数据流

例如，Lv3-Agent最初向Lv2-Agent提出一个子问题：“贝多芬的第五交响曲是在哪个世纪创作的？”。在收到“19世纪”的回答后，Lv3-Agent会接着问一个子问题：“19世纪发明了什么交通工具？”。通过整合来自Lv2-Agent的所有反馈，Lv3-Agent最终可以回答最初的问题：“与第五交响曲创作于同一个世纪的交通工具是什么？”。

实验结果：Qwen-Agent性能一骑绝尘

为了验证Qwen-Agent的性能，Qwen团队在两个专为256k上下文设计的基准测试集上进行了实验，分别是：

1. NeedleBench：用于测试模型能否在充满大量无关信息的上下文中识别出最相关的句子，类似于大海捞针。回答一个问题可能需要同时发现多个“针”，并进行多跳推理，非常考验模型的信息提取和逻辑推理能力。
2. LV-Eval：一个更具挑战性的基准测试集，需要模型同时理解多条证据才能正确回答问题。由于原始LV-Eval的评估指标过于严格，导致了大量的假阴性结果，Qwen团队对其进行了修改，以更准确地评估模型性能。

实验比较了以下三种方法：

1. 32k-Model：一个7B的聊天模型，主要使用8k上下文样本进行微调，并使用少量32k上下文样本进行微调，使用RoPE等无需训练的方法将其扩展到256k上下文窗口。
2. 4k-RAG：使用与32k-Model相同的模型，但采用Lv1-Agent RAG策略，只检索和处理最相关的4k上下文。
3. 4k-Agent：使用与32k-Model相同的模型，采用上述更先进的Agent策略，每次只使用4k上下文窗口与模型交互。

实验结果如下：

结果分析：

• 在短上下文场景下，4k-RAG的效果可能不如32k-Model，这可能是因为难以检索到正确的信息或难以理解多个部分。
• 但随着文档长度的增加，4k-RAG更有可能超过32k-Model。这一趋势表明，32k-Model在处理长上下文方面训练不足。
• 值得注意的是，4K-Agent的性能始终优于32k-Model和4k-RAG，这得益于其能够分块读取所有上下文，避免了模型上下文长度训练不足带来的限制。

总的来说，如果32k-Model能够得到充分的训练，理想情况下应该优于所有方法。然而，由于实际训练不足，32k-Model的性能反而不如4k-Agent。

最后，Qwen团队还在百万级Token的压力测试中测试了Agent（在一百万个Token中找到一根针），发现它能够正常工作。然而，目前还缺乏更可靠的定量基准来评估其在真实应用中处理百万级Token上下文时的性能。

更强大的长文本模型，更便捷的应用框架

本文介绍了如何利用8k上下文窗口的模型构建一个能够处理百万级Token的Agent。一旦Agent准备就绪，合成训练数据就变得水到渠成。例如，可以招募志愿者与Agent互动并记录结果，构建微调数据集。此外，还可以使用Agent对其他方法生成的数据进行交叉验证，确保数据质量。更重要的是，将Agent提炼成模型的总体思路也适用于其他领域，例如增强模型解决长程任务的能力。

Qwen团队的开源RAG和Agent框架Qwen-Agent 最初是为方便模型开发而编写的内部工具代码，最近得到了快速发展。目前，Qwen团队已经在该框架中发布了上述长上下文Agent的实现。

在不久的将来，Qwen团队希望能够提供处理长上下文能力更强的模型，以及更加用户友好的基础设施框架。