当前位置：首页 > news >正文

向量数据库详解：RAG 系统的核心引擎与多模态检索

news 2026/6/11 11:22:24

大家好，我是小耶，写功课只是为了我踩过的坑，你们别再踩了！

这两年AI太火了，尤其是大模型和RAG（检索增强生成）。你可能听说过“向量数据库”这个词，但未必清楚它到底是什么、跟传统数据库有什么关系、什么时候该用它。

先想象一个场景：你问大模型“公司年假怎么休”，可它只训练到去年，最新的制度不知道。怎么办？你可以从内部文档库里把最新版《员工手册》找出来，把相关内容喂给大模型，它就能答上了。问题是，内部文档可能有几万份，怎么快速找到最相关的那几段？这就需要向量检索。

你可以把每份文档看作一个点，位置由它的“语义坐标”决定——相似的文档在空间中靠得近。当用户提问时，把问题也变成一个点，然后找出空间中离它最近的几个文档点。这就是向量数据库做的事。

一、什么是向量嵌入（Vector Embedding）？

我们都有过寄信的经历：每个地址都能转换成一个邮政编码，邮编相近的地址地理位置也相近。向量嵌入做的类似：把图片、文本、音频等数据，通过AI模型转换成一串固定长度的数字（向量），语义相近的数据在向量空间中也靠得近。

常用模型：

文本：OpenAI text-embedding-3-large（1536维）、BGE（1024维）
图像：CLIP、ResNet
多模态：CLIP（可以同时编码图文）

向量检索的本质就是计算两个向量的距离（欧氏距离、余弦相似度等），找出最接近的几个。

二、向量数据库的核心能力

向量存储：支持高维向量（通常128-4096维）的存储。
相似性检索：给定一个向量，返回最相似的K个向量（KNN/ANN）。
高效索引：近似最近邻索引（HNSW、IVF、PQ）将检索复杂度从O(N)降到O(logN)。
标量过滤：支持在向量检索的同时附加条件过滤（如WHERE category='文档'）。
混合检索：向量相似度 + 关键词匹配（BM25）组合。

HNSW算法：你可以想象一个多层的高速公路网——顶层只有少数大站，底层是密密麻麻的小路。检索时，先从顶层快速跳跃到目标区域，再层层往下精细搜索。这样，原本需要看所有点的线性扫描，变成了对数级的跳跃查找。百万级数据也能毫秒响应。

三、主流方案的选择逻辑：先想清楚你要什么

聊完原理，你可能会问：那到底该用哪种向量数据库？专用向量库、传统库加扩展、还是融合数据库？

别急着看对比，先想清楚三个问题：

1. 你的数据量有多大？

几千条到几十万条：几乎任何方案都能应付。
百万到千万级：开始考验索引效率和内存占用。
亿级以上：专用向量库的架构优势会明显体现。

2. 向量检索之外，你还需要什么？

是否要关联查询业务表（比如查完相似商品，还要JOIN库存表）？
是否要用事务保证数据一致性？
是否需要SQL标准接口（方便现有开发团队）？

3. 你的运维能力如何？

愿意多维护一套新系统吗？
有GPU资源吗（部分向量库依赖GPU加速）？
云上还是自建？

这三个问题的答案，基本决定了你的方向。

专用向量数据库：代表产品 Milvus、Pinecone、Qdrant。它们的设计目标非常纯粹——极致向量检索。如果你只有向量检索需求，数据量上亿，对延迟极度敏感，并且不介意多维护一套系统，选它。它的优势是索引算法丰富（HNSW、IVF、PQ等），支持GPU加速，云原生弹性好。但代价是：① 你没法用SQL JOIN关联你的业务表；② 事务和强一致性不是它的强项；③ 多一套组件，运维复杂度上升。

传统关系库 + 向量扩展：代表产品 PostgreSQL + pgvector。如果你已经有一套PG在跑，数据量在百万级以下，不想引入新组件，这是最省事的方案。pgvector 用法简单，支持SQL，能和现有表做JOIN。但它的索引和查询优化器不如专用库成熟，数据量大了性能下降明显，且不支持分布式扩展。

融合数据库：代表产品金仓 KingbaseES V9（内建向量）。这种方案的设计理念是“多模一体”——向量不是孤岛，而是数据库内置的一种数据类型，可以和关系表、JSON、GIS 放在同一个SQL里混合查询。适合中等数据量（百万到千万级），且业务需要向量与关系数据频繁关联的场景。比如“找出图片相似的产品，并且库存>0、价格低于100元”——一条SQL搞定，不用应用层拼接。它的劣势是：纯向量检索性能略低于专用库；分布式能力相对弱；技术较新，生态还在成长。

选型对比一览

方案	适合数据量	能否关联关系表	额外运维成本	典型场景
专用向量库	亿级以上	❌ 需应用层拼	高	图搜、推荐召回、纯向量
传统库+扩展	百万级以下	✅ 支持	低	已有PG，小规模POC
融合数据库	百万～千万级	✅ 原生支持	中	多模关联、信创、中小规模

四、向量数据库在RAG中的角色

RAG（检索增强生成）流程：

离线阶段：将文档分块，用Embedding模型生成向量，存入向量数据库。
在线阶段：用户提问，将问题转成向量；向量数据库检索Top-K相似文档块；将检索结果 + 原始问题拼成Prompt；大模型生成回答。

为什么需要向量数据库？如果没有它，每次提问都要遍历所有文档（几十万次相似度计算），响应时间不可接受。向量索引将检索从分钟级降到毫秒级。

其他应用场景：推荐系统（用户向量+商品向量召回）、多模态检索（以图搜图）、异常检测（离群点识别）、去重聚类等。

五、选型决策建议

小规模、已有PG：从 pgvector 起步，够用就继续。
**纯向量检索、海量数据（>5000万）**：选专用向量库，别犹豫。
**向量需要和业务表、GIS、文档一起查，且数据量中等（百万～千万）**：融合数据库最省心，一条SQL搞定关联。
信创环境 + 多模需求：金仓V9是目前国内较完整的一体化方案。

向量数据库不是“传统数据库的替代品”，而是AI应用时代的新基建。它的核心价值在于：将非结构化数据转化为可计算、可检索的向量形式，为推荐、搜索、RAG等场景提供毫秒级相似性检索能力。选型时不需要盲目跟风，更不要被厂商的“跑分”迷惑——先搞清楚自己的数据规模、是否需要多模关联、团队运维能力，再对号入座。技术选型这件事，适合的才是最好的。

小耶在手，SQL 不愁

还有什么想了解的，欢迎留言！小耶一定知无不言言无不尽……我们下次见~

参考文献