RAG 检索到底在做什么？从检索策略、向量数据库到底层搜索算法

上一篇聊完分块以后接下来就是 RAG 里另一个很重要的部分检索。检索这块会遇到很多容易混在一起的概念向量数据库、混合检索、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_001 vector: [0.12, -0.37, 0.84, ...] metadata: - text - document_id - section_path - page - element_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年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】