在 RAG 中,稀疏向量(Sparse Vector)和稠密向量(Dense Vector)有什么区别?
在 RAG(检索增强生成)系统中,检索(Retrieval)的质量直接决定了最终生成的答案是否准确。而检索的核心在于如何将文本(Query 和 Document)转化为计算机可以计算的数字形式。
稀疏向量(Sparse Vector)和稠密向量(Dense Vector)是两种截然不同的文本表示方式。简单来说:稀疏向量主要用于关键词匹配,稠密向量主要用于语义理解。
以下是详细的对比分析:
1. 核心概念与直观理解
稀疏向量 (Sparse Vector)
- 直观理解: “词袋模型”或关键词搜索。
- 原理: 向量的维度等于整个词汇表的大小(通常是几万到几十万)。如果文本中包含了某个词,向量中对应的位置就是非零值(通常是 TF-IDF 值或 BM25 权重);如果没包含,该位置就是 0。
- 特点: 因为一句话只包含词汇表中的极少数词,所以向量中绝大多数位置都是 0(因此得名“稀疏”)。
- 代表算法: BM25, TF-IDF, SPLADE (一种学习型的稀疏向量)。
稠密向量 (Dense Vector)
- 直观理解: “语义坐标”。
- 原理: 通过深度学习模型(如 BERT, OpenAI Embeddings)将文本压缩到一个固定的低维空间(通常是 768, 1024 或 1536 维)。模型通过阅读海量文本,学会了将含义相近的词放在空间中相近的位置。
- 特点: 向量中的每个位置都是一个实数(浮点数),几乎没有 0(因此得名“稠密”)。
- 代表模型: BERT, text-embedding-3-small (OpenAI), Cohere Embed。
2. 详细对比表
| 特性 | 稀疏向量 (Sparse) | 稠密向量 (Dense) |
|---|---|---|
| 匹配逻辑 | 字面匹配 (Lexical Match) | 语义匹配 (Semantic Match) |
| 关注点 | 具体的关键词、专有名词、精确短语 | 句子的意图、上下文、同义词关系 |
| 维度 | 极高 (例如 30,000+) | 较低且固定 (例如 768, 1536) |
| 数据形态 | 大部分是 0,仅少数非零值 | 全部是非零浮点数 |
| 泛化能力 | 差 (无法识别同义词) | 强 (能识别"手机"和"移动电话"是相似的) |
| 精确度 | 对特定名词(如型号、ID)极高 | 可能丢失细节,对特定名词不敏感 |
| 计算方式 | 倒排索引 (Inverted Index) | 向量相似度计算 (Cosine Similarity, ANN) |
3. 在 RAG 中的具体表现差异
为了更好地理解,我们看一个具体的 RAG 场景例子。
用户提问: “怎么解决 iPhone 15 充电发烫的问题?”
场景 A:使用稀疏向量 (BM25)
- 检索逻辑: 系统会寻找文档中明确包含 “iPhone 15”、“充电”、“发烫” 这几个词的片段。
- 优势: 非常精准。如果文档里写的是 “iPhone 14”,它可能就会降低权重,因为它知道你要找的是 “15”。对于产品型号、错误代码(如 Error 404)、人名等精确信息,稀疏向量表现极佳。
- 劣势(词汇鸿沟): 如果文档里写的是“苹果手机电池过热解决方案”,虽然意思完全一样,但因为没有“发烫”这个词,稀疏向量可能根本找不到这篇文档。
场景 B:使用稠密向量 (Embedding)
- 检索逻辑: 系统将提问转化为向量,去寻找在语义空间距离最近的文档。
- 优势: 能够理解“发烫”约等于“过热”,“iPhone”属于“苹果手机”。即使文档中没有出现完全一样的词,只要意思相近,就能被检索出来。
- 劣势: 有时会“模糊化”细节。比如它可能觉得“iPhone 15 充电发烫”和“安卓手机电池过热”在语义上很像(都是手机电池问题),从而检索出错误的文档。对于区分“V1.2版本”和“V1.3版本”这种细微差别,稠密向量往往表现不佳。
4. 为什么现在的 RAG 流行“混合检索” (Hybrid Search)?
由于两者各有优缺点,现代成熟的 RAG 系统(如 Elasticsearch, Pinecone, Weaviate 等向量数据库支持的方案)通常采用 混合检索。
流程如下:
- 并行检索: 同时使用稀疏向量(BM25)和稠密向量(Embedding)对 Query 进行检索。
- 结果合并: 获取两组候选文档。
- 重排序 (Reranking): 使用 RRF (Reciprocal Rank Fusion) 算法或专门的 Rerank 模型(如 BGE-Reranker, Cohere Rerank)将两组结果的得分进行加权融合。
结论:
- 如果你需要 RAG 系统能够理解用户的模糊意图(比如“那个被咬了一口的logo的公司” -> 检索到“Apple”),你需要 稠密向量。
- 如果你需要 RAG 系统精准匹配特定的专业术语、SKU 编号或法律条款,你绝对不能丢掉 稀疏向量。
- 最佳实践是:两者都要(混合检索)。