本文深入剖析了RAG系统中召回质量差的原因，包括单一检索策略、Embedding模型适配不足、检索结果缺乏精排以及离线阶段的问题。文章提出了从Query理解、离线解析到在线召回的全链路优化方案，涵盖Query意图识别、重写、扩写及HyDE技术，多格式文档解析，语义分块策略，Embedding模型选型，混合检索与Rerank精排等关键模块。此外，还介绍了性能优化措施，如批量请求、异步并发、缓存策略等，以及如何将优化方案系统性地呈现给面试官。通过本文的学习，读者可以全面提升RAG系统的召回质量，为实际工作和面试做好准备。

面试官上来就问了一句： “你的 RAG 系统召回了一堆垃圾文档，用户问的是车险理赔流程，你给人家返回了一堆 2020 年的旧流程和通用介绍，怎么优化？”

他愣了几秒，说了句"加个 rerank"，面试官追问"rerank 之前呢？你的候选集本身就是垃圾，rerank 能起多大作用？"

然后他就没了…

这其实是 RAG 系统最核心、最高频的问题——召回质量差。你大模型能力再强，喂进去的上下文是垃圾，出来的答案也是垃圾。这就是经典的 “Garbage in, Garbage out”。

一、先搞清楚：召回为什么会变成"垃圾"？

很多人一上来就想着调参、换模型，但你得先搞清楚问题出在哪。我在实际项目中总结了四大病因：

病因一：单一检索策略的先天缺陷

这是最常见的问题。只用向量检索或者只用关键词检索，都有明显的短板。

只用向量检索的问题： 对于特别短的查询，比如用户就输入了"报销制度"四个字，向量模型拿到的语义上下文非常有限，很难准确度量相似度。结果就是把一堆含"费用"、"财务制度"的内容也拉进来了，真正讲报销制度的文档反而排不到前面。

只用 BM25 的问题： 关键词匹配是死板的字面匹配。用户问"如何推销保险产品"，但公司内部文档写的全是"保险销售策略"、“客户销售技巧”，BM25 根本匹配不上。更离谱的是，它可能召回一堆含"推销"二字但完全不相关的内容，比如"推销非法产品的案例"。

病因二：Embedding 模型的领域适配不足

通用预训练模型对金融保险这类垂直领域的专业术语理解很浅。比如用户问"保单的现金价值指的是什么"，通用 Embedding 模型可能把"现金价值"跟"现金流"、"财务价值"混为一谈，结果召回了一堆讲"公司现金流管理"的财务文档，而真正解释保单现金价值计算方法的文档却被淹没了。

病因三：检索结果缺乏精排

无论是 BM25 还是向量检索，初步检索出来的都只是"可能相关"的候选集。真正最优的答案未必排在前面。

举个实际案例：用户问"最新的车险理赔流程是什么"，检索返回了三类内容——2020年旧流程、2023年新流程、通用理赔介绍。BM25 可能因为旧流程包含更多匹配关键词，把它排在前面。没有精排的情况下，最新最相关的内容就这样被埋没了。

病因四：离线阶段的"原罪"

很多人只盯着在线检索优化，却忽略了一个根本问题——你的知识库本身就有问题。

比如 PDF 多栏排版解析错乱，左栏的"理赔流程"和右栏的"材料提交"被按行拼接成了一坨乱文本。再比如扫描版 PDF 的 OCR 把表格结构全丢了，"险种 | 最高赔付 | 免赔额"变成了"险种 最高赔付 免赔额 A款 500000 5000"这样的一行流水账。

这些问题不解决，后面的检索再怎么优化也是空谈。

二、全链路优化方案：四个模块逐个击破

理解了病因，我们来看治疗方案。RAG 系统的优化要从四个模块系统性地推进：Query 理解 → 离线解析 → 在线召回 → 上下文生成。今天重点讲跟召回质量直接相关的前三个。

模块一：Query 理解——别让用户的烂 query 毁了你的检索

用户输入的 query 往往是模糊的、不完整的、甚至是有歧义的。不做处理直接丢给检索模块，效果能好才怪。

1. 意图识别：先搞清楚用户要什么

意图识别决定了后续走什么链路。比如用户问报销流程，走知识库检索；问"帮我算一下赔付金额"，就应该路由到计算模块而不是纯文本检索。

实现上有三种方案可以组合使用：

规则方法最简单直接——维护一套关键词映射表，query 里出现"报销"“费用"就分到报销流程类，出现"销售”"技巧"就分到销售策略类。优点是快、可控，缺点是覆盖不全。

ML 方法用 BERT 等模型做分类，能捕获语义特征，对同义表达更鲁棒，但需要标注数据训练。

Prompt Engineering 方法最灵活，直接让大模型做 zero-shot 或 few-shot 分类，不需要训练数据，适合快速验证。

实际项目中，我们通常是规则兜底 + ML 模型主力 + LLM 兜底疑难 case 的三级组合。

2. Query 重写：把烂 query 变成好 query

用户问"他们家理赔咋整的"，你直接拿这句话去检索，效果肯定不行。Query 重写就是把用户的口语化、模糊化的输入改写成更适合检索的形式。

核心做法是用 LLM 做改写。比如把"他们家理赔咋整的"改写成"XX保险公司的理赔流程和所需材料"，信息更完整、表述更规范，检索命中率自然就上去了。

在多轮对话场景下，Query 重写还要处理指代消解。用户第一轮问"车险理赔流程"，第二轮追问"那需要什么材料"，这个"那"指的就是车险理赔。如果不做指代消解，第二轮的检索就完全跑偏了。

3. Query 扩写：一个 query 不够，多来几个

有时候用户的 query 用词跟文档不一样，一个 query 检索不到，那就生成多个变体一起检索。

比如原始 query 是"退保怎么操作"，可以扩写出：

• “保险退保流程和步骤”
• “如何申请退保及所需材料”
• “保单退保的具体操作方法”

用这些变体分别检索，然后合并去重取并集，召回覆盖率会大幅提升。

4. HyDE：用假设文档来检索

这是一个很巧妙的思路——让 LLM 根据用户 query 先生成一个"假设的理想答案文档"，然后用这个假设文档的 embedding 去检索，而不是直接用 query 的 embedding。

为什么这样做有效？因为 query 通常很短，语义信息有限；而假设文档是一段完整的回答文本，它的 embedding 跟知识库中真实文档的 embedding 在向量空间中更接近。

模块二：离线解析——把知识库的地基打牢

前面说了，“Garbage in, Garbage out”。离线阶段的质量直接决定了在线检索的上限。

1. 多格式文档解析

企业知识库里什么格式都有——PDF、PPT、Word、扫描图片、甚至视频。每种格式都需要针对性的解析方案。

PDF 多栏排版是重灾区。传统按行解析会把左右栏内容错误拼接，导致语义完全混乱。正确做法是引入版面分析（Layout Analysis）技术，先识别出文档的物理布局结构，再按逻辑顺序提取文本。

扫描版 PDF 和图片必须走 OCR，但普通 OCR 对表格和代码的还原能力很差。表格会被串成一行流水文本，代码的缩进和格式全部丢失。优化方案是对表格区域做专门的表格识别，把结构化信息保留下来；对代码块做格式保持处理。

2. 文本分块策略

分块是离线阶段最关键的环节之一。分块质量直接影响检索精度。

固定长度切分是最简单的，但也是最粗暴的——它会把一个完整的语义单元从中间切断，导致上下文割裂。

更好的做法是语义分块：先按章节、段落等自然结构切分，再对过长的段落递归地按句子拆分，确保每个 chunk 语义自包含且聚焦单一主题。

分块时还需要设置重叠窗口（chunk overlap）。比如上一个 chunk 的最后两句话，同时出现在下一个 chunk 的开头，这样可以避免硬切分导致的上下文断裂。

另外一个容易被忽略的点是层级信息保留。文档有章节、子章节的层次结构，分块时如果把子内容跟它所属的上级标题关联起来，作为元数据存储，检索时就能利用这个上下文提高召回的准确度。

3. Embedding 模型选型

选对 Embedding 模型是向量检索的基础。目前主流的选择：

• 中文或中英混合场景：BGE-M3 或 BGE-large-zh 是最稳的选择，社区验证充分
• 多语言场景：GTE-multilingual-base 或 BGE-M3
• 资源紧张 / 边缘设备：E5-small 或 MiniLM，模型小但效果也不差
• 长文本（≥8K token）：Jina Embeddings v2，支持更长的上下文窗口

一般情况下，无脑选 BGE-M3 不会错。如果你的领域比较垂直（比如金融保险），建议在通用模型基础上用领域数据做微调，效果提升非常明显。

微调的核心思路是构造"问题-正确段落"对作为训练数据，用 MultipleNegativesRankingLoss 做对比学习，拉近正确 query-doc 对的向量距离，拉开无关对的距离。

模块三：在线召回——混合检索 + 精排的组合拳

这是整个召回优化的核心战场。

1. 混合检索：向量 + 关键词，取长补短

单一检索策略各有短板，但组合起来就能互补。

向量检索擅长语义匹配，能理解"推销"和"销售"是一个意思；但对专有名词、编号、精确数值这类需要字面匹配的场景就力不从心。

BM25 关键词检索擅长精确匹配，"报销制度"四个字在文档里出现就能命中；但对同义词、近义词完全无感。

混合检索的做法是：同时执行向量检索和 BM25 检索，把两路结果合并去重，然后用加权公式计算综合得分。权重参数需要根据业务场景调优，一般向量权重 0.3、文本权重 0.7 是一个不错的起点（短查询场景下关键词更重要，可以适当调高文本权重）。

2. Rerank 精排：从"大概相关"到"精准命中"

混合检索拿到的候选集可能有几十甚至上百条，里面肯定有噪声。这时候就需要 Rerank 模型来做精细化排序。

Rerank 模型（通常是 Cross-Encoder 架构）跟 Embedding 模型有本质区别：Embedding 是双塔模型，query 和 doc 各自编码再算相似度，速度快但精度有限；Cross-Encoder 是把 query 和 doc 拼接在一起输入 Transformer，做深度交互后直接输出相关性分数，精度高但速度慢。

所以工程上的最佳实践是两阶段检索：

• 第一阶段（粗召回）：用混合检索快速拿到 Top 50-100 的候选集
• 第二阶段（精排）：用 Cross-Encoder 对候选集重新打分排序，取 Top 5-10 给 LLM

Rerank 模型的选择：

• 经典流水线：BGE-base 检索 Top 100 → BGE-reranker-base 精排
• 多语场景：GTE-multilingual-base + GTE-multilingual-reranker
• GPU 紧张：E5-small + MiniLM-L6-cross-encoder，做 batch 推理
• 长文本：Jina-embeddings-v2 + Jina-colbert-v2，段内匹配更稳

3. 分页策略优化：前几页精排，后面就别费劲了

在实际生产系统中，有一个很实用的优化策略——只对前几页结果做精排。

为什么？因为用户 90% 的情况只看前 1-3 页。对这几页做精排能显著提升体验，但对第 4 页之后还做精排就是浪费算力了。

具体实现是设一个阈值（比如 RERANK_PAGE_LIMIT = 3）：前 3 页先拿一个大候选集（比如 128 条），做完精排后按分页返回；第 4 页及以后直接用初始排序，跳过精排。这个设计在结果质量和系统性能之间取得了很好的平衡。

三、性能优化：别光顾着准，还得快

召回质量上去了，但如果响应速度太慢，用户体验一样糟糕。几个关键的性能优化点：

1. Embedding 阶段加速

• 批量请求：把多个文本一次性发送给 Embedding API，减少网络开销
• 异步并发：用 asyncio 做异步调用，同时控制并发数（5-10 个比较稳妥）避免触发限流
• 缓存 Embedding：对常见 query 的 embedding 结果缓存到 Redis，下次直接复用，跳过 API 调用

2. 向量检索阶段加速

• 选对索引：HNSW 索引在百万级向量上能做到毫秒级查询延迟，且召回率很高
• 调好参数：HNSW 的 efConstruction（建索引时设大点，128 左右）和 efSearch（查询时按需调，64 是个不错的起点）
• 多副本负载均衡：Milvus 支持在 load 时设置 replica_number，多副本可以显著提升 QPS

3. 全链路异步流水线

把 Embedding → 检索 → Prompt 构建 → LLM 生成串成异步流水线，同时引入三级缓存——Embedding 缓存、检索结果缓存、答案缓存，对热点查询可以实现近乎零延迟响应。

四、面试怎么说？

回到开头的面试场景，如果面试官问你"RAG 召回了一堆垃圾怎么优化"，你可以这样回答：

第一步，定位问题在哪个环节。 召回质量差可能是 query 理解不到位、离线分块有问题、检索策略单一、或者缺少精排，需要分模块排查。

第二步，讲你的优化方案。 从四个模块展开：Query 层做意图识别和 query 重写扩写，确保检索的输入质量；离线层优化文档解析和分块策略，确保知识库的底层质量；检索层用混合检索（向量+BM25）提升召回覆盖率；最后加 Rerank 精排模型提升排序质量。

第三步，讲量化评估。 用 MRR、NDCG、Precision@K 等指标做 A/B 对比实验，证明每个优化点的效果。比如混合检索主要提升 Recall@K，Rerank 主要提升 MRR 和 NDCG。

第四步，讲工程落地的取舍。 比如 Rerank 计算成本高，只对前几页做精排；比如 Embedding 模型选型要在效果和推理速度之间平衡；比如缓存策略要考虑数据时效性。

这样回答，既有系统性思维，又有实战细节，面试官想不给你过都难。

写在最后

RAG 的召回优化不是某一个 trick 就能搞定的，它是一个系统工程——从 query 理解到离线解析到在线召回到精排生成，每个环节都有优化空间，每个环节又互相影响。

比如离线分块的粒度要配合 LLM 的上下文窗口来定，分块太大 LLM 一次放不下几个片段，分块太小语义残缺需要拼凑更多片段。再比如 query 解析的准确度直接影响检索路由，解析错了走错链路，后面再怎么优化也白搭。

理解这个全局观，比记住任何一个优化 trick 都重要。

如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线科技企业深耕十二载，见证过太多因技术卡位而跃迁的案例。那些率先拥抱 AI 的同事，早已在效率与薪资上形成代际优势，我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。我们整理出这套 AI 大模型突围资料包：

• ✅ 从零到一的 AI 学习路径图
• ✅ 大模型调优实战手册（附医疗/金融等大厂真实案例）
• ✅ 百度/阿里专家闭门录播课
• ✅ 大模型当下最新行业报告
• ✅ 真实大厂面试真题
• ✅ 2026 最新岗位需求图谱

所有资料 ⚡️ ，朋友们如果有需要 《AI大模型入门+进阶学习资源包》，下方扫码获取~

① 全套AI大模型应用开发视频教程

（包含提示工程、RAG、LangChain、Agent、模型微调与部署、DeepSeek等技术点）

② 大模型系统化学习路线

作为学习AI大模型技术的新手，方向至关重要。 正确的学习路线可以为你节省时间，少走弯路；方向不对，努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划，带你从零基础入门到精通！

③ 大模型学习书籍&文档

学习AI大模型离不开书籍文档，我精选了一系列大模型技术的书籍和学习文档（电子版），它们由领域内的顶尖专家撰写，内容全面、深入、详尽，为你学习大模型提供坚实的理论基础。

④ AI大模型最新行业报告

2025最新行业报告，针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估，以了解哪些行业更适合引入大模型的技术和应用，以及在哪些方面可以发挥大模型的优势。

⑤ 大模型项目实战&配套源码

学以致用，在项目实战中检验和巩固你所学到的知识，同时为你找工作就业和职业发展打下坚实的基础。

⑥ 大模型大厂面试真题

面试不仅是技术的较量，更需要充分的准备。在你已经掌握了大模型技术之后，就需要开始准备面试，我精心整理了一份大模型面试题库，涵盖当前面试中可能遇到的各种技术问题，让你在面试中游刃有余。

以上资料如何领取？

为什么大家都在学大模型？

最近科技巨头英特尔宣布裁员2万人，传统岗位不断缩减，但AI相关技术岗疯狂扩招，有3-5年经验，大厂薪资就能给到50K*20薪！

不出1年，“有AI项目经验”将成为投递简历的门槛。

风口之下，与其像“温水煮青蛙”一样坐等被行业淘汰，不如先人一步，掌握AI大模型原理+应用技术+项目实操经验，“顺风”翻盘！

这些资料真的有用吗？

这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理，现任上海殷泊信息科技CEO，其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证，服务航天科工、国家电网等1000+企业，以第一作者在IEEE Transactions发表论文50+篇，获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。

资料内容涵盖了从入门到进阶的各类视频教程和实战项目，无论你是小白还是有些技术基础的技术人员，这份资料都绝对能帮助你提升薪资待遇，转行大模型岗位。

以上全套大模型资料如何领取？