一篇关于向量数据库的入门与选型分析。不写通稿，只说真话。
阅读时间：约 7 分钟 | 标签：#向量数据库 #RAG #技术选型 #云原生
云原生这十年，做的是把存储、计算、网络一步步解耦、托管、做成服务。AI 这波，做的是把「语义检索」也解耦出来——而承接它的，就是向量数据库。
过去一年，向量数据库从冷门品类变成了 RAG 应用的标配（Menlo Ventures 调研显示，RAG 在 2024 年已占企业 AI 部署的 51%）。这篇不讲产品清单，讲清楚它是什么、三条选型路线怎么走，以及开发者落地该注意什么。
一、向量数据库解决什么问题
向量数据库，存的是「向量」——一串表示意义的数字，做的是语义相似度检索。
传统库做精确匹配，擅长回答「金额大于 100 的订单有哪些」，但回答不了「找一找和这条投诉最像的 10 条记录」。因为传统匹配是字面相等，而「意思相近」是另一套逻辑。
一句话：传统库问「字面上像不像」，向量库问「意思上近不近」。
二、三个核心概念
Embedding：把意思变成数字。 用模型把文本、图片转成固定长度的数字，语义相近的内容向量也相近。上限在 Embedding 模型，不在数据库自己——中文场景要挑中文友好的模型（BGE 系列这类）。
相似度检索：在比距离。 余弦相似度（比方向，最常用）、欧氏距离、内积三种度量，本质就是「拿查询向量，去库里找离它最近的那批向量」。
ANN 索引：用近似换速度。 暴力扫描太慢，近似最近邻（ANN）允许偶尔漏几个，换毫秒级响应。主流三种：
| 算法 | 一句话原理 | 精度 | 查询速度 | 内存 |
|---|---|---|---|---|
| HNSW | 分层图，从粗到细跳近目标 | 高 | 快 | 大 |
| IVF | 聚类分桶，只搜最近的几个桶 | 中 | 中 | 较小 |
| PQ | 切段量化，用压缩换内存 | 较低 | 快 | 最小 |
衡量好坏看三个指标：召回率（准不准）、延迟（快不快）、吞吐（扛不扛得住）。别只看「99% 召回」——从 90% 提到 99%，往往要几倍的内存或延迟代价。
三、选型三条路线，怎么选
专用向量库：Milvus、Qdrant、Pinecone、Zilliz、Weaviate。性能调教得最好，但是套独立存储系统，等于又养一座数据孤岛。
传统库的向量扩展：pgvector 是代表。国产库里金仓 KingbaseES 等也在关系库上提供了向量扩展能力，企业不必另起炉灶。好处是一站式。
云托管向量服务：把向量检索当服务用，免运维、随用随扩。对已经深度绑定某朵云、不想养第二套系统的团队，这是最省事的路径；代价是接受一定生态绑定。
我的判断：绝大多数公司现阶段根本不需要专用向量库。 数据没到千万级、延迟没到毫秒级苛求，pgvector 就够用。图灵奖得主 Stonebraker 在 2024 年论文里判断，专用数据库市场终将被关系型数据库吸收——我不认为会这么快，但方向值得信。
四、给开发者的落地启示
- 先跑通再选型。 pgvector 是低成本入场券，先验证语义检索在你的数据上有没有价值，再决定要不要上更重的方案。
- 别急着重构。 先看清三件事：向量量级（百万/千万/亿）、查询形态（纯语义还是混合）、一致性要求。
- 混合检索才是生产常态。 真实查询往往要「关键词 + 标签过滤 + 语义」一起，向量检索和全文检索融合（RRF 之类）才是完整方案。
- 警惕单点 SOTA。 看召回率、延迟、吞吐的三角权衡，别被厂商的单点数字带偏。
- 更新删除提前问清。 向量进了索引，删除或更新一条数据的索引一致性怎么保证，是很多方案没讲清的工程点。
结语
语义检索这波，落地门槛比想象低。想清楚数据量、查询形态和数据在哪，就能选对路线——多数场景 pgvector 起步，规模化后再看云托管或专用库。
数据来源：RAG 企业部署占比引自 Menlo Ventures 调研；专用库市场判断引自 Michael Stonebraker 2024 年论文观点。
