向量数据库入门与选型：从云原生视角看语义检索这波变革

一篇关于向量数据库的入门与选型分析。不写通稿，只说真话。 阅读时间：约 7 分钟 | 标签：#向量数据库 #云原生 #RAG #技术选型

云原生这十年，做的是把存储、计算、网络一步步解耦、托管、做成服务。AI 这波，做的是把「语义检索」也解耦出来——而承接它的，就是向量数据库。

过去一年，向量数据库从冷门品类变成了 RAG 应用的标配（Menlo Ventures 调研显示，RAG 在 2024 年已占企业 AI 部署的 51%）。这篇不讲产品清单，讲清楚它是什么、三条选型路线怎么走，以及云上开发者落地该注意什么。

一、向量数据库解决什么问题

向量数据库，存的是「向量」——一串表示意义的数字，做的是语义相似度检索。

传统库做精确匹配，擅长回答「金额大于 100 的订单有哪些」，但回答不了「找一找和这条投诉最像的 10 条记录」。因为传统匹配是字面相等，而「意思相近」是另一套逻辑。

一句话：传统库问「字面上像不像」，向量库问「意思上近不近」。

二、三个核心概念

Embedding：把意思变成数字。 用模型把文本、图片转成固定长度的数字，语义相近的内容向量也相近。上限在 Embedding 模型，不在数据库自己——中文场景要挑中文友好的模型（BGE 系列这类）。

相似度检索：在比距离。 余弦相似度（比方向，最常用）、欧氏距离、内积三种度量，本质就是「拿查询向量，去库里找离它最近的那批向量」。

ANN 索引：用近似换速度。 暴力扫描太慢，近似最近邻（ANN）允许偶尔漏几个，换毫秒级响应。主流三种：

衡量好坏看三个指标：召回率（准不准）、延迟（快不快）、吞吐（扛不扛得住）。别只看「99% 召回」——从 90% 提到 99%，往往要几倍的内存或延迟代价。

三、选型三条路线，云上该怎么选

专用向量库：Milvus、Qdrant、Pinecone、Zilliz、Weaviate。性能调教得最好，但是套独立存储系统，等于又养一座数据孤岛。

传统库的向量扩展：pgvector 是代表。国产库里金仓 KingbaseES 等也在关系库上提供了向量扩展能力，企业不必另起炉灶。好处是一站式。

云托管向量服务：把向量检索当服务用，免运维、随用随扩。对已经深度绑定某朵云、不想养第二套系统的团队，这是最省事的路径；代价是接受一定生态绑定。

我的判断：绝大多数公司现阶段根本不需要专用向量库。 数据没到千万级、延迟没到毫秒级苛求，pgvector 就够用。图灵奖得主 Stonebraker 在 2024 年论文里判断，专用数据库市场终将被关系型数据库吸收——我不认为会这么快，但方向值得信。

四、给开发者的落地启示

1. 先跑通再选型。 pgvector 是低成本入场券，先验证语义检索在你的数据上有没有价值，再决定要不要上更重的方案。
2. 别急着重构。 先看清三件事：向量量级（百万/千万/亿）、查询形态（纯语义还是混合）、一致性要求。
3. 混合检索才是生产常态。 真实查询往往要「关键词 + 标签过滤 + 语义」一起，向量检索和全文检索融合（RRF 之类）才是完整方案。
4. 警惕单点 SOTA。 看召回率、延迟、吞吐的三角权衡，别被厂商的单点数字带偏。
5. 更新删除提前问清。 向量进了索引，删除或更新一条数据的索引一致性怎么保证，是很多方案没讲清的工程点。

结语

语义检索这波，落地门槛比想象低。想清楚数据量、查询形态和数据在哪，就能选对路线——多数场景 pgvector 起步，规模化后再看云托管或专用库。

本文基于公开信息与个人从业经验独立撰写，不代表任何厂商立场。

李白客，信创行业独立观察者。关注数据库、AI基础设施与国产化替代。