RAG混合检索原理与落地实践全解析

首页

RAG混合检索原理与落地实践全解析

热心网友

转载

2026-05-20

做RAG系统，十个团队有九个会在检索这一步栽跟头。语义检索、关键词检索、混合检索、Rerank重排序……这些概念听起来简单，但组合起来就是一道复杂的工程选择题。今天，我们把它们一次性讲透。

先说结论

「生产级RAG必须用混合检索。单一检索方式，无论是语义还是关键词，都有致命盲区。」

下面展开讲为什么。

一、RAG检索的关键在哪？

RAG（检索增强生成）的核心流程，说白了就是「先搜，再答」。

这个逻辑很直接：搜得好，大语言模型（LLM）就有高质量的“参考资料”，回答自然靠谱；搜得烂，LLM就只能靠“编”，结果可想而知。可以说，检索层的质量，直接决定了整个RAG系统的天花板。

「Garbage In, Garbage Out.」

目前，主流的检索方式有三种，它们各有各的脾气。

二、三种检索方式一图看懂

假设用户问了这么一句：「Transformer模型的注意力机制是什么？」

三种检索方式会怎么处理？

用户 Query
│
├── ① 语义检索（理解你想问啥）
│     Query → Embedding 向量 → 向量数据库搜索
│     能找到：“自注意力机制通过Q/K/V实现序列内部关联”
│     可能漏掉：包含 “multi-head attention” 但语义向量偏远的文档
│
├── ② 关键词检索（一字不差地匹配）
│     Query → 分词 → 关键词匹配
│     能找到：包含 “Transformer”、“注意力” 等关键词的文档
│     可能漏掉：“自注意力机制让模型学会了序列中各位置的关联”
│
└── ③ 混合检索 = ① + ② + 融合排序
       同时跑两路，合并结果
       兼顾语义理解和精确匹配 ← 这才是正解

看个更直观的对比：

只有混合检索能在所有场景下都保持不错的覆盖度，单一检索方式总会在某些地方“失明”。

三、语义检索：让机器“读懂”你的意思

核心原理

它的工作流可以概括为：文本 → 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」的向量，然后存进向量数据库，用内积（IP）搜索来匹配。

文本 → 分词 → BM25算法 → 稀疏向量（大部分维度为0）
                          ↓
              Milvus SparseFloatVector字段
                          ↓
             查询时也转成稀疏向量，用内积（IP）匹配

稀疏向量长什么样？

词汇表 = {猫:0, 狗:1, 吃:2, 鱼:3, 睡觉:4, ...}  （假设30000个词）
“猫吃鱼” → {0: 1.2, 2: 0.8, 3: 1.5}  // 30000维，只有3个维度非零

每个非零维度的值，就是该词的BM25权重，综合了词频、逆文档频率、文档长度等因素。

生成稀疏向量的三种方式

Milvus中怎么用？

// 定义Collection Schema
schema := &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）」：先把文本用分词器拆成一个个词（Term），然后建立“词 → 文档列表”的反向映射。查询时也拆词，直接查这个映射表。

文本 → 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”和“大语言模型”的文档，召回率会显著提升。

各引擎的实现方式

五、稀疏向量 vs 全文索引，到底选哪个？

这是大家最关心的问题，下面这张详细对比表可以帮你理清思路。

分词能力：核心区别

这是两条路线「最本质的差异」。

「稀疏向量」——黑盒分词：

无法控制“深度学习”是拆成两词还是保持整词
无法添加业务专有术语
无法配置同义词
→ 适合通用场景

「全文索引」——白盒分词：

自定义词典: jieba.add_word(“深度学习”)
专有名词:   jieba.add_word(“ChatGPT”)
同义词扩展: “LLM” ↔ “大语言模型”
停用词控制: 过滤“的”、“是”、“了”
→ 适合中文和专业领域

「划重点：如果你做的是中文RAG，自定义词典和同义词扩展几乎是刚需，这时候全文索引方案有明显优势。」

查询表达力：另一个关键差异

「稀疏向量」只能做相似度搜索，给你一个排好序的结果列表，功能比较单一。

「全文索引」则支持丰富的查询语法：

# 精确短语
“机器学习”                    → 必须连续出现
# 布尔组合
(Transformer OR BERT) AND 预训练 NOT GPT-2
# 通配符
deep*                        → deeplearning, deepfake, ...
# 模糊匹配
machne~1                     → machine（允许1个编辑距离）
# 高亮
搜索“注意力机制” → 返回 注意力机制

什么时候选哪个？

「选稀疏向量」：

只想维护一个向量库（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(“搜索关键词”),
})
// 第三步：合并去重 + Rerank
mergedResults := 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模型

最佳实践

混合检索取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 {
        return nil, fmt.Errorf(“embed dense: %w”, err)
    }
    sparseVec, err := s.embedder.EmbedSparse(ctx, query)
    if err != nil {
        return nil, fmt.Errorf(“embed sparse: %w”, err)
    }

    // 4倍候选量，留给Rerank筛选
    candidates, err := s.vectorRepo.HybridSearch(
        ctx, knowledgeBaseID, denseVec, sparseVec, topK*4,
    )
    if err != nil {
        return nil, 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