微信扫码
添加专属顾问
我要投稿
构建RAG应用的关键组件全解析,从模型选型到检索排序,帮你避开技术选型陷阱。 核心内容: 1. 向量模型选型指南:关键指标与中文场景推荐 2. 向量库与检索方式的技术对比与适用场景分析 3. 排序器的作用原理及与检索流程的协同优化
想做智能客服、企业知识库、RAG 应用?你绕不开的问题是:该用什么向量模型?用什么库?用什么排序器?本篇一次讲清
向量模型是整个语义检索链路的第一步,选错模型,后面再怎么优化都救不回来。
一个文本 embedding 模型的核心目标是:
把文本映射成一个能表达语义的向量,供向量库做检索、排序或相似度计算。
我们选模型时,主要看这几个维度:
语义表达能力(semantic fidelity) | |
压缩率(是否能低维表达) | |
领域适应性 | |
中英文支持 | |
模型大小/部署难度 | |
是否能用于 rerank |
BGE-M3 | BAAI/bge-m3 | |||
BGE-small-zh | BAAI/bge-small-zh | |||
text2vec-base-chinese | shibing624/text2vec-base-chinese | |||
GTE-base | thenlper/gte-base | |||
E5 系列 | intfloat/multilingual-e5-base | |||
Cohere embed-multilingual-v3 |
📌 简单选型建议:
bge-small-zh
或 text2vec-base-chinese
bge-m3
GTE-base
或 E5
很多人以为维度高 = 精度高,其实不对,这两个概念要分开:
维度(Dimension) | |
精度(Precision) | |
举个例子 |
有了好向量,还要有好仓库,否则查得慢、存得乱、删不掉。
向量库的主要功能就是:
快速存储 + 检索向量,支持近似最近邻搜索(ANN)。
为什么不用列表存呢?比如你有 100 万条文档,每条都是 768 维的向量,用户来一个 Query,你不能每次都和所有向量算一遍余弦距离,太慢了。所以你需要专业的向量库,用各种**加速算法(如 IVF、HNSW)**来快速找到最接近的 K 条向量。
FAISS | ||||
Milvus | ||||
Qdrant | ||||
Weaviate | ||||
ElasticSearch | ||||
Chroma |
这一点很重要,但很多人忽略,尤其是在做“文档知识库问答”时:
document_id
删除,不仅要删 metadata,还要删对应向量不要直接覆盖!
chunk_id
、doc_id
,方便追踪和更新检索 = 信息命中的关键策略,关键词 vs 向量 vs 混合,各有千秋,选错方法可能“差之毫厘谬以千里”。
关键词检索 | ||||
向量检索 | ||||
混合检索 |
BM25
是最常见的关键词匹配算法(Elasticsearch、Whoosh、Lucene)通常是以下结构:
1. 问题 -> Embedding 向量
2. 向量检索召回 Top-K 文档(广撒网)
3. + BM25/关键词命中过滤(精准查找)
4. + Reranker 精排打分(语义判断)
适合高精度场景,比如医疗、法律文档检索。
在检索过程中,可以结合结构化的元数据做“筛选”:
通常写在 切片的时候,或者嵌入的时候一起加入向量库中,比如:
{
"content": "XXXX",
"metadata": {
"source": "合同A.pdf",
"type": "付款条款",
"page": 12,
"created_at": "2023-10-01"
}
}
这时候你就可以在检索前,先用 metadata 做「结构化过滤」。
TopK 是一个很常见的术语,意思是:
从所有候选结果中,取出相关性最高的前 K 个文档。
比如:
所以:
这取决于你使用的检索方法,不同方式的评分函数不同:
BM25 | |
向量检索 | |
语义 rerank |
总结:不同的检索方法,用不同的“评分机制”来判断文档是否 relevant。
这是现代大模型知识检索系统里的一个经典两阶段流程:
目的:快速从海量文本中挑出一批“可能相关”的文档;
常用方法:
快但不准,就像捞鱼捞上来一堆。
目的:对召回出来的这 50~100 条再精细排序,找出语义上最贴合的问题的内容;
方法:
bge-reranker
、ColBERT、MiniLM 等);就像把捞上来的鱼一个个检查,再选出最肥美的几条。
这就像在面试筛选简历一样:先粗筛(召回)→再精排打分。
在 embedding 之前,清洗和切片是影响效果的“隐性关键因素”,但很多人忽略了它们的重要性。
文档不是越长越好,也不是越短越强 —— 切片策略=召回质量的下限
常见方式:
建议每段 200~500 字左右,太长影响召回精度,太短会语义不完整;
每个 chunk 加上 chunk_id
、doc_id
,方便更新 & 溯源;
有结构的内容(如 FAQ)建议保留原始字段结构,别拆散。
53AI,企业落地大模型首选服务商
产品:场景落地咨询+大模型应用平台+行业解决方案
承诺:免费POC验证,效果达标后再合作。零风险落地应用大模型,已交付160+中大型企业
2025-07-30
Spring AI + Milvus 实现 RAG 智能问答实战
2025-07-30
AI问答系统崩溃?这篇RAG优化实战指南,教你解决90%的检索问题
2025-07-30
基于MCP-RAG的大规模MCP服务精确调用方法
2025-07-30
优化 AI 问答准确率:知识库实践与避坑指南
2025-07-30
RAG召回优化完全指南:从理论到实践的三大核心策略!
2025-07-30
从0到1,彻底搞懂 RAG 分块的艺术(附开源代码)
2025-07-30
大规模RAG实施蓝图
2025-07-29
一小时内构建基于Gemma与Bright Data的生产级RAG应用
2025-06-06
2025-05-30
2025-06-05
2025-05-19
2025-05-08
2025-05-10
2025-06-05
2025-05-20
2025-06-05
2025-05-09
2025-07-28
2025-07-09
2025-07-04
2025-07-01
2025-07-01
2025-07-01
2025-07-01
2025-06-30