检索技术

检索技术

检索是 RAG 的「第一公里」：检索到什么，决定生成能有多好。本页讲检索技术的原理：关键词与向量两条路线、embedding 与向量索引、BM25、混合检索与重排、切块策略，以及检索质量怎么评估。RAG 整体流程与产品视角见 RAG 基础，查询改写、GraphRAG、Agentic RAG 等进阶方案见 高级 RAG。

检索在 RAG 中的位置

RAG 的检索侧是一条小管线，先建立全局视角再逐节展开：

1
2
3
4

用户问题 → 查询处理 → 编码为查询向量 → 检索器（向量路 + 关键词路）
                                             → 融合排序 → 重排精排 → 进入生成
                                      ↑
资料库 → 切块 → 编码为块向量 → 索引（向量索引 + 倒排索引 + 元数据）

这条管线里的每个环节（查询处理、切块、embedding、索引、融合、重排）都影响「正确的块能不能进生成上下文」——本页讲除查询处理（见 高级 RAG）之外的各个环节。

检索的两条路线

检索本质上是在资料库中找出「与问题最相关」的内容，实现路线分两大派：

• 关键词检索（稀疏）：把文档拆成词，建倒排索引，查询时按词匹配打分。代表算法：TF-IDF、BM25
• 向量检索（稠密）：把文档和查询都编码成语义向量，按向量相似度打分。代表算法：embedding + ANN 近邻搜索

直觉对比：用户问「报销流程」，关键词路要求文档里出现「报销」这个词；向量路允许文档里写的是「差旅费用规范」——它知道这两者语义相近。反过来，用户问「A100 显卡」，关键词路精确命中型号，向量路可能把「A1000」也当成语义邻居召回来。结论：两条路线互补，混合检索（两路都跑再融合）通常好过任何单一检索器，这是当前产品化 RAG 的标配。

何时用哪条路线

Embedding 与向量化

embedding 是什么

Embedding 是把文本映射为语义向量（如 768/1024/3072 维浮点数）的模型输出：语义相近的文本，向量距离近；语义无关的文本，向量距离远。「报销流程」与「差旅费用报销规范」即便没有共同的词，向量距离也可能很近——这就是向量检索能「听懂换种说法」的原因。

向量不是「词的一个编号」，而是模型在训练中学出来的语义坐标：每个维度捕捉一种语义特征（语法角色、话题、情感、领域……），维度越多表达能力越强、存储与计算成本也越高。选维度时按数据量权衡：小库用低维足够，大库与长文档用高维。

双塔架构

主流的文本 embedding 模型采用双塔（dual encoder）架构：一个编码器处理文档、另一个编码器处理查询（或共享同一编码器），各自输出向量，训练目标就是让「相关的文档-查询对」向量更近（用对比学习：拉近正样本对、推远负样本对）。训练数据的正负样本决定了模型「觉得什么相关」：通用语料训的模型懂通用语义，领域语料训的模型才懂领域黑话。双塔把「理解语义」前置到向量空间，查询时只做向量运算，所以检索可以很快——这是它与后面要讲的 cross-encoder 重排模型的本质区别：双塔每个文本独立编码一次（向量可离线算好存库），重排模型要「问题 + 文档」两两配对算，只能在线跑少量候选。

相似度度量

工程要点：用什么度量要跟模型匹配——多数公开 embedding 模型按余弦训练，别换成点积/欧氏后不做归一化；向量数据库默认度量与模型不匹配是「检索效果突然变差」的常见原因。少数模型（如部分按点积训练的双塔）另说，选模型时看官方说明。

向量距离的直觉例子

同一句「如何申请报销」的三个候选块：

• 块 A「员工差旅费用报销申请流程」（语义相近，距离近——应当命中）
• 块 B「报销单据粘贴规范」（语义相关但侧重不同，距离中等）
• 块 C「公司组织架构调整公告」（语义无关，距离远）

向量检索按距离排序会给出 A、B、C 的顺序——这就是「语义相关」的直观工作方式。注意向量路说不出「因为都提到了报销」，它只「觉得」A 和问题在语义空间里靠得近。

embedding 模型的选择

• 开源：BAAI 的 bge 系列（bge-large-zh 等中文模型、bge-m3 多语言，支持 8000+ 字符长文本）、bge-reranker 系列配套重排；HuggingFace MTEB 榜单（MTEB）可横向对比主流模型效果
• 闭源 API：OpenAI text-embedding-3-small/large（支持 1536/3072 维输出、可按需降维）、Cohere Embed（多语言、可按需压缩维度）——能力与价格以官方页面为准（OpenAI Embeddings 文档、Cohere Embed 文档）
• MTEB 一句话：MTEB 是覆盖 100+ 数据集、50+ 语言的 embedding 基准榜，看榜时注意挑与你的语言、任务类型匹配的子集，总榜第一不等于你的场景第一

选型实操：先按语言筛（中文场景优先中文/多语言模型），再在你的领域语料上跑小评测集实测；关注「检索命中率」而不是单看模型卡的数字；同模型的不同维度档位（如 1536 vs 3072）也值得在成本与效果间测一下——维度减半成本与内存都可能减半，效果未必差多少。

何时需要微调 embedding

通用 embedding 模型在垂直领域（法律、医疗、代码、公司内部黑话）可能「听不懂」领域同义关系。要不要微调 embedding 的决策：

• 先试用领域相关的现成模型（如法律/医疗领域微调版），多数场景够用
• 再测差距：小评测集上对比通用模型与领域模型，命中率差 < 3-5% 就不值得微调
• 真需要微调时：准备领域「相关对/不相关对」数据（几百到几千条），用对比学习继续训练；微调后必须重新嵌入全库、重跑评测集——这是一次全链路改动，不只是换个模型

向量检索与 ANN

精确检索的代价

最朴素的做法是暴力扫描：查询向量与库中每一个向量算相似度，取最大的 k 个。十万级文档可行，百万级以上每次查询都要全库扫描，延迟与算力都不可接受——100 万向量、768 维，一次全扫是亿次级浮点运算，单次查询要数百毫秒到秒级，且内存占用约 3 GB（100 万 × 768 维 × 4 字节）。所以需要近似最近邻（ANN，Approximate Nearest Neighbor）索引，用「少量精度损失」换「几个数量级的提速」。

ANN 三大类

参数直觉

以 FAISS 为代表，各库命名略有差异：

• HNSW：M（每层邻居数，越大召回越高内存越大）、efConstruction（建图精度，建库时用）、efSearch（查询时搜索范围，越大越准越慢）——调 efSearch 是最常用的「精度-延迟」旋钮，128-512 是常见范围
• IVF：nlist（簇数量，越多检索越细但建库越慢）、nprobe（查询时探访几个簇，越大越准越慢）——小库 nlist 设几百就够，nprobe 从 10-20 起调
• PQ：分段数 × 每段码位数决定压缩比，压缩比越高召回损失越大——大库优先，配合 IVF 用（IVF-PQ 是 FAISS 海量场景的标准组合）

召回率-延迟-内存三角

ANN 的本质是权衡：召回率（近似度）↑、延迟 ↓、内存 ↓ 三者不可兼得。HNSW 召回高但内存大；IVF 省内存但召回依赖聚类质量；PQ 最省内存但召回损失最大。产品化常用组合：IVF 或 HNSW 做粗召回 + 后面 rerank 精排补精度，让「粗召回快而全、精排准而贵」——ANN 的精度损失被 rerank 兜住，这是工程上最常见的搭配。调参决策也是三角取舍：延迟预算紧就调小 efSearch/nprobe，内存紧就上 PQ，两者都不紧就无脑 HNSW。

向量数据库与索引实现

• Milvus：云原生分布式向量数据库，支持十亿级规模与 GPU 加速，重场景（Milvus 官网）
• Qdrant：Rust 实现，原生支持混合检索（稠密 + 稀疏向量 + RRF 融合），轻量易部署（Qdrant 文档）
• Chroma：轻量嵌入式，原型与 demo 最快，适合起步（Chroma 文档）
• pgvector：PostgreSQL 扩展，已有 PG 基建的场景零新增组件，百万级够用（pgvector 仓库）
• FAISS：Meta 开源的 ANN 算法库，不是数据库，适合自建管线（FAISS 仓库）

选型一句话：数据量 < 100 万、已有 PG → pgvector；要混合检索与托管 → Qdrant；重规模与运维能力 → Milvus；原型验证 → Chroma；自建管线 → FAISS。供应商与托管方案的细节见 LLM API 与供应商；本文只给定位，不展开商业对比。

向量数据库选型对比

关键词检索与 BM25

倒排索引

关键词检索的地基是倒排索引：一张「词 → 包含该词的文档列表」的表。建索引时对每篇文档分词、把词登记进表；查询时把问题分词，查表拿到候选文档集合，再按打分公式排序。建索引只需一次（离线），查询只在词表上做集合运算，所以极快、极省资源——100 万文档的关键词查询是毫秒级。

示例直觉：「报销」→ [文档 3、文档 17、文档 102]；「流程」→ [文档 3、文档 5]；查询「报销流程」= 取两个词的交集候选，再按分数排序。

TF-IDF 直觉

TF-IDF 给每个「文档-词」对打分，两项相乘：

• TF（词频）：词在文档里出现得越多越重要——但长文档天然词频高，需要归一
• IDF（逆文档频率）：词越稀有越有区分度——「报销」比「公司」更有信息量，因为几乎所有文档都有「公司」

直觉例子：「报销」在制度文档里出现 5 次、在另一篇文档出现 1 次，且「报销」在全局很少见——前一篇文档的相关分远高于后一篇。而「公司」出现 50 次也说明不了什么——大家都用这个词。

BM25 为什么是基线强手

BM25 是 TF-IDF 的概率化改良，至今仍是关键词检索的事实标准（Okapi BM25 - Wikipedia），强在两点：

• 词频饱和：词频加到一定程度后收益递减，避免「重复最多的词 = 最相关」——文档里「报销」出现 50 次不比出现 10 次好 5 倍
• 文档长度归一：长文档词频天然高，按长度打折，避免长文档系统性占优

打分直觉（示意，完整公式见 Wikipedia）：

1

score(查询, 文档) = Σ 每个查询词:  IDF(词) × 词频饱和项(出现次数, k1) ÷ 长度归一项(文档长度, b)

两个可调参数：k1（词频饱和速度，默认 1.2-2.0）、b（长度归一强度，默认 0.75）。再加上实现简单、零训练成本、解释性强，BM25 至今是任何 RAG 检索基线的首选——先拿 BM25 出基线，再叠加向量检索，用评测数据决定是否加复杂度。

BM25 的领域适配

• 分词：中文要先用分词器（jieba 等）切词，分词质量直接决定命中率；英文要做小写化、词干化
• 停用词：去掉「的、了、是」等高频无义词，减小倒排索引体积、避免低区分度词干扰
• 专有名词：产品名、型号、人名要保证不被错误切分（自定义词典，如「ChatGPT」不能被切成「Chat」+「GPT」）
• 参数：k1 与 b 有默认值，领域语料上可用评测集调优；文档长短差异极大的库，b 调大（长度惩罚更强）
• 同义词扩展：领域同义词表（「打款」=「付款」）可手工扩充，代价是维护成本——这恰恰是向量检索最擅长的部分，所以实践中「同义词交给向量路，精确词交给关键词路」分工最省事

混合检索与重排

混合检索：为什么要混

单路检索各有盲区：向量漏精确术语，关键词不懂同义改写。混合检索 = 两路（或多路）各跑各的，再融合排序，让语义与精确互补——文档量上来之后，这是召回质量最实在的兜底手段。典型形态：向量路（语义覆盖）+ 关键词路（精确覆盖）+ 元数据过滤（权限/时效/类型收窄），三路合成最终候选集。

融合方式

RRF 为什么安全：它只看「排名」，向量分数是 0-1 的余弦、BM25 分数是无界的，直接相加必然被量纲大的那路主导；按名次融合天然免除了这个麻烦，所以「没有评测集时先上 RRF」是工程默认。

工程要点

• 融合的候选集合要够大：各路各取 top-k（如 50），融合后取前 5-10 进生成，避免「某一路的相关块被另一路挤掉」
• 融合前可先按元数据过滤（权限、时效、文档类型），缩小候选集、省后续精排成本
• 优先选原生支持混合查询的向量库（如 Qdrant），把两路检索与融合收敛在存储层，少维护一套自拼逻辑
• 融合参数（各路权重、RRF 的 k）都是可调参数，一律用评测集定，不拍脑袋

重排（rerank）：两阶段检索

粗召回阶段（向量 + 关键词）追求「快而全」，精排阶段用更强的模型对候选逐条打分，只留最相关的几个进生成：

• cross-encoder reranker：把「问题 + 候选文档」拼成一个输入，用完整 Transformer 编码，直接输出相关性分数——它看到的是问题与文档的完整交互（双向注意力能对齐「问题里的『它』指文档里的哪句」），比双塔的「向量近似」准得多，代价是每个候选都要一次模型推理，只能对少量候选用（LangChain reranker 文档）
• 后期交互（ColBERT）：把文档 token 级向量存下来，查询时对 token 级向量做最大相似度匹配（MaxSim），在「比双塔准、比 cross-encoder 快」之间取折中（ColBERT 论文）
• 模型选型：小模型可免费在 CPU 上跑（如 BAAI/bge-reranker-v2-m3 多语言），追求极致可用更大的 1.5B 级模型（需 GPU）；托管方案有 Cohere Rerank，按 search units 计费，另有 fast 变体降本提速（Cohere Rerank 文档）
• 典型配置：粗召回 top-20-50 → rerank → 取 top-3-5 进生成
• 对最终质量的杠杆：rerank 是「对 RAG 流水线质量提升最大的单点改进之一」——top-20 粗召回 + rerank 取 top-3，往往比单路直接取 top-3 好一个档次；代价是延迟与成本，所以只对候选集精排、不对全库精排

端到端配置示例

一个中等规模知识库（10 万文档、100 万块）的典型检索配置（示意，参数以评测为准）：

1
2
3
4
5
6
7

切块：递归切块，chunk_size 512 token，overlap 10%，父子块（父块上限 2000 token）
嵌入：bge-m3（多语言，1024 维），余弦相似度
索引：HNSW（M=16, efConstruction=200, efSearch=256）
关键词路：jieba 分词 + 自定义词典（产品名/型号），BM25（k1=1.5, b=0.75）
融合：RRF（k=2），各路 top-50，融合后取 top-20
重排：bge-reranker-v2-m3，对 top-20 精排，取 top-3 进生成
元数据过滤：权限标签、更新时间（检索前过滤）

每个参数都有评测集上的对应指标——改 efSearch 看延迟与命中率的此消彼长，改 chunk_size 看命中率与回答质量，全部可回滚可对比。

切块策略

切块（chunking）决定检索单元的大小与边界，是 RAG 的第一工程决策：块太大，检索不精确、上下文浪费；块太小，语义断裂、上下文不足。切块策略还直接影响引用粒度——块越碎，引用越精确，但「来源可读性」越差。

• 块大小与重叠的权衡：块越大语义越完整、但匹配越粗；块越小匹配越精确、但上下文越缺。相邻块之间留重叠（overlap，如 10-20%）能缓解「答案恰好被切断在边界」的问题
• 固定切块：按固定 token 数切，长度稳定、实现简单，但会在句子中间切断——英文可按字符/token 切，中文还要避免把词切开
• 递归切块：按段落 → 句子 → token 的层级递归切，优先尊重结构边界，是实用默认（LangChain RecursiveCharacterTextSplitter 一类）
• 语义切块：按相邻句子的向量相似度自适应找断点，块更连贯，但对语言敏感（LlamaIndex node parser 文档）
• 父子块与上下文补充：小块嵌入做精确检索、命中后把其所属的大块（父块）一起给生成——「窄检索 + 宽上下文」的经典组合，检索的精确性与生成的上下文完整性同时满足
• 上下文化切块：Anthropic Contextual Retrieval 的思路——切块后先让模型为每块补一段「上下文说明」（所在文档、主题、与其他块的关系），再嵌入与检索，能显著提升命中率（Anthropic Contextual Retrieval）
• 结构化内容先解析再切：代码块、表格、HTML、Markdown 先用对应解析器提取，再决定切法——表格可以整表一块、代码按函数切、Markdown 按标题层级切

常见切块错误

• 在句子中间硬切：固定 token 切分最常见的产物——块以半句话开头、半句话结尾，嵌入时语义残缺，检索命中率直接崩
• 列表/表格被拆散：一条制度的三列数据被分到三个块，查「职级 P7 年假」时找不到完整对应
• 块内无上下文：条文编号单独一块、正文单独一块，命中「第 34 条」时模型看不到条文内容——父子块与上下文化切块就是为这类问题设计的
• 切法与检索粒度脱节：用户问的是条款级问题，块却切到章节级——检索命中「第五章」整块，答案淹没在大段文字里

参数配置建议

• chunk_size：256-512 token 是常见起点（经验值，非铁律），长文档知识库可试 512-1024；必须与 embedding 模型匹配——不同模型对块大小的偏好不同
• chunk_overlap：10-20% 起步，答案常跨边界时加大
• 全部做成可配置参数：切块没有普适最优解，把大小、重叠、切法暴露为配置，在同一评测集上对比后再定——这是「切块是 RAG 的第一工程决策」的落地方式

全局影响

切块策略影响检索、上下文组装与引用三个环节——切法变了，命中率、回答质量、引用正确率全变。没有普适最优切法（不同 embedding 模型偏好不同块大小，ada-002 时代 256-512 token 块较优是经验值而非铁律），必须把块大小、重叠、切法做成可配置参数，用评测集对比后定案。

检索评估

组件级评估直接衡量「检索这一步」的质量，先于端到端评测暴露问题：

评测集构建（检索线的地基）：

1. 收集 30-50 个真实问题（常见、长尾、应拒答、跨文档、多轮）
2. 为每个问题标注「应命中的文档/块 id」——这是检索评测的必要标注，人工做
3. 批量跑检索管线，统计 top-⅕/10 的命中率与 MRR；按问题类型分组看短板
4. 每次改动（切块、embedding、索引参数、融合权重）重跑同一评测集，出对比报告

检索调试工作流

当命中率不达标时，按固定流程排查：

1. 人工看案例：随机抽 10 个 miss 案例，读「问题 + top-k 结果」，归类失败原因（切块碎？查询含混？术语没覆盖？）
2. 单路对比：分别跑向量路、关键词路，看是哪一路丢的——两路都丢，问题在切块/查询；只有一路丢，补那一路
3. 查索引与元数据：相关块真的入库了吗？被权限/时间过滤掉了吗？——「检不到」先排除「压根没入索引」
4. 调参迭代：按上一步定位，改对应环节（切块参数 / 查询改写 / 融合权重 / rerank），重跑评测集对比
5. 记录结论：每次调试留下「问题 → 假设 → 实验 → 结论」，避免重复踩坑

评估报告示例

1
2
3
4
5
6

检索基线（BM25 + 向量 + RRF）:
  hit@5: 0.72   MRR@10: 0.61   recall@10: 0.78
+ rerank 后:
  hit@5: 0.86   MRR@10: 0.79   recall@10: 0.80
按问题类型分组:
  常见问题  hit@5 0.95 | 长尾问题 0.68 | 跨文档 0.71 | 多轮追问 0.55 ← 多轮是短板

报告的价值在于分组：整体数字会掩盖「多轮追问全挂」的结构性短板。

要点：

• 检索评测要批量跑，而不是逐条看——单次检索好坏说明不了问题（LlamaIndex 官方评测文档）
• 组件级评估与端到端评估是两回事：检索命中率 100% 不保证回答正确（生成可能无视资料），回答正确也可能检索很烂（答案在常见知识里）——组件级定位「哪一环坏了」，端到端评估衡量「用户体感如何」，两者要分开跑、对起来看；端到端指标（RAGAS 等）见 高级 RAG 的「RAG 评测体系」

常见问题 FAQ

• 向量维度是不是越大越好？ 不是。维度大表达能力强，但内存、延迟、成本都涨；768/1024 维对多数场景够用，选维度看数据量与评测结果，不看「越大越高级」
• HNSW 和 IVF 选哪个？ 内存够、要召回 → HNSW；内存紧、海量 → IVF(-PQ)；拿不准就在你的库上各跑一版评测
• BM25 还要不要自己实现？ 不要。Elasticsearch、Lucene、Rank-BM25 库都是现成的，直接用；你要做的是分词与词典适配
• rerank 一定要上吗？ 「提升最大的单点改进之一」——预算允许就先上；延迟敏感场景用 CPU 可跑的小 reranker
• 切块大小多少合适？ 256-512 token 是常见起点，但必须用评测集在你的语料上对比；不同 embedding 模型偏好不同
• 为什么换了向量库后检索变差了？ 先查相似度度量是否与 embedding 模型匹配（最常见原因），再查 ANN 参数是否一致
• 检索评测集要多大？ 30-50 条起步够暴露主要问题；按问题类型分层（常见/长尾/跨文档/多轮），别全放简单问题

产品视角

• 检索质量 = 产品体验上限：检索不到，生成再好也没用——模型只能基于拿到的资料回答，top-k 里没有答案，后续一切优化都是空中楼阁。预算分配上，检索侧的投入（切块、混合、重排、评测集）通常回报最高
• 检索延迟预算：检索链路（embedding + ANN + 融合 + rerank）的延迟要按用户场景设预算——客服问答可接受 2-3 秒，实时助手要秒级；粗召回取小 top-k、精排只对少量候选、向量库上 ANN 参数调优（如调小 efSearch/nprobe），都是在预算内换质量的手段

• 监控指标清单：无命中率（检索空结果的比例）、top-1 相关率（抽样人工标注）、检索延迟分位数（p50/p95）、检索失败率（向量库超时/报错）——上线前定阈值，上线后监控
• 日志与 badcase 回流：线上检索要打日志（问题、检索命中的块 id、排序分、各路贡献），监控无命中率与 top-1 相关率（抽样人工标注）；每个错答案例回流归因——是切块问题、检索问题还是生成问题——修好后补进评测集防回归。没有日志与回流，检索优化就是盲调；日志里「命中块 id」与「用户是否满意」关联起来，还能发现「检到了但用户不满意」的深层问题

来源说明

本文为原创整理，主要依据以下权威来源（截至 2026-08-23 均已核实可达，引用日期 2026-08-23）：

1. Okapi BM25 - Wikipedia——BM25 算法说明
2. HNSW 论文（arXiv 1603.09320）——分层可导航小世界图
3. ColBERT 论文（arXiv 2004.12832）——后期交互检索模型
4. MTEB（embeddings-benchmark）——embedding 评测基准
5. OpenAI Embeddings 文档——text-embedding 系列能力与用法
6. Cohere Embed 文档与 Cohere Rerank 文档——多语言 embedding 与托管 rerank
7. Anthropic Contextual Retrieval——上下文化切块与混合检索
8. Qdrant 官方文档：Hybrid Queries——RRF / DBSF 融合方式与工程建议
9. LangChain 官方文档：Cross encoder reranker——rerank 原理与模型选型
10. LlamaIndex 官方文档：Node Parser Modules与 Evaluating——切块策略与检索评测
11. BAAI/bge 仓库——bge 系列 embedding 与 reranker 模型
12. Milvus、Qdrant、Chroma、pgvector、FAISS 官方站点/仓库——向量数据库与索引库定位

发现错误？想一起完善？ 在 GitHub 上编辑此页！
本页面贡献者：AI-PM Wiki Team
本页面的全部内容在 CC BY-SA 4.0 和 SATA 协议之条款下提供，附加条款亦可能应用