本文深入解析了RAG检索增强生成中的检索环节从三个层次系统阐述首先介绍了检索策略的选择包括向量检索、关键词检索和混合检索以及如何通过RRF融合和Rerank优化结果排序其次探讨了检索任务的执行者重点分析了向量数据库的核心作用并澄清了向量索引与向量数据库的区别最后深入到底层技术解释了HNSW、IVF等索引方法和PQ、SQ等量化技术如何提高检索效率。检索这块会遇到很多容易混在一起的概念向量数据库、混合检索、HNSW、RRF、重排……。这次重新拆解以后我发现 RAG 的检索其实可以从三个层次来理解第一层我要采用什么检索策略第二层这些检索任务由谁来执行第三层执行检索时底层又使用什么方法第一层决定 RAG 怎么把相关内容找出来第二层关注 谁来充当检索引擎把这些策略真正执行起来例如向量数据库第三层再继续往下理解 向量数据库怎样通过索引和搜索算法在大量数据中快速找到结果。这里讨论的主要是比较常规的、以向量检索为核心的 RAG 系统。GraphRAG 会引入知识图谱和图检索是另一套值得单独展开的检索思路这篇先不放进来。接下来就按照这三层往下看先从最上层的检索策略开始看看一次 RAG 检索到底是怎么被设计出来的。一、第一层检索策略决定“怎么找”RAG 的检索策略可以先从两种最基础的方式开始理解向量检索和关键词检索。① 两种基础检索方式向量检索在 RAG 里通常指基于 Embedding 的语义检索。 它解决的是这两段内容表达的意思是不是相近 所以即使用户的说法和原文并不完全一样只要语义接近也有机会被召回。关键词检索关键词检索关注的是字面上有没有匹配 典型方法就是 BM25。对于标准编号、专有名词、日期、型号等需要精确匹配的内容关键词检索往往更有优势。两种方法解决的问题并不一样向量检索擅长找“意思相近”的内容关键词检索擅长找“字面匹配”的内容。② 把两路召回放在一起混合检索既然两种方法各有所长生产 RAG 中一种很常见的做法就是同时进行向量检索和关键词检索向量检索 关键词检索 → Hybrid Search混合检索这样既能利用语义匹配也不会轻易漏掉标准编号、专业术语等需要精确匹配的信息。但这时又会出现一个问题两路检索分别返回一套结果而且分数不是一个体系。向量检索返回的是向量相似度BM25 返回的是自己的相关性分数。因此不能简单把两个分数直接相加还需要把两路结果融合成一个统一的排名。一种很常见的融合方法就是 RRFReciprocal Rank Fusion。RRF 不直接比较两套不同的分数而是根据一个结果在不同检索列表中分别排在什么位置重新计算融合后的排序。因此一套很常见的检索路径就形成了向量检索 关键词检索 → Hybrid Search → RRF 融合 → 候选结果③ 如果候选结果排序还不够好再做 Rerank前面的检索更强调的是召回先从大量 Chunk 中快速找到一批可能相关的内容尽量不要漏掉真正有用的信息。但“被召回来”并不意味着排序已经足够准确。如果对检索精度要求更高还可以在候选结果之后增加一步 Rerank重排。它不会重新搜索整个知识库而是针对已经召回的一小批候选内容再进行一次更精细的相关性判断把真正最相关的内容排到前面。常见的重排方式包括交叉编码器重排Cross-Encoder把用户问题和候选内容一起输入模型直接判断两者的相关性后期交互Late Interaction例如 ColBERT保留更细粒度的 token 级表示再进行相关性计算大模型重排LLM Reranking直接让大模型对候选内容进行打分或排序学习排序Learning to Rank利用相关性标签、点击等数据训练专门的排序模型。因此一条完整的检索策略线大概是这样的向量检索 关键词检索 → Hybrid Search → RRF → Rerank → Top K其中前半段负责尽可能召回相关内容重排再进一步提高候选结果的排序质量。这就是 RAG 最上层的检索策略先决定用什么方式召回再决定如何融合和筛选这些结果。二、第二层谁来执行这些检索策略第一层解决的是“我要怎么搜”真正落到工程实现时还要继续回答这条检索链里的每一步具体交给谁来完成这里没有一个固定答案。向量检索、关键词检索、结果融合和重排可以由同一个检索引擎提供也可以拆给不同的组件再由应用层把它们编排起来。比如前面这条向量检索 BM25 → RRF → 重排实际实现时可能是向量数据库负责向量检索 → 搜索引擎负责 BM25 → 应用层负责 RRF → 独立重排模型负责重排。也可能使用一个集成度更高的检索引擎把其中多项能力直接放在一个系统里完成。所以这一层需要建立的认识是检索策略决定“需要什么能力”执行层决定“这些能力分别由谁提供”。① 向量数据库是其中最核心的一类组件在常规的向量 RAG 中向量数据库通常是检索系统里最核心的执行组件之一。它并不只是一个“专门存向量的数据库”。一个 Chunk 进入向量数据库以后通常会保存向量Vector由 Embedding 模型生成用来进行相似度检索元数据Metadata / Payload保存原文以及文档、页码、章节等来源信息。例如id: chunk_001vector:[0.12, -0.37, 0.84, …]metadata:textdocument_idsection_pathpageelement_id…其中Vector 用来做相似度检索Metadata 则可以用来做过滤、返回原文和来源追溯。当用户问题被转换成 Query Vector 后向量数据库还要进一步负责建立和维护索引 → 执行向量搜索 → 返回 Top K所以它同时承担两类角色一方面是数据库负责存储和管理数据另一方面也是搜索引擎负责执行向量检索。② 向量索引不等于向量数据库这里还有一个很容易混淆的概念向量索引和向量数据库不是一回事。向量索引解决的核心问题是怎样高效地在大量向量中找到最相似的那些向量而一个完整的向量数据库除了维护索引通常还需要处理数据存储、增删改、Metadata 和过滤、索引更新、持久化和扩展等问题。Faiss 就是一个很典型的例子。Faiss 更接近一个向量搜索和索引库它提供 Flat、IVF、HNSW、PQ 等向量索引和相似度搜索能力但本身并不提供 BM25 这样的全文关键词检索能力。所以如果采用向量检索 BM25 → RRF而向量部分使用 Faiss那么就需要另外引入关键词检索组件。例如向量检索 → Faiss 关键词检索 → Elasticsearch / OpenSearch 等其他组件 RRF → 应用层编排再加上独立的重排模型才组成第一层设计好的完整检索链。而一些功能更完整的向量数据库或搜索引擎可能已经把向量检索、关键词或稀疏检索、过滤、混合检索甚至结果融合中的一部分能力集成进去。所以第二层真正关心的并不是“应该选哪个数据库”而是第一层设计出来的检索策略需要哪些执行能力以及这些能力分别由谁提供。理解到这里再继续往下一层问题就变成了当检索引擎接到“从大量向量中找到最相似结果”这个任务以后它究竟是怎么做到的三、第三层向量检索为什么能够跑得这么快假设数据库里只有几百个向量最直接的办法其实很简单让 Query Vector 和所有向量都计算一次距离再从中选出最相似的 Top K。这种方式通常被称为 Flat Search全量搜索。它不做近似也不会漏掉真正的最近邻但随着数据量从几百增长到几百万甚至上亿每次查询都扫描全部向量的成本会越来越高。因此大规模向量检索真正需要解决的不只是“怎么算两个向量是否相似”还要解决怎样尽量少做这些计算同时仍然快速找到最可能相似的结果这里可以把底层技术分成两个主要方向。① 减少需要比较的向量向量索引与近似最近邻搜索首先要有一种方式判断两个向量到底有多接近。常见的度量包括余弦相似度、点积和欧氏距离。它们负责定义“什么叫相似”但如果数据库里有上百万个向量仅有相似度公式还不够因为逐个计算依然太慢。因此会进一步使用各种近似最近邻搜索ANN和向量索引方法提前把向量空间按照某种结构组织起来让查询时只访问最有可能相关的一小部分数据。这类方法有很多不同路线比较有代表性的包括HNSW基于图结构把相近的向量连接起来。查询时沿着近邻关系逐步向更接近 Query 的区域移动IVF先把向量空间划分成多个区域查询时先找到最可能相关的几个区域再只在这些区域内部搜索。它们的内部结构不同但目标是一致的减少一次查询真正需要访问和比较的向量数量。② 降低每个向量的存储和计算成本量化与压缩另一个优化方向不是继续减少候选数量而是想办法让每个向量本身更小、计算起来更便宜。这类技术通常被称为向量量化或压缩比较典型的包括 PQ乘积量化 和 SQ标量量化。一个 Embedding 可能有几百甚至上千个维度如果每个维度都使用高精度浮点数保存当向量数量达到百万甚至亿级以后会产生很大的内存和存储成本。量化的思路就是用更紧凑的表示近似原始向量从而减少存储占用并降低搜索时的计算成本。当然这种压缩通常也会带来一定的信息损失因此仍然需要在效果、速度和资源消耗之间做权衡。这两类技术并不是互斥的。比如常见的 IVFPQ就是把两种思路组合起来IVF 负责减少需要搜索的范围PQ 负责降低范围内每个向量的存储和计算成本。所以再回头看这一层底层优化其实主要围绕两个问题展开怎么少比较一些向量怎么让每一次比较更便宜HNSW、IVF 代表的是前一个方向PQ、SQ 代表的是后一个方向。而余弦相似度、点积、欧氏距离则处在更基础的一层负责定义两个向量到底怎样才算“更近”。把这几类技术分开以后向量检索的底层逻辑就会清楚很多相似度度量定义“近”索引方法负责快速找到“近”的候选量化方法再进一步降低大规模检索的存储和计算成本。总结回头再看 RAG 的检索很多看起来混在一起的技术其实是在解决不同层的问题。最上层是检索策略。我们需要决定是使用向量检索还是关键词检索是否把两路结果组成混合检索怎样融合结果以及有没有必要进一步增加重排。这里解决的是一次检索应该经过哪些步骤才能找到更相关的内容。往下一层是检索执行。设计好的检索策略最终需要由具体的组件实现其中向量数据库通常承担向量存储和向量搜索的核心任务关键词检索、结果融合和重排则可能由数据库本身提供也可能交给其他搜索引擎、应用代码或专门的模型来完成。再往下才是搜索真正运行起来的底层方法。余弦相似度、点积等方法定义两个向量怎么算“近”HNSW、IVF 这样的索引方法通过减少需要比较的向量让搜索跑得更快PQ、SQ 等量化方法则进一步降低向量的存储和计算成本。把这三层分开以后检索就不再只是“把 Embedding 存进向量数据库然后做一次相似度搜索”而是一套从策略设计、工程实现到底层搜索机制逐层展开的系统。最后当下AI大模型是当下实打实的优质风口岗位缺口大、发展前景广、薪资待遇突出对比内卷严重、涨薪晋升困难的传统技术岗是普通人转行逆袭的绝佳选择。但很多想要入局大模型领域的朋友都面临无系统学习路径、无实战资源、求职无方向的难题一个人硬啃最容易走弯路、浪费大量时间精力。这里我结合多年一线实战与教学经验整理出一套零基础大模型专属资料包含系统化学习路线图零基础到精通大模型学习书籍 文档电子版2026 最新行业报告项目实战 配套源码大厂面试真题需要的朋友微信扫描下方 CSDN 官方认证二维码免费领取保证 100% 免费。扫码免费领取全部内容下面简单介绍一下资料包含的内容1、大模型系统化学习路线图专属定制从零基础入门到企业级实战的全阶段学习体系划分清晰的四大学习阶段规避碎片化学习弊端适配新手2、0基础到进阶视频教程配套完整高清实操教程覆盖Prompt提示工程、RAG知识库搭建、Agent智能体开发、模型微调、部署落地等核心知识点所有课程搭配实操演示零基础也能轻松看懂、上手实操。3、大模型学习书籍 文档汇总30本行业经典AI、大模型、深度学习精选书籍涵盖理论原理、开发实战、算法基础、AI产品思维等各类内容4、AI大模型最新行业报告整理2024-2026年最新大模型行业白皮书、市场分析报告清晰展现行业发展趋势、技术迭代方向、岗位需求变化帮助学习者精准把握行业风口找准学习和就业方向5、大厂面试真题汇总了常见的AI大模型面试问题、知识点梳理和面经参考方便求职时针对性准备。6、大模型项目实战 配套源码包含GPT应用开发、RAG私有知识库、智能问答系统等多个企业级实战项目配套完整可运行源码从简易Demo到完整商业应用全覆盖帮助学习者将理论转化为落地实战能力积累项目经验。7、适合谁学传统后端 / Java / 前端开发想转型 AI 应用大学生、应届生想拿更好的 offer产品经理、运营想武装职业竞争力技术负责人想给团队落地提效学习是反人性的但回报是真金白银。技术会更新赛道会切换但只要你先动手机会就永远站在你这边。8、这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。想要入局AI大模型赛道、抢占行业红利的朋友微信扫描下方CSDN官方认证二维码即可100%免费领取全套学习资料