开篇总述为什么“检索”是RAG系统的命脉你可能会遇到这样的情况用户问“我们公司的年假政策是什么”——向量检索返回了3个文档块其中2个讲的是“事假政策”只有1个提到了“年假”而且藏在第5段。大模型拿到这3个块勉强拼凑出一个回答但信息不完整、甚至有些地方张冠李戴。这就是RAG系统最核心的痛点——检索精度不够。向量检索虽然强大但它本质上是“语义相似度匹配”而不是“问题-答案相关性匹配”。用户问题和知识库文档之间的表述差异、查询本身的模糊性、以及单一检索模式的局限性都会导致“该召回的没召回不该召回的召了一堆”。在本篇文章中我们将系统性地拆解三个层次的检索优化技术第一查询转换Query Transformation——在检索之前对用户问题做改写、扩展和分解让查询本身更“好搜”第二多路召回与混合检索——用多种检索策略并行搜索再把结果融合起来取各家之长第三重排序Reranking——在初步召回之后用更精细的模型对候选文档重新打分排序把最相关的推到最前面。这三层技术构成了一个完整的“检索优化金字塔”从粗到精、层层递进。读完这篇文章你将掌握一套系统性的RAG检索精度提升方法论。分述一查询转换——让“问题”变得更好搜RAG检索的第一步是把用户的问题送入检索系统。但用户的问题往往“不好搜”——太短、太模糊、表述方式与文档不一致。查询转换Query Transformation的核心思路是在把查询送入向量数据库之前先对查询做一次“预处理”让它变得更适合检索。这个思路之所以有效是因为用户问题和知识库文档之间存在“语义鸿沟”——用户问的是“怎么请假”文档里写的是“休假申请流程”两者语义相同但表述不同向量检索可能匹配不上。1.1 多查询Multi-Query与Fan-Out并行检索这是最直接的查询转换方式让LLM基于原始问题生成多个不同措辞的查询变体然后并行执行检索最后合并结果。原理同一个问题用不同的措辞表达在嵌入空间中的位置不同命中的文档集合也会有所差异。并行执行多个查询变体覆盖更多可能的匹配角度。流程用户提交原始查询LLM生成3-5个语义相近但措辞不同的查询变体各变体并发执行向量检索合并所有检索结果去重将合并后的上下文送入LLM生成答案适用场景用户问题表述模糊、关键词单一、可能存在多种解读方式的情况。1.2 HyDE假设文档嵌入——让检索从“匹配关键词”升级到“理解意图”HyDEHypothetical Document Embeddings是2022年由Luyu Gao等人提出的检索技术在2026年已经成为RAG检索优化的“标配”之一。核心思想非常巧妙不直接用用户查询去做向量检索而是先让LLM针对这个查询“编”一段假设性的答案文档然后用这个假设文档的向量去检索。为什么要这么做因为查询和文档在嵌入空间中的“距离”天然比“答案和文档”更远。用户查询很短几个词到一句话而知识库里的文档块通常很长几百字。一个短向量去匹配长向量语义信息密度不匹配检索精度自然受限。HyDE的完整流程用户提交查询例如“LangSmith是什么以及为什么需要它”LLM生成假设文档模型写出一段可能回答这个问题的合成文本例如“LangSmith帮助开发者监控、调试和评估LLM应用……”生成Embedding把假设文档转成向量——这个向量的信息密度远高于原始查询的向量执行向量检索用假设文档的向量去向量数据库里做相似度搜索生成最终答案检索到的文档进入生成阶段关键要点假设文档不要求事实完全正确——它只需要“一个有用答案大致长什么样”。它起到的作用是“语义桥梁”——把用户问题的意图“翻译”成更接近文档风格和长度的表达。LangChain中的HyDE实现代码改动极小from langchain.embeddings import OpenAIEmbeddings from langchain.chat_models import ChatOpenAI from langchain.chains.hyde.base import HypotheticalDocumentEmbedder llm ChatOpenAI(temperature0) base_embeddings OpenAIEmbeddings() hyde_embeddings HypotheticalDocumentEmbedder.from_llm( llmllm, base_embeddingsbase_embeddings, prompt_keyweb_search ) query LangSmith是什么以及为什么需要它 embedding hyde_embeddings.embed_query(query)实证效果在RAGTurk的基准测试中HyDE将准确率从基线的78.70%提升到了85%。不过需要注意的是HyDE依赖LLM的生成质量——参数量偏小的模型生成的假设文档可能失真反而干扰检索。2026年的演进研究者发现HyDE的效果可以通过反馈模型进一步改进——利用Rocchio等反馈算法从假设文档中提取和加权扩展词能进一步提升检索效果。同时Multi-HyDE多假设HyDE通过生成多个不等价的查询来提升检索的覆盖率和效果。1.3 查询分解——把复杂问题拆成子问题有些查询本身就包含多个子问题单次检索无法覆盖全部所需信息。比如“Milvus和Zilliz Cloud的功能差异是什么”——这个问题涉及两个产品的对比需要分别检索两者的功能信息。查询分解把复杂查询拆解为若干粒度更细的子查询分别检索再合并结果子查询1“Milvus的功能特性有哪些”子查询2“Zilliz Cloud的功能特性有哪些”后退提示Step-Back Prompting是另一种分解思路——先退一步提出一个比原始查询更高层次的问题基于高层问题的检索结果再来回答具体问题。比如把“我有100亿条记录想存储在Milvus中这可能吗”改为“Milvus能够处理的数据集规模上限是多少”分述二多路召回与混合检索——取各家之长查询转换优化的是“检索的入口”而多路召回优化的是“检索的路径”——不依赖单一检索方式而是用多种策略并行搜索。2.1 为什么需要多路召回单一的向量检索虽然强大但它有天然的短板无法处理精确匹配产品型号“ABC-123-XYZ”、日期“2026-07-12”、编号“ORD-8876”——这些精确字符串向量检索的语义匹配往往不如关键词匹配精准语义漂移对于某些查询向量检索可能“过度泛化”召回语义相近但主题无关的内容混合检索的核心思路是同时运行多种检索策略稠密向量稀疏向量/关键词然后融合结果取语义匹配的“广度”和关键词匹配的“精度”。2.2 混合检索的典型架构最成熟的混合检索方案是“稠密向量 BM25稀疏检索”的双引擎并行设计BM25引擎基于倒排索引的关键词匹配保障精确术语的召回稠密向量引擎通过Embedding模型生成语义向量捕捉深层语义关联两个引擎并行检索后各自返回Top-K结果然后进入融合排序层。2.3 RRF倒数排名融合——多路结果的“公平合并”多路召回的结果不能简单拼接——各路检索返回的文档存在重叠排名也不尽相同直接合并会导致高质量文档被低质量文档淹没。RRFReciprocal Rank Fusion倒数排名融合是解决这个问题的标准方案。它不看原始相似度分数而是根据文档在每路结果中的排名位置计算分数RRF_score(d)∑r∈ranks1krankr(d)RRF_score(d)∑r∈ranks​krankr​(d)1​其中k是常数通常取60。排名越靠前得分越高在多路结果中反复出现且名次稳定的文档累计分数也更高。优势RRF不依赖不同检索系统之间的分数可比性直接基于排名融合简单有效。在SemEval-2026 Task 8的多轮RAG评测中使用“LLM驱动的查询改写 稠密-词汇双路检索 RRF融合 交叉编码器重排序”的系统取得了具有竞争力的成绩。分述三重排序Rerank——从“粗召回”到“精排序”如果说“查询转换”优化了检索入口、“多路召回”扩展了检索广度那么重排序解决的是检索的精度问题——在初步召回了一批候选文档后用更精细的模型重新打分排序。3.1 为什么需要重排序向量检索Embedding模型和重排序Rerank模型的核心区别在于计算方式Embedding模型双编码器将查询和文档分别编码成向量然后计算向量相似度。速度快适合海量数据的初步召回但精度有限——查询和文档是“分开编码”的无法捕捉两者之间的细粒度交互Rerank模型交叉编码器将查询和文档拼接在一起输入模型让模型同时看到两者并计算相关性分数。精度更高但计算成本也更高——每次计算都需要完整的模型推理典型RAG检索流程正是利用了两者的互补性第一阶段粗召回用Embedding模型或混合检索从百万级文档中快速召回Top-50/100第二阶段精排序用Rerank模型对这几十个候选文档逐一打分重新排序取Top-3/5送入LLM这种“粗召回 精排序”的两阶段架构兼顾了效率和精度。3.2 主流Rerank模型对比模型特点适用场景BGE-Reranker系列开源中文支持优秀BGE-reranker-large是主流选择中文RAG场景、对成本敏感的生产环境Cohere Rerank商业API服务多语言支持需要多语言支持、不想自建服务的场景Vertex AI RerankerGoogle云服务与Gemini生态整合GCP用户、需要与Vertex AI深度整合DashScope gte-rerank-v2阿里云服务中文优化阿里云用户、中文企业场景实证效果在RAGTurk的基准测试中使用交叉编码器重排序加上下文增强的配置达到了84.60%的准确率接近HyDE的85%但计算成本低得多。3.3 重排序的进阶方向2026年重排序技术正在经历几个重要演进基于LLM的重排序直接用大语言模型如GPT-5.5、Claude作为重排序器让模型对候选文档进行列表级Listwise排序。在SemEval-2026 Task 8中基于LLM的重排序已被证明能有效提升多轮对话场景下的检索精度。图结构重排序GraphER2026年提出的GraphER框架利用数据的组织结构如文档的层级关系、引用关系构建查询时图基于图结构对候选文档重新排序捕捉超越语义相似度的邻近关系。R3-RAG重加权-重排序-反思2026年提出的闭环多模态RAG框架在重排序环节引入了不确定性感知的候选级重排序专门针对科学推理场景。结尾总结从“粗召回”到“精排序”——RAG检索优化的“三步走”让我们回顾一下本文的核心内容第一查询转换是检索优化的“第一道关口”。在问题进入检索系统之前通过多查询并行、HyDE假设文档嵌入、查询分解和后退提示等技术把用户原本“不好搜”的问题转换成“更好搜”的形态。HyDE通过先让LLM生成假设答案再嵌入检索的方式将准确率从78.70%提升到了85%——代码改动极小效果提升明显。第二多路召回与混合检索解决了“单一检索模式不够用”的问题。稠密向量检索擅长语义匹配BM25关键词检索擅长精确匹配两者并行、通过RRF融合取各家之长。RRF不看分数看排名在多路结果中反复出现且名次稳定的文档会获得更高权重。第三重排序是检索精度的“最后一公里”。用交叉编码器对粗召回阶段的候选文档逐一精排把最相关的推到最前面。这种“粗召回精排序”的两阶段架构已经成为生产级RAG系统的标准范式。第四这三层技术构成了完整的“检索优化金字塔”——从查询转换优化入口到多路召回扩展广度再到重排序提升精度层层递进、环环相扣。在实际工程中这三层通常是叠加使用的先用查询转换生成优化的查询再用混合检索做多路召回最后用重排序做精排——每一层都在前一层的基础上进一步提升检索精度。掌握了这套检索优化的完整方法论你的RAG系统就从“能跑”升级到了“好用”。下一篇我们将进入RAG系列的生产级部署与评估篇章——如何用自动评测指标和人工评测流程来量化RAG系统的质量以及如何在生产环境中稳定运行。