1. 从“检索”到“推理”智能体搜索系统的范式转变最近在折腾一个基于大语言模型的智能客服项目核心需求是让模型能准确回答用户关于产品文档的复杂问题。一开始我们直接用了市面上效果最好的通用文本嵌入模型来做检索增强生成RAG把文档切片、向量化、存进向量数据库然后根据用户问题去召回最相关的几段文本。初期效果不错简单的事实性问题基本都能答对。但当我们把问题复杂度提升比如用户问“根据A产品的技术规格和B产品的历史故障记录分析在C场景下同时部署两者可能存在的兼容性风险”时整个系统就有点“抓瞎”了。检索回来的片段要么是A产品的纯规格参数要么是B产品的孤立故障案例模型很难将这些分散的、需要逻辑串联的信息拼凑成一个连贯、有深度的答案。这个痛点让我开始深入思考标题中提到的“Rethinking Reasoning-Intensive Retrieval”重新思考推理密集型检索。传统的检索系统无论是基于关键词的BM25还是基于稠密向量的语义检索其核心优化目标都是“相关性”Relevance。它们试图找到与查询语句在词汇或语义上最匹配的文档片段。这在处理事实性、描述性查询时非常有效。然而当查询本身包含了复杂的逻辑推理、多步计算、假设分析或因果判断时——我称之为“推理密集型”查询——仅仅找到“相关”的文本是远远不够的。我们需要找到那些能支撑起一个完整推理链条的“证据链”。这恰恰是“Agentic Search Systems”智能体搜索系统对检索器提出的新挑战。在这样的系统里检索器不再是一个被动的、一次性的信息提供者而是成为了一个主动的、具备初步推理能力的“信息猎手”。它需要理解智能体通常是大模型的深层意图和推理规划动态地、多轮次地从海量知识库中精准抓取那些构建答案所必需的“积木”而不仅仅是扔过去一堆看似相关的“原材料”。这个转变要求我们对检索器的评价标准和优化方向进行一次根本性的“再思考”。2. 传统检索评测基准的“盲区”与推理密集型检索的独特需求要改进先得知道问题在哪。我们现有的检索评测基准如MS MARCO、BEIR、MTEB等功不可没它们推动了语义检索技术的飞速发展。但这些基准主要衡量的是“点对点”的语义匹配能力。给定一个查询看系统能否从候选池中找出最相关的那个或那几个文档。评测指标如MRR平均倒数排名、nDCG归一化折损累计增益也围绕此设计。然而对于推理密集型任务这种评测方式存在几个明显的“盲区”2.1 对“证据完备性”的忽视一个复杂的推理问题其答案往往依赖于多个证据点的协同。例如要回答“某药物是否适用于患有高血压的孕妇”可能需要同时检索到1该药物的说明书注明孕妇禁用2一篇医学文献讨论该药物对血压的影响3一份临床指南关于高血压孕妇的用药原则。传统检索器可能只擅长找到其中相关性最高的一项比如说明书而忽略了其他同样关键但表面相关性稍弱的证据。这会导致智能体获得的信息是片面的从而做出错误推理。现有的基准很少评估检索器能否一次性或通过多轮交互召回一个“证据集合”的完整性。2.2 对“信息粒度”的错配推理过程可能需要不同抽象层次的信息。有时需要非常具体的数值、日期、名称细粒度有时需要概括性的结论、原理、框架粗粒度。例如分析一个市场趋势既需要具体的季度财报数据细粒度也需要行业年度白皮书中的宏观判断粗粒度。传统检索器通常使用固定长度的文本块如512个token这种“一刀切”的切片方式很容易切断完整的逻辑单元或者混入无关噪音给后续的推理步骤带来干扰。2.3 对“多跳推理”支持不足很多复杂问题需要“多跳”检索。例如问题“苹果公司最新款手机用的芯片是基于哪家公司的架构设计的” 第一跳检索“苹果公司最新款手机”是iPhone 15 Pro其芯片是A17 Pro。第二跳基于“A17 Pro芯片”检索其技术细节发现其基于ARM架构。传统检索器是单跳的它试图用“苹果公司最新款手机用的芯片架构”这个查询直接找到答案成功率很低因为知识库中可能没有这样直接表述的句子。这就需要检索器具备一定的推理能力或者与智能体协同进行查询重写与迭代检索。2.4 对“噪声容忍度”与“证据矛盾”处理的缺失真实知识库中充满噪声和矛盾信息。一个优秀的推理密集型检索器不仅要在相关文档中找证据还要能初步判断证据的可信度例如来源权威性、时间新鲜度甚至能识别出相互矛盾的证据片段并将这种不确定性传递给智能体做最终裁决。传统检索的“相关性排序”对此无能为力它默认排名越高的文档越“好”但这个“好”未必等于“可信”或“一致”。因此推进推理密集型检索的第一步是建立能够反映上述需求的、新的评测基准Benchmark。这个基准的查询集应由复杂的、需要多步推理的问题构成对应的标准答案不仅包含最终答案还应标注出支撑该答案所必需的所有证据文档或片段集合。评测指标也需要革新除了传统的召回率可能还需要引入“证据集合召回率”、“推理链完整性得分”、“噪声识别率”等。3. 面向推理的检索器进阶之路架构与训练策略革新明确了问题我们来看看如何打造一个更强的、为推理而生的检索器。这不仅仅是换一个更大的嵌入模型而是需要在模型架构、训练目标和系统设计层面进行综合革新。3.1 模型架构从“编码器”到“理解器规划器”当前主流的双塔式稠密检索模型如BERT双塔是一个高效的“编码器”它将查询和文档分别映射到向量空间。但对于推理密集型任务我们可能需要更复杂的架构交叉注意力编码器在检索阶段引入轻量级的查询-文档交叉注意力让模型在生成文档向量时就能“感知”到当前查询的意图从而生成更具任务针对性的表示。这比双塔式的事后计算相似度更灵活但计算成本更高需要精巧的工程优化。序列到序列生成式检索直接使用类似T5、BART的序列到序列模型将检索任务转化为“给定查询生成相关文档ID”或“生成支撑性文本片段”的任务。这种方式能自然处理多文档检索和证据生成将检索和初步的信息整合融为一体。例如Google的DSIDocument Indexed by Semantic Ids就是这一思路的探索。与大型语言模型LLM的深度集成让LLM来担任“检索规划师”。LLM首先分析复杂查询将其分解成多个子问题或检索指令例如“首先查找关于A产品功耗的文档其次查找B场景下的温度限制标准…”然后由传统的或改进后的检索器去执行这些具体的指令。这实质上是将部分推理负担前移到了检索规划阶段。3.2 训练目标超越对比学习对比学习Contrastive Learning是训练稠密检索器的基石它让相关查询-文档对的向量更近不相关的更远。但对于推理密集型检索我们需要设计更精细的训练目标多粒度负采样不仅使用随机不相关文档作为负例更要构造“困难负例”。例如对于查询“高血压孕妇的用药风险”与查询部分相关只谈高血压或只谈孕妇用药但不足以支撑完整推理的文档就是极具价值的困难负例。让模型学会区分“部分相关”和“充分相关”对推理至关重要。链式推理感知损失如果我们有标注好的推理链问题 - 证据1 - 证据2 - … - 答案可以设计损失函数鼓励模型不仅将查询与最终答案相关的文档拉近还要与推理链中间步骤所需的文档也保持较近的距离。基于LLM反馈的强化学习用LLM作为裁判对检索器返回的结果进行评价。例如给定一个复杂查询和检索到的一组文档让LLM判断这组文档是否足以支撑一个高质量的答案并给出分数。用这个分数作为奖励信号通过强化学习如PPO来微调检索器。这能将LLM的推理和评判能力“蒸馏”到检索器中。3.3 系统设计迭代式、交互式检索在智能体搜索系统中检索不应是孤立的单次操作而应是一个与智能体LLM紧密协作的迭代过程初始检索智能体或用户提出初始复杂查询。分析与规划智能体分析查询可能将其分解生成初步的检索指令。首轮检索检索器执行指令返回一批文档。阅读与反思智能体阅读返回的文档评估信息缺口、矛盾或新出现的问题。查询修正/扩展智能体基于已有信息提出更精准、更深入的后续检索问题例如“关于刚才提到的X机制请再查找其在高负载下的具体表现数据”。迭代检索检索器执行新的查询补充证据。 这个过程可以循环多次直到智能体认为信息足够或达到迭代上限。这要求检索器具备快速响应和状态保持记住之前的检索上下文的能力。4. 实战利用LoRA高效微调大型嵌入模型以Qwen2.5为例理论说再多不如动手试。当前像Qwen2.5-7B-Instruct、Qwen3-Embedding-4B这样的开源大模型和嵌入模型能力越来越强。但直接用它做推理密集型检索可能还不够“对口”。我们需要用特定领域或特定任务的数据对它进行微调。然而动辄数十亿参数的模型全参数微调成本极高。这时LoRALow-Rank Adaptation技术就成了我们的利器。以我们想微调一个Qwen3-Embedding-4B模型让它更擅长从技术文档中检索用于故障分析的证据链为例下面是具体的操作流程和核心考量。4.1 任务定义与数据准备首先我们要明确微调的目标不是让模型更“通用”而是更擅长我们的特定任务从技术手册和故障日志中检索出能用于根因分析的多维度证据。 因此我们需要构造高质量的配对数据。每条数据应包含复杂查询模拟真实故障分析场景的问题如“设备在高温环境下运行时通信模块间歇性中断可能的原因有哪些请列出需要核查的硬件和软件因素。”正例文档一组通常多个文档片段的集合这些片段共同包含了回答该问题所需的所有证据如设备工作温度范围说明书、通信模块的散热设计文档、相关版本的软件已知Bug列表、类似案例的维修记录。困难负例文档与查询部分相关但信息不全或无关的文档。例如只讲设备低温运行的文档只讲通信模块协议而不讲硬件的文档或者完全不相关的其他产品文档。数据的质量直接决定微调的上限。我们可以用较强的LLM如GPT-4、Claude 3或Qwen2.5-72B-Instruct来辅助生成和清洗这些数据。4.2 环境配置与模型加载假设我们使用Hugging Face的transformers和peft库以及trl库进行训练。# 安装核心库 pip install transformers datasets peft accelerate trl bitsandbytes torch加载基础模型和分词器。使用bitsandbytes进行4位量化可以极大减少显存占用。import torch from transformers import AutoTokenizer, AutoModel, BitsAndBytesConfig from peft import LoraConfig, get_peft_model, TaskType model_name Qwen/Qwen3-Embedding-4B # 假设模型已发布或使用类似路径 bnb_config BitsAndBytesConfig( load_in_4bitTrue, bnb_4bit_compute_dtypetorch.bfloat16, bnb_4bit_use_double_quantTrue, bnb_4bit_quant_typenf4 ) tokenizer AutoTokenizer.from_pretrained(model_name, trust_remote_codeTrue) # 注意嵌入模型通常使用AutoModel而非AutoModelForCausalLM base_model AutoModel.from_pretrained( model_name, quantization_configbnb_config, device_mapauto, trust_remote_codeTrue ) base_model.config.use_cache False # 梯度检查点可能需要关闭cache4.3 LoRA配置与模型包装接下来我们定义LoRA配置。对于嵌入模型我们通常对查询和文档编码器中的注意力层进行适配。# 定义LoRA配置 lora_config LoraConfig( task_typeTaskType.FEATURE_EXTRACTION, # 对于嵌入模型常使用此类型或SEQ_CLS r16, # LoRA的秩影响参数量和能力通常8-64之间 lora_alpha32, # 缩放因子通常设置为r的2倍 lora_dropout0.1, target_modules[q_proj, k_proj, v_proj, o_proj], # 针对Qwen的注意力模块名 biasnone ) # 将基础模型包装为PeftModel model get_peft_model(base_model, lora_config) model.print_trainable_parameters() # 查看可训练参数占比通常只有原模型的0.1%-1%这里的关键是target_modules的确定。不同模型架构的模块命名不同。对于Qwen这类类GPT架构的模型通常针对注意力机制中的Q、K、V、O投影层进行微调是有效的。如果不确定可以打印base_model的结构来查看。4.4 数据预处理与损失函数我们需要将(query, positive_docs, negative_docs)的数据格式转化为模型训练所需的格式。对于对比学习一个常用的方法是使用InfoNCE损失或称为交叉熵损失构造批次内负样本。from torch.utils.data import Dataset import numpy as np class EmbeddingDataset(Dataset): def __init__(self, queries, positives, negatives, tokenizer, max_length512): self.queries queries self.positives positives # 每个query对应一个正例文档列表 self.negatives negatives # 每个query对应一个负例文档列表 self.tokenizer tokenizer self.max_length max_length def __len__(self): return len(self.queries) def __getitem__(self, idx): query self.queries[idx] # 随机从正例列表中选一个作为本次训练的正例 pos_doc np.random.choice(self.positives[idx]) # 随机从负例列表中选一个作为本次训练的负例也可以选多个 neg_doc np.random.choice(self.negatives[idx]) # 分别对query和文档进行编码 query_enc self.tokenizer(query, truncationTrue, paddingmax_length, max_lengthself.max_length, return_tensorspt) pos_enc self.tokenizer(pos_doc, truncationTrue, paddingmax_length, max_lengthself.max_length, return_tensorspt) neg_enc self.tokenizer(neg_doc, truncationTrue, paddingmax_length, max_lengthself.max_length, return_tensorspt) # 返回编码后的输入ID和注意力掩码 return { query_input_ids: query_enc[input_ids].squeeze(), query_attention_mask: query_enc[attention_mask].squeeze(), pos_input_ids: pos_enc[input_ids].squeeze(), pos_attention_mask: pos_enc[attention_mask].squeeze(), neg_input_ids: neg_enc[input_ids].squeeze(), neg_attention_mask: neg_enc[attention_mask].squeeze(), }损失函数方面我们可以使用余弦相似度结合交叉熵损失或者直接使用sentence-transformers库中常用的MultipleNegativesRankingLoss的思想。这里展示一个简化的实现import torch.nn.functional as F def contrastive_loss(query_emb, pos_emb, neg_emb, temperature0.05): 计算对比损失。 query_emb: [batch_size, hidden_dim] pos_emb: [batch_size, hidden_dim] neg_emb: [batch_size, hidden_dim] # 计算余弦相似度 pos_sim F.cosine_similarity(query_emb, pos_emb, dim-1) / temperature neg_sim F.cosine_similarity(query_emb, neg_emb, dim-1) / temperature # 将正例相似度与负例相似度拼接第一列为正例 logits torch.stack([pos_sim, neg_sim], dim1) # [batch_size, 2] # 标签是0因为正例在索引0的位置 labels torch.zeros(logits.size(0), dtypetorch.long).to(query_emb.device) # 使用交叉熵损失 loss F.cross_entropy(logits, labels) return loss4.5 训练循环与关键技巧使用accelerate库可以方便地实现分布式训练。训练循环的核心步骤如下from accelerate import Accelerator from tqdm import tqdm accelerator Accelerator() model, optimizer, train_dataloader accelerator.prepare(model, optimizer, train_dataloader) model.train() for epoch in range(num_epochs): for batch in tqdm(train_dataloader): optimizer.zero_grad() # 获取query, positive, negative的嵌入 with torch.no_grad(): # 注意嵌入模型通常通过last_hidden_state的均值或[CLS] token来获取句子表示 query_outputs model(input_idsbatch[query_input_ids], attention_maskbatch[query_attention_mask]) pos_outputs model(input_idsbatch[pos_input_ids], attention_maskbatch[pos_attention_mask]) neg_outputs model(input_idsbatch[neg_input_ids], attention_maskbatch[neg_attention_mask]) # 假设我们取最后一层隐藏状态的均值作为句子嵌入 query_emb mean_pooling(query_outputs.last_hidden_state, batch[query_attention_mask]) pos_emb mean_pooling(pos_outputs.last_hidden_state, batch[pos_attention_mask]) neg_emb mean_pooling(neg_outputs.last_hidden_state, batch[neg_attention_mask]) loss contrastive_loss(query_emb, pos_emb, neg_emb) accelerator.backward(loss) optimizer.step() lr_scheduler.step()关键技巧与避坑点池化方式mean_pooling对有效token取平均是最常用的方式。对于某些模型使用[CLS]或stoken的表示也可能更好需要根据预训练模型的设计来定。Qwen的嵌入模型可能有自己的池化方法需查阅其官方文档。批次构建上述示例使用了最简单的(query, pos, neg)三元组。更高效的方法是“批次内负采样”在一个批次中对于第i个query其正例文档是pos_i而批次中其他query的正例文档pos_j (j!i)自然可以作为第i个query的困难负例。这能提供更丰富的负样本。温度参数temperature这是一个超参数控制相似度得分的平滑程度。值越小模型越关注困难的样本。通常需要调优范围在0.01到0.2之间。梯度检查点如果显存不足可以在from_pretrained时设置use_cacheFalse并启用梯度检查点model.gradient_checkpointing_enable()但这会以增加计算时间为代价换取更小的显存占用。评估与保存每隔一定步数要在验证集上评估模型。评估指标不应只是损失更要用检索任务本身的指标如RecallK。保存模型时使用model.save_pretrained(“my_lora_qwen_embed”)只保存LoRA权重非常轻量。5. 构建推理密集型检索的评估基准思路与实践当我们微调好一个检索器后如何知道它是否真的在“推理密集型”任务上变强了这就需要我们自己的评估基准。构建一个这样的基准可以从一个垂直领域开始。5.1 基准设计核心要素一个合格的推理密集型检索评估基准应包含查询集Queries包含多种推理类型的问题如因果推理为什么、比较推理A和B有何异同、假设推理如果X发生会怎样、多跳推理基于A和B推导C。问题应源自真实场景。文档集合Corpus一个规模适中但信息关联紧密的文档集合。例如一个产品的全套技术文档用户手册、API文档、故障排查指南、版本更新日志。相关性标注Qrels这是最耗时但最关键的部分。对于每个查询需要人工或借助强LLM标注出所有“支撑性文档”的集合。一个文档可能只提供部分证据因此标注粒度最好是段落或句子级别。同时可以标注证据的“角色”如“背景知识”、“核心前提”、“反驳信息”等。评估指标Metrics传统指标RecallK, MRRK。作为基线参考仍有价值。证据集合召回率Evidence Set Recall, ESR对于查询q其标准证据集合为E。检索器返回的Top K个文档集合为R。则ESRK |E ∩ R| / |E|。这衡量了检索器找全所有必需证据的能力。推理链覆盖度Reasoning Chain Coverage, RCC如果标注了证据之间的逻辑顺序推理链可以评估检索结果在多大程度上覆盖了完整的链条而不仅仅是孤立证据点的堆砌。5.2 一个简易的构建流程领域与数据选择选择你熟悉的领域如法律条款、医疗指南、学术论文。收集原始文档并进行清洗、分段。查询生成邀请领域专家或使用强LLM如GPT-4基于文档内容生成需要多步推理才能回答的问题。例如给定一份软件开发合同和一份需求变更记录生成问题“根据合同第5.2条关于范围变更的规定以及本次需求变更记录中描述的改动规模客户是否需要支付额外费用如果需要计算依据是什么”答案与证据标注同样由专家或LLM针对每个问题找出文档中所有相关的段落并撰写最终答案。这构成了标准答案和证据集。构建检索池将所有的文档段落向量化存入向量数据库如FAISS, Chroma。运行与评估用不同的检索器如微调前后的Qwen3-Embedding对查询集进行检索计算上述各项指标进行对比分析。5.3 利用基准进行迭代优化这个自建基准不仅是评估工具更是优化指南。通过分析失败案例高相关但低证据召回我们可以发现模型的弱点是不擅长理解特定领域术语还是无法捕捉长程逻辑依赖然后我们可以有针对性地构造训练数据进行下一轮的微调。例如如果发现模型在需要对比两个概念的查询上表现差我们就可以在训练数据中大量加入“比较型”查询及其对应的正负例文档。这种“评估-分析-改进”的闭环是推动推理密集型检索器性能持续提升的关键。6. 系统集成与未来展望智能体与检索器的共生进化最后让我们回到智能体搜索系统这个宏观图景。一个强大的推理密集型检索器如何与LLM智能体无缝协作6.1 智能体作为检索的“大脑”LLM智能体的核心价值在于规划、推理和决策。在一个复杂的问答任务中智能体应承担以下职责查询理解与分解将用户的模糊或复杂请求解析为明确的、可检索的子问题。检索策略制定决定检索的轮次、每次检索的查询语句、以及需要检索的文档类型或来源。证据综合与验证对检索器返回的多份证据进行交叉验证、去冲突、归纳总结。答案生成与溯源基于综合后的证据生成最终答案并清晰地注明答案的出处哪份文档的哪一段。6.2 检索器作为智能体的“手脚”而检索器则进化成智能体高效、精准的“信息触手”精准执行快速、准确地响应智能体发出的各种检索指令。初步过滤与排序不仅返回相关文档还能根据智能体的上下文或指令对证据进行初步的重要性排序或可信度标注。状态感知在迭代检索中“记住”之前已经返回过的信息避免重复并能根据对话历史优化后续检索。6.3 协同工作流示例一个简单的工作流可能是这样的用户提问“我们项目想用Redis做缓存但担心持久化数据丢失风险。对比一下AOF和RDB两种方式在我们的写多读少场景下哪个更合适需要考虑数据恢复速度。”智能体规划LLM分析后规划出检索步骤a) 查找Redis官方文档中关于AOF和RDB原理、配置、性能影响的详细说明。b) 查找关于“写多读少”场景下Redis性能优化的技术博客或案例。c) 查找AOF和RDB数据恢复速度的基准测试数据。多轮检索检索器根据这三个明确的指令分别从知识库官方文档、技术社区、性能测试报告中召回最相关的片段。智能体综合LLM阅读所有返回的证据理解AOF的“每次写操作日志”与RDB的“定时快照”在写多场景下的性能开销差异对比两者数据恢复的速度数据并结合“写多读少”的场景特点进行推理。生成答案LLM生成一个结构化的回答先简述两者原理然后以表格形式对比在写多场景下的性能、数据安全性和恢复速度最后给出倾向性建议并引用检索到的文档依据。在这个流程中检索器的“推理密集型”能力体现在它需要理解“写多读少”这个抽象场景并将其映射到文档中关于“写入吞吐量”、“磁盘IO”、“fsync频率”等具体技术描述的段落上而不仅仅是匹配“Redis AOF RDB 对比”这几个关键词。未来推理密集型检索与智能体搜索系统的结合将更加紧密。检索器可能会内化更复杂的推理模块甚至能够进行简单的逻辑推理来直接生成初步的证据摘要或答案草稿。而训练方式上基于LLM反馈的端到端优化、从交互轨迹中学习检索策略等方法将会成为主流。对于我们开发者而言理解从“语义匹配”到“推理支撑”的这一范式变迁掌握像LoRA这样的高效适配技术并具备构建领域特定评估基准的能力将是构建下一代智能信息系统的关键。这条路没有标准答案充满了挑战但也正是技术演进的乐趣所在。从我自己的项目实践来看当你看到智能体因为检索器的升级而能流畅地处理那些曾经让它“卡壳”的复杂问题时那种成就感是对所有折腾最好的回报。