qwen-long长文本实现技术调研

最新推荐文章于 2025-04-26 15:17:33 发布

mengting-wang

最新推荐文章于 2025-04-26 15:17:33 发布

阅读量823

点赞数 16

文章标签：阿里云

本文链接：https://blog.csdn.net/m0_64646666/article/details/147213184

版权

使用Qwen-Agent将上下文记忆扩展到百万量级 | Qwen

https://zhuanlan.zhihu.com/p/20651623837

结论分析

Qwen-Long 模型支持最大 10,000,000（1000万）个 tokens 的上下文长度，约合 1,500 万字，能够处理超长文档和多文档对话场景，适用于代码审查、论文分析等复杂任务。

而最新的Qwen2.5模型最多支持100万（1M）个 tokens 的上下文长度。

官方文档并没有解释过Qwen-Long 模型实现原理和相关技术报告，根据查阅的内容，作出推测如下：

根据Qwen-Agent的功能，实现Qwen-Long，实现主要包括（基座模型本身上下文扩展 + Agent RAG技术）

解释如下：

Qwen-Long 模型发表时间为 2024年5月

同期推出的工作还有：Qwen-Agent

查阅官方文档发现Qwen-Long模型支持文档导入（这是Agent技术的体现，即调用工具读取文档内容，而不是简单的文本生成）

模型本身上下文扩展

Qwen-long 模型一直在更新，由于底层基座模型一直在更新。下面是基座模型上下文拓展介绍：

Qwen2.5系列的一个Long Context升级，从128K拓展到了1M。提出了一些长上下文预训练以及长度外推的技术创新，开源了7B和14B的模型。

核心思路

Qwen2.5-1M 系列模型的核心思路是在 Qwen2.5 模型的基础上，通过以下关键策略来扩展上下文窗口，并优化长文本处理的效率：

高效的长上下文训练：
- 混合数据：使用自然文本和合成数据进行预训练，利用合成数据来增强模型对长距离依赖的理解。
- 渐进式训练：采用渐进式上下文长度扩展策略，逐步增加训练的上下文长度，以降低训练成本。
- 多阶段微调：采用多阶段监督式微调（SFT）和强化学习（RL）来平衡模型在短文本和长文本上的性能。
高效的推理和部署：
- 无训练长度外推：使用无训练的长度外推方法，允许模型在推理时处理比训练时更长的上下文。
- 稀疏注意力机制：引入稀疏注意力机制来减少推理过程中的计算成本。
- 引擎级优化：通过优化内核、流水线并行和调度来提升整体推理性能。

方案与技术

Qwen2.5-1M 模型在架构上基于 Qwen2.5 模型，使用 Transformer 结构，并针对长上下文处理进行了改进。主要使用的方案和技术包括：

架构：
- GQA（分组查询注意力）：用于高效的 KV 缓存利用。
- SwiGLU 激活函数：用于非线性转换。
- RoPE（旋转位置编码）：用于编码位置信息。
- QKV 偏置：在注意力机制中使用。
- RMSNorm（均方根归一化）：用于确保训练的稳定性。
预训练：
- 自然语料库：包括 Common Crawl、arXiv、书籍和代码库等。
- 合成数据：
  - FIM（中间填充）：迫使模型整合长距离上下文信息。
  - 基于关键词和位置的检索：增强模型在文本中识别和连接相关信息的能力。
  - 段落重排序：加强模型对逻辑流和结构连贯性的理解。
- 渐进式上下文长度扩展：从 4096 tokens 开始，逐步扩展到 262144 tokens。在扩展过程中，动态调整 RoPE 的基础频率（base frequency）和训练数据的长度分布。
后训练：
- 合成长指令数据：利用 Qwen2.5 模型生成基于长文档的查询，并使用 Qwen-Agent 框架生成高质量的回复。
- 两阶段监督微调：第一阶段专注于短文本数据，第二阶段混合短文本和长文本数据，以平衡短文本和长文本的性能。
- 强化学习：使用与 Qwen2.5 模型相同的离线 RL 训练对齐人类偏好。
推理和部署：
- DCA (双块注意力)：将序列分为多个块，将相对位置重新映射为较小的数字，以避免在训练中未遇到的较大相对位置。DCA 使用三种不同的注意力模式：
  - 块内注意力：处理同一块内的 token 之间的注意力，保留原始的相对位置。
  - 块间注意力：处理不同块之间的 token 的注意力，使用重复序列作为不同块之间的相对位置。
  - 连续块注意力：处理两个相邻块之间的注意力，以确保短距离相对位置的连续性。
- YaRN 中的注意力缩放：通过引入温度参数来增强模型在处理长序列时的注意力集中度。
- 基于 MInference 的稀疏注意力机制：根据「垂直-斜线」模式选择关键 token 进行注意力计算，以减少计算和内存开销。
- 分块预填充：将输入序列分成多个块进行处理，降低显存消耗。
- 稀疏性优化：根据长序列校准集调整稀疏配置。
- 内核优化：优化稀疏注意力内核和 MoE 内核。
- 动态分块流水线并行：动态调整块大小，以减少流水线气泡。
- 异步调度：通过完全异步生成器（TAG）架构实现请求调度、模型运行和解码的异步执行。

DCA

MInference

实验与结论

实验设计：

长文本性能评估：
- Passkey 检索：评估模型从长文档中检索隐藏数字的能力。
- RULER：评估模型在长上下文中的多针检索、问题回答、关键词识别等能力。
- LV-Eval：评估模型同时理解多个证据片段的能力。
- Longbench-Chat：评估模型在长文本任务中与人类偏好的一致性。
短文本性能评估：
- MMLU-Pro, MMLU-redux, LiveBench 0831：通用任务。
- GPQA, GSM8K, MATH：科学和数学任务。
- HumanEval, MBPP, MultiPL-E, LiveCodeBench：代码任务。
- IFEval：指令遵循能力。
- MT-Bench, Arena-Hard：人类偏好对齐和指令遵循能力。
推理速度评估：
- Time to First Token (TTFT)：衡量不同上下文长度下的首次 token 生成时间。

实验结果：

长文本任务：
- Qwen2.5-1M 系列模型在长文本任务上显著优于 128k 版本，特别是在处理超过 64k tokens 的序列时。
- Qwen2.5-14B-Instruct-1M 在 RULER 数据集上超越了 GPT-4，在长文本检索方面表现出色。
- Qwen2.5-14B-Instruct-1M 在 128k 序列上的准确率首次超过 90%。
- Qwen2.5-14B-Instruct-1M 在多个数据集上优于 GPT-4o-mini，成为长文本任务中强大的开源替代方案。
- Qwen2.5-Turbo 在长文本基准测试中表现介于 Qwen2.5-7B-Instruct-1M 和 Qwen2.5-14B-Instruct-1M 之间。
短文本任务：
- Qwen2.5-1M 模型在短文本任务中保持了与 128k 版本相似的性能，表明长上下文能力并没有损害其基础能力。
- Qwen2.5-14B-Instruct-1M 和 Qwen2.5-Turbo 在短文本任务上与 GPT-4o-mini 性能相近，但支持的上下文长度是其八倍。
推理速度：
- 通过稀疏注意力机制和优化的推理引擎，处理 1M tokens 上下文时，速度提升了 3.2 到 6.7 倍。

结论：

Qwen2.5-1M 系列模型通过长上下文预训练和后训练，显著提升了长文本处理能力，同时保持了短文本任务的性能。
长度外推、稀疏注意力机制和推理引擎优化等技术，大幅提升了长文本处理的效率和降低了成本。
Qwen2.5-Turbo 在性能、速度和成本之间实现了很好的平衡。

贡献

模型：
- 发布了 Qwen2.5-7B-Instruct-1M 和 Qwen2.5-14B-Instruct-1M 两个开源模型。
- 推出了 API 可访问的 Qwen2.5-Turbo 模型。
技术：
- 提出了使用合成数据和渐进式训练策略进行长上下文预训练。
- 开发了无训练的长度外推方法（DCA 和 YaRN）。
- 实现了基于 MInference 的稀疏注意力机制和分块预填充，加速推理。
- 优化了推理引擎，包括内核、流水线并行和异步调度等。

不足

稀疏注意力机制的局限性：虽然稀疏注意力机制可以显著加速推理，但在某些情况下仍可能导致精度下降。论文通过引入连续相对位置和细化稀疏配置来缓解这个问题，但仍然有改进的空间。
长文本数据生成：合成长指令数据的方法依赖于模型自身的生成能力，可能引入偏差或不准确性，需要进一步研究更可靠的长文本数据生成方法。
长文本评估：现有的长文本评估基准仍然相对有限，可能无法全面反映模型在各种长文本任务中的性能。需要开发更全面、更具挑战性的长文本评估基准。
模型大小和推理成本：尽管做了大量优化，但处理 1M 上下文长度的模型仍然需要较高的计算资源，如何在资源受限的环境下更有效地部署模型仍然是一个挑战。

Agent RAG 技术

构建智能体

我们构建的智能体包含三个复杂度级别，每一层都建立在前一层的基础上。

级别一：检索

处理100万字上下文的一种朴素方法是简单采用增强检索生成（RAG）。 RAG将上下文分割成较短的块，每块不超过512个字，然后仅保留最相关的块在8k字的上下文中。挑战在于如何精准定位最相关的块。经过多次尝试，我们提出了一种基于关键词的解决方案：

步骤1：指导聊天模型将用户查询中的指令信息与非指令信息分开。例如，将用户查询"回答时请用2000字详尽阐述，我的问题是，自行车是什么时候发明的？请用英文回复。"转化为{"信息": ["自行车是什么时候发明的"], "指令": ["回答时用2000字", "尽量详尽", "用英文回复"]}。
步骤2：要求聊天模型从查询的信息部分推导出多语言关键词。例如，短语"自行车是什么时候发明的"会转换为{"关键词_英文": ["bicycles", "invented", "when"], "关键词_中文": ["自行车", "发明", "时间"]}。
步骤3：运用BM25这一传统的基于关键词的检索方法，找出与提取关键词最相关的块。

流程图：检索

我们也尝试了基于向量的检索，但在大多数情况下，它带来的改进并不显著，不足以抵消部署单独向量模型所带来的额外复杂性。

RAG Code

级别二：分块阅读

上述RAG方法很快速，但常在相关块与用户查询关键词重叠程度不足时失效，导致这些相关的块未被检索到、没有提供给模型。尽管理论上向量检索可以缓解这一问题，但实际上效果有限。为了解决这个局限，我们采用了一种暴力策略来减少错过相关上下文的几率：

步骤1：对于每个512字块，让聊天模型评估其与用户查询的相关性，如果认为不相关则输出"无", 如果相关则输出相关句子。这些块会被并行处理以避免长时间等待。
步骤2：然后，取那些非"无"的输出（即相关句子），用它们作为搜索查询词，通过BM25检索出最相关的块（总的检索结果长度控制在8k上下文限制内）。
步骤3：最后，基于检索到的上下文生成最终答案，这一步骤的实现方式与通常的RAG相同。

流程图：分块阅读

Agent Code

级别三：逐步推理

在基于文档的问题回答中，一个典型的挑战是多跳推理。例如，考虑回答问题：“与第五交响曲创作于同一世纪的交通工具是什么？”模型首先需要确定子问题的答案，“第五交响曲是在哪个世纪创作的？”即19世纪。然后，它才可以意识到包含“自行车于19世纪发明”的信息块实际上与原始问题相关的。

工具调用（也称为函数调用）智能体或ReAct智能体是经典的解决方案，它们内置了问题分解和逐步推理的能力。因此，我们将前述级别二的智能体（Lv2-智能体）封装为一个工具，由工具调用智能体（Lv3-智能体）调用。工具调用智能体进行多跳推理的流程如下：

向Lv3-智能体提出一个问题。 while (Lv3-智能体无法根据其记忆回答问题) { Lv3-智能体提出一个新的子问题待解答。 Lv3-智能体向Lv2-智能体提问这个子问题。将Lv2-智能体的回应添加到Lv3-智能体的记忆中。 } Lv3-智能体提供原始问题的最终答案。

流程图：逐步推理

例如，Lv3-智能体最初向Lv2-智能体提出子问题：“贝多芬的第五交响曲是在哪个世纪创作的？”收到“19世纪”的回复后，Lv3-智能体提出新的子问题：“19世纪期间发明了什么交通工具？”通过整合Lv2-智能体的所有反馈，Lv3-智能体便能够回答原始问题：“与第五交响曲创作于同一世纪的交通工具是什么？”

实验

我们在两个针对256k上下文设计的基准测试上进行了实验：

NeedleBench，一个测试模型是否能在充满大量无关句子的语境中找到最相关句子的基准，类似于“大海捞针”。回答一个问题可能需要同时找到多根“针”，并进行多跳逐步推理。
LV-Eval是一个要求同时理解众多证据片段的基准测试。我们对LV-Eval原始版本中的评估指标进行了调整，因为其匹配规则过于严苛，导致了许多假阴性结果。

我们比较了以下方法：

32k-模型：这是一个7B对话模型，主要在8k上下文样本上进行微调，并辅以少量32k上下文样本。为了扩展到256k上下文，我们采用了无需额外训练的方法，如基于RoPE的外推。
4k-RAG：使用与32k-模型相同的模型，但采取了Lv1-智能体的RAG策略。它仅检索并处理最相关的4k上下文。
4k-智能体：同样使用32k-模型的模型，但采用前文描述的更复杂的智能体策略。该智能体策略会并行处理多个片段，但每次请求模型时至多只使用模型的4k上下文。

实验结果说明了以下几点：