从RAG到多跳推理：Qwen-Agent智能体在百万字检索中的三层架构详解

当面对一份百万字级别的技术白皮书、一部浩瀚的文学巨著，或是一个横跨多个文档的复杂研究项目时，传统的语言模型往往会显得力不从心。上下文窗口的限制，就像一扇狭窄的窗户，无法让模型一览全局。近年来，长上下文模型如Qwen-Long的出现，将窗口扩展到了千万token量级，为处理超长文本提供了基础能力。然而，仅仅拥有一个“大房间”并不够，关键在于如何高效、精准地在这个房间里找到并理解所需的信息。这正是智能体（Agent）技术大显身手的舞台。

本文将深入剖析基于Qwen-Agent框架构建的、面向百万字级文档检索与问答的三层智能体架构。我们不会停留在简单的RAG（检索增强生成）介绍，而是会层层递进，探讨从基础检索到分块阅读，再到多跳推理的完整技术演进路径。每一层架构都对应着不同的业务复杂度、成本考量与精度要求，理解其内在逻辑与适用边界，对于AI工程化落地的开发者而言，是进行技术选型、平衡性能与资源的关键。我们将结合架构原理、决策逻辑和潜在的实践考量，为你描绘一幅清晰的技术路线图。

1. 基石：第一层——基于关键词的精准检索（Lv1-Agent）

面对海量文档，最直观的思路是“按需索取”。第一层架构的核心思想，正是模拟人类在查阅资料时的第一步：根据问题，快速定位到最可能包含答案的段落。这一层通常被称为基础RAG，但其实现细节决定了效率的上限。

1.1 核心挑战与朴素方案

一个朴素的RAG流程通常包括：文档分块、向量化存储、查询向量化、相似度检索、上下文拼接、最终生成。然而，在百万字级别，直接使用向量检索面临几个现实挑战：

• 计算开销：对超长文档进行高质量的向量化本身就需要大量计算，且向量数据库的索引构建与查询在高维空间中也非易事。
• 语义漂移：单纯的向量相似度可能无法精准捕捉用户查询中的关键指令（如“用英文回答”、“总结成三点”），或者对特定术语、专有名词的匹配不够精确。
• 部署复杂性：引入独立的向量模型和数据库，增加了系统架构的复杂性和维护成本。

因此，一种更轻量、更直接的方案被提出：基于关键词的检索。它的优势在于速度快、资源消耗低，且对明确的事实性查询非常有效。

1.2 架构拆解：从查询理解到BM25检索

Lv1-Agent的工作流是一个精心设计的管道，其核心在于将用户的自然语言查询，转化为机器可高效执行的检索指令。

第一步：指令与信息分离 用户的问题往往混合了“要做什么”和“关于什么”两部分。例如，“请用表格对比一下Qwen2.5-7B和Qwen2.5-14B在长文本任务上的主要差异”。模型需要识别出：

• 信息部分：“Qwen2.5-7B和Qwen2.5-14B在长文本任务上的主要差异”。这是检索的目标。
• 指令部分：“请用表格对比”。这是生成答案时的格式要求。

通过提示工程，引导模型完成这种结构化解析，输出如下的JSON：

{
  "信息": ["Qwen2.5-7B和Qwen2.5-14B在长文本任务上的主要差异"],
  "指令": ["用表格对比"]
}

提示：这一步分离至关重要，它确保了后续检索只针对核心语义内容，避免了指令词（如“对比”、“总结”）对检索结果的干扰。

第二步：多语言关键词提取 接下来，针对“信息部分”，进一步提取关键词。考虑到技术文档可能中英混杂，提取多语言关键词能提高召回率。例如，上述信息可能被转化为：

{
  "关键词_英文": ["Qwen2.5-7B", "Qwen2.5-14B", "long context", "performance", "difference"],
  "关键词_中文": ["Qwen2.5-7B", "Qwen2.5-14B", "长文本", "性能", "差异"]
}

第三步：传统检索算法BM25的应用 获得关键词后，使用BM25这类经典的基于词频和文档长度的检索算法。BM25会扫描所有预先分割好的文本块（例如，每个块512个token），计算每个块与这组关键词的匹配得分。其公式综合考虑了关键词在块中的频率、块的长度以及关键词在整个文档集合中的逆文档频率（IDF）。

最终，得分最高的前K个文本块被选中，拼接后作为上下文，送入大语言模型生成最终答案。整个过程无需向量模型参与，检索速度极快。

# 伪代码示例：简化的Lv1-Agent检索核心流程
def lv1_agent_retrieve(query, document_chunks):
    # 1. 解析查询
    parsed = parse_query_to_structured(query) # 分离指令与信息
    info_part = parsed["信息"]
    
    # 2. 提取关键词
    keywords = extract_multilingual_keywords(info_part)
    
    # 3. BM25检索
    bm25 = BM25Okapi(document_chunks) # 假设文档块已预处理
    scores = bm25.get_scores(keywords)
    top_k_indices = np.argsort(scores)[-K:] # 取Top-K
    
    # 4. 组装上下文
    context = "".join([document_chunks[i] for i in top_k_indices])
    return context

1.3 适用场景与局限性

Lv1-Agent架构非常适合以下场景：

• 查询意图明确：问题中包含清晰的关键实体或术语。
• 文档结构规整：技术手册、API文档、产品说明书等。
• 对响应延迟敏感：需要毫秒级检索响应的应用。
• 资源受限环境：无法部署额外向量服务的情况。

然而，它的局限性也很明显：当答案分散在多个不包含查询关键词的段落中，或需要进行一定程度的语义联想和推理时，基于关键词的检索很容易失败。这便引出了我们对更高层次智能体的需求。

2. 进化：第二层——并行化分块阅读与精筛（Lv2-Agent）

Lv1-Agent的瓶颈在于“检索盲区”——那些与用户查询语义相关但词汇不重叠的文本块会被遗漏。为了突破这一限制，第二层架构采取了一种“广撒网，重点捕捞”的策略：先对文档进行一轮初步的、并行化的相关性筛查。

2.1 暴力策略背后的精巧设计

Lv2-Agent的核心思想是：不让模型只看检索到的几个块，而是让它快速“浏览”每一个文档块，并做出初步的相关性判断。这听起来计算量巨大，但通过并行化设计和巧妙的提示，可以将其控制在可接受的范围内。

其工作流程分为三个阶段：

第一阶段：并行化初步筛查 将百万字文档分割成的成千上万个文本块，批量提交给语言模型。对每个块，模型只回答一个简单问题：“这个文本块与用户查询‘[用户问题]’是否相关？如果相关，请摘录出最相关的一两句话；如果不相关，请输出‘无’。” 由于每个块的判断是独立的，这一过程可以高度并行化，利用模型的批量处理能力大幅缩短时间。

第二阶段：基于筛查结果的二次检索 收集所有非“无”的输出（即模型认为相关的句子片段）。这些句子片段本身已经过模型提炼，比原始文本块更精炼，更能代表其核心语义。然后，将这些句子片段作为新的“查询”，再次使用BM25算法，从原始文档块中检索最相关的块。 这一步的妙处在于，它用模型生成的、语义更贴近的“描述”替代了原始的用户查询，相当于进行了一次查询改写和语义增强，极大地提高了召回相关块的概率。

第三阶段：生成最终答案 将二次检索得到的高质量文本块组合，在模型的上下文窗口限制内（如8K），送入模型生成最终答案。

2.2 架构优势与成本权衡

Lv2-Agent通过增加一轮计算，换来了更高的召回率。其优势体现在：

• 克服词汇不匹配：即使文档块中没有用户查询的原词，只要模型能理解其语义相关性，就能被筛选出来。
• 实现粗粒度理解：模型在筛查时已经对每个块的内容有了初步理解，这比单纯的词频统计更智能。

当然，这种能力提升是有代价的：

• 计算成本增加：需要对每个文档块进行一次模型调用（尽管是并行的）。文档越长，块越多，成本越高。
• 延迟增加：虽然并行化，但处理整个文档仍需时间，不适合极低延迟场景。

下表对比了Lv1与Lv2架构的核心差异：

特性维度	Lv1-Agent (基础检索)	Lv2-Agent (分块阅读)
核心机制	关键词匹配 (BM25)	模型初步筛查 + 二次检索
检索召回率	较低，依赖词汇重叠	较高，依赖语义理解
计算开销	极低 (传统算法)	中高 (需调用模型并行处理所有块)
响应延迟	极低	中等 (依赖并行度和块数量)
适用查询	事实型、术语明确型	语义复杂、需要一定理解的查询
架构复杂度	简单	中等

注意：在实践中，可以对Lv2进行优化，例如先使用Lv1快速检索出一个较小的候选集，再对这个候选集进行分块阅读，以平衡精度和速度。

3. 跃升：第三层——工具调用与多跳推理（Lv3-Agent）

有些问题无法通过单次检索回答。例如，“在Qwen2.5-14B模型论文中，作者提到用于加速长文本推理的稀疏注意力机制，与另一篇知名论文《FlashAttention》中提出的方法，主要优化目标有何不同？”要回答这个问题，智能体需要执行多步操作：

1. 在Qwen的论文中找到关于其稀疏注意力机制（如MInference）的描述，理解其优化目标（减少计算和内存开销）。
2. 在《FlashAttention》的相关资料中找到其核心优化目标（优化GPU显存访问，提高计算吞吐量）。
3. 对两者的目标进行对比分析。

这就是多跳推理。第三层架构将Lv2-Agent封装成一个可靠的“文档阅读工具”，并由一个更高级的、具备规划能力的“元智能体”（Lv3-Agent）来驱动。

3.3 智能体协作：ReAct模式下的问题分解

Lv3-Agent通常基于ReAct（推理+行动）范式或函数调用（Tool Calling）能力构建。它不直接接触原始文档，而是学会将复杂问题分解为一系列子问题，并通过调用Lv2-Agent这个工具来逐一获取答案。

其核心循环如下：

1. 接收用户复杂问题。
2. 自我推理：判断当前记忆（即历史对话和工具返回结果）是否足以回答问题。如果不足，则规划下一个需要解决的子问题。
3. 调用工具：将子问题提交给Lv2-Agent执行。Lv2-Agent会利用其分块阅读能力，从百万字文档中寻找该子问题的答案。
4. 整合信息：将Lv2-Agent返回的答案添加到自己的记忆（上下文）中。
5. 循环：重复步骤2-4，直到Lv3-Agent认为已收集到足够信息，可以解答原始问题。
6. 生成最终答案：基于所有子问题的答案，进行综合、推理，生成最终回复。

# 伪代码示例：Lv3-Agent的核心循环逻辑
class Lv3Agent:
    def __init__(self, llm, lv2_tool):
        self.llm = llm # 具备规划能力的LLM
        self.lv2_tool = lv2_tool # 封装好的Lv2-Agent工具
        self.memory = [] # 存储对话历史和工具返回结果

    def solve_complex_query(self, initial_question):
        self.memory.append(f"用户: {initial_question}")
        
        while not self._can_answer_final(initial_question):
            # 规划下一个子问题
            sub_question = self.llm.plan_next_question(self.memory, initial_question)
            self.memory.append(f"思考: 我需要先了解：{sub_question}")
            
            # 调用Lv2工具寻找子问题答案
            sub_answer = self.lv2_tool.execute(sub_question) # 内部调用Lv2-Agent流程
            self.memory.append(f"工具返回: {sub_answer}")
            
            # 判断是否需要进行下一步
            self.llm.update_internal_state(self.memory)
        
        # 生成最终答案
        final_answer = self.llm.generate_final_answer(self.memory, initial_question)
        return final_answer

3.4 能力边界与系统设计考量

Lv3-Agent代表了当前智能体处理复杂、深层查询的先进水平。它尤其擅长：

• 多文档关联查询：问题答案分散在不同文档中。
• 隐含关系推理：需要结合多个事实进行逻辑推导。
• 分步规划任务：例如，“先总结A文档的第三章，再对比其与B文档结论的异同”。

然而，构建一个稳定的Lv3-Agent系统挑战更大：

• 规划可靠性：模型分解问题的能力是否稳定、合理？是否会陷入循环或提出无关子问题？
• 错误累积：Lv2-Agent在任何一个子问题上检索或理解错误，都可能导致最终答案的偏差。
• 成本与延迟：一次用户查询可能触发多次Lv2-Agent调用，总成本和时间开销成倍增加。

在实际工程中，是否需要部署Lv3-Agent，必须严格评估业务需求。对于绝大多数事实性问答，Lv1或Lv2已经足够。只有对那些明确需要串联信息、进行深度分析的场景，Lv3才具有不可替代的价值。

4. 架构选型策略与成本效益分析

了解了三层架构的原理后，如何为你的项目选择合适的一层？这绝非单纯的技术竞赛，而是一个需要权衡精度、成本、延迟和复杂度的工程决策。

4.1 技术决策树

你可以遵循以下决策路径进行初步筛选：

开始
│
├── 用户查询是否简单、包含明确关键词？
│   ├── 是 → 对延迟和成本是否极度敏感？
│   │   ├── 是 → **选择 Lv1-Agent** (成本最低，速度最快)
│   │   └── 否 → 可考虑 Lv1，也可评估 Lv2 以换取更高稳定性
│   │
│   └── 否 → 查询是否需要理解语义、上下文？
│       ├── 否 → (通常不会，返回上一步)
│       └── 是 → 问题是否需要结合多个分散信息点进行推理？
│           ├── 否 → **选择 Lv2-Agent** (精度与成本的较好平衡)
│           └── 是 → **选择 Lv3-Agent** (处理最复杂查询)
│

4.2 成本效益的量化视角

成本主要来自大模型API调用或自建模型的推理开销。我们可以做一个粗略的估算：

假设处理一份100万字（约70万token）的文档，分块大小为512 token，则约有1367个块。

• Lv1-Agent成本：1次查询解析调用 + 1次最终生成调用。检索部分（BM25）计算成本可忽略不计。总调用次数 ≈ 2次。
• Lv2-Agent成本：1次查询解析调用 + 1367次并行筛查调用（可批量处理，但计费通常按总token数算）+ 1次最终生成调用。总调用负担 ≈ 1369次模型交互（尽管并行，但计算量巨大）。
• Lv3-Agent成本：高度可变。假设一个复杂问题被分解为3个子问题。那么成本 ≈ Lv3自身规划调用（约3-4次） + 3 * Lv2单次查询成本。总成本可能是Lv2的3倍以上。

因此，在资源受限的情况下，采用混合策略往往是明智的：

• 分级处理：先使用Lv1处理大量简单查询，对Lv1置信度低的查询，再触发Lv2。
• 缓存优化：对常见查询和文档片段建立结果缓存。
• 动态分块：根据文档类型和查询预测，动态调整初步筛查的粒度，而非总是全量扫描。

4.3 与长上下文模型（如Qwen-Long）的协同

你可能会问：既然有了支持百万token上下文的Qwen-Long，是否还需要这么复杂的Agent架构？答案是：它们不是替代关系，而是互补关系。

• 长上下文模型是“容量”：它提供了一个巨大的“工作记忆区”，可以一次性装入大量文本。这解决了传统模型上下文不足的硬伤。
• Agent是“处理器”和“导航器”：即使有了大容量，如何从海量信息中快速找到、提取、串联关键信息，依然需要智能的策略。Agent的检索、筛选、推理能力，就是高效的导航和处理算法。

最理想的架构可能是 “Agent + 长上下文模型” 的组合：

1. Agent（Lv1/Lv2）负责从海量文档库中，精准检索出与问题最相关的多个片段。
2. 将这些片段，连同问题和历史对话，一起送入Qwen-Long这类长上下文模型。
3. 长上下文模型在其巨大的窗口内，对这些片段进行深度的综合、推理和答案生成。

这种组合既发挥了Agent精准定位的效率，又利用了长上下文模型强大的跨片段理解能力，同时避免了让长上下文模型去“阅读”全部原始文档的巨额计算成本。

在实际项目中，我见过一些团队一开始就追求最复杂的Lv3架构，结果发现大部分用户查询用Lv1就能很好解决，复杂的规划逻辑反而引入了不必要的故障点和延迟。我的建议始终是：从最简单的方案开始，用真实数据验证其瓶颈，再逐步升级。技术选型的艺术，不在于选择最强大的，而在于选择最合适的。