RAG 检索四件套全解析：模型、向量库、检索方式、排序器，一文选型不踩坑

显示全部楼层

想做智能客服、企业知识库、RAG 应用？你绕不开的问题是：该用什么向量模型？用什么库？用什么排序器？本篇一次讲清

一、向量模型

向量模型是整个语义检索链路的第一步，选错模型，后面再怎么优化都救不回来。

1.什么是向量模型？核心关注点有哪些？

一个文本 embedding 模型的核心目标是：

把文本映射成一个能表达语义的向量，供向量库做检索、排序或相似度计算。

我们选模型时，主要看这几个维度：

指标	说明
语义表达能力（semantic fidelity）	能否区分语义细微差别，比如“关闭灯”和“打开灯”之间
压缩率（是否能低维表达）	像 GTE 模型只有 384 维，而 BGE 有 1024 维，但效果不一定差
领域适应性	是通用模型还是特定领域的（如医疗、法律）？
中英文支持	有些模型只适合英文，如 OpenAI ada v2，有些是多语言
模型大小/部署难度	能不能本地部署？资源占用大不大？
是否能用于 rerank	有些模型能用于排序（如 BGE-Reranker），有些只能做检索

2.常见向量模型选型建议（中文语境为主）

模型	维度	优点	适用场景	HuggingFace ID
BGE-M3	1024	强大通用语义表达能力，中英皆可	检索 + rerank	`BAAI/bge-m3`
BGE-small-zh	384	小模型，适合中文场景，本地部署轻量	ToC 向量检索	`BAAI/bge-small-zh`
text2vec-base-chinese	768	中文文本匹配效果稳定，兼容 clip 图文对齐	中文项目、图文混合场景	`shibing624/text2vec-base-chinese`
GTE-base	768	OpenAI 替代品，多语言支持好	通用任务、跨语言	`thenlper/gte-base`
E5 系列	768	英文表现强、也有中英多语言版	多语言语义搜索	`intfloat/multilingual-e5-base`
Cohere embed-multilingual-v3	1024	商用强、支持 100 多种语言	国际化产品、长文本召回	需用 API

📌简单选型建议：

个人轻量测试、本地化→bge-small-zh或text2vec-base-chinese
公司级、支持 rerank→bge-m3
中英混合、国际化场景→GTE-base或E5

3.向量维度 ≠ 精度，二者的区别？

很多人以为维度高 = 精度高，其实不对，这两个概念要分开：

概念	说明
维度（Dimension）	向量的长度，比如是 384、768 还是 1024 维。它影响的是“表达能力上限”。维度越高，模型有更多空间表达复杂语义关系。但也可能引入噪声。
精度（Precision）	通常指模型在特定任务上的检索准确率，比如 Top-1 命中率、MRR（Mean Reciprocal Rank）、Recall@K。它取决于训练数据、目标任务是否匹配，而不是维度本身。
举个例子	一个 384 维的模型可能在法律领域比 1024 维的通用模型效果还好（因为数据更贴近）

二、向量库

有了好向量，还要有好仓库，否则查得慢、存得乱、删不掉。

1.什么是向量库？为什么不能直接用 list 存向量？

向量库的主要功能就是：

快速存储 + 检索向量，支持近似最近邻搜索（ANN）。

为什么不用列表存呢？比如你有 100 万条文档，每条都是 768 维的向量，用户来一个 Query，你不能每次都和所有向量算一遍余弦距离，太慢了。所以你需要专业的向量库，用各种**加速算法（如 IVF、HNSW）**来快速找到最接近的 K 条向量。

📚 2.主流向量库差异对比

向量库	语言	特点	是否推荐本地部署	是否支持多字段搜索（metadata）
FAISS	C++/Python	Meta 出品，轻量、快，适合本地测试	✅ 强烈推荐	❌（基础功能不支持 metadata）
Milvus	C++/Go	全功能、工业级、支持结构化 + 非结构化混合检索	✅ 推荐部署服务端	✅ 支持结构化字段过滤
Qdrant	Rust	快速、多功能、支持 REST/gRPC、embedding 版本管理很方便	✅ 强烈推荐	✅ 强支持（可对 metadata 索引）
Weaviate	Go	自带 RAG 特性，支持 hybrid 检索和 GraphQL 查询	✅ 中大型项目推荐	✅
ElasticSearch	Java	老牌搜索引擎，加了 dense_vector 向量功能	✅（但安装复杂）	✅ 强大（传统搜索引擎转向量）
Chroma	Python	本地开发神器，零依赖，LangChain 默认集成	✅ 轻量开发推荐	✅（但性能有限）

✅ 推荐选型策略（看你是哪类项目）

使用场景	推荐库	原因
本地轻量测试	FAISS / Chroma	快、简单、集成方便
中型项目（多用户、多字段）	Qdrant / Milvus	高性能 + 支持 metadata + 支持 REST/gRPC
想做 hybrid 检索（关键词 + 向量）	Weaviate / ElasticSearch	有结构化 + semantic 搜索能力
有中文大数据、需要稳定上线	Milvus（Zilliz 出品）	生态全、企业支持强

🔧 3.插入 / 删除 / 更新文档时，如何管理向量？

这一点很重要，但很多人忽略，尤其是在做“文档知识库问答”时：

✅ 插入：

新增文档 → 切片 → 向量化 → 存入向量库要记得带上对应的 metadata，比如标题、时间、部门等。

✅ 删除：

按document_id删除，不仅要删 metadata，还要删对应向量
有些库（如 Qdrant）支持按标签批量删除

✅ 更新：

不要直接覆盖！

通常要先删除旧的，再插入新的切片 + 向量
原因是：一段文档可能被切成多个 chunk，如果直接“覆盖”，很容易残留旧片段

✍️ 补充技巧：

插入时建议带上chunk_id、doc_id，方便追踪和更新
如果向量模型更新了，旧向量也要重算（不然新旧向量不一致）

三、检索

检索 = 信息命中的关键策略，关键词 vs 向量 vs 混合，各有千秋，选错方法可能“差之毫厘谬以千里”。

🎯 1.常见检索方式总览

检索方式	技术基础	优点	缺点	应用场景示例
关键词检索	BM25、TF-IDF	快速、解释性强	不懂语义，无法容错	FAQ 检索、搜索引擎
向量检索	Embedding + Faiss / Milvus 等	语义相关性强，能理解语言的含义	不懂结构、不精确、不透明	RAG 问答、智能客服、推荐系统
混合检索	向量 + 关键词 + rerank	结合语义与关键词，效果更好	实现复杂	高要求的智能搜索系统

🔍 2.关键词检索（Keyword-based Retrieval）

1. 原理

文档、问题 → 分词 → 统计词频（TF-IDF）或 BM25 打分 → 选出包含关键词的文档
不理解「语义」层面，比如“结婚”≠“婚礼”

2. 关键词检索优点

快、可解释：你知道它为啥命中，因为你看到词了
适合标题、标签、代码搜索等场景

3. 常用工具

BM25是最常见的关键词匹配算法（Elasticsearch、Whoosh、Lucene）
搜索引擎、电商站内搜索、PDF关键词命中

🧠 3.向量检索

1. 原理

每段文本 → 转成向量（用 Embedding 模型）
问题 → 也转成向量
相似度计算（通常是余弦相似度） → 得出最相近的文本段落

2. 向量检索优点

可理解语言语义，如“我累了”≈“我想休息一下”
能找到意思相近但没有关键词重合的内容

3. 缺点

不解释为什么召回了这些文本
不适合精确查找、对结构敏感的信息（比如合同条款）

⚖️ 4.混合检索（Hybrid Retrieval）

通常是以下结构：

1. 问题 -> Embedding 向量
2. 向量检索召回 Top-K 文档（广撒网）
3. + BM25/关键词命中过滤（精准查找）
4. + Reranker 精排打分（语义判断）

适合高精度场景，比如医疗、法律文档检索。

🏷️ 5.元数据过滤（Metadata Filtering）

在检索过程中，可以结合结构化的元数据做“筛选”：

每条文档不仅有文本，还有：类型（FAQ、新闻）、来源（文档名、网页）、时间（2024年）、语言等信息
举例：只要「2023年以后的医学文献」+「PDF 提取的内容」

元数据存储在哪里？

通常写在切片的时候，或者嵌入的时候一起加入向量库中，比如：

{
"content":"XXXX",
"metadata": {
 "source":"合同A.pdf",
 "type":"付款条款",
 "page":12,
 "created_at":"2023-10-01"
 }
}

这时候你就可以在检索前，先用 metadata 做「结构化过滤」。

四、排序

🧠 1.什么是 TopK？

TopK是一个很常见的术语，意思是：

从所有候选结果中，取出相关性最高的前 K 个文档。

比如：

你有 10 万条 FAQ；
用户提问：“怎么退货”；
系统通过某种相似度算法（BM25、embedding 等）打分后，取得相关性最高的前 3 条——这就是 top3。

所以：

✅ “K”是你设定的参数；
✅ “相关性”是通过评分函数来的，评分函数的计算方式取决于检索方法；
✅ 适合用户提问比较明确的场景，通常会搭配 rerank 使用。

🧠 2.TopK 背后的“相关性”是怎么判断的？

这取决于你使用的检索方法，不同方式的评分函数不同：

检索方式	相似度/相关性分数是怎么来的？
BM25	基于词频+逆文档频率（TF-IDF）+词位信息
向量检索	计算 Query 和文档向量的余弦相似度
语义 rerank	用更大的 LLM 比较语义相关性（例如 bge-reranker）

总结：不同的检索方法，用不同的“评分机制”来判断文档是否 relevant。

⚔️ 3.召回（Recall） vs 精排（Rerank）

这是现代大模型知识检索系统里的一个经典两阶段流程：

✅ 1. 召回（Recall）

目的：快速从海量文本中挑出一批“可能相关”的文档；
常用方法：

BM25、向量相似度（embedding）；
通常取 Top50、Top100，比较宽松；

快但不准，就像捞鱼捞上来一堆。

✅ 2. 精排（Rerank）

目的：对召回出来的这 50～100 条再精细排序，找出语义上最贴合的问题的内容；
方法：

用更大的模型打分（如bge-reranker、ColBERT、MiniLM 等）；
成本高一点，但准确度提升显著；

就像把捞上来的鱼一个个检查，再选出最肥美的几条。

这就像在面试筛选简历一样：先粗筛（召回）→再精排打分。

五、数据清洗 & 🪓 切片策略（别忽视！）

在 embedding 之前，清洗和切片是影响效果的“隐性关键因素”，但很多人忽略了它们的重要性。

1.数据清洗建议：

删掉无效字段（如页眉、页脚、水印、页码、二维码识别失败字符等）；
保留标题、段落、表格、列表等结构信息，别做成纯文本流；
清除乱码 / HTML tag / 多余空格等噪音；
PDF / 扫描图请先 OCR，但 OCR 后的结构往往极差，建议后处理重建结构（如文档树 / JSON 格式）。

2.切片策略：

文档不是越长越好，也不是越短越强 ——切片策略=召回质量的下限

常见方式：

固定长度 + 滑动窗口（适合结构化文档）；
按语义/标题/换段切分（适合 Markdown、手册类）；

建议每段 200～500 字左右，太长影响召回精度，太短会语义不完整；
每个 chunk 加上chunk_id、doc_id，方便更新 & 溯源；
有结构的内容（如 FAQ）建议保留原始字段结构，别拆散。