RAG检索系统必看:混合检索、关键词检索、语义检索与Rerank全解析,小白也能轻松上手大模型
❝
做 RAG 系统,十个团队九个栽在检索上。本文把语义检索、关键词检索、混合检索、Rerank 重排序一次讲清楚。
❞
先说结论
❝
「生产级 RAG 必须用混合检索。单一检索方式,无论是语义还是关键词,都有致命盲区。」
❞
下面展开讲为什么。
一、RAG 检索的关键在哪?
RAG(Retrieval-Augmented Generation)的核心流程是:「先搜,再答」。
- 「搜得好」 → LLM 有好的"参考资料" → 答得靠谱
- 「搜得烂」 → LLM 只能"编" → 答得一塌糊涂
检索层的质量,直接决定了 RAG 系统的上限。
❝
「Garbage In, Garbage Out.」
❞
目前主流有三种检索方式:
二、三种检索方式一图看懂
假设用户问了一句话:「“Transformer 模型的注意力机制是什么”」
用户 Query │ ├── ① 语义检索(理解你想问啥) │ Query → Embedding 向量 → 向量数据库搜索 │ 能找到:"自注意力机制通过 Q/K/V 实现序列内部关联" │ 可能漏掉:包含 "multi-head attention" 但语义向量偏远的文档 │ ├── ② 关键词检索(一字不差地匹配) │ Query → 分词 → 关键词匹配 │ 能找到:包含 "Transformer"、"注意力" 等关键词的文档 │ 可能漏掉:"自注意力机制让模型学会了序列中各位置的关联" │ └── ③ 混合检索 = ① + ② + 融合排序 同时跑两路,合并结果 兼顾语义理解和精确匹配 ← 这才是正解
看个更直观的对比:
| 场景 | 纯语义 | 纯关键词 | 混合检索 |
|---|---|---|---|
| 「同义词理解」 “提升代码质量” → “提高程序可维护性” | 支持 | 不支持 | 支持 |
| 「精确术语」 “BGE-M3 模型” | 不支持 | 支持 | 支持 |
| 「产品型号/错误码」 “Error 0x80070005” | 不支持 | 支持 | 支持 |
| 「长尾知识/罕见词」 | 不支持 | 支持 | 支持 |
| 「多语言混合」 “Golang 内存泄漏排查” | 支持 | 部分支持 | 支持 |
只有混合检索在所有场景下都能覆盖。
三、语义检索:让机器"读懂"你的意思
核心原理
文本 → Embedding 模型 → 稠密向量(1024 维浮点数组) → 向量数据库 ANN 搜索
简单说就是:把文字变成一串数字,然后用"数字之间的距离"来衡量语义相不相近。
"机器学习是人工智能的一个子领域"→ [0.23, -0.45, 0.67, 0.12, ..., -0.01] (1024 维,每维都有值)特点:• 维度固定(768 / 1024 / 1536),取决于模型• 几乎每一维都非零 → 所以叫"稠密"• 捕捉的是语义:同义词、上下位关系都能 handle
优势
- 理解"你想问什么"——不同表述、不同说法都能匹配上
- 跨语言能力——多语言模型让中英文互搜成为可能
- 对拼写错误、口语化表达有不错的容错性
局限
- 专有名词、低频术语在训练数据中太少,向量"认不准"
- 产品型号、错误码这类**「精确标识符」**完全编不进去
- 黑盒——你没法解释"为什么返回了这条结果"
四、关键词检索:两条截然不同的技术路线
关键词检索不是只有一种做法,它有**「两条完全不同的路线」**。很多人搞混了,所以我重点展开讲。
关键词检索 │ ┌────────────┴────────────┐ ▼ ▼ 路线 A:稀疏向量 路线 B:全文索引 + 分词 (BM25 in Milvus) (jieba + Qdrant/ES) │ │ 把关键词检索 用经典的 "向量化",统一到 倒排索引 向量检索框架中 直接做关键词匹配
两条路线**「都能实现关键词检索」**,但实现机制、能力边界、适用场景完全不同。
路线 A:稀疏向量——把关键词"伪装"成向量
核心思路
把文本用 BM25 或学习型模型(SPLADE、BGE-M3 Sparse)编码成一个**「超高维但绝大部分维度为 0」** 的向量,然后存进向量数据库,用内积搜索来匹配。
文本 → 分词 → BM25 算法 → 稀疏向量(大部分维度为 0) ↓ Milvus SparseFloatVector 字段 ↓ 查询时也转成稀疏向量,用内积(IP)匹配
稀疏向量长什么样?
词汇表 = {猫:0, 狗:1, 吃:2, 鱼:3, 睡觉:4, ...} (假设 30000 个词)"猫吃鱼" → {0: 1.2, 2: 0.8, 3: 1.5} // 30000 维,只有 3 个维度非零
每个非零维度的值 = 该词的 BM25 权重(综合了词频、逆文档频率、文档长度等因素)。
生成稀疏向量的三种方式
| 方法 | 说明 | 特点 |
|---|---|---|
| 「BM25 统计」 | 基于语料统计算词权重 | 简单、可解释 |
| 「SPLADE」 | 学习型稀疏编码模型 | 效果更好,需要推理服务 |
| 「BGE-M3 Sparse」 | BGE-M3 的稀疏输出 | 一个模型同时出稠密 + 稀疏 |
Milvus 中怎么用?
// 定义 Collection Schemaschema := &entity.Schema{ CollectionName: "chunks", Fields: []*entity.Field{ {Name: "id", DataType: entity.FieldTypeVarChar, PrimaryKey: true}, {Name: "dense_vector", DataType: entity.FieldTypeFloatVector, Dim: 1024}, {Name: "sparse_vector", DataType: entity.FieldTypeSparseVector}, // 稀疏向量 {Name: "content", DataType: entity.FieldTypeVarChar}, },}
一个 Collection 里同时放稠密和稀疏两种向量,混合检索一次 API 搞定。
路线 B:全文索引 + 分词——经典信息检索的正统玩法
核心思路
用经典的**「倒排索引(Inverted Index)」**:先把文本拿分词器拆成一个个词,然后建"词 → 文档列表"的反向映射。查询时也拆词,直接查映射表。
文本 → jieba 分词 → 建倒排索引 ↓ 词项 → [文档ID + 位置 + 词频] ↓ 查询时分词 → 查倒排索引 → BM25 打分
倒排索引长什么样?
文档1: "猫吃鱼" → ["猫", "吃", "鱼"]文档3: "狗吃骨头" → ["狗", "吃", "骨头"]文档5: "猫睡觉" → ["猫", "睡觉"]倒排索引:"猫" → [{doc1, pos=[0]}, {doc5, pos=[0]}]"吃" → [{doc1, pos=[1]}, {doc3, pos=[1]}]"鱼" → [{doc1, pos=[2]}]"狗" → [{doc3, pos=[0]}]查询 "猫吃鱼" → 分词 ["猫","吃","鱼"] → doc1 命中 3 个词 → 最相关
分词是灵魂
**「jieba 分词」**在中文 RAG 场景中是最关键的环节之一,它直接决定了索引质量:
# 默认分词——可能出问题jieba.cut("深度学习是人工智能的核心技术")→ ["深度", "学习", "是", "人工智能", "的", "核心", "技术"]# ↑ "深度学习" 被拆开了!# 加自定义词典——效果立竿见影jieba.add_word("深度学习", freq=10000)jieba.add_word("ChatGPT", freq=10000)jieba.add_word("BGE-M3", freq=10000)jieba.cut("深度学习是人工智能的核心技术")→ ["深度学习", "是", "人工智能", "的", "核心", "技术"]# ↑ 完美保持整词
同义词扩展
{ "synonym_filter": { "type": "synonym", "synonyms": [ "LLM, 大语言模型, 大模型", "RAG, 检索增强生成", "Embedding, 嵌入, 向量化" ] }}
搜 “大模型” 时自动匹配 “LLM” 和 “大语言模型”,召回率显著提升。
各引擎的实现方式
| 引擎 | 全文检索实现 | 分词支持 |
|---|---|---|
| 「Elasticsearch」 | 原生全文搜索,最成熟 | 内置 IK 分词、jieba 插件 |
| 「Qdrant」 | Multilingual 全文索引 | 内置多语言分词 |
| 「PostgreSQL」 | ParadeDB @@@ 全文匹配 |
pg_jieba 插件 |
五、稀疏向量 vs 全文索引,到底选哪个?
这是大家最关心的问题,做了一张详细对比表:
| 维度 | 稀疏向量(Milvus) | 全文索引(jieba + ES/Qdrant) |
|---|---|---|
| 「存储格式」 | 高维稀疏浮点向量 | 倒排索引 |
| 「和语义检索的关系」 | 和稠密向量在**「同一系统」** | 可能在**「不同系统」** |
| 「打分算法」 | 向量内积,近似 BM25 | 原生 BM25 / TF-IDF |
| 「混合检索」 | 一次调用搞定 | 两次调用 + 结果合并 |
| 「分词控制」 | 黑盒,不可自定义 | jieba 自定义词典 + 同义词 |
| 「精确匹配」 | 较弱 | 很强 |
| 「查询能力」 | 只有相似度搜索 | 布尔、短语、通配符、正则… |
| 「运维复杂度」 | 低(一个系统) | 中~高 |
分词能力:核心区别
这是两条路线**「最本质的差异」**。
「稀疏向量」——黑盒分词:
无法控制 "深度学习" 是拆成两词还是保持整词无法添加业务专有术语无法配置同义词→ 适合通用场景
「全文索引」——白盒分词:
自定义词典: jieba.add_word("深度学习")专有名词: jieba.add_word("ChatGPT")同义词扩展: "LLM" ↔ "大语言模型"停用词控制: 过滤 "的"、"是"、"了"→ 适合中文和专业领域
❝
「划重点:如果你做的是中文 RAG,自定义词典和同义词扩展几乎是刚需,这时候全文索引方案有明显优势。」
❞
查询表达力:另一个关键差异
**「稀疏向量」**只能做相似度搜索,给你一个排好序的结果列表,没了。
**「全文索引」**支持丰富的查询语法:
# 精确短语"机器学习" → 必须连续出现# 布尔组合(Transformer OR BERT) AND 预训练 NOT GPT-2# 通配符deep* → deeplearning, deepfake, ...# 模糊匹配machne~1 → machine(允许 1 个编辑距离)# 高亮搜索 "注意力机制" → 返回 <em>注意力机制</em>

什么时候选哪个?
「选稀疏向量」:
- 只想维护一个向量库(Milvus/Zilliz)
- 数据量几百万到几千万
- 快速 MVP,不需要复杂检索
- 通用领域,不需要自定义分词
「选全文索引」:
- 中文场景,需要 jieba 自定义词典
- 需要精确匹配:产品型号、法律条款、医学术语
- 亿级数据,ES 分布式更成熟
- 需要布尔查询、短语匹配等高级功能
六、混合检索怎么实现?两种方案实操对比
方案 A:稀疏向量方案(Milvus 原生)
一次 API 调用,数据库内部同时搜两种向量,自动 RRF 融合。
searchRequests := []*milvus.ANNSearchRequest{ // 稠密向量搜索(语义) milvus.NewANNSearchRequest("dense_vector", "COSINE", denseQuery, topK), // 稀疏向量搜索(关键词) milvus.NewANNSearchRequest("sparse_vector", "IP", sparseQuery, topK),}// Milvus 内部完成 RRF 融合results, _ := client.HybridSearch(ctx, collectionName, searchRequests, milvus.NewRRFRanker(60), topK)
「一句话评价」:简单省事,但分词不可控。
方案 B:全文索引方案(双通道)
两次独立调用 + 应用层融合。
// 第一步:向量检索vectorResults := qdrantClient.Search(ctx, &qdrant.SearchPoints{ CollectionName: collection, Vector: queryEmbedding, Limit: uint64(topK),})// 第二步:全文检索textResults := qdrantClient.Query(ctx, &qdrant.QueryPoints{ CollectionName: collection, Query: qdrant.NewQueryText("搜索关键词"),})// 第三步:合并去重 + RerankmergedResults := mergeAndDedup(vectorResults, textResults)finalResults := reranker.Rerank(query, mergedResults)
「一句话评价」:灵活强大,但需要多走一步。
融合排序用什么算法?
最常用的是 「RRF(倒数排名融合)」,简单又有效:
公式: RRF_score(d) = Σ 1/(k + rank_i(d)) k = 60举个例子: 文档 X: 语义排第 1, 关键词排第 5 → RRF = 1/61 + 1/65 = 0.03177 文档 Y: 语义排第 3, 关键词排第 2 → RRF = 1/63 + 1/62 = 0.03200 → Y 排前面(两边都靠前 > 一边极前一边靠后)
RRF 的妙处在于:「只看排名,不看分数」。所以不用操心两路检索分数量纲不同的问题。
七、Rerank 重排序:从"差不多"到"真的准"
为什么还需要 Rerank?
混合检索的第一阶段(召回)追求的是**「快」和「全」**,精度是有限的。Rerank 用更精确的模型做"精排":
Embedding 模型(Bi-Encoder): 分别编码 Query 和 Chunk → 独立向量 → 快,但精度有限Reranker(Cross-Encoder): 同时编码 Query + Chunk → 联合理解 → 慢,但精度高得多
打个比方:「召回是海选,Rerank 是终面。」
常用 Rerank 模型
| 模型 | 特点 |
|---|---|
| 「BGE-Reranker-v2-m3」 | 开源,多语言,中文友好 |
| 「Cohere Rerank」 | 商业 API,效果好,易集成 |
| 「bce-reranker-base_v1」 | 中英双语,轻量级 |
最佳实践
混合检索取 Top 20~50 → Rerank 精排 → 输出 Top 5关键参数:• 召回数量: 最终要 N 条,先召回 4N 条• 分数阈值: 过滤 Rerank 分数太低的结果• 降级策略: Rerank 挂了就退回原始排序,保证可用性
完整代码示例:
func (s *SearchService) HybridSearchWithRerank( ctx context.Context, knowledgeBaseID string, query string, topK int,) ([]*SearchResult, error) { denseVec, err := s.embedder.EmbedDense(ctx, query) if err != nil { returnnil, fmt.Errorf("embed dense: %w", err) } sparseVec, err := s.embedder.EmbedSparse(ctx, query) if err != nil { returnnil, fmt.Errorf("embed sparse: %w", err) } // 4 倍候选量,留给 Rerank 筛选 candidates, err := s.vectorRepo.HybridSearch( ctx, knowledgeBaseID, denseVec, sparseVec, topK*4, ) if err != nil { returnnil, fmt.Errorf("hybrid search: %w", err) } reranked, err := s.reranker.Rerank(ctx, query, candidates, topK) if err != nil { return candidates[:topK], nil// 降级:Rerank 挂了就用原始结果 } return reranked, nil}
八、方案选型:三种架构方案 + 决策树
方案 A:Milvus 单引擎(稠密 + 稀疏向量)
┌─────────────────────────────────┐│ Milvus ││ ┌──────────┐ ┌──────────┐ ││ │ Dense Vec│ │Sparse Vec│ ││ │ (语义) │ │ (BM25) │ ││ └──────────┘ └──────────┘ ││ HybridSearch + RRF │└─────────────────────────────────┘
优点:架构最简,一个库搞定;混合检索一次调用
不足:分词不可控;无复杂查询
方案 B:双引擎(向量库 + 全文搜索)
┌───────────────┐ ┌───────────────┐│ Milvus │ │Elasticsearch ││ (语义检索) │ │ (关键词) │└───────┬───────┘ └───────┬───────┘ └────────┬───────────┘ ▼ 应用层 RRF 融合 → Rerank
优点:各取所长;分词可控;复杂查询
不足:两套系统;需要自己写融合
方案 C:全能引擎(单引擎双模式)
┌─────────────────────────────────┐│ Qdrant / ES v8 / PostgreSQL ││ ┌──────────┐ ┌──────────┐ ││ │ Vector │ │ 全文索引 │ ││ │ (语义) │ │ (关键词) │ ││ └──────────┘ └──────────┘ ││ 单引擎覆盖两种检索模式 │└─────────────────────────────────┘
优点:单引擎双模;运维简单;分词可控
不足:超大规模下不如专业向量库
选型决策树
你的 RAG 项目需要什么?│├── 快速上线 + 数据 < 1000万 + 通用领域│ → 方案 A:Milvus 单引擎│├── 中文场景 + 需要自定义词典 + 精确匹配│ ││ ├── 数据 > 5000万,性能要求高│ │ → 方案 B:Milvus 语义 + ES 关键词│ ││ └── 数据量适中,运维简单优先│ → 方案 C:Qdrant / ES v8 单引擎│├── 多租户 SaaS + 不同客户不同需求│ → 方案 C:全能引擎 + 按需组合│└── 已有 PostgreSQL + 不想引入新组件 → 方案 C:pgvector + ParadeDB
方案对比总结
| 方案 A Milvus | 方案 B 双引擎 | 方案 C 全能引擎 | |
|---|---|---|---|
| 「哲学」 | 一切皆向量 | 术业有专攻 | 每个引擎都全能 |
| 「运维」 | 简单 | 复杂 | 中等 |
| 「分词」 | 不可控 | 可控 | 可控 |
| 「精确匹配」 | 弱 | 强 | 强 |
| 「超大规模」 | 最佳 | 最佳 | 中等 |
| 「代表」 | Dify (Milvus) | 自研大系统 | Qdrant / ES v8 |
附录:核心术语速查
| 术语 | 解释 |
|---|---|
| 「RAG」 | 检索增强生成,先搜再答 |
| 「ANN」 | 近似最近邻搜索,用少量精度换速度 |
| 「BM25」 | 经典关键词检索算法 |
| 「RRF」 | 倒数排名融合,多路结果合并算法 |
| 「SPLADE」 | 学习型稀疏编码模型 |
| 「Bi-Encoder」 | 分别编码 Query 和 Doc(Embedding 模型) |
| 「Cross-Encoder」 | 同时编码 Query + Doc(Reranker) |
| 「倒排索引」 | 从词到文档列表的映射 |
| 「jieba」 | 中文分词库,支持自定义词典 |
| 「Dense Vector」 | 稠密向量,编码语义 |
| 「Sparse Vector」 | 稀疏向量,编码关键词权重 |
| 「Rerank」 | 重排序,对召回结果精排 |
| 「pgvector」 | PostgreSQL 向量搜索扩展 |
| 「ParadeDB」 | PostgreSQL 全文搜索扩展 |
| 「HNSW」 | 多层级近邻图索引 |
写在最后
RAG 的检索层看似简单,但真正做好需要理解:
- **「语义检索」**理解"你想问什么",但对精确术语无能为力
- **「关键词检索」**擅长精确匹配,但对同义表述视而不见
- **「混合检索」**是唯一的正确答案,关键在于选对技术路线
- 「Rerank」 是从 80 分到 95 分的最后一公里
- **「选对架构」**让你面对不同场景都能从容应对
普通人如何抓住AI大模型的风口?
领取方式在文末
为什么要学习大模型?
目前AI大模型的技术岗位与能力培养随着人工智能技术的迅速发展和应用 , 大模型作为其中的重要组成部分 , 正逐渐成为推动人工智能发展的重要引擎 。大模型以其强大的数据处理和模式识别能力, 广泛应用于自然语言处理 、计算机视觉 、 智能推荐等领域 ,为各行各业带来了革命性的改变和机遇 。
目前,开源人工智能大模型已应用于医疗、政务、法律、汽车、娱乐、金融、互联网、教育、制造业、企业服务等多个场景,其中,应用于金融、企业服务、制造业和法律领域的大模型在本次调研中占比超过 30%。
随着AI大模型技术的迅速发展,相关岗位的需求也日益增加。大模型产业链催生了一批高薪新职业:
人工智能大潮已来,不加入就可能被淘汰。如果你是技术人,尤其是互联网从业者,现在就开始学习AI大模型技术,真的是给你的人生一个重要建议!
最后
只要你真心想学习AI大模型技术,这份精心整理的学习资料我愿意无偿分享给你,但是想学技术去乱搞的人别来找我!
在当前这个人工智能高速发展的时代,AI大模型正在深刻改变各行各业。我国对高水平AI人才的需求也日益增长,真正懂技术、能落地的人才依旧紧缺。我也希望通过这份资料,能够帮助更多有志于AI领域的朋友入门并深入学习。
真诚无偿分享!!!
vx扫描下方二维码即可
加上后会一个个给大家发
【附赠一节免费的直播讲座,技术大佬带你学习大模型的相关知识、学习思路、就业前景以及怎么结合当前的工作发展方向等,欢迎大家~】
大模型全套学习资料展示
自我们与MoPaaS魔泊云合作以来,我们不断打磨课程体系与技术内容,在细节上精益求精,同时在技术层面也新增了许多前沿且实用的内容,力求为大家带来更系统、更实战、更落地的大模型学习体验。

希望这份系统、实用的大模型学习路径,能够帮助你从零入门,进阶到实战,真正掌握AI时代的核心技能!
01 教学内容

-
从零到精通完整闭环:【基础理论 →RAG开发 → Agent设计 → 模型微调与私有化部署调→热门技术】5大模块,内容比传统教材更贴近企业实战!
-
大量真实项目案例: 带你亲自上手搞数据清洗、模型调优这些硬核操作,把课本知识变成真本事!
02适学人群
应届毕业生: 无工作经验但想要系统学习AI大模型技术,期待通过实战项目掌握核心技术。
零基础转型: 非技术背景但关注AI应用场景,计划通过低代码工具实现“AI+行业”跨界。
业务赋能突破瓶颈: 传统开发者(Java/前端等)学习Transformer架构与LangChain框架,向AI全栈工程师转型。

vx扫描下方二维码即可
【附赠一节免费的直播讲座,技术大佬带你学习大模型的相关知识、学习思路、就业前景以及怎么结合当前的工作发展方向等,欢迎大家~】
本教程比较珍贵,仅限大家自行学习,不要传播!更严禁商用!
03 入门到进阶学习路线图
大模型学习路线图,整体分为5个大的阶段:
04 视频和书籍PDF合集

从0到掌握主流大模型技术视频教程(涵盖模型训练、微调、RAG、LangChain、Agent开发等实战方向)

新手必备的大模型学习PDF书单来了!全是硬核知识,帮你少走弯路(不吹牛,真有用)
05 行业报告+白皮书合集
收集70+报告与白皮书,了解行业最新动态!
06 90+份面试题/经验
AI大模型岗位面试经验总结(谁学技术不是为了赚$呢,找个好的岗位很重要)

07 deepseek部署包+技巧大全

由于篇幅有限
只展示部分资料
并且还在持续更新中…
真诚无偿分享!!!
vx扫描下方二维码即可
加上后会一个个给大家发
【附赠一节免费的直播讲座,技术大佬带你学习大模型的相关知识、学习思路、就业前景以及怎么结合当前的工作发展方向等,欢迎大家~】
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念,把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起,为开发者提供从开发、训练到部署的一站式体验。
更多推荐

所有评论(0)